[Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670

[Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670

[marxin at gcc dot gnu.org]

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

            Bug ID: 98959
           Summary: ICE in extract_constrain_insn, at recog.c:2670
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: luoxhu at gcc dot gnu.org, segher at gcc dot gnu.org
  Target Milestone: ---
              Host: x86_64-linux-gnu
            Target: ppc64le-linux-gnu

The following fails:

$ cat ice.i
__attribute__((altivec(vector__))) unsigned __int128 e0(
    __attribute__((altivec(vector__))) unsigned __int128 v);
void me0() {
  __attribute__((altivec(vector__))) unsigned __int128 dv = {
      ((31415926539) << 6)};
  dv = e0(dv);
  if (dv[0] != 0) __builtin_abort();
}

$ ppc64le-linux-gnu-gcc -fno-schedule-insns -O2 ice.i -c
ice.i: In function ‘me0’:
ice.i:8:1: error: insn does not satisfy its constraints:
    8 | }
      | ^
(insn 48 5 49 2 (set (reg:V1TI 66 2)
        (rotate:V1TI (mem/u/c:V1TI (and:DI (reg/f:DI 9 9 [120])
                    (const_int -16 [0xfffffffffffffff0])) [0  S16 A128])
            (const_int 64 [0x40]))) "ice.i":6:8 1102 {*vsx_le_permute_v1ti}
     (nil))
during RTL pass: pro_and_epilogue
ice.i:8:1: internal compiler error: in extract_constrain_insn, at recog.c:2670
0x5c9c84 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/rtl-error.c:108
0x5c9caa _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/rtl-error.c:118
0x5c9154 extract_constrain_insn(rtx_insn*)
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/recog.c:2670
0xa8f31c copyprop_hardreg_forward_1
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/regcprop.c:831
0xa906a1 copyprop_hardreg_forward_bb_without_debug_insn(basic_block_def*)
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/regcprop.c:1210
0xae56eb prepare_shrink_wrap
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/shrink-wrap.c:451
0xae56eb try_shrink_wrapping(edge_def**, rtx_insn*)
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/shrink-wrap.c:674
0x86c3a9 thread_prologue_and_epilogue_insns()
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:6025
0x86c922 rest_of_handle_thread_prologue_and_epilogue
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:6510
0x86c922 execute
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/gcc/function.c:6586
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-02-03
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Can't reproduce, what exact -mcpu= etc. do you use by default?

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
I do not set any default CPU:

$ ~/BIG/bin/ppc64le/dev/shm/buildbot/install/gcc/bin/ppc64le-linux-gnu-gcc
ice.i -c -fno-schedule-insns -O2 -v
Using built-in specs.
COLLECT_GCC=/home/marxin/BIG/bin/ppc64le/dev/shm/buildbot/install/gcc/bin/ppc64le-linux-gnu-gcc
Target: ppc64le-linux-gnu
Configured with:
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-ppc64le/build/configure
--enable-languages=c,c++,fortran --disable-bootstrap --disable-libsanitizer
--disable-multilib --enable-checking=release
--prefix=/dev/shm/buildbot/install/gcc --target=ppc64le-linux-gnu
--with-as=/usr/bin/powerpc64le-suse-linux-as
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20210203 (experimental)
5c62e4f255bfac65e18213fd93ee1c9908b4a750 (GCC) 
COLLECT_GCC_OPTIONS='-c' '-fno-schedule-insns' '-O2' '-v'

/home/marxin/BIG/bin/ppc64le/dev/shm/buildbot/install/gcc/bin/../lib/gcc/ppc64le-linux-gnu/11.0.0/cc1
-fpreprocessed ice.i -quiet -dumpbase ice.i -dumpbase-ext .i -O2 -version
-fno-schedule-insns -o /tmp/ccM7L6uC.s
GNU C17 (GCC) version 11.0.0 20210203 (experimental)
5c62e4f255bfac65e18213fd93ee1c9908b4a750 (ppc64le-linux-gnu)
        compiled by GNU C version 10.2.1 20201202 [revision
e563687cf9d3d1278f45aaebd03e0f66531076c9], GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 11.0.0 20210203 (experimental)
5c62e4f255bfac65e18213fd93ee1c9908b4a750 (ppc64le-linux-gnu)
        compiled by GNU C version 10.2.1 20201202 [revision
e563687cf9d3d1278f45aaebd03e0f66531076c9], GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a0aac783ff2ce910e826fdec7bc2322b

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

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

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
So it started with g:e6f24f824beb8ba6805702e287bbd6153b472488.

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
Created attachment 50125
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50125&action=edit
auto-host.h

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #50125|0                           |1
        is obsolete|                            |

--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
Created attachment 50126
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50126&action=edit
auto-host.h for current master

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> ---
Emergency dump:
dump file: ice.i.298r.pro_and_epilogue

;; Function me0 (me0, funcdef_no=0, decl_uid=3226, cgraph_uid=1,
symbol_order=0)



try_optimize_cfg iteration 1

starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
df_worklist_dataflow_doublequeue: n_basic_blocks 5 n_edges 4 count 5 (    1)
df_worklist_dataflow_doublequeue: n_basic_blocks 5 n_edges 4 count 5 (    1)



EMERGENCY DUMP:



me0

Dataflow summary:
;;  fully invalidated by EH      0 [0] 3 [3] 4 [4] 5 [5] 6 [6] 7 [7] 8 [8] 9
[9] 10 [10] 11 [11] 12 [12] 13 [13] 32 [0] 33 [1] 34 [2] 35 [3] 36 [4] 37 [5]
38 [6] 39 [7] 40 [8] 41 [9] 42 [10] 43 [11] 44 [12] 45 [13] 64 [0] 65 [1] 66
[2] 67 [3] 68 [4] 69 [5] 70 [6] 71 [7] 72 [8] 73 [9] 74 [10] 75 [11] 76 [12] 77
[13] 78 [14] 79 [15] 80 [16] 81 [17] 82 [18] 83 [19] 96 [lr] 97 [ctr] 98 [ca]
100 [0] 101 [1] 105 [5] 106 [6] 107 [7] 109 [vscr]
;;  hardware regs used   1 [1] 109 [vscr]
;;  regular block artificial uses        1 [1]
;;  eh block artificial uses     1 [1] 99 [ap]
;;  entry block defs     1 [1] 3 [3] 4 [4] 5 [5] 6 [6] 7 [7] 8 [8] 9 [9] 10
[10] 33 [1] 34 [2] 35 [3] 36 [4] 37 [5] 38 [6] 39 [7] 40 [8] 41 [9] 42 [10] 43
[11] 44 [12] 45 [13] 66 [2] 67 [3] 68 [4] 69 [5] 70 [6] 71 [7] 72 [8] 73 [9] 74
[10] 75 [11] 76 [12] 77 [13] 96 [lr] 109 [vscr]
;;  exit block uses      1 [1] 2 [2] 96 [lr] 108 [vrsave] 109 [vscr]
;;  regs ever live       1 [1] 2 [2] 9 [9] 10 [10] 66 [2] 96 [lr] 100 [0] 109
[vscr]
;;  ref usage   r0={2d} r1={1d,9u} r2={4u} r3={3d} r4={3d} r5={3d} r6={3d}
r7={3d} r8={3d} r9={7d,3u} r10={4d,1u} r11={2d} r12={2d} r13={2d} r32={2d}
r33={3d} r34={3d} r35={3d} r36={3d} r37={3d} r38={3d} r39={3d} r40={3d}
r41={3d} r42={3d} r43={3d} r44={3d} r45={3d} r64={2d} r65={2d} r66={7d,5u}
r67={3d} r68={3d} r69={3d} r70={3d} r71={3d} r72={3d} r73={3d} r74={3d}
r75={3d} r76={3d} r77={3d} r78={2d} r79={2d} r80={2d} r81={2d} r82={2d}
r83={2d} r96={3d,1u} r97={2d} r98={2d} r100={3d,1u} r101={2d} r105={2d}
r106={2d} r107={2d} r108={1u} r109={3d,3u} 
;;    total ref usage 184{156d,28u,0e} in 13{11 regular + 2 call} insns.
(note 1 0 3 NOTE_INSN_DELETED)
(note 3 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 3 5 2 NOTE_INSN_FUNCTION_BEG)
(insn 5 2 48 2 (set (reg/f:DI 9 9 [120])
        (mem/u/c:DI (unspec:DI [
                    (symbol_ref/u:DI ("*.LC1") [flags 0x2])
                    (reg:DI 2 2)
                ] UNSPEC_TOCREL) [1  S8 A8]))
"/home/marxin/Programming/testcases/ice.i":6:8 636 {*movdi_internal64}
     (expr_list:REG_EQUIV (symbol_ref/u:DI ("*.LC0") [flags 0x82])
        (nil)))
(insn 48 5 49 2 (set (reg:V1TI 66 2)
        (rotate:V1TI (mem/u/c:V1TI (and:DI (reg/f:DI 9 9 [120])
                    (const_int -16 [0xfffffffffffffff0])) [0  S16 A128])
            (const_int 64 [0x40])))
"/home/marxin/Programming/testcases/ice.i":6:8 1102 {*vsx_le_permute_v1ti}
     (nil))
(insn 49 48 9 2 (set (reg:V1TI 66 2)
        (rotate:V1TI (reg:V1TI 66 2)
            (const_int 64 [0x40])))
"/home/marxin/Programming/testcases/ice.i":6:8 1102 {*vsx_le_permute_v1ti}
     (nil))
(call_insn 9 49 47 2 (parallel [
            (set (reg:V1TI 66 2)
                (call (mem:SI (symbol_ref:DI ("e0") [flags 0x41] 
<function_decl 0x7ffff75a8200 e0>) [0 e0 S4 A8])
                    (const_int 0 [0])))
            (use (const_int 0 [0]))
            (clobber (reg:DI 96 lr))
        ]) "/home/marxin/Programming/testcases/ice.i":6:8 724
{*call_value_nonlocal_aixdi}
     (expr_list:REG_CALL_DECL (symbol_ref:DI ("e0") [flags 0x41] 
<function_decl 0x7ffff75a8200 e0>)
        (nil))
    (expr_list (use (reg:DI 2 2))
        (expr_list:V1TI (use (reg:V1TI 66 2))
            (nil))))
(insn 47 9 50 2 (set (reg:DI 9 9 [136])
        (plus:DI (reg/f:DI 1 1)
            (const_int 32 [0x20])))
"/home/marxin/Programming/testcases/ice.i":6:8 66 {*adddi3}
     (nil))
(insn 50 47 51 2 (set (reg:V1TI 66 2)
        (rotate:V1TI (reg:V1TI 66 2)
            (const_int 64 [0x40])))
"/home/marxin/Programming/testcases/ice.i":6:8 1102 {*vsx_le_permute_v1ti}
     (nil))
(insn 51 50 52 2 (set (mem/c:V1TI (reg:DI 9 9 [136]) [2 %sfp+32 S16 A128])
        (rotate:V1TI (reg:V1TI 66 2)
            (const_int 64 [0x40])))
"/home/marxin/Programming/testcases/ice.i":6:8 1102 {*vsx_le_permute_v1ti}
     (nil))
(insn 52 51 44 2 (set (reg:V1TI 66 2)
        (rotate:V1TI (reg:V1TI 66 2)
            (const_int 64 [0x40])))
"/home/marxin/Programming/testcases/ice.i":6:8 1102 {*vsx_le_permute_v1ti}
     (nil))
(insn 44 52 45 2 (set (reg:DI 10 10 [131])
        (mem/c:DI (plus:DI (reg/f:DI 1 1)
                (const_int 32 [0x20])) [2 %sfp+32 S8 A128]))
"/home/marxin/Programming/testcases/ice.i":6:8 636 {*movdi_internal64}
     (nil))
(insn 45 44 13 2 (set (reg:DI 9 9 [orig:132+8 ] [132])
        (mem/c:DI (plus:DI (reg/f:DI 1 1)
                (const_int 40 [0x28])) [2 %sfp+40 S8 A64]))
"/home/marxin/Programming/testcases/ice.i":6:8 636 {*movdi_internal64}
     (nil))
(note 13 45 14 2 NOTE_INSN_DELETED)
(insn 14 13 15 2 (parallel [
            (set (reg:CC 100 0 [124])
                (compare:CC (ior:DI (reg:DI 9 9 [orig:128 _1+8 ] [128])
                        (reg:DI 10 10 [orig:127 _1 ] [127]))
                    (const_int 0 [0])))
            (clobber (reg:DI 9 9 [133]))
        ]) "/home/marxin/Programming/testcases/ice.i":7:6 214 {*booldi3_dot}
     (nil))
(jump_insn 15 14 28 2 (set (pc)
        (if_then_else (eq (reg:CC 100 0 [124])
                (const_int 0 [0]))
            (label_ref:DI 26)
            (pc))) "/home/marxin/Programming/testcases/ice.i":7:6 829
{*cbranch}
     (int_list:REG_BR_PROB 1073741831 (nil))
 -> 26)
(note 28 15 22 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(call_insn 22 28 23 3 (parallel [
            (call (mem:SI (symbol_ref:DI ("abort") [flags 0x41]  <function_decl
0x7ffff7490600 __builtin_abort>) [0 __builtin_abort S4 A8])
                (const_int 0 [0]))
            (use (const_int 0 [0]))
            (clobber (reg:DI 96 lr))
        ]) "/home/marxin/Programming/testcases/ice.i":7:19 723
{*call_nonlocal_aixdi}
     (expr_list:REG_CALL_DECL (symbol_ref:DI ("abort") [flags 0x41] 
<function_decl 0x7ffff7490600 __builtin_abort>)
        (expr_list:REG_NORETURN (const_int 0 [0])
            (expr_list:REG_EH_REGION (const_int 0 [0])
                (nil))))
    (expr_list (use (reg:DI 2 2))
        (nil)))
(barrier 23 22 26)
(code_label 26 23 27 4 1 (nil) [1 uses])
(note 27 26 46 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(note 46 27 0 NOTE_INSN_DELETED)

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org]

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

--- Comment #7 from Peter Bergner <bergner at gcc dot gnu.org> ---
I cannot recreate the ICE with a native build.  I'll try building a cross and
seeing if that exposes the issue for me.

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org]

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

--- Comment #8 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #2)
> I do not set any default CPU:

The default cpu on ppc64le is (should be!) POWER8.

That said, I cannot recreate the issue with a cross build using current trunk. 
I will say that the change you identified did cause some fallout that was fixed
with a later change (below) that looks related to the bad insn you are seeing. 
Maybe this is a bisec issue?  Does adding the later fix from the following
"fix" the ICE?

commit dd75498db79675a1a0b73c25e5f110969ee72d9d
Author:     Peter Bergner <bergner@linux.ibm.com>
AuthorDate: Thu Apr 16 23:26:41 2020 -0500
Commit:     Peter Bergner <bergner@linux.ibm.com>
CommitDate: Thu Apr 16 23:26:41 2020 -0500

    rs6000: Fix ICE in decompose_normal_address. [PR93974]

    Fix an ICE in decompose_normal_address(), which cannot handle Altivec AND:
    addresses, by disallowing them via implementing the target hook
    rs6000_cannot_substitute_mem_equiv_p.

    gcc/
            PR rtl-optimization/93974
            * config/rs6000/rs6000.c (TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P):
Define.
            (rs6000_cannot_substitute_mem_equiv_p): New function.

    gcc/testsuite/
            PR rtl-optimization/93974
            * g++.dg/pr93974.C: New test.

If that fixes it, are you really seeing the same ICE on current trunk?

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
> If that fixes it, are you really seeing the same ICE on current trunk?

Yes, I see it also on the current trunk.

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The important difference from my auto-host.h to your auto-host.h which causes
this ICE is that you don't have HAVE_LD_LARGE_TOC defined.
Manually commenting it out makes the ICE reproduceable.

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org]

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

