Scalar_accessor conversion operators are not constexpr

[Oblomov]

This is partially related to #2359 and in the same context. In GPUSPH we have several small auxiliary functions that are pure (no side-effects and the return value only depends on the arguments). We also mark this function as constexpr. An example would be:

typedef uint4 vertexinfo;
constexpr __host__ __device__ __forceinline__ __attribute__((pure))
bool has_vertex(vertexinfo const& verts, uint id)
{ return verts.x == id || verts.y == id || verts.z == id; }

Again, this fails to build with g++ (i.e. when compiling the host code with the host compiler):

test3.cc: In function ‘constexpr bool has_vertex(const vertexinfo&, uint)’:
test3.cc:6:21: error: call to non-‘constexpr’ function ‘hip_impl::Scalar_accessor< <template-parameter-1-1>, <template-parameter-1-2>, <anonymous> >::operator T() const [with T = unsigned int; Vector = unsigned int [4]; unsigned int idx = 0]’
    6 | { return verts.x == id || verts.y == id || verts.z == id; }
      |                     ^~
In file included from /opt/rocm-4.3.0/hip/include/hip/amd_detail/channel_descriptor.h:28,
                 from /opt/rocm-4.3.0/hip/include/hip/amd_detail/hip_texture_types.h:38,
                 from /opt/rocm-4.3.0/hip/include/hip/amd_detail/hip_runtime_api.h:40,
                 from /opt/rocm-4.3.0/hip/include/hip/hip_runtime_api.h:410,
                 from /opt/rocm-4.3.0/hip/include/hip/hip_runtime.h:113,
                 from test3.cc:1:
/opt/rocm-4.3.0/hip/include/hip/amd_detail/hip_vector_types.h:113:13: note: ‘hip_impl::Scalar_accessor< <template-parameter-1-1>, <template-parameter-1-2>, <anonymous> >::operator T() const [with T = unsigned int; Vector = unsigned int [4]; unsigned int idx = 0]’ declared here
  113 |             operator T() const noexcept { return data[idx]; }
      |             ^~~~~~~~

[ppanchad-amd]

@Oblomov Apologies for the lack of response. Can you please test with latest ROCm 6.0.2 (HIP 6.0.32831)? If resolved, please close ticket. Thanks!

[Oblomov]

Thanks, this seems to indeed be fixed now.