Re: [fortran, patch] Add Fortran 2003 IEEE intrinsic modules

["N.M. Maclaren" <nmm1 at cam dot ac dot uk>]

On Nov 21 2013, FX wrote:
> > That's a reasonable decision, but it is actually used at least ten 
> > times as much as everything else put together, possibly a hundred times 
> > as much.
>
> I believe we are in pretty different parts of the community. Around me I 
> rarely see it used, while people check for nans, infinities, and 
> exception flags often. Also, aborting on certain floating-point 
> exceptions is widely used as a debugging aid.

Probably.  My experience is more with Fortran, generally, including
portable Fortran and HPC, than with gfortran as such.  It is only very
recently that IEEE 754 support has been complete enough in most hardware
(let alone software!) to be worth considering for even moderately portable
programs.  This is related to the vast reduction in architectural diversity
that we have seen over the past couple of decades.

The people who use flush-to-zero most are the 'HPC community', which
includes a very high proportion of scientific programmers using desktops.
But, as I said, support for IEEE 754 denormalised numbers is becoming less
of a problem, though it was a major obstacle to performance even a decade
ago and still is on some specialist systems and some older ones.

> > However, it is used in the form of selecting hard underflow using a
> > compilation option, and not within the program.  You certainly DO have
> > targets where it would work, even dynamically within the program, and I
> > think that it could be done even on x86.  That isn't the same as it
> > should be done, of course!
>
> Indeed, 387/SSE has flush-to-zero modes. But other APIs do not (glibc, 
> SysV, AIX). I'm perfectly willing to add it, especially to 387/SSE, if 
> given a bit of help (someone to write the assembly code).

As most Fortran compilers were and are specific to a fairly small number
of architectures, and often have a lot of architectural dependence in the
optimisation and libraries, they aren't restricted by glibc and SysV APIs.
IBM has always been an extreme outlier, and POWER used to be the only
hardware on which denormalised numbers were not catastrophically slow
(i.e. they were only 4 times slower, not 100+ times), and poorly supported
in the library.  But that has changed over the past decade,

I would like to offer to write some example code, but it is some years
since I was involved with anything other than x86 or at low levels such
as this, and have a lot else going on.  If I do divert and look at the
x86 in detail, I will certainly post any useful assembler.  Sorry :-(


Regards,
Nick Maclaren.