[Bug tree-optimization/107312] New: [13 Regression] ICE in verify_range, at value-range.cc:1172, called from range_true_and_false

[Bug tree-optimization/107312] New: [13 Regression] ICE in verify_range, at value-range.cc:1172, called from range_true_and_false

[asolokha at gmx dot com]

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

            Bug ID: 107312
           Summary: [13 Regression] ICE in verify_range, at
                    value-range.cc:1172, called from range_true_and_false
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---
            Target: x86_64-pc-linux-gnu

gcc 13.0.0 20221016 snapshot (g:6366e3e8847af98d4728d55951534769d034d02a) ICEs
when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/aarch64/sve/vcond_2_run.c, w/ -mavx512vbmi -O1
-ftree-loop-vectorize:

void
foo (_Float16 *r, short int *a)
{
  int i;

  for (i = 0; i < 32; ++i)
    r[i] = !!a[i];
}

% x86_64-pc-linux-gnu-gcc-13 -mavx512vbmi -O1 -ftree-loop-vectorize -c
ppt01ppy.c
during GIMPLE pass: dom
ppt01ppy.c: In function 'foo':
ppt01ppy.c:2:1: internal compiler error: in verify_range, at
value-range.cc:1172
    2 | foo (_Float16 *r, short int *a)
      | ^~~
0x7bcad5 irange::verify_range()
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/value-range.cc:1172
0x1e6740b range_true_and_false
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/range.h:53
0x1e68c07 operator_not_equal::fold_range(irange&, tree_node*, irange const&,
irange const&, relation_kind_t) const
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/range-op.cc:639
0x1d56084 fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/gimple-range-fold.cc:581
0x1d57a60 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/gimple-range-fold.cc:489
0x1d4a6d3 gimple_ranger::fold_range_internal(vrange&, gimple*, tree_node*)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/gimple-range.cc:258
0x1d4a6d3 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/gimple-range.cc:319
0x1d4b23a gimple_ranger::range_of_expr(vrange&, tree_node*, gimple*)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/gimple-range.cc:126
0x1034a45 cprop_operand
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/tree-ssa-dom.cc:1968
0x1037232 cprop_into_stmt
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/tree-ssa-dom.cc:2045
0x1037232 dom_opt_dom_walker::optimize_stmt(basic_block_def*,
gimple_stmt_iterator*, bool*)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/tree-ssa-dom.cc:2273
0x10382cc dom_opt_dom_walker::before_dom_children(basic_block_def*)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/tree-ssa-dom.cc:1678
0x1d150ae dom_walker::walk(basic_block_def*)
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/domwalk.cc:311
0x1038dbc execute
       
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221016/work/gcc-13-20221016/gcc/tree-ssa-dom.cc:939

[Bug tree-optimization/107312] [13 Regression] ICE in verify_range, at value-range.cc:1172, called from range_true_and_false since r13-3193-g8b6bcedc88d54415

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-10-19
            Summary|[13 Regression] ICE in      |[13 Regression] ICE in
                   |verify_range, at            |verify_range, at
                   |value-range.cc:1172, called |value-range.cc:1172, called
                   |from range_true_and_false   |from range_true_and_false
                   |                            |since
                   |                            |r13-3193-g8b6bcedc88d54415
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r13-3193-g8b6bcedc88d54415.

[Bug tree-optimization/107312] [13 Regression] ICE in verify_range, at value-range.cc:1172, called from range_true_and_false since r13-3193-g8b6bcedc88d54415

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Target Milestone|---                         |13.0

[Bug tree-optimization/107312] [13 Regression] ICE in verify_range, at value-range.cc:1172, called from range_true_and_false since r13-3193-g8b6bcedc88d54415

[aldyh at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Wow, a seemingly innocent change causing an ICE.

range_true_and_false() returns a range of [0,1], which for a 1-bit signed
integer gets passed to the irange setter as [0, -1].  These endpoints are out
of order and cause an ICE.  Through some dumb luck, the legacy code swaps out
of order endpoints, because old VRP would sometimes pass endpoints reversed,
depending on the setter to fix them.  This swapping does not happen for
non-legacy, hence the ICE.

The right thing to do (apart from killing legacy and 1-bit signed integers
;-)), is to avoid passing out of order endpoints for 1-bit signed integers. 
For that matter, a range of [-1, 0] for 1-bit signed types is VARYING,
similarly for [0,1] for 1-bit unsigned types.

[Bug tree-optimization/107312] [13 Regression] ICE in verify_range, at value-range.cc:1172, called from range_true_and_false since r13-3193-g8b6bcedc88d54415

[aldyh at gcc dot gnu.org]

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

--- Comment #3 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 53730
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53730&action=edit
patch in testing

[Bug tree-optimization/107312] [13 Regression] ICE in verify_range, at value-range.cc:1172, called from range_true_and_false since r13-3193-g8b6bcedc88d54415

[cvs-commit at gcc dot gnu.org]

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

--- 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:d32969898e113e86e1c42b0c6f096f8228cbf1ff

commit r13-3382-gd32969898e113e86e1c42b0c6f096f8228cbf1ff
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Wed Oct 19 14:27:46 2022 +0200

    [PR tree-optimization/107312] Make range_true_and_false work with 1-bit
signed types.

    range_true_and_false() returns a range of [0,1], which for a 1-bit
    signed integer gets passed to the irange setter as [0, -1].  These
    endpoints are out of order and cause an ICE.  Through some dumb luck,
    the legacy code swaps out of order endpoints, because old VRP would
    sometimes pass endpoints reversed, depending on the setter to fix
    them.  This swapping does not happen for non-legacy, hence the ICE.

    The right thing to do (apart from killing legacy and 1-bit signed
    integers ;-)), is to avoid passing out of order endpoints for 1-bit
    signed integers.  For that matter, a range of [-1, 0] (signed) or
    [0, 1] (unsigned) is just varying.

            PR tree-optimization/107312

    gcc/ChangeLog:

            * range.h (range_true_and_false): Special case 1-bit signed types.
            * value-range.cc (range_tests_misc): New test.

    gcc/testsuite/ChangeLog:

            * gcc.target/i386/pr107312.c: New test.

[Bug tree-optimization/107312] [13 Regression] ICE in verify_range, at value-range.cc:1172, called from range_true_and_false since r13-3193-g8b6bcedc88d54415

[aldyh at gcc dot gnu.org]

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

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