http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994
--- Comment #9 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to jos...@codesourcery.com from comment #7)
> An example of MPC not following all the Annex G special cases is that
> catanh (1 + i0) is specified in Annex G to return Inf + i0 with
> divide-by-zero exception, but at least with my MPC installation it returns
> Inf + iNaN. I haven't tried to check how MPFR handles special cases; the
> issue with MPC is simply something I noticed incidentally while fixing
> glibc libm handling of various <complex.h> functions.
Thanks (I assume you reported it to MPC, so that will be one fewer issue in a
few years :-). I believe there are far fewer special cases (and thus risks)
with MPFR, but that would indeed require a suitable testsuite for all functions
for which we enable it (at least if MPFR doesn't already have such a testsuite,
and maybe even then, to make sure we call it properly).
> > I was wondering about that last point. Couldn't we replace:
> >
> > x=sin(Inf);
> >
> > with:
> >
> > x=NaN;
> > errno=EDOM; // only if flag_math_errno
>
> errno is typically a macro....
That's why I was mentioning front-end help... There should be ways to set errno
to EDOM faster than calling sin(Inf).
> > volatile double f=NaN+NaN; // if flag_trapping_math, something to raise
> > invalid
> > (make sure we don't recursively try to propagate the constant there, so
> > maybe
> > the NaN argument should be volatile)
>
> I think you mean 0.0 / 0.0 or Inf - Inf or similar; NaN+NaN doesn't raise
> an exception if the NaNs are quiet NaNs.
Yeah, any of those. I was inspired by glibc, which has for instance:
double
__fdim (double x, double y)
{
int clsx = fpclassify (x);
int clsy = fpclassify (y);
if (clsx == FP_NAN || clsy == FP_NAN
|| (y < 0 && clsx == FP_INFINITE && clsy == FP_INFINITE))
/* Raise invalid flag. */
return x - y;
which looks like it expects QNaN-QNaN to set the invalid flag.
