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
