Created attachment 916590 [details] build log ``` In file included from /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/include/llvm/Support/Threading.h:21, from /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/include/llvm/Support/Mutex.h:16, from /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/lib/Support/Unix/Signals.inc:44, from /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/lib/Support/Signals.cpp:277: /usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/ciso646:46:4: warning: #warning "<ciso646> is deprecated in C++17, use <version> to detect implementation-specific macros" [-Wcpp] 46 | # warning "<ciso646> is deprecated in C++17, use <version> to detect implementation-specific macros" | ^~~~~~~ ```
Created attachment 916591 [details] emerge --info
The error is: ``` FAILED: lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_sse2_x86-64_unix.S.o /usr/bin/x86_64-pc-linux-gnu-gcc -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm_build-abi_x86_64.amd64/lib/Support/BLAKE3 -I/var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/lib/Support/BLAKE3 -I/var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm_build-abi_x86_64.amd64/include -I/var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/include -DNDEBUG -march=x86-64-v3 -O2 -pipe -fPIC -MD -MT lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_sse2_x86-64_unix.S.o -MF lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_sse2_x86-64_unix.S.o.d -o lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_sse2_x86-64_unix.S.o -c /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/lib/Support/BLAKE3/blake3_sse2_x86-64_unix.S /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/lib/Support/BLAKE3/blake3_sse2_x86-64_unix.S: Assembler messages: /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/lib/Support/BLAKE3/blake3_sse2_x86-64_unix.S:1910: Error: operand type mismatch for `mov' /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/lib/Support/BLAKE3/blake3_sse2_x86-64_unix.S:1911: Error: operand type mismatch for `mov' ``` I suspect your binutils is miscompiled. Let's check that before going further. (See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409) Please try: FEATURES="-test" CFLAGS="-O2 -fdisable-tree-ifcombine" emerge -v1 sys-devel/binutils, then try llvm again.
Actually, you already have fixed GCC, sorry, so what you need to do (to recover from broken gas), is if you cannot rebuilt binutils, build it with Clang which has an integrated assembler: FEATURES="-test" CFLAGS="-O2" CC=clang emerge -v1 sys-devel/binutils.
Oh yes! Sorry, I missed the error completely by focusing on `<ciso646>` depr. Rebuilt binutils with Clang, llvm compiled successfully Should I rebuild GCC with patchset 39 (https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1b3664d4b7d4519739e274ebd7da0dadca8035e9) or wait until Sunday for the next Snapshot?
(In reply to David Goudou from comment #4) > Oh yes! Sorry, I missed the error completely by focusing on `<ciso646>` depr. > > Rebuilt binutils with Clang, llvm compiled successfully > > Should I rebuild GCC with patchset 39 > (https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=1b3664d4b7d4519739e274ebd7da0dadca8035e9) or wait until Sunday for the > next Snapshot? I'm not aware of any real-world packages broken like that testcase Jakub shows in PR118456 (ofc it's possible, I just mean I've not seen any issues yet that are ifcombine-related since the -r1 batch). If your machine is fast enough, maybe rebuild for the peace of mind, but if it's not, I think it's probably good enough to wait.
I do recommend running testsuites for various packages via package.env w/ FEATURES=test if using unreleased compilers. You can help find such issues :)
I'll add some packages with `FEATURES=test` (as I usually do an emerge -1 binutils / -e @world after GCC 15 updates). Will submit bugs if I come across anything
(In reply to David Goudou from comment #7) > I'll add some packages with `FEATURES=test` (as I usually do an emerge -1 > binutils / -e @world after GCC 15 updates). Will submit bugs if I come > across anything Please do! While I would encourage you to do it for at least a lot of @system packages and "generally important" ones, it is especially useful if you could do it for a selection of packages that you personally use a lot or have installed that *aren't* common.
David, can you let me know if you hit this still after building binutils with latest gcc (-r1 or ideally -r2)? bug 948202 has me worried there's something lurking still (I can't reproduce it yet).
Hi Sam, can confirm llvm-19.1.7 still fails to build with binutils on gcc-15 -r2
Created attachment 916773 [details] latest build log
Thanks for the quick reply! Can you do... ``` (cd /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm_build-abi_x86_64.amd64 && /usr/bin/x86_64-pc-linux-gnu-gcc -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm_build-abi_x86_64.amd64/lib/Support/BLAKE3 -I/var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/lib/Support/BLAKE3 -I/var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm_build-abi_x86_64.amd64/include -I/var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/include -DNDEBUG -march=x86-64-v3 -O2 -pipe -fPIC -MD -MT lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_sse2_x86-64_unix.S.o -MF lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_sse2_x86-64_unix.S.o.d -o lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_sse2_x86-64_unix.S.o -c /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/lib/Support/BLAKE3/blake3_sse2_x86-64_unix.S -save-temps) ``` and upload blake3_sse2_x86-64_unix.s (not lake3_sse2_x86-64_unix.S)? Frustratingly, I can't yet reproduce this -- trying to build binutils w/ -march=x86-64-v3 -O2 now.
Also, does dev-libs/blake3 fail to build for you?
Running that command errors out: ``` x86_64-pc-linux-gnu-gcc: warning: ‘-pipe’ ignored because ‘-save-temps’ specified /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/lib/Support/BLAKE3/blake3_sse2_x86-64_unix.S: Assembler messages: /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/lib/Support/BLAKE3/blake3_sse2_x86-64_unix.S:1910: Error: operand type mismatch for `mov' /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/lib/Support/BLAKE3/blake3_sse2_x86-64_unix.S:1911: Error: operand type mismatch for `mov' ``` dev-libs/blake3-1.5.3 fails to build
(In reply to David Goudou from comment #14) > Running that command errors out: > > ``` > x86_64-pc-linux-gnu-gcc: warning: ‘-pipe’ ignored because ‘-save-temps’ > specified > /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/lib/Support/BLAKE3/ > blake3_sse2_x86-64_unix.S: Assembler messages: > /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/lib/Support/BLAKE3/ > blake3_sse2_x86-64_unix.S:1910: Error: operand type mismatch for `mov' > /var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm/lib/Support/BLAKE3/ > blake3_sse2_x86-64_unix.S:1911: Error: operand type mismatch for `mov' > ``` > That's OK. It should still create the .s file somewhere. > dev-libs/blake3-1.5.3 fails to build Thanks. That gives me an easier way to check if I can break binutils ...
So far, I can't for the life of me make it happen with a recent build from trunk (so 15.0.9999). I guess I can try with -r2 next. But I don't know what would've fixed it, there's not been many wrong-code fixes...
Created attachment 916783 [details] blake3_sse2_x86-64_unix.S.s `./lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_sse2_x86-64_unix.S.s` Not sure if this is it
(In reply to David Goudou from comment #17) > Created attachment 916783 [details] > blake3_sse2_x86-64_unix.S.s > > `./lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_sse2_x86- > 64_unix.S.s` > > Not sure if this is it That's it. If you run `as /path/to/that`, it errors with the "operand ..." thing, right?
That's correct yup, pulled it from: `/var/tmp/portage/llvm-core/llvm-19.1.7/work/llvm_build-abi_x86_64.amd64/lib/Support/BLAKE3/CMakeFiles/LLVMSupportBlake3.dir/blake3_sse2_x86-64_unix.S.s`
Thanks. While I try look, would you be willing to try build gcc-15.0.9999, and then rebuild binutils with that, and see if it still fails to assemble that file / build blake3?
Ugh, I think I see it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b153d321e7b499c94cb370165dd58a0694195208 commit b153d321e7b499c94cb370165dd58a0694195208 Author: Sam James <sam@gentoo.org> AuthorDate: 2025-01-16 23:12:21 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-01-16 23:12:51 +0000 sys-devel/gcc: restore lost ifcombine patch I'd lost one of the ifcombine patches which fixed the binutils miscompilation, bleh. Closes: https://bugs.gentoo.org/948147 Closes: https://bugs.gentoo.org/948202 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/gcc/Manifest | 3 +- sys-devel/gcc/gcc-15.0.0_pre20250112-r2.ebuild | 53 ---------------------- ...-r1.ebuild => gcc-15.0.0_pre20250112-r3.ebuild} | 2 +- 3 files changed, 2 insertions(+), 56 deletions(-)
Thanks for the help & patience, and I'm sorry for my error.
Nice find. I'll let `gcc-15.0.9999` finish and then drop down to -r3 Thanks for fixing! :)
My plan is to migrate to a proper git-based workflow (from a fork of gcc.git) soon to help reduce the risk of such mistakes. The current janky one is one I inherited and it dates back to CVS-era workflows :(
