[Bug c/102463] New: ice in fold_using_range::relation_fold_and_or

[Bug c/102463] New: ice in fold_using_range::relation_fold_and_or

[dcb314 at hotmail dot com]

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

            Bug ID: 102463
           Summary: ice in fold_using_range::relation_fold_and_or
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C code:

_bfd_elf_merge_symbol_h, _bfd_elf_merge_symbol_h_1;
_Bool _bfd_elf_merge_symbol_olddef;
_bfd_elf_merge_symbol() {
  _Bool newdef = bfd_is_com_section(), ntdef, tdef;
  _bfd_elf_merge_symbol_olddef = _bfd_elf_merge_symbol_h;
  if (_bfd_elf_merge_symbol_h_1) {
    ntdef = newdef;
    tdef = _bfd_elf_merge_symbol_h;
  } else {
    ntdef = _bfd_elf_merge_symbol_h;
    tdef = newdef;
  }
  if (tdef && ntdef)
    ;
}

compiled by recent gcc and flag -O2, does this:

during GIMPLE pass: evrp
elflink.c: In function ‘_bfd_elf_merge_symbol’:
elflink.c:15198:1: internal compiler error: Segmentation fault
0xd6a899 crash_signal(int)
        ../../trunk.git/gcc/toplev.c:328
0x1a73c3c fold_using_range::relation_fold_and_or(irange&, gimple*, fur_source&)
        ../../trunk.git/gcc/gimple-range-fold.cc:1365

The problem first seems to occur sometime between git hash
947332a4e22aef9b, from last week, and hash 83aac698835edcdb
from yesterday.

[Bug c/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
           Severity|normal                      |blocker
           Keywords|                            |ice-on-valid-code
            Summary|ice in                      |[12 Regression] ice in
                   |fold_using_range::relation_ |fold_using_range::relation_
                   |fold_and_or                 |fold_and_or

[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman <dcb314 at hotmail dot com> ---
142 revisions in the gap, trying 24f99147b9264f8f.

[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or

[rguenth at gcc dot gnu.org]

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

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

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

[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #1)
> 142 revisions in the gap, trying 24f99147b9264f8f.

Revision looks good, trying f6ccb788f29ce79a, although Aldy seems
to be in the frame for this one.

[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Could you provide a preprocessed source?

[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Aldy Hernandez from comment #3)
> Could you provide a preprocessed source?

? It already is. It might need a few "int" and "void" to keep
modern C compilers happy. 

I forgot to add the relevant flags to the reduce. Sorry.

Current git range is [5d110fe90afcd850..f6ccb788f29ce79a].

[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or

[aldyh at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
                 CC|                            |amacleod at redhat dot com
   Last reconfirmed|                            |2021-09-23

--- Comment #5 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to David Binderman from comment #4)
> (In reply to Aldy Hernandez from comment #3)
> > Could you provide a preprocessed source?
> 
> ? It already is. It might need a few "int" and "void" to keep
> modern C compilers happy. 
> 
> I forgot to add the relevant flags to the reduce. Sorry.
> 
> Current git range is [5d110fe90afcd850..f6ccb788f29ce79a].

My bad.  I got thrown off by the first line and assumed it was some enum
specific to bfd.

This looks like it came from Andrew's EDGE_EXECUTABLE patches:

commit 73cf73af2392e00917de042a4692f6a0b6329ee8
commit 5d110fe90afcd850ea21aee6429f22edd6b1b592

This is an ICE in relation_fold_and_or where the defining statement for an SSA
is a PHI, which obviously has no range-ops entry, so we shouldn't dereference
its handler:

  range_operator *handler1 = gimple_range_handler (SSA_NAME_DEF_STMT (ssa1));
  range_operator *handler2 = gimple_range_handler (SSA_NAME_DEF_STMT (ssa2));

  int_range<2> bool_one (boolean_true_node, boolean_true_node);

  relation_kind relation1 = handler1->op1_op2_relation (bool_one);
  relation_kind relation2 = handler2->op1_op2_relation (bool_one);

SSA_NAME_DEF_STMT(ssa1) is: ntdef_10 = PHI <newdef_14(2), _3(3)>

CCing author.

[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or

[amacleod at redhat dot com]

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

--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> ---
That trapping routine (relation_fold_and_or)  is looking to see if there are
any relationships between dependencies that can be exploited. ie
   c_2 = a_6 > b_7
   c_3 = a_6 < b_7
   c_4 = c_2 && c_3
  if (c_4 != 0)

when looking at c_2 and c_3, it notes that they both depend on the same 2
ssa-names,  a_6, and a_7.
It then queries whether there is a relationship between them when c_2 is [1,1]
and c_3 is [1,1].   If so, it then tries to apply that relation to see if the
stmt can never be true or not based on that raw relation.

In this case, the 2 defining stmts are both PHI nodes, which happen to have the
same 2 ssa_names in the dependency list, so it matches the pattern being looked
for:

  # ntdef_6 = PHI <newdef_10(2), _bfd_elf_merge_symbol_h.0_1(3)>
  # tdef_7 = PHI <_bfd_elf_merge_symbol_h.0_1(2), newdef_10(3)>
  _5 = __tdef_7 & ntdef_6

both names depend on the value of newdef_10 and _bfd_elf_merge_symbol_h.0_1, so
a check is being made for a relationship between op1 and op2 in those stmts.

Whats missing is that we can only check for operand relationships in range-ops
enabled stmts... The phi will never overtly give us a relation between the
first and second operand, so no need to check.

[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS 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:fe4e6c824a580012bf9034cc33f0b440df93f56f

commit r12-3868-gfe4e6c824a580012bf9034cc33f0b440df93f56f
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Thu Sep 23 09:32:00 2021 -0400

    Look for a relation between operands only when possible.

    Do not look for a relation between 2 operands if there is no range-ops
handler.

            gcc/
            PR tree-optimization/102463
            * gimple-range-fold.cc (fold_using_range::relation_fold_and_or): If
            there is no range-ops handler, don't look for a relation.

            gcc/testsuite/
            * gcc.dg/pr102463.c: New.

[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

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

--- Comment #8 from Andrew Macleod <amacleod at redhat dot com> ---
Fixed.