https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #12 from Franz Sirl <sirl at gcc dot gnu.org> ---
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");
}
Even though the compiler emitted a .machine "403" (or currently the buggy
"ppc"), the assembler won't barf on "lvx 0,0,11" in ppc403func(), because of
the sticky altivec flag.
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.
And I hope the suggested warning options to help the users of existing sources
with multi-cpu inline asm, since they maybe affected when the compiler switches
the assembler to a different mode by default.
