* [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
2023-12-04 11:45 [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
@ 2023-12-04 14:17 ` jakub at gcc dot gnu.org
2023-12-04 14:26 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-12-04 14:17 UTC (permalink / raw)
To: gcc-bugs
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...
^ permalink raw reply [flat|nested] 13+ messages in thread* [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
2023-12-04 11:45 [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
2023-12-04 14:17 ` [Bug tree-optimization/112843] " jakub at gcc dot gnu.org
@ 2023-12-04 14:26 ` rguenth at gcc dot gnu.org
2023-12-04 14:28 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-12-04 14:26 UTC (permalink / raw)
To: gcc-bugs
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_.
^ permalink raw reply [flat|nested] 13+ messages in thread* [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
2023-12-04 11:45 [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
2023-12-04 14:17 ` [Bug tree-optimization/112843] " jakub at gcc dot gnu.org
2023-12-04 14:26 ` rguenth at gcc dot gnu.org
@ 2023-12-04 14:28 ` rguenth at gcc dot gnu.org
2023-12-04 14:32 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-12-04 14:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [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
2023-12-04 11:45 [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
` (2 preceding siblings ...)
2023-12-04 14:28 ` rguenth at gcc dot gnu.org
@ 2023-12-04 14:32 ` rguenth at gcc dot gnu.org
2023-12-04 16:02 ` amacleod at redhat dot com
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-12-04 14:32 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 13+ messages in thread* [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
2023-12-04 11:45 [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
` (3 preceding siblings ...)
2023-12-04 14:32 ` rguenth at gcc dot gnu.org
@ 2023-12-04 16:02 ` amacleod at redhat dot com
2023-12-04 16:13 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: amacleod at redhat dot com @ 2023-12-04 16:02 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 13+ messages in thread* [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
2023-12-04 11:45 [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
` (4 preceding siblings ...)
2023-12-04 16:02 ` amacleod at redhat dot com
@ 2023-12-04 16:13 ` jakub at gcc dot gnu.org
2023-12-04 16:39 ` amacleod at redhat dot com
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-12-04 16:13 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 13+ messages in thread* [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
2023-12-04 11:45 [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
` (5 preceding siblings ...)
2023-12-04 16:13 ` jakub at gcc dot gnu.org
@ 2023-12-04 16:39 ` amacleod at redhat dot com
2023-12-04 16:57 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: amacleod at redhat dot com @ 2023-12-04 16:39 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 13+ messages in thread* [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
2023-12-04 11:45 [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
` (6 preceding siblings ...)
2023-12-04 16:39 ` amacleod at redhat dot com
@ 2023-12-04 16:57 ` jakub at gcc dot gnu.org
2023-12-04 18:19 ` amacleod at redhat dot com
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-12-04 16:57 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [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
2023-12-04 11:45 [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
` (7 preceding siblings ...)
2023-12-04 16:57 ` jakub at gcc dot gnu.org
@ 2023-12-04 18:19 ` amacleod at redhat dot com
2023-12-05 8:48 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: amacleod at redhat dot com @ 2023-12-04 18:19 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [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
2023-12-04 11:45 [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
` (8 preceding siblings ...)
2023-12-04 18:19 ` amacleod at redhat dot com
@ 2023-12-05 8:48 ` cvs-commit at gcc dot gnu.org
2023-12-06 7:28 ` cvs-commit at gcc dot gnu.org
2023-12-06 7:57 ` rguenth at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-12-05 8:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [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
2023-12-04 11:45 [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
` (9 preceding siblings ...)
2023-12-05 8:48 ` cvs-commit at gcc dot gnu.org
@ 2023-12-06 7:28 ` cvs-commit at gcc dot gnu.org
2023-12-06 7:57 ` rguenth at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-12-06 7:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [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
2023-12-04 11:45 [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
` (10 preceding siblings ...)
2023-12-06 7:28 ` cvs-commit at gcc dot gnu.org
@ 2023-12-06 7:57 ` rguenth at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-12-06 7:57 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread