looking for the developer of tree-dump.c

looking for the developer of tree-dump.c

[d43d41u5]

Hi !

For some reason the -fdump-translation-unit switch doesn't dumps the body of
the functions from the AST if I compile sources with .c extension. (there is
no "body:" in the .tu dumpfile) Are the functions bodies in the tree, but
not dumped, or are they stored somewhere else ?

I tried gcc-3.2.2 and gcc-3.4.1 too.

Re: looking for the developer of tree-dump.c

[Gabriel Dos Reis]

Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de> writes:

| On Sat, Jul 24, 2004 at 09:04:57PM +0200, Gabriel Dos Reis wrote:
| > | For some reason the -fdump-translation-unit switch doesn't dumps the body of
| > | the functions from the AST if I compile sources with .c extension. (there is
| > | no "body:" in the .tu dumpfile) Are the functions bodies in the tree, but
| > | not dumped, or are they stored somewhere else ?
| > 
| > I've come across the similar misbehaivour a week ago for mainline.  I
| > think it is a regression introduced by the tree-ssa merge.
| 
| It's probably a thinko in the way dump_enabled_p works for TDI_all.
| Users off dump_enabled_p expect that the function returns true if
| ANY dump is enabled whereas dump_enabled_p will only return true
| if ALL dumps were enabled via -fdump-tree-all.
| 
| The following ad hoc patch works for me and fixes a few other cases
| where interesting things were not dumped. 

Thanks.  I think this should go on mainline, with appropriate
ChangeLog entries.

-- Gaby

Re: looking for the developer of tree-dump.c

[Christian Ehrhardt]

On Sat, Jul 24, 2004 at 09:04:57PM +0200, Gabriel Dos Reis wrote:
> | For some reason the -fdump-translation-unit switch doesn't dumps the body of
> | the functions from the AST if I compile sources with .c extension. (there is
> | no "body:" in the .tu dumpfile) Are the functions bodies in the tree, but
> | not dumped, or are they stored somewhere else ?
> 
> I've come across the similar misbehaivour a week ago for mainline.  I
> think it is a regression introduced by the tree-ssa merge.

It's probably a thinko in the way dump_enabled_p works for TDI_all.
Users off dump_enabled_p expect that the function returns true if
ANY dump is enabled whereas dump_enabled_p will only return true
if ALL dumps were enabled via -fdump-tree-all.

The following ad hoc patch works for me and fixes a few other cases
where interesting things were not dumped. 

Index: tree-dump.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/tree-dump.c,v
retrieving revision 1.27
diff -u -r1.27 tree-dump.c
--- tree-dump.c	7 Jul 2004 10:19:18 -0000	1.27
+++ tree-dump.c	26 Jul 2004 13:14:21 -0000
@@ -570,6 +590,11 @@
       dump_child ("op 2", TREE_OPERAND (t, 2));
       break;
 
+    case TRY_FINALLY_EXPR:
+      dump_child ("op 0", TREE_OPERAND (t, 0));
+      dump_child ("op 1", TREE_OPERAND (t, 1));
+      break;
+
     case CALL_EXPR:
       dump_child ("fn", TREE_OPERAND (t, 0));
       dump_child ("args", TREE_OPERAND (t, 1));
@@ -592,6 +617,10 @@
       dump_child ("cond", TREE_OPERAND (t, 0));
       break;
 
+    case RETURN_EXPR:
+      dump_child ("expr", TREE_OPERAND (t, 0));
+      break;
+
     case TARGET_EXPR:
       dump_child ("decl", TREE_OPERAND (t, 0));
       dump_child ("init", TREE_OPERAND (t, 1));
@@ -603,6 +632,29 @@
       dump_child ("init", TREE_OPERAND (t, 3));
       break;
 
+    case CASE_LABEL_EXPR:
+      dump_child ("name", CASE_LABEL (t));
+      if (CASE_LOW (t)) {
+        dump_child ("low ", CASE_LOW (t));
+	if (CASE_HIGH (t)) {
+	  dump_child ("high", CASE_HIGH (t));
+	}
+      }
+      break;
+    case LABEL_EXPR:
+      dump_child ("name", TREE_OPERAND (t,0));
+      break;
+    case GOTO_EXPR:
+      dump_child ("labl", TREE_OPERAND (t, 0));
+      break;
+    case SWITCH_EXPR:
+      dump_child ("cond", TREE_OPERAND (t, 0));
+      dump_child ("body", TREE_OPERAND (t, 1));
+      if (TREE_OPERAND (t, 2))
+        {
+      	  dump_child ("labl", TREE_OPERAND (t,2));
+        }
+      break;
     default:
       /* There are no additional fields to print.  */
       break;
@@ -789,13 +841,28 @@
   return stream;
 }
 
-/* Returns nonzero if tree dump PHASE is enabled.  */
+/* Returns nonzero if tree dump PHASE is enabled.  If PHASE is
+   TDI_all, return nonzero if any dump is enabled.  */
 
 int
 dump_enabled_p (enum tree_dump_index phase)
 {
-  struct dump_file_info *dfi = get_dump_file_info (phase);
-  return dfi->state;
+  if (phase == TDI_all)
+    {
+      size_t i;
+      for (i = TDI_none + 1; i < (size_t) TDI_end; i++)
+	if (dump_files[i].state)
+	  return 1;
+      for (i = 0; i < extra_dump_files_in_use; i++)
+	if (extra_dump_files[i].state)
+	  return 1;
+      return 0;
+    }
+  else
+    {
+      struct dump_file_info *dfi = get_dump_file_info (phase);
+      return dfi->state;
+    }
 }
 
 /* Returns the switch name of PHASE.  */

    regards  Christian

-- 
THAT'S ALL FOLKS!

Re: looking for the developer of tree-dump.c

[Gabriel Dos Reis]

"d43d41u5" <daedalus@freemail.hu> writes:

| Hi !
| 
| For some reason the -fdump-translation-unit switch doesn't dumps the body of
| the functions from the AST if I compile sources with .c extension. (there is
| no "body:" in the .tu dumpfile) Are the functions bodies in the tree, but
| not dumped, or are they stored somewhere else ?

I've come across the similar misbehaivour a week ago for mainline.  I
think it is a regression introduced by the tree-ssa merge.

It is even worse than that:  If you compile your translation unit with
g++ (from mainline), you'll still miss most (all?) function bodies,
except for member functions that are defined in their enclosing
classes.

-- Gaby