This matches the default used in userland, and the kernel already
depends on various GNU extensions to standard C that are supported by
both clang and GCC.
This should be a no-op for clang, but for GCC it enables some GNU
extensions that aren't otherwise enabled. It also enables GCC for
i386 to avoid the need for a floatundidf intrinsic in libkern.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D40646
As of clang 16, the -ftrivial-auto-var-init=zero option no longer needs
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
to enable the option. Only add it for older clang versions.
PR: 271047
Reviewed by: emaste
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D40208
We always build the kernel floating point support. Now that the
riscv64sf userspace variant has been removed the option is required for
correct operation.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39851
clang doesn't implement this warning, so violations are only caught by
GCC. It is also no longer a common practice to use this as it was in
the original BSD code, so the need for the warning is not as important
as when it was used to do cleanups 20 years ago. A recent commit
(c3179891f8) triggers this warning on
GCC, but that commit uses nested externs purposefully.
Reviewed by: markj, emaste
Differential Revision: https://reviews.freebsd.org/D39214
Silence -Winfinite-recursion for ldo.c in lua and -Wstringop-overread
for nvpair.c.
Reviewed by: mm
Differential Revision: https://reviews.freebsd.org/D37631
The mlx5 driver and some other OFED bits use a somewhat dubious
pattern of:
struct foo {
uint64_t arg[0];
/* Real members of a struct */
};
The code then treats 'arg' as if it were really a kind of union
such that foo.arg[N] functions similarly to (uint64_t *)foo[N].
This uses of foo.arg[N] then trigger this warning.
No real bugs were found by this warning though, so just turn it off
globally.
Reviewed by: hselasky, kib
Differential Revision: https://reviews.freebsd.org/D37630
Some of the warnings raised in the kernel seem to be outright bugs in
the compiler (e.g. the cases in ata_xpt.c and scsi_xpt.c). Other
cases are not fatal and it didn't seem to find any legitimate bugs in
the kernel.
Differential Revision: https://reviews.freebsd.org/D37629
The USB code and some other places raise false positives when a NULL
pointer is passed to an inlined function along with a separate length
and the compiler can't determine that the separate length of 0
prevents the use of the NULL pointer.
Differential Revision: https://reviews.freebsd.org/D37627
Clang 15 is more strict about function definitions not matching
declarations, and zlib has a lot of these, but since it is contributed
code (and in K&R style to boot), suppress those warnings instead.
MFC after: 3 days
make tinderbox now passes with this warning enabled as a fatal error,
so revert the change to hide it in preparation for making it fatal.
This reverts commit e8e691983b.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D34948
Use -Wno-unused-but-set-variable for kernel builds with clang13.
To turn this warning back on, set the following in src.conf:
WITH_SET_BUT_NOTUSED_KERNEL_WARNINGS=
Reviewed by: mjg, imp
Differential Revision: https://reviews.freebsd.org/D34784
Define NO_WUNUSED_BUT_SET_VARIABLE for newer clang, and use it in ATH_C
to account for different clang versions. Use it in Makefiles as well.
Sponsored by: Netflix
Reviewed by: kevans, jhb
Differential Revision: https://reviews.freebsd.org/D34408
GCC is more pedantic than clang about warning when a function doesn't
handle undefined enum values (see GCC bug 87950). Clang's warning
gives a more pragmatic coverage and should find any real bugs, so
disable the warning for GCC rather than adding __unreachable
annotations to appease GCC.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D34147
Parts of zstd, used in openzfs and other places, trigger a new clang 14
-Werror warning:
```
sys/contrib/zstd/lib/decompress/huf_decompress.c:889:25: error: use of bitwise '&' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
(BIT_reloadDStreamFast(&bitD1) == BIT_DStream_unfinished)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
While the warning is benign, it should ideally be fixed upstream and
then vendor-imported, but for now silence it selectively.
MFC after: 3 days
clang doesn't implement it, and Linux doesn't enforce it. As a
result, new instances keep cropping up both in FreeBSD's code and in
upstream sources from vendors.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D34144
Remove sys/mips as the next step of decomissioning mips from the tree.
Remove mips special cases from the kernel make files. Remove the mips
specific linker scripts.
Sponsored by: Netflix
GCC complains about the use of alloca() with variable sizes (for XSAVE
state len) in sendsig() for i386. Modern XSAVE state is probably
getting a bit large for the i386 kstack, but downgrade the error to a
warning.
Reviewed by: kib, emaste
Differential Revision: https://reviews.freebsd.org/D31934
Clang 13.0.0 now has a -Wunused-but-set-variable warning similar to the
one gcc has had for quite a while. Since this triggers *very* often for
our kernel builds, don't make it a hard error, but leave the warning
visible so is some incentive to fix the instances.
MFC after: 3 days
With current generation clang/llvm it can pass all of our tests in
libc/ssp.
While here, remove the extra MACHINE_CPUARCH check for mips. SSP is
included in BROKEN_OPTIONS for this architecture in src.opts.mk, which
is enough to ensure normal builds won't set SSP_CFLAGS.
Reviewed by: kevans, imp, emaste
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D31400
This warning is very rarely useful (inline is a hint and not mandatory).
This flag results in many warnings being printed when compiling C++
code that uses the standard library with GCC.
This flag was originally added in back in r94332 but the flag is a no-op
in Clang ("This diagnostic flag exists for GCC compatibility, and has no
effect in Clang"). Removing it should make the GCC build output slightly
more readable.
Reviewed By: jrtc27, imp
Differential Revision: https://reviews.freebsd.org/D29235
Clang 12 no longer supports -Wno-error-..., only the -Wno-error=...
style (which is already used everywhere else in the tree).
Differential Revision: https://reviews.freebsd.org/D29157
When I synchronized kern.mk with bsd.sys.mk, I accidentally changed
CCLDFLAGS to LDFLAGS which is not used by the kernel builds. This commit
should unbreak the GitHub actions cross-build CI. I didn't notice it
locally because cheribuild already passes -fuse-ld in the linker flags as
it predates this being done in the makefiles.
Reported By: Jose Luis Duran
Fixes: 172a624f0 ("Silence annoying and incorrect non-default linker warning with GCC")
The CROSS_TOOLCHAIN GCC .mk files include -B${CROSS_BINUTILS_PREFIX}, so
GCC will select the right linker and we don't need to warn.
While here also apply 17b8b8fb5f to kern.mk.
Test Plan: no more warning printed with CROSS_TOOLCHAIN=mips-gcc6
Reviewed By: jhb
Differential Revision: https://reviews.freebsd.org/D29015
After the removal of obsolete GDB 6.1.1 from the base system in
1c0ea326aa we no longer need to downgrade to DWARF2 debug info.
We will need to ensure that our tools (e.g. ctfconvert) handle DWARF5
prior to it becoming the default in the Clang and GCC versions we use.
Reported by: jhb
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
-mno-align-long-strings was a flag maintained by FreeBSD for the
now-deleted in-tree gcc. Upstream gcc has no such flag, so just drop
it.
The flag was originally submitted by bde and committed in 2002 (svn
r97911 & r104455). However, upstream gcc did address this same issue in
2004 (gcc svn r76694 / git 4137ba7ab7a), reducing long string alignment
in general, and to 1 with -Os.
Reviewed by: kib
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D27768
These options need to be in the kern.opts.mk file to be alive for kernel
and module builds. This also reverts r367579 since that's not needed with
this fix: the host's bsd.opts.mk is irrelevant.
Reviewed by: brooks@
Differential Revision: https://reviews.freebsd.org/D27170
When building out-of-tree modules, it appears that the system share/mk
is used, but sys/conf/kern.mk is used. That results in MK_INIT_ALL_ZERO
being undefined. In the interest of maximum compatability, check
that MK_INIT_ALL_* and COMPILER_FEATURES are defined before comparing
their values.
Reported by: mmacy
Sponsored by: DARPA
There are two options:
- WITH_INIT_ALL_ZERO: Zero all variables on the stack.
- WITH_INIT_ALL_PATTERN: Initialize variables with well-defined patterns.
The exact pattern are a compiler implementation detail and vary by type.
They are somewhat documented in the LLVM commit message:
https://reviews.llvm.org/rL349442
I've used WITH_INIT_ALL_* to match Microsoft's InitAll feature rather
than naming them after the LLVM specific compiler flags.
In a range of consumer products, options like these are used in
both debug and production builds with debugs builds using patterns
(intended to provoke crashes on use of uninitialized values) and
production using zeros (deemed more likely to lead to harmless
misbehavior or NULL-pointer dereferences).
Reviewed by: emaste
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D27131
This is the initial set up for PowerPC64LE.
The current plan is for this arch to remain experimental for FreeBSD 13.
This started as a weekend learning project for me and kinda snowballed from
there.
(More to follow momentarily.)
Reviewed by: imp (earlier version), emaste
Sponsored by: Tag1 Consulting, Inc.
Differential Revision: https://reviews.freebsd.org/D26399
When using relative paths for the linker we have to transform the name
since clang does not like -fuse-ld=ld.lld and instead requires -fuse-ld=lld
(the same also applies for ld.bfd).
This is needed so that setting LD/XLD is not ignored when linking with $CC
instead of directly using $LD. Currently only clang accepts an absolute
path for -fuse-ld= (Clang 12+ will add a new --ld-path flag), so we now
warn when building with GCC and $LD != "ld" since that might result in the
wrong linker being used.
We have been setting XLD=/path/to/cheri/ld.lld in CheriBSD for a long time and
used a similar version of this patch to avoid linking with /usr/bin/ld.
This change is also required when building FreeBSD on an Ubuntu with Clang:
In that case we set XCC=/usr/lib/llvm-10/bin/clang and since
/usr/lib/llvm-10/bin/ does not contain a "ld" binary the build fails with
`clang: error: unable to execute command: Executable "ld" doesn't exist!`
unless we pass -fuse-ld=/usr/lib/llvm-10/bin/ld.lld.
This change passes -fuse-ld instead of copying ${XLD} to WOLRDTMP/bin/ld
since then we would have to ensure that this file does not exist while
building the bootstrap tools. The cross-linker might not be compatible with
the host linker (e.g. when building on macos: host-linker= Mach-O /usr/bin/ld,
cross-linker=LLVM ld.lld).
Reviewed By: brooks, emaste
Differential Revision: https://reviews.freebsd.org/D26055
