(In reply to comment #1)
> I can't reproduce the isssue with an unlimited stack with release
> checking compiled FSF 4.6.1 or 4.5.3 releases.
>
> For some reason the C++ compiler nests constructing the members:
> Jason, can't we do something more optimal here?
The nesting is inherent in the language; after the initialization of an object which needs a cleanup, anything that throws needs to destroy that object. So each variable implies a TRY_FINALLY_EXPR to follow it.
For walk_tree we could probably do tail recursion into the try operand, but that won't work for gimplification since we need to process the try before the finally.
I think cc1plus should use setrlimit to raise the stack size limit.
(In reply to comment #1)
> I can't reproduce the isssue with an unlimited stack with release
> checking compiled FSF 4.6.1 or 4.5.3 releases.
>
> For some reason the C++ compiler nests constructing the members:
> Jason, can't we do something more optimal here?
The nesting is inherent in the language; after the initialization of an object which needs a cleanup, anything that throws needs to destroy that object. So each variable implies a TRY_FINALLY_EXPR to follow it.
For walk_tree we could probably do tail recursion into the try operand, but that won't work for gimplification since we need to process the try before the finally.
I think cc1plus should use setrlimit to raise the stack size limit.