On Fri, Sep 11, 2020 at 09:46:37AM +0200, Christophe Lyon via Gcc-patches wrote:
> I'm seeing an ICE with this new test on most of my arm configurations,
> for instance:
> --target arm-none-linux-gnueabi --with-cpu cortex-a9
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-linux-gnueabi/gcc3/gcc/xgcc
> -B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-ar
> m-none-linux-gnueabi/gcc3/gcc/ c_lto_pr96939_0.o c_lto_pr96939_1.o
> -fdiagnostics-plain-output -flto -O2 -o
> gcc-target-arm-lto-pr96939-01.exe

Seems a latent issue.
Neither cl_optimization_{save,restore} nor cl_target_option_{save,restore}
(nor any of the target hooks they call) saves or restores any opts_set
values, so I think opts_set can be trusted only during option processing (if
at all), but not later.
So, short term a fix would be IMHO just stop using opts_set altogether in
arm_configure_build_target, it doesn't make much sense to me, it should test
if those strings are non-NULL instead, or at least do that when it is
invoked from arm_option_restore (e.g. could be done by calling it with
opts instead of &global_options_set ).
Longer term, the question is if cl_optimization_{save,restore} and
cl_target_option_{save,restore} shouldn't be changed not to only
save/restore the options, but also save the opts_set flags.
It could be done e.g. by adding a bool array or set of bool members
to struct cl_optimization and struct cl_target_option , or even more compact
by using bitmasks, pack each 64 adjacent option flags into a UHWI element
of an array.

> In function 'crc':
> lto1: internal compiler error: Segmentation fault
> 0xba720f crash_signal
>         /gcc/toplev.c:327
> 0x172beb9 strchr
>         /usr/include/string.h:227
> 0x172beb9 arm_parse_cpu_option_name(cpu_option const*, char const*,
> char const*, bool)
>         /gcc/common/config/arm/arm-common.c:349
> 0xfa9372 arm_configure_build_target(arm_build_target*,
> cl_target_option*, gcc_options*, bool)
>         /gcc/config/arm/arm.c:3209
> 0xfbf8e1 arm_set_current_function
>         /gcc/config/arm/arm.c:32334
> 0x86b68b invoke_set_current_function_hook
>         /gcc/function.c:4670
> 0x870d77 invoke_set_current_function_hook
>         /gcc/function.c:4836
> 0x870d77 allocate_struct_function(tree_node*, bool)
>         /gcc/function.c:4793
> 0xa25943 input_function
>         /gcc/lto-streamer-in.c:1385
> 0xa25943 lto_read_body_or_constructor
>         /gcc/lto-streamer-in.c:1624
> 0x6f37ff cgraph_node::get_untransformed_body()
>         /gcc/cgraph.c:3932
> 0x703f42 cgraph_node::expand()
>         /gcc/cgraphunit.c:2274
> 0x70567c expand_all_functions
>         /gcc/cgraphunit.c:2476
> 0x70567c symbol_table::compile()
>         /gcc/cgraphunit.c:2839
> 0x63970b lto_main()
>         /gcc/lto/lto.c:653
> 
> This is with a cross-compiler.

        Jakub

Reply via email to