Bug 110240

Memcheck currently makes two kinds of approximations when checking floating
point code.  The propagation of uninit bits, and the main opcode results, both
assume 64-bit round-to-nearest mode.  See
http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits . 
[Thank you for the documentation.]  It would be better for memcheck to make only
one of these approximations: propagate the uninit bits through floating point
operations using a replacement strategy [if memcheck must], but give the main
opcode results as specified by the user code.

If the user code has gone to the trouble of changing the precision, rounding
mode, or exception control flags, then probably it was for a very good reason. 
Numerical analysis has decades of published peer-reviewed experience in dealing
with floating point arithmetic.  (IEEE 754 itself is a leading example.)  When
memcheck deviates from use of explicit IEEE 754 features, then the result is low
confidence in memcheck because the main answers are wrong under memcheck.

In theory the uninit bits and the main results could become inconsistent with
each other, but it will matter much less than not getting the right main answer.
 As an easy special case, if memcheck performs a default fixup of a main result
then propagation of uninit bits stops anyway:  there are no uninit bits in NaN,
infinity, or zero.  Moreover, the occurrence of uninit bits with non-default
precision/rounding/flags is expected to be lower than in general because such
cases already have received extra programmer attention, as evidenced by the
choice of non-defaults.

If numerical analysis code already tends to be so clean, then why would the user
run memcheck anway?  In order to take advantage of checking for uninit and
malloc/free errors in input/output, visualization, graphical user interface,
threading, and general system calls.  But please give the right main answers.