March 2009 - PPL-devel - BUGSENG Mailman

Problems with test suite on alpha
by Michael Tautschnig 09 Sep '10

09 Sep '10

Hi PPL developers, I've reported problems with some test cases because of suspected gcc bugs on alpha earlier already. Now it seems that even more test cases are broken, most probably because of the very same bug (I suspect it to be http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8966). My question now is: How to proceed? Shall I specifically disable the failing test cases by surrounding them with an #ifndef __alpha__ or disable the entire test suite on alpha? Thanks, Michael

2 6

make check fails on Freebsd in tests/Box/propagateconstraints2
by Tobias Grosser 11 Apr '09

11 Apr '09

Hi, ppl compiles as always flawless on FreeBSD current. As I wrote some weeks ago there are still some bugs in "make check". 1. tests/Box/Makefile.am (patch submitted) 2. test02 and test03 in tests/Box/propagateconstraints2 fail. They only fail if compile with gmake propagateconstraints2 -DBOX_INSTANCE=db_r_oc or gmake check (in ppl/, ppl/tests, or ppl/tests/Box) compiling with gmake propagateconstraints2 -DBOX_INSTANCE=rt_r_oc or gmake propagateconstraints2 fixes the test cases. I attached the outputs of NOISY and VERY_NOISY and the compilation of the relevant file. Do you have any idea how to debug this? Tobias

3 5

Bugs in OCaml interface
by Kenneth MacKenzie 03 Apr '09

03 Apr '09

