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.
