aboutsummaryrefslogtreecommitdiff
path: root/gcc/cp/lambda.c
diff options
context:
space:
mode:
authorRichard Sandiford <richard.sandiford@arm.com>2021-04-09 18:24:00 +0100
committerRichard Sandiford <richard.sandiford@arm.com>2021-04-09 18:24:00 +0100
commit1a5c82919c27a6af5eba0c2ba147dd011003cf72 (patch)
tree1ae4581cbab3184bbb507a13c41034927f47b940 /gcc/cp/lambda.c
parent00c3c31be43c018870569a599200a8af84956487 (diff)
downloadgcc-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