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: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- To: Asher Langton <langton2 at llnl dot gov>
- Cc: fortran at gcc dot gnu dot org
- Date: Tue, 31 Jul 2007 09:46:29 -0700
- Subject: Re: RFC: signaling NaNs, intrinsic modules, ieee_arithmetic
- References: <1953a4560707271141o43543e2dj3eea3bb1fcbcb9a7@mail.gmail.com>
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