Re: [Valgrind-developers] valgrind and subtle floating point problem

[Vince W. <vi...@cs...>]

On Sat, 24 Mar 2007, Julian Seward wrote:

>
> > On Saturday 24 March 2007 08:23, Bart Van Assche wrote:
> >
> > My opinion is that the art program is flawed: it is never a good idea to
> > compare floating point numbers with the "==" or "!=" operator.  [...]
>
> I agree, floating point comparison is not good.  On the other hand,
> SPEC CPU is designed to be portable and I would be amazed if the SPEC
> folks had not looked into these problems in depth.  Perhaps they
> fixed all problems they encountered in testing, but this one did not
> happen at that time, and it is only triggered by Valgrind's extra
> inaccuracy on x86.  Who knows.

While you would think SPEC would have done a good job picking portable
benchmarks, in actual fact they are a mess.  What passed for acceptable
code ~1998 when the spec2000 codes were frozen just wouldn't fly today.
They've had to release a number of service packs along the way because
probably at least half the original spec2k code release won't compile
with a gcc more recent than 2.8 or so.

Even now, with the most recent spec2k release, you can't compile the
'vortex' benchmark with optimizations turned on with gcc 4.0 or it will
crash on x86-linux.

I do wonder if any of the compiler vendors noticed this problem with art..
you could in theory make your compiler look better on the FP score by
having art finish in half the time if you made sure it ran in 64-bit
rather than 80-bit mode on x86...

For my purposes I hacked the art code and added a few lines of code
at the beginning to force the x87 fpu state to be FPU_DOUBLE (instead of
FPU_EXTENDED) and that is enough to make the valgrind runs match the
actual perf counter runs.

>From what I gather from the document I linked to earlier by Whiteley,
it is only Linux x86 that even shows this behavior; other OSes like
x86-BSD and Windows don't enable extended mode by default.

Thanks for all the help looking into this,

Vince