[PPL-devel] Parma Polyhedra Library 0.10.1

[Richard Guenther]

On Tue, Apr 14, 2009 at 6:58 PM, Roberto Bagnara <bagnara at cs.unipr.it> wrote:
> Richard Guenther wrote:
>>
>> On Tue, Apr 14, 2009 at 3:02 PM, Roberto Bagnara <bagnara at cs.unipr.it>
>> wrote:
>>>
>>> We are pleased to announce the availability of PPL 0.10.1, a new release
>>> of the Parma Polyhedra Library.
>>
>> It seems to build and test ok on {i586,ia64,ppc,ppc64,s390,x86_64}-linux
>> but I get
>>
>> PASS: nnc_writepolyhedron1
>> /bin/sh: line 4: 29952 Segmentation fault      ${dir}$tst
>> FAIL: memory1
>> ======================================
>> 1 of 191 tests failed
>> Please report to ppl-devel at cs.unipr.it
>> ======================================
>>
>> on s390x-linux.  Does the testsuite stop after the first error?
>
> Hi Richard.
>
> The testsuite does not proceed after the first directory that gives
> an error.  In your case, the `tests/Polyhedron' directory produced that
> error and the `tests/Grid' directory is the only subdirectory of `tests'
> that has not been tested because of that error.

Ok.

>> If not,
>> what is memory1 testing?
>
> It tests the PPL features that allow to recover after an out-of-memory
> error, i.e., when std::bad_alloc is thrown.  It does so by limiting
> the amount of memory available to the process, attempting some
> expensive computation, catching std:bad_alloc, and restart.
> The key function is this one:
>
> bool
> guarded_compute_open_hypercube_generators(dimension_type dimension,
>                                          unsigned long max_memory_in_bytes)
> {
>  try {
>    limit_memory(max_memory_in_bytes);
>    compute_open_hypercube_generators(dimension);
>    return true;
>  }
>  catch (const std::bad_alloc&) {
>    nout << "out of virtual memory" << endl;
>    return false;
>  }
>  catch (...) {
>    exit(1);
>  }
>  // Should never get here.
>  exit(1);
> }
>
> From the fact that you observe this failure, I gather that the configure
> script found a version of GMP compiled with -fexceptions.  Unfortunately,
> this is not always enough.

Ah, I guess the script (incorrectly) assumes this because it uses
the C++ bindings of GMP?  Certainly our GMP (the C parts) are not
built with -fexceptions.  The configure detects

checking how to link with libgmp... /usr/lib64/libgmp.so
checking how to link with libgmpxx... /usr/lib64/libgmpxx.so
/usr/lib64/libgmp.so
checking for the GMP library version 4.1.3 or above... yes
checking size of mp_limb_t... 8
checking whether GMP has been compiled with support for exceptions... yes
checking for __mpz_struct._mp_alloc... yes
checking for __mpz_struct._mp_size... yes
checking for __mpz_struct._mp_d... yes

the configure test for exceptions looks sane though.  It might be
that we indeed run into an unwinder bug.

>  For instance, on the Itanium the test fails
> because of the libunwind bug reported in
>
>   http://lists.gnu.org/archive/html/libunwind-devel/2008-09/msg00001.html
>
> Hence the test is disabled if defined(__ia64).  I don't know what the
> problem could be on s390x-linux.

After adding || defined(__s390x) all tests now pass (good enough
for me - the test doesn't seem to be critical).

> Do you know if there is an s390x-linux
> machine we can obtain access to for the purpose of debugging?

Unfortunately not.

Thanks,
Richard.