[PPL-devel] Fwd: ppl 0.11.2 vs llvm

Enea Zaffanella zaffanella at cs.unipr.it
Sat Aug 6 15:35:40 CEST 2011


Il 06/08/2011 14:14, Jack Howarth ha scritto:
> Roberto,
>    I am rather baffled that you can't reproduce this problem on Linux.
> Attached is a build and make check log from x86_64 Fedora 10 using the
> ppl 0.11.2 release and the binary distribution of the clang 2.9 compilers
> from http://llvm.org/releases/2.9/clang+llvm-2.9-x86_64-linux.tar.bz2.
> With CC set to clang and CXX set to clang++, I see the same failures as
> under the clang compilers from Xcode 4.1 under Lion.
>                   Jack

Hello Jack.

I have downloaded the binaries above on my (Ubuntu) system and I managed
to reproduce the first failure.

This is test08() in tests/Box/affineimage1.cc, compiled with
-DBOX_INSTANCE=ld_r_oc (that is, using long doubles).

If you run the test as follows:

   $ PPL_NOISY_TESTS=1 ./affineimage1

you will get some debugging output.

The relevant bits regarding test08() are the following:
=======================================================================
=== test08 ===
*** box ***
A in [0, 1], B in [-1, 2]
Containment does not hold:
computed result is
A in (-3689348814741910323/4611686018427387904,
3228180212899171533/2305843009213693952), B in [-1, 2]
known result is
A in [-4/5, 7/5], B in [-1, 2]
Individual dimensions where containment does not hold
(Variable: computed-result known-result):
A: (-3689348814741910323/4611686018427387904,
3228180212899171533/2305843009213693952) [-4/5, 7/5]
*** box.affine_image(A, -2*A - 3*B + 1, -5) ***
A in (-0.79999999999999999995663191310057982263970188796520233154296875,
1.4000000000000000000867361737988403547205962240695953369140625), B in
[-1, 2]
=======================================================================

The relevant part here is the computed lower bound for space dimension
named "A" (the first one), which should be lower than -0.8 (known result
is -4/5) in order to be on the safe side: the computed value
-0.79999...) was instead obtained by rounding towards the unsafe side,
leading to the failure.

If compiled using gcc, the output is as follows:
=======================================================================
=== test08 ===
*** box ***
A in [0, 1], B in [-1, 2]
*** box.affine_image(A, -2*A - 3*B + 1, -5) ***
A in
(-0.8000000000000000000108420217248550443400745280086994171142578125,
1.4000000000000000000867361737988403547205962240695953369140625), B in
[-1, 2]
=======================================================================

So, my hypothesis seems to be correct: the cause is the missing support
for -frounding-math in llvm/clang.

I will soon check some of the other failing tests and will report if I
see anything new with respect to what said above.

Cheers,
Enea.



More information about the PPL-devel mailing list