diff options
author | Richard Sandiford <richard.sandiford@arm.com> | 2021-04-09 18:24:00 +0100 |
---|---|---|
committer | Richard Sandiford <richard.sandiford@arm.com> | 2021-04-09 18:24:00 +0100 |
commit | 1a5c82919c27a6af5eba0c2ba147dd011003cf72 (patch) | |
tree | 1ae4581cbab3184bbb507a13c41034927f47b940 /gcc/cp/lambda.c | |
parent | 00c3c31be43c018870569a599200a8af84956487 (diff) | |
download | gcc-1a5c82919c27a6af5eba0c2ba147dd011003cf72.zip gcc-1a5c82919c27a6af5eba0c2ba147dd011003cf72.tar.gz gcc-1a5c82919c27a6af5eba0c2ba147dd011003cf72.tar.bz2 |
aarch64: Fix push/pop_options with --with-cpu
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.
Diffstat (limited to 'gcc/cp/lambda.c')
0 files changed, 0 insertions, 0 deletions