Question on repeating -march flags
Martin Sebor
msebor@gmail.com
Fri Jan 1 23:43:00 GMT 2016
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
More information about the Gcc
mailing list