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