>On 26/05/2021 12:36, Richard Earnshaw via Gcc-help wrote: >> >> >> On 26/05/2021 12:30, Richard Earnshaw wrote: >>> >>> >>> On 25/05/2021 18:05, Gabriel Marcano via Gcc-help wrote: >>>> 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 >>>> >>> >>> Thanks for the detailed analysis; using that I've been able to >>> reproduce this. All that's needed is something simple like >>> >>> gcc -O -c -march=armv8-a+simd -flto t1.c >>> gcc -O -c -mcpu=native -flto main.c >>> gcc -flto -o main main.o t1.o >>> >>> Where t1.c is >>> >>> int f() { return 1;} >>> >>> and main.c is >>> >>> int f(void); >>> int main() { return f(); } >>> >>> R. >> >> I've created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100767, but >> since you do not have a bugzilla account under your email address I >> can't add you on CC. >> >> R. > >This is now (hopefully) fixed on the master and gcc-11 branches. At >least, it fixes the testcase I showed above. > > >R. Alright, I tested the patch, and it doesn't segfault anymore, although I cannot build the application I was trying to build originally-- I'm getting a ton of undefined references to libc symbols, which doesn't happen when not using LTO (literally, removing -flto from the build leads to a success in linking). Does this mean something else is still broken? Does LTO require a match between arch/tune/cpu flags or something along those lines in order to link properly? Seemingly vanilla/no-lto doesn't need such a guarantee. I don't have a lot of time at the moment (end of academic year, lots of paper deadlines), but I can try to dig into this to see why it can't link with libc properly. Gabe Marcano
