https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #15 from Franz Sirl <sirl at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #14)
> (In reply to Franz Sirl from comment #12)
> > The emitted .machine is easy to fix, what's not so easy to fix is the
> > intention behind Segher's change that caused the wrong .machine.
> >
> > Consider this source compiled with -mcpu=7400:
> >
> > void ppcaltivecfunc (void) __attribute__ ((__target__
> > ("cpu=7400,altivec")));
> > void ppcaltivecfunc (void)
> > {
> > asm ("lvx 0,0,11");
> > }
> >
> >
> > void ppc403func (void) __attribute__ ((__target__ ("cpu=403")));
> > void ppc403func (void)
> > {
> > asm ("lvx 0,0,11");
> > }
>
> "7400" and "403" are not supported target attribute values, fwiw (says the
> manual).
Hmm, I don't understand what you mean. As I read the manual any -mcpu= option
is allowed? And certainly this seems to do something as you can see in the
assembler source. The only strange thing is that -mppc is passed to the
assembler for -mcpu=7400, but in the assembler source it selects ".machine
power7"?
> > That's why I suggested more control over the sticky flags via .machine
> > pseudo-ops, -mdotmachine-realcpu-resets-sticky or similar. That way the
> > users of pure assembly sources won't see a change in behaviour, but the
> > compiler still gains the full control it needs.
>
> We should just make this stuff work better / more intuitively :-) We do
> not need to preserve unworkable (or buggy) semantics, in general.
In that case I'll send a minimum patch for now.
