https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98726
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Eh, we can't even _dump_ those VECTOR_CST:
#0 internal_error (gmsgid=0x29cb490 "tree check: %s, have %s in %s, at %s:%d")
at ../../src/trunk/gcc/diagnostic.c:1804
#1 0x00000000017d00ea in tree_check_failed (
node=<poly_int_cst 0x7ffff6f25300>,
file=0x2858ad0 "../../src/trunk/gcc/tree.h", line=5984,
function=0x285fe70 <wi::to_wide(tree_node const*)::__FUNCTION__> "to_wide")
at ../../src/trunk/gcc/tree.c:9812
#2 0x0000000000ad994d in tree_check (__t=<poly_int_cst 0x7ffff6f25300>,
__f=0x2858ad0 "../../src/trunk/gcc/tree.h", __l=5984,
__g=0x285fe70 <wi::to_wide(tree_node const*)::__FUNCTION__> "to_wide",
__c=INTEGER_CST) at ../../src/trunk/gcc/tree.h:3594
#3 0x0000000000b56c27 in wi::to_wide (t=<poly_int_cst 0x7ffff6f25300>)
at ../../src/trunk/gcc/tree.h:5984
#4 0x00000000017d75b2 in vector_cst_int_elt (t=<vector_cst 0x7ffff6f2e050>,
i=3) at ../../src/trunk/gcc/tree.c:11104
#5 0x00000000017d7798 in vector_cst_elt (t=<vector_cst 0x7ffff6f2e050>, i=3)
at ../../src/trunk/gcc/tree.c:11131
#6 0x00000000014e0e2c in dump_generic_node (pp=0x3754e00,
node=<vector_cst 0x7ffff6f2e050>, spc=0, flags=2112, is_stmt=false)
at ../../src/trunk/gcc/tree-pretty-print.c:2112
11101 /* Otherwise work out the value from the last two encoded elements.
*/
11102 tree v1 = VECTOR_CST_ENCODED_ELT (t, final_i - npatterns);
11103 tree v2 = VECTOR_CST_ENCODED_ELT (t, final_i);
11104 wide_int diff = wi::to_wide (v2) - wi::to_wide (v1);
(gdb) p v1
$5 = <poly_int_cst 0x7ffff6f25300>
(gdb) p v2
$6 = <poly_int_cst 0x7ffff6f25320>
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=0x28dd290 "../../src/trunk/gcc/rtl.h", line=2296,
function=0x28e84a0 <wi::int_traits<std::pair<rtx_def*, machine_mode>
>::decompose(long*, unsigned int, std::pair<rtx_def*, machine_mode>
const&)::__FUNCTION__> "decompose") at ../../src/trunk/gcc/diagnostic.c:1884
#1 0x0000000000e17546 in wi::int_traits<std::pair<rtx_def*, machine_mode>
>::decompose (precision=32, x=...) at ../../src/trunk/gcc/rtl.h:2296
#2 0x0000000000e45617 in wide_int_ref_storage<false,
false>::wide_int_ref_storage<std::pair<rtx_def*, machine_mode> >
(this=0x7fffffffc5a0, x=...,
precision=32) at ../../src/trunk/gcc/wide-int.h:1034
#3 0x0000000000e427e7 in generic_wide_int<wide_int_ref_storage<false, false>
>::generic_wide_int<std::pair<rtx_def*, machine_mode> > (this=0x7fffffffc5a0,
x=..., precision=32) at ../../src/trunk/gcc/wide-int.h:790
#4 0x0000000000e405be in wi::sub<std::pair<rtx_def*, machine_mode>,
std::pair<rtx_def*, machine_mode> > (x=..., y=...) at
../../src/trunk/gcc/wide-int.h:2512
#5 0x000000000132743f in rtx_vector_builder::step (this=0x7fffffffc7a0,
elt1=0x7ffff6f2f0c0, elt2=0x7ffff6f2f0e0)
at ../../src/trunk/gcc/rtx-vector-builder.h:122
#6 0x000000000132795e in vector_builder<rtx_def*, machine_mode,
rtx_vector_builder>::elt (this=0x7fffffffc7a0, i=3)
at ../../src/trunk/gcc/vector-builder.h:254
#7 0x0000000001327051 in rtx_vector_builder::build (this=0x7fffffffc7a0)
at ../../src/trunk/gcc/rtx-vector-builder.c:73
#8 0x0000000000eb109a in const_vector_from_tree (
exp=<vector_cst 0x7ffff6f2e078>) 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 = _48 = 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.
