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.
