<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 28, 2014 at 5:41 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="im">On Jan 28, 2014, at 4:52 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:<br>
</div><div><div class="im"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 28, 2014 at 10:34 AM, <span dir="ltr"><<a href="mailto:bugzilla-daemon@llvm.org" target="_blank">bugzilla-daemon@llvm.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div>
<br></div><div>
<b><a title="NEW --- - "noreturn" follows virtual method implementation (opposite of g++)" href="http://llvm.org/bugs/show_bug.cgi?id=12200#c12" target="_blank">Comment # 12</a>
on <a title="NEW --- - "noreturn" follows virtual method implementation (opposite of g++)" href="http://llvm.org/bugs/show_bug.cgi?id=12200" target="_blank">bug 12200</a>
from <span><a href="mailto:rjmccall@apple.com" title="John McCall <rjmccall@apple.com>" target="_blank"> <span>John McCall</span></a>
</span></b>
<pre>(In reply to <a href="http://llvm.org/bugs/show_bug.cgi?id=12200#c10" target="_blank">comment #10</a>)
<span>> 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.</span>
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.</pre></div></div></blockquote><div>[Moving this discussion to cfe-dev for visibility.]<br></div><div><br></div><div>This is a GCC attribute, so my first inclination is to say that GCC gets to define its semantics.</div>
</div></div></div></blockquote><div><br></div></div><div>Is there a specification for it that I’ve missed?</div></div></div></blockquote><div><br></div><div>Sure, it's right there in GCC subversion ;-)</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>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.</div>
</div></div></blockquote><div><br></div><div>I agree, but our model is incompatible with GCC's model, and this breaks real code.</div><div><br></div><div>[For posterity, GCC's (bizarre) model is as follows... When applied to a function, it means that function does not return. When applied to a function pointer type or a function reference type, it affects the type. The type of a function declared __attribute__((noreturn)) is *not* a noreturn function type, and taking the address of a function declared __attribute__((noreturn)) does *not* give a noreturn function pointer.]</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>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),</div>
</div></div></blockquote><div><br></div><div>That's also meaningful in the GCC model: it means a devirtualized or non-virtual call is known to not return.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div>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?</div>
</div></div></blockquote><div><br></div><div>Code where the base class implements a function that always throws (maybe a "not implemented" exception) and the derived class does not? This doesn't seem unreasonable, and bug 12200 and its duplicate are examples reduced from real code that did exactly this, as far as I can see.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div>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.)</div>
</div></div></div></blockquote></div></div><br><div>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.</div>
</div></blockquote><div><br></div><div>I don't want to argue these should be interchangeable -- just observing that we are the only ones providing this noreturn-virtual-function-implies-overrides-are-noreturn behavior (though admittedly it's a small sample set, since _Noreturn doesn't count).</div>
<div><br></div><div>What I'm suggesting is that perhaps our GCC attribute should match GCC, and if not, we should have a solid reason for the difference, documented somewhere visible, explaining why we thought our semantics for a GCC attribute were more important than compatibility with GCC, that we can point people to when we get the next duplicate of this bug filed.</div>
</div></div></div>