I wrote: > Joe> There are several effects from "noreturn". We would want some > Joe> of these effects for "abort", but not others, to get debuggable > Joe> code without degrading compile-time warnings.
On Wed, Aug 06, 2008 at 01:37:51PM -0400, Paul Koning wrote: > So the issue is that two unrelated features are currently combined in > a single attribute: > > 1. This function doesn't return, do the right thing with warnings in > the caller of this function. > > 2. Don't bother saving registers when calling this function because it > won't return so the registers aren't needed afterwards. > > The issue is that #2 doesn't apply to "abort" because the registers > ARE needed afterwards -- at debug time. But not necessarily all of them (depending on platform). That is, the caller-saved registers don't have to be saved because the function isn't returning, but there has to be enough of a stack frame so that a debugger can set a breakpoint on the abort and determine who the caller was. > One possibility is to have "noreturn" mean #1 only, and invent a new > flag for #2. The alternative is to have "noreturn" mean both (as > today) and invent a new flag to cancel #2. > > I'd suggest the former because that's the more likely case. It's hard > to think of examples where #2 is needed (or at least, where it is > important). Evidently there was a motivating application where #2 was an important optimization. Still, I think you're right that it would be better to do it only if the optimization is asked for (via a new flag).
