date:20210906

[PATCH] D103136: [AVR] Add support for the tinyAVR 0-series and tinyAVR 1-seriesø

2021-09-06 Thread Ben Shi via Phabricator via cfe-commits

benshi001 added inline comments.



Comment at: llvm/lib/Target/AVR/AVRDevices.td:515
+def : Device<"attiny1614", FamilyXMEGA, ELFArchXMEGA3>;
+def : Device<"attiny416",  FamilyXMEGA, ELFArchXMEGA3>;
+def : Device<"attiny816",  FamilyXMEGA, ELFArchXMEGA3>;

`attiny3214` is missing


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103136/new/

https://reviews.llvm.org/D103136

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108366: [clang][deps] Deduce resource directory from the compiler path

2021-09-06 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 updated this revision to Diff 370851.
jansvoboda11 added a comment.
Herald added a subscriber: ormris.

Rebase on top of D108979 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108366/new/

https://reviews.llvm.org/D108366

Files:
  clang/test/ClangScanDeps/Inputs/resource_directory/cdb.json.template
  clang/test/ClangScanDeps/Inputs/resource_directory/compiler
  clang/test/ClangScanDeps/Inputs/resource_directory/mod.h
  clang/test/ClangScanDeps/Inputs/resource_directory/module.modulemap
  clang/test/ClangScanDeps/Inputs/resource_directory/tu.c
  clang/test/ClangScanDeps/resource_directory.c
  clang/tools/clang-scan-deps/ClangScanDeps.cpp


Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -194,6 +194,25 @@
 "until reaching the end directive."),
 llvm::cl::init(true), llvm::cl::cat(DependencyScannerCategory));
 
+enum ResourceDirRecipeKind {
+  RDRK_ModifyCompilerPath,
+  RDRK_InvokeCompiler,
+};
+
+static llvm::cl::opt ResourceDirRecipe(
+"resource-dir-recipe",
+llvm::cl::desc("How to produce missing '-resource-dir' argument"),
+llvm::cl::values(
+clEnumValN(RDRK_ModifyCompilerPath, "modify-compiler-path",
+   "Construct the resource directory from the compiler path in 
"
+   "the compilation database. This assumes it's part of the "
+   "same toolchain as this clang-scan-deps. (default)"),
+clEnumValN(RDRK_InvokeCompiler, "invoke-compiler",
+   "Invoke the compiler with '-print-resource-dir' and use the 
"
+   "reported path as the resource directory. (deprecated)")),
+llvm::cl::init(RDRK_ModifyCompilerPath),
+llvm::cl::cat(DependencyScannerCategory));
+
 llvm::cl::opt Verbose("v", llvm::cl::Optional,
 llvm::cl::desc("Use verbose output."),
 llvm::cl::init(false),
@@ -485,7 +504,7 @@
   AdjustedArgs.push_back("/clang:" + LastO);
 }
 
