Anastasia marked an inline comment as done.
Anastasia added inline comments.
================
Comment at: lib/Sema/TreeTransform.h:5363
+ if (ResultType.getAddressSpace() != LangAS::Default &&
+ (ResultType.getAddressSpace() != LangAS::opencl_private)) {
SemaRef.Diag(TL.getReturnLoc().getBeginLoc(),
----------------
Anastasia wrote:
> rjmccall wrote:
> > Anastasia wrote:
> > > I am trying to be a bit more helpful here although I am not sure if we
> > > should instead require explicit template parameter and fail the template
> > > deduction instead.
> > >
> > > Basically, do we want the following code to always require specifying
> > > template argument explicitly:
> > >
> > >
> > > ```
> > > template <class T>
> > > T xxx(T *in) {
> > > T *i = in;
> > > return *i;
> > > }
> > >
> > > __kernel void test() {
> > > int foo[10];
> > > xxx<int>(&foo[0]); // if we deduce type from foo, it ends up being
> > > qualified by __private that we currently diagnose. However private is
> > > default (implicit) address space for return type so technically there is
> > > no danger in just allowing xxx(&foo[0])
> > > }
> > > ```
> > Implicitly ignoring all address-space qualifiers on the return type seems
> > like the right thing to do; I don't think it needs to be limited to
> > `__private`. That's probably also the right thing to do for locals, but
> > I'm less certain about it.
> Just to clarify by "Implicitly ignoring" you mean ignoring if the templ
> parameters were deduced?
>
> Although I am a bit concerned about allowing other than `__private` address
> spaces in return types as we reject them in return types of functions
> generally. Would it not be somehow inconsistent?
Ok, I have removed the diagnostic completely. At least we don't seem to
generate any incorrect IR.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D62584/new/
https://reviews.llvm.org/D62584
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
