https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > I guess disabling them at least for now could be fine.
> > If somebody involved with dfp wants to extend it for dfp, it can be done
> > incrementally.
> >
> > BTW, thinking further about the singletons, I wonder if MODE_COMPOSITE_P
> > don't have similar problems. For the case where the values are exactly
> > equal
> > to their MSB (i.e. the __ibm128 value is equal to that value cast to double
> > and back), then the low part can be either +0.0 or -0.0. Ditto for +Inf and
> > -Inf.
> > So there can be quite a few non-singleton values.
> > libgcc/config/rs6000/ibm-ldouble-format describes it.
>
> Eeech, could you come up with a patch for that one? Consider it preapproved
> :-/. I'm afraid to mess it up.
I think it would be:
--- gcc/value-range.cc.jj 2022-09-05 16:50:51.443419082 +0200
+++ gcc/value-range.cc 2022-09-05 16:52:04.880434594 +0200
@@ -639,6 +639,19 @@ frange::singleton_p (tree *result) const
if (HONOR_NANS (m_type) && !get_nan ().no_p ())
return false;
+ if (MODE_COMPOSITE_P (TYPE_MODE (m_type)))
+ {
+ // In IBM extended format, if value is +-Inf or
+ // is exactly representable in double, the other
+ // double could be +0.0 or -0.0.
+ if (real_isinf (&m_min))
+ return false;
+ REAL_VALUE_TYPE v;
+ real_convert (&v, DFmode, &m_min);
+ if (real_identical (&v, &m_min))
+ return false;
+ }
+
// Return the appropriate zero if known.
if (HONOR_SIGNED_ZEROS (m_type) && zero_p ())
{
It changes when
long double foo (long double x)
{
if (x != 25.0L)
return 16.0L;
return x + 17.0L;
}
is simplified from evrp to dom2, but perhaps it is ok doing it in dom2 because
the result of the addition would at runtime go through libgcc which would most
likely use 0.0 as the other half.
But perhaps it could matter in other cases.
