https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87076
--- Comment #4 from Vladislav Ivanishin <vlad at ispras dot ru> ---
"rguenth at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> writes:
> On x86_64 the actual -march switch isn't serialized but it is decomposed into
> individual -mFEATURE switches by the driver which are serialized.
>
>
> The -march switch also appears in the lto_opts LTO section and should be
> handed off to the linker by lto-wrapper as well.
>
> You can check that by looking at -v output of the link command and/or
> looking at the lto_opts section in the object files.
Indeed, the -march switch makes it into .gnu.lto_.opts. However, when
lto-wrapper constructs the argument string in run_gcc(), it takes those
options (append_compiler_options()) and then appends the contents of
COLLECT_GCC_OPTIONS (append_linker_options()) to them.
COLLECT_GCC_OPTIONS is set by the topmost gcc driver to
... -mcpu=arm7tdmi -marm -march=armv4t
(these options come from evaluation of the DRIVER_SELF_SPECS spec
string).
So the LTO compiler is then invoked with something like
... -march=armv7-r ... -mcpu=arm7tdmi -marm -march=armv4t
The last -march takes effect. The ARM backend seems to infer -mFEATUREs
from -mcpu and -march rather than trying to deserialize from the file.
I drew this conclusion from looking at
gcc/config/arm/arm.c: arm_configure_build_target():
...
if (arm_selected_arch)
{
arm_initialize_isa (target->isa, arm_selected_arch->common.isa_bits);
...
if (arm_selected_cpu)
{
arm_initialize_isa (cpu_isa, arm_selected_cpu->common.isa_bits);
