Example program takes 2000 times as long to compile under C++ as C

[Zack Weinberg]

On Tue, Sep 05, 2000 at 09:35:07PM -0700, Mark Mitchell wrote:
> >>>>> "Zack" == Zack Weinberg <zack@wolery.cumb.org> writes:
> 
>     Zack> Also it appears to be unnecessary for walk_tree to dink with
>     Zack> the current line number, but I may be missing something.
> 
> I agree; that's seems a little odd.  That's from
> 
>   2000-05-01  Jason Merrill  <jason@casey.cygnus.com>
> 
> 	* tree.c (walk_tree): Set lineno.
> 
> Jason's message to gcc-patches said:
> 
>   Fixes line numbers on error messages for g++.pt/crash6.C when compiled
>   with optimization.
> 
> Would you see if that's still true, before committing those bits?

Unfortunately, it is still true.  The test suite doesn't try that one
with optimization, so I missed it.

I'll apply the patch with the line number dinking put back into
walk_tree, but not walk_stmt_tree (since I know that its users can't
cause problems).

> As for the tail recursion, I sort-of think we're likely to have to
> go to some kind of queue to avoid the recursion at some point, but
> that makes debugging much harder, so I'm trying to put it off until
> we really have to.

My point was more that this is an obvious case, and the tail recursion
optimizer isn't doing its job.  I could have done it by hand:

    return walk_tree (&TREE_OPERAND (*tp), ...);

becomes

    tp = &TREE_OPERAND (*tp);
    goto top_of_function;

but I'd rather see sibcall fixed.  (I don't have time to do it myself.
Hypothesis: maybe it thinks the recursive call uses the address of an
object in the current function's stack frame?)

I need to finish cleaning up the integrated preprocessor patch, then
I'll try us out on Apple's monster test case again.  I think that hits
an entirely different set of bottlenecks :(

zw