[Bug tree-optimization/113735] New: ICE: in operator[], at vec.h:910 with _BitInt() at -O and above

[Bug tree-optimization/113735] New: ICE: in operator[], at vec.h:910 with _BitInt() at -O and above

[zsojka at seznam dot cz]

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

            Bug ID: 113735
           Summary: ICE: in operator[], at vec.h:910 with _BitInt() at -O
                    and above
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: x86_64-pc-linux-gnu

Created attachment 57302
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57302&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c
during GIMPLE pass: bitintlower
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: in operator[], at vec.h:910
    4 | foo (_BitInt(6110) j)
      | ^~~
0x8a2ed8 vec<tree_node*, va_gc, vl_embed>::operator[](unsigned int)
        /repo/gcc-trunk/gcc/vec.h:910
0x8a30be vec<equiv_chain*, va_heap, vl_embed>::operator[](unsigned int)
        /repo/gcc-trunk/gcc/value-relation.cc:736
0x8a30be vec<equiv_chain*, va_heap, vl_ptr>::operator[](unsigned int)
        /repo/gcc-trunk/gcc/vec.h:1599
0x8a30be equiv_oracle::add_equiv_to_block(basic_block_def*, bitmap_head*)
        /repo/gcc-trunk/gcc/value-relation.cc:721
0x1868312 equiv_oracle::register_relation(basic_block_def*, relation_kind_t,
tree_node*, tree_node*)
        /repo/gcc-trunk/gcc/value-relation.cc:675
0x2741a67 fold_using_range::range_of_phi(vrange&, gphi*, fur_source&)
        /repo/gcc-trunk/gcc/gimple-range-fold.cc:932
0x27458f0 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
        /repo/gcc-trunk/gcc/gimple-range-fold.cc:604
0x272c929 gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*)
        /repo/gcc-trunk/gcc/gimple-range.cc:265
0x272c929 gimple_ranger::prefill_stmt_dependencies(tree_node*)
        /repo/gcc-trunk/gcc/gimple-range.cc:404
0x272d9ca gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
        /repo/gcc-trunk/gcc/gimple-range.cc:322
0x27315aa gimple_ranger::range_of_expr(vrange&, tree_node*, gimple*)
        /repo/gcc-trunk/gcc/gimple-range.cc:134
0x27077e2 range_to_prec
        /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2008
0x270c7e0 handle_operand_addr
        /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2211
0x270cbe7 lower_muldiv_stmt
        /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:3403
0x2720eb9 gimple_lower_bitint
        /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6575
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8771-20240203001826-g4b7d4d8a4af-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240203 (experimental) (GCC)

[Bug tree-optimization/113735] ICE: in operator[], at vec.h:910 with _BitInt() at -O and above

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> 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 <jakub at gcc dot gnu.org> ---
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  0x00000000011fcb6b in vec<equiv_chain*, va_heap, vl_embed>::operator[]
(this=0x39fb660 = {...}, ix=16) at ../../gcc/vec.h:910
#2  0x00000000011fc4b7 in vec<equiv_chain*, va_heap, vl_ptr>::operator[]
(Python Exception <class 'gdb.error'>: There is no member or method named
m_vecpfx.
this=0x39fc050, ix=16) at ../../gcc/vec.h:1599
#3  0x00000000011f81c4 in equiv_oracle::add_equiv_to_block (this=0x39fbf80,
bb=<basic_block 0x7fffea2dfd80 (16)>, equiv_set=0x3ad29b8) at
../../gcc/value-relation.cc:721
#4  0x00000000011f7f1e in equiv_oracle::register_initial_def (this=0x39fbf80,
ssa=<ssa_name 0x7fffea308240 13>) at ../../gcc/value-relation.cc:643
#5  0x00000000011f8025 in equiv_oracle::register_relation (this=0x39fbf80,
bb=<basic_block 0x7fffea2df960 (7)>, k=VREL_EQ, ssa1=<ssa_name 0x7fffea308360
17>, 
    ssa2=<ssa_name 0x7fffea308240 13>) at ../../gcc/value-relation.cc:675
#6  0x00000000011f98a5 in dom_oracle::register_relation (this=0x39fbf80,
bb=<basic_block 0x7fffea2df960 (7)>, k=VREL_EQ, op1=<ssa_name 0x7fffea308360
17>, 
    op2=<ssa_name 0x7fffea308240 13>) at ../../gcc/value-relation.cc:1111
#7  0x00000000011f96d7 in relation_oracle::register_stmt (this=0x39fbf80,
stmt=<gimple_phi 0x7fffea30ae00>, k=VREL_EQ, op1=<ssa_name 0x7fffea308360 17>, 
    op2=<ssa_name 0x7fffea308240 13>) at ../../gcc/value-relation.cc:1069
