If a toolchain is configured with --with-cpu=X and gcc is
then run with an explicit -march=Y option, we ignore the
X cpu setting and tune for generic Y code:
if (!selected_cpu)
{
if (selected_arch)
{
------> selected_cpu = &all_cores[selected_arch->ident];
aarch64_isa_flags = arch_isa;
explicit_arch = selected_arch->arch;
}
else
{
/* Get default configure-time CPU. */
selected_cpu = aarch64_get_tune_cpu (aarch64_none);
aarch64_isa_flags = TARGET_CPU_DEFAULT >> 6;
}
if (selected_tune)
explicit_tune_core = selected_tune->ident;
}
…
if (!selected_tune)
selected_tune = selected_cpu;
But after a push/pop_options pair, we simply did:
selected_tune = aarch64_get_tune_cpu (ptr->x_explicit_tune_core);
In the above scenario, ptr->x_explicit_tune_core is aarch64_none,
so we fall back on the default configure-time CPU. This means
that before the push_options we tuned for generic Y but after
the pop_options we tuned for X.
This was picked up by an assertion failure in cl_optimization_compare.
The ICE itself is a GCC 11 regression, but the problem that it shows
up is much older.
gcc/
* config/aarch64/aarch64.c (aarch64_option_restore): If the
architecture was specified explicitly and the tuning wasn't,
tune for the architecture rather than the configured default CPU.
struct gcc_options */* opts_set */,
struct cl_target_option *ptr)
{
- opts->x_explicit_tune_core = ptr->x_explicit_tune_core;
- selected_tune = aarch64_get_tune_cpu (ptr->x_explicit_tune_core);
opts->x_explicit_arch = ptr->x_explicit_arch;
selected_arch = aarch64_get_arch (ptr->x_explicit_arch);
+ opts->x_explicit_tune_core = ptr->x_explicit_tune_core;
+ if (opts->x_explicit_tune_core == aarch64_none
+ && opts->x_explicit_arch != aarch64_no_arch)
+ selected_tune = &all_cores[selected_arch->ident];
+ else
+ selected_tune = aarch64_get_tune_cpu (ptr->x_explicit_tune_core);
opts->x_aarch64_override_tune_string = ptr->x_aarch64_override_tune_string;
opts->x_aarch64_branch_protection_string
= ptr->x_aarch64_branch_protection_string;