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

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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 ...