This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Nov 21 2013, FX wrote:

Note: Gradual underflow control is implemented as "not supported by the processor" (its SUPPORT function returns false, and the GET and SET procedures abort if you call them), because we probably don't have targets where it would work (and I don't think people use it much, if at all). That's explicitly allowed by the standard.

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

I should have to study the various architectures to remind myself of how
to do it, but there were some which had a simple flag and I am pretty
sure that they are among gfortran's current targets.  How many of the
CPUs support that flag is another matter ....  On at least the x86, it
would have to be done by writing a floating-point interrupt handler,
which I think can be done without privilege and could be made to work.
It wouldn't be a lot of code, but would need some very low-level hacking.

It is getting rarer, as the support of denormalised numbers gets less
direly inefficient and they cause less chaos in the libraries, but
there are still codes that need hard underflow and quite a few algorithms
that work better with it.

Nick Maclaren.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]