This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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: GFortran Flush (Denormals) to Zero Flag


On Apr 14 2010, Tobias Burnus wrote:
On 04/14/2010 03:25 PM, Tim Prince wrote:

I suppose the reasons for those being defined as intrinsics include
that they would usually require platform-dependent implementation for
each platform.  These work on targets which have -mfpmath=sse and
conditionally implement additional intrinsics on the subset of those
platforms where fenv is present.

I think the full IEEE support will be done partially directly in the front end, where one queries the target system for capabilities - and partially in the libgfortran library.

While I haven't looked into it in detail, I am certain those are the two easiest parts! There are two other, utterly evil, ones:

   1) Finding out what each implementation actually delivers - there,
you need to start by finding out what symbols it defines, follow that
up by finding (!) and reading the platform-specific documentation, and
then discovering how much of that is speculative fiction (if not outright
fantasy).  For example, a header might be supported only with a particular
C compiler option - and the facilities fail, quietly, if you use different
ones.

   2) Finding out how much of gcc's optimisation and code-generation
produces code that is incompatible with full IEEE support and providing
alternative code for that case.  That is both where the code uses
hardware facilities that don't support full IEEE and where the generated
code that takes an incompatible short cut. That's a lifetime task, even
for a bright-eyed and bushy-tailed teenager!

There are multiple reasons that IEEE has not yet been picked up: It is
not trivial as target hooks have to be added. Also in terms of lines of
code, implementing IEEE is a larger project. The demand of IEEE has been
rather low so far (even though many commercial compilers have it).

Well, they have something that purports to be it. Some of them will have probably done a good job; others may have used the liberty provided to an implementation to produce an unusable result. Has anyone who really knows about this area done a proper investigation?

Talking about IEEE: I have problems understanding when IEEE applies and
when it does not. In terms of the compiler, -mieee, -ffinite-math-only
changes which optimizations are allowed. But the bigger question is:
When can one assume Fortran model numbers and when full IEEE numbers?

Quite. And IEEE flags. And signed zeroes.


Well, the last is easy.  The Fortran standard comes very close to saying
"don't be silly".

For instance, being based on model numbers, gfortran uses the
-fcx-fortran-rules option: "Complex multiplication and division follow
Fortran rules.  Range reduction is done as part of complex division, but
there is no checking whether the result of a complex multiplication or
division is "NaN + I*NaN", with an attempt to rescue the situation in
that case."

There are much worse problems with complex multiplication and division and the IEEE model!


Regards, Nick Maclaren.


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