Re: PING! [2/4] [patch, middle-end] Consolidate GCC, GFortran MPFR-to-tree functions.

[Brooks Moses <brooks dot moses at codesourcery dot com>]

Ian Lance Taylor wrote:
> Brooks Moses <brooks.moses@codesourcery.com> writes:
> > 2007-04-06  Brooks Moses  <brooks.moses@codesourcery.com>
> >
> >          real.c (mpfr_from_real): Handle Inf and NaN, and allow the
> >          rounding mode to be specified by the caller.
[snip]
> > +  if (mpfr_nan_p (m))
> > +    {
> > +      real_nan (r, "", 0, TYPE_MODE (type));
> > +      return;
> > +    }
>
> Is it correct to generate a signalling NaN here?  It seems to me that
> a quiet NaN would be a more reasonable default.
>
> This patch is approved with those changes, pending an answer to the
> NaN question.

This is a copy of the code from fortran/trans-const.c -- I'm essentially 
just consolidating existing code, not doing anything new.  However, 
certainly if that's an error, it should be fixed.

Jerry, the original of this in trans-const.c was yours.  What's your 
opinion on the matter -- was there a strong reason for using an SNaN 
instead of a QNaN here?

Nominally, I would think that in the Fortran front-end the only place 
that we'll be getting a NaN in a real number is in response to an 
"invalid" mathematical operation, and thus a QNaN would indeed be more 
appropriate [1].  Thus, I plan to convert this to a QNaN and redo the 
regression tests, and go ahead and commit that (assuming it passes) 
after 48 hours if nobody objects.

- Brooks


[1] http://steve.hollasch.net/cgindex/coding/ieeefloat.html has a good 
simple explanation of the distinction.