[Bug c/111922] New: GCC: internal compiler error: in decompose, at wide-int.h:1049

[Bug c/111922] New: GCC: internal compiler error: in decompose, at wide-int.h:1049

[141242068 at smail dot nju.edu.cn]

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

            Bug ID: 111922
           Summary: GCC: internal compiler error: in decompose, at
                    wide-int.h:1049
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

Compiler Explorer:
[https://gcc.godbolt.org/z/EoPGKa9r8](https://gcc.godbolt.org/z/EoPGKa9r8)

The code that triggers the crash is somewhat extensive. I've attempted to
minimize it, but the underlying cause seems to be complex. Here's the code:

```c
void f2(void);
struct T1 { int w; };
struct T2 { struct T1 *wi; int a; } v;

static int f1(dpy, wi)
    struct T3 *dpy;
    struct T1 *wi;
{
  (v.a = v.wi->w) || (v.a = v.wi->w);
  f2();
}

static void f3(int wi, int c) {
  int b = f1(0, ~wi);
  fn4(0, 0, v.a);
}

void f5() { f3(0, 0); }
```

Compiling this program with `-O2 -fno-tree-fre` causes GCC to crash.

Some interesting observations about this crash:
1. The crash only occurs when the function `f1` is declared using the old-style
function declaration. If it is converted to the modern style, the crash doesn't
occur.
2. If any statement in the code is commented out, even if it's just half of the
logic or expression inside `f1`, the crash disappears.

The full stack dump:
```
<source>: In function 'f3':
<source>:15:3: warning: implicit declaration of function 'fn4'
[-Wimplicit-function-declaration]
   15 |   fn4(0, 0, v.a);
      |   ^~~
during IPA pass: cp
<source>: At top level:
<source>:18:1: internal compiler error: in decompose, at wide-int.h:1049
   18 | void f5() { f3(0, 0); }
      | ^~~~
0x231f49e internal_error(char const*, ...)
        ???:0
0xa00958 fancy_abort(char const*, int, char const*)
        ???:0
0x103701e range_operator::wi_fold_in_parts(irange&, tree_node*,
generic_wide_int<wide_int_storage> const&, generic_wide_int<wide_int_storage>
const&, generic_wide_int<wide_int_storage> const&,
generic_wide_int<wide_int_storage> const&) const
        ???:0
0x1037b64 range_operator::fold_range(irange&, tree_node*, irange const&, irange
const&, relation_trio) const
        ???:0
0x1023768 operator_bitwise_not::fold_range(irange&, tree_node*, irange const&,
irange const&, relation_trio) const
        ???:0
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.
```

[Bug c/111922] GCC: internal compiler error: in decompose, at wide-int.h:1049

[141242068 at smail dot nju.edu.cn]

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

--- Comment #1 from wierton <141242068 at smail dot nju.edu.cn> ---
Compiler Explorer: https://gcc.godbolt.org/z/EoPGKa9r8

The link above seems broken.

[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> 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 <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre

[jamborm at gcc dot gnu.org]

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

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org

--- Comment #3 from Martin Jambor <jamborm at gcc dot gnu.org> ---
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

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com,
                   |                            |jakub at gcc dot gnu.org

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

[amacleod at redhat dot com]

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

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

[jakub at gcc dot gnu.org]

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

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

[amacleod at redhat dot com]

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

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

[jakub at gcc dot gnu.org]

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

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

[amacleod at redhat dot com]

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

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

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:634cf26c94de620e66aa124b8ec4d6c2be4b74b2

commit r14-5973-g634cf26c94de620e66aa124b8ec4d6c2be4b74b2
Author: Andrew MacLeod <amacleod@redhat.com>
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

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

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

--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> ---
fixed.

[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sjames at gcc dot gnu.org

--- Comment #12 from Sam James <sjames at gcc dot gnu.org> ---
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

[amacleod at redhat dot com]

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

--- Comment #13 from Andrew Macleod <amacleod at redhat dot com> ---
Created attachment 56735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56735&action=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...