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.