Re: Patch for Bug#4794

[Jim Wilson <wilson at specifixinc dot com>]

Hubert Xu wrote:
> !         cmp = has_cleanups (TREE_VALUE (TREE_OPERAND (exp, i)));

This isn't right.  TREE_VALUE is only meaningful for a TREE_LIST, and we 
can't possibly have a TREE_LIST here.  TREE_VALUE is wrong for every 
possible tree we can have here.

I suspect you copied this from the CALL_EXPR code above without trying 
to understand what the code was doing.  In that case, we do have a 
TREE_LIST.

I think the problem here is in fold, or perhaps how fold is called from 
the front end.  We end up with a huge tree to represent the expression. 
 It has long repeating sequences of
 <compound_expr <convert_expr <save_expr ...>
I suspect the culprit is fold_binary_op_with_conditional_arg.  I think 
it keeps adding more layers of compound_expr/convert_expr/save_expr 
everytime we call fold, and we eventually end up with a factorial (n!) 
number of them.  Since the input has lots of tests, we end up with a 
tree so large that we can't handle it.

has_cleanups shows up as the culprit in the end only because it tries to 
do a recursive depth-first search of the massive expression tree, and 
this takes a lot of time and a lot of memory (if it isn't compiled tail 
recursive).

This is part speculation.  The tree is so big I didn't look at all of 
it.  There is also the possibility here that we have a circular tree, 
and hence the depth-first search can never complete.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com