Re: RFC: signaling NaNs, intrinsic modules, ieee_arithmetic

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Fri, Jul 27, 2007 at 11:41:41AM -0700, Asher Langton wrote:
> 
> 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.  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.

Yes, I think it is worthwhile.  I suppose you'll want to put a
comment in the code explaining why the hack is needed.  If a
future version of mpfr supports qNaN and sNaN, a comment will
make it easy to find and remove the hack.

> 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 don't have a preference, however, I'd use the method that
simplifies cross-compilers.  This probably means building
the module on-the-fly may have a slight edge.

> 3) I'll probably start working on the IEEE math modules
> (ieee_features, ieee_exceptions, ieee_arithmetic) soon.  Is anybody
> else working on these?  Is it worth setting a up a subversion branch
> to work on this extension?

I'm not aware of anyone working on this feature.  One advantage of
a branch would be that you could make changes without seeking write
after approval of your patches.  If you were working against trunk
and you wanted to check-in a working copy (so you don't lose it),
you'ld have to through the patch submittal and review process.  If
you do go with a branch, use svnmerge to do all your merges and
merge trunk into your branch often.

-- 
Steve