Hello there, I've been using the PPL OCaml interface to carry out some program analysis within a compiler. It's been working pretty well, but I've come across a number of bugs. -------------------------------------------------------------------------------- 1. The OCaml 'unit' type has only a single value, denoted (); this is represented internally by a pointer to a single preallocated value. However, many of the functions in the PPL interface return the wrong value. Here's an example from an OCaml top level built with PPL $ ocamlppl Objective Caml version 3.11.0 # let p = Ppl_ocaml.ppl_new_C_Polyhedron_from_constraints [];; val p : Ppl_ocaml.polyhedron = <abstr> # let u = Ppl_ocaml.ppl_Polyhedron_add_constraints p [];; val u : unit = <unknown constructor> # u = ();; - : bool = false # The <unknown constructor> thing is something you should never see. Here's the defintion of the ppl_Polyhedron_add_constraints function from interfaces/OCaml/ppl_ocaml_Polyhedron.cc: extern "C" void ppl_Polyhedron_add_constraints(value ph, value cs) try { CAMLparam2(ph, cs); Polyhedron& pph = *p_Polyhedron_val(ph); Constraint_System pcs = build_ppl_Constraint_System(cs); pph.add_constraints(pcs); CAMLreturn0; } CATCH_ALL This has void return type, but should actually return a pointer to the preallocated unit value. I think the correct code should look like extern "C" CAMLprim value ppl_Polyhedron_add_constraints(value ph, value cs) try { CAMLparam2(ph, cs); Polyhedron& pph = *p_Polyhedron_val(ph); Constraint_System pcs = build_ppl_Constraint_System(cs); pph.add_constraints(pcs); CAMLreturn(Val_unit); } CATCH_ALL Every function returning a unit value (it looks like there are 509 of them) should look like this. I don't think this bug is very harmful unless one uses unit values in unusual ways. ---------------------------------------------------------------------- 2. Certain functions can lead to segmentation errors. Here's a program which creates a polyhedron and then loops round adding constraints one by one. The call to ppl_Polyhedron_get_constraints sometimes causes a segmentation fault; if you remove it then the program runs OK. (Presumably it eventually runs out of memory, but I've run it for a very long time (millions of iterations) without this happening.) $ cat tst.ml open Ppl_ocaml let itoz = Gmp.Z.of_int let f n = (* Generate a constraint nx + (n+1)y <= n+2 *) Less_Or_Equal (Plus (Times (itoz n, Variable 0), Times (itoz (n+1), Variable 1)), Coefficient (itoz (n+2))) let p = ppl_new_C_Polyhedron_from_space_dimension 2 Universe let rec g n = let () = ppl_Polyhedron_add_constraint p (f n) in let l = ppl_Polyhedron_get_constraints p in let () = Printf.printf "%d\n" n in let () = flush stdout in g (n+1) let _ = g 0 Here's what happens when you run it: $ ocamlppl # #use "tst.ml";; val itoz : int -> Gmp.Z.t = <fun> val f : int -> Ppl_ocaml.linear_constraint = <fun> val p : Ppl_ocaml.polyhedron = <abstr> File "tst.ml", line 12, characters 9-10: Warning Y: unused variable l. val g : int -> 'a = <fun> 0 1 2 3 . . <output deleted> . 1654 1655 1656 Segmentation fault I think that the problem here is in the function build_ocaml_constraint_system in interfaces/OCaml/ppl_ocaml_common.cc: value build_ocaml_constraint_system(const Constraint_System& ppl_cs) { // This code builds a list of constraints starting from bottom to // top. A list on OCaml must be built like a sequence of Cons and Tail. // The first element is the Nil list (the Val_int(0)). value result = Val_int(0); for (Constraint_System::const_iterator v_begin = ppl_cs.begin(), v_end = ppl_cs.end(); v_begin != v_end; ++v_begin) { value new_tail = caml_alloc_tuple(2); Field(new_tail, 0) = build_ocaml_constraint(*v_begin); Field(new_tail, 1) = result; result = new_tail; } return result; } The problem is in the way that allocation in the ocaml heap is handled. The function loops round allocating list cells in the heap, but the ocaml garbage collector doesn't know what's going on. Eventually caml_alloc_tuple is called when there isn't enough free space: this triggers garbage collection, and the memory occupied by the partially built list is reclaimed; the loop then continues, allocating a new list cell whose tail points to some garbage-collected memory which will later be occupied by something else allocated in the heap. The function finally returns a malformed list to the ocaml system, eventually leading to a crash. To overcome this the CAMLlocal macro should be used to tell the ocaml garbage collector to leave the partially-allocated list alone: CAMLprim value build_ocaml_constraint_system(const Constraint_System& ppl_cs) { // This code builds a list of constraints starting from bottom to // top. A list on OCaml must be built like a sequence of Cons and Tail. // The first element is the Nil list (the Val_int(0)). CAMLlocal2 (result, new_tail); result = Val_emptylist; // Synonymous with Val_int(0); for (Constraint_System::const_iterator v_begin = ppl_cs.begin(), v_end = ppl_cs.end(); v_begin != v_end; ++v_begin) { new_tail = caml_alloc_tuple(2); Field(new_tail, 0) = build_ocaml_constraint(*v_begin); Field(new_tail, 1) = result; result = new_tail; } CAMLreturn (result); } I haven't actually tested this since it would require too much rebuilding, but I've written similar code which worked OK. I'm not sure whether "CAMLprim" is in fact necessary, but I don't think it does any harm. Again, there are a number of functions which should be amended in a similar way: I think that in any C function which uses a caml_alloc* function, every local variable which may point to a value allocated in the ocaml heap should be protected by a CAMLlocal* macro. -------------------------------------------------------------------------------- 3. I've also had problems with ppl_Polyhedron_BHRZ03_widening_assign. Occasionally my compiler locks up with a lot of CPU usage when ppl_Polyhedron_BHRZ03_widening_assign is called. I didn't have any probelms using the H79 widening instead. I'm not sure what's causing this: ppl_Polyhedron_BHRZ03_widening_assign does have the problem with units mentioned in (1) above, but I don't think that should do any damage. It's possible that I have some malformed data structures from (2) which are causing problems. -------------------------------------------------------------------------------- 4. While looking at the code for ppl_Polyhedron_BHRZ03_widening_assign I noticed a bug in ppl_Polyhedron_BHRZ03_widening_assign_with_tokens, which is repeated in all the widening-with-tokens functions: CAMLprim value ppl_Polyhedron_BHRZ03_widening_assign_with_tokens (value ph1, value ph2, value integer) try { CAMLparam3(ph1, ph2, integer); Polyhedron& pph1 = *p_Polyhedron_val(ph1); Polyhedron& pph2 = *p_Polyhedron_val(ph2); int cpp_int = Val_int(integer); check_int_is_unsigned(cpp_int); unsigned int unsigned_value = cpp_int; pph1.BHRZ03_widening_assign(pph2, &unsigned_value); CAMLreturn(Int_val(unsigned_value)); } Val_int and Int_val should be interchanged here. The current version will calculate the number of remaining tokens incorrectly. -------------------------------------------------------------------------------- 5. It's not really a bug, but I'm a little confused by the way the code is divided into modules. Ppl_ocaml_globals contains the type definitions for various datatypes, but why does it also contain all the MIP functions? I see that the OCamldoc-generated documentation only contains information about Ppl_ocaml_globals, but Ppl_ocaml is missing, so there's no information available about the types of the polyhedron functions and other things in Ppl_ocaml. Also, the documentation for the OCaml interface (for example, at http://www.cs.unipr.it/ppl/Documentation/user/ppl-user-ocaml-interface-0.10… ) refers to a number of functions such as ppl_reset_timeout which don't actually occur in the interface. -------------------------------------------------------------------------------- Best wishes, Kenneth MacKenzie -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

