-- For x86_64 builtins preferring x86_64/floatundidf.S to floatundidf.c -- For x86_64 builtins preferring x86_64/floatundisf.S to floatundisf.c -- For x86_64 builtins preferring x86_64/floatdixf.c to floatdixf.c -- For x86_64 builtins preferring x86_64/floatundixf.S to floatundixf.c CMake Error at lib/crt/CMakeLists.txt:74 (message): /var/tmp/portage/sys-libs/compiler-rt-14.0.6-r1/work/compiler-rt-14.0.6_build/CMakeFiles/cmTC_zn9me.dir/CheckSectionExists.c:2:36: ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1-j4-20221013-070004 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-12.2.0 * clang/llvm (if any): clang version 15.0.2 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/15/bin Configuration file: /etc/clang/clang.cfg /usr/lib/llvm/15 15.0.2 Python 3.10.8 Available Ruby profiles: [1] ruby27 (with Rubygems) [2] ruby30 (with Rubygems) * Available Rust versions: [1] rust-bin-1.64.0 * The Glorious Glasgow Haskell Compilation System, version 9.0.2 php cli (if any): [1] php8.1 * GNU Make 4.3 HEAD of ::gentoo commit d570f90bc37945416fac36580349fea46f21319a Merge: b322f26fb42f 93c8551378c9 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Thu Oct 13 11:03:37 2022 +0000 Merge updates from master emerge -qpvO sys-libs/compiler-rt [ebuild R ] sys-libs/compiler-rt-15.0.2 USE="clang -debug -test -verify-sig" ABI_X86="32 (64)"
Created attachment 823891 [details] emerge-info.txt
Created attachment 823893 [details] CMakeError.log
Created attachment 823895 [details] CMakeOutput.log
Created attachment 823897 [details] emerge-history.txt
Created attachment 823899 [details] environment
Created attachment 823901 [details] etc.portage.tar.bz2
Created attachment 823903 [details] logs.tar.bz2
Created attachment 823905 [details] sys-libs:compiler-rt-14.0.6-r1:20221013-123744.log
Created attachment 823907 [details] temp.tar.bz2
I guess that's the work of clang-common[stricter]? Mentioned that on gentoo-dev ML, but I don't think -Werror=strict-prototypes makes much sense even with USE=stricter.. or at least not for widespread testing. int main() { return 0; } is valid in C2x and error'ing out on these breaks almost everything C in the tree, I don't think it's worth trying to worry about adding (void) everywhere. -Werror=deprecated-non-prototype is also not so great because it still errors out even with -std=gnu89, unless we really want to add -Wno-strict-prototypes everywhere with it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=930fe2268cbedda61e37fada65e57352d25d8761 commit 930fe2268cbedda61e37fada65e57352d25d8761 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-10-13 14:48:49 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-10-13 14:49:25 +0000 sys-devel/clang-common: drop -Werror=strict-prototypes,deprecated-non-prototype for 16.x We don't need either of these for Clang 16 as it's already strict enough and as noted in 6213a0be95909859a98c6ae60febb35de2e8f2fd, it affects e.g. -std=c89 too. Closes: https://bugs.gentoo.org/876985 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/clang-common/clang-common-16.0.0.9999.ebuild | 4 ---- sys-devel/clang-common/clang-common-16.0.0_pre20221010-r1.ebuild | 4 ---- 2 files changed, 8 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6213a0be95909859a98c6ae60febb35de2e8f2fd commit 6213a0be95909859a98c6ae60febb35de2e8f2fd Author: Sam James <sam@gentoo.org> AuthorDate: 2022-10-13 14:47:08 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-10-13 14:47:08 +0000 sys-devel/clang-common: drop -Werror=strict-prototypes for 15.x We're keeping -Werror=deprecated-non-prototype for 15.x as there's no better option though, as we need some way to emulate Clang 16's strict behaviour in Clang 15, even though this overshoots it a bit. But it isn't ideal as it still affects e.g. -std=c89. Bug: https://bugs.gentoo.org/876985 Signed-off-by: Sam James <sam@gentoo.org> .../{clang-common-15.0.2-r1.ebuild => clang-common-15.0.2-r2.ebuild} | 1 - sys-devel/clang-common/clang-common-15.0.3.9999.ebuild | 1 - 2 files changed, 2 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7acd5f570128aedd2b027bda84b3838539eba49e commit 7acd5f570128aedd2b027bda84b3838539eba49e Author: Sam James <sam@gentoo.org> AuthorDate: 2022-11-08 22:42:36 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-11-08 22:46:19 +0000 sys-devel/clang-common: drop -Werror=deprecated-non-prototype for 15.x, promote to 16.x Clang 16.x will make -Wimplicit-int, -Wimplicit-function-declaration, and -Wincompatible-function-pointer-type error by default. Clang 15.x+ also warns on -Wdeprecated-non-prototype but it's not becoming fatal yet. It'll be an error when the defaults in compilers change to C23. There's a LOT of breakage with -Werror=deprecated-non-prototype, and we do care about it, but the first batch of errors mentioned above are more important for the time being. We need to be able to triage and prioritise the bugs. So: * Clang 15 USE=stricter: only -Wimplict-int -Wimplicit-function-declaration and -Wincompatible-function-pointer-type are errors. * Clang 16 USE=stricter: upstream defaults (which include ^ as we're doing for clang 15) + -Wdeprecated-non-prototype as an error, because presumably if you set USE=stricter on *16*, you want something harsher than already will ship upstream. This more accurately lets developers in Gentoo set USE=stricter on clang-common for 15.x and get Clang 16.x behaviour rather than scaring the life out of them. Thanks to Ionen for talking this out with me. Bug: https://bugs.gentoo.org/876985 See: 930fe2268cbedda61e37fada65e57352d25d8761 Signed-off-by: Sam James <sam@gentoo.org> .../{clang-common-15.0.4.ebuild => clang-common-15.0.4-r1.ebuild} | 3 --- sys-devel/clang-common/clang-common-15.0.4.9999.ebuild | 3 --- sys-devel/clang-common/clang-common-16.0.0.9999.ebuild | 6 ++++++ ...20221023-r1.ebuild => clang-common-16.0.0_pre20221023-r2.ebuild} | 6 ++++++ ...pre20221104.ebuild => clang-common-16.0.0_pre20221104-r1.ebuild} | 6 ++++++ 5 files changed, 18 insertions(+), 6 deletions(-)
The issue in compiler-rt and LLVM itself is fixed in 15.0.5 too, fwiw.
*** Bug 879673 has been marked as a duplicate of this bug. ***
