[Valgrind-developers] [Valgrind-users] Obliteration of FPU mask

[Nicholas N. <n.n...@gm...>]

[Sorry, I forgot to CC the list the first time]

On Mon, Mar 9, 2009 at 5:50 AM,  <san...@gm...> wrote:
> Hi,
>
> I have just started using Valgrind, it's a fantastic tool!
>
> Among other things, I am concerned about potential floating
> exceptions, so I set an adequate mask. The point is that most of the
> operations that raise a FPE when executing normally, do not raise it
> when executing through Valgrind. I found no info about it, so I do not
> know if that is the intended behaviour (which I guess is not very
> desirable). When using Valgrind, NaNs, infs, underflows, etc., wander
> around like happy beasts.

The FP limitations are in the manual:
http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits :

As of version 3.0.0, Valgrind has the following limitations in its
implementation of x86/AMD64 floating point relative to IEEE754.

Precision: There is no support for 80 bit arithmetic. Internally,
Valgrind represents all such "long double" numbers in 64 bits, and so
there may be some differences in results. Whether or not this is
critical remains to be seen. Note, the x86/amd64 fldt/fstpt
instructions (read/write 80-bit numbers) are correctly simulated,
using conversions to/from 64 bits, so that in-memory images of 80-bit
numbers look correct if anyone wants to see.

The impression observed from many FP regression tests is that the
accuracy differences aren't significant. Generally speaking, if a
program relies on 80-bit precision, there may be difficulties porting
it to non x86/amd64 platforms which only support 64-bit FP precision.
Even on x86/amd64, the program may get different results depending on
whether it is compiled to use SSE2 instructions (64-bits only), or x87
instructions (80-bit). The net effect is to make FP programs behave as
if they had been run on a machine with 64-bit IEEE floats, for example
PowerPC. On amd64 FP arithmetic is done by default on SSE2, so amd64
looks more like PowerPC than x86 from an FP perspective, and there are
far fewer noticeable accuracy differences than with x86.

Rounding: Valgrind does observe the 4 IEEE-mandated rounding modes (to
nearest, to +infinity, to -infinity, to zero) for the following
conversions: float to integer, integer to float where there is a
possibility of loss of precision, and float-to-float rounding. For all
other FP operations, only the IEEE default mode (round to nearest) is
supported.

Numeric exceptions in FP code: IEEE754 defines five types of numeric
exception that can happen: invalid operation (sqrt of negative number,
etc), division by zero, overflow, underflow, inexact (loss of
precision).

For each exception, two courses of action are defined by IEEE754:
either (1) a user-defined exception handler may be called, or (2) a
default action is defined, which "fixes things up" and allows the
computation to proceed without throwing an exception.

Currently Valgrind only supports the default fixup actions. Again,
feedback on the importance of exception support would be appreciated.

When Valgrind detects that the program is trying to exceed any of
these limitations (setting exception handlers, rounding mode, or
precision control), it can print a message giving a traceback of where
this has happened, and continue execution. This behaviour used to be
the default, but the messages are annoying and so showing them is now
disabled by default. Use --show-emwarns=yes to see them.

The above limitations define precisely the IEEE754 'default'
behaviour: default fixup on all exceptions, round-to-nearest
operations, and 64-bit precision.

Nick