[PATCH, gfortran testsuite]: Do not load denormals in gfortran.fortran_torture/intrinsic_nearest.f90

[IainS]

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, and  
> it clearly requires target-dependent code.
> I'll work on this.  If it doesn't fit under the size limitation for  
> not requiring copyright assignment, I'd be glad to have someone  
> else propose it for quicker adoption, as my current employer won't  
> reaffirm my prior FSF copyright assignments.  Judging by past patch  
> submissions, it might not be adopted until I retire anyway, and by  
> then there should be improved hardware support for gradual underflow.
>
> I understood there was a fairly strong consensus in the gcc  
> community that abrupt underflow should be coupled with -ffast- 
> math.  I could argue that this decision isn't entirely appropriate  
> now that auto-vectorization and OpenMP are well supported, and the  
> performance implications are larger than for scalar code on current  
> targets, but I'm not looking for a flame war.

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