[Bug tree-optimization/112843] New: during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[Bug tree-optimization/112843] New: during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[zsojka at seznam dot cz]

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

            Bug ID: 112843
           Summary: during GIMPLE pass: bitintlower ICE: SIGSEGV in
                    ranger_cache::range_of_expr
                    (gimple-range-cache.cc:1204) with _BitInt() at -O1
           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
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c -wrapper valgrind,-q
==18057== Invalid read of size 8
==18057==    at 0x25641C8: ranger_cache::range_of_expr(vrange&, tree_node*,
gimple*) (gimple-range-cache.cc:1204)
==18057==    by 0x256FDB9: fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&) (gimple-range-fold.cc:671)
==18057==    by 0x25719D2: fold_using_range::fold_stmt(vrange&, gimple*,
fur_source&, tree_node*) (gimple-range-fold.cc:602)
==18057==    by 0x25575CD: gimple_ranger::update_stmt(gimple*)
(gimple-range.cc:564)
==18057==    by 0x16A90C4: update_stmt_operands(function*, gimple*)
(tree-ssa-operands.cc:1150)
==18057==    by 0x113AE26: update_stmt_if_modified (gimple-ssa.h:187)
==18057==    by 0x113AE26: update_stmt_if_modified (gimple-ssa.h:184)
==18057==    by 0x113AE26: update_modified_stmt (gimple-iterator.cc:44)
==18057==    by 0x113AE26: gsi_insert_after(gimple_stmt_iterator*, gimple*,
gsi_iterator_update) (gimple-iterator.cc:544)
==18057==    by 0x254E274: gimple_lower_bitint() (gimple-lower-bitint.cc:6348)
==18057==    by 0x13A3C1A: execute_one_pass(opt_pass*) (passes.cc:2641)
==18057==    by 0x13A44FF: execute_pass_list_1(opt_pass*) (passes.cc:2750)
==18057==    by 0x13A4511: execute_pass_list_1(opt_pass*) (passes.cc:2751)
==18057==    by 0x13A4538: execute_pass_list(function*, opt_pass*)
(passes.cc:2761)
==18057==    by 0xFB1595: expand (cgraphunit.cc:1841)
==18057==    by 0xFB1595: cgraph_node::expand() (cgraphunit.cc:1794)
==18057==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
==18057== 
during GIMPLE pass: bitintlower
testcase.c: In function 'foo':
testcase.c:2:1: internal compiler error: Segmentation fault
    2 | foo (_BitInt (128) x, _BitInt (256) y)
      | ^~~
0x14e51ff crash_signal
        /repo/gcc-trunk/gcc/toplev.cc:316
0x25641c8 ranger_cache::range_of_expr(vrange&, tree_node*, gimple*)
        /repo/gcc-trunk/gcc/gimple-range-cache.cc:1204
0x256fdb9 fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
        /repo/gcc-trunk/gcc/gimple-range-fold.cc:671
0x25719d2 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
        /repo/gcc-trunk/gcc/gimple-range-fold.cc:602
0x25575cd gimple_ranger::update_stmt(gimple*)
        /repo/gcc-trunk/gcc/gimple-range.cc:564
0x16a90c4 update_stmt_operands(function*, gimple*)
        /repo/gcc-trunk/gcc/tree-ssa-operands.cc:1150
0x113ae26 update_stmt_if_modified(gimple*)
        /repo/gcc-trunk/gcc/gimple-ssa.h:187
0x113ae26 update_stmt_if_modified(gimple*)
        /repo/gcc-trunk/gcc/gimple-ssa.h:184
0x113ae26 update_modified_stmt
        /repo/gcc-trunk/gcc/gimple-iterator.cc:44
0x113ae26 gsi_insert_after(gimple_stmt_iterator*, gimple*, gsi_iterator_update)
        /repo/gcc-trunk/gcc/gimple-iterator.cc:544
0x254e274 gimple_lower_bitint
        /repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6348
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-6110-20231204161110-g462ccc3b9d5-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/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
--disable-bootstrap --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-6110-20231204161110-g462ccc3b9d5-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231204 (experimental) (GCC)

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
   Last reconfirmed|                            |2023-12-04
             Status|UNCONFIRMED                 |ASSIGNED

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 56787
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56787&action=edit
gcc14-pr112843.patch

