<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 21, 2013 at 4:52 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote"><div class="im">On 11 December 2013 17:58, Yi Jiang <span dir="ltr"><<a href="mailto:yjiang@apple.com" target="_blank">yjiang@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It was reverted due to a LTO bug. I resubmitted it in r197109.<br></blockquote><div><br></div></div><div>Hi Yi! I'm replying here because there was no email sent for the commit of r197109.</div><div><br></div><div>This broke a number of tests, such as python's ujson library when built at -O2:</div>
<br> def test_numericIntFrcExp(self):<br> input = "1.337E40"<br> output = ujson.decode(input)<br> self.assertEquals(output, json.loads(input))</div><div class="gmail_quote"><br></div><div class="gmail_quote">
Their string-to-float parsing logic does a pow(<span class="">10</span>.0, expr) internally, and that's now producing a slightly different result (0x1.3a53c2af670d5p+133 vs. 0x1.3a53c2af6707ep+133 to be exact, or 1.337000000000021e+40 vs. 1.337e+40 in decimal).</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">On the one hand I'd like you to revert this patch (or disable it on linux) because it's breaking some tests, but I think it's more important first to understand what the FP accuracy guarantees are and whether we're allowed to make this transformation even though it will change the exact bit pattern produced and -ffast-math is not enabled.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Let me know if you need help producing a testcase for where it doesn't produce bit-exact output.</div></blockquote></div><br>So it turns out this is a glibc bug. =] I think its this one: <a href="https://sourceware.org/bugzilla/show_bug.cgi?id=13884">https://sourceware.org/bugzilla/show_bug.cgi?id=13884</a> Here is how anyone crazy enough to test it can test it out:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">First, I'll assume you're on Linux, and have glibc 2.15 installed. Most do. You can check like so:</div><div class="gmail_extra"><div class="gmail_extra">
% /lib/libc.so.6 </div><div class="gmail_extra">GNU C Library stable release version 2.15, by Roland McGrath et al.</div><div class="gmail_extra"><snip></div><div class="gmail_extra"><br></div><div class="gmail_extra">
Ok, to reproduce this bug, download the ujson module here: <a href="https://pypi.python.org/packages/source/u/ujson/ujson-1.33.zip#md5=8148a2493fff78940feab1e11dc0a893">https://pypi.python.org/packages/source/u/ujson/ujson-1.33.zip#md5=8148a2493fff78940feab1e11dc0a893</a></div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Unzip it, and build it with:</div><div class="gmail_extra">% unzip ujson-1.33.zip</div><div class="gmail_extra">% cd ujson-1.33</div><div class="gmail_extra">% CC=/your/path/to/clang python setup.py build</div>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">Next, run the python interpreter pointed at this just-built DSO:</div><div class="gmail_extra">% PYTHONPATH=./build/lib.linux-x86_64-2.7 python</div><div class="gmail_extra">
>>> import ujson</div><div class="gmail_extra">>>> ujson.decode("1.337E40")</div><div class="gmail_extra">1.337000000000021e+40<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">
Bad bad bad. Now, go download, build and install glibc 2.18. I'm not going to provide steps here because zomg-i-have-no-clue. Fortunately someone else gave me a nice tarball. Now, run the python interpreter but under glibc-2.18 so it uses that libc implementation:</div>
<div class="gmail_extra"><div class="gmail_extra">% PYTHONPATH=./build/lib.linux-x86_64-2.7 /path/to/glibc-2.18/lib64/<a href="http://ld-2.18.so">ld-2.18.so</a> python</div><div class="gmail_extra">>>> import ujson</div>
<div class="gmail_extra">>>> ujson.decode("1.337E40")</div><div class="gmail_extra">1.337e+40<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Tada! 2.18 was built after the bug mentioned above got fixed and before most of the other bugs relating to exp10 in glibc that I've found were fixed, so that leads me to believe this is it.</div>
<div class="gmail_extra"><br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Ultimately, it seems like there are quite a few bugs being found and fixed in glibc's exp10 family of functions even now. And the bug I mentioned was fixed over a year ago, and yet *many* distributions are still on glibc-2.15. The current ubuntu LTS is still there. It looks like the 2014 LTS will be 2.18, but I suspect it'll be a while for folks to move.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Unless we find a way to determine that a glibc version of at least 2.18 is available on the system, I think we need to disable this optimization on Linux. If anyone has ideas about how to detect this in the Clang driver (without reading contents of files or invoking subprocesses), let me know. Until then, to restore correctness on most people's linux platforms I'm going to unilaterally disable this on Linux hosts.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Sorry for all of the trouble. =[</div></div>