[ This is a spin-off of bug 358569. ] The bug shows 358569 that broken state of Floating Point Unit is detectable at least in double->string conversion. It would be nice if at least a debug build would give a warning about it to developers to notice.

See also bug 360247 for a relevant discussion.

Something like this?

Keith, could you check if a debug build indeed prints a warning? I have no idea how to check this on Linux besides injecting some inline assembly...

Patch to commit: the previous version did not have a trailing semicolon after fprintf.

I committed the patch from comment 4 to the trunk: Checking in jsdtoa.c; /cvsroot/mozilla/js/src/jsdtoa.c,v <-- jsdtoa.c new revision: 3.37; previous revision: 3.36 done

(In reply to comment #3) > Keith, could you check if a debug build indeed prints a warning? Sorry, I cant test this. I'm traveling this week. Also, I reinstalled my MSVC env. But, it does appear to be correct. It will inform the developer of the problem.

i hit this just starting firefox, i selected a profile and got "Minefield Add-on Updates", by the time i got this window, i had this message. as you can see, i don't have any plugins loaded, and the only extension i have is leakmon.

this warning is hit with no plugins and no extensions on linux when downloading anything from https://ftp.mozilla.org

+ if (d != 0.0) { this does not seem right according to papers: http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm In other words, if you do a calculation and then do this comparison: if (result == expectedResult) then it is unlikely that the comparison will be true. If the comparison is true then it is probably unstable – tiny changes in the input values, compiler, or CPU may change the result and make the comparison be false. Comparing with epsilon – absolute error Since floating point calculations involve a bit of uncertainty we can try to allow for this by seeing if two numbers are ‘close’ to each other. If you decide – based on error analysis, testing, or a wild guess – that the result should always be within 0.00001 of the expected result then you can change your comparison to this: if (fabs(result - expectedResult) < 0.00001) The maximum error value is typically called epsilon.

for |d| get values of 0.5 - 0.8 which seems big for "normal" rounding error

fwiw, I just saw this warning on the trunk (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070105 Minefield/3.0a2pre) when downloading http://www.oersted.co.jp/~emk/2007/01/fx-351949.zip (see bug #351949 comment #21) to disk.

according to the gcc macro, the FPU is in double precision state when the warning occurs.

I'm going to verify that we warn on this issue, as I see the warning. as for the warning I'm seeing when downloading that zip file, see bug #366848

For what it's worth, I've seen this warning on Linux/i686.

The warning occurs with this statement. var value = (0.123456).toPrecision(4); I don't think this is intended behaviour.