[Bug target/102485] -Wa,-many no longer has any effect

["amodra at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485

--- Comment #10 from Alan Modra <amodra at gmail dot com> ---
I have spent some time over the last few days digging into history relevant to
this bug as part of looking into a binutils report that an ARCH=powerpc
CROSS_COMPILE=powerpc-linux- pmac32_defconfig linux kernel no longer builds
with binutils-2.38.

As a result I've partly reverted the effect of binutils commit "ignore sticky
options for .machine", on both mainline binutils and the 2.38 branch.  Given
the way gcc operates, that commit was a mistake on my part.  The  initial
.machine passed by gcc will again keep -many, -maltivec, -mvsx, -mvle, -mspe or
-mspe2 in effect.  A .machine later in an assembly file, after some output to
any section (even .align counts), will be more strictly enforced.

That's the best I can do to solve this mess.  It does not completely fix this
bug, which I believe is a valid complaint.  For instance a user who has power10
asm() but does not want gcc generated power10 code, perhaps due to a gcc code
gen bug, might like to use -mcpu=power9 -Wa,-mpower10 on the gcc command line. 
Instead they would be forced to write ".machine power10" in their asm. 
(Ideally, .machine push; .machine power10; user asm; .machine pop, on each use
of power10 instructions.)  At least, that is the case for current mainline gcc
and binutils-2.38 where even "-mcpu=power9 -Wa,-many" won't work.  We simply
cannot dictate to users that their assembly needs rewriting.

A lot of this came about by accident.  On the gas side, it was by accident that
any of the gas command line cpu options were sticky for .machine.  The intent
behind the sticky options was to support people writing gas command lines like
"-maltivec -mppc" as well as the canonical "-mppc -maltivec".  When you
consider that gas also needs to support multiple cpu options on a command line,
with the last overriding any previous selection, it is more obvious why options
that add functional units like -maltivec are special.

On the gcc side, we have pr59828 and commit b9f12a01bedb5 which is where gcc
started to emit .machine rather than passing correct arguments to gas.  Current
mainline gcc continues to pass the wrong cpu to gas on the command line when
multiple -mcpu options are given to gcc, as can be seen by examining -v output
from the kernel compile mentioned above.  There have been multiple gcc bug
reports about that .machine directive, pr71216, pr91050, pr101393 to point out
some.  This means there are versions of gcc in widespread use that pass an
incorrect .machine to gas, which is why I say my gas change to make .machine
more strict was a mistake.  We can't expect the kernel and other users of the
toolchain to cope with gas using wrong cpu info if -many is disabled by
.machine.  Of course, the bugs in .machine might have been found earlier if
-many hadn't been covering them.  Similarly for bugs in the linux kernel
makefiles; mfsrin and mtsrin are not ppc64 instructions.

Overall, I think using .machine as a workaround for pr59828 was a mistake,
especially since digging into this bug reminded me that I'd submitted a
conceptually simple patch to fix pr59828 by passing on all the cpu args to gas.
 Which went unreviewed for a whole year before being dismissed.