Created attachment 826391 [details] emerge --info Not sure if y'all follow bugs about crossdev-generated toolchains, or if there's another category in bugzilla for them - feel free to move as required. --- # emerge -av1O cross-xtensa-esp32s2-elf/gcc These are the packages that would be merged, in order: [ebuild U *] cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023:13::crossdev [13.0.0_pre20220918:13::crossdev] USE="-ada -cet -custom-cflags -cxx -d -debug -doc -fixed-point -fortran -go -graphite -hardened -jit -libssp -lto (multilib) -nls -nptl -objc -objc++ -objc-gc -openmp (-pch) -pgo -pie -sanitize -ssp -systemtap -test -valgrind -vanilla -vtv zstd" 0 KiB … (5 minutes pass) … /var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/build/xtensa-esp32s2-elf/libgcc [1] # /var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/build/./gcc/xgcc -freport-bug -B/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/build/./gcc/ -B/usr/xtensa-esp32s2-elf/bin/ -B/usr/xtensa-esp32s2-elf/lib/ -isystem /usr/xtensa-esp32s2-elf/include -isystem /usr/xtensa-esp32s2-elf/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -mlongcalls -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fno-stack-clash-protection -Dinhibit_libc -mlongcalls -I. -I. -I../.././gcc -I/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/gcc-13-20221023/libgcc -I/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/gcc-13-20221023/libgcc/. -I/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/gcc-13-20221023/libgcc/../gcc -I/var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/gcc-13-20221023/libgcc/../include -DHAVE_CC_TLS -o _absvdi2.o -MT _absvdi2.o -MD -MP -MF _absvdi2.dep -DL_absvdi2 -c /var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/gcc-13-20221023/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS *** stack smashing detected ***: terminated during RTL pass: expand /var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/gcc-13-20221023/libgcc/libgcc2.c: In function '__absvdi2': /var/tmp/portage/cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023/work/gcc-13-20221023/libgcc/libgcc2.c:244:22: internal compiler error: Aborted 244 | const DWtype v = 0 - (a < 0); | ~~^~~~~~~~~ 0x139ab2a diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1], diagnostic_t) ???:0 0x139ba08 internal_error(char const*, ...) ???:0 0xb167ef crash_signal(int) ???:0 0x7fc8c6e4c731 raise ???:0 0x7fc8c6e37468 abort ???:0 0x7fc8c6f279a1 __fortify_fail ???:0 0x7fc8c6f2797f __stack_chk_fail ???:0 0x115effa gen_movdi(rtx_def*, rtx_def*) ???:0 0x7dcd97 emit_move_insn_1(rtx_def*, rtx_def*) ???:0 0x7e41dc gen_move_insn(rtx_def*, rtx_def*) ???:0 0x7c782f canonicalize_comparison(machine_mode, rtx_code*, rtx_def**) ???:0 0x7c7bd4 emit_store_flag_1(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode, int, int, machine_mode) ???:0 0x7c8114 emit_store_flag(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode, int, int) ???:0 0x7c8c3d emit_store_flag_force(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode, int, int) ???:0 0x7d3d4f do_store_flag(separate_ops*, rtx_def*, machine_mode) ???:0 0x7d49b4 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ???:0 0x7db5b5 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ???:0 0x7d4ca1 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ???:0 0x7db5b5 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ???:0 0x7d5abe expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ???:0 Please submit a full bug report, with preprocessed source. Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions. The bug is not reproducible, so it is likely a hardware or OS problem. --- Even though it says it's not reproducible, it happens just the same every time I run that command, or even if I wipe /var/tmp/portage and merge again - so it's at least reproducible for _me_. As noted by portage, cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20220918 merged just fine Same happens with cross-xtensa-esp32-elf/gcc-13.0.0_pre20221023 as well (esp32 rather than esp32s2) Also, cross-avr/gcc-13.0.0_pre20221023 succeeded in the same emerge run where this occurred - so it seems to be limited to xtensa or esp32 targets rather than anything general with cross-gcc-13.0.0_pre20221023 Searching "gen_movdi" turned up https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100106 although that looks like it's for ARM target rather than xtensa, and the fault location and backtrace is different I'll happily post this upstream if you like, but due to gentoo packaging it says to post here first - and I want to be able to tell them I already posted here before they ask.
Created attachment 826421 [details] build.log gzipped build log, full one is too big for bugzilla. Also available at https://triffid-hunter.no-ip.info/cross-xtensa-esp32s2-elf_gcc-13.0.0_pre20221023_build.log
Sorry, to be clear, "The bug is not reproducible, so it is likely a hardware or OS problem." is from you or what? I'd be surprised if it doesn't happen when you run the command again in the workdir. But yes, please send upstream & link it here, thanks! (Also, thanks for testing GCC 13).
https://wiki.gentoo.org/wiki/Gcc-ICE-reporting-guide too fwiw
(In reply to Sam James from comment #2) > Sorry, to be clear, "The bug is not reproducible, so it is likely a hardware > or OS problem." is from you or what? Nope, that's literally in gcc's terminal output - I found that odd too, especially after reproducing it
Created attachment 826571 [details] _absvdi2.i from -save-temps
Created attachment 826573 [details] _absvi2.dep from -save-temps
Created attachment 826575 [details] _absvdi2.s from -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107506#c1 sounds relevant I tried to grab gcc-13.0.9999 but: * Applying 12_all_disable-systemtap-switch.patch ... patching file gcc/configure Hunk #3 FAILED at 31389. 1 out of 3 hunks FAILED -- saving rejects to file gcc/configure.rej patching file gcc/configure.ac Hunk #1 FAILED at 6904. 1 out of 1 hunk FAILED -- saving rejects to file gcc/configure.ac.rej --- so I added that patch to upstreamed_patches and the build succeeded. Upstream bug is marked as resolved, what does that mean for this one? Should this stay open until another gcc-13.0.0_pre* that contains the fix is pushed?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/gcc-patches.git/commit/?id=01fd5d7f44dee4836111388a119aad4b5b3b232c commit 01fd5d7f44dee4836111388a119aad4b5b3b232c Author: Sam James <sam@gentoo.org> AuthorDate: 2022-11-02 17:06:56 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-11-02 17:07:27 +0000 13: drop upstreamed 12_all_disable-systemtap-switch.patch Bug: https://bugs.gentoo.org/879049 Signed-off-by: Sam James <sam@gentoo.org> .../gentoo/12_all_disable-systemtap-switch.patch | 122 --------------------- 1 file changed, 122 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9fbebc2c9d78f49edf4863cde0cf8e24681e6b1d commit 9fbebc2c9d78f49edf4863cde0cf8e24681e6b1d Author: Sam James <sam@gentoo.org> AuthorDate: 2022-11-02 22:02:36 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-11-02 22:02:36 +0000 sys-devel/gcc: add 13.0.0_pre20221030 Closes: https://bugs.gentoo.org/879049 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/gcc/Manifest | 1 + sys-devel/gcc/gcc-13.0.0_pre20221030.ebuild | 53 +++++++++++++++++++++++++++++ 2 files changed, 54 insertions(+)
