Re: [PATCH] apply transformation on Darwin platform: pow(10, x) ―> __exp10(x)

[Chandler Carruth]

On Sat, Dec 21, 2013 at 4:52 PM, Nick Lewycky <nlewycky at google.com> wrote:

> On 11 December 2013 17:58, Yi Jiang <yjiang at apple.com> wrote:
>
>> It was reverted due to a LTO bug. I resubmitted it in r197109.
>>
>
> Hi Yi! I'm replying here because there was no email sent for the commit of
> r197109.
>
> This broke a number of tests, such as python's ujson library when built at
> -O2:
>
>     def test_numericIntFrcExp(self):
>         input = "1.337E40"
>         output = ujson.decode(input)
>         self.assertEquals(output, json.loads(input))
>
> Their string-to-float parsing logic does a pow(10.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).
>
> 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.
>
> Let me know if you need help producing a testcase for where it doesn't
> produce bit-exact output.
>

So it turns out this is a glibc bug. =] I think its this one:
https://sourceware.org/bugzilla/show_bug.cgi?id=13884 Here is how anyone
crazy enough to test it can test it out:

First, I'll assume you're on Linux, and have glibc 2.15 installed. Most do.
You can check like so:
% /lib/libc.so.6
GNU C Library stable release version 2.15, by Roland McGrath et al.
<snip>

Ok, to reproduce this bug, download the ujson module here:
https://pypi.python.org/packages/source/u/ujson/ujson-1.33.zip#md5=8148a2493fff78940feab1e11dc0a893

Unzip it, and build it with:
% unzip ujson-1.33.zip
% cd ujson-1.33
% CC=/your/path/to/clang python setup.py build

Next, run the python interpreter pointed at this just-built DSO:
% PYTHONPATH=./build/lib.linux-x86_64-2.7 python
>>> import ujson
>>> ujson.decode("1.337E40")
1.337000000000021e+40

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:
% PYTHONPATH=./build/lib.linux-x86_64-2.7 /path/to/glibc-2.18/lib64/
ld-2.18.so python
>>> import ujson
>>> ujson.decode("1.337E40")
1.337e+40

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.


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.

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.

Sorry for all of the trouble. =[
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131227/b87ce757/attachment.html>