================
@@ -93,16 +73,6 @@
__SPIRV_BUILTIN_ALIAS(__builtin_spirv_generic_cast_to_ptr_explicit)
__private const void *
__spirv_GenericCastToPtrExplicit_ToPrivate(__generic const void *,
int) __SPIRV_NOEXCEPT;
-extern __SPIRV_overloadable
-__SPIRV_BUILTIN_ALIAS(__builtin_spirv_generic_cast_to_ptr_explicit)
-__private volatile void *
-__spirv_GenericCastToPtrExplicit_ToPrivate(__generic volatile void *,
- int) __SPIRV_NOEXCEPT;
-extern __SPIRV_overloadable
-__SPIRV_BUILTIN_ALIAS(__builtin_spirv_generic_cast_to_ptr_explicit)
-__private const volatile void *
-__spirv_GenericCastToPtrExplicit_ToPrivate(__generic const volatile void *,
- int) __SPIRV_NOEXCEPT;
----------------
Naghasan wrote:
> In such case, any built-in that uses the pointer arg will have the same issue,
Not sure what you mean. Did you mean the returned value ?
> IMO whether volatile is present should reflect how the built-in uses the
> pointer argument
Yes and no, there are situation where we should ban certain overload because it
doesn't make sense (e.g. no const if we write the memory) but we also want a
certain level of flexibility. Taking your point to the letter, the only
overload we need here is the one taking / returning `const`, but that would
force users to cast away the const (which usually raises a few eyebrows...).
I don't have strong opinion, a cast on the return type will usually be
required, but I find it better to not have to deal with cv-quals.
https://github.com/llvm/llvm-project/pull/146298
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
