[cfe-dev] PR15105: __attribute__((noreturn)) and noreturn function types

[John McCall]

On Jan 29, 2013, at 3:41 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> As PR15105 notes, our implementation of __attribute__((noreturn)) is
> not entirely GCC-compatible. As far as I can tell, the situation in
> GCC is:
> 
> GCC does not have a plain 'noreturn function' type.
> __attribute__((noreturn)) on a function declaration makes that
> declaration declare a noreturn function. It does not affect the
> function's type.
> __attribute__((noreturn)) on a function pointer or function reference
> produces a 'pointer/reference to noreturn function' type.
> GCC allows implicit conversions in either direction between
> pointer-to-noreturn-function and pointer-to-function.
> 
> In Clang:
> 
> Clang *does* have a plain 'noreturn function' type.
> __attribute__((noreturn)) on a function declaration makes that
> declaration declare a noreturn function, and *adjusts the function
> type* to be a noreturn function.
> __attribute__((noreturn)) on a function pointer or function reference
> produces a 'pointer/reference to noreturn function' type.
> Clang allows a pointer-to-noreturn-function to implicitly convert to a
> pointer-to-function, but not vice versa.
> 
> So... Clang's approach is more sound and type-safe, but it's not
> GCC-compatible. The difference reaches into the language semantics
> (C++ templates can tell the difference between noreturn and
> not-noreturn functions), and the ABI (GCC has a different mangling for
> pointer-to-noreturn-function which Clang does not implement).
> 
> What do people think? Is our improved behavior here sufficient to
> justify the GCC incompatibility, or should we switch to being GCC
> compatible? Or pick some middle-ground -- perhaps we could continue to
> diagnose pointer-to-function to pointer-to-noreturn-function
> conversions, except where the source expression is directly taking the
> address of a noreturn function?

We're not guided by language standards here, and GCC's model for this
is quite bizarre, probably because of the internal representational issues.
For example, they drop "noreturn" on member functions because volatile
functions are valid there, and I assume they get the subtype relationship
wrong because it's generally valid to add the volatile qualifier in
a pointer conversion.

If their model were any less broken, I might agree with the compatibility
argument.  As it is, it seems like a major drop in functionality for a pretty
theoretical interoperation gain.

That said, I see no reason not to adopt their mangling as a special case
when mangling pointers and references to noreturn functions.

John.