RFC: signaling NaNs, intrinsic modules, ieee_arithmetic

[Asher Langton]

Hi all,

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.  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.

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?

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?


Thanks,
Asher