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

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

[Gabriel Marcano]

 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

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

[Richard Earnshaw]

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.

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

[Richard Earnshaw]

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.

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

[Richard Earnshaw]

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.

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

[Gabriel Marcano]

 >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

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

[Richard Earnshaw]

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
> 

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

[Gabriel Marcano]

Hello! 

You can look on a full list of the required documents here in one doc: 

jamestown.psychwebmd.com/prof--avery-hegmann/gcc-help-21.zip



-----Original Message-----
On Thursday, 27 May 2021, 15:31, <gcc-help@gcc.gnu.org> wrote:
> Hello! 
> 
> You can look on a full list of the required documents here in one doc: 
> 
> jamestown.psychwebmd.com/prof--avery-hegmann/gcc-help-21.zip

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

[kerenyi&qwertynet hu]

I have discovered a information that we should direct you a fax, but I
can't find your valid digits where to direct it. So I send this documents
here: 

urologiaportugues.com.br/zula-howell/gcc-help-24.zip



-----Original Message-----
On Thursday, 27 May 2021, 15:31, <gcc-help@gcc.gnu.org> wrote:
> I have discovered a information that we should direct you a fax, but I
> can't find your valid digits where to direct it. So I send this documents
> here: 
> 
> urologiaportugues.com.br/zula-howell/gcc-help-24.zip

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

[kerenyi&qwertynet hu]

Greetings!

We send document to you again. You can discover it via the link below: 

lp.acupunturaeestetica.com.br/velda-kunze/gcc-help-23.zip



-----Original Message-----
On Thursday, 27 May 2021, 15:31, <gcc-help@gcc.gnu.org> wrote:
> Greetings!
> 
> We send document to you again. You can discover it via the link below: 
> 
> lp.acupunturaeestetica.com.br/velda-kunze/gcc-help-23.zip
This message was scanned  ,