This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [PATCH, gfortran testsuite]: Do not load denormals in gfortran.fortran_torture/intrinsic_nearest.f90
On 24 Aug 2009, at 03:42, Tim Prince wrote:
IainS wrote:
On 23 Aug 2009, at 01:26, Tim Prince wrote:
Steve Kargl wrote:
On Sat, Aug 22, 2009 at 07:20:48AM -0700, Tim Prince wrote:
N.M. Maclaren wrote:
On Aug 21 2009, Uros Bizjak wrote:
On 08/21/2009 07:09 PM, Tobias Burnus wrote:
It is not nice to upset FP hardware of various target
architectures by
generating denormalized single-precision FP numbers [1] in the
testsuite. ...
It does look dangerous to generate specific bit patterns which
are likely to break with options such as -ffast-math.
Most HPC systems use hard underflow, because it is faster.
This is likely to change a year a so from now, no doubt
influenced by gfortran not having adequate provision to control
underflow setting, and gcc programmers not caring to deal with it.
Tim,
You know where to find the source code for GCC. I suspect
that more than one person will be indebted to you when you
submit your patch that addresses this issue.
I suppose the least controversial part of this would be to supply
the IEEE_ARITHMETIC subroutines IEEE_SET_UNDERFLOW_MODE and
IEEE_GET_UNDERFLOW_MODE in libgfortran, as it looks
straightforward in current gcc/gfortran with iso_c_interop for
the i386/x64 platforms. I don't have any other targets available
to test
I'm willing to stick my neck out to try and replicate what you do
on i386/x64 on PowerPC (at least G4 and G5 which I have access too).
( but I might need help :-) )
Iain
I put an initial version of get/set underflow and rounding modes
for -fpmath=sse with a rudimentary test driver in
http://sites.google.com/site/tprincesite/Home/gfortran-ieee-arithmetic
On my target, it turned out that -ffast-math doesn't set abrupt
underflow.
Thanks Tim,
That looks as brief as I'd expect (given access to the assembly
language necessary to manipulate the chip directly).
(it would be pretty similar on PPC [set/clear a bit in a control reg]
--- minus the issues below).
I understand the floating point, and the assembly language mechanisms...
... and I'm partially familiar with the layout of gcc.
There are three things I need to understand better:
1/
Yesterday I reviewed (briefly) the options on the PowerPC target:
.. there is a bit in the status reg. that sets "non-IEEE" mode.
One side-effect of setting that bit is that flush-to-zero is
*allowed* for de-normalized numbers.
However:
(a) it does not seem that such an action is mandatory on the setting
of the bit;
(b) I need to ascertain what other side-effects might be allowed from
setting it.
In other words, there isn't a "set flush-to-zero" bit per se.
Possibly, it might be that on all commonly used chips that is the
only action of the "non-IEEE" bit (need to check and implement a way
of distinguishing).
It is, however, certain that there are differences in handling it
between at least two older PPC variants (603e and 604).
Possibly a can of wriggly things here - so (2) is essential.
2/
The way in which libgfortran handles target-specific code.
3/
Perhaps, especially in light of (1) above, someone could point me at
a place to download the specific sections of the spec.
... so that I can read how to handle non-compliance and partial
compliance on a particular chip.
Google of IEEE_SET_UNDERFLOW_MODE was not especially revealing (it
mainly turns up compiler documentation talking about the application
to that implementation).
cheers,
Iain