https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> --- (In reply to Franz Sirl from comment #3) > (In reply to Segher Boessenkool from comment #1) > > The -many is problematic, that is the whole point of this. As in this > > example: on different subtargets there are different machine code > > translations for the same mnemonic! > > But the way gas works there are never 2 active translations for the same > mnemonic, or? Of course. But it means that the meaning of the assembler code depends on the command line flags, unless a .machine statement is given (or equivalent command line flags). Since the compiler always depends on one particular meaning, this won't fly. > Actually, since -many is sticky and always (except when CHECKING_P?? or AIX) > part of ASM_CPU_SPEC, the ".machine ppc" doesn't really help since -many is > also active for the .machine pseudo-op. We want to get rid of -many if at all possible. This isn't possible currently mostly because of inline asm, but at least we can try too not depend on its (very problematic) effects. > Maybe you meant to also remove -many from ASM_CPU_SPEC? In that case we > would have seen at least an assembler error, since there is no dcread for > -mppc. Yeah, we would like to, but then people who *want* to use an insn not supported by the currently selected cpu have to adjust their inline asm code. It isn't clear to me where to warn for this (to nudge such users).
