PPL 0.10 testsuite failures on powerpc-linux
I'm trying to build the Parma Polyhedra Library on powerpc-linux so I can use it for Graphite support in GCC. I've tried a lot of things and my builds normally succeed but I get lots of testsuite failures:
in Box, 60 tests with -DBOX_INSTANCES=db_r_oc in Octagonal_Shape, 58 tests with -DOCTAGONAL_SHAPE_INSTANCE=double in BD_Shape, 59 tests with -DBD_SHAPE_INSTANCE=double
Most of the failures in the double tests are due to infinite values for the second argument to less-than functions, which end up at __gmp_binary_less::eval which calls __gmp_binary_less::eval which invokes DOUBLE_NAN_INF_ACTION which calls __gmp_invalid_operation for the infinity. It looks as if the infinity should be detected and handled earlier by functions in ppl-0.10/src/check-ext.inlines.hh.
I'll attach a build script for one of the various builds I've done that get these errors. In this case I start with GCC 4.3.2, build GMP 4.2.4 as only static libraries, and then build PPL as only static libraries. I get the same testsuite failures when starting with GCC mainline and building GMP and PPL as shared libaries, but run into other problems with earlier versions of GCC or the default libgmp on my test system.
Am I doing something obviously wrong? If not, can you offer any suggestions on how to find out what's going wrong, short of learning to understand the PPL and GMP sources?
I tried using GMP 4.1.4, which doesn't use DOUBLE_NAN_INF_ACTION, but ran into various PPL configure problems. One is that some configure checks end up using /usr/include/gmpxx.h instead of the one specified for --with-libgmp, and another is that the options to link libgmpxx end up including libgcc_s.so and libm.so even though I'm trying to build and use only static libraries. If there are known issues with those configure issues I'd like to know about them as well.
Janis Johnson IBM Linux Technology Center
Janis Johnson wrote:
I'll attach a build script for one of the various builds I've done that get these errors.
Dear Janis,
just to let you know that we have been able to reproduce the problem and we are investigating. Perhaps you forgot the attachment? All the best,
Roberto
On Tue, 2009-01-27 at 13:56 +0100, Roberto Bagnara wrote:
Janis Johnson wrote:
I'll attach a build script for one of the various builds I've done that get these errors.
Dear Janis,
just to let you know that we have been able to reproduce the problem and we are investigating. Perhaps you forgot the attachment? All the best,
Perhaps I did! Here it is, in case it's still interesting.
Janis
Janis Johnson wrote:
I'm trying to build the Parma Polyhedra Library on powerpc-linux so I can use it for Graphite support in GCC. I've tried a lot of things and my builds normally succeed but I get lots of testsuite failures:
in Box, 60 tests with -DBOX_INSTANCES=db_r_oc in Octagonal_Shape, 58 tests with -DOCTAGONAL_SHAPE_INSTANCE=double in BD_Shape, 59 tests with -DBD_SHAPE_INSTANCE=double
Hi Janis,
we investigated your report and found the culprit. The immediate cause is a bad interaction between Autoconf's AC_C_BIGENDIAN and AX_PREFIX_CONFIG_H. We reported this problem a few days ago, but did not get any reply:
http://www.cs.unipr.it/pipermail/ppl-devel/2009-January/013958.html
Perhaps AX_PREFIX_CONFIG_H is no longer maintained and we decided to drop it starting from PPL 0.11.
Now, what happens is that AX_PREFIX_CONFIG_H fails to rename WORDS_BIGENDIAN as PPL_WORDS_BIGENDIAN. The PPL, however, expects (only in three places, in src/Float.defs.hh) the symbol PPL_WORDS_BIGENDIAN to be defined on big-endian machines such as PowerPC.
A workaround is to configure the PPL for big-endian architectures specifying
CPPFLAGS="-UWORDS_BIGENDIAN -DPPL_WORDS_BIGENDIAN=1"
at the end of the configure command. Can you please check that that works? If it does we will immediately publish a notice on the PPL web site.
Taking into account that GCC 4.4 (via CLooG) does not use any PPL feature depending on that miscompilation, I wonder what is best. Do you think we should prepare a PPL 0.10.1 release with that fix?
Concerning how such a thing could have happened, the problem is that we have access to only one PowerPC machine. That machine has memory problems so that a make of the PPL terminates with a segmentation fault in GCC 90% of the times. So, basically, we currently have no sensible way to test on PowerPCs. It is a pity that this caused PPL 0.10 to be shipped with such a bug. Thanks again for the problem report,
Roberto
On Mon, 2009-02-02 at 18:31 +0100, Roberto Bagnara wrote:
Janis Johnson wrote:
I'm trying to build the Parma Polyhedra Library on powerpc-linux so I can use it for Graphite support in GCC. I've tried a lot of things and my builds normally succeed but I get lots of testsuite failures:
in Box, 60 tests with -DBOX_INSTANCES=db_r_oc in Octagonal_Shape, 58 tests with -DOCTAGONAL_SHAPE_INSTANCE=double in BD_Shape, 59 tests with -DBD_SHAPE_INSTANCE=double
Hi Janis,
we investigated your report and found the culprit. The immediate cause is a bad interaction between Autoconf's AC_C_BIGENDIAN and AX_PREFIX_CONFIG_H. We reported this problem a few days ago, but did not get any reply:
http://www.cs.unipr.it/pipermail/ppl-devel/2009-January/013958.htmlPerhaps AX_PREFIX_CONFIG_H is no longer maintained and we decided to drop it starting from PPL 0.11.
Now, what happens is that AX_PREFIX_CONFIG_H fails to rename WORDS_BIGENDIAN as PPL_WORDS_BIGENDIAN. The PPL, however, expects (only in three places, in src/Float.defs.hh) the symbol PPL_WORDS_BIGENDIAN to be defined on big-endian machines such as PowerPC.
A workaround is to configure the PPL for big-endian architectures specifying
CPPFLAGS="-UWORDS_BIGENDIAN -DPPL_WORDS_BIGENDIAN=1"at the end of the configure command. Can you please check that that works? If it does we will immediately publish a notice on the PPL web site.
Yes, it works! All tests pass (29 lines in output from "make -k check" match "^All tests").
I assume you mean you'll add an entry to the known bugs list; that's where I first checked when looking into the test failures.
Taking into account that GCC 4.4 (via CLooG) does not use any PPL feature depending on that miscompilation, I wonder what is best. Do you think we should prepare a PPL 0.10.1 release with that fix?
I don't think so, it should be enough to have the workaround in the known bugs list.
Concerning how such a thing could have happened, the problem is that we have access to only one PowerPC machine. That machine has memory problems so that a make of the PPL terminates with a segmentation fault in GCC 90% of the times. So, basically, we currently have no sensible way to test on PowerPCs. It is a pity that this caused PPL 0.10 to be shipped with such a bug. Thanks again for the problem report,
I can build and test CVS sources occasionally and report problems. When I can successfully build gmp/mpfr/ppl/cloog as 32-bit libraries on powerpc64-linux I plan to try as 64-bit libraries. Once that works with released versions I can try with CVS sources of some or all of them.
Thanks for the quick response.
Janis
participants (2)
-
Janis Johnson -
Roberto Bagnara