remainder (%) operator broken (use fdlibm fmod instead of Windows built-in fmod)
Reported by
8998...@gmail.com,
Feb 12 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: Paste this math into developer console: Number.MAX_VALUE % 1.8111139825551001 What is the expected behavior? 0.6471300971016367 What went wrong? The result is NaN and most programs will crash. Did this work before? N/A Chrome version: 56.0.2924.87 Channel: stable OS Version: 6.3 Flash Version: Shockwave Flash 24.0 r0 The second operand is not unique. About 0.3% of all 64 bit floating point numbers (or about 55 quadrillion) also trigger this bug. For the first operand, -Number.MAX_VALUE also works. I did NOT compile this chrome binary myself. It was obtained from https://www.google.com/chrome/browser/desktop/ This bug might be related to VS2015. The last line of chrome://version/ is: Compiler: MSVC 2015 (PGO) The operating system is Windows 8, 64 bit
,
Feb 12 2017
Wow, this is even weirder than my bug. At least for me the result is always the same as long as the operands stay the same, even when it is wrong. Which build are you running?
,
Feb 13 2017
,
Feb 14 2017
,
Feb 14 2017
,
Feb 14 2017
,
Feb 14 2017
sounds like optimizing compiler doing something wrong.
,
Feb 14 2017
I'm checking if this is PGO specific or if it repro in a non-PGO Chrome build.
,
Feb 14 2017
I doubt that this has anything to do with Chrome build. From the issue description this seems pretty clear to be a case of the optimizing compiler kicking in after a short while, and we then execute wrong code. I even suspect that the condition with the remainder operator is being constant folded.
,
Feb 14 2017
Cannot reproduce with 56.0.2924.87, neither compiler seems to produce the wrong result for me. Maybe it's part of a bigger program that triggers the wrong behavior? Can you provide exact reproduction steps?
,
Feb 14 2017
Ah, BTW. this is on Mac. Maybe there's a bug in fmod on Windows?
,
Feb 14 2017
I can repro on 58.0.3012.0, both on the PGO and the non-PGO build, so it's not a PGO specific bug but it might still be a compiler bug.
,
Feb 14 2017
I guess you're running Windows then?
,
Feb 14 2017
Yes, I've no idea how the Dev console works so it's hard for me to debug this, do you know which part of the code is responsible for handling this type of query? I'd like to look at the generated code for it.
,
Feb 14 2017
Since it happens on the console already w/o even being wrapped into a function that needs optimization, it's very, very likely that the bug is in the fmod library function on Windows (which is BTW known to be very buggy already). I guess it's about time that we import fdlibm's fmod instead, so that we can provide a uniform, correct implementation everywhere. Yang, WDTY?
,
Feb 15 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 20 2018
,
Mar 3 2018
Someday during the last year my chrome installation got updated automatically to a version which has been compiled with clang instead of VS2015, so this issue is fixed for me. But I don't know if there are still VS2015-compiled Chrome binaries being distributed, so I can't tell if this issue has been fixed for everyone.
,
Mar 3 2018
Good to know! I don't think new Chrome versions are still built with Visual Studio.
,
Mar 3 2018
Nice. This can be closed then.
,
Mar 3 2018
,
Mar 3 2018
\o/ |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by runem...@gmail.com
, Feb 12 2017To me this only happens with a very rare probability. Running this script: while (true) { if((Number.MAX_VALUE % 1.8111139825551001) != 0.6471300971016367) { console.log("x"); } } doesn't do anything for the first few seconds, before logging "x" about 10000 times in a row.