From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DC05D3857821; Tue, 26 Jan 2021 12:29:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DC05D3857821 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/98726] [10/11 Regression] SVE: tree check: expected integer_cst, have poly_int_cst in to_wide, at tree.h:5984 Date: Tue, 26 Jan 2021 12:29:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: ice-checking, ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 10.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2021 12:29:55 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98726 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rsandifo at gcc dot gnu.org --- Comment #2 from Richard Biener --- Eh, we can't even _dump_ those VECTOR_CST: #0 internal_error (gmsgid=3D0x29cb490 "tree check: %s, have %s in %s, at %= s:%d") at ../../src/trunk/gcc/diagnostic.c:1804 #1 0x00000000017d00ea in tree_check_failed ( node=3D,=20 file=3D0x2858ad0 "../../src/trunk/gcc/tree.h", line=3D5984,=20 function=3D0x285fe70 "to_= wide") at ../../src/trunk/gcc/tree.c:9812 #2 0x0000000000ad994d in tree_check (__t=3D,= =20 __f=3D0x2858ad0 "../../src/trunk/gcc/tree.h", __l=3D5984,=20 __g=3D0x285fe70 "to_wide"= ,=20 __c=3DINTEGER_CST) at ../../src/trunk/gcc/tree.h:3594 #3 0x0000000000b56c27 in wi::to_wide (t=3D) at ../../src/trunk/gcc/tree.h:5984 #4 0x00000000017d75b2 in vector_cst_int_elt (t=3D,=20 i=3D3) at ../../src/trunk/gcc/tree.c:11104 #5 0x00000000017d7798 in vector_cst_elt (t=3D, = i=3D3) at ../../src/trunk/gcc/tree.c:11131 #6 0x00000000014e0e2c in dump_generic_node (pp=3D0x3754e00,=20 node=3D, spc=3D0, flags=3D2112, is_stmt=3Dfa= lse) at ../../src/trunk/gcc/tree-pretty-print.c:2112 11101 /* Otherwise work out the value from the last two encoded element= s.=20 */ 11102 tree v1 =3D VECTOR_CST_ENCODED_ELT (t, final_i - npatterns); 11103 tree v2 =3D VECTOR_CST_ENCODED_ELT (t, final_i); 11104 wide_int diff =3D wi::to_wide (v2) - wi::to_wide (v1); (gdb) p v1 $5 =3D (gdb) p v2 $6 =3D now if such VECTOR_CST is well-formed (well ...?), then with using poly_wide_int in vector_cst_int_elt we at least get to RTL expansion where we ICE like #0 fancy_abort (file=3D0x28dd290 "../../src/trunk/gcc/rtl.h", line=3D2296,= =20 function=3D0x28e84a0 >::decompose(long*, unsigned int, std::pair const&)::__FUNCTION__> "decompose") at ../../src/trunk/gcc/diagnostic.c:1884 #1 0x0000000000e17546 in wi::int_traits >::decompose (precision=3D32, x=3D...) at ../../src/trunk/gcc/rtl.h:2296 #2 0x0000000000e45617 in wide_int_ref_storage::wide_int_ref_storage > (this=3D0x7fffffffc5a0, x=3D...,=20 precision=3D32) at ../../src/trunk/gcc/wide-int.h:1034 #3 0x0000000000e427e7 in generic_wide_int >::generic_wide_int > (this=3D0x7fffffffc= 5a0,=20 x=3D..., precision=3D32) at ../../src/trunk/gcc/wide-int.h:790 #4 0x0000000000e405be in wi::sub, std::pair > (x=3D..., y=3D...) at ../../src/trunk/gcc/wide-int.h:2512 #5 0x000000000132743f in rtx_vector_builder::step (this=3D0x7fffffffc7a0,= =20 elt1=3D0x7ffff6f2f0c0, elt2=3D0x7ffff6f2f0e0) at ../../src/trunk/gcc/rtx-vector-builder.h:122 #6 0x000000000132795e in vector_builder::elt (this=3D0x7fffffffc7a0, i=3D3) at ../../src/trunk/gcc/vector-builder.h:254 #7 0x0000000001327051 in rtx_vector_builder::build (this=3D0x7fffffffc7a0) at ../../src/trunk/gcc/rtx-vector-builder.c:73 #8 0x0000000000eb109a in const_vector_from_tree ( exp=3D) at ../../src/trunk/gcc/expr.c:12763 Richard - are POLY_INT_CST element VECTOR_CST well-formed? It seems they are introduced during vectorization but there they are simple like { POLY_INT_CST [4, 4], ... } but then FRE4 produces Value numbering stmt =3D _48 =3D vect_cst__46 + { 0, 1, 2, ... }; Match-and-simplified vect_cst__46 + { 0, 1, 2, ... } to { POLY_INT_CST [16, 16], POLY_INT_CST [17, 16], POLY_INT_CST [18, 16], ... } and things start to go downhill.=