[CUDA] Work around compatibility issue with libstdc++ 11.1.0

[tra]

Summary

libstdc++ 11.1.0 redeclares failed_assertion multiple times and that results in the
function declared with conflicting set of attributes when we include <complex>
with host__ device attributes force-applied to all functions.

In order to work around the issue, we rename __failed_assertion within the
region with forced attributes.

See https://bugs.llvm.org/show_bug.cgi?id=50383 for the details.

[fodinabor]

Sadly don't have stdibc++11 available locally as well.. so can't verify, but looks good to me except for the push and pop macros.

clang/lib/Headers/cuda_wrappers/complex

77

Not sure I understand what the push of __failed_assert is for..? can't find any reference to __failed_assert anywhere... did you mean to write __failed_assertion?

[tra]

clang/lib/Headers/cuda_wrappers/complex

77

It's a precaution -- we have no control over what may or may not be defined outside of this header.

[tra]

Fixed typo in push/pop macro name.

clang/lib/Headers/cuda_wrappers/complex

77

That, and I've made a typo. Fixed now.

[fodinabor]

LGTM :)

[jwakely]

You can't use __GLIBCXX__ this way. It will be different for different snapshots from the gcc-11 branch. Some distros are already shipping gcc-11 snapshots with later dates.

I would just check RELEASE == 11. If __failed_assertion is present, you'll rename it. If it's not present, nothing gets renamed but it works anyway.

Or you could pick a date next week and assume I'll have removed the __failed_assertion declarations by then (it should happen on Monday or Tuesday).

[tra]

Check only _GLIBCXX_RELEASE

[tra]

In D102936#2774686, @jwakely wrote:

You can't use __GLIBCXX__ this way. It will be different for different snapshots from the gcc-11 branch. Some distros are already shipping gcc-11 snapshots with later dates.

I would just check RELEASE == 11. If __failed_assertion is present, you'll rename it. If it's not present, nothing gets renamed but it works anyway.

Good point. I've updated the patch.

[yaxunl]

clang/lib/Headers/cuda_wrappers/complex

79

May I ask where is __cuda_failed_assertion defined? Thanks.

[tra]

clang/lib/Headers/cuda_wrappers/complex

79

The function is not defined anywhere.

From https://bugs.llvm.org/show_bug.cgi?id=50383#c14

Its sole purpose is to be a non-constexpr function that can be called during constant
evaluation to cause a compilation error. It can't be called at runtime, because
compilation will fail if control flow ever results in calling it. So no definition is needed.

[jwakely]

LGTM

clang/lib/Headers/cuda_wrappers/complex

 // don't care that they don't resolve to the right function because we won't
 // codegen this host code when compiling for device.
 
 #pragma push_macro("_GLIBCXX_USE_C99_COMPLEX")
 #pragma push_macro("_GLIBCXX_USE_C99_COMPLEX_TR1")
 #define _GLIBCXX_USE_C99_COMPLEX 0
 #define _GLIBCXX_USE_C99_COMPLEX_TR1 0
 
+// Work around a compatibility issue with libstdc++ 11.1.0
+// https://bugs.llvm.org/show_bug.cgi?id=50383
+#pragma push_macro("__failed_assertion")
+#if _GLIBCXX_RELEASE == 11
+#define __failed_assertion __cuda_failed_assertion
+#endif
+
 #include_next <complex>
 
+#pragma pop_macro("__failed_assertion")
 #pragma pop_macro("_GLIBCXX_USE_C99_COMPLEX_TR1")
 #pragma pop_macro("_GLIBCXX_USE_C99_COMPLEX")
 
 #pragma clang force_cuda_host_device end
 
 #endif // include guard