https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485
Nicholas Piggin <npiggin at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |npiggin at gmail dot com
--- Comment #6 from Nicholas Piggin <npiggin at gmail dot com> ---
(In reply to Peter Bergner from comment #1)
> I agree it is GCC's job to emit a ".machine CPU" directive that allows the
> assembler to correctly assemble the code GCC generates.
GCC already passes -m<cpu> to the assembler though.
The justification for emitting the .machine directive is given as fixing a
build breakage due to a build system that passes an incorrect -m<cpu> to the
assembler.
*That* is the broken code (if any) that should have been fixed. But instead
that is hacked around in a way that breaks working code that passes down
-Wa,-many option as specified.
> Your test case
> however uses inline asm and GCC does not know that you are using the mfppr32
> mnemonic. The assembler code you write in an inline asm is basically a
> black box to the compiler. It is therefor up to the programmer to ensure
> that either the -mcpu=CPU GCC option that is being used (which
> emits".machine CPU" directive) is enough to assemble the mnemonics in the
> inline asm or you have to emit them in your inline asm.
The kernel builds with a base compatibility (say -mcpu=power4) and then has
certain code paths that are dynamically taken if running on newer CPUs which
use newer instructions with inline asm.
This is an important usage and it's pervasive, it seems unreasonable to break
it. Adding .machine directives throughout inline asm for every instruction not
in the base compatibility class is pretty horrible.
