[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922 --- Comment #13 from Andrew Macleod --- Created attachment 56735 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56735=edit patch (In reply to Sam James from comment #12) > Is the plan to backport to 11/12/13 or to leave it? hmm. I don't think I would apply the same patch (it wouldn't work as is anyway), but if we wanted to fix this in earlier releases we could simply have the custom fold_ranges return false when the precision doesn't match... it would at least avoid most of these traps in earlier releases...? The attached patch for instance would probably apply to GCC 13, 12 and 11.. I can test these if we want to do that...
[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #12 from Sam James --- Is the plan to backport to 11/12/13 or to leave it?
[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Andrew Macleod --- fixed.
[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922 --- Comment #10 from GCC Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:634cf26c94de620e66aa124b8ec4d6c2be4b74b2 commit r14-5973-g634cf26c94de620e66aa124b8ec4d6c2be4b74b2 Author: Andrew MacLeod Date: Tue Nov 28 13:02:35 2023 -0500 Check operands before invoking fold_range. Call check_operands_p before fold_range to make sure it is a valid operation. PR tree-optimization/111922 gcc/ * ipa-cp.cc (ipa_vr_operation_and_type_effects): Check the operands are valid before calling fold_range. gcc/testsuite/ * gcc.dg/pr111922.c: New.
[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922 --- Comment #5 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #4) > > I think > Value_Range vr (operand_type); > if (TREE_CODE_CLASS (operation) == tcc_unary) > ipa_vr_operation_and_type_effects (vr, >src_lats->m_value_range.m_vr, >operation, param_type, >operand_type); > should be avoided if param_type is not a compatible type to operand_type, > unless operation is some cast operation (NOP_EXPR, CONVERT_EXPR, dunno if > the float to integral or vice versa ops as well but vrp probably doesn't > handle that yet). > In the above case, param_type is struct A *, i.e. pointer, while > operand_type is int. the root of the issue is that the precisions are different, and we're invoking an operation which expects the precisions to be the same (minus in this case). we can't deal with this in dispatch because some operations allow the LH and RH to be different precisions or even types. It also seems like overkill to have every operation check the incoming precision, but perhaps not... we could limit it to the wi_fold() subsets.. let me have a look. if we get incompatible types, perhaps returning VARYING should be OK?
[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> Well, in this case the user explicitly told compiler not to do that by not
> using a prototype and syntax which doesn't provide one from the definition.
> It is like using
> int f1 (struct C *x, struct A *y)
> {
> ...
> }
> definition in one TU, and
> int f1 (int, int);
> prototype and
> f1 (0, ~x)
> call in another one + using LTO. What I meant is how to do decide if the
> param_type vs. operand_type mismatch is ok or not.
I vote we do nothing extra for those clowns! Just return VARYING for a range
:-)
it seems like the safest thing to do?
[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #6 from Jakub Jelinek ---
I don't know the IPA code enough to know whether different operand_type vs.
param_type (in the !types_compatible_p sense) means just user bug (in that case
returning VARYING is perfectly fine), or if it can happen also on valid code,
where say caller has one type of argument and callee a different and there is
an implicit (or explicit) cast in between the two. The latter case would be
nice to get handled without giving up.
I mean something like
void
foo (int x)
{
asm volatile ("" : "+r" (x));
}
void
bar (long x)
{
foo (x);
}
void
baz (long x)
{
if (x < -42 || x >= 185)
return;
bar (x);
}
kind of thing (but making sure we don't inline and IPA-VRP tries to propagate
something etc.).
[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #8 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #7)
> Alternatively, if IPA could figure out when things need promoting.. GCC
> must already do it, although I suppose thats in the front ends :-P
Well, in this case the user explicitly told compiler not to do that by not
using a prototype and syntax which doesn't provide one from the definition.
It is like using
int f1 (struct C *x, struct A *y)
{
...
}
definition in one TU, and
int f1 (int, int);
prototype and
f1 (0, ~x)
call in another one + using LTO. What I meant is how to do decide if the
param_type vs. operand_type mismatch is ok or not.
[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922 --- Comment #7 from Andrew Macleod --- Explicit casts would be no problem as they go through the proper machinery. The IL for that case has an explicit cast in it. _1 = (int) x_2(D); foo (_1); its when that cast is not present,and we try to, say subtract two values, that we have a problem. we expect the compiler to promote things to be compatible when they are suppose to be. This would apply to dual operand arithmetic like +, -, /, *, bitwise ops, etc. The testcase in particular is a bitwise not... but it has a return type that is 64 bits and a operand type that is 32. It was expected that the compiler would promote the operand to 64 bits if it expects a 64 bit result. At least for those tree codes which expect compatible types.. I don't think we want to get into overruling decisions at the range-ops level.. So we decide whether to trap (which would be the same result as we see now :-P), or handle it some other way. returning VARYING was my thought.. because it means something is amuck so say we dont know anything. Alternatively, if IPA could figure out when things need promoting.. GCC must already do it, although I suppose thats in the front ends :-P
[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
Jakub Jelinek changed:
What|Removed |Added
CC||amacleod at redhat dot com,
||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Slightly cleaned up:
void f2 (void);
void f4 (int, int, int);
struct A { int a; };
struct B { struct A *b; int c; } v;
static int
f1 (x, y)
struct C *x;
struct A *y;
{
(v.c = v.b->a) || (v.c = v.b->a);
f2 ();
}
static void
f3 (int x, int y)
{
int b = f1 (0, ~x);
f4 (0, 0, v.c);
}
void
f5 (void)
{
f3 (0, 0);
}
The problem is in the f1 call, given it uses the K definition style and the
caller invokes UB by using incompatible types (int vs. pointers), I think
IPA-VRP should punt somewhere on the type mismatch.
I think
Value_Range vr (operand_type);
if (TREE_CODE_CLASS (operation) == tcc_unary)
ipa_vr_operation_and_type_effects (vr,
src_lats->m_value_range.m_vr,
operation, param_type,
operand_type);
should be avoided if param_type is not a compatible type to operand_type,
unless operation is some cast operation (NOP_EXPR, CONVERT_EXPR, dunno if the
float to integral or vice versa ops as well but vrp probably doesn't handle
that yet).
In the above case, param_type is struct A *, i.e. pointer, while operand_type
is int.
[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922 Martin Jambor changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #3 from Martin Jambor --- I'm adding this to the things to look at. But if our bisecting script is correct te ICE has been introduced by r10-3604-g38a734350fd787, so let me CC Aldy as well.
[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.5 Status|UNCONFIRMED |NEW Known to fail||10.1.0 Last reconfirmed||2023-10-22 Ever confirmed|0 |1 Summary|GCC: internal compiler |[11/12/13/14 Regression] |error: in decompose, at |ICE in cp with -O2 |wide-int.h:1049 |-fno-tree-fre Keywords||ice-on-valid-code --- Comment #2 from Andrew Pinski --- Confirmed.