Oops, ranger does some stuff during update_stmt.  Afraid updates of the IL will
be quite hard with that...

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
what?!  Ick.  It definitely shouldn't re-fold anything but only scrap caches
_at most_.

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> what?!  Ick.  It definitely shouldn't re-fold anything but only scrap caches
> _at most_.

So it does

  // Only update if it already had a value.
  if (m_cache.get_global_range (r, lhs))
    {
      // Re-calculate a new value using just cache values.
      Value_Range tmp (TREE_TYPE (lhs));
      fold_using_range f;
      fur_stmt src (s, &m_cache);
      f.fold_stmt (tmp, s, src, lhs);

      // Combine the new value with the old value to check for a change.
      if (r.intersect (tmp))
        {
          if (dump_file && (dump_flags & TDF_DETAILS))
            {
              print_generic_expr (dump_file, lhs, TDF_SLIM);
              fprintf (dump_file, " : global value re-evaluated to ");
              r.dump (dump_file);
              fputc ('\n', dump_file);
            }
          m_cache.set_global_range (lhs, r);

WTF?  If a pass invalidates a range it needs to properly do this itself.
But update_stmt itself _never_ should alter range info.

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> (In reply to Richard Biener from comment #2)
> > what?!  Ick.  It definitely shouldn't re-fold anything but only scrap caches
> > _at most_.
> 
> So it does
> 
>   // Only update if it already had a value.
>   if (m_cache.get_global_range (r, lhs))
>     {
>       // Re-calculate a new value using just cache values.
>       Value_Range tmp (TREE_TYPE (lhs));
>       fold_using_range f;
>       fur_stmt src (s, &m_cache);
>       f.fold_stmt (tmp, s, src, lhs);
> 
>       // Combine the new value with the old value to check for a change.
>       if (r.intersect (tmp))
>         {
>           if (dump_file && (dump_flags & TDF_DETAILS))
>             {
>               print_generic_expr (dump_file, lhs, TDF_SLIM);
>               fprintf (dump_file, " : global value re-evaluated to ");
>               r.dump (dump_file);
>               fputc ('\n', dump_file);
>             }
>           m_cache.set_global_range (lhs, r);
> 
> WTF?  If a pass invalidates a range it needs to properly do this itself.
> But update_stmt itself _never_ should alter range info.

At least the testcase that was added with it still passes when I remove
the call to get_range_query (fn)->update_stmt

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[amacleod at redhat dot com]

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

--- Comment #5 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Richard Biener from comment #3)
> (In reply to Richard Biener from comment #2)
> > what?!  Ick.  It definitely shouldn't re-fold anything but only scrap caches
> > _at most_.
> 
> So it does
> 
>   // Only update if it already had a value.
>   if (m_cache.get_global_range (r, lhs))
>     {
>       // Re-calculate a new value using just cache values.
>       Value_Range tmp (TREE_TYPE (lhs));
>       fold_using_range f;
>       fur_stmt src (s, &m_cache);
>       f.fold_stmt (tmp, s, src, lhs);
> 
>       // Combine the new value with the old value to check for a change.
>       if (r.intersect (tmp))
>         {
>           if (dump_file && (dump_flags & TDF_DETAILS))
>             {
>               print_generic_expr (dump_file, lhs, TDF_SLIM);
>               fprintf (dump_file, " : global value re-evaluated to ");
>               r.dump (dump_file);
>               fputc ('\n', dump_file);
>             }
>           m_cache.set_global_range (lhs, r);
> 
> WTF?  If a pass invalidates a range it needs to properly do this itself.
> But update_stmt itself _never_ should alter range info.

what do you mean?  when a statement is changed, it may generate a different
range than it did before, so we re-evaluate the statement to see if the result
is different.  If it is, then we update it in the cache.

All its doing is re-calculating and updating the cache values.

It looks to me like the problem is the stmt is being added in a way that leaves
the IL in an illegal state,

                    tree lhs2 = make_ssa_name (type);
                    gimple *g = gimple_build_assign (lhs, NOP_EXPR, lhs2);
                    if (stmt_ends_bb_p (stmt))
                      {
                        edge e = find_fallthru_edge (gsi_bb (gsi)->succs);
                        gsi_insert_on_edge_immediate (e, g);
                      }
                    else
                      gsi_insert_after (&gsi, g, GSI_SAME_STMT);
                    gimple_set_lhs (stmt, lhs2);

(gdb) p print_generic_expr (stderr, lhs, 0)
_1$3 = void
(gdb) p print_generic_expr (stderr, lhs2, 0)
_12$4 = void
(gdb) p print_gimple_stmt (stderr, stmt, 0, 0)
_1 = x_4(D) * 5;
$5 = void
(gdb) p print_gimple_stmt (stderr, g, 0, 0)
_1 = (_BitInt(128)) _12;
$6 = void

So we have 
_1 = x_4(D) * 5;
then we create 
_1 = (_BitInt(128)) _12;
And add it to the IL...  and finally change the original stmt to 
_12 = x_4(D) * 5

how is that right?  _1 is now a different type?  but regardless, we have 2
statements with _1 as a LHS for a brief time.

And rangers real complaint is that we have a range for _1, but its being
updated by a stmt which is not actually in the IL yet during this update.. so
it is finding no basic block info for an SSA name which is thinks its knows
something about already because it WAS in the IL.

It also does not seem correct to me that you can take an existing SSA_NAME and
change its type on the fly while its still being used in the IL?   Once we
create an ssa name, I thought it was immutable from a type point of view untl
deleted and reused?

(gdb) p print_generic_expr (stderr, lhs->typed.type, 0)
_BitInt(128)$7 = void
(gdb) p print_generic_expr (stderr, lhs2->typed.type, 0)
int128_t$8 = void

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #5)
> what do you mean?  when a statement is changed, it may generate a different
> range than it did before,

No, that would be a bug.  If some IL changes need to extend existing range,
then
reset_flow_sensitive_info needs to be called for the SSA_NAME.

> so we re-evaluate the statement to see if the
> result is different.  If it is, then we update it in the cache.
> 
> All its doing is re-calculating and updating the cache values.
> 
> It looks to me like the problem is the stmt is being added in a way that
> leaves the IL in an illegal state,

But unfortunately that is pretty much unavoidable in changes like this.
So, I have
  lhs1 = some_stmt;
and want to change it to
  lhs2 = some_stmt;
  lhs1 = (lhs_type) lhs2;
(where lhs2 has a different type from lhs).
The options to do that are either what the code does right now, i.e.
first create lhs1 = (lhs_type) lhs2; stmt, add it after lhs1 = some_stmt;
(including update_stmt), then gimple_set_lhs on the first stmt to lhs2, then
update_stmt on the first stmt, but this is temporarily invalid IL, because two
different stmts in the IL have the same lhs, or as changed in the patch
gimple_set_lhs on the first stmt to lhs2 (but no update_stmt), create the
second stmt, add it including update_stmt, then update_stmt on the first one;
this is also invalid IL, the effects of update_stmt haven't been done until the
second update_stmt; or gimple_set_lhs and update_stmt on the first one (but
then lhs1 has no definition and we insert a stmt into the IL without the
definition, so again temporarily invalid IL).

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[amacleod at redhat dot com]

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

--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Andrew Macleod from comment #5)
> > what do you mean?  when a statement is changed, it may generate a different
> > range than it did before,
> 
> No, that would be a bug.  If some IL changes need to extend existing range,
> then
> reset_flow_sensitive_info needs to be called for the SSA_NAME.

Not from rangers point of view.  You may change 
_1 = _2 + 5
to
_1 = _6 + 5  
and it finds it has a better understanding of the range of _6, and so it can
further refine the range for _1 based on that.    So it merely checks to see if
the changes to the statement means it can understand it better.  In particular: 
  const char *lossage = _result ? "constant string" : 0;

  if (__builtin_expect (lossage != ((void *)0) , 0))
    {
    unsigned __message_length = __builtin_strlen (lossage);
    if (! __builtin_constant_p (__message_length))
      dead ();
    }

This provides an IL update which happens later in compilation when
builtin_expect gives us a rbetter result which gives us a much better range and
can then fold away the call to dead()


> 
> > so we re-evaluate the statement to see if the
> > result is different.  If it is, then we update it in the cache.
> > 
> > All its doing is re-calculating and updating the cache values.
> > 
> > It looks to me like the problem is the stmt is being added in a way that
> > leaves the IL in an illegal state,
> 
> But unfortunately that is pretty much unavoidable in changes like this.
> So, I have
>   lhs1 = some_stmt;
> and want to change it to
>   lhs2 = some_stmt;
>   lhs1 = (lhs_type) lhs2;
> (where lhs2 has a different type from lhs).
> The options to do that are either what the code does right now, i.e.
> first create lhs1 = (lhs_type) lhs2; stmt, add it after lhs1 = some_stmt;
> (including update_stmt), then gimple_set_lhs on the first stmt to lhs2, then
> update_stmt on the first stmt, but this is temporarily invalid IL, because
> two different stmts in the IL have the same lhs, or as changed in the patch
> gimple_set_lhs on the first stmt to lhs2 (but no update_stmt), create the
> second stmt, add it including update_stmt, then update_stmt on the first
> one; this is also invalid IL, the effects of update_stmt haven't been done
> until the second update_stmt; or gimple_set_lhs and update_stmt on the first
> one (but then lhs1 has no definition and we insert a stmt into the IL
> without the definition, so again temporarily invalid IL).

Im still confused tho.

So what I think you are doing is taking
lhs1 = some_stmt
and rewriting it to a different type, and it looks like looping thru the
operands so that some_stmt is consuming the right types too..  so the type of
some_stmt is changing from lhs1_type to lhs2_type.  adn then we create  a new
stmt for lhs1.

to avoid lying why dont we just create a new stmt  'g' before stmt 
lhs2 = some_stmt
with the operands converted and then when that is done, simply update stmt
lhs1 = (lhs1_type) lhs2

the the IL is never in an invalid state?

Otherwise if we are going to have invalid IL states, we have to turn off any
automatic updating...   you could possible just save all the update/sets until
the end.. that might work.    The biggest issue would be that lhs1 was in the
IL so ranger expects the block to be set for its def stmt and it is being added
via a new stmt whic is not in the IL yet when the update happens...     its
expects gimple_bb to be set for a DEF that it has seen.


Isn't the "normal" way to do this to leave
lhs1 = some_stmt
and then add
lhs2 = (lhs2_type) lhs1
and  follow immeidate uses and change all the occurences of lhs1 to lhs2?

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Well, refining a range should be ok and I thought one would just flush caches
somewheres, so that next time it can be computed in more detail.
But, some local changes could be just temporary state until more code is
updated and that will be necessarily in some inconsistent state.
Anyway, I'm going to test my patch anyway because after thinking it through I
think such updating is the least worse of those 3 options for the update in
particular.

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[amacleod at redhat dot com]

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

--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> ---
Created attachment 56790
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56790&action=edit
auxially patch to avid the trap

refining a range is fine...  the only issue we are really running into here
that is causing the trap is that the "update" on the original LHS DEF is a new
stmt which hasnt been added to the IL yet, so ranger is trapping when it asks
for the basic block of the def stmt.. It had one before, it expects it to still
have one when it looks at the context of the stmt to update the range.

Now that said, the update issue is primarily within the cache.  if we are
updating and the BB isn't set, we could simply just pick up the global value. 
Patch is attached, and pre-approved if you want to use it.

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:1a84af19cd18730477dbceaebc45466c3fd77b60

commit r14-6138-g1a84af19cd18730477dbceaebc45466c3fd77b60
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Dec 5 09:45:40 2023 +0100

    lower-bitint: Make temporarily wrong IL less wrong [PR112843]

    As discussed in the PR, for the middle (on x86-64 65..128 bit) _BitInt
    types like
      _1 = x_4(D) * 5;
    where _1 and x_4(D) have _BitInt(128) type and x is PARM_DECL, the bitint
    lowering pass wants to replace this with
      _13 = (int128_t) x_4(D);
      _12 = _13 * 5;
      _1 = (_BitInt(128)) _12;
    where _13 and _12 have int128_t type and the ranger ICEs when the IL is
    temporarily invalid:
    during GIMPLE pass: bitintlower
    pr112843.c: In function âfooâ:
    pr112843.c:7:1: internal compiler error: Segmentation fault
        7 | foo (_BitInt (128) x, _BitInt (256) y)
          | ^~~
    0x152943f crash_signal
            ../../gcc/toplev.cc:316
    0x25c21c8 ranger_cache::range_of_expr(vrange&, tree_node*, gimple*)
            ../../gcc/gimple-range-cache.cc:1204
    0x25cdcf9 fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
            ../../gcc/gimple-range-fold.cc:671
    0x25cf9a0 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
            ../../gcc/gimple-range-fold.cc:602
    0x25b5520 gimple_ranger::update_stmt(gimple*)
            ../../gcc/gimple-range.cc:564
    0x16f1234 update_stmt_operands(function*, gimple*)
            ../../gcc/tree-ssa-operands.cc:1150
    0x117a5b6 update_stmt_if_modified(gimple*)
            ../../gcc/gimple-ssa.h:187
    0x117a5b6 update_stmt_if_modified(gimple*)
            ../../gcc/gimple-ssa.h:184
    0x117a5b6 update_modified_stmt
            ../../gcc/gimple-iterator.cc:44
    0x117a5b6 gsi_insert_after(gimple_stmt_iterator*, gimple*,
gsi_iterator_update)
            ../../gcc/gimple-iterator.cc:544
    0x25abc2f gimple_lower_bitint
            ../../gcc/gimple-lower-bitint.cc:6348

    What the code does right now is, it first creates a new SSA_NAME (_12
    above), adds the
      _1 = (_BitInt(128)) _12;
    stmt after it (where it crashes, because _12 has no SSA_NAME_DEF_STMT yet),
    then sets lhs of the previous stmt to _12 (this is also temporarily
    incorrect, there are incompatible types involved in the stmt), later on
    changes also operands and finally update_stmt it.

    The following patch instead changes the lhs of the stmt before adding the
    cast after it.  The question is if this is less or more wrong temporarily
    (but the ICE is gone).  In addition to that the patch moves the operand
    adjustments before the lhs adjustment.

    The reason I tweaked the lhs first is that it then just uses gimple_op and
    iterates over all ops, if that is done before lhs it would need to special
    case which op to skip because it is lhs (I'm using gimple_get_lhs for the
    lhs, but this isn't done for GIMPLE_CALL nor GIMPLE_PHI, so GIMPLE_ASSIGN
    or say GIMPLE_GOTO etc. are the only options).

    2023-12-05  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/112843
            * gimple-lower-bitint.cc (gimple_lower_bitint): Change lhs of stmt
            to lhs2 before building and inserting lhs = (cast) lhs2;
assignment.
            Adjust stmt operands before adjusting lhs.

            * gcc.dg/bitint-47.c: New test.

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:52f8092f54cf338c19d44e06b35612d15c96faf4

commit r14-6206-g52f8092f54cf338c19d44e06b35612d15c96faf4
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Dec 5 09:21:35 2023 +0100

    tree-optimization/112843 - update_stmt doing wrong things

    The following removes range_query::update_stmt and its single
    invocation from update_stmt_operands.  That function is not
    supposed to look beyond the raw stmt contents of the passed
    stmt since there's no guarantee about the rest of the IL.

            PR tree-optimization/112843
            * tree-ssa-operands.cc (update_stmt_operands): Do not call
            update_stmt from ranger.
            * value-query.h (range_query::update_stmt): Remove.
            * gimple-range.h (gimple_ranger::update_stmt): Likewise.
            * gimple-range.cc (gimple_ranger::update_stmt): Likewise.

[Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.