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

[Uros Bizjak]

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. boz_9.f90 testcase fails on alpha due to alpha's somehow
>> weird FP unit that requires software assistance to properly handle
>> denormals. I believe that the test was not meant to check for various
>> hardware oddities, so attached patch replaces denormals with some
>> other otherwise sane meaningless floating-point values.
>>      
> Indeed, for the test case it can be any number. (In real world programs,
> however, it is often used to write NaN/INF etc. - even though it is not
> portable. But since when do programmers care about portability ;-)
>    

Exactly the same problem happens in intrinsic_nearest.f90. 0x007fffff is 
IEEE single denormal and this upsets alpha's FP constant loading mechanism.

For interested readers, here is what happens when IEEE single denormals 
are loaded in alpha, see section 2.2.6.1, S_Floating from "Alpha 
Architecture Handbok, v4" [1]:

When IEEE single ("S_Floating") is loaded from memory, it is 
automatically translated to IEEE double ("T_Floating") with the 
translation as shown in section 4.8.3. Mantissa is copied as-is to 
correct place, but the problem lies in 8-bit memory-format exponent that 
is translated to 11-bit register-format using following table:

Memory <30:23> Register <62:52>
1 1111111      1 111 1111111
1 xxxxxxx      1 000 xxxxxxx (xxxxxxx not all 1’s)
0 xxxxxxx      0 111 xxxxxxx (xxxxxxx not all 0’s)
0 0000000      0 000 0000000

See what happens when denormals are loaded? Instead of loading 
<something>e-44, we just loaded <something_else>e-308. Without _ANY_ 
exception, that is, and this is silicon bug, plain and simple. Perhaps 
some other rocket is waiting to self-destruct... [2]. ;)

Lessons learned? Don't declare denormals if you want portable code.

</rant>

Anyway, attached patch fixes last alpha gfortran failure by removing 
load of denormal constant. IMO the patch doesn't affect the 
functionality of the test.

2009-08-21  Uros Bizjak <ubizjak@gmail.com>

     * gfortran.fortran-torture/execute/intrinsic_nearest.f90
     (test_nearest): Do not load denormal floating point numbers.

OK for mainline, 4.3 and 4.4 ?

[1] http://www.comms.scitech.susx.ac.uk/fft/programming/alphaahb.pdf
[2] http://en.wikipedia.org/wiki/Ariane_5_Flight_501

Uros.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: a.diff.txt
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20090821/4d7a038c/attachment.txt>