[Bug tree-optimization/104334] New: Ranger/dom miscompilation

[Bug tree-optimization/104334] New: Ranger/dom miscompilation

[jakub at gcc dot gnu.org]

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

            Bug ID: 104334
           Summary: Ranger/dom miscompilation
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

enum class A { A0, A1, A2, A3 };
int x;

__attribute__((noipa)) void
baz ()
{
  x = 1;
}

struct B {
  unsigned b : 2;

  A
  foo () const
  {
    return static_cast<A> (b);
  }

  __attribute__((noinline)) void
  bar ()
  {
    if (foo () == A::A2 || foo () == A::A3)
      baz ();
  }
};

int
main ()
{
  B c;
  c.b = 2;
  c.bar ();
  if (x != 1)
    __builtin_abort ();
  return 0;
}

is miscompiled on x86_64-linux with -O2 --param logical-op-non-short-circuit=0
and on powerpc64le-linux and s390x-linux with just -O2.
Strangely, I can't reproduce it with cross-compilers or -O0 built cc1plus or
even cc1plus bootstrapped my usual way:
../configure --enable-languages=default,ada,obj-c++,lto,go,d
--enable-checking=yes,rtl,extra --enable-libstdcxx-backtrace=yes
but can reproduce it in:
./configure --enable-bootstrap --enable-languages=c,c++
--enable-checking=release --disable-multilib --with-tune=generic
--with-build-config=bootstrap-lto --enable-link-serialization=1
(but there only in second and third stages, stage1-gcc still doesn't miscompile
it).
thread2 dump is still identical between non-miscompiled and miscompiled cases,
we have there:
  <unnamed-unsigned:2> _5;
  <unnamed-unsigned:2> _7;

  <bb 2> [local count: 1073741823]:
  _5 = MEM[(const struct B *)this_3(D)].b;
  _7 = _5 + 2;
  if (_7 <= 1)