#8  0x00000000025fb5fe in fur_depend::register_relation (this=0x7fffffffbcd0,
s=<gimple_phi 0x7fffea30ae00>, k=VREL_EQ, op1=<ssa_name 0x7fffea308360 17>, 
    op2=<ssa_name 0x7fffea308240 13>) at ../../gcc/gimple-range-fold.cc:202
#9  0x00000000025fe3d3 in fold_using_range::range_of_phi (this=0x7fffffffbcff,
r=..., phi=0x7fffea30ae00, src=...) at ../../gcc/gimple-range-fold.cc:932
#10 0x00000000025fcaa8 in fold_using_range::fold_stmt (this=0x7fffffffbcff,
r=..., s=<gimple_phi 0x7fffea30ae00>, src=..., name=<ssa_name 0x7fffea308360
17>)
    at ../../gcc/gimple-range-fold.cc:604
#11 0x00000000025ee502 in gimple_ranger::fold_range_internal (this=0x3b91ca0,
r=..., s=<gimple_phi 0x7fffea30ae00>, name=<ssa_name 0x7fffea308360 17>)
    at ../../gcc/gimple-range.cc:265
#12 0x00000000025eeb24 in gimple_ranger::prefill_stmt_dependencies
(this=0x3b91ca0, ssa=<ssa_name 0x7fffea137f78 4>) at
../../gcc/gimple-range.cc:404
#13 0x00000000025ee7c3 in gimple_ranger::range_of_stmt (this=0x3b91ca0, r=...,
s=<gimple_phi 0x7fffea2dda00>, name=<ssa_name 0x7fffea137f78 4>) at
../../gcc/gimple-range.cc:322
#14 0x00000000025edc52 in gimple_ranger::range_of_expr (this=0x3b91ca0, r=...,
expr=<ssa_name 0x7fffea137f78 4>, stmt=<gimple_assign 0x7fffea306000>)
    at ../../gcc/gimple-range.cc:134
#15 0x00000000025cb0a0 in (anonymous namespace)::range_to_prec (op=<ssa_name
0x7fffea137f78 4>, stmt=<gimple_assign 0x7fffea306000>) at
../../gcc/gimple-lower-bitint.cc:2008
#16 0x00000000025cc539 in (anonymous
namespace)::bitint_large_huge::handle_operand_addr (this=0x7fffffffd560,
op=<ssa_name 0x7fffea137f78 4>, stmt=<gimple_assign 0x7fffea306000>, 
    prec_stored=0x0, prec=0x7fffffffd148) at
../../gcc/gimple-lower-bitint.cc:2211
#17 0x00000000025d3688 in (anonymous
namespace)::bitint_large_huge::lower_muldiv_stmt (this=0x7fffffffd560,
obj=<tree 0x0>, stmt=<gimple_assign 0x7fffea306000>)
    at ../../gcc/gimple-lower-bitint.cc:3403
#18 0x00000000025de784 in (anonymous namespace)::bitint_large_huge::lower_stmt
(this=0x7fffffffd560, stmt=<gimple_assign 0x7fffea306000>) at
../../gcc/gimple-lower-bitint.cc:5439
#19 0x00000000025e4297 in gimple_lower_bitint () at
../../gcc/gimple-lower-bitint.cc:6575
#20 0x00000000025e5719 in (anonymous namespace)::pass_lower_bitint::execute
(this=0x3a10fe0) at ../../gcc/gimple-lower-bitint.cc:6837

[Bug tree-optimization/113735] ICE: in operator[], at vec.h:910 with _BitInt() at -O and above

[aldyh at gcc dot gnu.org]

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

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(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 (&m_chain_obstack,

[Bug tree-optimization/113735] ICE: in operator[], at vec.h:910 with _BitInt() at -O and above

[amacleod at redhat dot com]

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

--- Comment #3 from Andrew Macleod <amacleod at redhat dot com> ---
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

[aldyh at gcc dot gnu.org]

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

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 57335
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57335&action=edit
Proposed patch

Patch in testing.

[Bug tree-optimization/113735] ICE: in operator[], at vec.h:910 with _BitInt() at -O and above

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(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

[aldyh at gcc dot gnu.org]

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

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 57336
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57336&action=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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>:

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

commit r14-8885-gd2d5ef6e22082d945c4d255b44194155680a93bd
Author: Aldy Hernandez <aldyh@redhat.com>
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

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

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

--- Comment #8 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
fixed in trunk