[Bug tree-optimization/108253] New: [13 Regression] ICE in set_nonzero_bits

[Bug tree-optimization/108253] New: [13 Regression] ICE in set_nonzero_bits

[law at gcc dot gnu.org]

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

            Bug ID: 108253
           Summary: [13 Regression] ICE in set_nonzero_bits
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: law at gcc dot gnu.org
  Target Milestone: ---
            Target: x86_64

Created attachment 54167
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54167&action=edit
Testcase

I'm assuming this is a regression as I suspect the abseil-cpp package was
around and built during the f36/f37 gcc-12 cycle.

g++ -O2
./absl/strings/CMakeFiles/absl_cord_ring_reader_test.dir/cord_ring_reader_test.cc.ii
during GIMPLE pass: dom
/builddir/build/BUILD/abseil-cpp-20220623.1/absl/strings/cord_ring_reader_test.cc:
In member function 'virtual void
absl::lts_20220623::cord_internal::{anonymous}::CordRingReaderTest_DefaultInstance_Test::TestBody()':
/builddir/build/BUILD/abseil-cpp-20220623.1/absl/strings/cord_ring_reader_test.cc:58:1:
internal compiler error: in set_nonzero_bits, at tree-ssanames.cc:464
   58 | TEST(CordRingReaderTest, DefaultInstance) {
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source.
See <http://bugzilla.redhat.com/bugzilla> for instructions.


I haven't reduced or debugged this at all.  It could well land on me as it's
failing in DOM.  It could also well land on Aldy/Andrew since I suspect it's
touching ranger from inside DOM.

[Bug tree-optimization/108253] [13 Regression] ICE in set_nonzero_bits

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
           Keywords|                            |ice-on-valid-code

[Bug tree-optimization/108253] [13 Regression] ICE in set_nonzero_bits

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Reducing ...

[Bug tree-optimization/108253] [13 Regression] ICE in set_nonzero_bits

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 54169
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54169&action=edit
Reduced testcase

This is as reduced testcase as I can get it.
I tried to get back from some non-undefined behavior too. 
Note I also tried to inline a few things manually but that causes the failure
to go away too.

[Bug tree-optimization/108253] [13 Regression] ICE in set_nonzero_bits

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-12-30
     Ever confirmed|0                           |1

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I suspect it is trying to set the nonzero bits for:
  _19 = &_15->data_;

From the assert:
                if (reinterpret_cast<size_t>(ring_->data_) % 4 != 0)
                        __builtin_abort();

But I could be wrong ...

[Bug tree-optimization/108253] [13 Regression] ICE in set_nonzero_bits

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Full backtrace:
during GIMPLE pass: dom
t.cc: In function ‘void TestBody()’:
t.cc:46:1: internal compiler error: in set_nonzero_bits, at
tree-ssanames.cc:464
   46 | TestBody() {
      | ^~~~~~~~
0x8f0a06 set_nonzero_bits(tree_node*,
generic_wide_int<wide_int_ref_storage<false, true> > const&)
        /home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssanames.cc:464
0x14c8f23 maybe_set_nonzero_bits(edge_def*, tree_node*)
        /home/apinski/src/upstream-gcc-git/gcc/gcc/tree-vrp.cc:2456
0x1330c3b
dom_opt_dom_walker::set_global_ranges_from_unreachable_edges(basic_block_def*)
        /home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssa-dom.cc:1383
0x1332586 dom_opt_dom_walker::before_dom_children(basic_block_def*)
        /home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssa-dom.cc:1652
0x1f80d1e dom_walker::walk(basic_block_def*)
        /home/apinski/src/upstream-gcc-git/gcc/gcc/domwalk.cc:311
0x1333251 execute
        /home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssa-dom.cc:939
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.

That is maybe_set_nonzero_bits forgot to check if the cast was from a pointer
type.

I suspect (have not even tried this at all; figured this out via looking at the
assert and looking at the current code) will fix this:
diff --git a/gcc/tree-vrp.cc b/gcc/tree-vrp.cc
index e6c6c5a301d..8068cf2b083 100644
--- a/gcc/tree-vrp.cc
+++ b/gcc/tree-vrp.cc
@@ -762,6 +762,7 @@ maybe_set_nonzero_bits (edge e, tree var)
   tree cst;

   if (stmt == NULL
+      || POINTER_TYPE_P (TREE_TYPE (var))
       || gimple_code (stmt) != GIMPLE_COND
       || gimple_cond_code (stmt) != ((e->flags & EDGE_TRUE_VALUE)
                                     ? EQ_EXPR : NE_EXPR)

[Bug tree-optimization/108253] [13 Regression] ICE in set_nonzero_bits

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54178
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54178&action=edit
gcc13-pr108253.patch

We actually don't need to punt on pointers but can handle them.

[Bug tree-optimization/108253] [13 Regression] ICE in set_nonzero_bits

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:ebc449119442501c927ede0e83697eaece72223e

commit r13-4990-gebc449119442501c927ede0e83697eaece72223e
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Jan 4 12:16:22 2023 +0100

    vrp: Handle pointers in maybe_set_nonzero_bits [PR108253]

    maybe_set_nonzero_bits calls set_nonzero_bits which asserts that
    var doesn't have pointer type.  While we could punt for those
    cases, I think we can handle at least some easy cases.
    Earlier in maybe_set_nonzero_bits we've checked this is on
    (var & cst) == 0
    edge and the other edge is __builtin_unreachable, so if cst
    is say 3 as in the testcase, we want to turn it into 4 byte alignment
    of the pointer.

    2023-01-04  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/108253
            * tree-vrp.cc (maybe_set_nonzero_bits): Handle var with pointer
            types.

            * g++.dg/opt/pr108253.C: New test.

[Bug tree-optimization/108253] [13 Regression] ICE in set_nonzero_bits

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.