rsmith added a comment. In D102689#2778011 <https://reviews.llvm.org/D102689#2778011>, @rjmccall wrote:
> The C++ standard does not appear to have similar wording. On the other hand, > the C++ standard says that e.g. "The result of the expression `(T) > cast-expression` is of type `T`", and similarly for the other casts, which is > clearly just wrong if `T` is a reference type; the wording clarifies that the > expression is an l-value or x-value if the type is a reference but doesn't > remove the reference-ness of the expression type as it must, unless that's > done by some other clause at a distance. It is indeed done by a different clause at a distance: **[expr.type]** > 1. If an expression initially has the type “reference to `T`”, the type is > adjusted to `T` prior to any further analysis. The expression designates the > object or function denoted by the reference, and the expression is an lvalue > or an xvalue, depending on the expression. > 2. If a prvalue initially has the type “cv `T`”, where `T` is a > cv-unqualified non-class, non-array type, the type of the expression is > adjusted to `T` prior to any further analysis. In D102689#2778011 <https://reviews.llvm.org/D102689#2778011>, @rjmccall wrote: > C++ has a very strange feature of allowing qualifiers on class types in > particular circumstances, so we might need to be permissive about that, > although that's tricky for address spaces because (unlike with `const` or > `volatile`) we cannot in fact allocate a temporary in an arbitrary address > space. Right, specifically C++ preserves top-level `const` and `volatile` qualifications on prvalues only if they're of class or array type. If an address-space-qualified temporary makes sense, then I think extending this behavior to address spaces makes sense too: - For array prvalues, an `AS1 int[3]` should decay to an `AS1 int*`, not to a plain `int*`, because it seems clear the intent is for the array to be created in the given address space. - For class prvalues, I think it's important that we preserve the address space, because (for example) a function `AS1 MyClass f();` might take a return value slot as an `AS1` pointer, so a prvalue `f()` should retain the address space qualification. While we can't allocate an address-space-qualified temporary right now, would it be a good idea to prepare for the possibility that we will one day be able to, in some cases? For example, in a system with separate control and data stacks, we might want to put some data on the control stack; in an exotic heterogeneous compute system we might be able to allocate memory in the host and device stack from a single function. If so, following the C++ rule for all qualifiers might be a good direction. (We'll presumably need to look at the other qualifiers and see if any of them would have problems with this treatment.) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D102689/new/ https://reviews.llvm.org/D102689 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
