[cfe-dev] [OpenCL patch] Vector literals are rvalues *updated*

[Anton Lokhmotov]

> > importantly, neither OpenCL nor AltiVec (see permit using curly braces 
> > for initialising vector literals.  Do we need to worry about preserving
> > behaviour of (theoretically existing) code that's illegal to start with?
> 
> It's not illegal, it's just non-standard.  Notably, it's supported by
> previous releases of Apple's OpenCL parser, so it's something we should 
> not break.

John, just to make clear: I am not proposing to abolish the curly braces
syntax.  The question is whether:

>>>> this should be an r-value:
>>>> (int4) (3,2,1,0)
>>>> and this should be an l-value:
>>>> (int4) {3,2,1,0}

I take a little issue with this.  When the OpenCL dialect of C is used,
vector literals must be treated as rvalues, no matter which syntax is used.
The attached patch does exactly that:

-  case Expr::CompoundLiteralExprClass:
-    return Ctx.getLangOptions().CPlusPlus? Cl::CL_ClassTemporary 
-                                         : Cl::CL_LValue;
+    // OpenCL follows C99, but makes an exception for vector
+    //    literals (see OpenCL 1.1, 6.1.6).
+  case Expr::CompoundLiteralExprClass:
+    if (Ctx.getLangOptions().OpenCL && E->getType()->isExtVectorType())
+      return Cl::CL_PRValue;
+    else if (Ctx.getLangOptions().CPlusPlus)
+      return Cl::CL_ClassTemporary;
+    else
+      return Cl::CL_LValue;

If some code uses (int4){3,2,1,0} as an lvalue, the code does not conform to
the OpenCL specification and must be rejected (not because of the curly
braces syntax!).

I've included a new test case to demonstrate that taking the address of a
vector literal is rejected (as in OpenCL) but taking the address of an array
or struct literal is accepted (as in C99).

Please let me know if it's OK to commit.

Many thanks,
Anton.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compound_literals.cl
Type: application/octet-stream
Size: 653 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110928/d46dab4e/attachment.obj>