This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: RFC: signaling NaNs, intrinsic modules, ieee_arithmetic
- From: Tobias Burnus <burnus at net-b dot de>
- To: Asher Langton <langton2 at llnl dot gov>
- Cc: fortran at gcc dot gnu dot org
- Date: Sat, 28 Jul 2007 16:30:00 +0200
- Subject: Re: RFC: signaling NaNs, intrinsic modules, ieee_arithmetic
- References: <1953a4560707271141o43543e2dj3eea3bb1fcbcb9a7@mail.gmail.com>
Hi Asher, hi all,
Asher Langton wrote:
> I've been working on a patch for -finit-local-zero (as well as other
> options, including runtime control of initialization:
> http://gcc.gnu.org/ml/fortran/2007-06/msg00028.html) and thinking
> about how to implement the IEEE math intrinsic modules, and I have a
> few questions/issues:
>
> 1) As far as I can tell, it's not currently possible to build an
> initialization gfc_expr representing a signaling NaN. MPFR has a
> set_nan option, but it doesn't distinguish between signaling and quiet
> NaNs. When we call real_from_mpfr (in trans-const.c), all NaNs end
> up quiet. For debugging purposes, I'm intercepting all MPFR NaNs in
> trans-const.c:gfc_conv_mpfr_to_tree and forcing them to be signaling.
> The proper solution would probably be to ask the MPFR folks to add
> set_snan and set_qnan options, and then patch gcc/real.c to take
> advantage of those.
I just did so and the reply can be found at
http://websympa.loria.fr/wwsympa/arc/mpfr/2007-07/msg00118.html
Pre-remarks: IEEE 745 defines a quite and a signalling NaN, which have
(obviously) different bit patterns.
Signalling and quiete NaN are also in the currently being revised
standard "745r" though Wikipedia states: "There were questions about if
signalling NaNs should continue to be required in the revised standard.
In the end it appears they will be left in."
The discussion happend seemingly 2003:
http://www.cs.berkeley.edu/~ejr/projects/ieee754/meeting-minutes/03-02-20.html#signaling
One finds that sNaN had been removed in the draft 0.95 (12 Jan 2003) and
it was restored in 0.96 (21 Feb 2003).
The current draft of 2006 (1.2.5) can be found at
http://www.validlab.com/754R/drafts/archive/2006-10-04.pdf
and still contains sNaN, which implies that removing sNaN was not very
popular ...
Paul Zimmermann wrote:
<quotation>
I'm not sure to really understand your problem:
(1) do you want that MPFR implements two kinds of NaN, quiet and signalling?
(2) or do you want that MPFR NaNs are interpreted as signalling instead of
quiet NaNs (I realize that we do not document which kind of NaN is
produced by mpfr_get_d)?
For (2), it would be quite easy to write a wrapper on mpfr_get_d to convert
quiet NaNs to signalling NaNs.
For (1), this is a more difficult question. Before investing time on this,
I'd like to have a simple definition of quiet and signalling NaNs on which
everybody agrees, and it would be wise to wait the end of the IEEE 754
revision.
</quotation>
> In the meantime, is it worthwhile to hack in a
> temporary fix to create/detect MPFR signaling NaNs? Ideally, I'd like
> to be able to use -finit-real=snan -ffpe-trap=invalid to force an
> exception whenever an uninitialized local real variable is used.
>
Probably it make sense as it will seemingly take a while until we will
see signalling NaN support in mpfr.
> 2) What is the preferred way to implement intrinsic modules?
> Following Brooks's suggestion, I've encapsulated the
> runtime-controlled initialization routines in a intrinsic module.
> I've essentially hard-coded the module (in module.c) as a routine that
> creates all of the necessary gfc_symbols. It should also be possible
> to implement some intrinsic modules as actual Fortran modules in
> libgfortran. Which is preferable?
>
I think both is ok; note that for definition, one can put them in a
*.def file as it is already done for ISO_C_Binding and ISO_Fortran_ENV.
> 3) I'll probably start working on the IEEE math modules
> (ieee_features, ieee_exceptions, ieee_arithmetic) soon. Is anybody
> else working on these?
To my knowledge not.
> Is it worth setting a up a subversion branch to work on this extension?
Good question. With the subversion branch one has the disadvantage that
one had to merge the trunk all the time, but the advantage that it is
easier to test by others. However, if the patch is relatively small or
can be divided in relatively small independent parts, then submitting
them directly is probably the better approach: It makes reviewing easier
than a huge patch, prevents merge problems and is simply more
manageable. But at the end it is also personal style.
Tobias