CFLAGS is used for some parts of the kernel when compiling. COPTFLAGS is supposed to be used for the compiling the critical parts of the kernel, however. Even if one leave COPTFLAGS unset, CFLAGS can cause kernel compiling failures, and it is an unwanted behaviour. Many people use userland optimizations with the CFLAGS macro in make.conf. I have made two typescripts. In the first case I commented out COPTFLAGS and only used CFLAGS. It failed. In the second case I commented out CFLAGS too, and the compilation was successful. http://tux.t-hosting.hu/with-cflags http://tux.t-hosting.hu/without-cflags You might also want to seen my kernel config file: http://tux.t-hosting.hu/DREAM Fix: Kernel Makefiles should be updated to get around this issue. For a workaround, CFLAGS might be commented out for kernel compiling, but one tend to think that CFLAGS don't have so much influence on kernel compiling. CFLAGS did't cause kernel compiling failures on older releases for me, thus it was difficult to realize this problem. How-To-Repeat: Try to compile a GENERIC kernel with CFLAGS=-O3 -march=athlon64.
Agreed. This logic is broken/confusing: 38 .if defined(DEBUG) 39 _MINUS_O= -O 40 CTFFLAGS+= -g 41 .else 42 .if ${MACHINE_CPUARCH} == "powerpc" 43 _MINUS_O= -O # gcc miscompiles some code at -O2 44 .else 45 _MINUS_O= -O2 46 .endif 47 .endif 48 .if ${MACHINE_CPUARCH} == "amd64" 49 .if ${COMPILER_TYPE} == "clang" 50 COPTFLAGS?=-O2 -pipe 51 .else 52 COPTFLAGS?=-O2 -frename-registers -pipe 53 .endif 54 .else 55 COPTFLAGS?=${_MINUS_O} -pipe 56 .endif 57 .if !empty(COPTFLAGS:M-O[23s]) && empty(COPTFLAGS:M-fno-strict-aliasing) 58 COPTFLAGS+= -fno-strict-aliasing 59 .endif 60 .if !defined(NO_CPU_COPTFLAGS) 61 COPTFLAGS+= ${_CPUCFLAGS} 62 .endif In particular, clang's version of COPTFLAGS always override the ${_MINUS_O}, -O on clang is synonymous with -O2, etc. brewery was complaining about this as well the other day/week.
People generally shouldn't be setting CFLAGS in make.conf. It's generally unwise and can lead to problems. I know people do it, but it's not a good idea and while it often works, there's enough places in the build where it doesn't to be annoying. We kludge around this issue today by setting CFLAGS for kernel builds (blowing away the CFLAGS settings that make.conf tried to set). This behavior is not a bug and shouldn't be changed. There's lots of other problems if you dig deeply enough. One of them is that the logic that is presented here is, in fact, bogus for the reasons discussed. Another is that COPTFLAGS isn't set for anything that uses custom CFLAGS since most of them omit COPTFLAGS. I have a fix for this. Another is we have too many options. NO_CPU_COPTFLAGS is one that should just die. It's not needed and not all that useful given you get the same effect with CPUTYPE= on the command line for the kernel build. I have WIP in this area, so please include me on any reviews before commits. https://reviews.freebsd.org/D4155
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.