--- Comment #11 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> The important difference from my auto-host.h to your auto-host.h which
> causes this ICE is that you don't have HAVE_LD_LARGE_TOC defined.
> Manually commenting it out makes the ICE reproduceable.

So the important thing on recreating this is using a binutils that has been
configured a certain way?

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org]

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

--- Comment #12 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> The important difference from my auto-host.h to your auto-host.h which
> causes this ICE is that you don't have HAVE_LD_LARGE_TOC defined.
> Manually commenting it out makes the ICE reproduceable.

Doing this on my native build allowed me to recreate the ICE too.  I'll have a
look.

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |meissner at gcc dot gnu.org,
                   |                            |wschmidt at gcc dot gnu.org

--- Comment #13 from Peter Bergner <bergner at gcc dot gnu.org> ---
Adding Bill and Mike for some input.

So the bad insn below is being generated by the after LRA splitter,
specifically the *vsx_le_perm_load_<mode> splitter which calls
rs6000_emit_le_vsx_permute().  

Bill, Mike and Segher, I assume that vsx function is NOT expecting to see an
Altivec style and: address correct?  Adding some uses of the
altivec_indexed_or_indirect_operand () predicate to disable the splitters that
call rs6000_emit_le_vsx_permute() seems to fix the bug for me.  Does this look
like the correct fix?


diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index ec068c58aa5..8db41a066b4 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -10059,6 +10059,11 @@ rs6000_const_vec (machine_mode mode)
 void
 rs6000_emit_le_vsx_permute (rtx dest, rtx source, machine_mode mode)
 {
+  if (MEM_P (dest))
+    gcc_assert (!altivec_indexed_or_indirect_operand (dest, mode));
+  else if (MEM_P (source))
+    gcc_assert (!altivec_indexed_or_indirect_operand (source, mode));
+
   /* Scalar permutations are easier to express in integer modes rather than
      floating-point modes, so cast them here.  We use V1TImode instead
      of TImode to ensure that the values don't go through GPRs.  */
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index 3e0518631df..610490cb3d9 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -991,7 +991,8 @@
   "@
    #
    #"
-  "!BYTES_BIG_ENDIAN && TARGET_VSX && !TARGET_P9_VECTOR"
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && !TARGET_P9_VECTOR
+   && !altivec_indexed_or_indirect_operand (operands[1], <MODE>mode)"
   [(const_int 0)]
 {
   rtx tmp = (can_create_pseudo_p ()
@@ -1008,7 +1009,8 @@
 (define_insn "*vsx_le_perm_store_<mode>"
   [(set (match_operand:VSX_LE_128 0 "memory_operand" "=Z,Q")
         (match_operand:VSX_LE_128 1 "vsx_register_operand" "+wa,r"))]
-  "!BYTES_BIG_ENDIAN && TARGET_VSX && !TARGET_P9_VECTOR"
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && !TARGET_P9_VECTOR
+   & !altivec_indexed_or_indirect_operand (operands[0], <MODE>mode)"
   "@
    #
    #"
@@ -1019,7 +1021,8 @@
 (define_split
   [(set (match_operand:VSX_LE_128 0 "memory_operand")
         (match_operand:VSX_LE_128 1 "vsx_register_operand"))]
-  "!BYTES_BIG_ENDIAN && TARGET_VSX && !reload_completed && !TARGET_P9_VECTOR"
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && !reload_completed && !TARGET_P9_VECTOR
+   && !altivec_indexed_or_indirect_operand (operands[0], <MODE>mode)"
   [(const_int 0)]
 {
   rtx tmp = (can_create_pseudo_p ()
@@ -1075,7 +1078,8 @@
 (define_split
   [(set (match_operand:VSX_LE_128 0 "memory_operand")
         (match_operand:VSX_LE_128 1 "vsx_register_operand"))]
-  "!BYTES_BIG_ENDIAN && TARGET_VSX && reload_completed && !TARGET_P9_VECTOR"
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && reload_completed && !TARGET_P9_VECTOR
+   && !altivec_indexed_or_indirect_operand (operands[0], <MODE>mode)"
   [(const_int 0)]
 {
   rs6000_emit_le_vsx_permute (operands[1], operands[1], <MODE>mode);

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[wschmidt at gcc dot gnu.org]

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

--- Comment #14 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
We should definitely not be allowing the AltiVec "& ~16" flavors into these
patterns.  I'm not certain whether your fix is the best way to achieve that,
but it could well be; I'll defer to Segher on that.

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org]

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

--- Comment #15 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> The important difference from my auto-host.h to your auto-host.h which
> causes this ICE is that you don't have HAVE_LD_LARGE_TOC defined.
> Manually commenting it out makes the ICE reproduceable.

FYI, given HAVE_LD_LARGE_TOC controls the -mcmodel= default, I tried using a
normal build (ie, did not #undef HAVE_LD_LARGE_TOC in auto-host.h) and was able
to recreate the ICE by using the options: -fno-schedule-insns -O2
-mcmodel=small

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org]

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

--- Comment #16 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Bill Schmidt from comment #14)
> We should definitely not be allowing the AltiVec "& ~16" flavors into these
> patterns.  I'm not certain whether your fix is the best way to achieve that,
> but it could well be; I'll defer to Segher on that.

So I _think_ the patch above is correct.  Ie, we shouldn't split the insn which
calls the rs6000_emit_le_vsx_* functions if the mem address isn't valid for the
patterns the splitter is going to create.

The question I have is, there are 2 expanders which I think we also need to
guard with similar tests.  They are vsx_load_<mode> and vsx_store_<mode>. 
Segher, I assume we want to verify we don't have an altivec style & ~16 address
there too, correct?  Just like we do in vector.md's mov<mode> pattern.

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org]

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

--- Comment #17 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #16)
> The question I have is, there are 2 expanders which I think we also need to
> guard with similar tests.  They are vsx_load_<mode> and vsx_store_<mode>. 
> Segher, I assume we want to verify we don't have an altivec style & ~16
> address there too, correct?  Just like we do in vector.md's mov<mode>
> pattern.

Ie, adding the following hunks to the patch above:

@@ -1241,7 +1245,8 @@
   "VECTOR_MEM_VSX_P (<MODE>mode)"
 {
   /* Expand to swaps if needed, prior to swap optimization.  */
-  if (!BYTES_BIG_ENDIAN && !TARGET_P9_VECTOR)
+  if (!BYTES_BIG_ENDIAN && !TARGET_P9_VECTOR
+      && !altivec_indexed_or_indirect_operand(operands[1], <MODE>mode))
     {
       rs6000_emit_le_vsx_move (operands[0], operands[1], <MODE>mode);
       DONE;
@@ -1254,7 +1259,8 @@
   "VECTOR_MEM_VSX_P (<MODE>mode)"
 {
   /* Expand to swaps if needed, prior to swap optimization.  */
-  if (!BYTES_BIG_ENDIAN && !TARGET_P9_VECTOR)
+  if (!BYTES_BIG_ENDIAN && !TARGET_P9_VECTOR
+      && !altivec_indexed_or_indirect_operand(operands[0], <MODE>mode))
     {
       rs6000_emit_le_vsx_move (operands[0], operands[1], <MODE>mode);
       DONE;

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |bergner at gcc dot gnu.org
             Status|NEW                         |ASSIGNED
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2021-Februar
                   |                            |y/565269.html

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Peter Bergner <bergner@gcc.gnu.org>:

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

commit r11-7558-gcb25dea3ef2c7768007bffc56f0e31e1c42b44e2
Author: Peter Bergner <bergner@linux.ibm.com>
Date:   Mon Mar 8 12:20:41 2021 -0600

    rs6000: Fix invalid splits when using Altivec style addresses [PR98959]

    The rs6000_emit_le_vsx_* functions assume they are not passed an Altivec
    style "& ~16" address.  However, some of our expanders and splitters do
    not verify we do not have an Altivec style address before calling those
    functions, leading to an ICE.  The solution here is to guard the expanders
    and splitters to ensure we do not call them if we're given an Altivec style
    address.

    2021-03-08  Peter Bergner  <bergner@linux.ibm.com>

    gcc/
            PR target/98959
            * config/rs6000/rs6000.c (rs6000_emit_le_vsx_permute): Add an
assert
            to ensure we do not have an Altivec style address.
            * config/rs6000/vsx.md (*vsx_le_perm_load_<mode>): Disable if
passed
            an Altivec style address.
            (*vsx_le_perm_store_<mode>): Likewise.
            (splitters after *vsx_le_perm_store_<mode>): Likewise.
            (vsx_load_<mode>): Disable special expander if passed an Altivec
            style address.
            (vsx_store_<mode>): Likewise.

    gcc/testsuite/
            PR target/98959
            * gcc.target/powerpc/pr98959.c: New test.

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org]

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

--- Comment #19 from Peter Bergner <bergner at gcc dot gnu.org> ---
Fixed on trunk.  Needs backporting to GCC10.

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[segher at gcc dot gnu.org]

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

--- Comment #20 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Bill Schmidt from comment #14)
> We should definitely not be allowing the AltiVec "& ~16" flavors into these
> patterns.  I'm not certain whether your fix is the best way to achieve that,
> but it could well be; I'll defer to Segher on that.

Hey, it works, so it is okay for now at least.  Longer term we should
probably think of something more elegant and less failure-prone.

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Peter Bergner
<bergner@gcc.gnu.org>:

https://gcc.gnu.org/g:410ddbbc6612ca25f4a00120987921372937623e

commit r10-9433-g410ddbbc6612ca25f4a00120987921372937623e
Author: Peter Bergner <bergner@linux.ibm.com>
Date:   Mon Mar 8 12:20:41 2021 -0600

    rs6000: Fix invalid splits when using Altivec style addresses [PR98959]

    The rs6000_emit_le_vsx_* functions assume they are not passed an Altivec
    style "& ~16" address.  However, some of our expanders and splitters do
    not verify we do not have an Altivec style address before calling those
    functions, leading to an ICE.  The solution here is to guard the expanders
    and splitters to ensure we do not call them if we're given an Altivec style
    address.

    2021-03-08  Peter Bergner  <bergner@linux.ibm.com>

    gcc/
            PR target/98959
            * config/rs6000/rs6000.c (rs6000_emit_le_vsx_permute): Add an
assert
            to ensure we do not have an Altivec style address.
            * config/rs6000/vsx.md (*vsx_le_perm_load_<mode>): Disable if
passed
            an Altivec style address.
            (*vsx_le_perm_store_<mode>): Likewise.
            (splitters after *vsx_le_perm_store_<mode>): Likewise.
            (vsx_load_<mode>): Disable special expander if passed an Altivec
            style address.
            (vsx_store_<mode>): Likewise.

    gcc/testsuite/
            PR target/98959
            * gcc.target/powerpc/pr98959.c: New test.

    (cherry picked from commit cb25dea3ef2c7768007bffc56f0e31e1c42b44e2)

[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

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

--- Comment #22 from Peter Bergner <bergner at gcc dot gnu.org> ---
Fixed on trunk and GCC10.