On Wed, 13 Feb 2019, Jakub Jelinek wrote:
> On Tue, Feb 12, 2019 at 11:21:04PM +0000, Joseph Myers wrote:
> > I think this is changing architecture-independent code in a way that is
> > not clearly safe based on the architecture-independent options design, in
> > order to address an architecture-specific problem. The exclusion of
>
> Actually, I think it is a problem common to many backends, in particular
> those where *_host_detect_local_cpu emits for -m*=native sometimes more than
> one option, so at least i386, s390, rs6000, maybe also those that emit just
> one option because it likely ends up at a different spot on the command line
> from where -m{arch,cpu,tune}=native was originally present (that would be
> aarch64, alpha, arm, mips and sparc). I guess the user expectations is that
> -march=native -march=foobar will be handled as
> -march=foobar, rather than -march=native -march=foobar -march=my_great_cpu
> -mfoo -mbar
It seems right in the march= case to handle that combination as
-march=foobar - but it's less clear if that must always be the case for
Joined options with negative versions (at least, the semantics would need
defining more carefully in options.texi, with an analysis of existing
affected options).
--
Joseph S. Myers
jos...@codesourcery.com