-if (!HasResourceDir) {
+if (!HasResourceDir && ResourceDirRecipe == RDRK_InvokeCompiler) {
   StringRef ResourceDir =
   ResourceDirCache.findResourceDir(Args, ClangCLMode);
   if (!ResourceDir.empty()) {
Index: clang/test/ClangScanDeps/resource_directory.c
===
--- /dev/null
+++ clang/test/ClangScanDeps/resource_directory.c
@@ -0,0 +1,22 @@
+// RUN: rm -rf %t && mkdir %t
+// RUN: cp %S/Inputs/resource_directory/* %t
+
+// Deduce the resource directory from the compiler path.
+//
+// RUN: sed -e "s:CLANG:/our/custom/bin/clang:g" -e "s:DIR:%t:g" \
+// RUN:   %S/Inputs/resource_directory/cdb.json.template > %t/cdb_path.json
+// RUN: clang-scan-deps -compilation-database %t/cdb_path.json --format 
experimental-full \
+// RUN:   --resource-dir-recipe modify-compiler-path > %t/result_path.json
+// RUN: cat %t/result_path.json | sed 's:\?:/:g' | FileCheck %s 
--check-prefix=CHECK-PATH
+// CHECK-PATH:  "-resource-dir"
+// CHECK-PATH-NEXT: "/our/custom/lib{{.*}}"
+
+// Run the compiler and ask it for the resource directory.
+//
+// RUN: sed -e "s:CLANG:%t/compiler:g" -e "s:DIR:%t:g" \
+// RUN:   %S/Inputs/resource_directory/cdb.json.template > 
%t/cdb_invocation.json
+// RUN: clang-scan-deps -compilation-database %t/cdb_invocation.json --format 
experimental-full \
+// RUN:   --resource-dir-recipe invoke-compiler > %t/result_invocation.json
+// RUN: cat %t/result_invocation.json | sed 's:\?:/:g' | FileCheck %s 
--check-prefix=CHECK-INVOCATION
+// CHECK-INVOCATION:  "-resource-dir"
+// CHECK-INVOCATION-NEXT: "/custom/compiler/resources"
Index: clang/test/ClangScanDeps/Inputs/resource_directory/tu.c
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/tu.c
@@ -0,0 +1 @@
+#include "mod.h"
Index: clang/test/ClangScanDeps/Inputs/resource_directory/module.modulemap
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/module.modulemap
@@ -0,0 +1 @@
+module mod { header "mod.h" }
Index: clang/test/ClangScanDeps/Inputs/resource_directory/compiler
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/compiler
@@ -0,0 +1,2 @@
+#!/usr/bin/env python3
+print("/custom/compiler/resources")
Index: clang/test/ClangScanDeps/Inputs/resource_directory/cdb.json.template
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/cdb.json.template
@@ -0,0 +1,7 @@
+[
+  {
+"directory": "DIR",
+

[PATCH] D109305: [OpenCL] Supports optional program scope global variables in C++ for OpenCL 2021

2021-09-06 Thread Justas Janickas via Phabricator via cfe-commits

Topotuna created this revision.
Topotuna added a reviewer: Anastasia.
Herald added subscribers: ldrumm, yaxunl.
Topotuna requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Adds support for macro `__opencl_c_program_scope_global_variables`
in C++ for OpenCL 2021 enabling a respective optional core feature
from OpenCL 3.0.

This change aims to achieve compatibility between C++ for OpenCL
2021 and OpenCL 3.0.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109305

Files:
  clang/include/clang/Basic/OpenCLOptions.h
  clang/test/SemaOpenCL/storageclass.cl

Index: clang/test/SemaOpenCL/storageclass.cl
===
--- clang/test/SemaOpenCL/storageclass.cl
+++ clang/test/SemaOpenCL/storageclass.cl
@@ -3,6 +3,10 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=+__opencl_c_program_scope_global_variables,-__opencl_c_generic_address_space,-__opencl_c_pipes
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=-__opencl_c_program_scope_global_variables,+__opencl_c_generic_address_space
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=+__opencl_c_program_scope_global_variables,+__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++2021 -cl-ext=-__opencl_c_program_scope_global_variables,-__opencl_c_generic_address_space,-__opencl_c_pipes
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++2021 -cl-ext=+__opencl_c_program_scope_global_variables,-__opencl_c_generic_address_space,-__opencl_c_pipes
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++2021 -cl-ext=-__opencl_c_program_scope_global_variables,+__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++2021 -cl-ext=+__opencl_c_program_scope_global_variables,+__opencl_c_generic_address_space
 static constant int G1 = 0;
 constant int G2 = 0;
 
@@ -43,19 +47,23 @@
 #endif
 
 static generic float g_generic_static_var = 0;
-#if (__OPENCL_C_VERSION__ < 300)
+#if (defined(__OPENCL_C_VERSION__) && __OPENCL_C_VERSION__ < 300)
 // expected-error@-2 {{OpenCL C version 1.2 does not support the 'generic' type qualifier}}
 // expected-error@-3 {{program scope variable must reside in constant address space}}
-#elif (__OPENCL_C_VERSION__ == 300)
- #if !defined(__opencl_c_generic_address_space)
-// expected-error@-6 {{OpenCL C version 3.0 does not support the 'generic' type qualifier}}
- #endif
- #if !defined(__opencl_c_program_scope_global_variables)
-// expected-error@-9 {{program scope variable must reside in constant address space}}
- #endif
- #if defined(__opencl_c_generic_address_space) && defined(__opencl_c_program_scope_global_variables)
-// expected-error@-12 {{program scope variable must reside in global or constant address space}}
- #endif
+#elif (__OPENCL_CPP_VERSION__ == 202100 || __OPENCL_C_VERSION__ == 300)
+#if !defined(__opencl_c_generic_address_space)
+#if (__OPENCL_C_VERSION__ == 300)
+// expected-error@-7 {{OpenCL C version 3.0 does not support the 'generic' type qualifier}}
+#elif (__OPENCL_CPP_VERSION__ == 202100)
+// expected-error@-9 {{C++ for OpenCL version 2021 does not support the 'generic' type qualifier}}
+#endif
+#endif
+#if !defined(__opencl_c_program_scope_global_variables)
+// expected-error@-13 {{program scope variable must reside in constant address space}}
+#endif
+#if defined(__opencl_c_generic_address_space) && defined(__opencl_c_program_scope_global_variables)
+// expected-error@-16 {{program scope variable must reside in global or constant address space}}
+#endif
 #endif
 
 extern float g_implicit_extern_var;
@@ -85,32 +93,36 @@
 #endif
 
 extern generic float g_generic_extern_var;
-#if (__OPENCL_C_VERSION__ < 300)
+#if (defined(__OPENCL_C_VERSION__) && __OPENCL_C_VERSION__ < 300)
 // expected-error@-2 {{OpenCL C version 1.2 does not support the 'generic' type qualifier}}
 // expected-error@-3 {{extern variable must reside in constant address space}}
-#elif (__OPENCL_C_VERSION__ == 300)
- #if !defined(__opencl_c_generic_address_space)
-// expected-error@-6 {{OpenCL C version 3.0 does not support the 'generic' type qualifier}}
- #endif
- #if !defined(__opencl_c_program_scope_global_variables)
-// expected-error@-9 {{extern variable must reside in constant address space}}
- #endif
- #if defined(__opencl_c_generic_address_space) && defined(__opencl_c_program_scope_global_variables)
-// expected-error@-12 {{extern variable must reside in global or constant address space}}
- #endif
+#elif (__OPENCL_CPP_VERSION__ == 202100 || __OPENCL_C_VERSION__ == 300)
+#if !defined(__opencl_c_generic_address_space)
+#if (__OPENCL_C_VERSION__ == 300)
+// expected-error@-7 {{OpenCL C version 3.0 does not support the 'generic' type qualifier}}
+#elif (__OPENCL_CPP_VERSION__ == 202100)
+// expected-error@-9 {{C++ for OpenCL version 2021

[PATCH] D109306: [OpenCL] Supports optional pipe types in C++ for OpenCL 2021

2021-09-06 Thread Justas Janickas via Phabricator via cfe-commits

Topotuna created this revision.
Topotuna added a reviewer: Anastasia.
Herald added subscribers: ldrumm, yaxunl.
Topotuna requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Adds support for a feature macro `__opencl_c_pipes` in C++ for
OpenCL 2021 enabling a respective optional core feature from
OpenCL 3.0.

This change aims to achieve compatibility between C++ for OpenCL
2021 and OpenCL 3.0.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109306

Files:
  clang/lib/Basic/TargetInfo.cpp
  clang/test/CodeGenOpenCL/address-spaces-mangling.cl
  clang/test/CodeGenOpenCL/address-spaces.cl
  clang/test/CodeGenOpenCL/pipe_types.cl
  clang/test/CodeGenOpenCL/pipe_types_mangling.cl
  clang/test/Misc/opencl-c-3.0.incorrect_options.cl
  clang/test/SemaOpenCL/invalid-pipes-cl1.2.cl
  clang/test/SemaOpenCL/invalid-pipes-cl2.0.cl

Index: clang/test/SemaOpenCL/invalid-pipes-cl2.0.cl
===
--- clang/test/SemaOpenCL/invalid-pipes-cl2.0.cl
+++ clang/test/SemaOpenCL/invalid-pipes-cl2.0.cl
@@ -1,13 +1,15 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL2.0
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,+__opencl_c_program_scope_global_variables
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,-__opencl_c_program_scope_global_variables
-// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++1.0
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++2021 -cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,+__opencl_c_program_scope_global_variables
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++2021 -cl-ext=+__opencl_c_pipes,+__opencl_c_generic_address_space,-__opencl_c_program_scope_global_variables
 
 global pipe int gp;// expected-error {{type '__global read_only pipe int' can only be used as a function parameter in OpenCL}}
 global reserve_id_t rid;  // expected-error {{the '__global reserve_id_t' type cannot be used to declare a program scope variable}}
 
 extern pipe write_only int get_pipe(); // expected-error {{'write_only' attribute only applies to parameters and typedefs}}
-#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ == 200) || (__OPENCL_C_VERSION__ == 300 && defined(__opencl_c_program_scope_global_variables))
+#if (__OPENCL_CPP_VERSION__ == 100) || (__OPENCL_C_VERSION__ == 200) || ((__OPENCL_CPP_VERSION__ == 202100 || __OPENCL_C_VERSION__ == 300) && defined(__opencl_c_program_scope_global_variables))
 // expected-error-re@-2{{type '__global write_only pipe int ({{(void)?}})' can only be used as a function parameter in OpenCL}}
 #else
 // FIXME: '__private' here makes no sense since program scope variables feature is not supported, should diagnose as '__global' probably
Index: clang/test/SemaOpenCL/invalid-pipes-cl1.2.cl
===
--- clang/test/SemaOpenCL/invalid-pipes-cl1.2.cl
+++ clang/test/SemaOpenCL/invalid-pipes-cl1.2.cl
@@ -1,14 +1,18 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL1.2
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=-__opencl_c_pipes,-__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++2021 -cl-ext=-__opencl_c_pipes,-__opencl_c_generic_address_space
 
 void foo(read_only pipe int p);
 #if __OPENCL_C_VERSION__ > 120
 // expected-error@-2 {{OpenCL C version 3.0 does not support the 'pipe' type qualifier}}
 // expected-error@-3 {{access qualifier can only be used for pipe and image type}}
-#else
-// expected-warning@-5 {{type specifier missing, defaults to 'int'}}
+#elif defined(__OPENCL_CPP_VERSION__)
+// expected-error@-5 {{C++ for OpenCL version 2021 does not support the 'pipe' type qualifier}}
 // expected-error@-6 {{access qualifier can only be used for pipe and image type}}
-// expected-error@-7 {{expected ')'}} expected-note@-7 {{to match this '('}}
+#else
+// expected-warning@-8 {{type specifier missing, defaults to 'int'}}
+// expected-error@-9 {{access qualifier can only be used for pipe and image type}}
+// expected-error@-10 {{expected ')'}} expected-note@-10 {{to match this '('}}
 #endif
 
 // 'pipe' should be accepted as an identifier.
@@ -16,8 +20,16 @@
 #if __OPENCL_C_VERSION__ > 120
 // expected-error@-2 {{OpenCL C version 3.0 does not support the 'pipe' type qualifier}}
 // expected-warning@-3 {{typedef requires a name}}
+#elif defined(__OPENCL_CPP_VERSION__)
+// expected-error@-5 {{C++ for OpenCL version 2021 does not support the 'pipe' type qualifier}}
+// expected-warning@-6 {{typedef requires a name}}
 #endif
 
 void bar() {
- reserve_id_t r; // expected-e

[PATCH] D109307: [OpenCL] Supports optional same image reads and writes in C++ for OpenCL 2021

2021-09-06 Thread Justas Janickas via Phabricator via cfe-commits

Topotuna created this revision.
Topotuna added a reviewer: Anastasia.
Herald added subscribers: ldrumm, yaxunl.
Herald added a reviewer: aaron.ballman.
Topotuna requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Adds support for a feature macro `__opencl_c_read_write_images` in
C++ for OpenCL 2021 enabling a respective optional core feature
from OpenCL 3.0.

This change aims to achieve compatibility between C++ for OpenCL
2021 and OpenCL 3.0.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109307

Files:
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Misc/opencl-c-3.0.incorrect_options.cl
  clang/test/SemaOpenCL/access-qualifier.cl

Index: clang/test/SemaOpenCL/access-qualifier.cl
===
--- clang/test/SemaOpenCL/access-qualifier.cl
+++ clang/test/SemaOpenCL/access-qualifier.cl
@@ -2,24 +2,38 @@
 // RUN: %clang_cc1 -triple spir-unknown-unknown -verify -pedantic -fsyntax-only -cl-std=CL2.0 %s
 // RUN: %clang_cc1 -triple spir-unknown-unknown -verify -pedantic -fsyntax-only -cl-std=CL3.0 %s
 // RUN: %clang_cc1 -triple spir-unknown-unknown -verify -pedantic -fsyntax-only -cl-std=CL3.0 %s -cl-ext=-__opencl_c_read_write_images
+// RUN: %clang_cc1 -triple spir-unknown-unknown -verify -pedantic -fsyntax-only -cl-std=clc++2021 %s
+// RUN: %clang_cc1 -triple spir-unknown-unknown -verify -pedantic -fsyntax-only -cl-std=clc++2021 %s -cl-ext=-__opencl_c_read_write_images
 
 typedef image1d_t img1d_ro_default; // expected-note {{previously declared 'read_only' here}}
 
 typedef write_only image1d_t img1d_wo; // expected-note {{previously declared 'write_only' here}}
 typedef read_only image1d_t img1d_ro;
 
-#if (__OPENCL_C_VERSION__ == 200) || (__OPENCL_C_VERSION__ == 300 && defined(__opencl_c_read_write_images))
+#if (__OPENCL_C_VERSION__ == 200) || ((__OPENCL_CPP_VERSION__ == 202100 || __OPENCL_C_VERSION__ == 300) && defined(__opencl_c_read_write_images))
 typedef read_write image1d_t img1d_rw;
 #endif
 
 typedef int Int;
 typedef read_only int IntRO; // expected-error {{access qualifier can only be used for pipe and image type}}
 
+void myWrite(write_only image1d_t);
+#if !defined(__OPENCL_CPP_VERSION__)
+// expected-note@-2 {{passing argument to parameter here}}
+// expected-note@-3 {{passing argument to parameter here}}
+#else
+// expected-note@-5 {{candidate function not viable: no known conversion from '__private img1d_ro' (aka '__private __read_only image1d_t') to '__private __write_only image1d_t' for 1st argument}}
+// expected-note@-6 {{candidate function not viable: no known conversion from '__private img1d_ro_default' (aka '__private __read_only image1d_t') to '__private __write_only image1d_t' for 1st argument}}
+#endif
 
-void myWrite(write_only image1d_t); // expected-note {{passing argument to parameter here}} expected-note {{passing argument to parameter here}}
-void myRead(read_only image1d_t); // expected-note {{passing argument to parameter here}}
+void myRead(read_only image1d_t);
+#if !defined(__OPENCL_CPP_VERSION__)
+// expected-note@-2 {{passing argument to parameter here}}
+#else
+// expected-note@-4 {{candidate function not viable: no known conversion from '__private img1d_wo' (aka '__private __write_only image1d_t') to '__private __read_only image1d_t' for 1st argument}}
+#endif
 
-#if (__OPENCL_C_VERSION__ == 200) || (__OPENCL_C_VERSION__ == 300 && defined(__opencl_c_read_write_images))
+#if (__OPENCL_C_VERSION__ == 200) || ((__OPENCL_CPP_VERSION__ == 202100 || __OPENCL_C_VERSION__ == 300) && defined(__opencl_c_read_write_images))
 void myReadWrite(read_write image1d_t);
 #else
 void myReadWrite(read_write image1d_t); // expected-error {{access qualifier 'read_write' can not be used for '__read_write image1d_t' prior to OpenCL C version 2.0 or in version 3.0 and without __opencl_c_read_write_images feature}}
@@ -27,25 +41,40 @@
 
 
 kernel void k1(img1d_wo img) {
-  myRead(img); // expected-error {{passing '__private img1d_wo' (aka '__private __write_only image1d_t') to parameter of incompatible type '__read_only image1d_t'}}
+  myRead(img);
+#if !defined(__OPENCL_CPP_VERSION__)
+// expected-error@-2 {{passing '__private img1d_wo' (aka '__private __write_only image1d_t') to parameter of incompatible type '__read_only image1d_t'}}
+#else
+// expected-error@-4 {{no matching function for call to 'myRead'}}
+#endif
 }
 
 kernel void k2(img1d_ro img) {
-  myWrite(img); // expected-error {{passing '__private img1d_ro' (aka '__private __read_only image1d_t') to parameter of incompatible type '__write_only image1d_t'}}
+  myWrite(img);
+#if !defined(__OPENCL_CPP_VERSION__)
+// expected-error@-2 {{passing '__private img1d_ro' (aka '__private __read_only image1d_t') to parameter of incompatible type '__write_only image1d_t'}}
+#else
+// expected-error@-4 {{no matching function for call to 'myWrite'}}
+#endif
 }
 
 kernel void k3(img1d_wo img) {
   myWrite(img);
 }
 
-

[PATCH] D108461: [OpenCL] Supports optional generic address space sematics in C++ for OpenCL 2021

2021-09-06 Thread Justas Janickas via Phabricator via cfe-commits

Topotuna marked an inline comment as done.
Topotuna added inline comments.



Comment at: clang/lib/Basic/TargetInfo.cpp:413
   OpenCLFeaturesMap, "__opencl_c_generic_address_space");
-  Opts.OpenCLPipes =
-  hasFeatureEnabled(OpenCLFeaturesMap, "__opencl_c_pipes");
+  if (Opts.OpenCLVersion == 300)
+Opts.OpenCLPipes =

Anastasia wrote:
> Ok, I am guessing this will be changed back to one check later on?
Yes, the change that removes this check is already put for review: D109306


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108461/new/

https://reviews.llvm.org/D108461

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108366: [clang][deps] Make resource directory deduction configurable

2021-09-06 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 added a comment.

@dexonsmith I have incorporated your suggestions.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108366/new/

https://reviews.llvm.org/D108366

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109210: [clang-tidy] Attach fixit to warning, not note, in add_new_check.py example

2021-09-06 Thread Whisperity via Phabricator via cfe-commits

whisperity added a comment.

@mattbeardsley Thank you for the explanation. (I'd wager some of your 
observations could even be added to some developer docs that's versioned in the 
repo. 😉) I'm not opposed to the changes at all. And indeed, it looks like 
`Note`s are really an advanced feature. I'm incredibly biased because I just 
recently finished the development of a checker in which I extensively use notes 
(in some test cases, there were like 8 or 9 notes attached to a warning, albeit 
all without a `FixIt` attached).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109210/new/

https://reviews.llvm.org/D109210

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108556: [clangd] Don't highlight ObjC `id` and `instancetype`

2021-09-06 Thread Kadir Cetinkaya via Phabricator via cfe-commits

kadircet added a comment.

thanks, this looks great! just a question about the extra handling




Comment at: clang-tools-extra/clangd/FindTarget.cpp:100
+  // Even though ObjC `id` and `instancetype` are *implemented* via typedefs, 
we
+  // don't want to treat them like typedefs - instead let the editor treat
+  // them like keywords.

i think comment needs updating. rather than mentioning the editor, can we just 
talk about "these should be treated as keywords rather than decls" ?



Comment at: clang-tools-extra/clangd/FindTarget.cpp:188
 if (const TypedefNameDecl *TND = dyn_cast(D)) {
+  if (shouldSkipTypedef(TND))
+return;

why do we need this despite bailing out in the visitor?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108556/new/

https://reviews.llvm.org/D108556

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

2021-09-06 Thread Vassil Vassilev via Phabricator via cfe-commits

v.g.vassilev added subscribers: karies, Hahnfeld.
v.g.vassilev added a comment.

In D107049#2982224 , @thakis wrote:

> Thanks for fixing! Intel macs are happy now.
>
> But the test is still failing on arm macs: 
> http://45.33.8.238/macm1/17292/step_7.txt
>
>   FAIL: Clang-Unit :: 
> Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException
>  (28440 of 28440)
>    TEST 'Clang-Unit :: 
> Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests/InterpreterTest.CatchException'
>  FAILED 
>   Script:
>   --
>   
> /Users/thakis/src/llvm-project/out/gn/obj/clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests
>  --gtest_filter=InterpreterTest.CatchException
>   --
>   Note: Google Test filter = InterpreterTest.CatchException
>   [==] Running 1 test from 1 test suite.
>   [--] Global test environment set-up.
>   [--] 1 test from InterpreterTest
>   [ RUN  ] InterpreterTest.CatchException
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   libunwind: malformed __unwind_info at 0x192029E3C bad second level page
>   
>
> Please take a look.

It looks like we hit https://bugs.llvm.org/show_bug.cgi?id=49692

cc: @karies, @Hahnfeld


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] cc9260a - [OpenCL] Supports optional generic address space semantics in C++ for OpenCL 2021

2021-09-06 Thread Justas Janickas via cfe-commits


Author: Justas Janickas
Date: 2021-09-06T10:20:38+01:00
New Revision: cc9260a0fb7c42ac8a8bb87eac1e11900c25ed20

URL: 
https://github.com/llvm/llvm-project/commit/cc9260a0fb7c42ac8a8bb87eac1e11900c25ed20
DIFF: 
https://github.com/llvm/llvm-project/commit/cc9260a0fb7c42ac8a8bb87eac1e11900c25ed20.diff

LOG: [OpenCL] Supports optional generic address space semantics in C++ for 
OpenCL 2021

Adds support for a feature macro `__opencl_c_generic_adress_space`
in C++ for OpenCL 2021 enabling a respective optional core feature
from OpenCL 3.0. Testing is only performed in SemaOpenCL because
generic address space functionality is yet to be implemented in
C++ for OpenCL 2021.

This change aims to achieve compatibility between C++ for OpenCL
2021 and OpenCL 3.0.

Differential Revision: https://reviews.llvm.org/D108461

Added: 


Modified: 
clang/lib/Basic/TargetInfo.cpp
clang/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl
clang/test/SemaOpenCL/address-spaces.cl

Removed: 




diff  --git a/clang/lib/Basic/TargetInfo.cpp b/clang/lib/Basic/TargetInfo.cpp
index 5f8e04c2bd6c4..bc5f86a28d89d 100644
--- a/clang/lib/Basic/TargetInfo.cpp
+++ b/clang/lib/Basic/TargetInfo.cpp
@@ -406,12 +406,13 @@ void TargetInfo::adjust(DiagnosticsEngine &Diags, 
LangOptions &Opts) {
 // for OpenCL C 2.0 but with no access to target capabilities. Target
 // should be immutable once created and thus these language options need
 // to be defined only once.
-if (Opts.OpenCLVersion == 300) {
+if (Opts.getOpenCLCompatibleVersion() == 300) {
   const auto &OpenCLFeaturesMap = getSupportedOpenCLOpts();
   Opts.OpenCLGenericAddressSpace = hasFeatureEnabled(
   OpenCLFeaturesMap, "__opencl_c_generic_address_space");
-  Opts.OpenCLPipes =
-  hasFeatureEnabled(OpenCLFeaturesMap, "__opencl_c_pipes");
+  if (Opts.OpenCLVersion == 300)
+Opts.OpenCLPipes =
+hasFeatureEnabled(OpenCLFeaturesMap, "__opencl_c_pipes");
 }
   }
 

diff  --git a/clang/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl 
b/clang/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl
index 7531e742f0264..482254190789a 100644
--- a/clang/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl
+++ b/clang/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl
@@ -1,12 +1,15 @@
 // RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DCONSTANT -cl-std=CL2.0
 // RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGLOBAL -cl-std=CL2.0
 // RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGENERIC -cl-std=CL2.0
-// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DCONSTANT -cl-std=clc++
-// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGLOBAL -cl-std=clc++
-// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGENERIC -cl-std=clc++
+// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DCONSTANT -cl-std=clc++1.0
+// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGLOBAL -cl-std=clc++1.0
+// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGENERIC -cl-std=clc++1.0
 // RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DCONSTANT -cl-std=CL3.0 -cl-ext=+__opencl_c_generic_address_space
 // RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGLOBAL -cl-std=CL3.0 -cl-ext=+__opencl_c_generic_address_space
 // RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGENERIC -cl-std=CL3.0 -cl-ext=+__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DCONSTANT -cl-std=clc++2021 -cl-ext=+__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGLOBAL -cl-std=clc++2021 -cl-ext=+__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGENERIC -cl-std=clc++2021 -cl-ext=+__opencl_c_generic_address_space
 
 /* OpenCLC v2.0 adds a set of restrictions for conversions between pointers to
 *  
diff erent address spaces, mainly described in Sections 6.5.5 and 6.5.6.

diff  --git a/clang/test/SemaOpenCL/address-spaces.cl 
b/clang/test/SemaOpenCL/address-spaces.cl
index 61a1c8ec73ee3..21992d970560f 100644
--- a/clang/test/SemaOpenCL/address-spaces.cl
+++ b/clang/test/SemaOpenCL/address-spaces.cl
@@ -1,7 +1,8 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only
 // RUN: %clang_cc1 %s -cl-std=CL2.0 -verify -pedantic -fsyntax-only
 // RUN: %clang_cc1 %s -cl-std=CL3.0 -cl-ext=+__opencl_c_generic_address_space 
-verify -pedantic -fsyntax-only
-// RUN: %clang_cc1 %s -cl-std=clc++ -verify -pedantic -fsyntax-only
+// RUN: %clang_cc1 %s -cl-st

[PATCH] D108461: [OpenCL] Supports optional generic address space sematics in C++ for OpenCL 2021

2021-09-06 Thread Justas Janickas via Phabricator via cfe-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Topotuna marked an inline comment as done.
Closed by commit rGcc9260a0fb7c: [OpenCL] Supports optional generic address 
space semantics in C++ for OpenCL… (authored by Topotuna).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108461/new/

https://reviews.llvm.org/D108461

Files:
  clang/lib/Basic/TargetInfo.cpp
  clang/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl
  clang/test/SemaOpenCL/address-spaces.cl


Index: clang/test/SemaOpenCL/address-spaces.cl
===
--- clang/test/SemaOpenCL/address-spaces.cl
+++ clang/test/SemaOpenCL/address-spaces.cl
@@ -1,7 +1,8 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only
 // RUN: %clang_cc1 %s -cl-std=CL2.0 -verify -pedantic -fsyntax-only
 // RUN: %clang_cc1 %s -cl-std=CL3.0 -cl-ext=+__opencl_c_generic_address_space 
-verify -pedantic -fsyntax-only
-// RUN: %clang_cc1 %s -cl-std=clc++ -verify -pedantic -fsyntax-only
+// RUN: %clang_cc1 %s -cl-std=clc++1.0 -verify -pedantic -fsyntax-only
+// RUN: %clang_cc1 %s -cl-std=clc++2021 
-cl-ext=+__opencl_c_generic_address_space -verify -pedantic -fsyntax-only
 
 __constant int ci = 1;
 
Index: clang/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl
===
--- clang/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl
+++ clang/test/SemaOpenCL/address-spaces-conversions-cl2.0.cl
@@ -1,12 +1,15 @@
 // RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DCONSTANT -cl-std=CL2.0
 // RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGLOBAL -cl-std=CL2.0
 // RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGENERIC -cl-std=CL2.0
-// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DCONSTANT -cl-std=clc++
-// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGLOBAL -cl-std=clc++
-// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGENERIC -cl-std=clc++
+// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DCONSTANT -cl-std=clc++1.0
+// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGLOBAL -cl-std=clc++1.0
+// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGENERIC -cl-std=clc++1.0
 // RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DCONSTANT -cl-std=CL3.0 -cl-ext=+__opencl_c_generic_address_space
 // RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGLOBAL -cl-std=CL3.0 -cl-ext=+__opencl_c_generic_address_space
 // RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGENERIC -cl-std=CL3.0 -cl-ext=+__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DCONSTANT -cl-std=clc++2021 -cl-ext=+__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGLOBAL -cl-std=clc++2021 -cl-ext=+__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -ffake-address-space-map -verify -pedantic -fsyntax-only 
-DGENERIC -cl-std=clc++2021 -cl-ext=+__opencl_c_generic_address_space
 
 /* OpenCLC v2.0 adds a set of restrictions for conversions between pointers to
 *  different address spaces, mainly described in Sections 6.5.5 and 6.5.6.
Index: clang/lib/Basic/TargetInfo.cpp
===
--- clang/lib/Basic/TargetInfo.cpp
+++ clang/lib/Basic/TargetInfo.cpp
@@ -406,12 +406,13 @@
 // for OpenCL C 2.0 but with no access to target capabilities. Target
 // should be immutable once created and thus these language options need
 // to be defined only once.
-if (Opts.OpenCLVersion == 300) {
+if (Opts.getOpenCLCompatibleVersion() == 300) {
   const auto &OpenCLFeaturesMap = getSupportedOpenCLOpts();
   Opts.OpenCLGenericAddressSpace = hasFeatureEnabled(
   OpenCLFeaturesMap, "__opencl_c_generic_address_space");
-  Opts.OpenCLPipes =
-  hasFeatureEnabled(OpenCLFeaturesMap, "__opencl_c_pipes");
+  if (Opts.OpenCLVersion == 300)
+Opts.OpenCLPipes =
+hasFeatureEnabled(OpenCLFeaturesMap, "__opencl_c_pipes");
 }
   }
 


Index: clang/test/SemaOpenCL/address-spaces.cl
===
--- clang/test/SemaOpenCL/address-spaces.cl
+++ clang/test/SemaOpenCL/address-spaces.cl
@@ -1,7 +1,8 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only
 // RUN: %clang_cc1 %s -cl-std=CL2.0 -verify -pedantic -fsyntax-only
 // RUN: %clang_cc1 %s -cl-std=CL3.0 -cl-ext=+__opencl_c_generic_address_space -verify -pedantic -fsyntax-only
-// RUN: %clang_

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

2021-09-06 Thread Jonas Hahnfeld via Phabricator via cfe-commits

Hahnfeld added a comment.

In D107049#2984835 , @v.g.vassilev 
wrote:

> It looks like we hit https://bugs.llvm.org/show_bug.cgi?id=49692

I agree. Unfortunately, as described in the report, this is something that 
needs to be fixed on Apples side first.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 12fa608 - [X86] Add CRC32 feature.

2021-09-06 Thread Tianqing Wang via cfe-commits


Author: Tianqing Wang
Date: 2021-09-06T17:24:30+08:00
New Revision: 12fa608af44a80de8b655a8a984cd095908e7e80

URL: 
https://github.com/llvm/llvm-project/commit/12fa608af44a80de8b655a8a984cd095908e7e80
DIFF: 
https://github.com/llvm/llvm-project/commit/12fa608af44a80de8b655a8a984cd095908e7e80.diff

LOG: [X86] Add CRC32 feature.

d8faf03807ac implemented general-regs-only for X86 by disabling all features
with vector instructions. But the CRC32 instruction in SSE4.2 ISA, which uses
only GPRs, also becomes unavailable. This patch adds a CRC32 feature for this
instruction and allows it to be used with general-regs-only.

Reviewed By: pengfei

Differential Revision: https://reviews.llvm.org/D105462

Added: 
clang/lib/Headers/crc32intrin.h
clang/test/CodeGen/attr-target-crc32-x86.c
clang/test/Driver/x86-mcrc32.c
clang/test/Driver/x86-mgeneral-regs-only-crc32.c
llvm/test/CodeGen/X86/crc32-intrinsics-fast-isel-x86_64.ll
llvm/test/CodeGen/X86/crc32-intrinsics-x86.ll
llvm/test/CodeGen/X86/crc32-intrinsics-x86_64.ll
llvm/test/CodeGen/X86/crc32-target-feature.ll

Modified: 
clang/docs/ClangCommandLineReference.rst
clang/include/clang/Basic/BuiltinsX86.def
clang/include/clang/Basic/BuiltinsX86_64.def
clang/include/clang/Driver/Options.td
clang/lib/Basic/Targets/X86.cpp
clang/lib/Basic/Targets/X86.h
clang/lib/Headers/CMakeLists.txt
clang/lib/Headers/ia32intrin.h
clang/lib/Headers/smmintrin.h
clang/lib/Headers/x86gprintrin.h
clang/test/CodeGen/X86/x86-crc-builtins.c
clang/test/CodeGen/attr-cpuspecific.c
clang/test/CodeGen/attr-target-x86.c
clang/test/Driver/x86-target-features.c
clang/test/Preprocessor/x86_target_features.c
llvm/include/llvm/Support/X86TargetParser.def
llvm/lib/Support/Host.cpp
llvm/lib/Support/X86TargetParser.cpp
llvm/lib/Target/X86/X86.td
llvm/lib/Target/X86/X86InstrFormats.td
llvm/lib/Target/X86/X86InstrInfo.td
llvm/lib/Target/X86/X86InstrSSE.td
llvm/lib/Target/X86/X86Subtarget.h
llvm/test/CodeGen/X86/function-subtarget-features.ll
llvm/test/CodeGen/X86/sse42-intrinsics-fast-isel.ll
llvm/test/CodeGen/X86/sse42-intrinsics-x86.ll
llvm/test/CodeGen/X86/stack-folding-int-sse42.ll

Removed: 
llvm/test/CodeGen/X86/sse42-intrinsics-fast-isel-x86_64.ll
llvm/test/CodeGen/X86/sse42-intrinsics-x86_64.ll



diff  --git a/clang/docs/ClangCommandLineReference.rst 
b/clang/docs/ClangCommandLineReference.rst
index 48ae68fe089bf..a02c2bd772be4 100644
--- a/clang/docs/ClangCommandLineReference.rst
+++ b/clang/docs/ClangCommandLineReference.rst
@@ -3590,6 +3590,8 @@ X86
 
 .. option:: -mclzero, -mno-clzero
 
+.. option:: -mcrc32, -mno-crc32
+
 .. option:: -mcx16, -mno-cx16
 
 .. option:: -menqcmd, -mno-enqcmd

diff  --git a/clang/include/clang/Basic/BuiltinsX86.def 
b/clang/include/clang/Basic/BuiltinsX86.def
index 4bab7ca3010be..e0912fb99521e 100644
--- a/clang/include/clang/Basic/BuiltinsX86.def
+++ b/clang/include/clang/Basic/BuiltinsX86.def
@@ -421,9 +421,9 @@ TARGET_BUILTIN(__builtin_ia32_pcmpestrio128, 
"iV16ciV16ciIc","ncV:128:", "sse4.2
 TARGET_BUILTIN(__builtin_ia32_pcmpestris128, "iV16ciV16ciIc","ncV:128:", 
"sse4.2")
 TARGET_BUILTIN(__builtin_ia32_pcmpestriz128, "iV16ciV16ciIc","ncV:128:", 
"sse4.2")
 
-TARGET_BUILTIN(__builtin_ia32_crc32qi, "UiUiUc", "nc", "sse4.2")
-TARGET_BUILTIN(__builtin_ia32_crc32hi, "UiUiUs", "nc", "sse4.2")
-TARGET_BUILTIN(__builtin_ia32_crc32si, "UiUiUi", "nc", "sse4.2")
+TARGET_BUILTIN(__builtin_ia32_crc32qi, "UiUiUc", "nc", "crc32")
+TARGET_BUILTIN(__builtin_ia32_crc32hi, "UiUiUs", "nc", "crc32")
+TARGET_BUILTIN(__builtin_ia32_crc32si, "UiUiUi", "nc", "crc32")
 
 // SSE4a
 TARGET_BUILTIN(__builtin_ia32_extrqi, "V2OiV2OiIcIc", "ncV:128:", "sse4a")

diff  --git a/clang/include/clang/Basic/BuiltinsX86_64.def 
b/clang/include/clang/Basic/BuiltinsX86_64.def
index e0c9bec9b4e00..c3b9703a9cc67 100644
--- a/clang/include/clang/Basic/BuiltinsX86_64.def
+++ b/clang/include/clang/Basic/BuiltinsX86_64.def
@@ -44,7 +44,7 @@ TARGET_BUILTIN(__builtin_ia32_cvttsd2si64, "OiV2d", 
"ncV:128:", "sse2")
 TARGET_BUILTIN(__builtin_ia32_movnti64, "vOi*Oi", "n", "sse2")
 TARGET_BUILTIN(__builtin_ia32_vec_ext_v2di, "OiV2OiIi", "ncV:128:", "sse2")
 TARGET_BUILTIN(__builtin_ia32_vec_set_v2di, "V2OiV2OiOiIi", "ncV:128:", 
"sse4.1")
-TARGET_BUILTIN(__builtin_ia32_crc32di, "UOiUOiUOi", "nc", "sse4.2")
+TARGET_BUILTIN(__builtin_ia32_crc32di, "UOiUOiUOi", "nc", "crc32")
 TARGET_BUILTIN(__builtin_ia32_vec_ext_v4di, "OiV4OiIi", "ncV:256:", "avx")
 TARGET_BUILTIN(__builtin_ia32_vec_set_v4di, "V4OiV4OiOiIi", "ncV:256:", "avx")
 TARGET_BUILTIN(__builtin_ia32_rdfsbase32, "Ui", "n", "fsgsbase")

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index fa94c08c74e22..adac18b4404fd 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang

[PATCH] D105462: [X86] Add CRC32 feature.

2021-09-06 Thread Wang Tianqing via Phabricator via cfe-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
tianqing marked an inline comment as done.
Closed by commit rG12fa608af44a: [X86] Add CRC32 feature. (authored by 
tianqing).

Changed prior to commit:
  https://reviews.llvm.org/D105462?vs=368795&id=370866#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105462/new/

https://reviews.llvm.org/D105462

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Basic/BuiltinsX86.def
  clang/include/clang/Basic/BuiltinsX86_64.def
  clang/include/clang/Driver/Options.td
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Basic/Targets/X86.h
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/crc32intrin.h
  clang/lib/Headers/ia32intrin.h
  clang/lib/Headers/smmintrin.h
  clang/lib/Headers/x86gprintrin.h
  clang/test/CodeGen/X86/x86-crc-builtins.c
  clang/test/CodeGen/attr-cpuspecific.c
  clang/test/CodeGen/attr-target-crc32-x86.c
  clang/test/CodeGen/attr-target-x86.c
  clang/test/Driver/x86-mcrc32.c
  clang/test/Driver/x86-mgeneral-regs-only-crc32.c
  clang/test/Driver/x86-target-features.c
  clang/test/Preprocessor/x86_target_features.c
  llvm/include/llvm/Support/X86TargetParser.def
  llvm/lib/Support/Host.cpp
  llvm/lib/Support/X86TargetParser.cpp
  llvm/lib/Target/X86/X86.td
  llvm/lib/Target/X86/X86InstrFormats.td
  llvm/lib/Target/X86/X86InstrInfo.td
  llvm/lib/Target/X86/X86InstrSSE.td
  llvm/lib/Target/X86/X86Subtarget.h
  llvm/test/CodeGen/X86/crc32-intrinsics-fast-isel-x86_64.ll
  llvm/test/CodeGen/X86/crc32-intrinsics-x86.ll
  llvm/test/CodeGen/X86/crc32-intrinsics-x86_64.ll
  llvm/test/CodeGen/X86/crc32-target-feature.ll
  llvm/test/CodeGen/X86/function-subtarget-features.ll
  llvm/test/CodeGen/X86/sse42-intrinsics-fast-isel-x86_64.ll
  llvm/test/CodeGen/X86/sse42-intrinsics-fast-isel.ll
  llvm/test/CodeGen/X86/sse42-intrinsics-x86.ll
  llvm/test/CodeGen/X86/sse42-intrinsics-x86_64.ll
  llvm/test/CodeGen/X86/stack-folding-int-sse42.ll

Index: llvm/test/CodeGen/X86/stack-folding-int-sse42.ll
===
--- llvm/test/CodeGen/X86/stack-folding-int-sse42.ll
+++ llvm/test/CodeGen/X86/stack-folding-int-sse42.ll
@@ -1,5 +1,5 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
-; RUN: llc -O3 -disable-peephole -mtriple=x86_64-unknown-unknown -mattr=+sse4.2,+aes,+pclmul < %s | FileCheck %s
+; RUN: llc -O3 -disable-peephole -mtriple=x86_64-unknown-unknown -mattr=+sse4.2,+aes,+crc32,+pclmul < %s | FileCheck %s
 
 target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-unknown-unknown"
Index: llvm/test/CodeGen/X86/sse42-intrinsics-x86.ll
===
--- llvm/test/CodeGen/X86/sse42-intrinsics-x86.ll
+++ llvm/test/CodeGen/X86/sse42-intrinsics-x86.ll
@@ -1,10 +1,12 @@
 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
-; RUN: llc < %s -disable-peephole -mtriple=i386-apple-darwin -mattr=+sse4.2 -show-mc-encoding | FileCheck %s --check-prefixes=X86,SSE,X86-SSE
-; RUN: llc < %s -disable-peephole -mtriple=i386-apple-darwin -mattr=+avx -show-mc-encoding | FileCheck %s --check-prefixes=X86,AVX,X86-AVX,X86-AVX1
-; RUN: llc < %s -disable-peephole -mtriple=i386-apple-darwin -mattr=+avx512f,+avx512bw,+avx512dq,+avx512vl -show-mc-encoding | FileCheck %s --check-prefixes=X86,AVX,X86-AVX,X86-AVX512
-; RUN: llc < %s -disable-peephole -mtriple=x86_64-apple-darwin -mattr=+sse4.2 -show-mc-encoding | FileCheck %s --check-prefixes=X64,SSE,X64-SSE
-; RUN: llc < %s -disable-peephole -mtriple=x86_64-apple-darwin -mattr=+avx -show-mc-encoding | FileCheck %s --check-prefixes=X64,AVX,X64-AVX,X64-AVX1
-; RUN: llc < %s -disable-peephole -mtriple=x86_64-apple-darwin -mattr=+avx512f,+avx512bw,+avx512dq,+avx512vl -show-mc-encoding | FileCheck %s --check-prefixes=X64,AVX,X64-AVX,X64-AVX512
+; RUN: llc < %s -disable-peephole -mtriple=i386-apple-darwin -mattr=+sse4.2 -show-mc-encoding | FileCheck %s --check-prefixes=SSE,X86-SSE
+; RUN: llc < %s -disable-peephole -mtriple=i386-apple-darwin -mattr=+sse4.2,-crc32 -show-mc-encoding | FileCheck %s --check-prefixes=SSE,X86-SSE
+; RUN: llc < %s -disable-peephole -mtriple=i386-apple-darwin -mattr=+avx -show-mc-encoding | FileCheck %s --check-prefixes=AVX,X86-AVX,X86-AVX1
+; RUN: llc < %s -disable-peephole -mtriple=i386-apple-darwin -mattr=+avx512f,+avx512bw,+avx512dq,+avx512vl -show-mc-encoding | FileCheck %s --check-prefixes=AVX,X86-AVX,X86-AVX512
+; RUN: llc < %s -disable-peephole -mtriple=x86_64-apple-darwin -mattr=+sse4.2 -show-mc-encoding | FileCheck %s --check-prefixes=SSE,X64-SSE
+; RUN: llc < %s -disable-peephole -mtriple=x86_64-apple-darwin -mattr=+sse4.2,-crc32 -show-mc-encoding | FileCheck %s --check-prefixes=SSE,X64-SSE
+; RUN: llc < %s -disable-peephole -mtriple=x86_64-apple-darwin -mattr=+avx -show-mc-encod

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

2021-09-06 Thread Axel Naumann via Phabricator via cfe-commits

karies added inline comments.



Comment at: clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt:2
+# The interpreter can throw an exception from user input. The test binary needs
+# to be compiled with exception support to expect and catch the thrown
+# exception.

I don't understand the term "to expect" the thrown exception. Please ignore if 
that's a known term of art.



Comment at: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:93
+static void ThrowerAnError(const char* Name) {
+  throw std::runtime_error(Name);
+}

Why not just `throw Name;` to avoid `#include `?



Comment at: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:100
+  } catch (const std::exception& E) {
+printf("Caught: '%s'\n", E.what());
+  } catch (...) {

Consider fwd declaring `printf` to avoid inclusion of `stdio.h`.



Comment at: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:102
+  } catch (...) {
+printf("Unknown exception\n");
+  }

How is that provoking a test failure? What about `exit(1)` or whatever works 
for gtest?



Comment at: 
clang/unittests/Interpreter/ExceptionTests/InterpreterExceptionTest.cpp:104
+  }
+  ThrowerAnError("From JIT");
+  return 0;

To me, the wording difference between "In JIT" and "From JIT" doesn't signal 
anything. Maybe "the first could be "To be caught in JIT" and the second "To be 
caught in binary"?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107049/new/

https://reviews.llvm.org/D107049

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109002: [OpenCL] Supports optional image types in C++ for OpenCL 2021

2021-09-06 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109002/new/

https://reviews.llvm.org/D109002

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108765: [docs] Fix documentation of clang-format BasedOnStyle type

2021-09-06 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

Could you just rebase, I'm not getting a clean merge of 
ClangFormatStyleOptions.rst


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108765/new/

https://reviews.llvm.org/D108765

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] fae0dfa - [Clang] Add __ibm128 type to represent ppc_fp128

2021-09-06 Thread Qiu Chaofan via cfe-commits


Author: Qiu Chaofan
Date: 2021-09-06T18:00:58+08:00
New Revision: fae0dfa6421ea6c02f86ba7292fa782e1e2b69d1

URL: 
https://github.com/llvm/llvm-project/commit/fae0dfa6421ea6c02f86ba7292fa782e1e2b69d1
DIFF: 
https://github.com/llvm/llvm-project/commit/fae0dfa6421ea6c02f86ba7292fa782e1e2b69d1.diff

LOG: [Clang] Add __ibm128 type to represent ppc_fp128

Currently, we have no front-end type for ppc_fp128 type in IR. PowerPC
target generates ppc_fp128 type from long double now, but there's option
(-mabi=(ieee|ibm)longdouble) to control it and we're going to do
transition from IBM extended double-double ppc_fp128 to IEEE fp128 in
the future.

This patch adds type __ibm128 which always represents ppc_fp128 in IR,
as what GCC did for that type. Without this type in Clang, compilation
will fail if compiling against future version of libstdcxx (which uses
__ibm128 in headers).

Although all operations in backend for __ibm128 is done by software,
only PowerPC enables support for it.

There's something not implemented in this commit, which can be done in
future ones:

- Literal suffix for __ibm128 type. w/W is suitable as GCC documented.
- __attribute__((mode(IF))) should be for __ibm128.
- Complex __ibm128 type.

Reviewed By: rjmccall

Differential Revision: https://reviews.llvm.org/D93377

Added: 
clang/test/CodeGen/ibm128-cast.c
clang/test/CodeGen/ibm128-unsupported.c
clang/test/CodeGenCXX/ibm128-declarations.cpp

Modified: 
clang/bindings/python/clang/cindex.py
clang/include/clang-c/Index.h
clang/include/clang/AST/ASTContext.h
clang/include/clang/AST/BuiltinTypes.def
clang/include/clang/AST/Type.h
clang/include/clang/AST/TypeLoc.h
clang/include/clang/Basic/Specifiers.h
clang/include/clang/Basic/TargetInfo.h
clang/include/clang/Basic/TokenKinds.def
clang/include/clang/Sema/DeclSpec.h
clang/include/clang/Serialization/ASTBitCodes.h
clang/lib/AST/ASTContext.cpp
clang/lib/AST/ItaniumMangle.cpp
clang/lib/AST/MicrosoftMangle.cpp
clang/lib/AST/NSAPI.cpp
clang/lib/AST/PrintfFormatString.cpp
clang/lib/AST/StmtPrinter.cpp
clang/lib/AST/Type.cpp
clang/lib/AST/TypeLoc.cpp
clang/lib/Basic/TargetInfo.cpp
clang/lib/Basic/Targets/PPC.h
clang/lib/CodeGen/CGDebugInfo.cpp
clang/lib/CodeGen/CGExprScalar.cpp
clang/lib/CodeGen/CodeGenTypes.cpp
clang/lib/CodeGen/ItaniumCXXABI.cpp
clang/lib/CodeGen/TargetInfo.cpp
clang/lib/Format/FormatToken.cpp
clang/lib/Index/USRGeneration.cpp
clang/lib/Parse/ParseDecl.cpp
clang/lib/Parse/ParseExpr.cpp
clang/lib/Parse/ParseExprCXX.cpp
clang/lib/Parse/ParseTentative.cpp
clang/lib/Sema/DeclSpec.cpp
clang/lib/Sema/Sema.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaExpr.cpp
clang/lib/Sema/SemaOverload.cpp
clang/lib/Sema/SemaTemplateVariadic.cpp
clang/lib/Sema/SemaType.cpp
clang/lib/Serialization/ASTCommon.cpp
clang/lib/Serialization/ASTReader.cpp
clang/test/Sema/128bitfloat.cpp
clang/tools/libclang/CXType.cpp

Removed: 




diff  --git a/clang/bindings/python/clang/cindex.py 
b/clang/bindings/python/clang/cindex.py
index aceaa131f1555..44bfba494df21 100644
--- a/clang/bindings/python/clang/cindex.py
+++ b/clang/bindings/python/clang/cindex.py
@@ -2059,6 +2059,7 @@ def __repr__(self):
 TypeKind.OBJCSEL = TypeKind(29)
 TypeKind.FLOAT128 = TypeKind(30)
 TypeKind.HALF = TypeKind(31)
+TypeKind.IBM128 = TypeKind(40)
 TypeKind.COMPLEX = TypeKind(100)
 TypeKind.POINTER = TypeKind(101)
 TypeKind.BLOCKPOINTER = TypeKind(102)

diff  --git a/clang/include/clang-c/Index.h b/clang/include/clang-c/Index.h
index 26844d1c74f39..8afd4c9ff1d05 100644
--- a/clang/include/clang-c/Index.h
+++ b/clang/include/clang-c/Index.h
@@ -3298,8 +3298,9 @@ enum CXTypeKind {
   CXType_UAccum = 37,
   CXType_ULongAccum = 38,
   CXType_BFloat16 = 39,
+  CXType_Ibm128 = 40,
   CXType_FirstBuiltin = CXType_Void,
-  CXType_LastBuiltin = CXType_BFloat16,
+  CXType_LastBuiltin = CXType_Ibm128,
 
   CXType_Complex = 100,
   CXType_Pointer = 101,

diff  --git a/clang/include/clang/AST/ASTContext.h 
b/clang/include/clang/AST/ASTContext.h
index 5004cb6cb2671..b8f7c3aae2608 100644
--- a/clang/include/clang/AST/ASTContext.h
+++ b/clang/include/clang/AST/ASTContext.h
@@ -1076,7 +1076,7 @@ class ASTContext : public RefCountedBase {
   CanQualType SignedCharTy, ShortTy, IntTy, LongTy, LongLongTy, Int128Ty;
   CanQualType UnsignedCharTy, UnsignedShortTy, UnsignedIntTy, UnsignedLongTy;
   CanQualType UnsignedLongLongTy, UnsignedInt128Ty;
-  CanQualType FloatTy, DoubleTy, LongDoubleTy, Float128Ty;
+  CanQualType FloatTy, DoubleTy, LongDoubleTy, Float128Ty, Ibm128Ty;
   CanQualType ShortAccumTy, AccumTy,
   LongAccumTy;  // ISO/IEC JTC1 SC22 WG14 N1169 Extension
   CanQualType UnsignedShortAccumTy, UnsignedAccumTy, UnsignedLongAccumTy;

diff  --git a/clang/include/clang/AST/BuiltinTypes.

[PATCH] D93377: [Clang] Add __ibm128 type to represent ppc_fp128

2021-09-06 Thread Qiu Chaofan via Phabricator via cfe-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGfae0dfa6421e: [Clang] Add __ibm128 type to represent 
ppc_fp128 (authored by qiucf).

Changed prior to commit:
  https://reviews.llvm.org/D93377?vs=369045&id=370878#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93377/new/

https://reviews.llvm.org/D93377

Files:
  clang/bindings/python/clang/cindex.py
  clang/include/clang-c/Index.h
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/BuiltinTypes.def
  clang/include/clang/AST/Type.h
  clang/include/clang/AST/TypeLoc.h
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/AST/NSAPI.cpp
  clang/lib/AST/PrintfFormatString.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/PPC.h
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Format/FormatToken.cpp
  clang/lib/Index/USRGeneration.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Parse/ParseTentative.cpp
  clang/lib/Sema/DeclSpec.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplateVariadic.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/test/CodeGen/ibm128-cast.c
  clang/test/CodeGen/ibm128-unsupported.c
  clang/test/CodeGenCXX/ibm128-declarations.cpp
  clang/test/Sema/128bitfloat.cpp
  clang/tools/libclang/CXType.cpp

Index: clang/tools/libclang/CXType.cpp
===
--- clang/tools/libclang/CXType.cpp
+++ clang/tools/libclang/CXType.cpp
@@ -60,6 +60,7 @@
 BTCASE(ULongAccum);
 BTCASE(Float16);
 BTCASE(Float128);
+BTCASE(Ibm128);
 BTCASE(NullPtr);
 BTCASE(Overload);
 BTCASE(Dependent);
@@ -577,6 +578,7 @@
 TKIND(ULongAccum);
 TKIND(Float16);
 TKIND(Float128);
+TKIND(Ibm128);
 TKIND(NullPtr);
 TKIND(Overload);
 TKIND(Dependent);
Index: clang/test/Sema/128bitfloat.cpp
===
--- clang/test/Sema/128bitfloat.cpp
+++ clang/test/Sema/128bitfloat.cpp
@@ -20,7 +20,7 @@
   return x + *y;
 }
 
-// expected-no-diagnostics
+// expected-no-error {{__float128 is not supported on this target}}
 #else
 #if !defined(__STRICT_ANSI__)
 __float128 f;  // expected-error {{__float128 is not supported on this target}}
@@ -44,3 +44,18 @@
 
 #endif
 #endif
+
+#ifdef __ppc__
+__ibm128 i;
+template <> struct __is_floating_point_helper<__ibm128> {};
+int w(int x, __ibm128 *y) {
+  return x + *y;
+}
+// expected-no-error {{__ibm128 is not supported on this target}}
+#else
+__ibm128 i; // expected-error {{__ibm128 is not supported on this target}}
+template <> struct __is_floating_point_helper<__ibm128> {}; // expected-error {{__ibm128 is not supported on this target}}
+int w(int x, __ibm128 *y) { // expected-error {{__ibm128 is not supported on this target}}
+  return x + *y;
+}
+#endif
Index: clang/test/CodeGenCXX/ibm128-declarations.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/ibm128-declarations.cpp
@@ -0,0 +1,169 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
+// RUN: %clang_cc1 -emit-llvm -triple powerpc64-unknown-unknown \
+// RUN:   -std=c++20 %s -o - -debug-info-kind=limited | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -triple powerpc64le-unknown-unknown \
+// RUN:   -std=c++20 %s -o - -debug-info-kind=limited | FileCheck %s
+
+#include 
+
+static __ibm128 sgf;
+__ibm128 arrgf[10];
+__ibm128 func1(__ibm128 arg);
+
+class CTest {
+  __ibm128 pf;
+  static const __ibm128 scf;
+  volatile __ibm128 vf;
+
+public:
+  CTest(__ibm128 arg) : pf(arg), vf(arg) {}
+  __ibm128 func2(__ibm128 arg) {
+return pf + arg;
+  }
+  static __ibm128 func3(__ibm128 arg) {
+return arg * CTest::scf;
+  }
+};
+
+constexpr __ibm128 func_add(__ibm128 a, __ibm128 b) {
+  return a + b;
+}
+
+constinit const __ibm128 ci = func_add(1.0, 2.0);
+__ibm128 gf = ci;
+
+__ibm128 func_arith(__ibm128 a, __ibm128 b, __ibm128 c) {
+  __ibm128 v1 = a + b;
+  __ibm128 v2 = a - c;
+  __ibm128 v3 = v1 * c;
+  __ibm128 v4 = v2 / v3;
+  return v4;
+}
+
+__ibm128 func_va

[PATCH] D109150: [OpenCL] Disallows static kernel functions in C++ for OpenCL

2021-09-06 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:9972
 // OpenCL v1.2 s6.8 static is invalid for kernel functions.
-if ((getLangOpts().OpenCLVersion >= 120)
-&& (SC == SC_Static)) {
+if ((getLangOpts().getOpenCLCompatibleVersion() >= 120) &&
+(SC == SC_Static)) {

I wonder though if we should just drop a version check here completely.

I don't think we can allow this in the earlier OpenCL versions. The reason why 
it doesn't apply to earlier versions is that `static`/`extern` wasn't allowed 
at all so presumably frontend would reject such a case earlier.

I think the extra check is not doing anything useful here, but only adds extra 
code to read and maintain.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109150/new/

https://reviews.llvm.org/D109150

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108320: Add semantic token modifier for non-const reference parameter

2021-09-06 Thread Sam McCall via Phabricator via cfe-commits

sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Thanks! This looks good to me to land as is.
I'd like to see the std::map eliminated, but if you don't want to do this I'm 
happy to take a stab at it after.

Want someone to commit this for you?




Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:470
   std::vector Tokens;
+  std::map> ExtraModifiers;
   const HeuristicResolver *Resolver;

tom-anders wrote:
> nridge wrote:
> > Looking at existing usage of associative containers in clangd code, 
> > `llvm::DenseMap` and `llvm::DenseSet` (which are hashtable-based) are more 
> > commonly used than `std::map` and `std::set`, though it may require some 
> > boilerplate to teach them to use new key types 
> > ([example](https://searchfox.org/llvm/rev/2556f58148836f0af3ad2c73fe54bbdf49f0295a/clang-tools-extra/clangd/index/dex/Token.h#117))
> > 
> > We could also consider making the value just a vector instead of a set 
> > (maybe even an `llvm::SmallVector` given its 
> > anticipated usage), since even in the unlikely case that we get duplicates, 
> > `addModifier()` will handle them correctly
> Agreed, changed std::set to llvm::SmallVector. I can't really judge if it's 
> worth using llvm::DenseMap here though.
We do try to avoid std::map/std::set as they're pretty gratuitous performance 
sinks. And the map here may not be tiny.

I'd suggest either:
 - make this a flat `vector>`, sort it 
after building, and use binary search to find the right place. This has the 
same big-O as std::map but without all the allocations and pointer chasing
 - Specializing DenseMapInfo in protocol.h and using 
DenseMap>

We don't really need the full Range in the key, as the start defines it.

> We could also consider making the value just a vector instead of a set

In practice these sets of modifiers end up being a bitmask, so if using a map, 
you could just store a uint32_t of `1

[PATCH] D109305: [OpenCL] Supports optional program scope global variables in C++ for OpenCL 2021

2021-09-06 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109305/new/

https://reviews.llvm.org/D109305

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109306: [OpenCL] Supports optional pipe types in C++ for OpenCL 2021

2021-09-06 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109306/new/

https://reviews.llvm.org/D109306

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109265: [X86][mingw] Modify the alignment of m128/m256/__m512 vector type for mingw

2021-09-06 Thread Martin Storsjö via Phabricator via cfe-commits

mstorsjo accepted this revision.
mstorsjo added a comment.
This revision is now accepted and ready to land.

Thanks, this does seem to do the right thing in the testcase you provided.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109265/new/

https://reviews.llvm.org/D109265

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109307: [OpenCL] Supports optional same image reads and writes in C++ for OpenCL 2021

2021-09-06 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109307/new/

https://reviews.llvm.org/D109307

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108765: [docs] Fix documentation of clang-format BasedOnStyle type

2021-09-06 Thread Ludovic Jozeau via Phabricator via cfe-commits

FederAndInk updated this revision to Diff 370883.
FederAndInk added a comment.

rebase main


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108765/new/

https://reviews.llvm.org/D108765

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/tools/dump_format_style.py
  clang/docs/tools/plurals.txt

Index: clang/docs/tools/plurals.txt
===
--- /dev/null
+++ clang/docs/tools/plurals.txt
@@ -0,0 +1,3 @@
+Strings
+IncludeCategories
+RawStringFormats
Index: clang/docs/tools/dump_format_style.py
===
--- clang/docs/tools/dump_format_style.py
+++ clang/docs/tools/dump_format_style.py
@@ -1,23 +1,73 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
 # A tool to parse the FormatStyle struct from Format.h and update the
 # documentation in ../ClangFormatStyleOptions.rst automatically.
 # Run from the directory in which this file is located to update the docs.
 
-import collections
+import inspect
 import os
 import re
+from typing import Set
 
 CLANG_DIR = os.path.join(os.path.dirname(__file__), '../..')
 FORMAT_STYLE_FILE = os.path.join(CLANG_DIR, 'include/clang/Format/Format.h')
 INCLUDE_STYLE_FILE = os.path.join(CLANG_DIR, 'include/clang/Tooling/Inclusions/IncludeStyle.h')
 DOC_FILE = os.path.join(CLANG_DIR, 'docs/ClangFormatStyleOptions.rst')
 
+PLURALS_FILE = os.path.join(os.path.dirname(__file__), 'plurals.txt')
+print(f'generated plurals (for yaml type) are stored in {PLURALS_FILE}')
+print('you can use `git checkout -- plurals.txt` to reemit warnings or `git add`\n')
+plurals: Set[str] = set()
+with open(PLURALS_FILE, 'a+') as f:
+  f.seek(0)
+  plurals = set(f.read().splitlines())
 
 def substitute(text, tag, contents):
   replacement = '\n.. START_%s\n\n%s\n\n.. END_%s\n' % (tag, contents, tag)
   pattern = r'\n\.\. START_%s\n.*\n\.\. END_%s\n' % (tag, tag)
   return re.sub(pattern, '%s', text, flags=re.S) % replacement
 
+def register_plural(singular: str, plural: str):
+  if plural not in plurals:
+plurals.add(plural)
+with open(PLURALS_FILE, 'a') as f:
+  f.write(plural + '\n')
+cf = inspect.currentframe()
+lineno = ''
+if cf and cf.f_back:
+  lineno = ':' + str(cf.f_back.f_lineno)
+print(f'{__file__}{lineno} check if plural of {singular} is {plural}', file=os.sys.stderr)
+  return plural
+
+def pluralize(word: str):
+  lword = word.lower()
+  if len(lword) >= 2 and lword[-1] == 'y' and lword[-2] not in 'aeiou':
+return register_plural(word, word[:-1] + 'ies')
+  elif lword.endswith(('s', 'sh', 'ch', 'x', 'z')):
+return register_plural(word, word[:-1] + 'es')
+  elif lword.endswith('fe'):
+return register_plural(word, word[:-2] + 'ves')
+  elif lword.endswith('f') and not lword.endswith('ff'):
+return register_plural(word, word[:-1] + 'ves')
+  else:
+return register_plural(word, word + 's')
+
+
+def to_yaml_type(typestr: str):
+  if typestr == 'bool':
+return 'Boolean'
+  elif typestr == 'int':
+return 'Integer'
+  elif typestr == 'unsigned':
+return 'Unsigned'
+  elif typestr == 'std::string':
+return 'String'
+
+  subtype, napplied = re.subn(r'^std::vector<(.*)>$', r'\1', typestr)
+  if napplied == 1:
+return 'List of ' + pluralize(to_yaml_type(subtype))
+
+  return typestr
+
 def doxygen2rst(text):
   text = re.sub(r'\s*(.*?)\s*<\/tt>', r'``\1``', text)
   text = re.sub(r'\\c ([^ ,;\.]+)', r'``\1``', text)
@@ -40,7 +90,7 @@
 self.nested_struct = None
 
   def __str__(self):
-s = '**%s** (``%s``)\n%s' % (self.name, self.type,
+s = '**%s** (``%s``)\n%s' % (self.name, to_yaml_type(self.type),
  doxygen2rst(indent(self.comment, 2)))
 if self.enum and self.enum.values:
   s += indent('\n\nPossible values:\n\n%s\n' % self.enum, 2)
@@ -85,7 +135,7 @@
 self.type = enumtype
 
   def __str__(self):
-s = '\n* ``%s %s``\n%s' % (self.type, self.name,
+s = '\n* ``%s %s``\n%s' % (to_yaml_type(self.type), self.name,
  doxygen2rst(indent(self.comment, 2)))
 s += indent('\nPossible values:\n\n', 2)
 s += indent('\n'.join(map(str, self.values)),2)
Index: clang/docs/ClangFormatStyleOptions.rst
===
--- clang/docs/ClangFormatStyleOptions.rst
+++ clang/docs/ClangFormatStyleOptions.rst
@@ -125,7 +125,7 @@
 the configuration (without a prefix: ``Auto``).
 
 
-**BasedOnStyle** (``string``)
+**BasedOnStyle** (``String``)
   The style used for all options not specifically set in the configuration.
 
   This option is supported only in the :program:`clang-format` configuration
@@ -166,7 +166,7 @@
 
 .. START_FORMAT_STYLE_OPTIONS
 
-**AccessModifierOffset** (``int``)
+**AccessModifierOffset** (``Integer``)
   The extra indent or outdent of access modifiers, e.g. ``public:``.
 
 **AlignAfterOpenBracket** (``BracketAli

[PATCH] D109315: [clang] Check unsupported types in expressions

2021-09-06 Thread Andrew Savonichev via Phabricator via cfe-commits

asavonic created this revision.
asavonic added reviewers: erichkeane, Fznamznon.
asavonic requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

The patch adds diagnostics for cases like:

  float F3 = ((__float128)F1 * (__float128)F2) / 2.0f;

Sema::checkDeviceDecl (renamed to checkTypeSupport) is changed to work
with a type without the corresponding ValueDecl. It is also refactored
so that host diagnostics for unsupported types can be added here as
well.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109315

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/OpenMP/nvptx_unsupported_type_messages.cpp
  clang/test/SemaSYCL/float128.cpp
  clang/test/SemaSYCL/int128.cpp

Index: clang/test/SemaSYCL/int128.cpp
===
--- clang/test/SemaSYCL/int128.cpp
+++ clang/test/SemaSYCL/int128.cpp
@@ -26,19 +26,18 @@
   // expected-note@+1 3{{'A' defined here}}
   __int128 A;
   Z<__int128> C;
-  // expected-error@+2 {{'A' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
-  // expected-error@+1 {{'field1' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+  // expected-error@+1 4{{128 bit size '__int128' type is not supported for target 'spir64'}}
   C.field1 = A;
-  // expected-error@+1 {{'bigfield' requires 128 bit size 'Z::BIGTYPE' (aka '__int128') type support, but device 'spir64' does not support it}}
+  // expected-error@+1 2{{128 bit size 'Z::BIGTYPE' (aka '__int128') type is not supported for target 'spir64'}}
   C.bigfield += 1.0;
 
-  // expected-error@+1 {{'A' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+  // expected-error@+1 {{128 bit size '__int128' type is not supported for target 'spir64'}}
   auto foo1 = [=]() {
 __int128 AA;
 // expected-note@+2 {{'BB' defined here}}
-// expected-error@+1 {{'A' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+// expected-error@+1 {{128 bit size '__int128' type is not supported for target 'spir64'}}
 auto BB = A;
-// expected-error@+1 {{'BB' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+// expected-error@+1 2{{128 bit size '__int128' type is not supported for target 'spir64'}}
 BB += 1;
   };
 
@@ -50,7 +49,7 @@
 void foo2(){};
 
 // expected-note@+3 {{'P' defined here}}
-// expected-error@+2 {{'P' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+// expected-error@+2 {{128 bit size '__int128' type is not supported for target 'spir64'}}
 // expected-note@+1 2{{'foo' defined here}}
 __int128 foo(__int128 P) { return P; }
 
@@ -58,7 +57,7 @@
   // expected-note@+1 {{'operator __int128' defined here}}
   struct X { operator  __int128() const; } x;
   bool a = false;
-  // expected-error@+1 {{'operator __int128' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+  // expected-error@+1 3{{128 bit size '__int128' type is not supported for target 'spir64'}}
   a = x == __int128(0);
 }
 
@@ -74,12 +73,12 @@
   host_ok();
   kernel([=]() {
 decltype(CapturedToDevice) D;
-// expected-error@+1 {{'CapturedToDevice' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+// expected-error@+1 {{128 bit size '__int128' type is not supported for target 'spir64'}}
 auto C = CapturedToDevice;
 Z<__int128> S;
-// expected-error@+1 {{'field1' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+// expected-error@+1 2{{128 bit size '__int128' type is not supported for target 'spir64'}}
 S.field1 += 1;
-// expected-error@+1 {{'field' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+// expected-error@+1 2{{128 bit size '__int128' type is not supported for target 'spir64'}}
 S.field = 1;
   });
 
@@ -88,8 +87,8 @@
 usage();
 // expected-note@+1 {{'' defined here}}
 BIGTY ;
-// expected-error@+3 {{'' requires 128 bit size 'BIGTY' (aka 'unsigned __int128') type support, but device 'spir64' does not support it}}
-// expected-error@+2 2{{'foo' requires 128 bit size '__int128' type support, but device 'spir64' does not support it}}
+// expected-error@+3 2{{128 bit size '__int128' type is not supported for target 'spir64'}}
+// expected-error@+2 1{{128 bit size 'BIGTY' (aka 'unsigned __int128') type is not supported for target 'spir64'}}
 // expected-note@+1 1{{called by 'operator()'}}
 auto A = foo();
 // expected-note@+1 {{called by 'operator()'}}
Index: clang/test

[PATCH] D109157: [ARM] Mitigate the cve-2021-35465 security vulnurability.

2021-09-06 Thread Oliver Stannard (Linaro) via Phabricator via cfe-commits

ostannard added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:1665
+
+CmdArgs.push_back("-mllvm");
+if (A->getOption().matches(options::OPT_mfix_cmse_cve_2021_35465))

Are these optional also being passed through to the linker when doing LTO?



Comment at: clang/test/Driver/arm-cmse-cve-2021-35465.c:3
+//
+// RUN: %clang --target=arm-arm-none-eabi -march=armv8-m.main %s -### \
+// RUN:   -mcmse -mno-fix-cmse-cve-2021-35465 2>&1 |\

The last few paragraphs of 
https://developer.arm.com/support/arm-security-updates/vlldm-instruction-security-vulnerability
 claim that this is enabled by default for -march=armv8-m.main in AC6 and GCC, 
is there a reason we're not matching that?



Comment at: llvm/lib/Target/ARM/ARMExpandPseudoInsts.cpp:1564
   .addReg(Reg)
+  .addReg(ARM::CPSR, RegState::ImplicitDefine)
   .add(predOps(ARMCC::AL));

Why are these needed?



Comment at: llvm/lib/Target/ARM/ARMExpandPseudoInsts.cpp:1626
+  // Thumb2ITBlockPass will not recognise the instruction as conditional.
+  BuildMI(MBB, MBBI, DL, TII->get(ARM::t2IT))
+  .addImm(ARMCC::NE)

This pass runs before the final scheduler pass, so is there a risk that the IT 
and VMOV instructions could be moved apart? I think it would be safer to either 
put the IT instruction inside the inline asm block, or make this a new 
pseudo-instruction expanded in the asm printer.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109157/new/

https://reviews.llvm.org/D109157

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98895: [X86][Draft] Disable long double type for -mno-x87 option

2021-09-06 Thread Andrew Savonichev via Phabricator via cfe-commits

asavonic added a comment.

Thanks @erichkeane. SPIR-V diagnostics seem to work fine. There are a few cases 
that are not handled, so I submitted D109315  
to review them separately.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98895/new/

https://reviews.llvm.org/D98895

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109265: [X86][mingw] Modify the alignment of m128/m256/__m512 vector type for mingw

2021-09-06 Thread Pengfei Wang via Phabricator via cfe-commits

pengfei added a comment.

Thanks Martin!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109265/new/

https://reviews.llvm.org/D109265

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109150: [OpenCL] Disallows static kernel functions in C++ for OpenCL

2021-09-06 Thread Justas Janickas via Phabricator via cfe-commits

Topotuna added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:9972
 // OpenCL v1.2 s6.8 static is invalid for kernel functions.
-if ((getLangOpts().OpenCLVersion >= 120)
-&& (SC == SC_Static)) {
+if ((getLangOpts().getOpenCLCompatibleVersion() >= 120) &&
+(SC == SC_Static)) {

Anastasia wrote:
> I wonder though if we should just drop a version check here completely.
> 
> I don't think we can allow this in the earlier OpenCL versions. The reason 
> why it doesn't apply to earlier versions is that `static`/`extern` wasn't 
> allowed at all so presumably frontend would reject such a case earlier.
> 
> I think the extra check is not doing anything useful here, but only adds 
> extra code to read and maintain.
That is correct. If `static` or `extern` is used in OpenCL C 1.0, diagnostic 
`err_opencl_unknown_type_specifier` is displayed before control flow reaches 
this part of code. And so removing the check here doesn't seem to change the 
compiler behaviour.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109150/new/

https://reviews.llvm.org/D109150

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109150: [OpenCL] Disallows static kernel functions in C++ for OpenCL

2021-09-06 Thread Justas Janickas via Phabricator via cfe-commits

Topotuna updated this revision to Diff 370895.
Topotuna added a comment.

Condition on OpenCL C / C++ for OpenCL version removed because it was redundant.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109150/new/

https://reviews.llvm.org/D109150

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaOpenCL/storageclass-cl20.cl


Index: clang/test/SemaOpenCL/storageclass-cl20.cl
===
--- clang/test/SemaOpenCL/storageclass-cl20.cl
+++ clang/test/SemaOpenCL/storageclass-cl20.cl
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL2.0
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++1.0
 
 int G2 = 0;
 global int G3 = 0;
@@ -18,6 +19,9 @@
 extern private float g_private_extern_var; // expected-error {{extern variable 
must reside in global or constant address space}}
 extern generic float g_generic_extern_var; // expected-error {{extern variable 
must reside in global or constant address space}}
 
+static void kernel bar() { // expected-error{{kernel functions cannot be 
declared static}}
+}
+
 void kernel foo() {
   constant int L1 = 0;
   local int L2;
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -9969,8 +9969,7 @@
 
   if (getLangOpts().OpenCL && NewFD->hasAttr()) {
 // OpenCL v1.2 s6.8 static is invalid for kernel functions.
-if ((getLangOpts().OpenCLVersion >= 120)
-&& (SC == SC_Static)) {
+if (SC == SC_Static) {
   Diag(D.getIdentifierLoc(), diag::err_static_kernel);
   D.setInvalidType();
 }


Index: clang/test/SemaOpenCL/storageclass-cl20.cl
===
--- clang/test/SemaOpenCL/storageclass-cl20.cl
+++ clang/test/SemaOpenCL/storageclass-cl20.cl
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL2.0
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=clc++1.0
 
 int G2 = 0;
 global int G3 = 0;
@@ -18,6 +19,9 @@
 extern private float g_private_extern_var; // expected-error {{extern variable must reside in global or constant address space}}
 extern generic float g_generic_extern_var; // expected-error {{extern variable must reside in global or constant address space}}
 
+static void kernel bar() { // expected-error{{kernel functions cannot be declared static}}
+}
+
 void kernel foo() {
   constant int L1 = 0;
   local int L2;
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -9969,8 +9969,7 @@
 
   if (getLangOpts().OpenCL && NewFD->hasAttr()) {
 // OpenCL v1.2 s6.8 static is invalid for kernel functions.
-if ((getLangOpts().OpenCLVersion >= 120)
-&& (SC == SC_Static)) {
+if (SC == SC_Static) {
   Diag(D.getIdentifierLoc(), diag::err_static_kernel);
   D.setInvalidType();
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109157: [ARM] Mitigate the cve-2021-35465 security vulnurability.

2021-09-06 Thread Sjoerd Meijer via Phabricator via cfe-commits

SjoerdMeijer added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:1666
+CmdArgs.push_back("-mllvm");
+if (A->getOption().matches(options::OPT_mfix_cmse_cve_2021_35465))
+  CmdArgs.push_back("-arm-fix-cmse-cve-2021-35465=1");

If `-mcpu=cortex-[m33|m35|m55]` was provided, then 
`-arm-fix-cmse-cve-2021-35465=1` is already set and we are adding another 
option here? For example, for

  -mcpu=cortex-m33 -mcmse -mfix-cmse-cve-2021-35465

I am expecting:

  "-mllvm" "-arm-fix-cmse-cve-2021-35465=1"  "-mllvm" 
"-arm-fix-cmse-cve-2021-35465=1" 

and with `-mno-fix-cmse-cve-2021-35465`:

   "-mllvm" "-arm-fix-cmse-cve-2021-35465=1"  "-mllvm" 
"-arm-fix-cmse-cve-2021-35465=0" 

Probably it's nicer to just pass this once.

Also, in the tests, I think cases are missing for `-mcpu=...` and 
`-m[no-]fix-cmse-cve-2021-35465`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109157/new/

https://reviews.llvm.org/D109157

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 52f7cd2 - [OpenCL] Fix condition macro name in test

2021-09-06 Thread Justas Janickas via cfe-commits


Author: Justas Janickas
Date: 2021-09-06T13:13:13+01:00
New Revision: 52f7cd23b4af84c9e195e9e2263b8ece8d233fe2

URL: 
https://github.com/llvm/llvm-project/commit/52f7cd23b4af84c9e195e9e2263b8ece8d233fe2
DIFF: 
https://github.com/llvm/llvm-project/commit/52f7cd23b4af84c9e195e9e2263b8ece8d233fe2.diff

LOG: [OpenCL] Fix condition macro name in test

Added: 


Modified: 
clang/test/SemaOpenCL/access-qualifier.cl

Removed: 




diff  --git a/clang/test/SemaOpenCL/access-qualifier.cl 
b/clang/test/SemaOpenCL/access-qualifier.cl
index c538e73253ce0..fc6ad750e7174 100644
--- a/clang/test/SemaOpenCL/access-qualifier.cl
+++ b/clang/test/SemaOpenCL/access-qualifier.cl
@@ -79,7 +79,7 @@ kernel void read_write_twice_typedef(read_write img1d_rw i){} 
// expected-warnin
 // expected-note@-67 {{previously declared 'read_write' here}}
 #endif
 
-#if OPENCL_C_VERSION__ >= 200
+#if __OPENCL_C_VERSION__ >= 200
 void myPipeWrite(write_only pipe int); // expected-note {{passing argument to 
parameter here}}
 kernel void k14(read_only pipe int p) {
   myPipeWrite(p); // expected-error {{passing '__private read_only pipe int' 
to parameter of incompatible type 'write_only pipe int'}}



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] e6e8d25 - [X86][mingw] Modify the alignment of m128/m256/__m512 vector type for mingw

2021-09-06 Thread via cfe-commits


Author: Wang, Pengfei
Date: 2021-09-06T20:28:09+08:00
New Revision: e6e8d25920c1f1cffb58c6b3d52c2b4abbb4c963

URL: 
https://github.com/llvm/llvm-project/commit/e6e8d25920c1f1cffb58c6b3d52c2b4abbb4c963
DIFF: 
https://github.com/llvm/llvm-project/commit/e6e8d25920c1f1cffb58c6b3d52c2b4abbb4c963.diff

LOG: [X86][mingw] Modify the alignment of __m128/__m256/__m512 vector type for 
mingw

This is a follow up patch after D78564 and D108887.

Martin helped to confirm the alignment in GCC mingw is the same as the
size of vector. https://reviews.llvm.org/D108887#inline-1040893

Reviewed By: mstorsjo

Differential Revision: https://reviews.llvm.org/D109265

Added: 


Modified: 
clang/lib/CodeGen/TargetInfo.cpp
clang/test/CodeGen/x86_32-align-linux.c

Removed: 




diff  --git a/clang/lib/CodeGen/TargetInfo.cpp 
b/clang/lib/CodeGen/TargetInfo.cpp
index b9668607bd3a..5d33403f1233 100644
--- a/clang/lib/CodeGen/TargetInfo.cpp
+++ b/clang/lib/CodeGen/TargetInfo.cpp
@@ -1170,7 +1170,8 @@ class X86_32ABIInfo : public SwiftABIInfo {
   IsRetSmallStructInRegABI(RetSmallStructInRegABI),
   IsWin32StructABI(Win32StructABI), IsSoftFloatABI(SoftFloatABI),
   IsMCUABI(CGT.getTarget().getTriple().isOSIAMCU()),
-  IsLinuxABI(CGT.getTarget().getTriple().isOSLinux()),
+  IsLinuxABI(CGT.getTarget().getTriple().isOSLinux() ||
+ CGT.getTarget().getTriple().isOSCygMing()),
   DefaultNumRegisterParameters(NumRegisterParameters) {}
 
   bool shouldPassIndirectlyForSwift(ArrayRef scalars,

diff  --git a/clang/test/CodeGen/x86_32-align-linux.c 
b/clang/test/CodeGen/x86_32-align-linux.c
index 6e6ddd757b6f..df864588ae68 100644
--- a/clang/test/CodeGen/x86_32-align-linux.c
+++ b/clang/test/CodeGen/x86_32-align-linux.c
@@ -1,6 +1,9 @@
 // RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-gnu 
-emit-llvm -o - %s | FileCheck %s
 // RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-gnu 
-target-feature +avx -emit-llvm -o - %s | FileCheck %s
 // RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-gnu 
-target-feature +avx512f -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-mingw 
-emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-mingw 
-target-feature +avx -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-mingw 
-target-feature +avx512f -emit-llvm -o - %s | FileCheck %s
 
 #include 
 



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109265: [X86][mingw] Modify the alignment of m128/m256/__m512 vector type for mingw

2021-09-06 Thread Pengfei Wang via Phabricator via cfe-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe6e8d25920c1: [X86][mingw] Modify the alignment of 
__m128/__m256/__m512 vector type for mingw (authored by pengfei).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109265/new/

https://reviews.llvm.org/D109265

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/x86_32-align-linux.c


Index: clang/test/CodeGen/x86_32-align-linux.c
===
--- clang/test/CodeGen/x86_32-align-linux.c
+++ clang/test/CodeGen/x86_32-align-linux.c
@@ -1,6 +1,9 @@
 // RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-gnu 
-emit-llvm -o - %s | FileCheck %s
 // RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-gnu 
-target-feature +avx -emit-llvm -o - %s | FileCheck %s
 // RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-gnu 
-target-feature +avx512f -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-mingw 
-emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-mingw 
-target-feature +avx -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-mingw 
-target-feature +avx512f -emit-llvm -o - %s | FileCheck %s
 
 #include 
 
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -1170,7 +1170,8 @@
   IsRetSmallStructInRegABI(RetSmallStructInRegABI),
   IsWin32StructABI(Win32StructABI), IsSoftFloatABI(SoftFloatABI),
   IsMCUABI(CGT.getTarget().getTriple().isOSIAMCU()),
-  IsLinuxABI(CGT.getTarget().getTriple().isOSLinux()),
+  IsLinuxABI(CGT.getTarget().getTriple().isOSLinux() ||
+ CGT.getTarget().getTriple().isOSCygMing()),
   DefaultNumRegisterParameters(NumRegisterParameters) {}
 
   bool shouldPassIndirectlyForSwift(ArrayRef scalars,


Index: clang/test/CodeGen/x86_32-align-linux.c
===
--- clang/test/CodeGen/x86_32-align-linux.c
+++ clang/test/CodeGen/x86_32-align-linux.c
@@ -1,6 +1,9 @@
 // RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-gnu -emit-llvm -o - %s | FileCheck %s
 // RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-gnu -target-feature +avx -emit-llvm -o - %s | FileCheck %s
 // RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-gnu -target-feature +avx512f -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-mingw -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-mingw -target-feature +avx -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-mingw -target-feature +avx512f -emit-llvm -o - %s | FileCheck %s
 
 #include 
 
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -1170,7 +1170,8 @@
   IsRetSmallStructInRegABI(RetSmallStructInRegABI),
   IsWin32StructABI(Win32StructABI), IsSoftFloatABI(SoftFloatABI),
   IsMCUABI(CGT.getTarget().getTriple().isOSIAMCU()),
-  IsLinuxABI(CGT.getTarget().getTriple().isOSLinux()),
+  IsLinuxABI(CGT.getTarget().getTriple().isOSLinux() ||
+ CGT.getTarget().getTriple().isOSCygMing()),
   DefaultNumRegisterParameters(NumRegisterParameters) {}
 
   bool shouldPassIndirectlyForSwift(ArrayRef scalars,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108765: [docs] Fix documentation of clang-format BasedOnStyle type

2021-09-06 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added inline comments.



Comment at: clang/docs/tools/dump_format_style.py:17
+PLURALS_FILE = os.path.join(os.path.dirname(__file__), 'plurals.txt')
+print(f'generated plurals (for yaml type) are stored in {PLURALS_FILE}')
+print('you can use `git checkout -- plurals.txt` to reemit warnings or `git 
add`\n')

printing this is just unnecessary please remove


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108765/new/

https://reviews.llvm.org/D108765

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108765: [docs] Fix documentation of clang-format BasedOnStyle type

2021-09-06 Thread Ludovic Jozeau via Phabricator via cfe-commits

FederAndInk added inline comments.



Comment at: clang/docs/tools/dump_format_style.py:17
+PLURALS_FILE = os.path.join(os.path.dirname(__file__), 'plurals.txt')
+print(f'generated plurals (for yaml type) are stored in {PLURALS_FILE}')
+print('you can use `git checkout -- plurals.txt` to reemit warnings or `git 
add`\n')

MyDeveloperDay wrote:
> printing this is just unnecessary please remove
Ok, should I also remove line 18?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108765/new/

https://reviews.llvm.org/D108765

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109150: [OpenCL] Disallows static kernel functions in C++ for OpenCL

2021-09-06 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

Cool! Thanks


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109150/new/

https://reviews.llvm.org/D109150

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108003: [Clang] Extend -Wbool-operation to warn about bitwise and of bools with side effects

2021-09-06 Thread Hans Wennborg via Phabricator via cfe-commits

hans added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:7428-7430
+def warn_bitwise_and_bool : Warning<
+  "bitwise and of boolean expressions; did you mean logical and?">,
+  InGroup;

Quuxplusone wrote:
> xbolva00 wrote:
> > Quuxplusone wrote:
> > > I suggest that the name and wording of this diagnostic should match 
> > > `warn_logical_instead_of_bitwise`, currently `"use of logical '%0' with 
> > > constant operand"`. So:
> > > ```
> > > def warn_bitwise_instead_of_logical : Warning<
> > >   "use of bitwise '%0' with boolean operand">,
> > > ```
> > > This neatly sidesteps the problem of what to call the `&` operator: I was 
> > > not thrilled with the phrase `bitwise and of`, but have no problem with 
> > > `use of bitwise '&'`.
> > I see the point but then I will not be able to provide -Wbool-operation-and 
> > flag to enable/disable this warning.
> > 
> > For example I know that Google prefers a new flag for every new warning so 
> > they dont have to disable eg. -Wbool-operation, but just this new warning 
> > while there are working on fixes for new warnings.
> > 
> > @hans what do you think?
> > 
> > 
> I don't understand your comment. My guess is that you didn't notice that 
> `-Wbitwise-instead-of-logical` would still be a different flag from 
> `-Wlogical-instead-of-bitwise`. I'm not suggesting putting them under the 
> //same// flag; just making the newly added flag a little more consistent and 
> (heh) logical, based on what's already there.
> @hans what do you think?

I think we're all in agreement here. Putting this behind a separate 
-Wbitwise-instead-of-logical flag sounds good to me.



Comment at: clang/test/Sema/warn-bitwise-and-bool.c:21-22
+void test(boolean a, boolean b, int i) {
+  b = a & b;
+  b = a & foo();  // expected-warning {{bitwise and of boolean 
expressions; did you mean logical and?}}
+  // CHECK: 
fix-it:"{{.*}}":{[[@LINE-1]]:9-[[@LINE-1]]:10}:"&&"

xbolva00 wrote:
> Quuxplusone wrote:
> > So the warning triggers only when the RHS has side-effects? I'd like tests 
> > for
> > ```
> > foo() & a;  // should not trigger, by that logic, because && wouldn't 
> > short-circuit anything?
> > (p != nullptr) & (*p == 42);  // should certainly trigger: deref is a side 
> > effect, and of course obviously this is a bug
> > ```
> Yes, but oh.
> 
> This is weird, HasSideEffects is false for this case. Works fine for volatile 
> int.
> 
> @rsmith?
I don't think a non-volatile pointer deref actually has any side effect. I 
think what we'd want to check here is if the expression could be reordered with 
the LHS. But I don't know how we'd check that.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108003/new/

https://reviews.llvm.org/D108003

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109320: [OpenCL][Docs] Update OpenCL 3.0 implementation status.

2021-09-06 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia created this revision.
Anastasia added reviewers: azabaznov, airlied.
Herald added subscribers: ebevhan, yaxunl.
Anastasia requested review of this revision.

Updated a section of OpenCLSupport page to reflect the latest development in 
OpenCL 3.0 support for release 13.

This table will be displayed in 
https://clang.llvm.org/docs/OpenCLSupport.html#opencl-c-3-0-implementation-status.

FYI the current change is going to be added in the main branch as well as the 
release 13 branch. This therefore reflects the implementation state for the 
release 13. I am aware that some more patches have been merged and therefore 
finalized some more features after the release was branched which will then 
appear in release 14. I am going to follow up with the update including this 
delta for the main branch separately.


https://reviews.llvm.org/D109320

Files:
  clang/docs/OpenCLSupport.rst


Index: clang/docs/OpenCLSupport.rst
===
--- clang/docs/OpenCLSupport.rst
+++ clang/docs/OpenCLSupport.rst
@@ -362,41 +362,43 @@
 The following table provides an overview of features in OpenCL C 3.0 and their
 implementation status.
 
-+--+--+--+---+
-| Category | Feature   
   | Status   | Reviews 
  |
-+==+==+==+===+
-| Command line interface   | New value for ``-cl-std`` flag
   | :good:`done` | https://reviews.llvm.org/D88300 
  |
-+--+--+--+---+
-| Predefined macros| New version macro 
   | :good:`done` | https://reviews.llvm.org/D88300 
  |
-+--+--+--+---+
-| Predefined macros| Feature macros
   | :good:`done` | https://reviews.llvm.org/D95776 
  |
-+--+--+--+---+
-| Feature optionality  | Generic address space 
   | :none:`worked on`| https://reviews.llvm.org/D95778 
(partial frontend)|
-+--+--+--+---+
-| Feature optionality  | Builtin function overloads with generic 
address space| :part:`worked on`| https://reviews.llvm.org/D92004   
|
-+--+--+--+---+
-| Feature optionality  | Program scope variables in global memory  
   | :none:`unclaimed`| 
  |
-+--+--+--+---+
-| Feature optionality  | 3D image writes including builtin functions   
   | :none:`unclaimed`| 
  |
-+--+--+--+---+
-| Feature optionality  | read_write images including builtin functions 
   | :none:`unclaimed`| 
  |
-+--+--+--+---+
-| Feature optionality  | C11 atomics memory sco

[PATCH] D109320: [OpenCL][Docs] Update OpenCL 3.0 implementation status.

2021-09-06 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia added a comment.

@azabaznov  and @airlied the main feedback I am looking for is whether I have 
missed any important patch and whether you agree with the judgement about the 
completion status.

Note, that due to the release completion schedule and my planned absences it is 
likely that this needs finalizing by the end of the week. Any small changes can 
still be added later on should you wish to improve something afterwards up 
until the release branch is frozen. I just want to make sure that we don't miss 
adding the main content for the release.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109320/new/

https://reviews.llvm.org/D109320

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109320: [OpenCL][Docs] Update OpenCL 3.0 implementation status.

2021-09-06 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia added inline comments.



Comment at: clang/docs/OpenCLSupport.rst:392
++--+-+-+--+--+
+| Feature optionality  | Image types and builtin functions 
| :good:`done` | https://reviews.llvm.org/D103911 
(frontend) and https://reviews.llvm.org/D107539 (functions) |
++--+-+-+--+--+

I can see that https://reviews.llvm.org/D107539 is not committed yet... so 
potentially it would make sense to change to `worked on`.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109320/new/

https://reviews.llvm.org/D109320

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109321: [clang][OpenMP] Fix the bug in codegen for ordered directive

2021-09-06 Thread Peixin Qiao via Phabricator via cfe-commits

peixin created this revision.
peixin added reviewers: jhuber6, jdoerfert, kiranchandramohan, Meinersbur, 
clementval, kiranktp, Leporacanthicus, bryanpkc, arnamoy10, Chuanfeng.
peixin added projects: LLVM, clang.
Herald added subscribers: guansong, yaxunl.
peixin requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.

For the ordered construct with the simd clause, the outlined region
cannot be inlined. Otherwise, there may be unexpected behavior when
the captured statements are vectorized.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109321

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp


Index: clang/lib/CodeGen/CGStmtOpenMP.cpp
===
--- clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -5362,8 +5362,8 @@
   CGF.CapturedStmtInfo = &CapStmtInfo;
   llvm::Function *Fn = CGF.GenerateOpenMPCapturedStmtFunction(*S, Loc);
   Fn->setDoesNotRecurse();
-  if (CGM.getCodeGenOpts().OptimizationLevel != 0)
-Fn->addFnAttr(llvm::Attribute::AlwaysInline);
+  Fn->removeFnAttr(llvm::Attribute::AlwaysInline);
+  Fn->addFnAttr(llvm::Attribute::NoInline);
   return Fn;
 }
 


Index: clang/lib/CodeGen/CGStmtOpenMP.cpp
===
--- clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -5362,8 +5362,8 @@
   CGF.CapturedStmtInfo = &CapStmtInfo;
   llvm::Function *Fn = CGF.GenerateOpenMPCapturedStmtFunction(*S, Loc);
   Fn->setDoesNotRecurse();
-  if (CGM.getCodeGenOpts().OptimizationLevel != 0)
-Fn->addFnAttr(llvm::Attribute::AlwaysInline);
+  Fn->removeFnAttr(llvm::Attribute::AlwaysInline);
+  Fn->addFnAttr(llvm::Attribute::NoInline);
   return Fn;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109321: [clang][OpenMP] Fix the bug in codegen for ordered directive

2021-09-06 Thread Peixin Qiao via Phabricator via cfe-commits

peixin added a comment.

The following test case fails after 
https://reviews.llvm.org/rGaf000197c4214926bd7d0862d86f89aed5f20da6.

  #include 
  using namespace std;
  
  int main() {
float a[10];
int i, N = 10;
for (i = 0; i < N; i++)
  a[i] = 0;
  
#pragma omp simd
for (i = 0; i < N; i++) {
  #pragma omp ordered simd
  a[i] = a[i-1] + 1.0;
}
  
for (i = 0; i < N; i++)
  cout << a[i] << "  ";
cout << endl;
  }



  $ clang++ -fopenmp simd.cpp && ./a.out
  1  2  3  4  5  6  7  8  9  10
  $ clang++ -fopenmp -O1 simd.cpp && ./a.out
  1  1  1  1  2  1  1  1  2  3

It is fixed by this patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109321/new/

https://reviews.llvm.org/D109321

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109321: [clang][OpenMP] Fix the bug in codegen for ordered directive

2021-09-06 Thread Roman Lebedev via Phabricator via cfe-commits

lebedev.ri requested changes to this revision.
lebedev.ri added a comment.
This revision now requires changes to proceed.

In D109321#2985244 , @peixin wrote:

> The following test case fails after 
> https://reviews.llvm.org/rGaf000197c4214926bd7d0862d86f89aed5f20da6.
>
>   #include 
>   using namespace std;
>   
>   int main() {
> float a[10];
> int i, N = 10;
> for (i = 0; i < N; i++)
>   a[i] = 0;
>   
> #pragma omp simd
> for (i = 0; i < N; i++) {
>   #pragma omp ordered simd
>   a[i] = a[i-1] + 1.0;
> }
>   
> for (i = 0; i < N; i++)
>   cout << a[i] << "  ";
> cout << endl;
>   }
>
>
>
>   $ clang++ -fopenmp simd.cpp && ./a.out
>   1  2  3  4  5  6  7  8  9  10
>   $ clang++ -fopenmp -O1 simd.cpp && ./a.out
>   1  1  1  1  2  1  1  1  2  3
>
> It is fixed by this patch.

That's UB; https://godbolt.org/z/5nb61G3vY

  /app/example.cpp:13:12: runtime error: index -1 out of bounds for type 'float 
[10]'
  SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
/app/example.cpp:13:12 in 
  1  2  3  4  5  6  7  8  9  10  

Do you have an example that is miscompiled and doesn't contain UB?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109321/new/

https://reviews.llvm.org/D109321

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109315: [clang] Check unsupported types in expressions

2021-09-06 Thread Mariya Podchishchaeva via Phabricator via cfe-commits

Fznamznon added a comment.

No objections, just a couple of minors.




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:10687
 def err_device_unsupported_type
-: Error<"%0 requires %select{|%2 bit size}1 %3 type support, but device "
-"'%4' does not support it">;
+: Error<"%select{|%1 bit size}0 %2 type is not supported for target '%3'">;
 def err_omp_lambda_capture_in_declare_target_not_to : Error<

Maybe it is just me, but the old version was a bit more clear since it pointed 
to the wrong declaration. Now looking at the tests I see that clang ends up 
emitting several identical diagnostics at the same line, but they point to the 
different declarations/expressions used on this line. Should we still mention 
which concrete declaration/expression the diagnostic is about?



Comment at: clang/include/clang/Sema/Sema.h:12154
 
-  /// Check if the expression is allowed to be used in expressions for the
-  /// offloading devices.
-  void checkDeviceDecl(ValueDecl *D, SourceLocation Loc);
+  /// Check if the type is allowed to be used for this target.
+  void checkTypeSupport(QualType Ty, SourceLocation Loc,

Having that in single source offloading programming models usually two targets 
are used, "current target" sounds a bit more clear.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109315/new/

https://reviews.llvm.org/D109315

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109321: [clang][OpenMP] Fix the bug in codegen for ordered directive

2021-09-06 Thread Peixin Qiao via Phabricator via cfe-commits

peixin added a comment.

`for (i = 0; i < N; i++)` --> `for (i = 1; i < N; i++)`

  #include 
  using namespace std;
  
  int main() {
float a[10];
int i, N = 10;
for (i = 0; i < N; i++)
  a[i] = 0;
  
#pragma omp simd
for (i = 1; i < N; i++) {
  #pragma omp ordered simd
  a[i] = a[i-1] + 1.0;
}
  
for (i = 0; i < N; i++)
  cout << a[i] << "  ";
cout << endl;
  }



  $ clang++ -fopenmp simd.cpp && ./a.out
  0 1  2  3  4  5  6  7  8  9
  $ clang++ -fopenmp -O1 simd.cpp && ./a.out
  0 1  1  1  1  2  1  1  1  2


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109321/new/

https://reviews.llvm.org/D109321

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105092: [RISCV] (1/2) Add the tail policy argument to builtins/intrinsics.

2021-09-06 Thread Hsiangkai Wang via Phabricator via cfe-commits

HsiangKai added a comment.

Clang part: https://reviews.llvm.org/D109322


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105092/new/

https://reviews.llvm.org/D105092

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109321: [clang][OpenMP] Fix the bug in codegen for ordered directive

2021-09-06 Thread Roman Lebedev via Phabricator via cfe-commits

lebedev.ri added a comment.

Aha. But i don't think this is the right fix,
the fact that the inlining manifests the miscompile is a symptom.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109321/new/

https://reviews.llvm.org/D109321

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109321: [clang][OpenMP] Fix the bug in codegen for ordered directive

2021-09-06 Thread Joseph Huber via Phabricator via cfe-commits

jhuber6 added a comment.

In D109321#2985281 , @lebedev.ri 
wrote:

> Aha. But i don't think this is the right fix,
> the fact that the inlining manifests the miscompile is a symptom.

Preventing the outlined region from being inlined would also hurt OpenMP 
performance considerably.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109321/new/

https://reviews.llvm.org/D109321

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109157: [ARM] Mitigate the cve-2021-35465 security vulnurability.

2021-09-06 Thread Alexandros Lamprineas via Phabricator via cfe-commits

labrinea added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:1665
+
+CmdArgs.push_back("-mllvm");
+if (A->getOption().matches(options::OPT_mfix_cmse_cve_2021_35465))

ostannard wrote:
> Are these optional also being passed through to the linker when doing LTO?
No, the mitigation is only performed in the compiler. Also, I believe that 
`-flto` and `-mcmse` are incompatible options.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:1666
+CmdArgs.push_back("-mllvm");
+if (A->getOption().matches(options::OPT_mfix_cmse_cve_2021_35465))
+  CmdArgs.push_back("-arm-fix-cmse-cve-2021-35465=1");

SjoerdMeijer wrote:
> If `-mcpu=cortex-[m33|m35|m55]` was provided, then 
> `-arm-fix-cmse-cve-2021-35465=1` is already set and we are adding another 
> option here? For example, for
> 
>   -mcpu=cortex-m33 -mcmse -mfix-cmse-cve-2021-35465
> 
> I am expecting:
> 
>   "-mllvm" "-arm-fix-cmse-cve-2021-35465=1"  "-mllvm" 
> "-arm-fix-cmse-cve-2021-35465=1" 
> 
> and with `-mno-fix-cmse-cve-2021-35465`:
> 
>"-mllvm" "-arm-fix-cmse-cve-2021-35465=1"  "-mllvm" 
> "-arm-fix-cmse-cve-2021-35465=0" 
> 
> Probably it's nicer to just pass this once.
> 
> Also, in the tests, I think cases are missing for `-mcpu=...` and 
> `-m[no-]fix-cmse-cve-2021-35465`.
Your interpretetion is correct. The established policy is "last option wins", 
but I could make the Driver pass only one option if that's preferable.



Comment at: clang/test/Driver/arm-cmse-cve-2021-35465.c:3
+//
+// RUN: %clang --target=arm-arm-none-eabi -march=armv8-m.main %s -### \
+// RUN:   -mcmse -mno-fix-cmse-cve-2021-35465 2>&1 |\

ostannard wrote:
> The last few paragraphs of 
> https://developer.arm.com/support/arm-security-updates/vlldm-instruction-security-vulnerability
>  claim that this is enabled by default for -march=armv8-m.main in AC6 and 
> GCC, is there a reason we're not matching that?
Yes, the inconsistency lies on the fact that GCC implements the mitigation in 
library code, therefore it is always present for `-march=armv8-m.main`, whereas 
in llvm there's no such limitation. We've contacted the authors of this page to 
rectify the documentation.



Comment at: llvm/lib/Target/ARM/ARMExpandPseudoInsts.cpp:1564
   .addReg(Reg)
+  .addReg(ARM::CPSR, RegState::ImplicitDefine)
   .add(predOps(ARMCC::AL));

ostannard wrote:
> Why are these needed?
These prevent the reordering with the mitigation sequence. It answers your next 
question.



Comment at: llvm/lib/Target/ARM/ARMExpandPseudoInsts.cpp:1626
+  // Thumb2ITBlockPass will not recognise the instruction as conditional.
+  BuildMI(MBB, MBBI, DL, TII->get(ARM::t2IT))
+  .addImm(ARMCC::NE)

ostannard wrote:
> This pass runs before the final scheduler pass, so is there a risk that the 
> IT and VMOV instructions could be moved apart? I think it would be safer to 
> either put the IT instruction inside the inline asm block, or make this a new 
> pseudo-instruction expanded in the asm printer.
The use of `.addReg(ARM::CPSR, RegState::ImplicitDefine)` prevents the 
reordering. There are regression tests in place that check the mitigation 
sequence ordering.

Is this what you meant? Where you refering specifically to the case where 
`!STI->hasFPRegs()`, when we generate inline asm, or to both scenarios?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109157/new/

https://reviews.llvm.org/D109157

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109321: [clang][OpenMP] Fix the bug in codegen for ordered directive

2021-09-06 Thread Peixin Qiao via Phabricator via cfe-commits

peixin added a comment.

In D109321#2985284 , @jhuber6 wrote:

> In D109321#2985281 , @lebedev.ri 
> wrote:
>
>> Aha. But i don't think this is the right fix,
>> the fact that the inlining manifests the miscompile is a symptom.
>
> Preventing the outlined region from being inlined would also hurt OpenMP 
> performance considerably.

Please notice that this remove is only inside `emitOutlinedOrderedFunction`, 
which is only used when `ordered simd` directive is there. According to OpenMP 
5.0 Spec, the ordered construct either specifies a structured block in a 
worksharing-loop, simd, or worksharing-loop SIMD region that will be executed 
in the order of the loop iterations.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109321/new/

https://reviews.llvm.org/D109321

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109157: [ARM] Mitigate the cve-2021-35465 security vulnurability.

2021-09-06 Thread Oliver Stannard (Linaro) via Phabricator via cfe-commits

ostannard added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:1665
+
+CmdArgs.push_back("-mllvm");
+if (A->getOption().matches(options::OPT_mfix_cmse_cve_2021_35465))

labrinea wrote:
> ostannard wrote:
> > Are these optional also being passed through to the linker when doing LTO?
> No, the mitigation is only performed in the compiler. Also, I believe that 
> `-flto` and `-mcmse` are incompatible options.
The mitigation is performed in the backend, which is run from the linker when 
doing LTO.

> Also, I believe that -flto and -mcmse are incompatible options.

Fair enough



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:1666
+CmdArgs.push_back("-mllvm");
+if (A->getOption().matches(options::OPT_mfix_cmse_cve_2021_35465))
+  CmdArgs.push_back("-arm-fix-cmse-cve-2021-35465=1");

labrinea wrote:
> SjoerdMeijer wrote:
> > If `-mcpu=cortex-[m33|m35|m55]` was provided, then 
> > `-arm-fix-cmse-cve-2021-35465=1` is already set and we are adding another 
> > option here? For example, for
> > 
> >   -mcpu=cortex-m33 -mcmse -mfix-cmse-cve-2021-35465
> > 
> > I am expecting:
> > 
> >   "-mllvm" "-arm-fix-cmse-cve-2021-35465=1"  "-mllvm" 
> > "-arm-fix-cmse-cve-2021-35465=1" 
> > 
> > and with `-mno-fix-cmse-cve-2021-35465`:
> > 
> >"-mllvm" "-arm-fix-cmse-cve-2021-35465=1"  "-mllvm" 
> > "-arm-fix-cmse-cve-2021-35465=0" 
> > 
> > Probably it's nicer to just pass this once.
> > 
> > Also, in the tests, I think cases are missing for `-mcpu=...` and 
> > `-m[no-]fix-cmse-cve-2021-35465`.
> Your interpretetion is correct. The established policy is "last option wins", 
> but I could make the Driver pass only one option if that's preferable.
I agree with Sjoerd, the ""last option wins" policy should be implemented in 
the driver, and only the winning option passed through to CC1. You can use 
`Args.hasFlag` instead of `getLastArg` here, with the default set based on the 
CPU option.



Comment at: clang/test/Driver/arm-cmse-cve-2021-35465.c:3
+//
+// RUN: %clang --target=arm-arm-none-eabi -march=armv8-m.main %s -### \
+// RUN:   -mcmse -mno-fix-cmse-cve-2021-35465 2>&1 |\

labrinea wrote:
> ostannard wrote:
> > The last few paragraphs of 
> > https://developer.arm.com/support/arm-security-updates/vlldm-instruction-security-vulnerability
> >  claim that this is enabled by default for -march=armv8-m.main in AC6 and 
> > GCC, is there a reason we're not matching that?
> Yes, the inconsistency lies on the fact that GCC implements the mitigation in 
> library code, therefore it is always present for `-march=armv8-m.main`, 
> whereas in llvm there's no such limitation. We've contacted the authors of 
> this page to rectify the documentation.
This still sounds like an inconsistency which will catch out users migrating 
between GCC and clang. I'd prefer that we match GCC's behaviour, though I'd 
also be OK with leaving it like this as long as these defaults are clearly 
documented in ClangCommandLineReference.rst.



Comment at: llvm/lib/Target/ARM/ARMExpandPseudoInsts.cpp:1564
   .addReg(Reg)
+  .addReg(ARM::CPSR, RegState::ImplicitDefine)
   .add(predOps(ARMCC::AL));

labrinea wrote:
> ostannard wrote:
> > Why are these needed?
> These prevent the reordering with the mitigation sequence. It answers your 
> next question.
Do you mean that this is modeling the effect of this instruction on the CONTROL 
register, to prevent it from being re-ordered with the MRS instruction? If so, 
then this is unrelated to my next question, and could do with a comment because 
I wouldn't expect any CONTROL bits to be part of ARM::CPSR (they are different 
registers).



Comment at: llvm/lib/Target/ARM/ARMExpandPseudoInsts.cpp:1626
+  // Thumb2ITBlockPass will not recognise the instruction as conditional.
+  BuildMI(MBB, MBBI, DL, TII->get(ARM::t2IT))
+  .addImm(ARMCC::NE)

labrinea wrote:
> ostannard wrote:
> > This pass runs before the final scheduler pass, so is there a risk that the 
> > IT and VMOV instructions could be moved apart? I think it would be safer to 
> > either put the IT instruction inside the inline asm block, or make this a 
> > new pseudo-instruction expanded in the asm printer.
> The use of `.addReg(ARM::CPSR, RegState::ImplicitDefine)` prevents the 
> reordering. There are regression tests in place that check the mitigation 
> sequence ordering.
> 
> Is this what you meant? Where you refering specifically to the case where 
> `!STI->hasFPRegs()`, when we generate inline asm, or to both scenarios?
My concern is that these two instructions (IT and VMOV) have to be adjacent, 
otherwise the IT would apply to some other instruction, but I don't think 
there's anything here which guarantees that. I don't think a regression test is 
enough here, because the re-ordering coul

[PATCH] D109315: [clang] Check unsupported types in expressions

2021-09-06 Thread Andrew Savonichev via Phabricator via cfe-commits

asavonic added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:10687
 def err_device_unsupported_type
-: Error<"%0 requires %select{|%2 bit size}1 %3 type support, but device "
-"'%4' does not support it">;
+: Error<"%select{|%1 bit size}0 %2 type is not supported for target '%3'">;
 def err_omp_lambda_capture_in_declare_target_not_to : Error<

Fznamznon wrote:
> Maybe it is just me, but the old version was a bit more clear since it 
> pointed to the wrong declaration. Now looking at the tests I see that clang 
> ends up emitting several identical diagnostics at the same line, but they 
> point to the different declarations/expressions used on this line. Should we 
> still mention which concrete declaration/expression the diagnostic is about?
Agree, but I couldn't figure out good wording for the diagnostic that works 
well for both decl and expr cases.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109315/new/

https://reviews.llvm.org/D109315

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109157: [ARM] Mitigate the cve-2021-35465 security vulnurability.

2021-09-06 Thread Oliver Stannard (Linaro) via Phabricator via cfe-commits

ostannard added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:1665
+
+CmdArgs.push_back("-mllvm");
+if (A->getOption().matches(options::OPT_mfix_cmse_cve_2021_35465))

ostannard wrote:
> labrinea wrote:
> > ostannard wrote:
> > > Are these optional also being passed through to the linker when doing LTO?
> > No, the mitigation is only performed in the compiler. Also, I believe that 
> > `-flto` and `-mcmse` are incompatible options.
> The mitigation is performed in the backend, which is run from the linker when 
> doing LTO.
> 
> > Also, I believe that -flto and -mcmse are incompatible options.
> 
> Fair enough
Actually, I just checked and these options are accepted together, and I can't 
find any docs saying they are incompatible. Do you have a link to something 
I've missed? Since there isn't already an error, I think we should either fix 
this to work with LTO (my preference), or add an error when using the options 
together, and document that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109157/new/

https://reviews.llvm.org/D109157

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93110: [analyzer] Implement fine-grained suppressions via attributes

2021-09-06 Thread Valeriy Savchenko via Phabricator via cfe-commits

vsavchenko added a comment.

@aaron.ballman a gentle ping


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93110/new/

https://reviews.llvm.org/D93110

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109327: [OpenCL][Docs] Release 13 notes

2021-09-06 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia created this revision.
Anastasia added reviewers: azabaznov, olestrohm, Topotuna, svenvh, airlied, 
stuart, tstellar.
Herald added subscribers: ebevhan, yaxunl.
Anastasia requested review of this revision.

Major OpenCL functionality added in release 13.


https://reviews.llvm.org/D109327

Files:
  clang/docs/ReleaseNotes.rst


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -150,10 +150,82 @@
 Objective-C Language Changes in Clang
 -
 
-OpenCL C Language Changes in Clang
---
+OpenCL Kernel Language Changes in Clang
+---
 
-...
+
+Command-line interface changes:
+
+- All builtin types, macros and functions declarations are now added by default
+  without any command-line flags. A flag is provided ``-cl-no-stdinc`` to
+  suppress the default declarations non-native to the compiler.
+
+- Clang now compiles using OpenCL C version 1.2 by default if no version is
+  specified explicitly from the command line.
+
+- Clang now supports ``.clcpp`` file extension for sources written in
+  C++ for OpenCL.
+
+Misc common changes:
+
+- Added ``NULL`` definition in internal headers for standards prior to the
+  version 2.0.
+
+- Fix OpenCL C language version and SPIR address space reporting in DWARF.
+
+- Simplified use of pragma in extensions for ``double``, images, atomics,
+  subgroups, Arm dot product extension. There are less cases where extension
+  pragma is now required by clang to compile kernel sources.
+
+- Added missing ``as_size``/``as_ptrdiff``/``as_intptr``/``as_uintptr_t``
+  operators to internal headers.
+
+- Added new builtin function for ndrange, ``cl_khr_subgroup_extended_types``,
+  ``cl_khr_subgroup_non_uniform_vote``, ``cl_khr_subgroup_ballot``,
+  ``cl_khr_subgroup_non_uniform_arithmetic``, ``cl_khr_subgroup_shuffle``,
+  ``cl_khr_subgroup_shuffle_relative``, ``cl_khr_subgroup_clustered_reduce``
+  into the default Tablegen-based header.
+
+- Added online documentation for Tablegen-based header, OpenCL 3.0 support,
+  new clang extensions.
+
+New extensions:
+
+- ``cl_khr_integer_dot_product`` for dedicated support of DOT product.
+
+- ``cl_khr_extended_bit_ops`` for dedicated support of extra binary operations.
+
+- ``__cl_clang_bitfields`` for use of bit-fields in the kernel code.
+
+- ``__cl_clang_non_portable_kernel_param_types`` for relaxing some restrictions
+  to types of kernel parameters.
+
+OpenCL C 3.0 related changes:
+
+- Added parsing support for the optionality of generic address space, images 
+  (including 3d writes and ``read_write`` access qualifier), pipes, program
+  scope variables, double-precision floating-point support. 
+
+- Added optionality support for builtin functions (in ``opencl-c.h`` header)
+  for generic address space, C11 atomics.  
+
+- Added ``memory_scope_all_devices`` enum for the atomics in internal headers.
+
+- Enabled use of ``.rgba`` vector components.
+
+C++ for OpenCL related changes:
+
+- Added ``NULL`` macro to internal headers.
+
+- Added ``__remove_address_space`` metaprogramming utility in internal headers
+  to allow removing address spaces from types.
+
+- Improved overloads resolution logic for constructors wrt address spaces.
+
+- Improved diagnostics of OpenCL specific types and address space qualified
+  types in ``reinterpret_cast`` and template functions.
+
+- Fixed use of ``half`` type.
 
 ABI Changes in Clang
 


Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -150,10 +150,82 @@
 Objective-C Language Changes in Clang
 -
 
-OpenCL C Language Changes in Clang
---
+OpenCL Kernel Language Changes in Clang
+---
 
-...
+
+Command-line interface changes:
+
+- All builtin types, macros and functions declarations are now added by default
+  without any command-line flags. A flag is provided ``-cl-no-stdinc`` to
+  suppress the default declarations non-native to the compiler.
+
+- Clang now compiles using OpenCL C version 1.2 by default if no version is
+  specified explicitly from the command line.
+
+- Clang now supports ``.clcpp`` file extension for sources written in
+  C++ for OpenCL.
+
+Misc common changes:
+
+- Added ``NULL`` definition in internal headers for standards prior to the
+  version 2.0.
+
+- Fix OpenCL C language version and SPIR address space reporting in DWARF.
+
+- Simplified use of pragma in extensions for ``double``, images, atomics,
+  subgroups, Arm dot product extension. There are less cases where extension
+  pragma is now required by clang to compile kernel sources.
+
+- Added missing ``as_size``/``as_ptrdiff``/``as_intptr``/``as_uintptr_t``
+

[PATCH] D109328: [OpenCL] Supports optional writing to 3d images in C++ for OpenCL 2021

2021-09-06 Thread Justas Janickas via Phabricator via cfe-commits

Topotuna created this revision.
Topotuna added a reviewer: Anastasia.
Herald added subscribers: ldrumm, yaxunl.
Topotuna requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Adds support for a feature macro __opencl_c_3d_image_writes in
C++ for OpenCL 2021 enabling a respective optional core feature
from OpenCL 3.0.

This change aims to achieve compatibility between C++ for OpenCL
2021 and OpenCL 3.0.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109328

Files:
  clang/lib/Sema/SemaType.cpp
  clang/test/Misc/opencl-c-3.0.incorrect_options.cl
  clang/test/SemaOpenCL/unsupported-image.cl


Index: clang/test/SemaOpenCL/unsupported-image.cl
===
--- clang/test/SemaOpenCL/unsupported-image.cl
+++ clang/test/SemaOpenCL/unsupported-image.cl
@@ -2,7 +2,8 @@
 // RUN: %clang_cc1 -triple spir-unknown-unknown -verify -cl-std=CL3.0 
-cl-ext=+__opencl_c_images,+__opencl_c_read_write_images,+cl_khr_3d_image_writes,+__opencl_c_3d_image_writes
 %s
 // RUN: %clang_cc1 -triple spir-unknown-unknown -verify -cl-std=CL3.0 
-cl-ext=+__opencl_c_images,+__opencl_c_read_write_images,-cl_khr_3d_image_writes,-__opencl_c_3d_image_writes
 %s
 // RUN: %clang_cc1 -triple spir-unknown-unknown -verify -cl-std=clc++2021 
-cl-ext=-__opencl_c_images,-__opencl_c_read_write_images,-cl_khr_3d_image_writes,-__opencl_c_3d_image_writes
 %s
-// RUN: %clang_cc1 -triple spir-unknown-unknown -verify -cl-std=clc++2021 
-cl-ext=+__opencl_c_images %s
+// RUN: %clang_cc1 -triple spir-unknown-unknown -verify -cl-std=clc++2021 
-cl-ext=+__opencl_c_images,+__opencl_c_read_write_images,+cl_khr_3d_image_writes,+__opencl_c_3d_image_writes
 %s
+// RUN: %clang_cc1 -triple spir-unknown-unknown -verify -cl-std=clc++2021 
-cl-ext=+__opencl_c_images,+__opencl_c_read_write_images,-cl_khr_3d_image_writes,-__opencl_c_3d_image_writes
 %s
 
 #if defined(__opencl_c_images) && defined(__opencl_c_3d_image_writes)
 //expected-no-diagnostics
Index: clang/test/Misc/opencl-c-3.0.incorrect_options.cl
===
--- clang/test/Misc/opencl-c-3.0.incorrect_options.cl
+++ clang/test/Misc/opencl-c-3.0.incorrect_options.cl
@@ -8,6 +8,8 @@
 // RUN: not %clang_cc1 -cl-std=clc++2021 -triple spir-unknown-unknown 
-cl-ext=+__opencl_c_pipes,-__opencl_c_generic_address_space %s 2>&1 | FileCheck 
-check-prefix=CHECK-PIPES %s
 // RUN: not %clang_cc1 -cl-std=CL3.0 -triple spir-unknown-unknown 
-cl-ext=+__opencl_c_3d_image_writes,+__opencl_c_images,-cl_khr_3d_image_writes 
%s 2>&1 | FileCheck -check-prefix=CHECK-3D-WRITE-IMAGES-DIFF %s
 // RUN: not %clang_cc1 -cl-std=CL3.0 -triple spir-unknown-unknown 
-cl-ext=+__opencl_c_3d_image_writes,-__opencl_c_images %s 2>&1 | FileCheck 
-check-prefix=CHECK-3D-WRITE-IMAGES-DEPS %s
+// RUN: not %clang_cc1 -cl-std=clc++2021 -triple spir-unknown-unknown 
-cl-ext=+__opencl_c_3d_image_writes,+__opencl_c_images,-cl_khr_3d_image_writes 
%s 2>&1 | FileCheck -check-prefix=CHECK-3D-WRITE-IMAGES-DIFF %s
+// RUN: not %clang_cc1 -cl-std=clc++2021 -triple spir-unknown-unknown 
-cl-ext=+__opencl_c_3d_image_writes,-__opencl_c_images %s 2>&1 | FileCheck 
-check-prefix=CHECK-3D-WRITE-IMAGES-DEPS %s
 
 // CHECK-FP64: error: options cl_khr_fp64 and __opencl_c_fp64 are set to 
different values
 
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -1732,10 +1732,6 @@
 
   if (S.getLangOpts().OpenCL) {
 const auto &OpenCLOptions = S.getOpenCLOptions();
-// FIXME: both variables IsOpenCLC30 and IsOpenCLC30Compatible should be
-// unified into one when __opencl_c_3d_image_writes option is enabled in
-// C++ for OpenCL 2021
-bool IsOpenCLC30 = (S.getLangOpts().OpenCLVersion == 300);
 bool IsOpenCLC30Compatible =
 S.getLangOpts().getOpenCLCompatibleVersion() == 300;
 // OpenCL C v3.0 s6.3.3 - OpenCL image types require __opencl_c_images
@@ -1756,7 +1752,7 @@
   S.getLangOpts())) {
   S.Diag(DS.getTypeSpecTypeLoc(), diag::err_opencl_requires_extension)
   << 0 << Result
-  << (IsOpenCLC30
+  << (IsOpenCLC30Compatible
   ? "cl_khr_3d_image_writes and __opencl_c_3d_image_writes"
   : "cl_khr_3d_image_writes");
   declarator.setInvalidType();


Index: clang/test/SemaOpenCL/unsupported-image.cl
===
--- clang/test/SemaOpenCL/unsupported-image.cl
+++ clang/test/SemaOpenCL/unsupported-image.cl
@@ -2,7 +2,8 @@
 // RUN: %clang_cc1 -triple spir-unknown-unknown -verify -cl-std=CL3.0 -cl-ext=+__opencl_c_images,+__opencl_c_read_write_images,+cl_khr_3d_image_writes,+__opencl_c_3d_image_writes %s
 // RUN: %clang_cc1 -triple spir-unknown-unknown -verify -cl-std=CL3.0 -cl-ext=+__opencl_c_images,

[PATCH] D108366: [clang][deps] Make resource directory deduction configurable

2021-09-06 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 updated this revision to Diff 370931.
jansvoboda11 added a comment.

Attempt to fix tests in CI


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108366/new/

https://reviews.llvm.org/D108366

Files:
  clang/test/ClangScanDeps/Inputs/resource_directory/cdb.json.template
  clang/test/ClangScanDeps/Inputs/resource_directory/compiler
  clang/test/ClangScanDeps/Inputs/resource_directory/mod.h
  clang/test/ClangScanDeps/Inputs/resource_directory/module.modulemap
  clang/test/ClangScanDeps/Inputs/resource_directory/tu.c
  clang/test/ClangScanDeps/resource_directory.c
  clang/tools/clang-scan-deps/ClangScanDeps.cpp


Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -194,6 +194,25 @@
 "until reaching the end directive."),
 llvm::cl::init(true), llvm::cl::cat(DependencyScannerCategory));
 
+enum ResourceDirRecipeKind {
+  RDRK_ModifyCompilerPath,
+  RDRK_InvokeCompiler,
+};
+
+static llvm::cl::opt ResourceDirRecipe(
+"resource-dir-recipe",
+llvm::cl::desc("How to produce missing '-resource-dir' argument"),
+llvm::cl::values(
+clEnumValN(RDRK_ModifyCompilerPath, "modify-compiler-path",
+   "Construct the resource directory from the compiler path in 
"
+   "the compilation database. This assumes it's part of the "
+   "same toolchain as this clang-scan-deps. (default)"),
+clEnumValN(RDRK_InvokeCompiler, "invoke-compiler",
+   "Invoke the compiler with '-print-resource-dir' and use the 
"
+   "reported path as the resource directory. (deprecated)")),
+llvm::cl::init(RDRK_ModifyCompilerPath),
+llvm::cl::cat(DependencyScannerCategory));
+
 llvm::cl::opt Verbose("v", llvm::cl::Optional,
 llvm::cl::desc("Use verbose output."),
 llvm::cl::init(false),
@@ -485,7 +504,7 @@
   AdjustedArgs.push_back("/clang:" + LastO);
 }
 
-if (!HasResourceDir) {
+if (!HasResourceDir && ResourceDirRecipe == RDRK_InvokeCompiler) {
   StringRef ResourceDir =
   ResourceDirCache.findResourceDir(Args, ClangCLMode);
   if (!ResourceDir.empty()) {
Index: clang/test/ClangScanDeps/resource_directory.c
===
--- /dev/null
+++ clang/test/ClangScanDeps/resource_directory.c
@@ -0,0 +1,23 @@
+// RUN: rm -rf %t && mkdir %t
+// RUN: cp %S/Inputs/resource_directory/* %t
+
+// Deduce the resource directory from the compiler path.
+//
+// RUN: sed -e "s|CLANG|/our/custom/bin/clang|g" -e "s|DIR|%t|g" \
+// RUN:   %S/Inputs/resource_directory/cdb.json.template > %t/cdb_path.json
+// RUN: clang-scan-deps -compilation-database %t/cdb_path.json --format 
experimental-full \
+// RUN:   --resource-dir-recipe modify-compiler-path > %t/result_path.json
+// RUN: cat %t/result_path.json | sed 's:\?:/:g' | FileCheck %s 
--check-prefix=CHECK-PATH
+// CHECK-PATH:  "-resource-dir"
+// CHECK-PATH-NEXT: "/our/custom/lib{{.*}}"
+
+// Run the compiler and ask it for the resource directory.
+//
+// RUN: chmod +x %t/compiler
+// RUN: sed -e "s|CLANG|%t/compiler|g" -e "s|DIR|%t|g" \
+// RUN:   %S/Inputs/resource_directory/cdb.json.template > 
%t/cdb_invocation.json
+// RUN: clang-scan-deps -compilation-database %t/cdb_invocation.json --format 
experimental-full \
+// RUN:   --resource-dir-recipe invoke-compiler > %t/result_invocation.json
+// RUN: cat %t/result_invocation.json | sed 's:\?:/:g' | FileCheck %s 
--check-prefix=CHECK-INVOCATION
+// CHECK-INVOCATION:  "-resource-dir"
+// CHECK-INVOCATION-NEXT: "/custom/compiler/resources"
Index: clang/test/ClangScanDeps/Inputs/resource_directory/tu.c
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/tu.c
@@ -0,0 +1 @@
+#include "mod.h"
Index: clang/test/ClangScanDeps/Inputs/resource_directory/module.modulemap
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/module.modulemap
@@ -0,0 +1 @@
+module mod { header "mod.h" }
Index: clang/test/ClangScanDeps/Inputs/resource_directory/compiler
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/compiler
@@ -0,0 +1,2 @@
+#!/usr/bin/env python3
+print("/custom/compiler/resources")
Index: clang/test/ClangScanDeps/Inputs/resource_directory/cdb.json.template
===
--- /dev/null
+++ clang/test/ClangScanDeps/Inputs/resource_directory/cdb.json.template
@@ -0,0 +1,7 @@
+[
+  {
+"directory": "DIR",
+"command": "CLANG -fmodules -gmodules

[PATCH] D109327: [OpenCL][Docs] Release 13 notes

2021-09-06 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia added a comment.

Due to the release completion schedule and my planned absences, it is likely 
that this needs finalizing by the end of the week. Any small changes can still 
be added later on should you wish to improve something afterwards up until the 
release branch is frozen. I just want to make sure that we don't miss adding 
the main content for the release.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109327/new/

https://reviews.llvm.org/D109327

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108765: [docs] Fix documentation of clang-format BasedOnStyle type

2021-09-06 Thread Ludovic Jozeau via Phabricator via cfe-commits

FederAndInk updated this revision to Diff 370944.
FederAndInk added a comment.

remove one print l17, tell me if we don't want the second print (now l17)

fixed typo in the script coment -> comment


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108765/new/

https://reviews.llvm.org/D108765

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/tools/dump_format_style.py
  clang/docs/tools/plurals.txt

Index: clang/docs/tools/plurals.txt
===
--- /dev/null
+++ clang/docs/tools/plurals.txt
@@ -0,0 +1,3 @@
+Strings
+IncludeCategories
+RawStringFormats
Index: clang/docs/tools/dump_format_style.py
===
--- clang/docs/tools/dump_format_style.py
+++ clang/docs/tools/dump_format_style.py
@@ -1,23 +1,74 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
 # A tool to parse the FormatStyle struct from Format.h and update the
 # documentation in ../ClangFormatStyleOptions.rst automatically.
 # Run from the directory in which this file is located to update the docs.
 
-import collections
+import inspect
 import os
 import re
+from typing import Set
 
 CLANG_DIR = os.path.join(os.path.dirname(__file__), '../..')
 FORMAT_STYLE_FILE = os.path.join(CLANG_DIR, 'include/clang/Format/Format.h')
 INCLUDE_STYLE_FILE = os.path.join(CLANG_DIR, 'include/clang/Tooling/Inclusions/IncludeStyle.h')
 DOC_FILE = os.path.join(CLANG_DIR, 'docs/ClangFormatStyleOptions.rst')
 
+PLURALS_FILE = os.path.join(os.path.dirname(__file__), 'plurals.txt')
+print('Plural generation: you can use '
+  f'`git checkout -- {os.path.relpath(PLURALS_FILE)}` '
+  'to reemit warnings or `git add` to include new plurals\n')
+plurals: Set[str] = set()
+with open(PLURALS_FILE, 'a+') as f:
+  f.seek(0)
+  plurals = set(f.read().splitlines())
 
 def substitute(text, tag, contents):
   replacement = '\n.. START_%s\n\n%s\n\n.. END_%s\n' % (tag, contents, tag)
   pattern = r'\n\.\. START_%s\n.*\n\.\. END_%s\n' % (tag, tag)
   return re.sub(pattern, '%s', text, flags=re.S) % replacement
 
+def register_plural(singular: str, plural: str):
+  if plural not in plurals:
+plurals.add(plural)
+with open(PLURALS_FILE, 'a') as f:
+  f.write(plural + '\n')
+cf = inspect.currentframe()
+lineno = ''
+if cf and cf.f_back:
+  lineno = ':' + str(cf.f_back.f_lineno)
+print(f'{__file__}{lineno} check if plural of {singular} is {plural}', file=os.sys.stderr)
+  return plural
+
+def pluralize(word: str):
+  lword = word.lower()
+  if len(lword) >= 2 and lword[-1] == 'y' and lword[-2] not in 'aeiou':
+return register_plural(word, word[:-1] + 'ies')
+  elif lword.endswith(('s', 'sh', 'ch', 'x', 'z')):
+return register_plural(word, word[:-1] + 'es')
+  elif lword.endswith('fe'):
+return register_plural(word, word[:-2] + 'ves')
+  elif lword.endswith('f') and not lword.endswith('ff'):
+return register_plural(word, word[:-1] + 'ves')
+  else:
+return register_plural(word, word + 's')
+
+
+def to_yaml_type(typestr: str):
+  if typestr == 'bool':
+return 'Boolean'
+  elif typestr == 'int':
+return 'Integer'
+  elif typestr == 'unsigned':
+return 'Unsigned'
+  elif typestr == 'std::string':
+return 'String'
+
+  subtype, napplied = re.subn(r'^std::vector<(.*)>$', r'\1', typestr)
+  if napplied == 1:
+return 'List of ' + pluralize(to_yaml_type(subtype))
+
+  return typestr
+
 def doxygen2rst(text):
   text = re.sub(r'\s*(.*?)\s*<\/tt>', r'``\1``', text)
   text = re.sub(r'\\c ([^ ,;\.]+)', r'``\1``', text)
@@ -40,7 +91,7 @@
 self.nested_struct = None
 
   def __str__(self):
-s = '**%s** (``%s``)\n%s' % (self.name, self.type,
+s = '**%s** (``%s``)\n%s' % (self.name, to_yaml_type(self.type),
  doxygen2rst(indent(self.comment, 2)))
 if self.enum and self.enum.values:
   s += indent('\n\nPossible values:\n\n%s\n' % self.enum, 2)
@@ -85,7 +136,7 @@
 self.type = enumtype
 
   def __str__(self):
-s = '\n* ``%s %s``\n%s' % (self.type, self.name,
+s = '\n* ``%s %s``\n%s' % (to_yaml_type(self.type), self.name,
  doxygen2rst(indent(self.comment, 2)))
 s += indent('\nPossible values:\n\n', 2)
 s += indent('\n'.join(map(str, self.values)),2)
@@ -121,7 +172,7 @@
 
 def read_options(header):
   class State(object):
-BeforeStruct, Finished, InStruct, InNestedStruct, InNestedFieldComent, \
+BeforeStruct, Finished, InStruct, InNestedStruct, InNestedFieldComment, \
 InFieldComment, InEnum, InEnumMemberComment = range(8)
   state = State.BeforeStruct
 
@@ -165,12 +216,12 @@
 raise Exception('Invalid format, expected comment, field or enum')
 elif state == State.InNestedStruct:
   if line.startswith('///'):
-state = State.InNestedFieldComent
+state = State.InNestedFieldComment
 comment = clean_comment_line(

[PATCH] D107775: [Clang][AST] Resolve FIXME: Remove ObjCObjectPointer from isSpecifierType

2021-09-06 Thread Alf via Phabricator via cfe-commits

gAlfonso-bit added a comment.

@dgoldman May I ask what tests?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107775/new/

https://reviews.llvm.org/D107775

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108765: [docs] Fix documentation of clang-format BasedOnStyle type

2021-09-06 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

I still think the printing is unnecessary, tell me when the plurals will be 
different otherwise keep quiet? otherwise, it confuses people making them think 
they have to do something


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108765/new/

https://reviews.llvm.org/D108765

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108765: [docs] Fix documentation of clang-format BasedOnStyle type

2021-09-06 Thread Ludovic Jozeau via Phabricator via cfe-commits

FederAndInk updated this revision to Diff 370953.
FederAndInk added a comment.

only print info on generated plurals if there is a new plural


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108765/new/

https://reviews.llvm.org/D108765

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/tools/dump_format_style.py
  clang/docs/tools/plurals.txt

Index: clang/docs/tools/plurals.txt
===
--- /dev/null
+++ clang/docs/tools/plurals.txt
@@ -0,0 +1,3 @@
+Strings
+IncludeCategories
+RawStringFormats
Index: clang/docs/tools/dump_format_style.py
===
--- clang/docs/tools/dump_format_style.py
+++ clang/docs/tools/dump_format_style.py
@@ -1,23 +1,78 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
 # A tool to parse the FormatStyle struct from Format.h and update the
 # documentation in ../ClangFormatStyleOptions.rst automatically.
 # Run from the directory in which this file is located to update the docs.
 
-import collections
+import inspect
 import os
 import re
+from typing import Set
 
 CLANG_DIR = os.path.join(os.path.dirname(__file__), '../..')
 FORMAT_STYLE_FILE = os.path.join(CLANG_DIR, 'include/clang/Format/Format.h')
 INCLUDE_STYLE_FILE = os.path.join(CLANG_DIR, 'include/clang/Tooling/Inclusions/IncludeStyle.h')
 DOC_FILE = os.path.join(CLANG_DIR, 'docs/ClangFormatStyleOptions.rst')
 
+PLURALS_FILE = os.path.join(os.path.dirname(__file__), 'plurals.txt')
+
+plurals: Set[str] = set()
+with open(PLURALS_FILE, 'a+') as f:
+  f.seek(0)
+  plurals = set(f.read().splitlines())
 
 def substitute(text, tag, contents):
   replacement = '\n.. START_%s\n\n%s\n\n.. END_%s\n' % (tag, contents, tag)
   pattern = r'\n\.\. START_%s\n.*\n\.\. END_%s\n' % (tag, tag)
   return re.sub(pattern, '%s', text, flags=re.S) % replacement
 
+def register_plural(singular: str, plural: str):
+  if plural not in plurals:
+if not hasattr(register_plural, "generated_new_plural"):
+  print('Plural generation: you can use '
+  f'`git checkout -- {os.path.relpath(PLURALS_FILE)}` '
+  'to reemit warnings or `git add` to include new plurals\n')
+register_plural.generated_new_plural = True
+
+plurals.add(plural)
+with open(PLURALS_FILE, 'a') as f:
+  f.write(plural + '\n')
+cf = inspect.currentframe()
+lineno = ''
+if cf and cf.f_back:
+  lineno = ':' + str(cf.f_back.f_lineno)
+print(f'{__file__}{lineno} check if plural of {singular} is {plural}', file=os.sys.stderr)
+  return plural
+
+def pluralize(word: str):
+  lword = word.lower()
+  if len(lword) >= 2 and lword[-1] == 'y' and lword[-2] not in 'aeiou':
+return register_plural(word, word[:-1] + 'ies')
+  elif lword.endswith(('s', 'sh', 'ch', 'x', 'z')):
+return register_plural(word, word[:-1] + 'es')
+  elif lword.endswith('fe'):
+return register_plural(word, word[:-2] + 'ves')
+  elif lword.endswith('f') and not lword.endswith('ff'):
+return register_plural(word, word[:-1] + 'ves')
+  else:
+return register_plural(word, word + 's')
+
+
+def to_yaml_type(typestr: str):
+  if typestr == 'bool':
+return 'Boolean'
+  elif typestr == 'int':
+return 'Integer'
+  elif typestr == 'unsigned':
+return 'Unsigned'
+  elif typestr == 'std::string':
+return 'String'
+
+  subtype, napplied = re.subn(r'^std::vector<(.*)>$', r'\1', typestr)
+  if napplied == 1:
+return 'List of ' + pluralize(to_yaml_type(subtype))
+
+  return typestr
+
 def doxygen2rst(text):
   text = re.sub(r'\s*(.*?)\s*<\/tt>', r'``\1``', text)
   text = re.sub(r'\\c ([^ ,;\.]+)', r'``\1``', text)
@@ -40,7 +95,7 @@
 self.nested_struct = None
 
   def __str__(self):
-s = '**%s** (``%s``)\n%s' % (self.name, self.type,
+s = '**%s** (``%s``)\n%s' % (self.name, to_yaml_type(self.type),
  doxygen2rst(indent(self.comment, 2)))
 if self.enum and self.enum.values:
   s += indent('\n\nPossible values:\n\n%s\n' % self.enum, 2)
@@ -85,7 +140,7 @@
 self.type = enumtype
 
   def __str__(self):
-s = '\n* ``%s %s``\n%s' % (self.type, self.name,
+s = '\n* ``%s %s``\n%s' % (to_yaml_type(self.type), self.name,
  doxygen2rst(indent(self.comment, 2)))
 s += indent('\nPossible values:\n\n', 2)
 s += indent('\n'.join(map(str, self.values)),2)
@@ -121,7 +176,7 @@
 
 def read_options(header):
   class State(object):
-BeforeStruct, Finished, InStruct, InNestedStruct, InNestedFieldComent, \
+BeforeStruct, Finished, InStruct, InNestedStruct, InNestedFieldComment, \
 InFieldComment, InEnum, InEnumMemberComment = range(8)
   state = State.BeforeStruct
 
@@ -165,12 +220,12 @@
 raise Exception('Invalid format, expected comment, field or enum')
 elif state == State.InNestedStruct:
   if line.startswith('///'):
-state = State.InNestedFieldComent
+state =

[PATCH] D107775: [Clang][AST] Resolve FIXME: Remove ObjCObjectPointer from isSpecifierType

2021-09-06 Thread Alf via Phabricator via cfe-commits

gAlfonso-bit updated this revision to Diff 370952.
gAlfonso-bit added a comment.

Added test to TypePrinter


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107775/new/

https://reviews.llvm.org/D107775

Files:
  clang/lib/AST/DeclPrinter.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/unittests/AST/TypePrinterTest.cpp


Index: clang/unittests/AST/TypePrinterTest.cpp
===
--- clang/unittests/AST/TypePrinterTest.cpp
+++ clang/unittests/AST/TypePrinterTest.cpp
@@ -62,4 +62,11 @@
   ASSERT_TRUE(PrintedTypeMatches(
   Code, {}, Matcher, "const N::Type &",
   [](PrintingPolicy &Policy) { Policy.FullyQualifiedName = true; }));
+}
+
+TEST(TypePrinter, ObjectCPointerType) {
+  
+  auto Qual = qualType().bind(ObjCObjectPointerType);
+
+  ASSERT_TRUE(Qual.getTypePtr().isSpecifier() == false;)
 }
\ No newline at end of file
Index: clang/lib/AST/TypePrinter.cpp
===
--- clang/lib/AST/TypePrinter.cpp
+++ clang/lib/AST/TypePrinter.cpp
@@ -303,7 +303,6 @@
   SaveAndRestore PrevPHIsEmpty(HasEmptyPlaceHolder);
 
   // Print qualifiers as appropriate.
-
   bool CanPrefixQualifiers = false;
   bool NeedARCStrongQualifier = false;
   CanPrefixQualifiers = canPrefixQualifiers(T, NeedARCStrongQualifier);
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -2785,7 +2785,6 @@
   case DependentTemplateSpecialization:
   case ObjCInterface:
   case ObjCObject:
-  case ObjCObjectPointer: // FIXME: object pointers aren't really specifiers
 return true;
   default:
 return false;
Index: clang/lib/AST/DeclPrinter.cpp
===
--- clang/lib/AST/DeclPrinter.cpp
+++ clang/lib/AST/DeclPrinter.cpp
@@ -153,11 +153,14 @@
   while (!BaseType->isSpecifierType()) {
 if (const PointerType *PTy = BaseType->getAs())
   BaseType = PTy->getPointeeType();
+else if (const ObjCObjectPointerType *OPT =
+ BaseType->getAs())
+  BaseType = OPT->getPointeeType();
 else if (const BlockPointerType *BPy = BaseType->getAs())
   BaseType = BPy->getPointeeType();
-else if (const ArrayType* ATy = dyn_cast(BaseType))
+else if (const ArrayType *ATy = dyn_cast(BaseType))
   BaseType = ATy->getElementType();
-else if (const FunctionType* FTy = BaseType->getAs())
+else if (const FunctionType *FTy = BaseType->getAs())
   BaseType = FTy->getReturnType();
 else if (const VectorType *VTy = BaseType->getAs())
   BaseType = VTy->getElementType();


Index: clang/unittests/AST/TypePrinterTest.cpp
===
--- clang/unittests/AST/TypePrinterTest.cpp
+++ clang/unittests/AST/TypePrinterTest.cpp
@@ -62,4 +62,11 @@
   ASSERT_TRUE(PrintedTypeMatches(
   Code, {}, Matcher, "const N::Type &",
   [](PrintingPolicy &Policy) { Policy.FullyQualifiedName = true; }));
+}
+
+TEST(TypePrinter, ObjectCPointerType) {
+  
+  auto Qual = qualType().bind(ObjCObjectPointerType);
+
+  ASSERT_TRUE(Qual.getTypePtr().isSpecifier() == false;)
 }
\ No newline at end of file
Index: clang/lib/AST/TypePrinter.cpp
===
--- clang/lib/AST/TypePrinter.cpp
+++ clang/lib/AST/TypePrinter.cpp
@@ -303,7 +303,6 @@
   SaveAndRestore PrevPHIsEmpty(HasEmptyPlaceHolder);
 
   // Print qualifiers as appropriate.
-
   bool CanPrefixQualifiers = false;
   bool NeedARCStrongQualifier = false;
   CanPrefixQualifiers = canPrefixQualifiers(T, NeedARCStrongQualifier);
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -2785,7 +2785,6 @@
   case DependentTemplateSpecialization:
   case ObjCInterface:
   case ObjCObject:
-  case ObjCObjectPointer: // FIXME: object pointers aren't really specifiers
 return true;
   default:
 return false;
Index: clang/lib/AST/DeclPrinter.cpp
===
--- clang/lib/AST/DeclPrinter.cpp
+++ clang/lib/AST/DeclPrinter.cpp
@@ -153,11 +153,14 @@
   while (!BaseType->isSpecifierType()) {
 if (const PointerType *PTy = BaseType->getAs())
   BaseType = PTy->getPointeeType();
+else if (const ObjCObjectPointerType *OPT =
+ BaseType->getAs())
+  BaseType = OPT->getPointeeType();
 else if (const BlockPointerType *BPy = BaseType->getAs())
   BaseType = BPy->getPointeeType();
-else if (const ArrayType* ATy = dyn_cast(BaseType))
+else if (const ArrayType *ATy = dyn_cast(BaseType))
   BaseType = ATy->getElementType();
-else if (const FunctionType* FTy = BaseType->getAs())
+else if (const FunctionType *FTy = BaseType->getAs())
   BaseType = FTy->getReturnType();

[PATCH] D107775: [Clang][AST] Resolve FIXME: Remove ObjCObjectPointer from isSpecifierType

2021-09-06 Thread Alf via Phabricator via cfe-commits

gAlfonso-bit updated this revision to Diff 370955.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107775/new/

https://reviews.llvm.org/D107775

Files:
  clang/lib/AST/DeclPrinter.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/unittests/AST/TypePrinterTest.cpp


Index: clang/unittests/AST/TypePrinterTest.cpp
===
--- clang/unittests/AST/TypePrinterTest.cpp
+++ clang/unittests/AST/TypePrinterTest.cpp
@@ -62,4 +62,11 @@
   ASSERT_TRUE(PrintedTypeMatches(
   Code, {}, Matcher, "const N::Type &",
   [](PrintingPolicy &Policy) { Policy.FullyQualifiedName = true; }));
+}
+
+TEST(TypePrinter, ObjectCPointerType) {
+  
+  auto Qual = qualType().bind(ObjCObjectPointerType);
+
+  ASSERT_TRUE(Qual.getTypePtr().isSpecifier() == false);
 }
\ No newline at end of file
Index: clang/lib/AST/TypePrinter.cpp
===
--- clang/lib/AST/TypePrinter.cpp
+++ clang/lib/AST/TypePrinter.cpp
@@ -303,7 +303,6 @@
   SaveAndRestore PrevPHIsEmpty(HasEmptyPlaceHolder);
 
   // Print qualifiers as appropriate.
-
   bool CanPrefixQualifiers = false;
   bool NeedARCStrongQualifier = false;
   CanPrefixQualifiers = canPrefixQualifiers(T, NeedARCStrongQualifier);
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -2785,7 +2785,6 @@
   case DependentTemplateSpecialization:
   case ObjCInterface:
   case ObjCObject:
-  case ObjCObjectPointer: // FIXME: object pointers aren't really specifiers
 return true;
   default:
 return false;
Index: clang/lib/AST/DeclPrinter.cpp
===
--- clang/lib/AST/DeclPrinter.cpp
+++ clang/lib/AST/DeclPrinter.cpp
@@ -153,11 +153,14 @@
   while (!BaseType->isSpecifierType()) {
 if (const PointerType *PTy = BaseType->getAs())
   BaseType = PTy->getPointeeType();
+else if (const ObjCObjectPointerType *OPT =
+ BaseType->getAs())
+  BaseType = OPT->getPointeeType();
 else if (const BlockPointerType *BPy = BaseType->getAs())
   BaseType = BPy->getPointeeType();
-else if (const ArrayType* ATy = dyn_cast(BaseType))
+else if (const ArrayType *ATy = dyn_cast(BaseType))
   BaseType = ATy->getElementType();
-else if (const FunctionType* FTy = BaseType->getAs())
+else if (const FunctionType *FTy = BaseType->getAs())
   BaseType = FTy->getReturnType();
 else if (const VectorType *VTy = BaseType->getAs())
   BaseType = VTy->getElementType();


Index: clang/unittests/AST/TypePrinterTest.cpp
===
--- clang/unittests/AST/TypePrinterTest.cpp
+++ clang/unittests/AST/TypePrinterTest.cpp
@@ -62,4 +62,11 @@
   ASSERT_TRUE(PrintedTypeMatches(
   Code, {}, Matcher, "const N::Type &",
   [](PrintingPolicy &Policy) { Policy.FullyQualifiedName = true; }));
+}
+
+TEST(TypePrinter, ObjectCPointerType) {
+  
+  auto Qual = qualType().bind(ObjCObjectPointerType);
+
+  ASSERT_TRUE(Qual.getTypePtr().isSpecifier() == false);
 }
\ No newline at end of file
Index: clang/lib/AST/TypePrinter.cpp
===
--- clang/lib/AST/TypePrinter.cpp
+++ clang/lib/AST/TypePrinter.cpp
@@ -303,7 +303,6 @@
   SaveAndRestore PrevPHIsEmpty(HasEmptyPlaceHolder);
 
   // Print qualifiers as appropriate.
-
   bool CanPrefixQualifiers = false;
   bool NeedARCStrongQualifier = false;
   CanPrefixQualifiers = canPrefixQualifiers(T, NeedARCStrongQualifier);
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -2785,7 +2785,6 @@
   case DependentTemplateSpecialization:
   case ObjCInterface:
   case ObjCObject:
-  case ObjCObjectPointer: // FIXME: object pointers aren't really specifiers
 return true;
   default:
 return false;
Index: clang/lib/AST/DeclPrinter.cpp
===
--- clang/lib/AST/DeclPrinter.cpp
+++ clang/lib/AST/DeclPrinter.cpp
@@ -153,11 +153,14 @@
   while (!BaseType->isSpecifierType()) {
 if (const PointerType *PTy = BaseType->getAs())
   BaseType = PTy->getPointeeType();
+else if (const ObjCObjectPointerType *OPT =
+ BaseType->getAs())
+  BaseType = OPT->getPointeeType();
 else if (const BlockPointerType *BPy = BaseType->getAs())
   BaseType = BPy->getPointeeType();
-else if (const ArrayType* ATy = dyn_cast(BaseType))
+else if (const ArrayType *ATy = dyn_cast(BaseType))
   BaseType = ATy->getElementType();
-else if (const FunctionType* FTy = BaseType->getAs())
+else if (const FunctionType *FTy = BaseType->getAs())
   BaseType = FTy->getReturnType();
 else if (const VectorType *VTy = BaseType->getAs())

[PATCH] D109157: [ARM] Mitigate the cve-2021-35465 security vulnurability.

2021-09-06 Thread Alexandros Lamprineas via Phabricator via cfe-commits

labrinea added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:1665
+
+CmdArgs.push_back("-mllvm");
+if (A->getOption().matches(options::OPT_mfix_cmse_cve_2021_35465))

ostannard wrote:
> ostannard wrote:
> > labrinea wrote:
> > > ostannard wrote:
> > > > Are these optional also being passed through to the linker when doing 
> > > > LTO?
> > > No, the mitigation is only performed in the compiler. Also, I believe 
> > > that `-flto` and `-mcmse` are incompatible options.
> > The mitigation is performed in the backend, which is run from the linker 
> > when doing LTO.
> > 
> > > Also, I believe that -flto and -mcmse are incompatible options.
> > 
> > Fair enough
> Actually, I just checked and these options are accepted together, and I can't 
> find any docs saying they are incompatible. Do you have a link to something 
> I've missed? Since there isn't already an error, I think we should either fix 
> this to work with LTO (my preference), or add an error when using the options 
> together, and document that.
I have addressed all the other comments, but I am not sure how to go about this 
one. What does it take to make the cve-2021-35465 option work with LTO? Could 
you elaborate on this?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109157/new/

https://reviews.llvm.org/D109157

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108756: [clang] Add '-ast-dump-filter=' support

2021-09-06 Thread David Blaikie via Phabricator via cfe-commits

dblaikie accepted this revision.
dblaikie added a comment.
This revision is now accepted and ready to land.

Sure, sounds OK!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108756/new/

https://reviews.llvm.org/D108756

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109338: [clang][OpenMP] Make IR function names for OpenMP-outlined blocks slightly less awful

2021-09-06 Thread Roman Lebedev via Phabricator via cfe-commits

lebedev.ri created this revision.
lebedev.ri added reviewers: jdoerfert, ABataev, rjmccall.
lebedev.ri added projects: OpenMP, clang.
Herald added subscribers: zzheng, guansong, yaxunl.
lebedev.ri requested review of this revision.
Herald added a subscriber: sstefan1.

I've recently had to stare at the LLVM IR for a C++ source that contained 
OpenMP Tasks,
and it was *really* *extremely* painful to piece together which `@omp_outlined` 
function
was related to what original source code, because their names are rather 
obfuscated.

Example: https://godbolt.org/z/rTo6js8nx

I don't believe the exact name that will be used for these helpers matters (for 
ABI purposes)?

So i think we can do better.
This doesn't fix everything, i only touched `Tasks`.
There are likely other places that could use better names.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109338

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.h
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/captured-statements-nested.c
  clang/test/CodeGen/captured-statements.c
  clang/test/CodeGen/predefined-expr.c
  clang/test/CodeGenCXX/captured-statements.cpp
  clang/test/OpenMP/cancel_codegen.cpp
  clang/test/OpenMP/cancellation_point_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/for_reduction_task_codegen.cpp
  clang/test/OpenMP/function-attr.cpp
  clang/test/OpenMP/irbuilder_for_iterator.cpp
  clang/test/OpenMP/irbuilder_for_rangefor.cpp
  clang/test/OpenMP/irbuilder_for_unsigned.c
  clang/test/OpenMP/irbuilder_nested_parallel_for.c
  clang/test/OpenMP/irbuilder_unroll_full.c
  clang/test/OpenMP/irbuilder_unroll_heuristic.c
  clang/test/OpenMP/irbuilder_unroll_partial_factor.c
  clang/test/OpenMP/irbuilder_unroll_partial_factor_for.c
  clang/test/OpenMP/irbuilder_unroll_partial_heuristic.c
  clang/test/OpenMP/irbuilder_unroll_partial_heuristic_constant_for.c
  clang/test/OpenMP/irbuilder_unroll_partial_heuristic_runtime_for.c
  clang/test/OpenMP/irbuilder_unroll_unroll_partial_factor.c
  clang/test/OpenMP/irbuilder_unroll_unroll_partial_heuristic.c
  clang/test/OpenMP/master_taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_master_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_sections_reduction_task_codegen.cpp
  clang/test/OpenMP/sections_reduction_task_codegen.cpp
  clang/test/OpenMP/target_parallel_codegen.cpp
  clang/test/OpenMP/target_parallel_for_codegen.cpp
  clang/test/OpenMP/target_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/target_parallel_reduction_task_codegen.cpp
  clang/test/OpenMP/target_teams_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_codegen.cpp
  clang/test/OpenMP/task_codegen.cpp
  clang/test/OpenMP/task_if_codegen.cpp
  clang/test/OpenMP/task_in_reduction_codegen.cpp
  clang/test/OpenMP/taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/Profile/Inputs/c-captured.proftext
  clang/test/Profile/c-captured.c

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103136: [AVR] Add support for the tinyAVR 0-series and tinyAVR 1-seriesø

2021-09-06 Thread Justin Latimer via Phabricator via cfe-commits

justinlatimer added inline comments.



Comment at: llvm/lib/Target/AVR/AVRDevices.td:515
+def : Device<"attiny1614", FamilyXMEGA, ELFArchXMEGA3>;
+def : Device<"attiny416",  FamilyXMEGA, ELFArchXMEGA3>;
+def : Device<"attiny816",  FamilyXMEGA, ELFArchXMEGA3>;

benshi001 wrote:
> `attiny3214` is missing
I can't find any details on the `attiny3214`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103136/new/

https://reviews.llvm.org/D103136

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109338: [clang][OpenMP] Make IR function names for OpenMP-outlined blocks slightly less awful

2021-09-06 Thread Alexey Bataev via Phabricator via cfe-commits

ABataev added a comment.

Maybe use something close to target entries format? Encode function name and 
line number of the region. This would help if there are several omp regions in 
a function.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109338/new/

https://reviews.llvm.org/D109338

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109338: [clang][OpenMP] Make IR function names for OpenMP-outlined blocks slightly less awful

2021-09-06 Thread Roman Lebedev via Phabricator via cfe-commits

lebedev.ri added a comment.

In D109338#2985731 , @ABataev wrote:

> Maybe use something close to target entries format? Encode function name and 
> line number of the region. This would help if there are several omp regions 
> in a function.

Sure, i can do that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109338/new/

https://reviews.llvm.org/D109338

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D109322: [RISCV] (2/2) Add the tail policy argument to builtins/intrinsics.

2021-09-06 Thread Hsiangkai Wang via Phabricator via cfe-commits

HsiangKai added a comment.

I didn't attach all the test update in this patch. It is too huge to collect 
them in one patch.

I ever ran `check-clang` and all tests pass after I updated all the clang test 
cases.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109322/new/

https://reviews.llvm.org/D109322

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105092: [RISCV] (1/2) Add the tail policy argument to builtins/intrinsics.

2021-09-06 Thread Hsiangkai Wang via Phabricator via cfe-commits

HsiangKai updated this revision to Diff 370980.
HsiangKai added a comment.

Use timm for the $policy argument in the patterns.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105092/new/

https://reviews.llvm.org/D105092

Files:
  llvm/include/llvm/IR/IntrinsicsRISCV.td
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
  llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp
  llvm/lib/Target/RISCV/RISCVISelDAGToDAG.h
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/lib/Target/RISCV/RISCVInsertVSETVLI.cpp
  llvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td
  llvm/lib/Target/RISCV/RISCVInstrInfoVVLPatterns.td
  llvm/test/CodeGen/RISCV/rvv/common-shuffle-patterns.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-buildvec.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-fp-shuffles.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-int-shuffles.ll
  llvm/test/CodeGen/RISCV/rvv/fixed-vectors-masked-gather.ll
  llvm/test/CodeGen/RISCV/rvv/interleave-crash.ll
  llvm/test/CodeGen/RISCV/rvv/mgather-sdnode.ll
  llvm/test/CodeGen/RISCV/rvv/tail-agnostic-impdef-copy.mir
  llvm/test/CodeGen/RISCV/rvv/vaadd-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vaadd-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vaaddu-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vaaddu-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vadd-policy.ll
  llvm/test/CodeGen/RISCV/rvv/vadd-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vadd-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vand-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vand-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vasub-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vasub-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vasubu-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vasubu-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vdiv-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vdiv-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vdivu-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vdivu-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfadd-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfadd-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-f-x-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-f-x-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-f-xu-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-f-xu-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-rtz-x-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-rtz-x-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-rtz-xu-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-rtz-xu-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-x-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-x-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-xu-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfcvt-xu-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfdiv-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfdiv-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfmax-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfmax-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfmin-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfmin-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfmul-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfmul-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-f-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-f-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-f-x-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-f-x-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-f-xu-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-f-xu-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-rod-f-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-rod-f-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-rtz-x-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-rtz-x-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-rtz-xu-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-rtz-xu-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-x-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-x-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-xu-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfncvt-xu-f-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfrdiv-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfrdiv-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfrec7-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfrec7-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfrsqrt7-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfrsqrt7-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfrsub-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfrsub-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfsgnj-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfsgnj-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfsgnjn-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfsgnjn-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfsgnjx-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfsgnjx-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfslide1down-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfslide1down-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfslide1up-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfslide1up-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfsqrt-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfsqrt-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfsub-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfsub-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfwadd-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfwadd-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfwadd.w-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfwadd.w-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vfwcvt-f-f-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vfwcvt-f-f

[PATCH] D103136: [AVR] Add support for the tinyAVR 0-series and tinyAVR 1-seriesø

2021-09-06 Thread Ben Shi via Phabricator via cfe-commits

benshi001 added inline comments.



Comment at: llvm/lib/Target/AVR/AVRDevices.td:515
+def : Device<"attiny1614", FamilyXMEGA, ELFArchXMEGA3>;
+def : Device<"attiny416",  FamilyXMEGA, ELFArchXMEGA3>;
+def : Device<"attiny816",  FamilyXMEGA, ELFArchXMEGA3>;

justinlatimer wrote:
> benshi001 wrote:
> > `attiny3214` is missing
> I can't find any details on the `attiny3214`?
Let's just ignore that. I see attiny3214 in GCC but not find in microchip's 
website. 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103136/new/

https://reviews.llvm.org/D103136

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105191: [Clang][OpenMP] Add support for Static Device Libraries

2021-09-06 Thread Ye Luo via Phabricator via cfe-commits

ye-luo added a comment.

@saiislam since clang-nvlink-wrapper has landed, could you update this patch?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105191/new/

https://reviews.llvm.org/D105191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 9529901 - [clang] Add '-ast-dump-filter=' support

2021-09-06 Thread via cfe-commits


Author: oToToT
Date: 2021-09-07T10:42:18+08:00
New Revision: 95299019e35b21a790a2f797bede1af98d84fcb5

URL: 
https://github.com/llvm/llvm-project/commit/95299019e35b21a790a2f797bede1af98d84fcb5
DIFF: 
https://github.com/llvm/llvm-project/commit/95299019e35b21a790a2f797bede1af98d84fcb5.diff

LOG: [clang] Add '-ast-dump-filter=' support

Before this patch, we only support syntax like
`clang -cc1 -ast-dump -ast-dump-filter main a.c`
or
`clang -Xclang -ast-dump -Xclang -ast-dump-filter -Xclang main a.c`
when using ast-dump-filter.

It is helpful to also support `-ast-dump-filter=` syntax, so we can do
something like
`clang -cc1 -ast-dump -ast-dump-filter=main a.c`
or
`clang -Xclang -ast-dump -Xclang -ast-dump-filter=main a.c`

It is more cleaner when passing arguments through `-Xclang` in this case.

Also, **clang-check** do support this syntax, and I think people might
be confiused when they found they can't use `ast-dump-filter` with
clang.

Added: 


Modified: 
clang/include/clang/Driver/Options.td

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index adac18b4404fd..0b374fa4db410 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5282,6 +5282,8 @@ def ast_dump_filter : Separate<["-"], "ast-dump-filter">,
" nodes having a certain substring in a qualified name. Use"
" -ast-list to list all filterable declaration node names.">,
   MarshallingInfoString>;
+def ast_dump_filter_EQ : Joined<["-"], "ast-dump-filter=">,
+  Alias;
 def fno_modules_global_index : Flag<["-"], "fno-modules-global-index">,
   HelpText<"Do not automatically generate or update the global module index">,
   MarshallingInfoNegativeFlag>;



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105191: [Clang][OpenMP] Add support for Static Device Libraries

2021-09-06 Thread Saiyedul Islam via Phabricator via cfe-commits

saiislam added a comment.

In D105191#2985819 , @ye-luo wrote:

> @saiislam since clang-nvlink-wrapper has landed, could you update this patch?

@ye-luo , In the last multi-company OpenMP-dev meeting it was suggested that 
D106809  should be reviewed separately 
because it is logically a separate patch. But, D106809 
 is required for this patch so that it 
doesn't break our downstream pipeline.
Could you please take a look at D106809 ?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105191/new/

https://reviews.llvm.org/D105191

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D106577: [clang] Define __STDC_ISO_10646__

2021-09-06 Thread Hubert Tong via Phabricator via cfe-commits

hubert.reinterpretcast added a comment.

In D106577#2983709 , @ThePhD wrote:

> What it does mean is that Clang and every other compiler - so long as they 
> pick a ISO10646-code point capable encoding for their `wchar_t` literals - 
> can define this preprocessor macro unconditionally. My understanding is that 
> on most systems where things have not been patched / tweaked, this applies 
> since Clang vastly prefers UTF-32 in most of its setups.
>
> It is my strong recommendation this patch be accepted and made unconditional, 
> both in anticipation of the upcoming standard and the widespread existing 
> practice.

The paper does //not// update 6.10.8.2 to add "when expressed as a wchar_t 
character constant" to the wording for the macro which is the subject of this 
patch.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106577/new/

https://reviews.llvm.org/D106577

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] c2810f2 - [clangd] Omit type hints that are too long

2021-09-06 Thread Nathan Ridge via cfe-commits


Author: Nathan Ridge
Date: 2021-09-07T02:33:58-04:00
New Revision: c2810f2c1655593a48791327e9563417caf2e261

URL: 
https://github.com/llvm/llvm-project/commit/c2810f2c1655593a48791327e9563417caf2e261
DIFF: 
https://github.com/llvm/llvm-project/commit/c2810f2c1655593a48791327e9563417caf2e261.diff

LOG: [clangd] Omit type hints that are too long

Differential Revision: https://reviews.llvm.org/D108972

Added: 


Modified: 
clang-tools-extra/clangd/InlayHints.cpp
clang-tools-extra/clangd/unittests/InlayHintTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/InlayHints.cpp 
b/clang-tools-extra/clangd/InlayHints.cpp
index 7c3c6a2421d83..bea5306daeb7e 100644
--- a/clang-tools-extra/clangd/InlayHints.cpp
+++ b/clang-tools-extra/clangd/InlayHints.cpp
@@ -331,8 +331,9 @@ class InlayHintVisitor : public 
RecursiveASTVisitor {
 if (!T.getTypePtrOrNull())
   return;
 
-addInlayHint(R, InlayHintKind::TypeHint,
- std::string(Prefix) + T.getAsString(TypeHintPolicy));
+std::string TypeName = T.getAsString(TypeHintPolicy);
+if (TypeName.length() < TypeNameLimit)
+  addInlayHint(R, InlayHintKind::TypeHint, std::string(Prefix) + TypeName);
   }
 
   std::vector &Results;
@@ -341,6 +342,8 @@ class InlayHintVisitor : public 
RecursiveASTVisitor {
   StringRef MainFileBuf;
   const HeuristicResolver *Resolver;
   PrintingPolicy TypeHintPolicy;
+
+  static const size_t TypeNameLimit = 32;
 };
 
 std::vector inlayHints(ParsedAST &AST) {

diff  --git a/clang-tools-extra/clangd/unittests/InlayHintTests.cpp 
b/clang-tools-extra/clangd/unittests/InlayHintTests.cpp
index 6796a8ce70fff..62930d1f42b12 100644
--- a/clang-tools-extra/clangd/unittests/InlayHintTests.cpp
+++ b/clang-tools-extra/clangd/unittests/InlayHintTests.cpp
@@ -591,6 +591,17 @@ TEST(TypeHints, DependentType) {
   )cpp");
 }
 
+TEST(TypeHints, LongTypeName) {
+  assertTypeHints(R"cpp(
+template 
+struct A {};
+struct MultipleWords {};
+A foo();
+// Omit type hint past a certain length (currently 32)
+auto var = foo();
+  )cpp");
+}
+
 // FIXME: Low-hanging fruit where we could omit a type hint:
 //  - auto x = TypeName(...);
 //  - auto x = (TypeName) (...);



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108972: [clangd] Omit type hints that are too long

2021-09-06 Thread Nathan Ridge via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGc2810f2c1655: [clangd] Omit type hints that are too long 
(authored by nridge).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108972/new/

https://reviews.llvm.org/D108972

Files:
  clang-tools-extra/clangd/InlayHints.cpp
  clang-tools-extra/clangd/unittests/InlayHintTests.cpp


Index: clang-tools-extra/clangd/unittests/InlayHintTests.cpp
===
--- clang-tools-extra/clangd/unittests/InlayHintTests.cpp
+++ clang-tools-extra/clangd/unittests/InlayHintTests.cpp
@@ -591,6 +591,17 @@
   )cpp");
 }
 
+TEST(TypeHints, LongTypeName) {
+  assertTypeHints(R"cpp(
+template 
+struct A {};
+struct MultipleWords {};
+A foo();
+// Omit type hint past a certain length (currently 32)
+auto var = foo();
+  )cpp");
+}
+
 // FIXME: Low-hanging fruit where we could omit a type hint:
 //  - auto x = TypeName(...);
 //  - auto x = (TypeName) (...);
Index: clang-tools-extra/clangd/InlayHints.cpp
===
--- clang-tools-extra/clangd/InlayHints.cpp
+++ clang-tools-extra/clangd/InlayHints.cpp
@@ -331,8 +331,9 @@
 if (!T.getTypePtrOrNull())
   return;
 
-addInlayHint(R, InlayHintKind::TypeHint,
- std::string(Prefix) + T.getAsString(TypeHintPolicy));
+std::string TypeName = T.getAsString(TypeHintPolicy);
+if (TypeName.length() < TypeNameLimit)
+  addInlayHint(R, InlayHintKind::TypeHint, std::string(Prefix) + TypeName);
   }
 
   std::vector &Results;
@@ -341,6 +342,8 @@
   StringRef MainFileBuf;
   const HeuristicResolver *Resolver;
   PrintingPolicy TypeHintPolicy;
+
+  static const size_t TypeNameLimit = 32;
 };
 
 std::vector inlayHints(ParsedAST &AST) {


Index: clang-tools-extra/clangd/unittests/InlayHintTests.cpp
===
--- clang-tools-extra/clangd/unittests/InlayHintTests.cpp
+++ clang-tools-extra/clangd/unittests/InlayHintTests.cpp
@@ -591,6 +591,17 @@
   )cpp");
 }
 
+TEST(TypeHints, LongTypeName) {
+  assertTypeHints(R"cpp(
+template 
+struct A {};
+struct MultipleWords {};
+A foo();
+// Omit type hint past a certain length (currently 32)
+auto var = foo();
+  )cpp");
+}
+
 // FIXME: Low-hanging fruit where we could omit a type hint:
 //  - auto x = TypeName(...);
 //  - auto x = (TypeName) (...);
Index: clang-tools-extra/clangd/InlayHints.cpp
===
--- clang-tools-extra/clangd/InlayHints.cpp
+++ clang-tools-extra/clangd/InlayHints.cpp
@@ -331,8 +331,9 @@
 if (!T.getTypePtrOrNull())
   return;
 
-addInlayHint(R, InlayHintKind::TypeHint,
- std::string(Prefix) + T.getAsString(TypeHintPolicy));
+std::string TypeName = T.getAsString(TypeHintPolicy);
+if (TypeName.length() < TypeNameLimit)
+  addInlayHint(R, InlayHintKind::TypeHint, std::string(Prefix) + TypeName);
   }
 
   std::vector &Results;
@@ -341,6 +342,8 @@
   StringRef MainFileBuf;
   const HeuristicResolver *Resolver;
   PrintingPolicy TypeHintPolicy;
+
+  static const size_t TypeNameLimit = 32;
 };
 
 std::vector inlayHints(ParsedAST &AST) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D108975: [clangd] Omit default template arguments from type hints

2021-09-06 Thread Nathan Ridge via Phabricator via cfe-commits

nridge updated this revision to Diff 370994.
nridge marked an inline comment as done.
nridge added a comment.

Address review comment


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108975/new/

https://reviews.llvm.org/D108975

Files:
  clang-tools-extra/clangd/InlayHints.cpp
  clang-tools-extra/clangd/unittests/InlayHintTests.cpp

Index: clang-tools-extra/clangd/unittests/InlayHintTests.cpp
===
--- clang-tools-extra/clangd/unittests/InlayHintTests.cpp
+++ clang-tools-extra/clangd/unittests/InlayHintTests.cpp
@@ -602,6 +602,16 @@
   )cpp");
 }
 
+TEST(TypeHints, DefaultTemplateArgs) {
+  assertTypeHints(R"cpp(
+template 
+struct A {};
+A foo();
+auto $var[[var]] = foo();
+  )cpp",
+  ExpectedHint{": A", "var"});
+}
+
 // FIXME: Low-hanging fruit where we could omit a type hint:
 //  - auto x = TypeName(...);
 //  - auto x = (TypeName) (...);
Index: clang-tools-extra/clangd/InlayHints.cpp
===
--- clang-tools-extra/clangd/InlayHints.cpp
+++ clang-tools-extra/clangd/InlayHints.cpp
@@ -24,7 +24,8 @@
   : Results(Results), AST(AST.getASTContext()),
 MainFileID(AST.getSourceManager().getMainFileID()),
 Resolver(AST.getHeuristicResolver()),
-TypeHintPolicy(this->AST.getPrintingPolicy()) {
+TypeHintPolicy(this->AST.getPrintingPolicy()),
+StructuredBindingPolicy(this->AST.getPrintingPolicy()) {
 bool Invalid = false;
 llvm::StringRef Buf =
 AST.getSourceManager().getBufferData(MainFileID, &Invalid);
@@ -33,14 +34,16 @@
 TypeHintPolicy.SuppressScope = true; // keep type names short
 TypeHintPolicy.AnonymousTagLocations =
 false; // do not print lambda locations
-// Print canonical types. Otherwise, SuppressScope would result in
-// things like "metafunction::type" being shorted to just "type",
-// which is useless. This is particularly important for structured
-// bindings that use the tuple_element protocol, where the non-canonical
-// types would be "tuple_element::type".
-// Note, for "auto", we would often prefer sugared types, but the AST
-// doesn't currently retain them in DeducedType anyways.
-TypeHintPolicy.PrintCanonicalTypes = true;
+
+// For structured bindings, print canonical types. This is important because
+// for bindings that use the tuple_element protocol, the non-canonical types
+// would be "tuple_element::type".
+// For "auto", we often prefer sugared types, but the AST doesn't currently
+// retain them in DeducedType. However, not setting PrintCanonicalTypes for
+// "auto" at least allows SuppressDefaultTemplateArgs (set by default) to
+// have an effect.
+StructuredBindingPolicy = TypeHintPolicy;
+StructuredBindingPolicy.PrintCanonicalTypes = true;
   }
 
   bool VisitCXXConstructExpr(CXXConstructExpr *E) {
@@ -98,7 +101,8 @@
 // but show hints for the individual bindings.
 if (auto *DD = dyn_cast(D)) {
   for (auto *Binding : DD->bindings()) {
-addTypeHint(Binding->getLocation(), Binding->getType(), ": ");
+addTypeHint(Binding->getLocation(), Binding->getType(), ": ",
+StructuredBindingPolicy);
   }
   return true;
 }
@@ -327,11 +331,16 @@
   }
 
   void addTypeHint(SourceRange R, QualType T, llvm::StringRef Prefix) {
+addTypeHint(R, T, Prefix, TypeHintPolicy);
+  }
+
+  void addTypeHint(SourceRange R, QualType T, llvm::StringRef Prefix,
+   const PrintingPolicy &Policy) {
 // Do not print useless "NULL TYPE" hint.
 if (!T.getTypePtrOrNull())
   return;
 
-std::string TypeName = T.getAsString(TypeHintPolicy);
+std::string TypeName = T.getAsString(Policy);
 if (TypeName.length() < TypeNameLimit)
   addInlayHint(R, InlayHintKind::TypeHint, std::string(Prefix) + TypeName);
   }
@@ -341,7 +350,14 @@
   FileID MainFileID;
   StringRef MainFileBuf;
   const HeuristicResolver *Resolver;
+  // We want to suppress default template arguments, but otherwise print
+  // canonical types. Unfortunately, they're conflicting policies so we can't
+  // have both. For regular types, suppressing template arguments is more
+  // important, whereas printing canonical types is crucial for structured
+  // bindings, so we use two separate policies. (See the constructor where
+  // the policies are initialized for more details.)
   PrintingPolicy TypeHintPolicy;
+  PrintingPolicy StructuredBindingPolicy;
 
   static const size_t TypeNameLimit = 32;
 };
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] 3e03d92 - [clangd] Omit default template arguments from type hints

2021-09-06 Thread Nathan Ridge via cfe-commits


Author: Nathan Ridge
Date: 2021-09-07T02:38:27-04:00
New Revision: 3e03d92e2f4ad150469646c1b140ae6abb256c82

URL: 
https://github.com/llvm/llvm-project/commit/3e03d92e2f4ad150469646c1b140ae6abb256c82
DIFF: 
https://github.com/llvm/llvm-project/commit/3e03d92e2f4ad150469646c1b140ae6abb256c82.diff

LOG: [clangd] Omit default template arguments from type hints

Differential Revision: https://reviews.llvm.org/D108975

Added: 


Modified: 
clang-tools-extra/clangd/InlayHints.cpp
clang-tools-extra/clangd/unittests/InlayHintTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/InlayHints.cpp 
b/clang-tools-extra/clangd/InlayHints.cpp
index bea5306daeb7..167f8001d6e4 100644
--- a/clang-tools-extra/clangd/InlayHints.cpp
+++ b/clang-tools-extra/clangd/InlayHints.cpp
@@ -24,7 +24,8 @@ class InlayHintVisitor : public 
RecursiveASTVisitor {
   : Results(Results), AST(AST.getASTContext()),
 MainFileID(AST.getSourceManager().getMainFileID()),
 Resolver(AST.getHeuristicResolver()),
-TypeHintPolicy(this->AST.getPrintingPolicy()) {
+TypeHintPolicy(this->AST.getPrintingPolicy()),
+StructuredBindingPolicy(this->AST.getPrintingPolicy()) {
 bool Invalid = false;
 llvm::StringRef Buf =
 AST.getSourceManager().getBufferData(MainFileID, &Invalid);
@@ -33,14 +34,16 @@ class InlayHintVisitor : public 
RecursiveASTVisitor {
 TypeHintPolicy.SuppressScope = true; // keep type names short
 TypeHintPolicy.AnonymousTagLocations =
 false; // do not print lambda locations
-// Print canonical types. Otherwise, SuppressScope would result in
-// things like "metafunction::type" being shorted to just "type",
-// which is useless. This is particularly important for structured
-// bindings that use the tuple_element protocol, where the non-canonical
-// types would be "tuple_element::type".
-// Note, for "auto", we would often prefer sugared types, but the AST
-// doesn't currently retain them in DeducedType anyways.
-TypeHintPolicy.PrintCanonicalTypes = true;
+
+// For structured bindings, print canonical types. This is important 
because
+// for bindings that use the tuple_element protocol, the non-canonical 
types
+// would be "tuple_element::type".
+// For "auto", we often prefer sugared types, but the AST doesn't currently
+// retain them in DeducedType. However, not setting PrintCanonicalTypes for
+// "auto" at least allows SuppressDefaultTemplateArgs (set by default) to
+// have an effect.
+StructuredBindingPolicy = TypeHintPolicy;
+StructuredBindingPolicy.PrintCanonicalTypes = true;
   }
 
   bool VisitCXXConstructExpr(CXXConstructExpr *E) {
@@ -98,7 +101,8 @@ class InlayHintVisitor : public 
RecursiveASTVisitor {
 // but show hints for the individual bindings.
 if (auto *DD = dyn_cast(D)) {
   for (auto *Binding : DD->bindings()) {
-addTypeHint(Binding->getLocation(), Binding->getType(), ": ");
+addTypeHint(Binding->getLocation(), Binding->getType(), ": ",
+StructuredBindingPolicy);
   }
   return true;
 }
@@ -327,11 +331,16 @@ class InlayHintVisitor : public 
RecursiveASTVisitor {
   }
 
   void addTypeHint(SourceRange R, QualType T, llvm::StringRef Prefix) {
+addTypeHint(R, T, Prefix, TypeHintPolicy);
+  }
+
+  void addTypeHint(SourceRange R, QualType T, llvm::StringRef Prefix,
+   const PrintingPolicy &Policy) {
 // Do not print useless "NULL TYPE" hint.
 if (!T.getTypePtrOrNull())
   return;
 
-std::string TypeName = T.getAsString(TypeHintPolicy);
+std::string TypeName = T.getAsString(Policy);
 if (TypeName.length() < TypeNameLimit)
   addInlayHint(R, InlayHintKind::TypeHint, std::string(Prefix) + TypeName);
   }
@@ -341,7 +350,14 @@ class InlayHintVisitor : public 
RecursiveASTVisitor {
   FileID MainFileID;
   StringRef MainFileBuf;
   const HeuristicResolver *Resolver;
+  // We want to suppress default template arguments, but otherwise print
+  // canonical types. Unfortunately, they're conflicting policies so we can't
+  // have both. For regular types, suppressing template arguments is more
+  // important, whereas printing canonical types is crucial for structured
+  // bindings, so we use two separate policies. (See the constructor where
+  // the policies are initialized for more details.)
   PrintingPolicy TypeHintPolicy;
+  PrintingPolicy StructuredBindingPolicy;
 
   static const size_t TypeNameLimit = 32;
 };

diff  --git a/clang-tools-extra/clangd/unittests/InlayHintTests.cpp 
b/clang-tools-extra/clangd/unittests/InlayHintTests.cpp
index 62930d1f42b1..cda2ba41e264 100644
--- a/clang-tools-extra/clangd/unittests/InlayHintTests.cpp
+++ b/clang-tools-extra/clangd/unittests/InlayHintTests.cpp
@@ -602,6 +602,16 @@ TEST(TypeHints, LongTypeName) {
   )cpp");
 }
 
+TEST(TypeHi

[PATCH] D108975: [clangd] Omit default template arguments from type hints

2021-09-06 Thread Nathan Ridge via Phabricator via cfe-commits

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG3e03d92e2f4a: [clangd] Omit default template arguments from 
type hints (authored by nridge).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108975/new/

https://reviews.llvm.org/D108975

Files:
  clang-tools-extra/clangd/InlayHints.cpp
  clang-tools-extra/clangd/unittests/InlayHintTests.cpp

Index: clang-tools-extra/clangd/unittests/InlayHintTests.cpp
===
--- clang-tools-extra/clangd/unittests/InlayHintTests.cpp
+++ clang-tools-extra/clangd/unittests/InlayHintTests.cpp
@@ -602,6 +602,16 @@
   )cpp");
 }
 
+TEST(TypeHints, DefaultTemplateArgs) {
+  assertTypeHints(R"cpp(
+template 
+struct A {};
+A foo();
+auto $var[[var]] = foo();
+  )cpp",
+  ExpectedHint{": A", "var"});
+}
+
 // FIXME: Low-hanging fruit where we could omit a type hint:
 //  - auto x = TypeName(...);
 //  - auto x = (TypeName) (...);
Index: clang-tools-extra/clangd/InlayHints.cpp
===
--- clang-tools-extra/clangd/InlayHints.cpp
+++ clang-tools-extra/clangd/InlayHints.cpp
@@ -24,7 +24,8 @@
   : Results(Results), AST(AST.getASTContext()),
 MainFileID(AST.getSourceManager().getMainFileID()),
 Resolver(AST.getHeuristicResolver()),
-TypeHintPolicy(this->AST.getPrintingPolicy()) {
+TypeHintPolicy(this->AST.getPrintingPolicy()),
+StructuredBindingPolicy(this->AST.getPrintingPolicy()) {
 bool Invalid = false;
 llvm::StringRef Buf =
 AST.getSourceManager().getBufferData(MainFileID, &Invalid);
@@ -33,14 +34,16 @@
 TypeHintPolicy.SuppressScope = true; // keep type names short
 TypeHintPolicy.AnonymousTagLocations =
 false; // do not print lambda locations
-// Print canonical types. Otherwise, SuppressScope would result in
-// things like "metafunction::type" being shorted to just "type",
-// which is useless. This is particularly important for structured
-// bindings that use the tuple_element protocol, where the non-canonical
-// types would be "tuple_element::type".
-// Note, for "auto", we would often prefer sugared types, but the AST
-// doesn't currently retain them in DeducedType anyways.
-TypeHintPolicy.PrintCanonicalTypes = true;
+
+// For structured bindings, print canonical types. This is important because
+// for bindings that use the tuple_element protocol, the non-canonical types
+// would be "tuple_element::type".
+// For "auto", we often prefer sugared types, but the AST doesn't currently
+// retain them in DeducedType. However, not setting PrintCanonicalTypes for
+// "auto" at least allows SuppressDefaultTemplateArgs (set by default) to
+// have an effect.
+StructuredBindingPolicy = TypeHintPolicy;
+StructuredBindingPolicy.PrintCanonicalTypes = true;
   }
 
   bool VisitCXXConstructExpr(CXXConstructExpr *E) {
@@ -98,7 +101,8 @@
 // but show hints for the individual bindings.
 if (auto *DD = dyn_cast(D)) {
   for (auto *Binding : DD->bindings()) {
-addTypeHint(Binding->getLocation(), Binding->getType(), ": ");
+addTypeHint(Binding->getLocation(), Binding->getType(), ": ",
+StructuredBindingPolicy);
   }
   return true;
 }
@@ -327,11 +331,16 @@
   }
 
   void addTypeHint(SourceRange R, QualType T, llvm::StringRef Prefix) {
+addTypeHint(R, T, Prefix, TypeHintPolicy);
+  }
+
+  void addTypeHint(SourceRange R, QualType T, llvm::StringRef Prefix,
+   const PrintingPolicy &Policy) {
 // Do not print useless "NULL TYPE" hint.
 if (!T.getTypePtrOrNull())
   return;
 
-std::string TypeName = T.getAsString(TypeHintPolicy);
+std::string TypeName = T.getAsString(Policy);
 if (TypeName.length() < TypeNameLimit)
   addInlayHint(R, InlayHintKind::TypeHint, std::string(Prefix) + TypeName);
   }
@@ -341,7 +350,14 @@
   FileID MainFileID;
   StringRef MainFileBuf;
   const HeuristicResolver *Resolver;
+  // We want to suppress default template arguments, but otherwise print
+  // canonical types. Unfortunately, they're conflicting policies so we can't
+  // have both. For regular types, suppressing template arguments is more
+  // important, whereas printing canonical types is crucial for structured
+  // bindings, so we use two separate policies. (See the constructor where
+  // the policies are initialized for more details.)
   PrintingPolicy TypeHintPolicy;
+  PrintingPolicy StructuredBindingPolicy;
 
   static const size_t TypeNameLimit = 32;
 };
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

86 matches

Mail list logo