This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/49756] g++ ICE
- From: "jason at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 18 Jul 2011 14:17:51 +0000
- Subject: [Bug c++/49756] g++ ICE
- Auto-submitted: auto-generated
- References: <bug-49756-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49756
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org
|gnu.org |
--- Comment #2 from Jason Merrill <jason at gcc dot gnu.org> 2011-07-18 14:17:34 UTC ---
(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.