<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>
      <p>
        </p><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. 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).</div>
<div><br></div><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>