https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, regarding the behavior around DBL_MAX or -DBL_MAX, consider say:
__attribute__((noipa)) double
foo (double eps)
{
double d = __DBL_MAX__ + eps;
if (d == __DBL_MAX__)
return eps;
return 0.0;
}
The exact range (tested with just trying to call the function with appropriate
constants) is
[-0x0.fffffffffffff8p+970, 0x0.fffffffffffff8p+970], the function for those
boundary
values still returns that value, while for nextafter of the former towards -inf
(-0x0.8p+971) or nextafter of the latter towards +inf (0x0.8p+971) it already
returns 0.
GCC trunk before r13-6549 would compute obviously incorrectly
[frange] double [0.0 (0x0.0p+0), 0.0 (0x0.0p+0)]
and miscompile it.
r13-6549 computes
[frange] double
[-1.9958403095347198116563727130368385660674512604354575415e+292 (-0x0.8p+972),
+Inf]
which is conservatively correct, but especially the +Inf side way too large.
With an untested patch I'm going to attach momentarily we get instead
[frange] double
[-1.9958403095347198116563727130368385660674512604354575415e+292 (-0x0.8p+972),
1.9958403095347198116563727130368385660674512604354575415e+292 (
0x0.8p+972)], which is still wider than needed, but at least finite.
