[Bug target/109566] New: powerpc: unrecognizable insn for -mcpu=e6500

[Bug target/109566] New: powerpc: unrecognizable insn for -mcpu=e6500

[sebastian.huber@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

            Bug ID: 109566
           Summary: powerpc: unrecognizable insn for -mcpu=e6500
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sebastian.huber@embedded-brains.de
  Target Milestone: ---

Consider the following test case:

typedef int __int32_t;
typedef unsigned int __uint32_t;
typedef union
{
  double value;
  struct
  {
    __uint32_t msw;
    __uint32_t lsw;
  } parts;
} ieee_double_shape_type;
 double __ieee754_fmod(double x, double y)
{
 __int32_t n,hx,hy,hz,ix,iy,sx,i;
 __uint32_t lx,ly,lz;
 do { ieee_double_shape_type ew_u; ew_u.value = (x); (hx) = ew_u.parts.msw;
(lx) = ew_u.parts.lsw; } while (0);
 sx = hx&0x80000000;
 hx ^=sx;
 if(hx<=hy) {
 }
 if(hx<0x00100000) {
     if(hx==0) {
  for (ix = -1043, i=lx; i>0; i<<=1) ix -=1;
     }
 } else ix = (hx>>20)-1023;
 if(ix >= -1022)
     hx = 0x00100000|(0x000fffff&hx);
 while(hx<0x00100000) {
     if(n<=20) {
     }
 }
}

This yields:

powerpc-rtems6-gcc -O2  -mcpu=e6500  -c test.c
test.c: In function '__ieee754_fmod':
test.c:32:1: error: unrecognizable insn:
   32 | }
      | ^
(insn 52 8 53 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 [0xffe0000000000000]))
                    (const_int 0 [0])))
            (clobber (reg:DI 9 9 [129]))
        ]) "test.c":21:4 -1
     (nil))
during RTL pass: split2
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
0x957477 extract_insn(rtx_insn*)
        /home/EB/sebastian_h/src/gcc/gcc/recog.cc:2791
0x9574d1 extract_insn_cached(rtx_insn*)
        /home/EB/sebastian_h/src/gcc/gcc/recog.cc:2680
0x6a9a0b cleanup_subreg_operands(rtx_insn*)
        /home/EB/sebastian_h/src/gcc/gcc/final.cc:3054
0x95583c split_insn
        /home/EB/sebastian_h/src/gcc/gcc/recog.cc:3420
0x95a5b2 split_all_insns()
        /home/EB/sebastian_h/src/gcc/gcc/recog.cc:3488
0x95a6c8 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 <https://gcc.gnu.org/bugs/> for instructions.

[Bug target/109566] powerpc: unrecognizable insn for -mcpu=e6500

[sebastian.huber@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

Sebastian Huber <sebastian.huber@embedded-brains.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |12.1.0, 12.2.0

--- Comment #1 from Sebastian Huber <sebastian.huber@embedded-brains.de> ---
I did a git bisect using. It ended up in this commit:

commit d75be7e4343f049176546aa9517d570e5eb67954
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Thu Oct 6 15:01:24 2022 -0400

    Add partial equivalence recognition to cast and bitwise and.

    This provides the hooks that will register partial equivalencies for
    casts and bitwise AND operations with the appropriate bit pattern.

            * range-op.cc (operator_cast::lhs_op1_relation): New.
            (operator_bitwise_and::lhs_op1_relation): New.

 gcc/range-op.cc | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)

[Bug target/109566] powerpc: unrecognizable insn for -mcpu=e6500