(frankly weird to do the addition and comparison in unsigned:2 type, but it is
what reassoc comes up with.  Furthermore, for unsigned:2 type, test for value
in [2,3] range can be done with just
_5 >= 2 and doesn't need to do the addition).
The difference is in dom3 dump (-fdump-tree-all-alias-details):
@@ -66,11 +66,11 @@ LKUP STMT _5 = MEM[(const struct B *)thi
 extract_range_from_stmt visiting:
 _7 = _5 + 2;
 Intersecting
-  <unnamed-unsigned:2> VARYING
+  <unnamed-unsigned:2> [1, +INF]
 and
   <unnamed-unsigned:2> VARYING
 to
-  <unnamed-unsigned:2> VARYING
+  <unnamed-unsigned:2> [1, +INF]
 Optimizing statement _7 = _5 + 2;
 LKUP STMT _7 = _5 plus_expr 2
 2>>> STMT _7 = _5 plus_expr 2
@@ -79,7 +79,7 @@ Optimizing statement if (_7 <= 1)
 Visiting conditional with predicate: if (_7 <= 1)

 With known ranges
-       _7: <unnamed-unsigned:2> VARYING
+       _7: <unnamed-unsigned:2> [1, +INF]

 Predicate evaluates to: DON'T KNOW
 LKUP STMT _7 le_expr 1
@@ -94,9 +94,9 @@ Adding assert for _5 from _5 + 2 <= 1
 Intersecting
   <unnamed-unsigned:2> [0, 1]  EQUIVALENCES: { _7 } (1 elements)
 and
-  <unnamed-unsigned:2> VARYING
+  <unnamed-unsigned:2> [1, +INF]
 to
-  <unnamed-unsigned:2> [0, 1]  EQUIVALENCES: { _7 } (1 elements)
+  <unnamed-unsigned:2> [1, 1]  EQUIVALENCES: { _7 } (1 elements)
 Intersecting
   <unnamed-unsigned:2> [2, +INF]  EQUIVALENCES: { _5 } (1 elements)
 and
@@ -104,12 +104,12 @@ and
 to
   <unnamed-unsigned:2> [2, +INF]  EQUIVALENCES: { _5 } (1 elements)
 Intersecting
-  <unnamed-unsigned:2> VARYING
+  <unnamed-unsigned:2> [1, +INF]
 and
-  <unnamed-unsigned:2> [0, 1]
+  <unnamed-unsigned:2> [1, 1]
 to
-  <unnamed-unsigned:2> [0, 1]
-pushing new range for _7: <unnamed-unsigned:2> [0, 1]  EQUIVALENCES: { _7 } (1
elements)
+  <unnamed-unsigned:2> [1, 1]
+pushing new range for _7: <unnamed-unsigned:2> [1, 1]  EQUIVALENCES: { _7 } (1
elements)
 Intersecting
   <unnamed-unsigned:2> VARYING
 and
@@ -123,7 +123,7 @@ Optimizing statement baz ();
 <<<< STMT 0 = _7 gt_expr 1
 <<<< STMT 1 = _7 le_expr 1
 popping range for _5, restoring <unnamed-unsigned:2> VARYING
-popping range for _7, restoring <unnamed-unsigned:2> VARYING
+popping range for _7, restoring <unnamed-unsigned:2> [1, +INF]


 Optimizing block #4
@@ -144,6 +144,7 @@ void B::bar (struct B * const this)

   <bb 2> [local count: 1073741823]:
   _5 = MEM[(const struct B *)this_3(D)].b;
+  # RANGE [1, 3]
   _7 = _5 + 2;
   if (_7 <= 1)
     goto <bb 3>; [20.24%]

and the bogus # RANGE in the last hunk is what is the problem, both _5 and _7
have actually VARYING range (aka [0, 3]).

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Ranger/dom miscompilation   |[12 Regression] Ranger/dom
                   |                            |miscompilation
           Priority|P3                          |P1
   Target Milestone|---                         |12.0

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Also tried
../configure --enable-bootstrap --enable-languages=c,c++
--enable-checking=release --disable-multilib --with-tune=generic
build, but there it doesn't reproduce in either of stage1 or stage2 (stage3
still building).
So most probably LTO bootstrap is the trigger :(.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |lto, wrong-code
           Severity|normal                      |blocker

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>So most probably LTO bootstrap is the trigger :(.

Maybe you could throw some "#pragma GCC optimize" in some files to figure out
which file has the function that is being miscompiled. Maybe then narrow it
down using the optimize attribute?

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org
   Last reconfirmed|                            |2022-02-02
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
I can confirm the same behavior: the non-bootstrapped compiler is fine and
openSUSE gcc12 package built with lto/PGO reproduces that.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needs-bisection

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
I can try bisecting that. Do we speak about a possible miscompilation?

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
If there is a way to test adding -fno-ipa-modref to the bootstrap. That or
-fno-tree-vectorize. I suspect it is one of those two since those were the
areas that changed the most for the trunk.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, in the debugger the difference is in the range_operator::wi_fold_in_parts
function (with:
enum class A { A0, A1, A2, A3 };
int x;

void baz ();

struct B {
  unsigned b : 2;

  A
  foo () const
  {
    return static_cast<A> (b);
  }

  void bar ();
};

void
B::bar ()
{
  if (foo () == A::A2 || foo () == A::A3)
    baz ();
}
the first one).
type is unsigned:2, lh_lb 0, lh_ub -1 (aka 3), rh_lb and rh_ub -2 (aka 2).
lh_range is -1 (aka 3), rh_range is 0, ov_{l,r}h is OVF_NONE.
In the non-LTO case, we do wi_fold on line 176
171       // Otherise check for 2, 3, or 4 values in the LH range and split
them up.
172       // The RH side has been checked, so no recursion needed.
173       else if (wi::gt_p (lh_range, 0, sign) && wi::lt_p (lh_range, 4, sign)
174                && ov_lh == wi::OVF_NONE)
175         {
176           wi_fold (r, type, lh_lb, lh_lb, rh_lb, rh_ub);
while in the LTO case on line 192.

The wi::lt_p (rh_range, 4, sign) and wi::lt_p (lh_range, 4, sign) calls
look highly suspicious, 4 is not representable in unsigned:2.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrs at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org,
                   |                            |rsandifo at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The difference might be in:
1938      /* Optimize comparisons with constants.  */
1939      if (STATIC_CONSTANT_P (yi.len == 1 && yi.val[0] >= 0))
1940        return xi.len == 1 && xi.to_uhwi () < (unsigned HOST_WIDE_INT)
yi.val[0];
1941      if (STATIC_CONSTANT_P (xi.len == 1 && xi.val[0] >= 0))
1942        return yi.len != 1 || yi.to_uhwi () > (unsigned HOST_WIDE_INT)
xi.val[0];
1943      /* Optimize the case of two HWIs.  The HWIs are implicitly
sign-extended
1944         for precisions greater than HOST_BITS_WIDE_INT, but sign-extending
both
1945         values does not change the result.  */
1946      if (__builtin_expect (xi.len + yi.len == 2, true))
1947        {
1948          unsigned HOST_WIDE_INT xl = xi.to_uhwi ();
1949          unsigned HOST_WIDE_INT yl = yi.to_uhwi ();
1950          return xl < yl;
1951        }
Perhaps with LTO STATIC_CONSTANT_P (yi.len && iy.val[0] >= 0) is true while
without LTO it is false.
I'll verify that.  Though, xi.len == 1, xi.to_uhwi () is 3, yi.val[0] is 4 and
yi.to_uhwi () is 0.
So I think if STATIC_CONSTANT_P is true, it will return 3 < 4, while if it is
false, it will return 3 < 0.

Now, the question is, do we consider those wi::lt_p (x, 4, sign) calls invalid
if 4 is not representable in type,
or does the STATIC_CONSTANT_P case need to also check precision, or mask
Xi.val[0]?

And another question is, the 2, 3, 4 cases handling seems like an optimization,
so wi_fold at line 192 should give the right answer, but it doesn't.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Now verified, in the LTO case both wi::gt_p/wi::gtu_p and wi::lt_p/wi::ltu_p
are inlined and do:
   0x000000000191600e
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_+750>:
       test   %rdx,%rdx
   0x0000000001916011
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_+753>:
       je     0x1915edc
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_+444>
   0x0000000001916017
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_+759>:
       cmp    $0x3,%rdx
   0x000000000191601b
<_ZNK14range_operator16wi_fold_in_partsER6irangeP9tree_nodeRK16generic_wide_intI16wide_int_storageES8_S8_S8_+763>:
       ja     0x1915edc <_ZNK14range_operator
so that looks like lh_range.val[0] != 0 && lh_range.val[0] <= 3U, so I'm pretty
sure that is the STATIC_CONSTANT_P case.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation

[rsandifo at gcc dot gnu.org]

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

--- Comment #9 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> The difference might be in:
> 1938	  /* Optimize comparisons with constants.  */
> 1939	  if (STATIC_CONSTANT_P (yi.len == 1 && yi.val[0] >= 0))
> 1940	    return xi.len == 1 && xi.to_uhwi () < (unsigned HOST_WIDE_INT)
> yi.val[0];
> 1941	  if (STATIC_CONSTANT_P (xi.len == 1 && xi.val[0] >= 0))
> 1942	    return yi.len != 1 || yi.to_uhwi () > (unsigned HOST_WIDE_INT)
> xi.val[0];
> 1943	  /* Optimize the case of two HWIs.  The HWIs are implicitly
> sign-extended
> 1944	     for precisions greater than HOST_BITS_WIDE_INT, but sign-extending
> both
> 1945	     values does not change the result.  */
> 1946	  if (__builtin_expect (xi.len + yi.len == 2, true))
> 1947	    {
> 1948	      unsigned HOST_WIDE_INT xl = xi.to_uhwi ();
> 1949	      unsigned HOST_WIDE_INT yl = yi.to_uhwi ();
> 1950	      return xl < yl;
> 1951	    }
> Perhaps with LTO STATIC_CONSTANT_P (yi.len && iy.val[0] >= 0) is true while
> without LTO it is false.
> I'll verify that.  Though, xi.len == 1, xi.to_uhwi () is 3, yi.val[0] is 4
> and yi.to_uhwi () is 0.
> So I think if STATIC_CONSTANT_P is true, it will return 3 < 4, while if it
> is false, it will return 3 < 0.
> 
> Now, the question is, do we consider those wi::lt_p (x, 4, sign) calls
> invalid if 4 is not representable in type,
> or does the STATIC_CONSTANT_P case need to also check precision, or mask
> Xi.val[0]?
At the moment I think they're invalid.  If we want to change that,
and have the value be implicitly truncated, we should probably do
it by setting primitive_int_traits::is_sign_extended to false.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 2 Feb 2022, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
> 
> --- Comment #9 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
> (In reply to Jakub Jelinek from comment #7)
> > The difference might be in:
> > 1938	  /* Optimize comparisons with constants.  */
> > 1939	  if (STATIC_CONSTANT_P (yi.len == 1 && yi.val[0] >= 0))
> > 1940	    return xi.len == 1 && xi.to_uhwi () < (unsigned HOST_WIDE_INT)
> > yi.val[0];
> > 1941	  if (STATIC_CONSTANT_P (xi.len == 1 && xi.val[0] >= 0))
> > 1942	    return yi.len != 1 || yi.to_uhwi () > (unsigned HOST_WIDE_INT)
> > xi.val[0];
> > 1943	  /* Optimize the case of two HWIs.  The HWIs are implicitly
> > sign-extended
> > 1944	     for precisions greater than HOST_BITS_WIDE_INT, but sign-extending
> > both
> > 1945	     values does not change the result.  */
> > 1946	  if (__builtin_expect (xi.len + yi.len == 2, true))
> > 1947	    {
> > 1948	      unsigned HOST_WIDE_INT xl = xi.to_uhwi ();
> > 1949	      unsigned HOST_WIDE_INT yl = yi.to_uhwi ();
> > 1950	      return xl < yl;
> > 1951	    }
> > Perhaps with LTO STATIC_CONSTANT_P (yi.len && iy.val[0] >= 0) is true while
> > without LTO it is false.
> > I'll verify that.  Though, xi.len == 1, xi.to_uhwi () is 3, yi.val[0] is 4
> > and yi.to_uhwi () is 0.
> > So I think if STATIC_CONSTANT_P is true, it will return 3 < 4, while if it
> > is false, it will return 3 < 0.
> > 
> > Now, the question is, do we consider those wi::lt_p (x, 4, sign) calls
> > invalid if 4 is not representable in type,
> > or does the STATIC_CONSTANT_P case need to also check precision, or mask
> > Xi.val[0]?
> At the moment I think they're invalid.  If we want to change that,
> and have the value be implicitly truncated, we should probably do
> it by setting primitive_int_traits::is_sign_extended to false.

I also think they are invalid.  I guess primitive_int_traits
always produce "widest_ints", but I don't know whether we can
reasonably reject the wi:lt_p (x, 4, sign) calls in favor of
requiring wi::lt_p (wi::to_widest (x), 4, sign) at compile-time ...

I don't think we want to silenlty truncate the literal '4', instead
if we really want, we could ICE with checking enabled ...

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> And another question is, the 2, 3, 4 cases handling seems like an optimization, > so wi_fold at line 192 should give the right answer, but it doesn't.

Actually no, I misunderstood, with -O0 or non-LTO, it is the wi_fold call,
while with LTO it is the
178           wi_fold (r, type, lh_lb, lh_lb, rh_lb, rh_ub);
179           if (wi::gt_p (lh_range, 1, sign))
180             {
181               wi_fold (tmp, type, lh_lb + 1, lh_lb + 1, rh_lb, rh_ub);
182               r.union_ (tmp);
183               if (wi::eq_p (lh_range, 3))
184                 {
(gdb) 
185                   wi_fold (tmp, type, lh_lb + 2, lh_lb + 2, rh_lb, rh_ub);
186                   r.union_ (tmp);
187                 }
188             }
189           wi_fold (tmp, type, lh_ub, lh_ub, rh_lb, rh_ub);
190           r.union_ (tmp);
optimization.  And that one doesn't work too well, because
wi::eq_p (lh_range, 3) is false:
xi.is_sign_extended is true, yi.is_sign_extended is true
lh_range.val[0] is -1, and yi.val[0] is 3, so it isn't equal.
That is because we haven't sign-extended 3.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12 Regression] Ranger/dom  |[12 Regression] Ranger/dom
                   |miscompilation              |miscompilation since
                   |                            |r12-4694-gcb153222404e2e

--- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r12-4694-gcb153222404e2e.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, I think one way is to punt on these small precision types, like:
--- range-op.cc.jj1     2022-01-13 22:29:15.345831749 +0100
+++ range-op.cc 2022-02-02 13:44:05.813637820 +0100
@@ -148,11 +148,13 @@ range_operator::wi_fold_in_parts (irange
   int_range_max tmp;
   wide_int rh_range = wi::sub (rh_ub, rh_lb, TYPE_SIGN (type), &ov_rh);
   wide_int lh_range = wi::sub (lh_ub, lh_lb, TYPE_SIGN (type), &ov_lh);
-  signop sign = TYPE_SIGN (type);;
+  signop sign = TYPE_SIGN (type);
   // If there are 2, 3, or 4 values in the RH range, do them separately.
   // Call wi_fold_in_parts to check the RH side.
-  if (wi::gt_p (rh_range, 0, sign) && wi::lt_p (rh_range, 4, sign)
-      && ov_rh == wi::OVF_NONE)
+  if (wi::min_precision (4, sign) <= wi::get_precision (rh_range)
+      && ov_rh == wi::OVF_NONE
+      && wi::gt_p (rh_range, 0, sign)
+      && wi::lt_p (rh_range, 4, sign))
     {
       wi_fold_in_parts (r, type, lh_lb, lh_ub, rh_lb, rh_lb);
       if (wi::gt_p (rh_range, 1, sign))
@@ -170,8 +172,10 @@ range_operator::wi_fold_in_parts (irange
     }
   // Otherise check for 2, 3, or 4 values in the LH range and split them up.
   // The RH side has been checked, so no recursion needed.
-  else if (wi::gt_p (lh_range, 0, sign) && wi::lt_p (lh_range, 4, sign)
-          && ov_lh == wi::OVF_NONE)
+  else if (wi::min_precision (4, sign) <= wi::get_precision (lh_range)
+          && ov_lh == wi::OVF_NONE
+          && wi::gt_p (lh_range, 0, sign)
+          && wi::lt_p (lh_range, 4, sign))
     {
       wi_fold (r, type, lh_lb, lh_lb, rh_lb, rh_ub);
       if (wi::gt_p (lh_range, 1, sign))
i.e. only optimize if 4 is representable in the given wide_int.
The other option is to be extra careful.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška <marxin at gcc dot gnu.org> ---
I can just confirm that using tree-vrp.o from stage1 fixes the issue.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52328
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52328&action=edit
gcc12-pr104334.patch

Better untested fix.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e

[amacleod at redhat dot com]

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

--- Comment #16 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #13)
> So, I think one way is to punt on these small precision types, like:
> --- range-op.cc.jj1	2022-01-13 22:29:15.345831749 +0100
> +++ range-op.cc	2022-02-02 13:44:05.813637820 +0100
> @@ -148,11 +148,13 @@ range_operator::wi_fold_in_parts (irange
>    int_range_max tmp;
>    wide_int rh_range = wi::sub (rh_ub, rh_lb, TYPE_SIGN (type), &ov_rh);
>    wide_int lh_range = wi::sub (lh_ub, lh_lb, TYPE_SIGN (type), &ov_lh);
> -  signop sign = TYPE_SIGN (type);;
> +  signop sign = TYPE_SIGN (type);
>    // If there are 2, 3, or 4 values in the RH range, do them separately.
>    // Call wi_fold_in_parts to check the RH side.
> -  if (wi::gt_p (rh_range, 0, sign) && wi::lt_p (rh_range, 4, sign)
> -      && ov_rh == wi::OVF_NONE)
> +  if (wi::min_precision (4, sign) <= wi::get_precision (rh_range)
> +      && ov_rh == wi::OVF_NONE
> +      && wi::gt_p (rh_range, 0, sign)
> +      && wi::lt_p (rh_range, 4, sign))
>      {
>        wi_fold_in_parts (r, type, lh_lb, lh_ub, rh_lb, rh_lb);
>        if (wi::gt_p (rh_range, 1, sign))
> @@ -170,8 +172,10 @@ range_operator::wi_fold_in_parts (irange
>      }
>    // Otherise check for 2, 3, or 4 values in the LH range and split them up.
>    // The RH side has been checked, so no recursion needed.
> -  else if (wi::gt_p (lh_range, 0, sign) && wi::lt_p (lh_range, 4, sign)
> -	   && ov_lh == wi::OVF_NONE)
> +  else if (wi::min_precision (4, sign) <= wi::get_precision (lh_range)
> +	   && ov_lh == wi::OVF_NONE
> +	   && wi::gt_p (lh_range, 0, sign)
> +	   && wi::lt_p (lh_range, 4, sign))
>      {
>        wi_fold (r, type, lh_lb, lh_lb, rh_lb, rh_ub);
>        if (wi::gt_p (lh_range, 1, sign))
> i.e. only optimize if 4 is representable in the given wide_int.
> The other option is to be extra careful.

yes, I think if the precision is small, simply don't try to break it up.  We
special case 1 bit all over the place for this reason. 
Like you did, or simply this way. Either amounts to the same thing and wi_fold
get called on the range.

diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 19bdf30911a..a88fb7b8932 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -149,6 +149,11 @@ range_operator::wi_fold_in_parts (irange &r, tree type,
   wide_int rh_range = wi::sub (rh_ub, rh_lb, TYPE_SIGN (type), &ov_rh);
   wide_int lh_range = wi::sub (lh_ub, lh_lb, TYPE_SIGN (type), &ov_lh);
   signop sign = TYPE_SIGN (type);;
+
+  // If precision of the type is too small, don't bother trying to split it
up.
+  if (TYPE_PRECISION (type) <= 3)
+    wi_fold (r, type, lh_lb, lh_ub, rh_lb, rh_ub);
+  else
   // If there are 2, 3, or 4 values in the RH range, do them separately.
   // Call wi_fold_in_parts to check the RH side.
   if (wi::gt_p (rh_range, 0, sign) && wi::lt_p (rh_range, 4, sign)

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e

[rguenther at suse dot de]

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

--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 2 Feb 2022, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104334
> 
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|NEW                         |ASSIGNED
>            Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
> 
> --- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Created attachment 52328
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52328&action=edit
> gcc12-pr104334.patch
> 
> Better untested fix.

unconditional using wi::to_widest for the compares might also work?

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think to_widest only works with INTEGER_CSTs, to do the comparisons (or have
?h_range be widest_int), we'd need to use widest_int::from I think.

Anyway, with the above patch I've built so far stage2 cc1plus and that no
longer miscompiles the testcase.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52329
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52329&action=edit
gcc12-pr104334.patch

Patch doing ?h_range and related comparisons in widest_int.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e

[rsandifo at gcc dot gnu.org]

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

--- Comment #20 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #19)
> Created attachment 52329 [details]
> gcc12-pr104334.patch
> 
> Patch doing ?h_range and related comparisons in widest_int.
Looks like a good approach to me FWIW.  You can use infix
operators instead of lts_p etc. for widest_ints, since widest_ints
always have enough bits for the sign.

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 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:de67f943b858099b40f73632a51e66147ec79c9b

commit r12-7012-gde67f943b858099b40f73632a51e66147ec79c9b
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Feb 3 09:45:16 2022 +0100

    ranger: Fix up wi_fold_in_parts for small precision types [PR104334]

    The wide-int.h templates expect that when an int/long etc. operand is used
    it will be sign-extended based on the types precision.
    wi_fold_in_parts passes 3 such non-zero constants to wi::lt_p, wi::gt_p
    and wi::eq_p - 1, 3 and 4, which means it was doing weird things if either
    some of 1, 3 or 4 weren't representable in type, or if type was unsigned 3
bit
    type 4 should be written as -4.
    The following patch promotes the subtraction operands to widest_int and
    uses that as the type for ?h_range variables and compares them as such.
    We don't need the overflow handling because there is never an overflow.

    2022-02-02  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/104334
            * range-op.cc (range_operator::wi_fold_in_parts): Change lh_range
            and rh_range type to widest_int and subtract in widest_int.  Remove
            ov_rh, ov_lh and sign vars, always perform comparisons as signed
            and use >, < and == operators for it.

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

[Bug tree-optimization/104334] [12 Regression] Ranger/dom miscompilation since r12-4694-gcb153222404e2e

[jakub at gcc dot gnu.org]

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

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

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

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