Bug 83995 - CFLAGS & COPTFLAGS ambiguous behaviour
Summary: CFLAGS & COPTFLAGS ambiguous behaviour
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 6.0-BETA1
Hardware: Any Any
: Normal Affects Only Me
Assignee: Bryan Drewery
Depends on:
Reported: 2005-07-24 13:40 UTC by Gabor Kovesdan
Modified: 2018-05-28 19:44 UTC (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
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.


You might also want to seen my kernel config file:



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
Try to compile a GENERIC kernel with CFLAGS=-O3 -march=athlon64.
Comment 1 Enji Cooper freebsd_committer 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)
 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 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.
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 
- Untouched since 2018-01-01.
- Affects Base System OR Documentation


Reset to open status.

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.