[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #12 from Jakub Jelinek  ---
--- gcc/config/rs6000/rs6000.cc.jj  2023-04-04 10:33:47.433201866 +0200
+++ gcc/config/rs6000/rs6000.cc 2023-04-24 12:31:07.237031550 +0200
@@ -11409,7 +11409,16 @@ bool
 rs6000_is_valid_rotate_dot_mask (rtx mask, machine_mode mode)
 {
   int nb, ne;
-  return rs6000_is_valid_mask (mask, , , mode) && nb >= ne && ne > 0;
+  if (rs6000_is_valid_mask (mask, , , mode) && nb >= ne && ne > 0)
+{
+  if (TARGET_64BIT)
+   return true;
+  /* *rotldi3_mask_dot requires for -m32 -mpowerpc64 that the mask is
+<= 0x7ff.  */
+  return (UINTVAL (mask) << (63 - nb)) <= 0x7fff;
+}
+  else
+return false;
 }

 /* Return whether MASK (a CONST_INT) is a valid mask for any rlwinm, rldicl,
seems to fix this.

[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #11 from Jakub Jelinek  ---
I bet the culprit is that *rotl3_mask_dot has
(mode == Pmode || UINTVAL (operands[3]) <= 0x7fff)
in condition.  So, because *branch_anddi3_dot always wants DImode, if Pmode is
SImode,
it should make sure (UINTVAL (operands[2]) << (63 - nb)) <= 0x7fff.

[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #10 from Jakub Jelinek  ---
Ah, but that actually isn't the problem, rather just useless clutter.
The problem is that
(jump_insn 10 7 32 2 (parallel [
(set (pc)
(if_then_else (eq (and:DI (reg:DI 9 9 [121])
(const_int 2146435072 [0x7ff0]))
(const_int 0 [0]))
(label_ref:SI 40)
(pc)))
(clobber (reg:DI 9 9 [125]))
(clobber (reg:CC 100 0))
]) "pr109566-3.c":6:6 229 {*branch_anddi3_dot}
 (int_list:REG_BR_PROB 708669604 (nil))
 -> 40)
is split into:
(insn 43 7 44 2 (parallel [
(set (reg:CC 100 0)
(compare:CC (and:DI (ashift:DI (reg:DI 9 9 [121])
(const_int 33 [0x21]))
(const_int -9007199254740992 [0xffe0]))
(const_int 0 [0])))
(clobber (reg:DI 9 9 [125]))
]) "pr109566-3.c":6:6 -1
 (nil))
(jump_insn 44 43 32 2 (set (pc)
(if_then_else (eq:CCEQ (reg:CC 100 0)
(const_int 0 [0]))
(label_ref 40)
(pc))) "pr109566-3.c":6:6 -1
 (int_list:REG_BR_PROB 708669604 (nil))
 -> 40)
and the first instruction isn't recognized.

[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2023-04-24
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||yinyuefengyi at gmail dot com

--- Comment #9 from Jakub Jelinek  ---
Ah, it ICEs on powerpc64-linux too, with -m32 -O2 -mpowerpc64 -mcpu=power3 (or
10 etc.),
-mpowerpc64 is what matters.
In *.postreload we have
(jump_insn 10 7 32 2 (parallel [
(set (pc)
(if_then_else (eq (and:DI (reg:DI 9 9 [121])
(const_int 2146435072 [0x7ff0]))
(const_int 0 [0]))
(label_ref:SI 40)
(pc)))
(clobber (reg:DI 9 9 [125]))
(clobber (reg:CC 100 0))
]) "pr109566-3.c":6:6 229 {*branch_anddi3_dot}
 (int_list:REG_BR_PROB 708669604 (nil))
The define_insn_and_split has been introduced already in GCC 12 in PR102239
r12-6433
and I'd say it is just wrong, the FAIL part doesn't belong there, that is an
ICE if for a define_insn_and_split with "#" the splitter part FAILs.
The condition on the instruction or predicates/constraints should make sure it
is splittable.

[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #8 from Jakub Jelinek  ---
Ah, --target powerpc-rtems6 reproduces it, wonder what is different here.
Reduced testcase:
void
foo (double x)
{
  union { double d; unsigned i; } u;
  u.d = x;
  if (u.i & 2146435072)
return;
  else
for (;;)
  ;
}

[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread sebastian.huber--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #7 from Sebastian Huber  ---
(In reply to Jakub Jelinek from comment #6)
> How have you configured gcc?  I certainly can't reproduce this with
> --enable-targets=powerpc64-linux,powerpc-linux --with-cpu-32=power7
> --with-cpu-64=power7 --with-long-double-128 --enable-checking=release
> --target=powerpc64-linux-gnu --enable-languages=c,c++,fortran,lto
> nor
> --target powerpc-linux --enable-languages=c,c++
> configured gccs.

I notices this issue with the powerpc-rtems6 target while building Newlib. Can
you compile the test case with your compiler?

I was able to reproduce the error with the powerpc-elf target:

powerpc-elf-gcc -O2  -mcpu=power10 -c test.c
/home/EB/sebastian_h/tmp/bug-gcc-pr109566/test.c: In function '__ieee754_fmod':
/home/EB/sebastian_h/tmp/bug-gcc-pr109566/test.c:32:1: error: unrecognizable
insn:
   32 | }
  | ^
(insn 49 8 50 2 (parallel [
(set (reg:CC 100 0)
(compare:CC (and:DI (ashift:DI (reg:DI 9 9 [123])
(const_int 33 [0x21]))
(const_int -9007199254740992 [0xffe0]))
(const_int 0 [0])))
(clobber (reg:DI 9 9 [127]))
]) "/home/EB/sebastian_h/tmp/bug-gcc-pr109566/test.c":21:4 -1
 (nil))
during RTL pass: split2
/home/EB/sebastian_h/tmp/bug-gcc-pr109566/test.c:32:1: internal compiler error:
in extract_insn, at recog.cc:2791
0x40730a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/EB/sebastian_h/src/gcc/gcc/rtl-error.cc:108
0x407329 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/EB/sebastian_h/src/gcc/gcc/rtl-error.cc:116
0x957257 extract_insn(rtx_insn*)
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:2791
0x9572b1 extract_insn_cached(rtx_insn*)
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:2680
0x6a99ab cleanup_subreg_operands(rtx_insn*)
/home/EB/sebastian_h/src/gcc/gcc/final.cc:3054
0x95561c split_insn
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:3420
0x95a392 split_all_insns()
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:3488
0x95a4a8 execute
/home/EB/sebastian_h/src/gcc/gcc/recog.cc:4412
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
How have you configured gcc?  I certainly can't reproduce this with
--enable-targets=powerpc64-linux,powerpc-linux --with-cpu-32=power7
--with-cpu-64=power7 --with-long-double-128 --enable-checking=release
--target=powerpc64-linux-gnu --enable-languages=c,c++,fortran,lto
nor
--target powerpc-linux --enable-languages=c,c++
configured gccs.

[Bug target/109566] [13/14 Regression] powerpc: unrecognizable insn for -mcpu=e6500, -mcpu=power3, ..., -mcpu=power10

2023-04-24 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 CC||segher at gcc dot gnu.org
Summary|powerpc: unrecognizable |[13/14 Regression] powerpc:
   |insn for -mcpu=e6500,   |unrecognizable insn for
   |-mcpu=power3, ...,  |-mcpu=e6500, -mcpu=power3,
   |-mcpu=power10   |..., -mcpu=power10
   Keywords||build, ice-on-valid-code

--- Comment #5 from Richard Biener  ---
It does look like an error in the splitter, I suspect the constant isn't
legitimate?