Re: Parma Polyhedra Library 0.10.1

Re: Parma Polyhedra Library 0.10.1

[Jack Howarth]

Roberto,
    I am finding the following when I build my ppl-10.1
packaging in fink...

Validating .deb dir /sw/src/fink.build/root-ppl-shlibs-0.10.1-1...
Error: Shlibs field says compatibility version for /sw/lib/libppl.7.dylib is 8.0.0, but it is actually 9.0.0.
Error: package contains the shared library
          /sw/lib/ppl/libppl_java.jnilib
       but the corresponding install_name and compatibility_version
          %p/lib/ppl/libppl_java.jnilib 0.0.0
       are not listed in the Shlibs field.  See the packaging manual.
Removing runtime build-lock...
Removing build-lock package...

It seems rather bad form to me that soversions are being changed in
minor dot releases of ppl. This has been one of my biggest fears
about cloog/ppl...that the so version control be randomly bumped.
          Jack

Re: Parma Polyhedra Library 0.10.1

[Richard Guenther]

On Wed, Apr 15, 2009 at 2:00 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote:
> Roberto,
>    I am finding the following when I build my ppl-10.1
> packaging in fink...
>
> Validating .deb dir /sw/src/fink.build/root-ppl-shlibs-0.10.1-1...
> Error: Shlibs field says compatibility version for /sw/lib/libppl.7.dylib is 8.0.0, but it is actually 9.0.0.
> Error: package contains the shared library
>          /sw/lib/ppl/libppl_java.jnilib
>       but the corresponding install_name and compatibility_version
>          %p/lib/ppl/libppl_java.jnilib 0.0.0
>       are not listed in the Shlibs field.  See the packaging manual.
> Removing runtime build-lock...
> Removing build-lock package...
>
> It seems rather bad form to me that soversions are being changed in
> minor dot releases of ppl. This has been one of my biggest fears
> about cloog/ppl...that the so version control be randomly bumped.

Looks ok for me on Linux targets.  0.10 had

lrwxrwxrwx    1 root    root               15 Nov 18 11:53
/usr/lib64/libppl.so.7 -> libppl.so.7.0.0
-rwxr-xr-x    1 root    root           921473 Nov 18 11:42
/usr/lib64/libppl.so.7.0.0

and 0.10.1 now has

lrwxrwxrwx    1 root    root               15 Apr 14 15:28
/usr/lib64/libppl.so.7 -> libppl.so.7.1.0
-rwxr-xr-x    1 root    root           803544 Apr 14 15:28
/usr/lib64/libppl.so.7.1.0

which is fine.  Of course a more fine-grained control with
symbol versions would be nice - but that's hard to get right with
a C++ library.

Richard.

Re: Parma Polyhedra Library 0.10.1

[Jack Howarth]

On Wed, Apr 15, 2009 at 02:44:12PM +0200, Richard Guenther wrote:
> On Wed, Apr 15, 2009 at 2:00 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote:
> > Roberto,
> >    I am finding the following when I build my ppl-10.1
> > packaging in fink...
> >
> > Validating .deb dir /sw/src/fink.build/root-ppl-shlibs-0.10.1-1...
> > Error: Shlibs field says compatibility version for /sw/lib/libppl.7.dylib is 8.0.0, but it is actually 9.0.0.
> > Error: package contains the shared library
> >          /sw/lib/ppl/libppl_java.jnilib
> >       but the corresponding install_name and compatibility_version
> >          %p/lib/ppl/libppl_java.jnilib 0.0.0
> >       are not listed in the Shlibs field.  See the packaging manual.
> > Removing runtime build-lock...
> > Removing build-lock package...
> >
> > It seems rather bad form to me that soversions are being changed in
> > minor dot releases of ppl. This has been one of my biggest fears
> > about cloog/ppl...that the so version control be randomly bumped.
> 
> Looks ok for me on Linux targets.  0.10 had
> 
> lrwxrwxrwx    1 root    root               15 Nov 18 11:53
> /usr/lib64/libppl.so.7 -> libppl.so.7.0.0
> -rwxr-xr-x    1 root    root           921473 Nov 18 11:42
> /usr/lib64/libppl.so.7.0.0
> 
> and 0.10.1 now has
> 
> lrwxrwxrwx    1 root    root               15 Apr 14 15:28
> /usr/lib64/libppl.so.7 -> libppl.so.7.1.0
> -rwxr-xr-x    1 root    root           803544 Apr 14 15:28
> /usr/lib64/libppl.so.7.1.0
> 
> which is fine.  Of course a more fine-grained control with
> symbol versions would be nice - but that's hard to get right with
> a C++ library.
> 
> Richard.

