On Mon, 12 Jun 2017, Richard Earnshaw (lists) wrote:

> It does.  The problem seems to be a generic one in the driver in that
> the rewrite rules are always passed the first instance of -march and not
> the last.  Indeed, with the aarch64 compiler, if I write
> 
> gcc -mcpu=native -mcpu=cortex-a53
> 
> then the driver will rewrite this as
> 
> ./cc1 -mcpu=cortex-a53 -mcpu=<expansion of native cpu name>
> 
> which doesn't seem to be the right thing at all.
> 
> So we either have a generic problem with all option rewriting, or there
> are some subtle details of it that we've not figured out yet.
> 
> Joseph, is there a way to get the rewrite rules to receive the *last*
> instance of a flag rather than the first?  Or is the current behaviour
> simply wrong?

I think there are at least two separate issues here.

In the AArch64 port (and other ports), the specs for -mcpu=native use 
%{mcpu=native:%<mcpu=native %:local_cpu_detect(cpu)} as part of 
DRIVER_SELF_SPECS.  Options added by DRIVER_SELF_SPECS are added at the 
end of the command line (after OPTION_DEFAULT_SPECS has been processed).  
Thus, if there is any -mcpu=native option, the options from generated by 
local_cpu_detect will be added.

In patch 14 of this series, you have specs of the form %{mcpu=*: cpu %*} 
inside a canon_arch call.  According to the comment in gcc.c documenting 
specs

 %{S*:X}  substitutes X if one or more switches whose names start
          with -S was given to GCC.  Normally X is substituted only
          once, no matter how many such switches appeared.  However,
          if %* appears somewhere in X, then X will be substituted
          once for each matching switch, with the %* replaced by the
          part of that switch that matched the '*'.  A space will be
          appended after the last substition unless there is more
          text in current sequence.

this ought to mean that every -mcpu= option results in a corresponding cpu 
<something> in the arguments to canon_arch (in the same order as the 
original options).  If it doesn't, that sounds like a bug in the %* 
handling.

Overridden options can be removed before specs processing if a cycle of 
options is marked with Negative in the .opt files (see prune_options), but 
that doesn't apply to options with arguments.  If you had a system for 
pruning e.g. all but the last -mcpu= option (for options where it's just 
the last argument that matters), you'd also want to make sure that prior 
options do still generate errors if the option argument is invalid.

-- 
Joseph S. Myers
jos...@codesourcery.com

Reply via email to