================
@@ -2428,6 +2435,11 @@ static ExprResult BuiltinMaskedScatter(Sema &S, CallExpr 
*TheCall) {
   QualType PtrTy = PtrArg->getType();
   QualType PointeeTy = PtrTy->getPointeeType();
 
+  if (PtrTy->getPointeeType().isConstQualified())
+    return ExprError(
+        S.Diag(PtrArg->getExprLoc(), diag::err_typecheck_assign_const)
+        << /*read-only*/ 5);
----------------
rjmccall wrote:

The non-memory arguments should all be undergoing lvalue-to-rvalue conversion. 
If the builtins are using custom type-checking, you need to do this explicitly. 
This will:
- fix the use of ObjC or MSVC property reference expressions in these positions,
- change object references to be non-ODR-used if they're constant-evaluable, and
- remove qualifiers from the argument type.

The memory argument should not undergo lvalue-to-rvalue conversion, of course.

Since the intrinsic has to implement the memory access manually, you need to 
actually consider all the qualifiers for the memory argument.
- `restrict`, ObjC, and `__ptrauth` qualifiers do not apply to vector types and 
can be ignored.
- `_Atomic` should be disallowed because we don't want to implement it; this 
may happen implicitly in Sema because of its representation, but it's something 
you should explicitly test.
- The intrinsic appears to be overloaded properly for address spaces, so 
address space qualifiers are presumably fine. This should be tested.
- `const` should be allowed only for loads; you've fixed that now, so good.
- Whether `volatile` should be allowed depends on whether we can maintain the 
volatile semantics in LLVM IR. There is no `volatile` flag on the intrinsic, so 
this really depends on (1) whether LLVM will ever optimize these intrinsics in 
the middle-end and (2) whether it ever lowers these intrinsics in a way such 
that the back-end could break `volatile` semantics. The safest answer is to 
disallow it.

https://github.com/llvm/llvm-project/pull/160185
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to