[OpenCL] Disable && (address of label) GNU extension for OpenCL

[echuraev]

Summary

Patch by Guy Benyei

[Anastasia]

It seems that this bit is accepted under -std=c99 and the warning is given with the -pedantic flag. I am not sure whether it adds much deviating the implementation from C here. The OpenCL spec doesn't seem to contain anything on this matter? But if we decide to be more strict, could we try to keep it consistent with the C implementation (perhaps we could give the same diagnostic as C does as an error instead or a warning).

Also this bit gives different error in C:

int a;
void *p = &&a;
error: use of undeclared label 'a'

It doesn't seem like any of the errors for that code is more logical or precise. But if I would have to pick among equivalent approaches I would go for keeping it coherent with C.

[rsmith]

Please don't ban things just because you can. If there's some reason why this doesn't make sense in OpenCL, this may be fine, but generally you shouldn't be making this language mode deviate from clang's normal behaviour regarding extensions.

(It would be great if we had a flag to turn off gnu extensions other than -pedantic-errors, like we have for MS extensions, but that's mostly orthogonal to OpenCL.)

[keryell]

+1
Please do not remove anything, since it may be useful in some contexts.

I do not think there are negative tests in the Khronos OpenCL conformance test suite anyway.

include/clang/Basic/DiagnosticParseKinds.td

 def warn_pragma_unknown_extension : Warning<
   "unknown OpenCL extension %0 - ignoring">, InGroup<IgnoredPragmas>;
 def warn_pragma_unsupported_extension : Warning<
   "unsupported OpenCL extension %0 - ignoring">, InGroup<IgnoredPragmas>;
 def warn_pragma_extension_is_core : Warning<
   "OpenCL extension %0 is core feature or supported optional core feature - ignoring">, InGroup<DiagGroup<"pedantic-core-features">>, DefaultIgnore;
 
 // OpenCL errors.
+def err_opencl_address_of_label : Error<
+  "OpenCL does not support address of label ('&&') GNU extension">;
 def err_opencl_taking_function_address_parser : Error<
   "taking address of function is not allowed">;
 def err_opencl_logical_exclusive_or : Error<
   "^^ is a reserved operator in OpenCL">;
 
 // OpenMP support.
 def warn_pragma_omp_ignored : Warning<
   "unexpected '#pragma omp ...' in program">, InGroup<SourceUsesOpenMP>, DefaultIgnore;

lib/Parse/ParseExpr.cpp

#undef RTT_JOIN
   // unary-expression: '__builtin_omp_required_simd_align' '(' type-name ')'
   case tok::kw___builtin_omp_required_simd_align:
     return ParseUnaryExprOrTypeTraitExpression();
   case tok::ampamp: {      // unary-expression: '&&' identifier
     SourceLocation AmpAmpLoc = ConsumeToken();
     if (Tok.isNot(tok::identifier))
       return ExprError(Diag(Tok, diag::err_expected) << tok::identifier);
 
+    if (getLangOpts().OpenCL)
+      return ExprError(Diag(Tok, diag::err_opencl_address_of_label));
+
     if (getCurScope()->getFnParent() == nullptr)
       return ExprError(Diag(Tok, diag::err_address_of_label_outside_fn));
     
     Diag(AmpAmpLoc, diag::ext_gnu_address_of_label);
     LabelDecl *LD = Actions.LookupOrCreateLabel(Tok.getIdentifierInfo(),
                                                 Tok.getLocation());
     Res = Actions.ActOnAddrLabel(AmpAmpLoc, Tok.getLocation(), LD);
     ConsumeToken();

test/SemaOpenCL/ampamp-gnu.cl

+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only
+
+kernel void foo(global int *in) {
+  int a;
+  void *p = &&a; // expected-error {{OpenCL does not support address of label ('&&') GNU extension}}
+
+  void *hlbl_tbl[] = { &&label1 }; // expected-error {{OpenCL does not support address of label ('&&') GNU extension}}
+label1:
+  a = 0;
+}