[cfe-dev] [Bug 12200] "noreturn" follows virtual method implementation (opposite of g++)

[John McCall]

On Jan 28, 2014, at 4:52 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Tue, Jan 28, 2014 at 10:34 AM, <bugzilla-daemon at llvm.org> wrote:
> 
> Comment # 12 on bug 12200 from John McCall
> (In reply to comment #10)
> > There's also an IRgen problem: it should ignore 'noreturn' when making a
> > (non-devirtualized) virtual call -- that's a property of the function, not
> > of the vtable slot.
> 
> That's the GCC model.  Our design has always been that attribute((noreturn))
> --- when declared in the class definition --- is a property of the signature of
> the virtual function.
> [Moving this discussion to cfe-dev for visibility.]
> 
> This is a GCC attribute, so my first inclination is to say that GCC gets to define its semantics.

Is there a specification for it that I’ve missed?  My understanding is that this is accidental fallout from a particularly poor representation choice that prevents them from supporting noreturn on member functions at all, and that GCC would consider this a (perhaps low priority or even unfixable) bug in their implementation.  Certainly our model is more consistent with the original philosophy behind making __attribute__((noreturn)) part of the function type.  Our model is also more expressive: among other things, it makes it meaningful to put __attribute__((noreturn)) on a virtual function declaration (including a pure one), and it enables things like a member function that polymorphically throws its object as an exception.  In contrast, overriding a noreturn virtual function with a returning implementation seems basically useless — what code could ever reasonably use it? — unless the overridden function is not meant to ever actually be called, and frankly there are much more appropriate tools for that pattern (like builtin_unreachable, or just making the base class abstract).

> Do we actually have a strong case for diverging from GCC here? We have evidence that we're breaking existing code and damaging our portability story by doing so. (FWIW, C++11's [[noreturn]] behaves like GNU's [[noreturn]], and our implementation of _Noreturn does the same. I don't know how __declspec(noreturn) behaves.)

Analogies to [[noreturn]] and _Noreturn are flawed because they are defined by the standards to not be part of the type.  If you want to argue that all of these attributes should be interchangeable, you’re really arguing for a fundamental change to the GCC extension.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140128/7500403c/attachment.html>