[sebastian.huber@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #2 from Sebastian Huber <sebastian.huber@embedded-brains.de> ---
Sorry for the confusion, the actual bad commit was the follow up commit (NOT
d75be7e4343f049176546aa9517d570e5eb67954):

commit 6cc3394507a2303a18891d34222c53f679256c37
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Wed Oct 5 10:42:07 2022 -0400

    propagate partial equivs in the cache.

    Adjust on-entry cache propagation to look for and propagate both full
    and partial equivalences.

            gcc/
            PR tree-optimization/102540
            PR tree-optimization/102872
            * gimple-range-cache.cc (ranger_cache::fill_block_cache):
            Handle partial equivs.
            (ranger_cache::range_from_dom): Cleanup dump output.

            gcc/testsuite/
            * gcc.dg/pr102540.c: New.
            * gcc.dg/pr102872.c: New.

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

[sebastian.huber@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

Sebastian Huber <sebastian.huber@embedded-brains.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|powerpc: unrecognizable     |powerpc: unrecognizable
                   |insn for -mcpu=e6500        |insn for -mcpu=e6500,
                   |                            |-mcpu=power3, ...,
                   |                            |-mcpu=power10

--- Comment #3 from Sebastian Huber <sebastian.huber@embedded-brains.de> ---
I get this error also for -mcpu=power3, ..., -mcpu=power10.

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

[sebastian.huber@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #4 from Sebastian Huber <sebastian.huber@embedded-brains.de> ---
(In reply to Sebastian Huber from comment #3)
> I get this error also for -mcpu=power3, ..., -mcpu=power10.

I get the ICE only in 32-bit mode, the 64-bit mode works:

powerpc-rtems6-gcc -O2 -mcpu=power10 -m64 -S test.c -dA -da -dp -o - 
        .file   "test.c"
        .machine power10
        .abiversion 2
        .section        ".text"
        .align 2
        .p2align 4,,15
        .globl __ieee754_fmod
        .type   __ieee754_fmod, @function
__ieee754_fmod:
.LFB0:
        .cfi_startproc
        .localentry     __ieee754_fmod,1
 # BLOCK 2, count:118111600 (estimated locally) seq:0
 # PRED: ENTRY [always]  count:118111600 (estimated locally) (FALLTHRU)
        mfvsrd 9,1       # 7    [c=4 l=4]  *movdi_internal64/25
        srdi 9,9,32      # 8    [c=4 l=4]  lshrdi3
        rldicr. 9,9,33,10        # 49   [c=4 l=4]  *rotldi3_mask_dot/0
 # SUCC: 4 [50.0% (guessed)]  count:59055800 (estimated locally) (CAN_FALLTHRU)
3 [50.0% (guessed)]  count:59055800 (estimated locally) (FALLTHRU,CAN_FALLTHRU)
        beq 0,.L2        # 50   [c=4 l=4]  *cbranch
 # BLOCK 3, count:118111600 (estimated locally) seq:1
 # PRED: 2 [50.0% (guessed)]  count:59055800 (estimated locally)
(FALLTHRU,CAN_FALLTHRU)
        xxlxor 1,1,1     # 22   [c=4 l=4]  *movdf_hardfloat64/8
 # SUCC: EXIT [always]  count:118111600 (estimated locally)
        blr              # 53   [c=4 l=4]  simple_return
 # BLOCK 4, count:0 (estimated locally) seq:2
 # PRED: 2 [50.0% (guessed)]  count:59055800 (estimated locally) (CAN_FALLTHRU)
4 [always]  count:0 (estimated locally) (DFS_BACK,CAN_FALLTHRU)
.L2:
 # SUCC: 4 [always]  count:0 (estimated locally) (DFS_BACK,CAN_FALLTHRU)
        b .L2            # 59   [c=4 l=4]  jump
        .long 0
        .byte 0,0,0,0,0,0,0,0
        .cfi_endproc
.LFE0:
        .size   __ieee754_fmod,.-__ieee754_fmod
        .ident  "GCC: (GNU) 13.0.1 20230424 (prerelease) [releases/gcc-13
f743863e09a]"
        .gnu_attribute 4, 9
        .section        .note.GNU-stack,"",@progbits

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

Richard Biener <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> ---
It does look like an error in the splitter, I suspect the constant isn't
legitimate?

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[sebastian.huber@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #7 from Sebastian Huber <sebastian.huber@embedded-brains.de> ---
(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 [0xffe0000000000000]))
                    (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 <https://gcc.gnu.org/bugs/> for instructions.

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

Jakub Jelinek <jakub at gcc dot gnu.org> 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 <jakub at gcc dot gnu.org> ---
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 [0x7ff00000]))
                        (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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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 [0x7ff00000]))
                        (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 [0xffe0000000000000]))
                    (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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I bet the culprit is that *rotl<mode>3_mask_dot has
(<MODE>mode == Pmode || UINTVAL (operands[3]) <= 0x7fffffff)
in condition.  So, because *branch_anddi3_dot always wants DImode, if Pmode is
SImode,
it should make sure (UINTVAL (operands[2]) << (63 - nb)) <= 0x7fffffff.

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
--- 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, &nb, &ne, mode) && nb >= ne && ne > 0;
+  if (rs6000_is_valid_mask (mask, &nb, &ne, mode) && nb >= ne && ne > 0)
+    {
+      if (TARGET_64BIT)
+       return true;
+      /* *rotldi3_mask_dot requires for -m32 -mpowerpc64 that the mask is
+        <= 0x7ffffff.  */
+      return (UINTVAL (mask) << (63 - nb)) <= 0x7fffffff;
+    }
+  else
+    return false;
 }

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

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[13/14 Regression] powerpc: |[12/13/14 Regression]
                   |unrecognizable insn for     |powerpc: unrecognizable
                   |-mcpu=e6500, -mcpu=power3,  |insn for -mcpu=e6500,
                   |..., -mcpu=power10          |-mcpu=power3, ...,
                   |                            |-mcpu=power10

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Confirmed at least on the reduced testcase this really started with r12-6433.
Though, it still could be considered P1 on 13/14 branches given that the ranger
changes make it trigger on code on which it didn't trigger before.
powerpc*-rtems* isn't primary nor secondary, but it can trigger even on
powerpc64-linux with -m32 -mpowerpc64.

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54910
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54910&action=edit
gcc13-pr109566.patch

