Parma Polyhedra Library 0.10.2

[Roberto Bagnara]

We announce the availability of PPL 0.10.2, a new release of the Parma
Polyhedra Library fixing a few bugs affecting PPL 0.10.1.

The precise list of user-visible changes is below.
For more information, please come and visit the PPL web site at

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

The core development team,

Roberto Bagnara  
Patricia M. Hill 
Enea Zaffanella  


--
NEWS for version 0.10.2  (released on April 18, 2009)
--

Bugfixes


o  Correctly detect GMP 4.3.0.

o  Fixed the C interface library version information.

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

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


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

[RFC] Massive recursion in tree_ssa_phiprop_1?

[Dave Korn]

Hi,

  I'm getting a stack overflow caused by *very* deep recursion while trying to
build gnu/javax/swing/text/html/parser/HTML_401F.o in libjava, bootstrapping
HEAD on i686-pc-cygwin.

  With the default per-thread stack size of 2MB, it crashes in
tree_ssa_phiprop_1(), which by the time of the crash has recursed to a depth
that I can actually honestly describe as "OVER 9000"!  If I boost the stack to
4MB, I find that the recursion does actually bottom out at some point, since
the compile completes, but I tested at 3MB and it crashed at a recursion depth
of 13924.

  I know that boostrapping libjava is a tough job and pretty intensive on
memory demands, but is this level of nesting actually to be expected, or has
something gone astray?

cheers,
  DaveK
-- 
Breakpoint 1, tree_ssa_phiprop_1 (bb=0x7efd0580, phivn=0x3d3c9a8, n=150236)
at /gnu/gcc/gcc/gcc/tree-ssa-phiprop.c:333
333 {
(gdb) bt -13
#9198 0x007e069c in tree_ssa_phiprop_1 (bb=,
phivn=, n=150236)
at /gnu/gcc/gcc/gcc/tree-ssa-phiprop.c:344
#9199 0x007e069c in tree_ssa_phiprop_1 (bb=,
phivn=, n=150236)
at /gnu/gcc/gcc/gcc/tree-ssa-phiprop.c:344
#9200 0x007e069c in tree_ssa_phiprop_1 (bb=,
phivn=, n=150236)
at /gnu/gcc/gcc/gcc/tree-ssa-phiprop.c:344
#9201 0x007e1063 in tree_ssa_phiprop ()
at /gnu/gcc/gcc/gcc/tree-ssa-phiprop.c:360
#9202 0x0053d646 in execute_one_pass (pass=)
at /gnu/gcc/gcc/gcc/passes.c:1290
#9203 0x0053d8ac in execute_pass_list (pass=0xbb4b80)
at /gnu/gcc/gcc/gcc/passes.c:1339
#9204 0x0053d8bf in execute_pass_list (pass=0xbb3e60)
at /gnu/gcc/gcc/gcc/passes.c:1340
#9205 0x0079f5e0 in tree_rest_of_compilation (fndecl=0x7ff72c80)
at /gnu/gcc/gcc/gcc/tree-optimize.c:437
#9206 0x005b8bc5 in cgraph_expand_function (node=0x7ff74c00)
at /gnu/gcc/gcc/gcc/cgraphunit.c:1048
#9207 0x005ba950 in cgraph_optimize () at /gnu/gcc/gcc/gcc/cgraphunit.c:1107
#9208 0x00443e4a in java_parse_file (set_yydebug=0)
at /gnu/gcc/gcc/gcc/java/jcf-parse.c:1987
#9209 0x00475b64 in toplev_main (argc=32, argv=0x2f19be8)
at /gnu/gcc/gcc/gcc/toplev.c:976
#9210 0x0044e2f0 in main (argc=32, argv=0x2f19be8)
at /gnu/gcc/gcc/gcc/main.c:35
(gdb) print *bb
$1 = {preds = 0x7d1e2920, succs = 0x7d1e2980, aux = 0x0, loop_father = 0x0,
  dom = {0x3b3c798, 0x0}, prev_bb = 0x7efd0540, next_bb = 0x7efd05c0, il = {
gimple = 0x7f10ba80, rtl = 0x7f10ba80}, count = 0, index = 18400,
  loop_depth = 0, frequency = 252, flags = 3}
(gdb) print *bb->dom[0]
$2 = {data = 0x7efd0580, dfs_num_in = 9200, dfs_num_out = 34433,
  father = 0x3b3c738, son = 0x3b3c7f8, left = 0x3b3c768, right = 0x3b3c768,
  rightmost_occ = 0x3b3fcd0, parent_occ = 0x3768630}
(gdb) print *bb->dom[0]->son
$3 = {data = 0x7efd0600, dfs_num_in = 9201, dfs_num_out = 34430,
  father = 0x3b3c798, son = 0x3b3c858, left = 0x3b3c7c8, right = 0x3b3c7c8,
  rightmost_occ = 0x3b3fd20, parent_occ = 0x3768680}
