this option from all modules that enable it theirselves.
In C mode -fms-extensions option enables anonymous structs and unions,
allowing us to use this C11 feature in kernel. Of course, clang supports
it without any extra options.
Reviewed by: dim
The C standard undefines behavior when signed integers overflow. The
compiler toolchain has become more adept at detecting this and taking
advantage of faster undefined behavior. At the current time this has the
unfortunate effect of the clock stopping after 24 days of uptime.
clang makes no distinction between -fwrapv and -fno-strict-overflow. gcc
does treat them differently but -fwrapv is mature in gcc and is the
behavior are actually expecting.
Obtained from: kib
__attribute__((format(...))), and the -fformat-extensions flag was
removed, introduce a new macro in bsd.sys.mk to choose the right variant
of compile flag for the used compiler, and use it.
Also add something similar to kern.mk, since including bsd.sys.mk from
that file will anger Warner. :-)
Note that bsd.sys.mk does not support the MK_FORMAT_EXTENSIONS knob used
in kern.mk, since that knob is only available in kern.opts.mk, not in
src.opts.mk. We might want to add it later, to more easily support
external compilers for building world (in particular, sys/boot).
get the tail part of the path. We can now build kernels the
old-fashioned way on FreeBSD 9.x and 10.x on at least amd64 using
clang 3.3, 3.4 or gcc 4.2.1 (though with the latter you need
WITHOUT_MODULES="aesni vmm cxgbe" due to various issues with
gcc 4.2.1).
has support for the .codeXX directives). However, it is desirable, for
a time, to allow kernels to be built with clang 3.4. Historically, it
has been advantageous to allow stable X-1 to build kernels the old
way (so long as the impact of doing so is small), and this restores
that ability.
Also, centralize the addition of ${ASM_CFLAGS.${.IMPSRC}}, place it in
kern.mk rather than kern.pre.mk so that all modules can benefit, and
give the same treatment to CFLAGS in kern.mk as well.
building with gcc 4.2
This has been requested several times over the past few months by several
people (including me), because gcc 4.2 just gets it wrong too often. It's
causing us to litter the code with lots of bogus initializers just to
squelch the warnings. We still have clang and coverity telling us about
uninitialized variables, and they do so more accurately.
CWARNFALGS.$file centrally so we don't have to have it in all the
places. Remove a few warning flags that are no longer needed.
Also, always use -Wno-unknown-pragma to (hopefully temporarily) work
around #pragma ident in debug.h in the opensolaris code. Remove some
stale warning suppression that's no longer necessary.
the place where the C dialect is selected. Have a fairly long list
of newly requires warning suppression for clang 3.5.0, also
centralized in kern.mk. Survive the fallout of the removal of
bsd.sys.mk from bsd.kmod.mk.
raft of new warnings that appear to be on by default in clang 3.5.0.
Fix RPI-B build issues with new clang not liking the ability to pass
arbitrary flags to as, since some flags are more arbitrary (and thus
verboten) than others.
These warnings should be actually fixed in the code, but this is a
band-aide to get things (almost) building again.
cutover is, but we need better tools to cope with inline tuning per
compiler version than we have. This is a quick bandaid until such
tools are around.
completely silenced. Make sure these warnings appear again, so there is
some incentive to fix them, but do not error out the whole kernel build
for them.
Noticed by: steven@pyro.eu.org
PR: 191867
MFC after: 3 days
This includes:
o All directories named *ia64*
o All files named *ia64*
o All ia64-specific code guarded by __ia64__
o All ia64-specific makefile logic
o Mention of ia64 in comments and documentation
This excludes:
o Everything under contrib/
o Everything under crypto/
o sys/xen/interface
o sys/sys/elf_common.h
Discussed at: BSDcan
o KMODDEPS warning is 15 years stale. Remove it.
o MK_CTF will always be defined now, so no need to test to see if it
is defined.
o no need to define MK_FORMAT_EXTENTIONS if undefined anymore.
generate dwarf4 by default as well, so always force dwarf2 when
generating debugging data. It is harmless on older versions of both
clang and gcc, but required on newer ones.
though it works w/o it for some reason, contrary to our reading of
make(1)). Also add a comment explaining things a bit better so there's
one less mystery that must be answered with svn blame.
Submitted by: ian@
add it in kern.mk, but only if we're using clang. While this
option is supported by both clang and gcc, in the future there
may be changes to clang which change the defaults that require
a tweak to build our kernel such that other tools in our tree
will work. Set a good example by forcing -gdwarf-2 only for
clang builds, and only if the user hasn't specified another
dwarf level already. Update UPDATING to reflect the changed
state of affairs. This also keeps us from having to update
all the ARM kernels to add this, and also keeps us from
in the future having to update all the MIPS kernels and is
one less place the user will have to know to do something
special for clang and one less thing developers will need
to do when moving an architecture to clang.
Reviewed by: ian@
MFC after: 1 week
-mcmodel=large, for now. While here, disable -msoft-float for clang
since it is not supported, and add -fno-dwarf2-cfi-asm to stop it from
emitting .cfi directives, which GNU as does not support.
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC after: 1 month
for signed values due to a compiler authors considering integer
overflow as impossible.
The change follows suit of other projects taking the same measure.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
type of compiler is being used (currently clang or gcc). COMPILER_TYPE
is set in the new bsd.compiler.mk file based on the value of the CC
variable or, should it prove informative, by running ${CC} --version
and examining the output.
To avoid negative performance impacts in the default case and correct
value for COMPILER_TYPE type is determined and passed in the environment
of submake instances while building world.
Replace adhoc attempts at determining the compiler type by examining
CC or MK_CLANG_IS_CC with checks of COMPILER_TYPE. This eliminates
bootstrapping complications when first setting WITH_CLANG_IS_CC.
Sponsored by: DARPA, AFRL
Reviewed by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>, imp, linimon
(with some modifications post review)
MFC after: 2 weeks
sys/dev/mps/mps_sas.c:861:1: error: function 'mpssas_discovery_timeout' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
mpssas_discovery_timeout(void *data)
^
Because the driver is obtained from upstream, we don't want to modify
it; just silence the warning instead, it is harmless.
MFC after: 3 days
to match reality: clang does _not_ disable SSE automatically when
-mno-mmx is used, you have to specify -mno-sse explicitly.
Note this was the case even before r232894, which only makes a change in
the 'positive' flag case; e.g. when you specify -msse, MMX gets enabled
too.
MFC after: 1 week
of the Cavium Simple Executive, which violates large function growth rules
in such a way that simply increasing the large function growth parameter is
insufficient.
that it is better to error out when people attempt to build using the
wrong bsd.*.mk files, than to silently ignore the problem.
This means, that after this commit, if you want to build kernel modules
by hand (or via a port) from a head source tree, you *must* make sure
the files in /usr/share/mk are in sync with that tree. If that isn't
possible, for example when you are running on an older FreeBSD branch,
you can:
- Run "make buildenv" from your head source tree, to have the correct
environment setup. (It's advisable to have run "make buildworld", or
at a minimum "make toolchain" first.)
- Alternatively, set MAKESYSPATH to the share/mk directory under your
head source tree. If your build tools are too old, other problems may
still occur.
- Alternatively, use "make -m" and specify the share/mk directory under
your head source tree. Again, build tools that are too old may still
result in trouble.
MFC after: 2 weeks
kernel modules using their old installed /usr/share/mk/bsd.*.mk files,
instead of the updated ones in their source tree. This leads to errors
like:
"sys/conf/kmod.mk", line 111: Malformed conditional (${MK_CLANG_IS_CC} == "no" && ${CC:T:Mclang} != "clang")
Obviously, these errors will go away after a "make installworld", or
alternatively, by using "make buildenv" before attempting to manually
build modules.
However, since it is apparently an expected use case to build using old
.mk files, change the way we test for clang, so it also works when the
MK_CLANG_IS_CC macro doesn't exist.
Note the conditional expressions are becoming rather unreadable now, but
I will attempt to fix that on a followup commit.
MFC after: 2 weeks
installs clang as /usr/bin/cc, /usr/bin/c++ and /usr/bin/cpp.
Note this does *not* disable building and installing gcc, which will
still be available as /usr/bin/gcc, /usr/bin/g++ and /usr/bin/gcpp. If
you want to disable gcc completely, you must use WITHOUT_GCC.
MFC after: 2 weeks
sys/dev/hpt27xx/osm_bsd.c, since it gets the following warnings:
sys/dev/hpt27xx/osm_bsd.c:1180:25: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]
S_IRUSR | S_IWUSR, driver_name);
^~~~~~~~~~~
@/dev/hpt27xx/hpt27xx_config.h:46:21: note: expanded from:
#define driver_name hpt27xx_driver_name
^~~~~~~~~~~~~~~~~~~
Since 'hpt27xx_driver_name' is a constant string symbol (coming from the
proprietary hpt27xx_lib.o file), there is no security problem.
Because this driver is provided by the vendor, and applying changes
requires re-certification and other bureaucratic exercises, just disable
the warning for now.
MFC after: 1 week
several sys/cam/ctl files, since these get the following warnings:
In file included from sys/cam/ctl/ctl_backend.c:60:
sys/cam/ctl/ctl_private.h:300:30: error: variable 'page_index_template' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]
static struct ctl_page_index page_index_template[] = {
^
These warnings are tricky to fix without a lot of overhaul, and they are
harmless, so disable them for now.
MFC after: 1 week
All of these are harmless, and are in fact used to shut up warnings from
lint.
While here, remove -Wno-missing-prototypes from the xfs module
Makefile, as I could not reproduce those warnings either with gcc or
clang.
MFC after: 1 week
with clang. There are several macros in these files that return values,
and in some cases nothing is done with them, but it is completely
harmless. For some other files, also disable -Wconstant-conversion,
since that triggers a false positive with the DMA_BIT_MASK() macro.
MFC after: 1 week
