[BUG]: `cuda::warp_match_all` is not reliable when the input has padding

[fbusato]

Is this a duplicate?

• I confirmed there appear to be no duplicate issues for this bug and that I agree to the Code of Conduct

Type of Bug

Silent Failure

Component

libcu++

Describe the bug

cuda::warp_match_all is a generalization of the __match_all_sync intrinsic. The function relies on bitwise comparison for any type.
If a type has padding, the functionality has undefined behavior. Even if the documentation highlights the problem, the functionality is bug-prone.

possible solutions:

1. Wait until the compiler/nvvm provides a way to detect padding of a type. It could take long time and the function is easy to misused in the meanwhile.
2. Deprecate / mark = delete. Short-term solution (preferred).

[fbusato]

@gonzalobg for visibility

[gonzalobg]

I took a look at the other APIs after finding this, and convinced myself that they don't have this issue, but these sort of issues are quite complex so it may be worth double checking cause I may have missed something.

[bernhardmgruber]

Would it help to static_assert(has_unique_object_representations_v<T>)?

[gonzalobg]

That excludes float (https://cpp.godbolt.org/z/Tv6n17v79) so you couldn't use any floating point type (EDIT: or user defined type containing a floating point type) with this API.

[bernhardmgruber]

That excludes float (https://cpp.godbolt.org/z/Tv6n17v79) so you couldn't use any floating point type (EDIT: or user defined type containing a floating point type) with this API.

Oh. That makes sense. If T was an aggreate, we could recursively reflect it in C++17 using the structured binding hack from Boost.PFR. But I see there is no constraint on T, so it could be a class with private members.