(gdb) print *bb->dom[0]->son->son
$4 = {data = 0x7efd0700, dfs_num_in = 9202, dfs_num_out = 34427,
  father = 0x3b3c7f8, son = 0x3b3c8b8, left = 0x3b3c828, right = 0x3b3c828,
  rightmost_occ = 0x3b3fd70, parent_occ = 0x37686d0}
(gdb) print *bb->dom[0]->son->son->son
$5 = {data = 0x7efd07c0, dfs_num_in = 9203, dfs_num_out = 34424,
  father = 0x3b3c858, son = 0x3b3c918, left = 0x3b3c888, right = 0x3b3c888,
  rightmost_occ = 0x3b3fdc0, parent_occ = 0x3768720}
(gdb) print *bb->dom[0]->son->son->son->son
$6 = {data = 0x7efd0840, dfs_num_in = 9204, dfs_num_out = 34421,
  father = 0x3b3c8b8, son = 0x3b3c978, left = 0x3b3c8e8, right = 0x3b3c8e8,
  rightmost_occ = 0x3b3fe10, parent_occ = 0x3768770}
(gdb) print *bb->dom[0]->son->son->son->son->son->son->son->son->son->son->son
->son
$7 = {data = 0x7efd0e80, dfs_num_in = 9212, dfs_num_out = 34397,
  father = 0x3b3cbb8, son = 0x3b3cc78, left = 0x3b3cbe8, right = 0x3b3cbe8,
  rightmost_occ = 0x3b40090, parent_occ = 0x37689f0}
(gdb) print *bb->dom[0]->son->son->son->son->son->son->son->son->son->son->son
->son->son->son->son->son->son->son->son->son->son->son->son->son
$8 = {data = 0x7efd1780, dfs_num_in = 9224, dfs_num_out = 34361,
  father = 0x3b3d038, son = 0x3b3d0f8, left = 0x3b3d068, right = 0x3b3d068,
  rightmost_occ = 0x3b40450, parent_occ = 0x3768db0}
(gdb) print *bb->dom[0]->son->son->son->son->son->son->son->son->son->son->son
->son->son->son->son->son->son->son->son->son->son->son->son->son->son->son->s
on->son->son->son->son->son->son->son->son->son->son->son->son->son->son->son-
>son->son->son->son->son->son->son->son->son->son->son->son->son->son
$9 = {data = 0x7efd2f80, dfs_num_in = 9256, dfs_num_out = 34265,
  father = 0x3b3dc38, son = 0x3b3dcf8, left = 0x3b3dc68, right = 0x3b3dc68,
  rightmost_occ = 0x3b40e50, parent_occ = 0x37697c0}
(gdb) print *bb->dom[0]->son->son->son->son->son->son->son->son->son->son->son
->son->son->son->son->son->son->son->son->son->son->son->son->son->son->son->s
on->son->son->son->son->son->son->son->son->son->son->son->son->son->son->son-
>son->son->son->son->son->son

Re: [gnat] reuse of ASTs already constructed

[Oliver Kellogg]

I've run up against a problem with reusing the GNAT trees:
Apparently during semantic analysis entity names are expanded
to their fully qualified names in the tree.

For example, when compiling the following file with the node
for System already installed by a previous compilation,

-- file: ext.ads
with System;
procedure Ext (Addr : System.Address);

I get the following error from sem_ch8.adb Find_Expanded_Name
during semantic analysis of the above System.Address,

ext.ads:3:29: "Address" is not a visible entity of "System"

This is because in sem_ch8.adb:4482,

  if No (Id) or else Chars (Id) /= Chars (Selector) then ...

the second part of the condition becomes true as Chars(Id) is
"system__address" [and Chars(Selector) is "address"].
When compiling the same file afresh without preinstalled nodes,
Chars(Id) is just "address" and all is fine.

Oliver


On 2009-04-12 at 19:29 +0200, Oliver Kellogg wrote:
> Picking up an old thread,
> http://gcc.gnu.org/ml/gcc/2003-03/msg00281.html
> 
> 
> On Tue, 4 Mar 2003, Geert Bosch  wrote:
> > [...]
> > Best would be to first post a design overview,
> > before doing a lot of work in order to prevent spending time
> > on implementing something that may turn out to have fundamental
> > problems.
> 
> I've done a little experimenting to get a feel for this.
> 
> I've looked at the work done toward the GCC compile server but
> decided that I want to concentrate on GNAT trees (whereas the
> compile server targets the GNU trees.)
> 
> Also I am aiming somewhat lower - not making a separate compile
> server process but rather extending gnat1 to handle multiple
> files in a single invocation.
> 
> The current GNAT code makes a strong assumption that there be
> only one main unit, and this Main_Unit be located at index 0 of
> Lib.Units.Table (see procedure Lib.Load.Load_Main_Source).
> 
> I am currently looking at having each main unit supplied on
> the gnat1 command line overwrite the Main_Unit in the Units table.
> 
> What do you think of this approach?
> 
> The attached patch sets the stage for passing multiple source
> files to a single gnat1 invocation. (Beware, this is a rough cut.
> Best use "svn diff --diff-cmd diff -x -uw" after applying as
> there are many changes that only affect indentation.)
> 
> Thanks,
> 
> Oliver
> 
>