August 2008 - PPL-devel - BUGSENG Mailman

Re: [PPL-devel] patch for merging graphite branch (before tuplification)
by Roberto Bagnara 08 Aug '08

08 Aug '08

Jack Howarth wrote: > A couple questions. Do you know when the ppl cvs > will be released as the next ppl version? I noticed today > that the ppl testsuite failures I am seeing on > i386-apple-darwin9 appear to be fixed in ppl cvs. Dear Jack, work for the release of PPL 0.10 has already started and I expect the release to occur in a month or so. Actually, all the functionality supposed to be included in PPL 0.10 is already in, and the code is quite stable. The release work yet to be done has to do with documentation and packaging. You can start using the new code today by using the anonymous CVS access or by downloading: ftp://ftp.cs.unipr.it/pub/ppl/snapshots/ppl-0.10pre19.tar.bz2 Please, direct any PPL-related message to ppl-devel(a)cs.unipr.it (possibly omitting my own address). > Also is it likely that cloog-ppl git and the graphite > patches would build under ppl cvs? I ask because I > thought I would try ppl cvs to see if it eliminated > the two graphite gcc testsuite failures I am seeing > on i686-apple-darwin9 with ppl 0.9 (since that release > shows failures in the ppl testsuite on that target). I think that basing new development on PPL 0.9 is a mistake: my advise is to work with PPL 0.10 from the start, possibly helping us to make this release as robust as possible (e.g., as you know, we do not have access to any Darwin machine). I have also tried to compile cloog-ppl git, but I get the following error at make-time: $ make Making all in . make[1]: Entering directory `/usr/local/distrib/cloog' /bin/sh ./libtool --tag=CC --mode=compile gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"cloog\" -DVERSION=\"0.15\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSTDC_HEADERS=1 -DHAVE_STRTOL=1 -I. -I./include -I./include -I/usr/local/include -DCLOOG_PPL_BACKEND -Wall -fomit-frame-pointer -g -O2 -MT block.lo -MD -MP -MF .deps/block.Tpo -c -o block.lo `test -f 'source/block.c' || echo './'`source/block.c ./libtool: line 459: CDPATH: command not found ./libtool: line 1262: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.3a, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.3a libtool: and run autoconf again. make[1]: *** [block.lo] Error 63 make[1]: Leaving directory `/usr/local/distrib/cloog' make: *** [all-recursive] Error 1 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

2 1

Re: [PPL-devel] patch for merging graphite branch (before tuplification)
by Roberto Bagnara 08 Aug '08

08 Aug '08

Joseph S. Myers wrote: > And what is the packaging status of the GMP C++ interface? The PPL page > claims it's widely not packaged. The PPL's web page reflected what was the situation in a not too distant past. Nowadays, most binary distrubutions of GMP include its C++ interface. I have updated the PPL web page: sorry if this anachronism has caused some confusion. 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

2 1

Re: [PPL-devel] patch for merging graphite branch (before tuplification)
by Roberto Bagnara 08 Aug '08

08 Aug '08

Joseph S. Myers wrote: > On Sun, 3 Aug 2008, Richard Guenther wrote: > >> Sure. But modulo bugs there shouldn't be a difference in code-generation >> (for the PPL part at least), as it provides "basic math" like mpfr. Code >> generation could be affected by the version of Cloog though. > > Thanks - this is useful information. If PPL's interface is such that > there is a unique correct output for any inputs, like MPFR, then indeed we > only need check the version is recent enough rather than requiring an > exact version. Dear All, I think a little clarification is necessary. It is not strictly true that the PPL's interface is such that there is a unique correct output for any input. Let us start from generic convex polyhedra, which (as far as I can tell) is the only numerical abstraction used by cloog. There the point is that, given a convex polyhedron, there are many minimal constraint systems (i.e., not containing any redundant constraint) that describe it. No polyhedra library that I know uses strong normalization methods for constraints (like the Gram-Schmidt orthogonalization process) since they are costly and tend to produce very big coefficients. So the most that can be guaranteed is a minimal form (i.e., with the minimum number of individually-normalized constraints), but there is no guarantee to obtain, for the same polyhedron, the same set of constraints. However, if you stick to a particular PPL release, you can count on obtaining the same set of constraints on all architectures. Other numerical abstractions implemented by the PPL, such as octagonal shapes, bounded-difference shapes and boxes using floating point coefficients, give rise to results that are not exactly reproducible. The only guarantee that the PPL provides is correctness; due to the nature of floating point computations any change of PPL version, compiler version, architecture, math library and so forth may give rise to different (but always correct) results. Finally, the mixed integer programming solver integrated in the PPL optionally use floating point computations in order to implement the steepest-edge heuristics: in the presence of multiple optima you can get one or another depending on all that influences the execution of floating point computations. 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