Richard,
   However if you look in ppl-0.10.1/src/Makefile.am, you will find...

#       PPL release             -version-info
#           0.1                     -----
#           0.2                     -----
#           0.3                     0:0:0
#           0.4                     1:0:1
#           0.5                     2:0:0
#           0.6                     3:0:0
#           0.7                     4:0:0
#           0.8                     5:0:0
#           0.9                     6:0:0
#           0.10                    7:0:0
#           0.10.1                  8:0:1

So either Roberto meant to bump the soversion and
forgot or changed his mind and didn't revert all of the
soversion changes out before release. In any case,
it seems really weird to have soversion changes in
a 0.10.x release.
             Jack

Re: Parma Polyhedra Library 0.10.1

[Peter O'Gorman]

Jack Howarth wrote:

>    However if you look in ppl-0.10.1/src/Makefile.am, you will find...
> 
> #       PPL release             -version-info
> #           0.1                     -----
> #           0.2                     -----
> #           0.3                     0:0:0
> #           0.4                     1:0:1
> #           0.5                     2:0:0
> #           0.6                     3:0:0
> #           0.7                     4:0:0
> #           0.8                     5:0:0
> #           0.9                     6:0:0
> #           0.10                    7:0:0
> #           0.10.1                  8:0:1
> 
> So either Roberto meant to bump the soversion and
> forgot or changed his mind and didn't revert all of the
> soversion changes out before release.

I assume that there was some added API that caused the CURRENT version
number to increase. Since the soname did not change (AGE was also
bumped), anything that was built against version 0.10 will continue to
work with 0.10.1 without being rebuilt.

If there was no added API, and none removed, then only the revision
should have been touched, of course.

http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info

Peter

Re: Parma Polyhedra Library 0.10.1

[Roberto Bagnara]

Jack Howarth wrote:
> On Wed, Apr 15, 2009 at 02:44:12PM +0200, Richard Guenther wrote:
>> On Wed, Apr 15, 2009 at 2:00 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote:
>>> [...]
>>> It seems rather bad form to me that soversions are being changed in
>>> minor dot releases of ppl. This has been one of my biggest fears
>>> about cloog/ppl...that the so version control be randomly bumped.

Jack,

can you please explain what you mean by "randomly bumped"?
Thanks,

    Roberto

P.S. Please direct all the PPL-related messages to ppl-devel@cs.unipr.it

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it

Re: Parma Polyhedra Library 0.10.1

[Jack Howarth]

On Wed, Apr 15, 2009 at 04:36:04PM +0200, Roberto Bagnara wrote:
> Jack Howarth wrote:
>> On Wed, Apr 15, 2009 at 02:44:12PM +0200, Richard Guenther wrote:
>>> On Wed, Apr 15, 2009 at 2:00 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote:
>>>> [...]
>>>> It seems rather bad form to me that soversions are being changed in
>>>> minor dot releases of ppl. This has been one of my biggest fears
>>>> about cloog/ppl...that the so version control be randomly bumped.
>
> Jack,
>
> can you please explain what you mean by "randomly bumped"?
> Thanks,
>

Roberto,
    I think there is a common misunderstanding on darwin about the
meaning of the compatibility level. I (and others) have been under the
impression that the compatibility level should be exactly one more than
the major soversion. For instance, the fftw3 3.2.1 release bumped the
compatibility level by one compared to the major soversion and the
package was never updated because this was viewed as an error upstream.
My understanding now is that the relationship is rather loose and the
compatibility level only need to be at least one higher than the
major soversion.
                          Jack
>    Roberto
>
> P.S. Please direct all the PPL-related messages to ppl-devel@cs.unipr.it
>
> -- 
> Prof. Roberto Bagnara
> Computer Science Group
> Department of Mathematics, University of Parma, Italy
> http://www.cs.unipr.it/~bagnara/
> mailto:bagnara@cs.unipr.it

Re: Parma Polyhedra Library 0.10.1

[Roberto Bagnara]

Peter O'Gorman wrote:
> Jack Howarth wrote:
> 
>>    However if you look in ppl-0.10.1/src/Makefile.am, you will find...
>>
>> #       PPL release             -version-info
>> #           0.1                     -----
>> #           0.2                     -----
>> #           0.3                     0:0:0
>> #           0.4                     1:0:1
>> #           0.5                     2:0:0
>> #           0.6                     3:0:0
>> #           0.7                     4:0:0
>> #           0.8                     5:0:0
>> #           0.9                     6:0:0
>> #           0.10                    7:0:0
>> #           0.10.1                  8:0:1
>>
>> So either Roberto meant to bump the soversion and
>> forgot or changed his mind and didn't revert all of the
>> soversion changes out before release.
> 
> I assume that there was some added API that caused the CURRENT version
> number to increase. Since the soname did not change (AGE was also
> bumped), anything that was built against version 0.10 will continue to
> work with 0.10.1 without being rebuilt.

Yes, this is what happened.

> [...]
> 
> http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info

This is the algorithm we followed.  However, I realize now that
we forgot to update the C interface using the same algorithm.
So in interfaces/C/Makefile.am we have

...
#	    0.10		    2:0:0

LIBPPL_C_LT_CURRENT =  2
LIBPPL_C_LT_REVISION = 0
LIBPPL_C_LT_AGE =      0

whereas we should have

...
#	    0.10		    2:0:0
#	    0.10.1		    3:0:1

LIBPPL_C_LT_CURRENT =  3
LIBPPL_C_LT_REVISION = 0
LIBPPL_C_LT_AGE =      1

Last but not least, GMP 4.3.0 was released a few hours after
PPL 0.10.1 with a change that is not backward compatible and
that affects the PPL.  Summing up, I think the only solution
is to release PPL 0.10.2 during the weekend.
All the best,

    Roberto

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it

Re: Parma Polyhedra Library 0.10.1

[Richard Guenther]

On Wed, Apr 15, 2009 at 5:28 PM, Roberto Bagnara <bagnara@cs.unipr.it> wrote:
> Peter O'Gorman wrote:
>>
>> Jack Howarth wrote:
>>
>>>   However if you look in ppl-0.10.1/src/Makefile.am, you will find...
>>>
>>> #       PPL release             -version-info
>>> #           0.1                     -----
>>> #           0.2                     -----
>>> #           0.3                     0:0:0
>>> #           0.4                     1:0:1
>>> #           0.5                     2:0:0
>>> #           0.6                     3:0:0
>>> #           0.7                     4:0:0
>>> #           0.8                     5:0:0
>>> #           0.9                     6:0:0
>>> #           0.10                    7:0:0
>>> #           0.10.1                  8:0:1
>>>
>>> So either Roberto meant to bump the soversion and
>>> forgot or changed his mind and didn't revert all of the
>>> soversion changes out before release.
>>
>> I assume that there was some added API that caused the CURRENT version
>> number to increase. Since the soname did not change (AGE was also
>> bumped), anything that was built against version 0.10 will continue to
>> work with 0.10.1 without being rebuilt.
>
> Yes, this is what happened.
>
>> [...]
>>
>>
>> http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info
>
> This is the algorithm we followed.  However, I realize now that
> we forgot to update the C interface using the same algorithm.
> So in interfaces/C/Makefile.am we have
>
> ...
> #           0.10                    2:0:0
>
> LIBPPL_C_LT_CURRENT =  2
> LIBPPL_C_LT_REVISION = 0
> LIBPPL_C_LT_AGE =      0
>
> whereas we should have
>
> ...
> #           0.10                    2:0:0
> #           0.10.1                  3:0:1
>
> LIBPPL_C_LT_CURRENT =  3
> LIBPPL_C_LT_REVISION = 0
> LIBPPL_C_LT_AGE =      1
>
> Last but not least, GMP 4.3.0 was released a few hours after
> PPL 0.10.1 with a change that is not backward compatible and
> that affects the PPL.  Summing up, I think the only solution
> is to release PPL 0.10.2 during the weekend.

You mean the inability to verify the version requirement?

hecking for the GMP library version 4.1.3 or above... no
configure: error: Cannot find GMP version 4.1.3 or higher.
GMP is the GNU Multi-Precision library:
see http://www.swox.com/gmp/ for more information.
When compiling the GMP library, do not forget to enable the C++ interface:
add --enable-cxx to the configuration options.

which is what I get after updating to GMP 4.3.0.

Richard.

Re: [PPL-devel] Parma Polyhedra Library 0.10.1

[Roberto Bagnara]

Richard Guenther wrote:
> On Wed, Apr 15, 2009 at 5:28 PM, Roberto Bagnara <bagnara@cs.unipr.it> wrote:
>> Last but not least, GMP 4.3.0 was released a few hours after
>> PPL 0.10.1 with a change that is not backward compatible and
>> that affects the PPL.  Summing up, I think the only solution
>> is to release PPL 0.10.2 during the weekend.
> 
> You mean the inability to verify the version requirement?
> 
> hecking for the GMP library version 4.1.3 or above... no
> configure: error: Cannot find GMP version 4.1.3 or higher.
> GMP is the GNU Multi-Precision library:
> see http://www.swox.com/gmp/ for more information.
> When compiling the GMP library, do not forget to enable the C++ interface:
> add --enable-cxx to the configuration options.
> 
> which is what I get after updating to GMP 4.3.0.

Precisely.  This is due to the fact that, starting from GMP version 4.3.0
the `gmp_version' variable always contains three parts (major, minor,
patchlevel).  In previous versions the patchlevel was omitted if it was 0.
This change broke our GMP detection procedure.

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it

Snapshots of PPL 0.10.2 available for testing

[Roberto Bagnara]

All the problems of PPL 0.10.1 we are aware of have been
fixed in the snapshot of PPL 0.10.2 available at

     ftp://ftp.cs.unipr.it/pub/ppl/snapshots/

In particular here is what has changed:

- Correctly detect GMP 4.3.0.

- Fixed the C interface library version information.

- Test program tests/Polyhedron/memory1 disabled on the zSeries s390x
   platform.

- Makefiles fixed so as to avoid failure of `make -n check'.

If no further issues are reported, that snapshot will be
relabeled PPL 0.10.2 and released on Saturday, April 18, 2009.
Thanks to all who provided feedback.
All the best,

     Roberto

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it

Re: Snapshots of PPL 0.10.2 available for testing

[Richard Guenther]

On Thu, Apr 16, 2009 at 2:08 PM, Roberto Bagnara <bagnara@cs.unipr.it> wrote:
>
> All the problems of PPL 0.10.1 we are aware of have been
> fixed in the snapshot of PPL 0.10.2 available at
>
>    ftp://ftp.cs.unipr.it/pub/ppl/snapshots/
>
> In particular here is what has changed:
>
> - Correctly detect GMP 4.3.0.
>
> - Fixed the C interface library version information.
>
> - Test program tests/Polyhedron/memory1 disabled on the zSeries s390x
>  platform.

Huh.  It looks like the test only randomly fails.  Thus I didn't notice
that the preprocessor define is __s390x__ instead of __s390x.

Otherwise it works all fine now.

Thanks,
Richard.

Re: Snapshots of PPL 0.10.2 available for testing

[Jack Howarth]

On Thu, Apr 16, 2009 at 02:08:32PM +0200, Roberto Bagnara wrote:
>
> All the problems of PPL 0.10.1 we are aware of have been
> fixed in the snapshot of PPL 0.10.2 available at
>
>     ftp://ftp.cs.unipr.it/pub/ppl/snapshots/
>
> In particular here is what has changed:
>
> - Correctly detect GMP 4.3.0.
>
> - Fixed the C interface library version information.
>
> - Test program tests/Polyhedron/memory1 disabled on the zSeries s390x
>   platform.
>
> - Makefiles fixed so as to avoid failure of `make -n check'.
>
> If no further issues are reported, that snapshot will be
> relabeled PPL 0.10.2 and released on Saturday, April 18, 2009.
> Thanks to all who provided feedback.
> All the best,
>
>     Roberto
>
> -- 
> Prof. Roberto Bagnara
> Computer Science Group
> Department of Mathematics, University of Parma, Italy
> http://www.cs.unipr.it/~bagnara/
> mailto:bagnara@cs.unipr.it
>

The 0.10.2pre1 snapshot builds fine and passes the testsuite
on x86_64-apple-darwin10. FYI.
                 Jack

Re: Snapshots of PPL 0.10.2 available for testing

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

On Thu, 16 Apr 2009 14:08:32 +0200
Roberto Bagnara <bagnara@cs.unipr.it> wrote:

> 
> All the problems of PPL 0.10.1 we are aware of have been
> fixed in the snapshot of PPL 0.10.2 available at
> 
>      ftp://ftp.cs.unipr.it/pub/ppl/snapshots/
> 
> In particular here is what has changed:
> 
> - Correctly detect GMP 4.3.0.
> 
> - Fixed the C interface library version information.
> 
> - Test program tests/Polyhedron/memory1 disabled on the zSeries s390x
>    platform.
> 
> - Makefiles fixed so as to avoid failure of `make -n check'.
> 
> If no further issues are reported, that snapshot will be
> relabeled PPL 0.10.2 and released on Saturday, April 18, 2009.
> Thanks to all who provided feedback.
> All the best,

Everything is working here as well.  Thanks for your quick response.

-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Parma Polyhedra Library 0.10.1

[Richard Guenther]

On Tue, Apr 14, 2009 at 6:58 PM, Roberto Bagnara <bagnara@cs.unipr.it> wrote:
> Richard Guenther wrote:
>>
>> On Tue, Apr 14, 2009 at 3:02 PM, Roberto Bagnara <bagnara@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@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.

Re: Parma Polyhedra Library 0.10.1

[Ralf Wildenhues]

Hello,

* Roberto Bagnara wrote on Tue, Apr 14, 2009 at 06:58:01PM CEST:
> Richard Guenther wrote:
>> 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@cs.unipr.it
>> ======================================
>>
>> on s390x-linux.  Does the testsuite stop after the first error?

Are you saying that there were no 190 PASSes before that FAIL?  If yes,
that would be weird, and I'd be interested in the output of
  make check SHELL="/bin/sh -x"

and the make version used.

> The testsuite does not proceed after the first directory that gives
> an error.

Why not recommend
  make -k check

then?

Cheers,
Ralf

Re: Parma Polyhedra Library 0.10.1

[Roberto Bagnara]

Richard Guenther wrote:
> On Tue, Apr 14, 2009 at 3:02 PM, Roberto Bagnara <bagnara@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@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.

> 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.  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.  Do you know if there is an s390x-linux
machine we can obtain access to for the purpose of debugging?
Cheers,

    Roberto

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it

Re: Parma Polyhedra Library 0.10.1

[Richard Guenther]

On Tue, Apr 14, 2009 at 3:02 PM, Roberto Bagnara <bagnara@cs.unipr.it> wrote:
>
> We are pleased to announce the availability of PPL 0.10.1, a new release
> of the Parma Polyhedra Library.
>
> This release includes several important improvements to PPL 0.10,
> among which is better portability (including the support for
> cross-compilation), increased robustness, better packaging and several
> bug fixes.  The precise list of user-visible changes is available at
> http://www.cs.unipr.it/ppl/Download/ftp/releases/0.10.1/NEWS .
> For more information, please come and visit the PPL web site at
>
>    http://www.cs.unipr.it/ppl/
>
> On behalf of all the past and present contributors listed at
> http://www.cs.unipr.it/ppl/Credits/ and in the file CREDITS,
>
>        Roberto Bagnara  <bagnara@cs.unipr.it>
>        Patricia M. Hill <hill@comp.leeds.ac.uk>
>        Enea Zaffanella  <zaffanella@cs.unipr.it>

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@cs.unipr.it
======================================

on s390x-linux.  Does the testsuite stop after the first error?  If not,
what is memory1 testing?

Thanks,
Richard.

Parma Polyhedra Library 0.10.1

[Roberto Bagnara]

We are pleased to announce the availability of PPL 0.10.1, a new release
of the Parma Polyhedra Library.

This release includes several important improvements to PPL 0.10,
among which is better portability (including the support for
cross-compilation), increased robustness, better packaging and several
bug fixes.  The precise list of user-visible changes is available at
http://www.cs.unipr.it/ppl/Download/ftp/releases/0.10.1/NEWS .
For more information, please come and visit the PPL web site at

     http://www.cs.unipr.it/ppl/

On behalf of all the past and present contributors listed at
http://www.cs.unipr.it/ppl/Credits/ and in the file CREDITS,

         Roberto Bagnara  <bagnara@cs.unipr.it>
         Patricia M. Hill <hill@comp.leeds.ac.uk>
         Enea Zaffanella  <zaffanella@cs.unipr.it>

-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara@cs.unipr.it