https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #7 from Segher Boessenkool <segher at gcc dot gnu.org> ---
> GCC already passes -m<cpu> to the assembler though.
That mostly is historic.
> 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.
Not really, no. That is just one tiny part of the problem. It is impossible
to know what instruction sets we need ahead of time, and -many cannot work (and
*does not* work: there are quite a few mnemonics that encode to different insns
on different architecture versions (or for different CPUs), and we cannot know
which is wanted, or which is preferred, ahead of time.
> *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.
There is no working code that uses -many (accept by accident, if no problem
has hit you yet).
> 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.
It is the only correct thing to do.
