[Bug tree-optimization/97378] New: [11 Regression] ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 sincer11-3685-gfcae5121154d1c33

[Bug tree-optimization/97378] New: [11 Regression] ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 sincer11-3685-gfcae5121154d1c33

[marxin at gcc dot gnu.org]

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

            Bug ID: 97378
           Summary: [11 Regression] ICE in tree check: expected class
                    ‘type’, have ‘exceptional’ (error_mark) in
                    useless_type_conversion_p, at gimple-expr.c:87
                    sincer11-3685-gfcae5121154d1c33
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ cat acc-branch.f90
program openacc_clause_validity
  real(8) :: a(256)
  do i = 1, N
    return
  end do
  do i = 1, N
    if(i == N-1) THEN
    end if
  end do
  do i = 1, N
  end do
end program openacc_clause_validity

$ gfortran acc-branch.f90 -fno-tree-forwprop -ftree-vrp -O
during GIMPLE pass: evrp
acc-branch.f90:12:0:

   12 | end program openacc_clause_validity
      | 
internal compiler error: tree check: expected class ‘type’, have ‘exceptional’
(error_mark) in useless_type_conversion_p, at gimple-expr.c:87
0x739d90 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
        /home/marxin/Programming/gcc/gcc/tree.c:9779
0x67650f tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
        /home/marxin/Programming/gcc/gcc/tree.h:3426
0x67650f useless_type_conversion_p(tree_node*, tree_node*)
        /home/marxin/Programming/gcc/gcc/gimple-expr.c:87
0xe676f4 verify_gimple_assign_binary
        /home/marxin/Programming/gcc/gcc/tree-cfg.c:4147
0xe78301 verify_gimple_in_cfg(function*, bool)
        /home/marxin/Programming/gcc/gcc/tree-cfg.c:5418
0xd5e50f execute_function_todo
        /home/marxin/Programming/gcc/gcc/passes.c:1992
0xd5f35c do_per_function
        /home/marxin/Programming/gcc/gcc/passes.c:1640
0xd5f35c execute_todo
        /home/marxin/Programming/gcc/gcc/passes.c:2046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug tree-optimization/97378] [11 Regression] ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 sincer11-3685-gfcae5121154d1c33

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |amacleod at redhat dot com
   Last reconfirmed|                            |2020-10-12
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

[Bug tree-optimization/97378] [11 Regression] ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 since r11-3685-gfcae5121154d1c33

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcb314 at hotmail dot com

--- Comment #1 from David Binderman <dcb314 at hotmail dot com> ---
I have similar for the following C code:

int a, b, c;
void d() {
e : {
  long f;
  long *g = &f;
  if ((a != 0) - (b = 0))
    ;
  else
    a &= (*g %= a *= c) >= (*g || f);
  goto e;
}
}

Compiler flag -O2.

[Bug tree-optimization/97378] [11 Regression] ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 since r11-3685-gfcae5121154d1c33

[aldyh at gcc dot gnu.org]

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

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to David Binderman from comment #1)
> I have similar for the following C code:
> 
> int a, b, c;
> void d() {
> e : {
>   long f;
>   long *g = &f;
>   if ((a != 0) - (b = 0))
>     ;
>   else
>     a &= (*g %= a *= c) >= (*g || f);
>   goto e;
> }
> }
> 
> Compiler flag -O2.

For the C snippet above, we are queuing the assignment to _7 for removal:

Folding statement: _7 = a.0_1 * c.3_6;
EVRP:hybrid: RVRP found singleton 0
Queued stmt for removal.  Folds to: 0

Yet there is still one use of _7 dangling around at the end of evrp:

_17 = _7 & _29;

