PowerPC: ignore sticky options for .machine

[Segher Boessenkool]

Hi!

On Fri, Jul 23, 2021 at 08:53:31PM +0930, Alan Modra wrote:
> PowerPC gas and objdump for a long time have allowed certain -m/-M
> options that extend a base cpu with extra functional units to be
> specified before the base cpu.  For example, "-maltivec -mpower4" is
> the same as "-mpower4 -maltivec".  See
> https://sourceware.org/pipermail/binutils/2008-January/054935.html
> 
> It doesn't make as much sense that .machine keep any of these
> "sticky" flags when handling a new base cpu.  See gcc PR101393.  I
> think that instead .machine ought to override the command line.
> That's what this patch does.  It is still possible to extend cpu
> functionality with .machine.  For example the following can be
> assembled when selecting a basic -mppc on the command line:
> 	.machine power5
> 	.machine altivec
> 	frin 1,2
> 	lvsr 3,4,5
> Here, ".machine altivec" extends the ".machine power5" so that both
> the power5 "frin" instruction and the altivec "lvsr" instruction are
> enabled.  Swapping the two ".machine" directives would result in
> failure to assemble "lvsr".

Yeah, that makes sense.

> The change will expose some assembly errors, such as the one in
> glibc/sysdeps/powerpc/powerpc64/tst-ucontext-ppc64-vscr.c, a file
> compiled with -maltivec but containing
>   asm volatile (".machine push;\n"
> 		".machine \"power5\";\n"
> 		"vspltisb %0,0;\n"
> 		"vspltisb %1,-1;\n"
> 		"vpkuwus %0,%0,%1;\n"
> 		"mfvscr %0;\n"
> 		"stvx %0,0,%2;\n"
> 		".machine pop;"
> 		: "=v" (v0), "=v" (v1)
> 		: "r" (vscr_ptr)
> 		: "memory");
> It's just wrong to choose power5 for a bunch of altivec instructions
> and in fact all of those .machine directives are unnecessary.

As are the (quoted) quotes around "power5", heh :-)

Can you think about any situation where the user *wants* to keep sticky
options?  And, if so, can the user write anything that will work as
wanted both on old and new binutils?

You tested this with glibc it seems?  Did you also test building Linux?

In either case, thank you for this!


Segher