3 7

Re: [PPL-devel] Intel Compiler Help
by Roberto Bagnara 02 Apr '09

02 Apr '09

Patel, Jayesh wrote: > Hello Mr. Roberto Bagnara, Dear Patel, please accept my apologies for the delay in answering your message: your letter arrived in a very busy moment and I had to postpone replying. > My name is Jayesh Patel (J.D.). I work for Intel as a Compiler TCE (Technical Consulting Engineer). > I recently worked on resolving one of your issues (#523343 - Internal error compiling GMP 4.2.4). > I am glad to inform you that I have taken over PPL/GMP related tasks at Intel. This is very good news indeed. > I also wanted to inform you that: > 1. I will work on Intel compiler related issues reported by you or your team. Good. There are several still open. > 2. I will reproduce working environment of up-to-date PPL/GMP in Intel lab, and compile > it with major releases of the Intel compiler. > a. I have already downloaded PPL-0.10 and GMP-4.2.4. OK. We are in the process of releasing PPL 0.10.1. If you want, you can access our Git repository: http://www.cs.unipr.it/ppl/Download/Git > b. I have managed to compile both PPL and GMP successfully using Intel compiler 11.0.086. Did your builds pass `make check' both for GMP and PPL? > c. However, using GCC-4.3.0 gets me error "configure: error: Cannot find GMP version 4.1.3 or higher." > 3. I also intend to benchmark Intel compiler optimized binaries of PPL/GMP against GCC compiled ones. > a. What are the performance benchmarks for PPL/GMP that you prefer to focus? One benchmark that is significant for all the applications that work on polyhedra is described at http://www.cs.unipr.it/ppl/performance When we will be able to build the PPL with the Intel compiler and let it pass `make check', we can help you to reproduce this kind of experiment. > b. What is the typical execution environment (h/w and s/w) for PPL/GMP based applications? Speaking for the PPL only, I think the majority of users works on Unix-like system, with a preference for GNU/Linux. In your shoes, I would test on recent versions of Debian and Fedora. > c. I have also recompiled both PPL and GMP with optimization flags for Intel compiler. The PPL configure script already recognizes the Intel C/C++ compiler. If you let us know which flags are suitable, we can use them as defaults. > Please let me know what you think. Looking forward to working with you. > > Thanks. > > J.D. Patel > Intel Corporation > (C) 973.420.1438 Sure. Sorry again for the delay. All the best, Roberto P.S. Please direct all PPL-related messages to ppl-devel(a)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

2 1

[GIT] ppl/ppl(master): Made ascii_load more restrictive.
by Abramo Bagnara 31 Mar '09

31 Mar '09

Module: ppl/ppl Branch: master Commit: 1826e6cd378ec51530b262c7f65a489b1341bdf8 URL: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=1826e6cd378e… Author: Abramo Bagnara <abramo.bagnara(a)gmail.com> Date: Tue Mar 31 20:18:44 2009 +0200 Made ascii_load more restrictive. --- src/DB_Matrix.templates.hh | 5 ++--- src/OR_Matrix.templates.hh | 5 ++--- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/src/DB_Matrix.templates.hh b/src/DB_Matrix.templates.hh index e25a0e2..ba98212 100644 --- a/src/DB_Matrix.templates.hh +++ b/src/DB_Matrix.templates.hh @@ -232,9 +232,8 @@ DB_Matrix<T>::ascii_load(std::istream& s) { DB_Matrix& x = *this; for (dimension_type i = 0; i < nrows; ++i) for (dimension_type j = 0; j < nrows; ++j) { - Result r = input(x[i][j], s, ROUND_UP); - // FIXME(0.10.1): V_CVT_STR_UNK is probably not the only possible error. - if (!s || r == V_CVT_STR_UNK) + Result r = input(x[i][j], s, ROUND_CHECK); + if (r != V_EQ || is_minus_infinity(x[i][j])) return false; } diff --git a/src/OR_Matrix.templates.hh b/src/OR_Matrix.templates.hh index decf583..da03cda 100644 --- a/src/OR_Matrix.templates.hh +++ b/src/OR_Matrix.templates.hh @@ -92,9 +92,8 @@ OR_Matrix<T>::ascii_load(std::istream& s) { row_reference_type r_i = *i; const dimension_type rs = i.row_size(); for (dimension_type j = 0; j < rs; ++j) { - Result r = input(r_i[j], s, ROUND_UP); - // FIXME(0.10.1): V_CVT_STR_UNK is probably not the only possible error. - if (!s || r == V_CVT_STR_UNK) + Result r = input(r_i[j], s, ROUND_CHECK); + if (r != V_EQ || is_minus_infinity(r_i[j])) return false; } }

1 0

[GIT] ppl/ppl(master): Indentation fixed.
by Roberto Bagnara 31 Mar '09

31 Mar '09

Module: ppl/ppl Branch: master Commit: 432d03e6ab06dcad0455c9504a2661ab1ada431a URL: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=432d03e6ab06… Author: Roberto Bagnara <bagnara(a)cs.unipr.it> Date: Tue Mar 31 20:30:09 2009 +0200 Indentation fixed. --- src/BD_Shape.templates.hh | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/src/BD_Shape.templates.hh b/src/BD_Shape.templates.hh index 82e81c6..166f2d6 100644 --- a/src/BD_Shape.templates.hh +++ b/src/BD_Shape.templates.hh @@ -5643,15 +5643,15 @@ BD_Shape<T>::OK() const { // MINUS_INFINITY cannot occur at all. for (dimension_type i = dbm.num_rows(); i-- > 0; ) for (dimension_type j = dbm.num_rows(); j-- > 0; ) - if (is_minus_infinity(dbm[i][j])) { + if (is_minus_infinity(dbm[i][j])) { #ifndef NDEBUG - using namespace Parma_Polyhedra_Library::IO_Operators; - std::cerr << "BD_Shape::dbm[" << i << "][" << j << "] = " - << dbm[i][j] << "!" - << std::endl; + using namespace Parma_Polyhedra_Library::IO_Operators; + std::cerr << "BD_Shape::dbm[" << i << "][" << j << "] = " + << dbm[i][j] << "!" + << std::endl; #endif - return false; - } + return false; + } // On the main diagonal only PLUS_INFINITY can occur. for (dimension_type i = dbm.num_rows(); i-- > 0; )

1 0

[GIT] ppl/ppl(master): Merge branch 'master' of ssh://bagnara@git.cs.unipr. it/git/ppl/ppl
by Roberto Bagnara 31 Mar '09

31 Mar '09

Module: ppl/ppl Branch: master Commit: 6ac85b56ba1b4277e27a28a5384121931f7f6e52 URL: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=6ac85b56ba1b… Author: Roberto Bagnara <bagnara(a)cs.unipr.it> Date: Tue Mar 31 17:38:30 2009 +0000 Merge branch 'master' of ssh://bagnara@git.cs.unipr.it/git/ppl/ppl ---

1 0

[GIT] ppl/ppl(master): Disabled one more test on the Alpha.
by Roberto Bagnara 31 Mar '09

31 Mar '09

Module: ppl/ppl Branch: master Commit: ccc5ce00a303af09a7e37d120695a2c1cbb37834 URL: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=ccc5ce00a303… Author: Roberto Bagnara <bagnara(a)cs.unipr.it> Date: Tue Mar 31 17:37:40 2009 +0000 Disabled one more test on the Alpha. --- tests/BD_Shape/disjoint1.cc | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/tests/BD_Shape/disjoint1.cc b/tests/BD_Shape/disjoint1.cc index c8f6dca..5a22e5b 100644 --- a/tests/BD_Shape/disjoint1.cc +++ b/tests/BD_Shape/disjoint1.cc @@ -185,7 +185,10 @@ BEGIN_MAIN DO_TEST(test01); DO_TEST(test02); DO_TEST(test03); +#ifndef __alpha__ + // Exception handling is broken in GCC on the Alpha. DO_TEST(test04); +#endif DO_TEST(test05); DO_TEST(test06); DO_TEST(test07);

1 0

[GIT] ppl/ppl(master): Postponed FIXME.
by Abramo Bagnara 31 Mar '09

31 Mar '09

Module: ppl/ppl Branch: master Commit: 21f7acf730e5ebf68eca6bcf9034b19098375b67 URL: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=21f7acf730e5… Author: Abramo Bagnara <abramo.bagnara(a)gmail.com> Date: Tue Mar 31 17:35:39 2009 +0200 Postponed FIXME. --- src/Box.inlines.hh | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/Box.inlines.hh b/src/Box.inlines.hh index d3a514b..1c6556e 100644 --- a/src/Box.inlines.hh +++ b/src/Box.inlines.hh @@ -407,8 +407,9 @@ Box<ITV> seq_v.refine_existential((den > 0) ? GREATER_THAN : LESS_THAN, q); break; } - // FIXME(0.10.1): do check the value returned by `refine_existential' and + // FIXME: do check the value returned by `refine_existential' and // set `empty' and `empty_up_to_date' as appropriate. + // This has to be done after reimplementation of intervals. reset_empty_up_to_date(); assert(OK()); }

1 0

[GIT] ppl/ppl(master): Removed FIXME and documented the default value.
by Abramo Bagnara 31 Mar '09

31 Mar '09

Module: ppl/ppl Branch: master Commit: 337302a6e28fd7e7200b1d80bf65021d66cfa449 URL: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=337302a6e28f… Author: Abramo Bagnara <abramo.bagnara(a)gmail.com> Date: Tue Mar 31 17:02:11 2009 +0200 Removed FIXME and documented the default value. --- src/Init.cc | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/Init.cc b/src/Init.cc index dce7393..35fb4f4 100644 --- a/src/Init.cc +++ b/src/Init.cc @@ -86,7 +86,8 @@ PPL::Init::Init() { old_rounding_direction = fpu_get_rounding_direction(); fpu_set_rounding_direction(round_fpu_dir(ROUND_DIRECT)); #endif - // FIXME(0.10.1): choose a better default + // The default is choosen to have a precision greater than most + // precise IEC559 floating point (112 bits of mantissa). set_rational_sqrt_precision_parameter(128); } }

1 0