fix max_align_t for __int128

[davebayer]

The max_align_t is described as:

max_align_t is a standard-layout TrivialType(until C++26)TriviallyCopyable type(since C++26) whose alignment requirement is at least as strict (as large) as that of every scalar type.

The max_align_t was defined to be of type long double which could lead to invalid alignment e. g. for NVRTC with __int128 support because long double may be implemented as double which would lead to 8-byte alignment instead of 16-byte.

This PR adds a check for __int128 support before falling back to long double.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[bernhardmgruber]

Thanks for opening this PR, because it makes us aware of the problem. However, touching max_align_t is scary, because we need to make sure it also aligns with the compilers we have in use. Your changeset looks reasonable to me, but I definitely want to have more opinions here.

[wmaxey]

Since _LIBCUDACXX_HAS_NO_INT128 is extremely pessimistic, I would say this change is fine. Most compilers will define their max_align_t and will never end up here. NVRTC alone has the unique property where there is no 'host' alignment.

I can see this backfiring where the host uses 64b alignment and NVRTC compiles with 128b alignment. Interop between host and device might result in silent failures just like #3066.

I'd also like to hear more opinions.