powerpc: Fix unrecognized instruction errors with recent GCC

Message ID 20210914181958.749314-1-pc@us.ibm.com
State Committed
Commit 064b475a2e5662b6b3973fabf505eade86e61510
Delegated to: Tulio Magno Quites Machado Filho
Headers
Series powerpc: Fix unrecognized instruction errors with recent GCC |

Checks

Context Check Description
dj/TryBot-apply_patch success Patch applied to master at the time it was sent
dj/TryBot-32bit success Build for i686

Commit Message

Paul A. Clarke Sept. 14, 2021, 6:19 p.m. UTC
  Recent versions of GCC stopped passing "-many" to the assembler,
so some instructions which were under older, more stringent
"machine" directives no longer compile with unrecognized instructions
in that context.

In tst-ucontext-ppc64-vscr.c, while the instructions provoking the new
error messages are bracketed by ".machine power5", which is ostensibly
Power ISA 2.03 (POWER5), the POWER5 processor did not support the
VSX subset, so these instructions are not recognized as "power5".

Error: unrecognized opcode: `vspltisb'
Error: unrecognized opcode: `vpkuwus'
Error: unrecognized opcode: `mfvscr'
Error: unrecognized opcode: `stvx'

Manually adding the VSX subset via ".machine altivec" is sufficient.
---
 sysdeps/powerpc/powerpc64/tst-ucontext-ppc64-vscr.c | 1 +
 1 file changed, 1 insertion(+)
  

Comments

Tulio Magno Quites Machado Filho Sept. 20, 2021, 12:56 p.m. UTC | #1
"Paul A. Clarke via Libc-alpha" <libc-alpha@sourceware.org> writes:

> Recent versions of GCC stopped passing "-many" to the assembler,
> so some instructions which were under older, more stringent
> "machine" directives no longer compile with unrecognized instructions
> in that context.

I think the most recent change causing this is binutils commit:
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a

It's worth mentioning it in the commit message too.

LGTM with this inclusion in the commit message.

Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
  
Joseph Myers Sept. 22, 2021, 11:48 a.m. UTC | #2
Even with this commit included, I'm still seeing such errors with 
build-many-glibcs.py for powerpc-linux-gnu, powerpc-linux-gnu-power4, 
powerpc-linux-gnu-soft and powerpc64-linux-gnu, which I expect have the 
same underlying cause.

https://sourceware.org/pipermail/libc-testresults/2021q3/008589.html

These are all errors building tst-set_ppr:

/tmp/ccyn2EoO.s: Assembler messages:
/tmp/ccyn2EoO.s:73: Error: unrecognized opcode: `mfppr32'
/tmp/ccyn2EoO.s:130: Error: unrecognized opcode: `mfppr32'
/tmp/ccyn2EoO.s:197: Error: unrecognized opcode: `mfppr32'
/tmp/ccyn2EoO.s:288: Error: unrecognized opcode: `mfppr32'
/tmp/ccyn2EoO.s:340: Error: unrecognized opcode: `mfppr32'
/tmp/ccyn2EoO.s:420: Error: unrecognized opcode: `mfppr32'
/scratch/jmyers/glibc-bot/build/glibcs/powerpc-linux-gnu/glibc/sysd-rules:723: recipe for target '/scratch/jmyers/glibc-bot/build/glibcs/powerpc-linux-gnu/glibc/misc/tst-set_ppr.o' failed
  
Paul A. Clarke Sept. 25, 2021, 3:09 p.m. UTC | #3
On Wed, Sep 22, 2021 at 11:48:32AM +0000, Joseph Myers wrote:
> Even with this commit included, I'm still seeing such errors with 
> build-many-glibcs.py for powerpc-linux-gnu, powerpc-linux-gnu-power4, 
> powerpc-linux-gnu-soft and powerpc64-linux-gnu, which I expect have the 
> same underlying cause.
> 
> https://sourceware.org/pipermail/libc-testresults/2021q3/008589.html
> 
> These are all errors building tst-set_ppr:
> 
> /tmp/ccyn2EoO.s: Assembler messages:
> /tmp/ccyn2EoO.s:73: Error: unrecognized opcode: `mfppr32'
> /tmp/ccyn2EoO.s:130: Error: unrecognized opcode: `mfppr32'
> /tmp/ccyn2EoO.s:197: Error: unrecognized opcode: `mfppr32'
> /tmp/ccyn2EoO.s:288: Error: unrecognized opcode: `mfppr32'
> /tmp/ccyn2EoO.s:340: Error: unrecognized opcode: `mfppr32'
> /tmp/ccyn2EoO.s:420: Error: unrecognized opcode: `mfppr32'
> /scratch/jmyers/glibc-bot/build/glibcs/powerpc-linux-gnu/glibc/sysd-rules:723: recipe for target '/scratch/jmyers/glibc-bot/build/glibcs/powerpc-linux-gnu/glibc/misc/tst-set_ppr.o' failed

Thanks for the report, Joseph!

This manifests only with a very recent version of binutils (not even the
current release, 2.37).  It is likely provoked by commit
b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a "PowerPC: ignore sticky options
for .machine".  (I think there is a fair amount of fallout from that
change.)

Interestingly, there was a change (9250e6610fdb0f3a6f238d2813e319a41fb7a810
"powerpc: Fix build failures with current GCC") back in 2019 to that test's
Makefile to add `-many` to the compile options for exactly this problem
when `-many` stopped being passed by GCC to the assembler.  Now, even
passing `-many` on the command line doesn't work.

I'll post a fix to include the required `.machine` directives for that test
shortly.

PC
  

Patch

diff --git a/sysdeps/powerpc/powerpc64/tst-ucontext-ppc64-vscr.c b/sysdeps/powerpc/powerpc64/tst-ucontext-ppc64-vscr.c
index 28c87fcef72b..d3fc4ab589f4 100644
--- a/sysdeps/powerpc/powerpc64/tst-ucontext-ppc64-vscr.c
+++ b/sysdeps/powerpc/powerpc64/tst-ucontext-ppc64-vscr.c
@@ -50,6 +50,7 @@  do_test (void)
   /* Set SAT bit in VSCR register.  */
   asm volatile (".machine push;\n"
 		".machine \"power5\";\n"
+		".machine altivec;\n"
 		"vspltisb %0,0;\n"
 		"vspltisb %1,-1;\n"
 		"vpkuwus %0,%0,%1;\n"