Full test I'm going to bootstrap/regtest momentarily.

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

[sebastian.huber@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #15 from Sebastian Huber <sebastian.huber@embedded-brains.de> ---
Thanks for digging into this. With the change I am able to build the
powerpc-rtems target.

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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:97f8f2d0a0384d377ca46da88495f9a3d18d4415

commit r14-218-g97f8f2d0a0384d377ca46da88495f9a3d18d4415
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Apr 25 14:20:51 2023 +0200

    powerpc: Fix up *branch_anddi3_dot for -m32 -mpowerpc64 [PR109566]

    The following testcase reduced from newlib ICEs on powerpc-linux,
    with -O2 -m32 -mpowerpc64 since r12-6433 PR102239 optimization was
    added and on the original testcase since some ranger improvements in
    GCC 13 made it no longer latent on newlib.
    The problem is that the *branch_anddi3_dot define_insn_and_split
    relies on the *rotldi3_mask_dot define_insn_and_split being recognized
    during splitting.  The rs6000_is_valid_rotate_dot_mask function checks
whether
    the mask is a CONST_INT which is a valid mask, but *rotl<mode>3_mask_dot in
    addition to checking that it is a valid mask also has
      (<MODE>mode == Pmode || UINTVAL (operands[3]) <= 0x7fffffff)
    test in the condition.  For TARGET_64BIT that doesn't add any further
    requirements, but for !TARGET_64BIT && TARGET_POWERPC64 if the AND
    second operand is larger than INT_MAX it will not be recognized.

    The rs6000_is_valid_rotate_dot_mask function is used solely in one spot,
    condition of *branch_anddi3_dot, so the following patch adjusts it
    to check for that as well.

    2023-04-25  Jakub Jelinek  <jakub@redhat.com>

            PR target/109566
            * config/rs6000/rs6000.cc (rs6000_is_valid_rotate_dot_mask): For
            !TARGET_64BIT, don't return true if UINTVAL (mask) << (63 - nb)
            is larger than signed int maximum.

            * gcc.target/powerpc/pr109566.c: New test.

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

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #17 from Segher Boessenkool <segher at gcc dot gnu.org> ---
So, apparently powerpc-rtems uses -mpowerpc64 by default?!  That is
problematic,
it changes the ABI, might not actually work at all (it requires your
setjmp/longjmp
and getcontext/setcontext to restore the full 64-bit registers), and is often
bigger and slower code (but not always).

I suppose powerpc-rtems gets this from a default CPU choice?

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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:fb4e50a7c1cdd14e8f06421c642837292c9d8dee

commit r13-7240-gfb4e50a7c1cdd14e8f06421c642837292c9d8dee
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Apr 25 14:20:51 2023 +0200

    powerpc: Fix up *branch_anddi3_dot for -m32 -mpowerpc64 [PR109566]

    The following testcase reduced from newlib ICEs on powerpc-linux,
    with -O2 -m32 -mpowerpc64 since r12-6433 PR102239 optimization was
    added and on the original testcase since some ranger improvements in
    GCC 13 made it no longer latent on newlib.
    The problem is that the *branch_anddi3_dot define_insn_and_split
    relies on the *rotldi3_mask_dot define_insn_and_split being recognized
    during splitting.  The rs6000_is_valid_rotate_dot_mask function checks
whether
    the mask is a CONST_INT which is a valid mask, but *rotl<mode>3_mask_dot in
    addition to checking that it is a valid mask also has
      (<MODE>mode == Pmode || UINTVAL (operands[3]) <= 0x7fffffff)
    test in the condition.  For TARGET_64BIT that doesn't add any further
    requirements, but for !TARGET_64BIT && TARGET_POWERPC64 if the AND
    second operand is larger than INT_MAX it will not be recognized.

    The rs6000_is_valid_rotate_dot_mask function is used solely in one spot,
    condition of *branch_anddi3_dot, so the following patch adjusts it
    to check for that as well.

    2023-04-25  Jakub Jelinek  <jakub@redhat.com>

            PR target/109566
            * config/rs6000/rs6000.cc (rs6000_is_valid_rotate_dot_mask): For
            !TARGET_64BIT, don't return true if UINTVAL (mask) << (63 - nb)
            is larger than signed int maximum.

            * gcc.target/powerpc/pr109566.c: New test.

    (cherry picked from commit 97f8f2d0a0384d377ca46da88495f9a3d18d4415)

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12/13/14 Regression]       |[12 Regression] powerpc:
                   |powerpc: unrecognizable     |unrecognizable insn for
                   |insn for -mcpu=e6500,       |-mcpu=e6500, -mcpu=power3,
                   |-mcpu=power3, ...,          |..., -mcpu=power10
                   |-mcpu=power10               |

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk and for 13.1 so far.

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.0                        |12.3

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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

--- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:2e5e72488b108e5d75049179ef91a093e5fedc49

commit r12-9475-g2e5e72488b108e5d75049179ef91a093e5fedc49
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Apr 25 14:20:51 2023 +0200

    powerpc: Fix up *branch_anddi3_dot for -m32 -mpowerpc64 [PR109566]

    The following testcase reduced from newlib ICEs on powerpc-linux,
    with -O2 -m32 -mpowerpc64 since r12-6433 PR102239 optimization was
    added and on the original testcase since some ranger improvements in
    GCC 13 made it no longer latent on newlib.
    The problem is that the *branch_anddi3_dot define_insn_and_split
    relies on the *rotldi3_mask_dot define_insn_and_split being recognized
    during splitting.  The rs6000_is_valid_rotate_dot_mask function checks
whether
    the mask is a CONST_INT which is a valid mask, but *rotl<mode>3_mask_dot in
    addition to checking that it is a valid mask also has
      (<MODE>mode == Pmode || UINTVAL (operands[3]) <= 0x7fffffff)
    test in the condition.  For TARGET_64BIT that doesn't add any further
    requirements, but for !TARGET_64BIT && TARGET_POWERPC64 if the AND
    second operand is larger than INT_MAX it will not be recognized.

    The rs6000_is_valid_rotate_dot_mask function is used solely in one spot,
    condition of *branch_anddi3_dot, so the following patch adjusts it
    to check for that as well.

    2023-04-25  Jakub Jelinek  <jakub@redhat.com>

            PR target/109566
            * config/rs6000/rs6000.cc (rs6000_is_valid_rotate_dot_mask): For
            !TARGET_64BIT, don't return true if UINTVAL (mask) << (63 - nb)
            is larger than signed int maximum.

            * gcc.target/powerpc/pr109566.c: New test.

    (cherry picked from commit 97f8f2d0a0384d377ca46da88495f9a3d18d4415)

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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.