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

[Tim Prince]

IainS wrote:
> 
> 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
I'll try making <fenv.h> the primary implementation for rounding 
control.  <fenv.h> doesn't cover underflow mode.  I don't suppose anyone 
cares that <fenv.h> is likely to work only for glibc targets, while 
<xmmintrin.h> (for SSE only) doesn't depend on glibc.  I haven't seen 
any examples of autoconf to choose between <fenv.h> and <xmmintrin.h>.