2 1

w3ppl/htdocs/Download requirements.raw
by Roberto Bagnara 08 Aug '08

08 Aug '08

CVSROOT: /cvs/ppl Module name: w3ppl Changes by: bagnara(a)cs.unipr.it 2008-08-08 17:16:19 Modified files: htdocs/Download: requirements.raw Log message: Nowadays, most binary distrubutions of GMP include its C++ interface. Patches: http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/w3ppl/htdocs/Download/requirement…

1 0

Re: [PPL-devel] patch for merging graphite branch (before tuplification)
by Roberto Bagnara 08 Aug '08

08 Aug '08

Jack Howarth wrote: > I didn't bother to post the make check results to gcc-testresults yet because I noticed that the ppl-0.9 testsuite showed > five failures on i686-apple-darwin9... > > failed tests: test08 > FAIL: affineimage1 > failed tests: test09 test11 > FAIL: affineimage2 > failed tests: test06 > FAIL: affinepreimage2 > failed tests: test06 > FAIL: generalizedaffineimage2 > failed tests: test07 test14 > FAIL: generalizedaffinepreimage1 > > I posted the output for these failing test run with the > PPL_NOISY_TESTS environmental variable set to yes on the > ppl-devel mailing list... > > http://www.cs.unipr.it/pipermail/ppl-devel/2008-August/011968.html > > Roberto Bagnara's cursory examination of those results was that > these were flaws in the testsuite itself and not real errors. > I don't seem to see them in ppl cvs. Dear Jack, I have checked more carefully and found that the testsuite is OK. My guess is that PPL 0.9 does not use the -frounding-math GCC option for compilation. This was fixed in: 2007-09-10 Monday 15:45 Roberto Bagnara <bagnara(a)cs.unipr.it> * configure.ac (1.283): With GCC, use -frounding-math to disable transformations and optimizations that assume default floating point rounding behavior. I can only repeat my invitation to base any new development on (prereleases of) PPL 0.10. 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

1 0

ppl 0.9 make check failures on i686-apple-darwin9
by Jack Howarth 07 Aug '08

07 Aug '08

