https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #13 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Alan Modra from comment #11)
> Given the number of ppc micros around with differing functional units, it is
> quite reasonable that we have assembly options to say "this base cpu" plus
> "this extra functionality".
Certainly.
> Whether you think it was wise to allow those
> "extra functionality" options to be specified before the "base cpu" option
> is another matter, but it has been that way for a long time.
We do the same in GCC, it works fine. But that works because it is treated
independently of -mcpu= (our analogue of .machine). Such options are evaluated
separately, always override what -mcpu= says.
> I'm not
> inclined to change that since it would very likely break some projects, and
> I happen to think that it is entirely reasonable to expect that "-maltivec
> -mppc64" for example is the same as "-mppc64 -maltivec".
Very much so :-)
> In any case sticky options are a side issue here. The real issue is that
> emitted .machine is wrong.
See my comment 2, so we agree. I'll work on it.
> Note that I'm not vetoing assembler changes. It
> might be a good idea to reset all sticky options on processing any .machine
> directive for example, and I'm happy with the idea of -mno-vsx etc. options
> for the assembler.
Yeah, I don't see how it can work with push and pop and stuff this way.
Ideally that would work just as if you had the options it pushes and pops
on the command line, at every stage -- and AFAICS that means you have to
track these options separately.
