Clang doesn't equate __attribute__((noreturn)) and [[noreturn]]

[aoates]

When __attribute__((noreturn)) is set on a function pointer, a function marked [[noreturn]] cannot be assigned to it.

Original context on gdb-patches mailing list (https://sourceware.org/pipermail/gdb-patches/2024-October/212507.html)

Example:

typedef __attribute__((noreturn)) void (*noreturn_ptr)(void);

__attribute__((noreturn)) void function_attr1(void);
[[noreturn]] void function_attr2(void);
void function_noattr(void);

void test(void) {
  noreturn_ptr fptr[3];

  fptr[0] = &function_attr1;   // OK
  fptr[1] = &function_attr2;   // Should be OK?  But is error.
  fptr[2] = &function_noattr;  // Error
}

Compiling:

$ clang -c -o /dev/null noreturn_test.c
noreturn_test.c:11:11: error: incompatible function pointer types assigning to 'noreturn_ptr' (aka 'void (*)(void) __attribute__((noreturn))') from 'void (*)(void)' [-Wincompatible-function-pointer-types]
   11 |   fptr[1] = &function_attr2;   // Should be OK?  But is error.
      |           ^ ~~~~~~~~~~~~~~~
noreturn_test.c:12:11: error: incompatible function pointer types assigning to 'noreturn_ptr' (aka 'void (*)(void) __attribute__((noreturn))') from 'void (*)(void)' [-Wincompatible-function-pointer-types]
   12 |   fptr[2] = &function_noattr;  // Error
      |           ^ ~~~~~~~~~~~~~~~~
2 errors generated.

This seems incorrect --- clang should treat function_attr2 the same as function_attr1. As a point of reference, GCC does this (it allows the assignment in the second line).

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (aoates)

When `__attribute__((noreturn))` is set on a function pointer, a function marked `[[noreturn]]` cannot be assigned to it.

Original context on gdb-patches mailing list (https://sourceware.org/pipermail/gdb-patches/2024-October/212507.html)

Example:

typedef __attribute__((noreturn)) void (*noreturn_ptr)(void);

__attribute__((noreturn)) void function_attr1(void);
[[noreturn]] void function_attr2(void);
void function_noattr(void);

void test(void) {
  noreturn_ptr fptr[3];

  fptr[0] = &function_attr1;   // OK
  fptr[1] = &function_attr2;   // Should be OK?  But is error.
  fptr[2] = &function_noattr;  // Error
}

Compiling:

$ clang -c -o /dev/null noreturn_test.c
noreturn_test.c:11:11: error: incompatible function pointer types assigning to 'noreturn_ptr' (aka 'void (*)(void) __attribute__((noreturn))') from 'void (*)(void)' [-Wincompatible-function-pointer-types]
   11 |   fptr[1] = &function_attr2;   // Should be OK?  But is error.
      |           ^ ~~~~~~~~~~~~~~~
noreturn_test.c:12:11: error: incompatible function pointer types assigning to 'noreturn_ptr' (aka 'void (*)(void) __attribute__((noreturn))') from 'void (*)(void)' [-Wincompatible-function-pointer-types]
   12 |   fptr[2] = &function_noattr;  // Error
      |           ^ ~~~~~~~~~~~~~~~~
2 errors generated.

This seems incorrect --- clang should treat function_attr2 the same as function_attr1. As a point of reference, GCC does this (it allows the assignment in the second line).

[shafik]

CC @erichkeane

[erichkeane]

So the problem here is that we don't treat [[noreturn]] as part of the function type, but __attribute__((noreturn)) (GNU spelling) IS. We treat [[noreturn]] as a part of the function decl instead of the type, which I believe is consistent with the standard. The result is that by the time we do our overload, we end up losing the [[noreturn]] for the point of our checking.

I believe we are 'right' in that perspective as far as the standard is concerned, but the interop with GCC is our problem. As far as I can tell, GCC's spelling of noreturn in GCC doesn't seem to actually modify the type (so the last line, isn't a conversion, it just isn't an error).

The fix here is likely to just see if we can make the GNU spelling of noreturn be the same implementation as the CXX11NoReturn/C11NoReturn (likely depending on language mode). But perhaps @AaronBallman can share more context/hints?

THis MIGHT be a beginner bug if the answer is to just add the spelling of the gnu attribute as an alias of the standards ones.

[AaronBallman]

As far as I can tell, GCC's spelling of noreturn in GCC doesn't seem to actually modify the type (so the last line, isn't a conversion, it just isn't an error).

I think this confirms it: https://godbolt.org/z/Md9Ej1PWv

The fix here is likely to just see if we can make the GNU spelling of noreturn be the same implementation as the CXX11NoReturn/C11NoReturn (likely depending on language mode). But perhaps @AaronBallman can share more context/hints?

That does seem plausible, but I think we should try to figure out why we are trying to make this a type attribute in the first place.

[erichkeane]

Looks like this attribute was added in: f7146ca

It seems to have added it as a decl attribute at that point.

This commit: 8c5d7996e840a

Seems to add it as a type attribute, but without any real explaination? You can see it kinda gets everywhere to implement, so removing all references to it might be nice.

So... anyone around at the time who can help? @rjmccall and @DougGregor and @lattner seem to be the only ones who were around at the time that i can still see.

[AaronBallman]

Looking through the cfe-dev and cfe-commits archives around that timeframe shows no discussion either.

[zygoloid]

GCC used to treat noreturn as part of the type in a typedef for a function type. It looks like this changed in GCC 5 -- at least, that's when the "volatile" bit (!) stops showing up in mangling for a noreturn function type. The GCC documentation also suggests that treating noreturn as a volatile qualifier on a function type is supposed to only happen in C.

Clang has never implemented the mangling part of this (mangling the noreturn type bit as V), but did implement the "noreturn attribute is part of the type" portion because it has historically aimed to be compatible with GCC 4.2.

[erichkeane]

Hmm... GCC seemingly NEVER disallowed conversions between the two types. It looks like based on the 3.4.6 diagnostic that they initially just had it alias volatile in some way (take the previous godbolt and switch it to GCC 3.4.6), which is why it was just mangling volatile.

It would be GREAT to remove it from the function type 'some day', but the GCC4.2 compat story likely means we cannot. In the meantime, I think we could probably have SemaOverload.cpp's TryImplicitConversion just permit the noreturn function types to be convertible. It LOOKS like we do something similar for HLSL (though that seems to be considered a Standard conversion, which is probably wrong EDIT: Standard is the opposite of UserDefined, so perhaps that conversion makes sense), so we could probably put it right there.

IDK how 'newbie friendly' this bug ends up being, but perhaps the hardest part is just writing a ton of tests, as I've identified where the change could be made?

[zygoloid]

It looks like, while GCC did treat noreturn and non-noreturn function types as being different, it allowed conversions between them, even under multiple layers of pointers or pointers to members, but not when used as template arguments.

And in fact some of that seems to still be true in GCC trunk. Looks like GCC's current behavior is:

• The noreturn function type qualifier is not mangled any more, even though you can overload on it!
• The noreturn qualifier in a function pointer can be added or removed by an implicit conversion.
• Pointers to pointers cannot have noreturn added or removed, even if all the intervening levels of pointer are const.
• Noreturn and non-noreturn types are treated as different canonical types when used as type template arguments.

So I think the only way in which Clang's behavior is diverging from GCC's here is that we don't support an implicit conversion between pointer-to-function and pointer-to-noreturn function. This should presumably behave somewhat like the implicit conversion between pointer-to-function and pointer-to-noexcept-function except that it can apparently be performed implicitly in either direction.

[zygoloid]

In the meantime, I think we could probably have SemaOverload.cpp's TryImplicitConversion just permit the noreturn function types to be convertible.

Looks like we were typing our comments at the same time, and came to the same conclusion :-)

[pinskia]

GCC bugs in the area of noreturn and function types:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79604
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80496

there might be more.

[rjmccall]

IIRC, GCC used to not support noreturn on C++ methods exactly because they used the volatile qualifier to encode it, which on methods conflicted with how they represented method type qualifiers.

The decision to honor noreturn as structurally part of the type wasn't solely motivated by a desire to strictly match the GCC 4.2 semantics; we (I?) also felt convinced that it was the semantically cleaner model, and we've kept to it despite the growing mismatch with GCC behavior.