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

[Tim Prince]

IainS wrote:
> 
> On 24 Aug 2009, at 18:28, Tim Prince wrote:
> 
>> IainS wrote:
>>> On 24 Aug 2009, at 17:58, Tim Prince wrote:
>>>> 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>.
>>> well.. there are several targets without glibc including Darwin (my 
>>> base for testing) so that might not be an ideal solution either.
>>> a generic method for this is the essence of my question 2.
>> <fenv.h> should be a more generic method than <xmmintrin.h> for 
>> rounding mode control.  If I were using Darwin, I would want to see it 
>> working (maybe it does, or could, with adjustment of gcc build?).  If 
>> I were to continue to implement more of IEEE_ARITHMETIC, I might 
>> expect to depend on <fenv.h>.
> 
> whilst fenv.h is present on Darwin... AFAICT the potential use of the 
> fenv_t to access unspecified FP environment (e.g. the Non-IEEE bit I 
> mention above) is outside the specified content e.g. 
> http://www.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html
> (please correct me if this is rubbish).
> 
> Since fenv.h is outside of, and uncontrolled by, gcc - trying to modify 
> it on Darwin is likely to be between a non-starter and an extreme uphill 
> struggle.
> 
> If access to the "flush to zero" function was implied by some standard 
> to which compliance was claimed, then perhaps some pressure could be 
> applied to implement it...
> 
> what I'm driving at is that there are escapes for different archs. 
> elsewhere in gcc - that end up with the .md files -- how do we access 
> that functionality from within libgfortan (or am I on the wrong track 
> completely?)
> 
> cheers,
> Iain
<fenv.h> doesn't address underflow mode, so I'm using the SSE-only 
<xmmintrin.h> for that; it would require replacement for PPC targets.
<fenv.h> or <xmmintrin.h> work equally well for rounding modes on SSE 
(as I tested on linux x86_64), with <fenv.h> covering more architectures 
(including x87), but fewer SSE targets.
<fenv.h> should have more convenient coverage of certain other 
IEEE_ARITHMETIC intrinsics.  If there are cases where it goes down to 
.md as a basis, that would make me optimistic that such cases would work 
for multiple gfortran targets.