[ <-- Back ]
FP bug 20110305
Reporter: Sebastian Hütter
Affects the following:
manipulation, jQuery calendars, and similar. Possibly also other
functions that use high precision numbers in complex calculations.
Builds: All regular
builds. Athlon XP build unaffected.
inaccuracies in compiled code. MSVC specific. Should not occur as
compile flags are already in place on Tracemonkey/nanoJIT to enforce
accuracy/mitigate MSVC++ errors, but apparently higher functions still
suffer from intermediate rounding when variables are passed on.
By default, the compiler uses the coprocessor's 80-bit registers to
hold the intermediate results of floating-point calculations. This
increases program speed and decreases program size. Because the
calculation involves floating-point data types that are represented in
memory by less than 80 bits, however, carrying the extra bits of
precision (80 bits minus the number of bits in a smaller floating-point
type) through a lengthy calculation can produce inconsistent results.
In addition, using fast FP for overlying functions may downcast
intermediate computation results, causing subsequent errors: the
compiler will typically attempt to maintain at least the precision
specified by the source code. However, in some instances the compiler
may choose to perform intermediate expressions at a lower precision
than specified in the source code.
Apply proper rounding of large numbers when passing them from one
function to the next. This can be done globally or per-function.
- 3.6.15 and later will be built with a global solution, to cut this
bug short for any yet-unknown other functions also suffering from
precision loss or rounding errors.
This may cause a small speed penalty as a tradeoff for accuracy, since
intrinsics will be disabled for floating point functions, always doing
a complete function call instead of passing the values directly to the
- Critical-path libraries will not be changed as they don't seem to
be affected by this problem, to keep maximum efficiency.
- 3.6.16/4.0.6 and later will be built with global fast floating point
model enabled again like before, to maximize efficiency. To prevent
this bug, correcting a makefile mistake for js by adding CXXFLAGS +=
-fp:precise in addition to the (already present) CFLAGS (js is
mostly/all C++; flag wasn't picked up)
[ <-- Back ]