This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: paranoia on PowerPC


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]