Hello, I'm working with a Gentoo crossdev built GCC 11.1.0 with some user patches (in case anyone cares, this cross-compiler is for compiling for the Nintendo 3DS, so I am borrowing some patches from the devKitPro project). There is still a chance the patches are to blame, but I am not sure yet as the segfault happens inside lto1. I would love to be able to submit a bug report (if this turns out to be a proper bug) but I'm having a hard time reducing this to something not requiring a full project build. Part of the problem is the project I'm building against requires custom patches to newlib (adds an extra system library, or something like that, to newlib). Here's the specific lto1 invocation that segfaults (this is more for reference so that it's more clear where in the LTO phase things are going sideways): /usr/libexec/gcc/arm-3ds-none-eabi/11.1.0/lto1 -quiet -dumpbase ./arm9.elf.wpa -mfloat-abi=soft -mtune=arm946e-s -mthumb -mfloat-abi=soft -mcpu=arm946e-s -march=armv5te -g -O3 -version -fno-openmp -fno-openacc -fno-pie -fcf-protection=none -fltrans-output-list=./arm9.elf.ltrans.out -fwpa -fresolution=arm9.elf.res -flinker-output=exec @./arm9.elf.wpa.args.0 It blows up with the following output: $ /usr/libexec/gcc/arm-3ds-none-eabi/11.1.0/lto1 -quiet -dumpbase ./arm9.elf.wpa -mfloat-abi=soft -mtune=arm946e-s -mthumb -mfloat-abi=soft -mcpu=arm946e-s -march=armv5te -g -O3 -version -fno-openmp -fno-openacc -fno-pie -fcf-protection=none -fltrans-output-list=./arm9.elf.ltrans.out -fwpa -fresolution=arm9.elf.res -flinker-output=exec @./arm9.elf.wpa.args.0 GNU GIMPLE (Gentoo 11.1.0 p1) version 11.1.0 (arm-3ds-none-eabi) compiled by GNU C version 11.1.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version none GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU GIMPLE (Gentoo 11.1.0 p1) version 11.1.0 (arm-3ds-none-eabi) compiled by GNU C version 11.1.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version none GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 during IPA pass: inline lto1: internal compiler error: Segmentation fault 0x1145488 crash_signal /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/toplev.c:327 0x7f524fb6c4ff ??? ../sysdeps/unix/sysv/linux/sigaction.c:10 0x7f524fbccdf3 ??? ../sysdeps/x86_64/multiarch/../strchr.S:32 0x218cbc6 arm_parse_cpu_option_name(cpu_option const*, char const*, char const*, bool) /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/common/config/arm/arm-common.c:386 0x1644e47 arm_configure_build_target(arm_build_target*, cl_target_option*, gcc_options*, bool) /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/config/arm/arm.c:3211 0x169c476 arm_can_inline_p /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/config/arm/arm.c:32812 0x1fe8712 can_inline_edge_p /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/ipa-inline.c:378 0x1fedec4 inline_small_functions /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/ipa-inline.c:2016 0x1ff0b62 ipa_inline /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/ipa-inline.c:2723 0x1ff1a50 execute /usr/src/debug/cross-arm-3ds-none-eabi/gcc-11.1.0/gcc-11.1.0/gcc/ipa-inline.c:3122 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions. Using GDB, I can see that the problem is that by line gcc/config/arm/arm.c:3212 the opts->x_arm_tune_string variable is actually NULL even though the opts_set->x_arm_tune_string variable is not. From a lot more digging, the closest I can come up as to understanding what's going on is that this project builds with an explicit -mtune parameter, but the libc it's linking against is the default mulitlib thumb one, which does not appear to have any mtune information associated with it. At least, if I iterate through the function cl_target_option_stream_in in what appears to be a generated source file build/gcc/options-save.c:9102 (or thereabouts), I see the parameter x_arm_tune_string being extracted for all the different files in the project (specifically, if I do a "display data_in->file_data->file_name" I can see which files are being loaded in). All of the project object files have x_arm_tune_string as "arm946e-s". libc, on the other hand, doesn't: 2: ptr->x_arm_tune_string = 0x0 3: data_in->file_data->file_name = 0x2c83890 "/usr/lib/gcc/arm-3ds-none-eabi/11.1.0/../../../../arm-3ds-none-eabi/lib/thumb/libc.a" I think this is the source of the problem. It appears something is assuming that since global_options_set.x_arm_tune_string is not NULL that every object file should have this value set. This isn't the case for libc. I don't have a strong understanding of GCC, though, so I could be completely off the mark. Am I thinking about this correctly? Anything else I should be looking at? And are there any suggestions on how to reduce this to an example I can send as a bug report? Even if for some reason libc is bad, GCC shouldn't segfault. Thanks for reading my wall of text. Gabriel Marcano
