[Bug target/113652] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450

2024-01-29 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652

--- Comment #11 from Kewen Lin  ---
In gcc, lfiwzx is guarded with TARGET_LFIWZX => TARGET_POPCNTD (ISA2.06), while
-mvsx will guarantee TARGET_POPCNTD (ISA_2_6_MASKS_SERVER) set, so it considers
lfiwzx is supported. IMHO the underlying philosophy is that having the
capability of vsx the supported ISA level is at least 2.06, lfiwzx is supported
from 2.06, so it's supported.

But binutils seems not to follow it:
{"xvadddp", XX3(60,96), XX3_MASK,PPCVSX,PPCVLE, {XT6,
XA6, XB6}},
{"lfiwzx",  X(31,887),  X_MASK,   POWER7|PPCA2, 0,  {FRT,
RA0, RB}},
Both are guarded with different masks and apparently PPCVSX doesn't enable
POWER7.

Hi Alan and Peter,

I wonder if assembler can enable POWER7 when PPCVSX gets enabled like what gcc
adopts now?

[Bug target/113652] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450

2024-01-29 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652

--- Comment #10 from Sam James  ---
(In reality, I think it is a regression, given:
a) it regresses non-release checking (which we sometimes use even for released
versions, it's opt-in though);
b) it blocks further testing with GCC 14

but I understand the argument that if a release were made with it, it wouldn't
be the end of the world by itself and it only affects a specific
configuration.)

[Bug target/113652] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450

2024-01-29 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652

Kewen Lin  changed:

   What|Removed |Added

Summary|[14 regression] Failed  |Failed bootstrap on ppc
   |bootstrap on ppc|unrecognized opcode:
   |unrecognized opcode:|`lfiwzx' with -mcpu=7450
   |`lfiwzx' with -mcpu=7450|

--- Comment #9 from Kewen Lin  ---
(In reply to Andrew Pinski from comment #8)
> So t-float128 has this line:
> # Build the emulator without ISA 3.0 hardware support.
> FP128_CFLAGS_SW  = -Wno-type-limits -mvsx -mfloat128 \
> ...
> 
> Which gets added to some of the libgcc object files while compiling:
> $(fp128_softfp_obj)  : INTERNAL_CFLAGS += $(FP128_CFLAGS_SW)
> $(fp128_ppc_obj) : INTERNAL_CFLAGS += $(FP128_CFLAGS_SW)
> 
> 
> The problem is CFLAGS gets added also. It seems like passing -mvsx enables
> some other instructions in GCC's code generation BUT does not enable it for
> the assembler ...

ah, just noticed that it's bootstrapping gcc. Stripping regression tag since I
don't think it's actually a regression as comments above.

I found that the libgcc_cv_powerpc_float128 checking can pass with -mcpu=7450
-mabi=altivec -mvsx -mfloat128, the assembler options are "-a32 -mppc -mvsx
-maltivec -mbig" is actually the same as what are used for the case #c5
compiling. So it looks that -mvsx is supposed to tell assembler to recognize
vsx instructions but somehow "lfiwzx" is not counted as vsx instruction.

More specifically "xvadddp" is recognized by assembler with -mvsx while
"lfiwzx" isn't.

$ cat t1.s
.machine "7450"
lfiwzx 1,0,9

$ cat t2.s
.machine "7450"
xvadddp 34,34,35

$ as -a32 -mppc -mvsx t1.s -o t1.o
t1.s: Assembler messages:
t1.s:2: Error: unrecognized opcode: `lfiwzx'
$ as -a32 -mppc -mvsx t2.s -o t2.o
$ echo $?
$ 0