Re: [PPL-devel] FW: patch for merging graphite branch (before tuplification)

Sebastian Pop wrote:
On Wed, Aug 20, 2008 at 9:24 AM, David Edelsohn edelsohn@gmail.com wrote:
On Tue, Aug 19, 2008 at 6:37 PM, Sebastian Pop sebpop@gmail.com wrote:
Thanks David. Could you give the graphite-branch a run on AIX?
Seb,
What release of G++ are you using to compile PPL?
I initially did not have the C++ interfaces to GMP installed. I fixed that, but I had to compile GMP 4.1.4 with G++ 4.1.
I downloaded the most recent PPL, ppl-0.10pre22 from August 15. When I try to build it on AIX, I first get an error in Bit_Row.inlines.hh because ffs is not declared. The file includes <cstring>, which includes <string.h>, but ffs() is not declared in /usr/include/string.h on AIX, only in, /usr/include/strings.h. I manually declared ffs and proceeded.
But then I receive a more significant C++ error when compiling MIP_Problem.cc:
/usr/gnu/src/ppl-0.10pre22/src/MIP_Problem.cc: In member function 'Parma_Polyhedra_Library::dimension_type Parma_Polyhedra_Library::MIP_Problem::steepest_edge_entering_index() const': /usr/gnu/src/ppl-0.10pre22/src/MIP_Problem.cc:871: error: no matching function for call to 'assign_r(double&, const __gmp_expr<__gmpz_value, __gmpz_value>&, Parma_Polyhedra_Library::Rounding_Dir)' /usr/gnu/src/ppl-0.10pre22/src/MIP_Problem.cc:885: error: no matching function for call to 'assign_r(double&, __gmp_expr<__gmpq_value, __gmpq_value>&, Parma_Polyhedra_Library::Rounding_Dir)'
I tried G++ 4.1, 4.2, and 4.3.
PPL is supposed to compile with g++ 4.0.3 or later. I used g++ 4.2.3 and it worked on Ubuntu (linux-amd64) machine. Roberto, is this a known bug?
The first bug (including <cstring> instead of <strings.h> was unknown and is now fixed in the CVS version.
For the other problem, I am unable to reproduce it on any of our machines. Can I have access to a system where the problem shows up? Cheers,
Roberto
P.S. Please direct all the PPL-related messages to ppl-devel@cs.unipr.it, not to myself.

On Wed, Aug 20, 2008 at 11:30 AM, Roberto Bagnara bagnara@cs.unipr.it wrote:
The first bug (including <cstring> instead of <strings.h> was unknown and is now fixed in the CVS version.
Is this wrapped in
extern "C" { }
or assumed to be C++ safe?
For the other problem, I am unable to reproduce it on any of our machines. Can I have access to a system where the problem shows up?
I am not sure about easy access to an AIX system, but I can send you preprocessed source code, if you want to examine it. Let me know to whom I should send it.
Thanks, David

David Edelsohn wrote:
On Wed, Aug 20, 2008 at 11:30 AM, Roberto Bagnara bagnara@cs.unipr.it wrote:
The first bug (including <cstring> instead of <strings.h> was unknown and is now fixed in the CVS version.
Is this wrapped in
extern "C" { }
or assumed to be C++ safe?
The latter. Would this be a problem for AIX?
For the other problem, I am unable to reproduce it on any of our machines. Can I have access to a system where the problem shows up?
I am not sure about easy access to an AIX system, but I can send you preprocessed source code, if you want to examine it. Let me know to whom I should send it.
Plese, send the preprocessed sources to myself. I also would like to have the generated config.log and ppl-config.h files, as well as the precise compiler version you are using. Thanks,
Roberto

On Wed, Aug 20, 2008 at 3:38 PM, Roberto Bagnara bagnara@cs.unipr.it wrote:
or assumed to be C++ safe?
The latter. Would this be a problem for AIX?
This works on AIX. I wanted to make sure that the assumptions and expectations of system headers are explicitly documented.
Thanks, David

To better understand what's the problem with double floating point binary format could you try the attached program on the AIX machine and post the output of the following commands?
gcc testdouble.c ./a.out 0xaaacccaa 0xacccaaac ./a.out 0xacccaaac 0xaaacccaa ./a.out 0xcccaaacc 0xcaaaccca ./a.out 0xcaaaccca 0xcccaaacc

On Thu, Aug 21, 2008 at 6:39 AM, Abramo Bagnara abramobagnara@tin.it wrote:
To better understand what's the problem with double floating point binary format could you try the attached program on the AIX machine and post the output of the following commands?
gcc testdouble.c ./a.out 0xaaacccaa 0xacccaaac
-4.0182423960326471e-103
./a.out 0xacccaaac 0xaaacccaa
-6.871459756898565e-93
./a.out 0xcccaaacc 0xcaaaccca
-85705035845709847000000000000000000000000000000000000000000000
./a.out 0xcaaaccca 0xcccaaacc
-5013529507616260900000000000000000000000000000000000

David Edelsohn wrote:
On Thu, Aug 21, 2008 at 6:39 AM, Abramo Bagnara abramobagnara@tin.it wrote:
To better understand what's the problem with double floating point binary format could you try the attached program on the AIX machine and post the output of the following commands?
gcc testdouble.c ./a.out 0xaaacccaa 0xacccaaac
-4.0182423960326471e-103
./a.out 0xacccaaac 0xaaacccaa
-6.871459756898565e-93
./a.out 0xcccaaacc 0xcaaaccca
-85705035845709847000000000000000000000000000000000000000000000
./a.out 0xcaaaccca 0xcccaaacc
-5013529507616260900000000000000000000000000000000000
Thanks David. Abramo and myself discovered that what you observe is due to a bug in Autoconf 2.62:
http://lists.gnu.org/archive/html/autoconf/2008-08/msg00020.html
We have now reverted to Autoconf 2.61 for the generation of the new snapshot
ftp://ftp.cs.unipr.it/pub/ppl/snapshots/ppl-0.10pre23.tar.bz2
Please let us know if it works for you; and please send me the config.log and config.h you obtain from configure (I would like to check a couple of other things). All the best,
Roberto

On Thu, Aug 21, 2008 at 12:51 PM, Roberto Bagnara bagnara@cs.unipr.it wrote:
Thanks David. Abramo and myself discovered that what you observe is due to a bug in Autoconf 2.62:
http://lists.gnu.org/archive/html/autoconf/2008-08/msg00020.html
We have now reverted to Autoconf 2.61 for the generation of the new snapshot
Nice autoconf bug.
ftp://ftp.cs.unipr.it/pub/ppl/snapshots/ppl-0.10pre23.tar.bz2
Is that new snapshot complete? Configure is looking for interface/Prolog subdirectory, but it does not exist in the tar file. I have removed the references in configure and see how well the rest works.
Thanks, David

David Edelsohn wrote:
ftp://ftp.cs.unipr.it/pub/ppl/snapshots/ppl-0.10pre23.tar.bz2
Is that new snapshot complete? Configure is looking for interface/Prolog subdirectory, but it does not exist in the tar file. I have removed the references in configure and see how well the rest works.
Oops... I had uploaded the wrong file. Please try again. Cheers,
Roberto

Now on to Cloog bugs.
cloog/source/ppl/clast.c cloog/source/ppl/domain.c cloog/source/ppl/matrix.c
all include
#include "../../include/cloog/cloog.h"
which assumes compiling within the source directory. The should use
#include "cloog/cloog.h" .
After fixing that, compilation fails with
/usr/gnu/src/cloog/source/ppl/domain.c:928: error: 'PPL_CONSTRAINT_TYPE_LESS_THAN_OR_EQUAL' undeclared (first use in this function) /usr/gnu/src/cloog/source/ppl/domain.c:936: error: 'PPL_CONSTRAINT_TYPE_GREATER_THAN_OR_EQUAL' undeclared (first use in this function) /usr/gnu/src/cloog/source/ppl/domain.c: In function 'changes_generators': /usr/gnu/src/cloog/source/ppl/domain.c:1011: warning: implicit declaration of function 'ppl_Polyhedron_minimized_generators'
ppl_c.h defines enum including PPL_CONSTRAINT_TYPE_LESS_OR_EQUAL and PPL_CONSTRAINT_TYPE_GREATER_OR_EQUAL, but not the names used by Cloog. Also, ppl_c.h declares ppl_Polyhedron_get_minimized_generators(), but not the function referenced in Cloog.
David

And more undeclared functions, like:
ppl_Polyhedron_generators() and ppl_new_NNC_Polyhedron_from_dimension(). I can change the latter to ppl_new_NNC_Polyhedron_from_space_dimension(), but it it has the wrong number of arguments.
Did the PPL interfaces change? It looks like PPL 0.10pre23 and Cloog pulled yesterday from Git are out of sync with respect to the PPL interfaces.
David

David Edelsohn wrote:
And more undeclared functions, like:
ppl_Polyhedron_generators() and ppl_new_NNC_Polyhedron_from_dimension(). I can change the latter to ppl_new_NNC_Polyhedron_from_space_dimension(), but it it has the wrong number of arguments.
Did the PPL interfaces change? It looks like PPL 0.10pre23 and Cloog pulled yesterday from Git are out of sync with respect to the PPL interfaces.
All these changes were in the patch I sent to Sebastian some time ago. My understanding is that the patch has indeed been applied:
$ pwd /usr/local/distrib/cloog/source/ppl $ git-pull git://repo.or.cz/cloog-ppl.git Already up-to-date. $ fgrep LESS_THAN_OR *.h *.c $ fgrep ppl_new_NNC_Polyhedron_from_dimension *.h *.c $

On Thu, Aug 21, 2008 at 2:14 PM, Roberto Bagnara bagnara@cs.unipr.it wrote:
David Edelsohn wrote:
And more undeclared functions, like:
ppl_Polyhedron_generators() and ppl_new_NNC_Polyhedron_from_dimension(). I can change the latter to ppl_new_NNC_Polyhedron_from_space_dimension(), but it it has the wrong number of arguments.
Did the PPL interfaces change? It looks like PPL 0.10pre23 and Cloog pulled yesterday from Git are out of sync with respect to the PPL interfaces.
All these changes were in the patch I sent to Sebastian some time ago. My understanding is that the patch has indeed been applied:
$ pwd /usr/local/distrib/cloog/source/ppl $ git-pull git://repo.or.cz/cloog-ppl.git Already up-to-date. $ fgrep LESS_THAN_OR *.h *.c $ fgrep ppl_new_NNC_Polyhedron_from_dimension *.h *.c $
Right. The head of cloog-ppl should have all the needed changes to compile with ppl-0.10pre23.
David, just git-pull and try to compile again. I will include your suggestion of include "cloog/cloog.h" in a next revision, or if you have a patch for that (git-diff), it's even better ;-)
Thanks for the testing, Sebastian
participants (4)
-
Abramo Bagnara
-
David Edelsohn
-
Roberto Bagnara
-
Sebastian Pop