[Bug tree-optimization/113735] ICE: in operator[], at vec.h:910 with _BitInt() at -O and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Aldy Hernandez --- fixed in trunk
[Bug tree-optimization/113735] ICE: in operator[], at vec.h:910 with _BitInt() at -O and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735 --- Comment #7 from GCC Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:d2d5ef6e22082d945c4d255b44194155680a93bd commit r14-8885-gd2d5ef6e22082d945c4d255b44194155680a93bd Author: Aldy Hernandez Date: Tue Feb 6 10:22:30 2024 +0100 ranger: Grow BBs in relation oracle as needed [PR113735] The relation oracle grows the internal vector of SSAs as needed, but due to an oversight was not growing the basic block vector. This fixes the oversight. PR tree-optimization/113735 gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr113735.c: New test. gcc/ChangeLog: * value-relation.cc (equiv_oracle::add_equiv_to_block): Call limit_check().
[Bug tree-optimization/113735] ICE: in operator[], at vec.h:910 with _BitInt() at -O and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735 --- Comment #6 from Aldy Hernandez --- Created attachment 57336 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57336=edit Proposed patch #2 Thanks for the suggestion Jakub.
[Bug tree-optimization/113735] ICE: in operator[], at vec.h:910 with _BitInt() at -O and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
--- Comment #5 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #4)
> Created attachment 57335 [details]
> Proposed patch
>
> Patch in testing.
The testcase should at least use /* { dg-do compile { target bitint } } */
and ideally have the foo function wrapped in #if __BITINT_MAXWIDTH__ >= 6110
and #endif.
[Bug tree-optimization/113735] ICE: in operator[], at vec.h:910 with _BitInt() at -O and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735 --- Comment #4 from Aldy Hernandez --- Created attachment 57335 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57335=edit Proposed patch Patch in testing.
[Bug tree-optimization/113735] ICE: in operator[], at vec.h:910 with _BitInt() at -O and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735 --- Comment #3 from Andrew Macleod --- Seems reasonable to me, adding BBS should be fine throughout. just don't re-order them :-)
[Bug tree-optimization/113735] ICE: in operator[], at vec.h:910 with _BitInt() at -O and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
--- Comment #2 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #1)
> Slightly tweaked, still -O1:
> char b;
> void bar (void);
>
> void
> foo (_BitInt(6110) j)
> {
> for (;;)
> {
> _BitInt(10) k = b % j;
> for (j = 6; j; --j)
> if (k)
> bar ();
> }
> }
>
> The ICE is in on:
> 721 if (!m_equiv[bb->index])
> because bb->index is larger than m_equiv size.
> The bitint lowering pass works by walking the IL and replacing some
> statements in there with lowered code, which can involve new basic blocks
> (either through splitting existing blocks or creating fresh new ones) and
> the like. And asks the ranger about range of statements during that.
> Is that something that ranger doesn't/can't support?
> So, would I need to ensure to find out what ranges I'll need before making
> any changes,
> ask for them, remember them somewhere on the side and then use them during
> the transformations?
We're generally OK with changing IL, if the semantic of the statement doesn't
change. For example, you couldn't change the meaning of a statement to mean
something totally different, as that would invalidate the cached value of the
resulting SSA. The cache was tweaked in the last release or so to handle
growing SSA names.
I'm not totally sure on changing BBs, as VRP didn't add BB's in flight, IIRC.
But I do see code in the relation oracle handling a change in the BB count:
void
equiv_oracle::limit_check (basic_block bb)
{
int i = (bb) ? bb->index : last_basic_block_for_fn (cfun);
if (i >= (int)m_equiv.length ())
m_equiv.safe_grow_cleared (last_basic_block_for_fn (cfun) + 1);
}
Interestingly, this function is never used.
Andrew, was this an oversight?
The attached patch seems to fix the problem, and it looks like all other
dereferences of m_equiv[] have a suitable check, or are looking for things
already known to have an entry.Andrew would know for sure.
diff --git a/gcc/value-relation.cc b/gcc/value-relation.cc
index 27f9ad61c0e..619ee5f0867 100644
--- a/gcc/value-relation.cc
+++ b/gcc/value-relation.cc
@@ -718,6 +718,7 @@ equiv_oracle::add_equiv_to_block (basic_block bb, bitmap
equiv_set)
// Check if this is the first time a block has an equivalence added.
// and create a header block. And set the summary for this block.
+ limit_check (bb);
if (!m_equiv[bb->index])
{
ptr = (equiv_chain *) obstack_alloc (_chain_obstack,
[Bug tree-optimization/113735] ICE: in operator[], at vec.h:910 with _BitInt() at -O and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2024-02-03
Status|UNCONFIRMED |NEW
CC||aldyh at gcc dot gnu.org,
||amacleod at redhat dot com
--- Comment #1 from Jakub Jelinek ---
Slightly tweaked, still -O1:
char b;
void bar (void);
void
foo (_BitInt(6110) j)
{
for (;;)
{
_BitInt(10) k = b % j;
for (j = 6; j; --j)
if (k)
bar ();
}
}
The ICE is in on:
721 if (!m_equiv[bb->index])
because bb->index is larger than m_equiv size.
The bitint lowering pass works by walking the IL and replacing some statements
in there with lowered code, which can involve new basic blocks (either through
splitting existing blocks or creating fresh new ones) and the like. And asks
the ranger about range of statements during that.
Is that something that ranger doesn't/can't support?
So, would I need to ensure to find out what ranges I'll need before making any
changes,
ask for them, remember them somewhere on the side and then use them during the
transformations?
#0 fancy_abort (file=0x2c76d8a "../../gcc/vec.h", line=910, function=0x2c76d7f
"operator[]") at ../../gcc/diagnostic.cc:2313
#1 0x011fcb6b in vec::operator[]
(this=0x39fb660 = {...}, ix=16) at ../../gcc/vec.h:910
#2 0x011fc4b7 in vec::operator[]
(Python Exception : There is no member or method named
m_vecpfx.
this=0x39fc050, ix=16) at ../../gcc/vec.h:1599
#3 0x011f81c4 in equiv_oracle::add_equiv_to_block (this=0x39fbf80,
bb=, equiv_set=0x3ad29b8) at
../../gcc/value-relation.cc:721
#4 0x011f7f1e in equiv_oracle::register_initial_def (this=0x39fbf80,
ssa=) at ../../gcc/value-relation.cc:643
#5 0x011f8025 in equiv_oracle::register_relation (this=0x39fbf80,
bb=, k=VREL_EQ, ssa1=,
ssa2=) at ../../gcc/value-relation.cc:675
#6 0x011f98a5 in dom_oracle::register_relation (this=0x39fbf80,
bb=, k=VREL_EQ, op1=,
op2=) at ../../gcc/value-relation.cc:
#7 0x011f96d7 in relation_oracle::register_stmt (this=0x39fbf80,
stmt=, k=VREL_EQ, op1=,
op2=) at ../../gcc/value-relation.cc:1069
#8 0x025fb5fe in fur_depend::register_relation (this=0x7fffbcd0,
s=, k=VREL_EQ, op1=,
op2=) at ../../gcc/gimple-range-fold.cc:202
#9 0x025fe3d3 in fold_using_range::range_of_phi (this=0x7fffbcff,
r=..., phi=0x7fffea30ae00, src=...) at ../../gcc/gimple-range-fold.cc:932
#10 0x025fcaa8 in fold_using_range::fold_stmt (this=0x7fffbcff,
r=..., s=, src=..., name=)
at ../../gcc/gimple-range-fold.cc:604
#11 0x025ee502 in gimple_ranger::fold_range_internal (this=0x3b91ca0,
r=..., s=, name=)
at ../../gcc/gimple-range.cc:265
#12 0x025eeb24 in gimple_ranger::prefill_stmt_dependencies
(this=0x3b91ca0, ssa=) at
../../gcc/gimple-range.cc:404
#13 0x025ee7c3 in gimple_ranger::range_of_stmt (this=0x3b91ca0, r=...,
s=, name=) at
../../gcc/gimple-range.cc:322
#14 0x025edc52 in gimple_ranger::range_of_expr (this=0x3b91ca0, r=...,
expr=, stmt=)
at ../../gcc/gimple-range.cc:134
#15 0x025cb0a0 in (anonymous namespace)::range_to_prec (op=, stmt=) at
../../gcc/gimple-lower-bitint.cc:2008
#16 0x025cc539 in (anonymous
namespace)::bitint_large_huge::handle_operand_addr (this=0x7fffd560,
op=, stmt=,
prec_stored=0x0, prec=0x7fffd148) at
../../gcc/gimple-lower-bitint.cc:2211
#17 0x025d3688 in (anonymous
namespace)::bitint_large_huge::lower_muldiv_stmt (this=0x7fffd560,
obj=, stmt=)
at ../../gcc/gimple-lower-bitint.cc:3403
#18 0x025de784 in (anonymous namespace)::bitint_large_huge::lower_stmt
(this=0x7fffd560, stmt=) at
../../gcc/gimple-lower-bitint.cc:5439
#19 0x025e4297 in gimple_lower_bitint () at
../../gcc/gimple-lower-bitint.cc:6575
#20 0x025e5719 in (anonymous namespace)::pass_lower_bitint::execute
(this=0x3a10fe0) at ../../gcc/gimple-lower-bitint.cc:6837
