GCC 11.1.0 ARM cross-compiler lto1 ICE segfault, trying to debug

Richard Earnshaw Richard.Earnshaw@foss.arm.com
Tue Jun 1 10:57:23 GMT 2021



On 27/05/2021 19:03, Gabriel Marcano via Gcc-help wrote:
>   >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.
> 

I don't have enough information from the above to even start to 
speculate what may be happening.  I would have thought that it's highly 
unlikely to be related to your original problem, but even that is 
speculation ;)

R.

> Gabe Marcano
> 


More information about the Gcc-help mailing list