ebevhan added inline comments.
================ Comment at: lib/Sema/SemaInit.cpp:4539 + if (InitCategory.isPRValue() || InitCategory.isXValue()) + T1Quals.removeAddressSpace(); + ---------------- rjmccall wrote: > rjmccall wrote: > > I can understand why a pr-value wouldn't have an address space, but an > > x-value's address space is surely important. > No, wait, I think this is more deeply wrong. We're initializing a reference > to type `cv1 T1`, and if we're initializing it with a temporary, we're > dropping the address space from `cv1`? That's definitely wrong. > > If we're starting with a pr-value, reference-initialization normally has to > start by initializing a temporary. (The exception is it's a class type with > a conversion operator to a reference type; C++ is abysmally complicated. > Let's ignore this for a moment.) Temporaries are always in the default > address space (the address space of local variables) because the language > (neither OpenCL nor Embedded C) does not give us any facility for allocating > temporary memory anywhere else. So reference-initialization from a pr-value > creates a temporary in the default address space and then attempts to > initialize the destination reference type with that temporary. That > initialization should fail if there's no conversion from the default address > space to the destination address space. For example, consider initializing a > `const int __global &` from a pr-value: this should clearly not succeed, > because we have no way of putting a temporary in the global address space. > That reference can only be initialized with a gl-value that's already in the > `__global` address space. > > On the other hand, we can successfully initialize a `const int &` with a > gl-value of type `const int __global` not by direct reference initialization > but by loading from the operand and then materializing the result into a new > temporary. > > I think what this means is: > > - We need to be doing this checking as if pr-values were in `__private`. > This includes both (1) expressions that were originally pr-values and (2) > expressions that have been converted to pr-values due to a failure to perform > direct reference initialization. > > - We need to make sure that reference compatibility correctly prevents > references from being bound to gl-values in incompatible address spaces. > On the other hand, we can successfully initialize a `const int &` with a > gl-value of type `const int __global` not by direct reference initialization > but by loading from the operand and then materializing the result into a new > temporary. Is this the right thing to do? It means that initializing such a reference would incur a cost under the hood that might be unnoticed/unwanted by the user. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D56066/new/ https://reviews.llvm.org/D56066 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
