Created attachment 916164 [details] Output of "emerge -v --info" I've been trying to build the latest version of sys-devel/gcc:14 for the past week or so with no success. Logs are hosted on my Google Drive space at the included link. "emerge --info" attached. I am running an LLVM profile. I've tried building this with LTO enabled and disabled, with the fallback gcc environment I've set up, and with ccache enabled and disabled. Each time and configuration, I've reached the same result. This may be similar to a build failure for gcc:13 on s390x.
I can't access the drive link ("access denied").
(In reply to Sam James from comment #1) > I can't access the drive link ("access denied"). I edited the link, please give that a try. If it still doesn't work, I'll find another way to share the logs.
Thanks, that works. Can you try with USE=-cet?
(In reply to Sam James from comment #3) > Thanks, that works. Can you try with USE=-cet? I gave USE="-cet" a try, and it appears the result is the same. [I'll note that cet should be disabled on my system, since my processor does not support it.] The logs from the last build can be found here: https://drive.google.com/file/d/10u4R8nHcgmL6do99QSJK94TZdlwdQ3jg/view?usp=sharing
Thanks. Could you provide a tarball of the differing object files? Specifically, I need ideally all but a subset of (so several) of the files from: ``` make[3]: Entering directory '/var/tmp/portage/sys-devel/gcc-14.2.1_p20241221/work/build' rm -f stage_current make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-14.2.1_p20241221/work/build' Comparing stages 2 and 3 Bootstrap comparison failure! gcc/build/genmodes.o differs gcc/build/errors.o differs gcc/build/genmddeps.o differs gcc/build/read-md.o differs gcc/build/genversion.o differs ``` I need *both* versions, so there will be some in one directory, and some in another. I don't remember the exact names, but please make your tarball structured like (roughly): stage2/build/genmodes.o stage3/build/genmodes.o and so on. This is required so we can analyse why they differ. Let me know if I need to explain more, thanks!
(In reply to Sam James from comment #5) > Thanks. > > Could you provide a tarball of the differing object files? > > Specifically, I need ideally all but a subset of (so several) of the files > from: > ``` > make[3]: Entering directory > '/var/tmp/portage/sys-devel/gcc-14.2.1_p20241221/work/build' > rm -f stage_current > make[3]: Leaving directory > '/var/tmp/portage/sys-devel/gcc-14.2.1_p20241221/work/build' > Comparing stages 2 and 3 > Bootstrap comparison failure! > gcc/build/genmodes.o differs > gcc/build/errors.o differs > gcc/build/genmddeps.o differs > gcc/build/read-md.o differs > gcc/build/genversion.o differs > ``` > > I need *both* versions, so there will be some in one directory, and some in > another. I don't remember the exact names, but please make your tarball > structured like (roughly): > > stage2/build/genmodes.o > stage3/build/genmodes.o > > and so on. This is required so we can analyse why they differ. > > Let me know if I need to explain more, thanks! I cleared the prior failure, and ran a new instance of "emerge -av1 gcc". The build failed as expected. I believe I got the appropriate files. I pulled them from the following directories: /var/tmp/portage/sys-devel/gcc-14.2.1_p20241221/work/build/stage2-gcc/build/ /var/tmp/portage/sys-devel/gcc-14.2.1_p20241221/work/build/stage3-gcc/build/ I also included the emerge generated log tarball from this build attempt. The link to the requested files is below. Thank you for your time and effort assisting me. https://drive.google.com/file/d/1RbUkVJRC9Qq-__q3p9s8_TI9OCBfTxF8/view?usp=sharing
Thanks! Not yet looked at the tarball, but let me make a remark: the root cause of bug 933772 was actually https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117952. So, without CET, we might actually just get a mismatch later on in the build for -march=native.
(In reply to Sam James from comment #7) > Thanks! Not yet looked at the tarball, but let me make a remark: the root > cause of bug 933772 was actually > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117952. So, without CET, we > might actually just get a mismatch later on in the build for -march=native. In fact, the more I think about it, yes, that's surely what is happening.. the stage1 compiler gets built not knowing how to detect native, then when using it to build stage2, it will emit generic binaries. Then the stage2 compiler will know how to determine native (as it was built by GCC) and when it builds stage3, the binaries will be different.
(In reply to Sam James from comment #8) > (In reply to Sam James from comment #7) > > Thanks! Not yet looked at the tarball, but let me make a remark: the root > > cause of bug 933772 was actually > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117952. So, without CET, we > > might actually just get a mismatch later on in the build for -march=native. > > In fact, the more I think about it, yes, that's surely what is happening.. > the stage1 compiler gets built not knowing how to detect native, then when > using it to build stage2, it will emit generic binaries. Then the stage2 > compiler will know how to determine native (as it was built by GCC) and when > it builds stage3, the binaries will be different. Well... this might be a wild goose chase... I remember reading about the issues earlier about --march=native, and setup package.env to specifically build gcc with --march=znver2. I'm sorry I missed that portage wasn't calling my package.env configuration. Turns out I misspelled sys-devel/gcc as sys-decel/gcc when adding a line for portage to call my compiler-gcc-nolto configuration. I previously built gcc calling a config that just subbed CFLAGS and CXXFLAGS that changed --march=native, but didn't call the fallback gcc environment recommended for LLVM profile users. I changed it as I started this bug. After fixing my typos, the build completed successfully. This maybe a result of setting USE="-cet" and ensuring --march != native. Thank you again for your time and assistance, I'm going to mark this bug as resolved.
No worries! I think we should strip -march=native for Clang builds, or force 4-stage bootstrap.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d6788adfff00dacda8c3f1a19d806dad5ba80e89 commit d6788adfff00dacda8c3f1a19d806dad5ba80e89 Author: Sam James <sam@gentoo.org> AuthorDate: 2025-01-19 01:16:12 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-01-19 01:16:12 +0000 toolchain.eclass: add TODO for collecting differing bootstrap objects Add a TODO for bootstrap comparison failures, where we should include the stage2 & stage3 differing objects to avoid having to ask reporters to manually collect... Bug: https://bugs.gentoo.org/904426 Bug: https://bugs.gentoo.org/920719 Bug: https://bugs.gentoo.org/932789 Bug: https://bugs.gentoo.org/947752 Signed-off-by: Sam James <sam@gentoo.org> eclass/toolchain.eclass | 2 ++ 1 file changed, 2 insertions(+)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dcaab8c1db8a33cfc110c1aecfef799b26be65ae commit dcaab8c1db8a33cfc110c1aecfef799b26be65ae Author: Sam James <sam@gentoo.org> AuthorDate: 2025-02-23 03:57:57 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-02-23 05:09:00 +0000 toolchain.eclass: strip -march=native when building with Clang -march=native doesn't work correctly in the stage2 compiler when the stage1 compiler is Clang (see PR117952 for details). We have two options until that is fixed: 1) strip -march=native, or 2) do 'bootstrap4' (which isn't super well-tested at the moment, see e.g. https://trofi.github.io/posts/301-another-gcc-profiling-bug.html) Choose 1). Thanks to immolo for testing. Bug: https://gcc.gnu.org/PR117952 Bug: https://bugs.gentoo.org/933772 Closes: https://bugs.gentoo.org/947752 Signed-off-by: Sam James <sam@gentoo.org> eclass/toolchain.eclass | 1 + 1 file changed, 1 insertion(+)
build failed w/ USE="lto" > make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-14.2.1_p20241221/work/build' > Comparing stages 2 and 3 > Bootstrap comparison failure! > gcc/lto1 differs > make[2]: *** [Makefile:27690: compare] Error 1 > make[1]: *** [Makefile:27670: stage3-bubble] Error 2 > make: *** [Makefile:27744: bootstrap-lean] Error 2 diff of gcc/lto1 bellow: --- build/stage2-gcc/lto1 +++ build/stage3-gcc/lto1 ├── objdump --line-numbers --disassemble --demangle --reloc --no-show-raw-insn --section=.text {} │ @@ -9748592,16 +9748592,16 @@ │ je 19f88f3 <concat+0x233> │ concat(): │ /var/tmp/portage/sys-devel/gcc-14.2.1_p20241221/work/gcc-14-20241221/libiberty/concat.c:151 │ lea 0x110(%rsp),%rax │ movl $0x8,(%rsp) │ vconcat_copy(): │ /var/tmp/portage/sys-devel/gcc-14.2.1_p20241221/work/gcc-14-20241221/libiberty/concat.c:73 │ - mov %r13,%r12 │ mov %r15,%rbx │ + mov %r13,%r12 │ concat(): │ /var/tmp/portage/sys-devel/gcc-14.2.1_p20241221/work/gcc-14-20241221/libiberty/concat.c:151 │ mov %rax,0x8(%rsp) │ lea 0x20(%rsp),%rax │ movl $0x30,0x4(%rsp) │ mov %rax,0x10(%rsp) │ vconcat_copy(): │ @@ -9748796,16 +9748796,16 @@ │ je 19f8b4c <reconcat+0x24c> │ reconcat(): │ /var/tmp/portage/sys-devel/gcc-14.2.1_p20241221/work/gcc-14-20241221/libiberty/concat.c:188 │ lea 0x120(%rsp),%rax │ movl $0x10,0x10(%rsp) │ vconcat_copy(): │ /var/tmp/portage/sys-devel/gcc-14.2.1_p20241221/work/gcc-14-20241221/libiberty/concat.c:73 │ - mov %r13,%r12 │ mov %r14,%rbx │ + mov %r13,%r12 │ reconcat(): │ /var/tmp/portage/sys-devel/gcc-14.2.1_p20241221/work/gcc-14-20241221/libiberty/concat.c:188 │ mov %rax,0x18(%rsp) │ lea 0x30(%rsp),%rax │ movl $0x30,0x14(%rsp) │ mov %rax,0x20(%rsp) │ vconcat_copy():
(In reply to Zhixu Liu from comment #13) > build failed w/ USE="lto" > Can you put that in a new bug please? I think this one is solved (and fully debugged).
(In reply to Sam James from comment #14) > (In reply to Zhixu Liu from comment #13) > > build failed w/ USE="lto" > > > > Can you put that in a new bug please? I think this one is solved (and fully > debugged). https://bugs.gentoo.org/951969
