paranoia on PowerPC

[Joel Sherrill]

Tim Prince wrote:
> ralf.corsepius@rtems.org wrote:
>> On Mon, 2007-07-23 at 19:00 -0700, Tim Prince wrote:
>>
>>> Should we know which version of Paranoia this is?
>>
>> It's the version having been integrated into the rtems source tree many
>> years ago:
>> http://www.rtems.org/cgi-bin/viewcvs.cgi/rtems/testsuites/samples/paranoia/paranoia.c 
>>
>>
> Interesting, I wasn't aware there were multiple C versions of the 
> benchmark.  I spent a lot of time in the early years making the 
> Fortran version work correctly on a bunch of architectures.  The only 
> one remaining, where paranoia was particularly buggy, was 387.  Having 
> to run with -ffloat-store is a symptom of bugs in paranoia.  I found 
> the netlib C version sufficiently different to make it hard to search 
> for similar bugs.  I assume the C is testing only double.
The one in RTEMS tree is from Cygnus years ago.  Since RTEMS targets
embedded systems, paranoia is a good check that the FPU is initialized
OK and things are working.  We don't change the code except to keep it
compiling.
>>>   or guess which flaw is reported? I'd be happy to check Paranoia on 
>>> a platform to which I have access, with a more interesting gcc 
>>> version, but you've given little to go on.
>> cf. the thread starting at
>> http://rtems.rtems.org/pipermail/rtems-users/2007-July/018611.html
>>
> IEEE compliance implies that processors should default to settings 
> which will pass those rounding tests.  They catch the behavior of 387 
> double when run in default 64-bit precision mode.  387 has to be set 
> to 53-bit mode to pass the rounding tests, but the resulting 
> inconsistencies in exponent range will produce paranoia failures 
> elsewhere.
> If I recall correctly, problems paranoia had with fused multiply-add 
> were due to its source code bugs.  It doesn't have specific tests for 
> variations in rounding behavior of fma, but bugs in the extra 
> precision tests would show up.  As hinted previously, you could use 
> these tests to see whether a gcc option to not use fma is working.  
> IA-64 has fma behavior similar to Power.  Now that fma is being 
> codified by IEEE, it would be interesting to have corresponding checks 
> for that added.
I don't know if this would matter or not.  I dug out an old RTEMS
release which used gcc 3.2.3 and gdb 5.2.  They exhibited the same
behavior.

So it isn't a new issue.  The question is back to whether this was a
known issue on the PowerPC.  Does anyone care? Is it a problem?
Should I file a PR?

--joel