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

[Richard Smith]

On Tue, Jan 28, 2014 at 10:34 AM, <bugzilla-daemon at llvm.org> wrote:

>   *Comment # 12 <http://llvm.org/bugs/show_bug.cgi?id=12200#c12> on bug
> 12200 <http://llvm.org/bugs/show_bug.cgi?id=12200> from John McCall
> <rjmccall at apple.com> *
>
> (In reply to comment #10 <http://llvm.org/bugs/show_bug.cgi?id=12200#c10>)> 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. We've presented this attribute with different
semantics for some time, and it's possible that people are somehow relying
on that, but for the most part, switching to GCC's semantics would be
backwards-compatible (we may start producing -Wmissing-noreturn warnings on
derived class functions that don't return and override a noreturn function,
for instance, and we'll lose some optimization opportunities).

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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140128/9832dc2b/attachment.html>