https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #14 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(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).
> 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.
Yeah, we should fix that.
> 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.