In preparation for creating fink gcc44 packages, I have created a fink ppl package for the release 0.9 version on Mac OS X 10.5. I noticed that the make check of a stock build of ppl 0.9 on i686-apple-darwin9 exhibits five test failures... make[5]: Nothing to be done for `run_tests'. make check-TESTS PASS: addconstraints1 PASS: addspacedims1 PASS: affinedimension1 failed tests: test08 FAIL: affineimage1 failed tests: test09 test11 FAIL: affineimage2 PASS: affinepreimage1 failed tests: test06 FAIL: affinepreimage2 PASS: ascii_dump_load1 PASS: bdsdifference1 PASS: bdshull1 PASS: bgp99extrapolation1 PASS: bhmz05widening1 PASS: bhz03widening1 PASS: cc76narrowing1 PASS: cc76extrapolation1 PASS: closure1 PASS: concatenate1 PASS: constraints1 PASS: contains1 PASS: empty1 PASS: equality1 PASS: fromgensys1 PASS: generalizedaffineimage1 failed tests: test06 FAIL: generalizedaffineimage2 failed tests: test07 test14 FAIL: generalizedaffinepreimage1 PASS: generalizedaffinepreimage2 PASS: geomcovers1 PASS: h79widening1 PASS: intersection1 PASS: limitedbhmz05extrapolation1 PASS: limitedcc76extrapolation1 PASS: limitedh79extrapolation1 PASS: mapspacedims1 PASS: maxspacedim PASS: minconstraints1 PASS: relations1 PASS: relations2 PASS: relations3 PASS: removespacedims1 PASS: timeelapse1 PASS: universe1 PASS: writebdshape1 ====================================== 5 of 42 tests failed Please report to ppl-devel(a)cs.unipr.it Are these expected for ppl 0.9 on i686-apple-darwin9? Also, might these be fixed in the ppl cvs? I ask because my initial testing of the graphite patch for gcc 4.4 shows a couple unexpected failures... FAIL: gcc.dg/graphite/scop-16.c (test for excess errors) FAIL: gcc.dg/graphite/scop-16.c scan-graphite-dump-times graphite "Interchange valid for loops 2 and 3:" 1: dump file does not exist FAIL: gcc.dg/graphite/scop-17.c (test for excess errors) FAIL: gcc.dg/graphite/scop-17.c scan-graphite-dump-times graphite "Interchange not valid for loops 2 and 3:" 1: dump file does not exist which are... Executing on host: /sw/src/fink.build/gcc44-4.3.999-20080805/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20080805/darwin_objdir/gcc / /sw/src/fink.build/gcc44-4.3.999-20080805/gcc-4.4-20080805/gcc/testsuite/gcc.dg/graphite/scop-16.c -O2 -floop-block -fdump-tree-graphite-all -fno-show-column -S -o scop-16.s (timeout = 300) /sw/src/fink.build/gcc44-4.3.999-20080805/gcc-4.4-20080805/gcc/testsuite/gcc.dg/graphite/scop-16.c: In function 'test': /sw/src/fink.build/gcc44-4.3.999-20080805/gcc-4.4-20080805/gcc/testsuite/gcc.dg/graphite/scop-16.c:7: error: size of array 'a' is too large /sw/src/fink.build/gcc44-4.3.999-20080805/gcc-4.4-20080805/gcc/testsuite/gcc.dg/graphite/scop-16.c:8: error: size of array 'b' is too large compiler exited with status 1 output is: /sw/src/fink.build/gcc44-4.3.999-20080805/gcc-4.4-20080805/gcc/testsuite/gcc.dg/graphite/scop-16.c: In function 'test': /sw/src/fink.build/gcc44-4.3.999-20080805/gcc-4.4-20080805/gcc/testsuite/gcc.dg/graphite/scop-16.c:7: error: size of array 'a' is too large /sw/src/fink.build/gcc44-4.3.999-20080805/gcc-4.4-20080805/gcc/testsuite/gcc.dg/graphite/scop-16.c:8: error: size of array 'b' is too large FAIL: gcc.dg/graphite/scop-16.c (test for excess errors) Excess errors: /sw/src/fink.build/gcc44-4.3.999-20080805/gcc-4.4-20080805/gcc/testsuite/gcc.dg/graphite/scop-16.c:7: error: size of array 'a' is too large /sw/src/fink.build/gcc44-4.3.999-20080805/gcc-4.4-20080805/gcc/testsuite/gcc.dg/graphite/scop-16.c:8: error: size of array 'b' is too large FAIL: gcc.dg/graphite/scop-16.c scan-graphite-dump-times graphite "Interchange valid for loops 2 and 3:" 1: dump file does not exist Executing on host: /sw/src/fink.build/gcc44-4.3.999-20080805/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20080805/darwin_objdir/gcc / /sw/src/fink.build/gcc44-4.3.999-20080805/gcc-4.4-20080805/gcc/testsuite/gcc.dg/graphite/scop-17.c -O2 -floop-block -fdump-tree-graphite-all -fno-show-column -S -o scop-17.s (timeout = 300) /sw/src/fink.build/gcc44-4.3.999-20080805/gcc-4.4-20080805/gcc/testsuite/gcc.dg/graphite/scop-17.c: In function 'test': /sw/src/fink.build/gcc44-4.3.999-20080805/gcc-4.4-20080805/gcc/testsuite/gcc.dg/graphite/scop-17.c:7: error: size of array 'a' is too large compiler exited with status 1 output is: /sw/src/fink.build/gcc44-4.3.999-20080805/gcc-4.4-20080805/gcc/testsuite/gcc.dg/graphite/scop-17.c: In function 'test': /sw/src/fink.build/gcc44-4.3.999-20080805/gcc-4.4-20080805/gcc/testsuite/gcc.dg/graphite/scop-17.c:7: error: size of array 'a' is too large FAIL: gcc.dg/graphite/scop-17.c (test for excess errors) Excess errors: /sw/src/fink.build/gcc44-4.3.999-20080805/gcc-4.4-20080805/gcc/testsuite/gcc.dg/graphite/scop-17.c:7: error: size of array 'a' is too large FAIL: gcc.dg/graphite/scop-17.c scan-graphite-dump-times graphite "Interchange not valid for loops 2 and 3:" 1: dump file does not exist ...and I am concerned these may be due to a buggy build of ppl 0.9. Thanks in advance for any advice. Jack ps I checked the Fedora 9 ppl srpm and didn't notice any bugfix specific patches.

2 13

[Fwd: Re: patch for merging graphite branch (before tuplification)]
by Roberto Bagnara 04 Aug '08

04 Aug '08

-------- Original Message -------- Subject: Re: patch for merging graphite branch (before tuplification) Date: Sun, 3 Aug 2008 21:20:19 +0200 From: Richard Guenther <richard.guenther(a)gmail.com> To: Joseph S. Myers <joseph(a)codesourcery.com> CC: Sebastian Pop <sebpop(a)gmail.com>, GCC Patches <gcc-patches(a)gcc.gnu.org>, Mark Mitchell <mark(a)codesourcery.com>, Jakub Jelinek <jakub(a)redhat.com>, David Edelsohn <edelsohn(a)gmail.com>, Harle, Christophe <christophe.harle(a)amd.com>, Tobias Grosser <grosser(a)fim.uni-passau.de>, Konrad Trifunovic <konrad.trifunovic(a)gmail.com>, Albert Cohen <Albert.Cohen(a)inria.fr>, Roberto Bagnara <bagnara(a)cs.unipr.it> References: <cb9d34b20807251914jb7fb76q4452be18461d7464(a)mail.gmail.com> <84fc9c000807260228h12552595x17b2a7556d35913b(a)mail.gmail.com> <cb9d34b20808021726w3dcb5015o9b256ef393dba02c(a)mail.gmail.com> <Pine.LNX.4.64.0808031809020.15922(a)digraph.polyomino.org.uk> On Sun, Aug 3, 2008 at 8:23 PM, Joseph S. Myers <joseph(a)codesourcery.com> wrote: > On Sat, 2 Aug 2008, Sebastian Pop wrote: > >> Hi, >> >> The graphite branch has been tuplified and the port to PPL passes the >> graphite testsuite. For building the graphite branch right now, here >> are the steps you'll have to go through: >> >> You have to get a copy of the release 0.9 of PPL from: >> http://www.cs.unipr.it/ppl/Download/ > > I see this is documented as needing (a) C++, (b) GCC 4.0.3 or later, (c) > GMP compiled with the C++ interface enabled. I believe we previously > reached a conclusion that if GCC is made to require C++ it would work with > any version of GCC 3.4 or later (and did not discuss the question of the > GMP C++ interface). Recall that right now the documented requirement is > that a cross-compiler (so all non-Ada front ends) can be built with GCC > 2.95 or later; Ada requires 3.4 or later; and any ISO C compiler should > work for bootstrapping a native compiler. If Graphite can be disabled then the bootstrapping issue goes away as you can in a first step build current GCC with C++ enabled and do a second stage with Graphite enabled. > At this point I think the policy questions regarding the build > requirements for graphite, even as an optional feature, need to be raised > on their own in a thread on the gcc list rather than buried in the patch > discussion. I agree. At least this is the place for requesting Host testing on non-Linux hosts. Note that Fedora has packages for the PPL, likewise has Debian. I am in the progress of building ones for SUSE. Richard. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0