Tim Prince wrote:
[EMAIL PROTECTED] 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