It looks like substitute_and_fold_engine::replace_uses_in() is not propagating
into the above statement because ranger can't find the range of _7 at

  FOR_EACH_SSA_USE_OPERAND (use, stmt, iter, SSA_OP_USE)
    {
      tree tuse = USE_FROM_PTR (use);
      tree val = value_of_expr (tuse, stmt);

=>    if (val == tuse || val == NULL_TREE)
        continue;

(gdb) dd stmt
_17 = _7 & _29;
(gdb) dd tuse
_7
(gdb) dd val
<nil>

And the reason why value_of_expr() returns NULL is because the range for _7
here is actually UNDEFINED (i.e. unreachable).  It looks like we can never make
it to BB 5 (where _17 = _7 & _29 lives).  Because BB5 is predicated by a
division by zero:

  <bb 3> :
  c.3_6 = c;
  _7 = a.0_1 * c.3_6;
  a = 0;
  _9 = (long int) _7;
  _10 = f_33(D) % 0;
  if (_10 != 0)
    goto <bb 5>; [INV]
  else
    goto <bb 4>; [INV]


  <bb 5> :
...
  _17 = _7 & _29;


The division by zero was product of various transformations.  Basically we know
that a.0_1 is 0, so we _7 is 0, which means _9 is also 0, which means that
final conditional can't happen:

  <bb 3> :
  c.3_6 = c;
  _7 = a.0_1 * c.3_6;
  a = _7;
  _9 = (long int) _7;
  _10 = f_33(D) % _9;
  if (_10 != 0)

Andrew can take it from here, but it looks like the substitute_and_fold engine
must be able to remove *ALL* references to an LHS whose definition was folded
away, even if said references appear in unreachable code.

[Bug tree-optimization/97378] [11 Regression] ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 since r11-3685-gfcae5121154d1c33

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
The substitute-and-fold engine was designed in a way to queue stmt removal and
it has to adjust all conditions that make unreachable code unreachable to
trivial true/false conditions so CFG cleanup will get rid of those regions.

It all worked fine before.

[Bug tree-optimization/97378] [11 Regression] ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 since r11-3685-gfcae5121154d1c33

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
            Version|10.0                        |11.0

[Bug tree-optimization/97378] [11 Regression] ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 since r11-3685-gfcae5121154d1c33

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS 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:82118acc18e416b9c82c82ce7737f5e6246d6574

commit r11-3830-g82118acc18e416b9c82c82ce7737f5e6246d6574
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Mon Oct 12 10:41:21 2020 -0400

    operator_trunc_mod::wi_fold: Return VARYING for mod by zero.

    gcc/ChangeLog:

            PR tree-optimization/97378
            * range-op.cc (operator_trunc_mod::wi_fold): Return VARYING for mod
by zero.

    gcc/testsuite/ChangeLog:

            * gcc.dg/pr97378.c: New test.

[Bug tree-optimization/97378] [11 Regression] ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 since r11-3685-gfcae5121154d1c33

[aldyh at gcc dot gnu.org]

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

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

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

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

[Bug tree-optimization/97378] [11 Regression] ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 since r11-3685-gfcae5121154d1c33

[amacleod at redhat dot com]

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

--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Aldy Hernandez from comment #2)
> (In reply to David Binderman from comment #1)
>
> 
> 
> The division by zero was product of various transformations.  Basically we
> know that a.0_1 is 0, so we _7 is 0, which means _9 is also 0, which means
> that final conditional can't happen:
> 
>   <bb 3> :
>   c.3_6 = c;
>   _7 = a.0_1 * c.3_6;
>   a = _7;
>   _9 = (long int) _7;
>   _10 = f_33(D) % _9;
>   if (_10 != 0)
> 
> Andrew can take it from here, but it looks like the substitute_and_fold
> engine must be able to remove *ALL* references to an LHS whose definition
> was folded away, even if said references appear in unreachable code.

The issue was a residue of the conflict between the old meaning of undefined
(which was unprocessed, and could be treated as VARYING in a calculation) and
the original ranger design in which undefined means an empty range and is not
reachable.

as such, range-ops was returning undefined for   _10 = f_33 % 0 and when
processing UNDEFINED != 0 ranger was assuming neither edge could be taken
because it wouldn't arrive at this statement in the first place, and well, bad
things happened. 

The current meaning of UNDEFINED in ranger world is still that a value cant be
resolved but use as UNDEFINED is primarily triggered on edge calculations when
combining ranges to indicate an edge isnt taken.  When its used in a
calculation that can/will happen, it should be treated as a VARYING value since
we dont actually know what the value will be and can't draw conclusions.

Its still slightly schizophrenic, and I will work to resolve the consistency of
it.