http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59255
--- Comment #4 from Mark Jarvin <mark at jarv dot in> --- I think the other relevant text from the C++11 standard is available here: http://stackoverflow.com/q/13041715/228142 "An implicitly declared special member function (Clause 12) shall have an exception-specification. If f is an implicitly declared default constructor, copy constructor, move constructor, destructor, copy assignment operator, or move assignment operator, its implicit exception-specification specifies the type-id T if and only if T is allowed by the exception-specification of a function directly invoked by f’s implicit definition; f shall allow all exceptions if any function it directly invokes allows all exceptions, and f shall allow no exceptions if every function it directly invokes allows no exceptions." I guess I'm trying to build the case that it makes sense that icall_bb has no EH successor because it's a must-not-throw block, and it's a must-not-throw block in this specific case because it's a destructor with -std=c++11 and its members are (I'm guessing) all must-not-throw. The bug amounts to the code not correctly handling must-not-throw statements. If you buy that argument, I think there might be other places in GCC that aren't handling it either. For example, cfgexpand.c:2313 simply checks that lp_nr != 0. Likewise cgraph.c:1084, tree-cfg.c:4709, tree-eh.c:3029, maybe others.
