This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[patches] fix semantics for walk_stmt_tree()


According to the comment documenting walk_stmt_tree(), when
argument walk_subtrees is 0, the subtrees of the current node
will not be visited. 

However, as it is currently implemented, setting walk_subtrees to
0 will actually stop traversing the tree chain as well. Which of
the two is the intended semantics for this argument? IMO, the
more useful semantics is the first one. Furthermore, there
already is a way of stopping a tree traversal, just return a
non-null value from the callback. Having two ways of doing the
same thing seems silly.

The only place where we seem to use walk_stmt_tree is in
prune_unused_decls() which makes use of the implemented
behaviour.

The following patch makes the behaviour of walk_stmt_tree match
its documentation. But it breaks prune_unused_decls(), of course.
The question is, should I fix prune_unused_decls() or change the
comment for walk_subtrees()?

Thanks.

2001-02-27  Diego Novillo  <dnovillo@redhat.com>

	* c-common.c (walk_stmt_tree): Visit the chain of the current tree
	even if walk_subtrees is 0.

Index: c-common.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-common.c,v
retrieving revision 1.227
diff -d -c -p -r1.227 c-common.c
*** c-common.c	2001/02/16 13:08:44	1.227
--- c-common.c	2001/02/27 05:55:27
*************** walk_stmt_tree (tp, func, data)
*** 3797,3821 ****
    if (result)
      return result;
  
-   /* Even if we didn't, FUNC may have decided that there was nothing
-      interesting below this point in the tree.  */
-   if (!walk_subtrees)
-     return NULL_TREE;
- 
    /* FUNC may have modified the tree, recheck that we're looking at a
       statement node.  */
    code = TREE_CODE (*tp);
    if (!statement_code_p (code))
      return NULL_TREE;
  
!   /* Walk over all the sub-trees of this operand.  Statement nodes never
!      contain RTL, and we needn't worry about TARGET_EXPRs.  */
!   len = TREE_CODE_LENGTH (code);
  
!   /* Go through the subtrees.  We need to do this in forward order so
!      that the scope of a FOR_EXPR is handled properly.  */
!   for (i = 0; i < len; ++i)
!     WALK_SUBTREE (TREE_OPERAND (*tp, i));
  
    /* Finally visit the chain.  This can be tail-recursion optimized if
       we write it this way.  */
--- 3797,3821 ----
    if (result)
      return result;
  
    /* FUNC may have modified the tree, recheck that we're looking at a
       statement node.  */
    code = TREE_CODE (*tp);
    if (!statement_code_p (code))
      return NULL_TREE;
  
!   /* Visit the subtrees unless FUNC decided that there was nothing
!      interesting below this point in the tree.  */
!   if (walk_subtrees)
!     {
!       /* Walk over all the sub-trees of this operand.  Statement nodes
! 	 never contain RTL, and we needn't worry about TARGET_EXPRs.  */
!       len = TREE_CODE_LENGTH (code);
  
!       /* Go through the subtrees.  We need to do this in forward order so
! 	 that the scope of a FOR_EXPR is handled properly.  */
!       for (i = 0; i < len; ++i)
! 	WALK_SUBTREE (TREE_OPERAND (*tp, i));
!     }
  
    /* Finally visit the chain.  This can be tail-recursion optimized if
       we write it this way.  */


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]