in ubuntu 14.04 i386 with glibc2.19 we are seeing wrong results for calls to sin that don't appear with 2.18: https://launchpadlibrarian.net/167193519/buildlog_ubuntu-trusty-i386.python-cffi_0.8.1-1ubuntu3_FAILEDTOBUILD.txt.gz > assert library.sin(12.3) == math.sin(12.3) E assert 0.8444952930965295 == -0.26323179136580094 I failed to create a testcase for as it seems to depend on global state. to reproduce via the packages in 14.04 o apt-get source python-cffi cd python-cffi* apt-get build-dep python-cffi gdb --args python2.7 -m pytest testing/test_function.py testing/test_zdistutils.py from what I can tell with my limited assembly skills is that it computes the right result but clobbers it in libc_feresetround_387_ctx 0xf7da2028 in libc_feresetround_387_ctx (ctx=0xffffa0a0) at ../sysdeps/i386/fpu/fenv_private.h:452 452 if (__glibc_unlikely (ctx->updated_status)) 3: $st2 = 0.26251239976915330398554715429781936 2: $st1 = 7.2970669792260636173761756580191662e-08 1: $st0 = 0.84449529309652948683151407749392092 $st2 contains the right result, but its not returned to $st0 after the function returns so cffi gets the wrong result.
hm no $st2 does not contain the right result but its related to the rounding context retval in ../sysdeps/ieee754/dbl-64/s_sin.c:391 does contain the result, after that it jumps to the rounding context after which the result is wrong. some better debugging instructions for cffi: gdb --args python2.7 -m pytest testing/test_function.py testing/test_zdistutils.py break sin # calls sin 8 times with before it x=1.23 reaches the problematic case of x=12.3 ignore 1 8
I'm unable to reproduce that. Compiler bug?
possible, I just rebuilt the packaged libc with -Og instead of -O2 and the issue disappears... the compiler I use is is 4.8.2-16ubuntu2 20140221 (r208010) from the gcc-4_8-branch.
I have bisected the issue to this commit: commit 392dd2de03c054b1b32358561570be14f55e9ae9 Author: Siddhesh Poyarekar <siddhesh@redhat.com> Date: Fri Dec 20 16:01:03 2013 +0530 Consolidate code to compute sin and cos from lookup tables
but building the commit with gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-11ubuntu1) fixes it again, really does smell like a compiler bug
gcc-4.9 (Ubuntu 4.9-20140303-0ubuntu3) 4.9.0 20140304 (experimental) [trunk revision 208299] works too, so its just 4.8.2 thats broken
r204212 of gcc fixes it http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02422.html though it seems like an accidental fix be removing the -fregmove pass building with gcc 4.8.2 and -fno-regmove fixes the issue too.
Resolved as a compiler bug, not a glibc bug.