* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
@ 2021-02-03 18:52 ` marxin at gcc dot gnu.org
2021-02-04 11:44 ` jakub at gcc dot gnu.org
` (22 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-02-03 18:52 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
2021-02-03 18:52 ` [Bug target/98959] " marxin at gcc dot gnu.org
@ 2021-02-04 11:44 ` jakub at gcc dot gnu.org
2021-02-04 12:19 ` marxin at gcc dot gnu.org
` (21 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-02-04 11:44 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
2021-02-03 18:52 ` [Bug target/98959] " marxin at gcc dot gnu.org
2021-02-04 11:44 ` jakub at gcc dot gnu.org
@ 2021-02-04 12:19 ` marxin at gcc dot gnu.org
2021-02-04 13:20 ` marxin at gcc dot gnu.org
` (20 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-02-04 12:19 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (2 preceding siblings ...)
2021-02-04 12:19 ` marxin at gcc dot gnu.org
@ 2021-02-04 13:20 ` marxin at gcc dot gnu.org
2021-02-04 13:20 ` marxin at gcc dot gnu.org
` (19 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-02-04 13:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (3 preceding siblings ...)
2021-02-04 13:20 ` marxin at gcc dot gnu.org
@ 2021-02-04 13:20 ` marxin at gcc dot gnu.org
2021-02-04 13:23 ` marxin at gcc dot gnu.org
` (18 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-02-04 13:20 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (4 preceding siblings ...)
2021-02-04 13:20 ` marxin at gcc dot gnu.org
@ 2021-02-04 13:23 ` marxin at gcc dot gnu.org
2021-02-04 13:24 ` marxin at gcc dot gnu.org
` (17 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-02-04 13:23 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (5 preceding siblings ...)
2021-02-04 13:23 ` marxin at gcc dot gnu.org
@ 2021-02-04 13:24 ` marxin at gcc dot gnu.org
2021-02-04 16:33 ` bergner at gcc dot gnu.org
` (16 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-02-04 13:24 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (6 preceding siblings ...)
2021-02-04 13:24 ` marxin at gcc dot gnu.org
@ 2021-02-04 16:33 ` bergner at gcc dot gnu.org
2021-02-04 17:01 ` bergner at gcc dot gnu.org
` (15 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-02-04 16:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (7 preceding siblings ...)
2021-02-04 16:33 ` bergner at gcc dot gnu.org
@ 2021-02-04 17:01 ` bergner at gcc dot gnu.org
2021-02-04 17:08 ` marxin at gcc dot gnu.org
` (14 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-02-04 17:01 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (8 preceding siblings ...)
2021-02-04 17:01 ` bergner at gcc dot gnu.org
@ 2021-02-04 17:08 ` marxin at gcc dot gnu.org
2021-02-04 18:18 ` jakub at gcc dot gnu.org
` (13 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-02-04 17:08 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (9 preceding siblings ...)
2021-02-04 17:08 ` marxin at gcc dot gnu.org
@ 2021-02-04 18:18 ` jakub at gcc dot gnu.org
2021-02-04 19:29 ` bergner at gcc dot gnu.org
` (12 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-02-04 18:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (10 preceding siblings ...)
2021-02-04 18:18 ` jakub at gcc dot gnu.org
@ 2021-02-04 19:29 ` bergner at gcc dot gnu.org
2021-02-04 19:37 ` bergner at gcc dot gnu.org
` (11 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-02-04 19:29 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (11 preceding siblings ...)
2021-02-04 19:29 ` bergner at gcc dot gnu.org
@ 2021-02-04 19:37 ` bergner at gcc dot gnu.org
2021-02-05 0:13 ` bergner at gcc dot gnu.org
` (10 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-02-04 19:37 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (12 preceding siblings ...)
2021-02-04 19:37 ` bergner at gcc dot gnu.org
@ 2021-02-05 0:13 ` bergner at gcc dot gnu.org
2021-02-07 22:06 ` wschmidt at gcc dot gnu.org
` (9 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-02-05 0:13 UTC (permalink / raw)
To: gcc-bugs
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);
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (13 preceding siblings ...)
2021-02-05 0:13 ` bergner at gcc dot gnu.org
@ 2021-02-07 22:06 ` wschmidt at gcc dot gnu.org
2021-02-11 22:28 ` bergner at gcc dot gnu.org
` (8 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: wschmidt at gcc dot gnu.org @ 2021-02-07 22:06 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (14 preceding siblings ...)
2021-02-07 22:06 ` wschmidt at gcc dot gnu.org
@ 2021-02-11 22:28 ` bergner at gcc dot gnu.org
2021-02-11 23:56 ` bergner at gcc dot gnu.org
` (7 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-02-11 22:28 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (15 preceding siblings ...)
2021-02-11 22:28 ` bergner at gcc dot gnu.org
@ 2021-02-11 23:56 ` bergner at gcc dot gnu.org
2021-02-11 23:59 ` bergner at gcc dot gnu.org
` (6 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-02-11 23:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (16 preceding siblings ...)
2021-02-11 23:56 ` bergner at gcc dot gnu.org
@ 2021-02-11 23:59 ` bergner at gcc dot gnu.org
2021-02-12 20:51 ` bergner at gcc dot gnu.org
` (5 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-02-11 23:59 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (17 preceding siblings ...)
2021-02-11 23:59 ` bergner at gcc dot gnu.org
@ 2021-02-12 20:51 ` bergner at gcc dot gnu.org
2021-03-08 18:24 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-02-12 20:51 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (18 preceding siblings ...)
2021-02-12 20:51 ` bergner at gcc dot gnu.org
@ 2021-03-08 18:24 ` cvs-commit at gcc dot gnu.org
2021-03-10 19:09 ` bergner at gcc dot gnu.org
` (3 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-08 18:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (19 preceding siblings ...)
2021-03-08 18:24 ` cvs-commit at gcc dot gnu.org
@ 2021-03-10 19:09 ` bergner at gcc dot gnu.org
2021-03-10 21:31 ` segher at gcc dot gnu.org
` (2 subsequent siblings)
23 siblings, 0 replies; 25+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-03-10 19:09 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (20 preceding siblings ...)
2021-03-10 19:09 ` bergner at gcc dot gnu.org
@ 2021-03-10 21:31 ` segher at gcc dot gnu.org
2021-03-10 23:48 ` cvs-commit at gcc dot gnu.org
2021-03-11 0:03 ` bergner at gcc dot gnu.org
23 siblings, 0 replies; 25+ messages in thread
From: segher at gcc dot gnu.org @ 2021-03-10 21:31 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (21 preceding siblings ...)
2021-03-10 21:31 ` segher at gcc dot gnu.org
@ 2021-03-10 23:48 ` cvs-commit at gcc dot gnu.org
2021-03-11 0:03 ` bergner at gcc dot gnu.org
23 siblings, 0 replies; 25+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-03-10 23:48 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 25+ messages in thread* [Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
2021-02-03 18:52 [Bug target/98959] New: ICE in extract_constrain_insn, at recog.c:2670 marxin at gcc dot gnu.org
` (22 preceding siblings ...)
2021-03-10 23:48 ` cvs-commit at gcc dot gnu.org
@ 2021-03-11 0:03 ` bergner at gcc dot gnu.org
23 siblings, 0 replies; 25+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-03-11 0:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 25+ messages in thread