Issue #68 resolved

long double

Armin Rigo
created an issue

The tests for the "long double" type fail on PowerPC: a "long double" there has more precision, but not more exponent range.

The tests also fail on ARM (unknown reason so far).

Comments (7)

  1. Armin Rigo reporter

    s390x: looks like sinl() is broken in this architecture. Try to write a C program that does the same thing, i.e. sinl(1.23), and print the result: it seems that we get 1.23, which is bogus.

    sparc: calling sinl() in C code gives a illegal instruction. That looks even more broken to me.

    I guess you can add some py.test.skip() on these two architectures.

  2. Armin Rigo reporter

    Then you need to debug the C-compiled extension modules by hand to figure out why apparently the same C code doesn't work here... :-(

  3. Vincent Bernat

    I am trying to tackle this very bug on Sparc (which triggers a SIGILL). With a debugger, I notice that sinl is aliased on sin on such a platform, while it shouldn't. In fact, the tests are not linking against libm as they should. When linking them to libm, the bug vanishes (and a debugger confirms that it uses the appropriate sinl implementation, the one from ldbl-128).

    I suppose that the appropriate sinl is not present due to inappropriate linking but some part of the glibc was using the weaker sinl aliased to sin and therefore, this was the one used. The generated assembly is always:

       1052c:       40 00 40 b6     call  20804 <sinl@plt>
       10530:       01 00 00 00     nop 
       10534:       00 00 00 10     illtrap  0x10
    

    I don't know the Sparc ABI, but I suppose that the compiler is expecting to return a long double and therefore, the illtrap instruction should be skipped but because the library only returns a double, we get the illtrap. Or something around that.

    Linking the appropriate tests against libm as they should makes the tests work on both Sparc and S390x (the two platforms where the tests were failing). I'll come with a tested patch shortwhile.

  4. Vincent Bernat

    After reading a bit how cffi works, it seems that illtrap 0x10 is in fact an unimp with the size of the returning data. So, it explains why we get a trap when we get doubles instead of long doubles.

  5. Log in to comment