On Tue, Feb 12, 2019 at 4:43 PM Joseph Myers <jos...@codesourcery.com> wrote:
>
> 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).
>
Backend must have "Negative(march=) " to have negative Joined options.
It is not like it will happen automatically. What is wrong to have a negative
Joined option when a backend is specifically asking for it?
--
H.J.
