Bug 83995

Summary: CFLAGS & COPTFLAGS ambiguous behaviour
Product: Base System Reporter: Gabor Kovesdan <gabor.kovesdan>
Component: kernAssignee: Bryan Drewery <bdrewery>
Status: Closed FIXED    
Severity: Affects Only Me CC: bdrewery, gabor.kovesdan, imp, ngie
Priority: Normal    
Version: 6.0-BETA1   
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190103
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193768

Description Gabor Kovesdan 2005-07-24 13:40:17 UTC 
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.
Comment 1 Enji Cooper freebsd_committer freebsd_triage 2015-11-10 12:59:57 UTC 
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.
Comment 2 Warner Losh freebsd_committer freebsd_triage 2015-11-15 04:35:23 UTC 
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
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:44:06 UTC 
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.
Comment 4 Warner Losh freebsd_committer freebsd_triage 2025-01-24 18:09:44 UTC 
The specific issues here have been fixed.