Re: Question on repeating -march flags

[Martin Sebor <msebor at gmail dot com>]

On 12/23/2015 05:02 AM, Yuri D'Elia wrote:
> I couldn't find anything on the matter, but what happens if -march is
> repeated more than once?  I would assume the usual behavior that the
> last flag "wins".

This is correct for all -march= arguments except for native.

Some -march= option processing takes place in the compiler driver
and some in the compiler itself.

For -march=native, unless the handling is overridden in the GCC
spec file, the i386 compiler driver determines the host CPU model
and substitutes its name and a set of other options for "native"
in the -march option passed to the compiler.  This can be seen
in the driver output by invoking it with -march=native -v.  For
example, on my machine, -march=native ends up replaced with
-march=sandybridge -mmmx -mno-3dnow -msse and a few dozen other
options.

All other -march= options are passed to the compiler unchanged.
The compiler then takes the last -march= option and ignores any
other -march= options that may have preceded it.

> On a haswell host, the following:
>
> gcc -march=native -march=opteron
>
> or
>
> gcc -march=opteron -march=native
> both emit code which is illegal for the opteron ISA, as if -march=native
> had special treatment. Specifying -march=opteron alone works as intended.

Because of the special handling, when -march=native and another,
more specific -march= option is specified, the latter option is
always appended to the cc1 command line by the driver.  This has
the effect of -march=opteron overriding the -march= option
substituted for -march=native by the driver regardless of which
comes first.  (See also bug 64534.)

> Since I generally override the default flags in makefiles by appending
> exceptions where needed, I'd sort of expected the regular behavior.
>
> Is this intended? If not, should I try to generate a small test case?

A test case with the -v output of the compiler and its version
is always helpful.  Based on your description it sounds to me
as though one of the other (non-march) options substituted for
-march=native by the driver is interfering with the subsequent
-march=opteron option.

In any event, I would be inclined to consider this a bug since
the details above aren't documented anywhere and are far from
intuitive.  At the very least, the special treatment of
-march=native should be documented.  Ideally, though, I would
expect the driver to avoid doing the substitution when the
-march=native is subsequently overridden on the command line.

Martin