paranoia on PowerPC

paranoia on PowerPC

[Joel Sherrill]

Hi,

In analyzing the output of paranoia, Eric Norum
and I have noticed that when compiled at
default optimization levels, the results
are reported to have a flaw.  When compiled
with no optimization, paranoia reports no flaws.

I tried this with RTEMS running on psim using
gcc 4.2.1.  RTEMS uses newlib.

Eric duplicated the problem on a PowerPC Mac
using gcc 4.0.1. 

We believe this indicates an issue introduced
by gcc optimization.

Given the age of paranoia (the version included
with RTEMS is from Cygnus circa 1993), does this
sound familiar or is this a new issue?

--joel

Re: paranoia on PowerPC

[Andrew Pinski]

On 7/23/07, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
> Given the age of paranoia (the version included
> with RTEMS is from Cygnus circa 1993), does this
> sound familiar or is this a new issue?

What happens if you use -mno-fused-madd option?

Thanks,
Andrew Pinski

Re: paranoia on PowerPC

[Joel Sherrill]

Andrew Pinski wrote:
> On 7/23/07, Joel Sherrill <joel.sherrill@oarcorp.com> wrote:
>> Given the age of paranoia (the version included
>> with RTEMS is from Cygnus circa 1993), does this
>> sound familiar or is this a new issue?
>
> What happens if you use -mno-fused-madd option?

Same result for me using RTEMS on psim.  Eric N. will
have to give a Mac report.

--joel
>
> Thanks,
> Andrew Pinski

Re: paranoia on PowerPC

[Tim Prince]

joel.sherrill@oarcorp.com wrote:
> Hi,
> 
> In analyzing the output of paranoia, Eric Norum
> and I have noticed that when compiled at
> default optimization levels, the results
> are reported to have a flaw.  When compiled
> with no optimization, paranoia reports no flaws.
> 
> I tried this with RTEMS running on psim using
> gcc 4.2.1.  RTEMS uses newlib.
> 
> Eric duplicated the problem on a PowerPC Mac
> using gcc 4.0.1.
> We believe this indicates an issue introduced
> by gcc optimization.
> 
> Given the age of paranoia (the version included
> with RTEMS is from Cygnus circa 1993), does this
> sound familiar or is this a new issue?
> 

Should we know which version of Paranoia this is?  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.

Re: paranoia on PowerPC

[Ralf Corsepius]

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

>   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

Ralf

Re: paranoia on PowerPC

[Tim Prince]

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.
>>   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.

Re: 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

Re: paranoia on PowerPC

[Segher Boessenkool]

>>> Given the age of paranoia (the version included
>>> with RTEMS is from Cygnus circa 1993), does this
>>> sound familiar or is this a new issue?
>>
>> What happens if you use -mno-fused-madd option?
>
> Same result for me using RTEMS on psim.  Eric N. will
> have to give a Mac report.

I tested it (the source from netlib.org, that is) with GCC-2.95,
3.3, and various 4.x on Darwin and Linux, both 32-bit and
64-bit; all versions failed with optimisation without
-mno-fused-madd, and all versions passed with any optimisation
with -mno-fused-madd.  So I would say the only bug is in
paranoia itself (namely, it flags fused multiply-add as a
flaw).

If the RTEMS version of paranoia shows different results, it
probably is time to update it?


Segher

Re: paranoia on PowerPC

[Joel Sherrill]

Joern Rennecke wrote:
>> Given the age of paranoia (the version included
>> with RTEMS is from Cygnus circa 1993), does this
>> sound familiar or is this a new issue?
>>     
>
> Is this related to PR29100?
>   
I don't think so since I was using 4.2.1
and tried that option upon someone else's
suggestion.

FWIW I ran this code on a V7 SPARC and it
also had the same flaw.  Changing the optimization
level did NOT help.  This was with gcc 4.2.1.

--joel

Re: paranoia on PowerPC

[Joern Rennecke]

> Given the age of paranoia (the version included
> with RTEMS is from Cygnus circa 1993), does this
> sound familiar or is this a new issue?

Is this related to PR29100?