[PATCH] D99458: [clang-format] Fix east const pointer alignment of operators

2021-03-29 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay accepted this revision.
MyDeveloperDay added a comment.

This LGTM, thank you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99458

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


[PATCH] D99488: [SYCL][Doc] Add address space handling section to SYCL documentation

2021-03-29 Thread Alexey Bader via Phabricator via cfe-commits
bader created this revision.
bader added reviewers: Anastasia, keryell, Naghasan.
Herald added subscribers: ebevhan, yaxunl.
bader requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99488

Files:
  clang/docs/SYCLSupport.md

Index: clang/docs/SYCLSupport.md
===
--- clang/docs/SYCLSupport.md
+++ clang/docs/SYCLSupport.md
@@ -813,6 +813,113 @@
 The SPIR-V specific functions are implemented in for the SYCL host device here:
 `sycl/source/spirv_ops.cpp`.
 
+### Address spaces handling
+
+SYCL specification uses C++ classes to represent pointers to disjoint memory
+regions on an accelerator to enable compilation with standard C++ toolchain and
+SYCL compiler toolchain. Section 3.8.2 of SYCL 2020 specification defines
+[memory model](https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_sycl_device_memory_model),
+section 4.7.7 - [address space classes](https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_address_space_classes)
+and section 5.9.2 covers [address space deduction](https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_address_space_deduction).
+
+For instance:
+
+``` C++
+// check that SYCL mode is ON and we can use non-standard decorations
+#if defined(__SYCL_DEVICE_ONLY__)
+// GPU/accelerator implementation
+template  class multi_ptr {
+  // DecoratedType applies corresponding address space attribute to the type T
+  // DecoratedType::type == "__attribute__((opencl_global)) T"
+  // See sycl/include/CL/sycl/access/access.hpp for more details
+  using pointer_t = typename DecoratedType::type *;
+
+  pointer_t m_Pointer;
+  public:
+  pointer_t get() { return m_Pointer; }
+  T& operator* () { return *reinterpret_cast(m_Pointer); }
+}
+#else
+// CPU/host implementation
+template  class multi_ptr {
+  T *m_Pointer; // regular undecorated pointer
+  public:
+  T *get() { return m_Pointer; }
+  T& operator* () { return *m_Pointer; }
+}
+#endif
+```
+
+Depending on the compiler mode `multi_ptr` will either decorate internal data
+with address space attribute or not.
+
+The main address space semantic difference of SYCL mode from OpenCL is that
+SYCL doesn't assign OpenCL generic address space to a declaration's type without
+explicit address space attribute. Similar to other single-source C++-based GPU
+programming modes like OpenMP/CUDA/HIP, SYCL uses clang's "default" address
+space for types with no address space attributes. During the lowering to LLVM
+IR, the default address space is mapped to the SPIR generic address space.
+Declarations are assigned to the relevant memory region depending on their
+declaration context and pointers to them are cast to generic. This design has
+two important features: keeps the type system consistent with C++ on one hand
+and enable tools for emitting device code aligned with SPIR memory model (and
+other GPU targets).
+
+So inside a function, this variable declaration:
+
+```C++
+int var;
+```
+
+SYCL device compiler turns into
+
+```C++
+VarDecl  var 'int'
+```
+
+OpenCL compiler turn into
+
+```C++
+VarDecl  var '__private int'
+```
+
+Changing variable type has massive and destructive effect in C++. For instance
+this does not compile in C++ for OpenCL mode:
+
+```C++
+template
+struct is_same {
+static constexpr int value = 0;
+};
+
+template
+struct is_same {
+static constexpr int value = 1;
+};
+
+void foo(int p) {
+static_assert(is_same::value, "int is not an int?"); // Fails: p is '__private int' != 'int'
+static_assert(is_same::value, "int* is not an int*?");  // Fails: p is '__private int*' != '__generic int*'
+}
+```
+
+To utilize existing clang's functionality, we re-use following OpenCL address
+space attributes in SYCL mode:
+
+| Address space attribute | SYCL address_space enumeration |
+|-||
+| `__attribute__((opencl_global))` | global_space, constant_space |
+| `__attribute__((opencl_global_host))` | global_host_space |
+| `__attribute__((opencl_global_device))` | global_device_space |
+| `__attribute__((opencl_local))` | local_space |
+| `__attribute__((opencl_private))` | private_space |
+| `__attribute__((opencl_constant))` | N/A
+
+> **NOTE**: although SYCL device compiler supports
+`__attribute__((opencl_constant))`, the use of this attribute is limited within
+SYCL implementation. An OpenCL constant pointer can not be casted to a pointer
+with any other address space (including default).
+
 ### Compiler/Runtime interface
 
 ## SYCL Runtime architecture
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99190: WIP: [SYCL] Add design document for SYCL mode

2021-03-29 Thread Alexey Bader via Phabricator via cfe-commits
bader updated this revision to Diff 333780.
bader added a comment.

Move address space handling section to https://reviews.llvm.org/D99488 to 
address https://reviews.llvm.org/D89909#2653452.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99190

Files:
  clang/docs/SYCLSupport.md
  clang/docs/images/Compiler-HLD.svg
  clang/docs/images/DeviceCodeSplit.svg
  clang/docs/images/DeviceLinkAndWrap.svg
  clang/docs/images/DevicePTXProcessing.svg
  clang/docs/images/SplitCompileAndLink.svg

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


[PATCH] D99489: [clang] [PR49736] [C++2b] Correctly reject lambdas with requires clause and no parameter list

2021-03-29 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius created this revision.
curdeius added reviewers: aaron.ballman, rsmith.
curdeius requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This fixes http://llvm.org/PR49736 caused by implementing 
http://wg21.link/P1102 
(https://reviews.llvm.org/rG0620e6f4b76a9725dbd82454d58c5a68a7e47074), by 
correctly allowing requires-clause only:

1. directly after template-parameter-list
2. after lambda-specifiers iff parameter-declaration-clause is present (2nd 
kind of lambda-declarator)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99489

Files:
  clang/lib/Parse/ParseExprCXX.cpp
  clang/test/Parser/cxx-concepts-requires-clause.cpp
  clang/test/Parser/cxx2a-template-lambdas.cpp
  clang/test/Parser/cxx2b-lambdas.cpp

Index: clang/test/Parser/cxx2b-lambdas.cpp
===
--- clang/test/Parser/cxx2b-lambdas.cpp
+++ clang/test/Parser/cxx2b-lambdas.cpp
@@ -18,8 +18,8 @@
 auto L10 = [] noexcept { return true; };
 auto L11 = [] -> bool { return true; };
 auto L12 = [] consteval {};
-auto L13 = [] requires requires() { true; }
-{};
+auto L13 = []() requires true {};
+auto L14 = [] requires true() requires true {};
 auto L15 = [] [[maybe_unused]]{};
 
 auto XL0 = [] mutable constexpr mutable {};// expected-error{{cannot appear multiple times}}
@@ -32,3 +32,11 @@
// expected-note{{to match this '('}} \
// expected-error{{expected body}} \
// expected-warning{{duplicate 'constexpr'}}
+
+// http://llvm.org/PR49736
+auto XL4 = [] requires true() {}; // expected-error{{expected body}}
+auto XL5 = [] requires true {}; // expected-error{{expected body}}
+auto XL6 = [] requires true requires true {}; // expected-error{{expected body}}
+auto XL7 = [] requires true noexcept requires true {}; // expected-error{{expected body}}
+auto XL8 = [] requires true requires true {}; // expected-error{{expected body}}
+auto XL9 = [] requires true noexcept requires true {}; // expected-error{{expected body}}
Index: clang/test/Parser/cxx2a-template-lambdas.cpp
===
--- clang/test/Parser/cxx2a-template-lambdas.cpp
+++ clang/test/Parser/cxx2a-template-lambdas.cpp
@@ -7,3 +7,30 @@
 auto L2 = [](T1 arg1, T2 arg2) -> T1 { };
 auto L3 = [](auto arg) { T t; };
 auto L4 = []() { };
+
+// http://llvm.org/PR49736
+auto L5 = []{};
+auto L6 = [] noexcept {};
+#if __cplusplus <= 202002L
+// expected-warning@-2 {{is a C++2b extension}}
+#endif
+auto L7 = [] requires true {}; // ?
+auto L8 = [] requires true noexcept {};
+#if __cplusplus <= 202002L
+// expected-warning@-2 {{is a C++2b extension}}
+#endif
+
+auto L9 = [](){};
+auto L10 = []() noexcept {};
+auto L11 = [] requires true(){};
+auto L12 = [] requires true() noexcept {};
+auto L13 = [] requires true() noexcept requires true {};
+auto L14 = []() noexcept requires true {};
+auto L15 = [] requires true(){};
+
+auto XL0 = [] noexcept requires true {}; // expected-error {{expected body}}
+auto XL1 = [] noexcept requires true {}; // expected-error {{expected body}}
+#if __cplusplus <= 202002L
+// expected-warning@-3 {{is a C++2b extension}}
+// expected-warning@-3 {{is a C++2b extension}}
+#endif
Index: clang/test/Parser/cxx-concepts-requires-clause.cpp
===
--- clang/test/Parser/cxx-concepts-requires-clause.cpp
+++ clang/test/Parser/cxx-concepts-requires-clause.cpp
@@ -154,7 +154,9 @@
 
 auto lambda2 = [] (auto x) constexpr -> int requires (sizeof(decltype(x)) == 1) { return 0; };
 
-auto lambda3 = [] requires (sizeof(char) == 1) { };
+auto lambda3 = [] requires(sizeof(char) == 1){};
+
+auto lambda4 = [] requires(sizeof(char) == 1){}; // expected-error {{expected body}}
 #if __cplusplus <= 202002L
 // expected-warning@-2{{is a C++2b extension}}
 #endif
Index: clang/lib/Parse/ParseExprCXX.cpp
===
--- clang/lib/Parse/ParseExprCXX.cpp
+++ clang/lib/Parse/ParseExprCXX.cpp
@@ -1392,12 +1392,6 @@
 /*DeclsInPrototype=*/None, LParenLoc, FunLocalRangeEnd, D,
 TrailingReturnType, TrailingReturnTypeLoc, &DS),
 std::move(Attr), DeclEndLoc);
-
-// Parse requires-clause[opt].
-if (Tok.is(tok::kw_requires))
-  ParseTrailingRequiresClause(D);
-
-WarnIfHasCUDATargetAttr();
   };
 
   if (Tok.is(tok::l_paren)) {
@@ -1433,6 +1427,12 @@
 // Parse lambda-specifiers.
 ParseLambdaSpecifiers(LParenLoc, /*DeclEndLoc=*/T.getCloseLocation(),
   ParamInfo, EllipsisLoc);
+
+// Parse requires-clause[opt].
+if (Tok.is(tok::kw_requires))
+  ParseTrailingRequiresClause(D);
+
+WarnIfHasCUDATargetAttr();
   } else if (Tok.isOneOf(tok::kw_mutable, to

[PATCH] D99262: [analyzer] Fix dead store checker false positive

2021-03-29 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko updated this revision to Diff 333789.
vsavchenko added a comment.

Add comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99262

Files:
  clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
  clang/test/Analysis/dead-stores.c


Index: clang/test/Analysis/dead-stores.c
===
--- clang/test/Analysis/dead-stores.c
+++ clang/test/Analysis/dead-stores.c
@@ -635,3 +635,21 @@
   volatile int v;
   v = 0; // no warning
 }
+
+struct Foo {
+  int x;
+  int y;
+};
+
+struct Foo rdar34122265_getFoo(void);
+
+int rdar34122265_test_struct(int input) {
+  // This is allowed for defensive programming.
+  struct Foo foo = {0, 0};
+  if (input > 0) {
+foo = rdar34122265_getFoo();
+  } else {
+return 0;
+  }
+  return foo.x + foo.y;
+}
Index: clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
@@ -11,17 +11,18 @@
 //
 
//===--===//
 
-#include "clang/Lex/Lexer.h"
-#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Attr.h"
 #include "clang/AST/ParentMap.h"
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/Analysis/Analyses/LiveVariables.h"
+#include "clang/Lex/Lexer.h"
+#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
 #include "clang/StaticAnalyzer/Core/Checker.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
 #include "llvm/ADT/BitVector.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/SaveAndRestore.h"
 
@@ -415,8 +416,23 @@
   if (E->isEvaluatable(Ctx))
 return;
 
+  // We should also allow defensive initialization of structs.
+  if (const auto *ILE =
+  dyn_cast(E->IgnoreParenCasts())) {
+// We can use exactly the same logic here.
+// If all fields of the struct are initialized with constants,
+//
+// e.g. : Foo x = { 0, 1 };
+//
+// we shouldn't complain about the fact that it is not used.
+if (llvm::all_of(ILE->inits(), [this](const Expr *Init) {
+  return Init->isEvaluatable(Ctx);
+}))
+  return;
+  }
+
   if (const DeclRefExpr *DRE =
-  dyn_cast(E->IgnoreParenCasts()))
+  dyn_cast(E->IgnoreParenCasts()))
 if (const VarDecl *VD = dyn_cast(DRE->getDecl())) {
   // Special case: check for initialization from constant
   //  variables.


Index: clang/test/Analysis/dead-stores.c
===
--- clang/test/Analysis/dead-stores.c
+++ clang/test/Analysis/dead-stores.c
@@ -635,3 +635,21 @@
   volatile int v;
   v = 0; // no warning
 }
+
+struct Foo {
+  int x;
+  int y;
+};
+
+struct Foo rdar34122265_getFoo(void);
+
+int rdar34122265_test_struct(int input) {
+  // This is allowed for defensive programming.
+  struct Foo foo = {0, 0};
+  if (input > 0) {
+foo = rdar34122265_getFoo();
+  } else {
+return 0;
+  }
+  return foo.x + foo.y;
+}
Index: clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
@@ -11,17 +11,18 @@
 //
 //===--===//
 
-#include "clang/Lex/Lexer.h"
-#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Attr.h"
 #include "clang/AST/ParentMap.h"
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/Analysis/Analyses/LiveVariables.h"
+#include "clang/Lex/Lexer.h"
+#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
 #include "clang/StaticAnalyzer/Core/Checker.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
 #include "llvm/ADT/BitVector.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/SaveAndRestore.h"
 
@@ -415,8 +416,23 @@
   if (E->isEvaluatable(Ctx))
 return;
 
+  // We should also allow defensive initialization of structs.
+  if (const auto *ILE =
+  dyn_cast(E->IgnoreParenCasts())) {
+  

[PATCH] D99262: [analyzer] Fix dead store checker false positive

2021-03-29 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko updated this revision to Diff 333793.
vsavchenko added a comment.

Add another test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99262

Files:
  clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
  clang/test/Analysis/dead-stores.c


Index: clang/test/Analysis/dead-stores.c
===
--- clang/test/Analysis/dead-stores.c
+++ clang/test/Analysis/dead-stores.c
@@ -635,3 +635,27 @@
   volatile int v;
   v = 0; // no warning
 }
+
+struct Foo {
+  int x;
+  int y;
+};
+
+struct Foo rdar34122265_getFoo(void);
+
+int rdar34122265_test(int input) {
+  // This is allowed for defensive programming.
+  struct Foo foo = {0, 0};
+  if (input > 0) {
+foo = rdar34122265_getFoo();
+  } else {
+return 0;
+  }
+  return foo.x + foo.y;
+}
+
+void rdar34122265_test_cast() {
+  // This is allowed for defensive programming.
+  struct Foo foo = {0, 0};
+  (void)foo;
+}
Index: clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
@@ -11,17 +11,18 @@
 //
 
//===--===//
 
-#include "clang/Lex/Lexer.h"
-#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Attr.h"
 #include "clang/AST/ParentMap.h"
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/Analysis/Analyses/LiveVariables.h"
+#include "clang/Lex/Lexer.h"
+#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
 #include "clang/StaticAnalyzer/Core/Checker.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
 #include "llvm/ADT/BitVector.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/SaveAndRestore.h"
 
@@ -415,8 +416,23 @@
   if (E->isEvaluatable(Ctx))
 return;
 
+  // We should also allow defensive initialization of structs.
+  if (const auto *ILE =
+  dyn_cast(E->IgnoreParenCasts())) {
+// We can use exactly the same logic here.
+// If all fields of the struct are initialized with constants,
+//
+// e.g. : Foo x = { 0, 1 };
+//
+// we shouldn't complain about the fact that it is not used.
+if (llvm::all_of(ILE->inits(), [this](const Expr *Init) {
+  return Init->isEvaluatable(Ctx);
+}))
+  return;
+  }
+
   if (const DeclRefExpr *DRE =
-  dyn_cast(E->IgnoreParenCasts()))
+  dyn_cast(E->IgnoreParenCasts()))
 if (const VarDecl *VD = dyn_cast(DRE->getDecl())) {
   // Special case: check for initialization from constant
   //  variables.


Index: clang/test/Analysis/dead-stores.c
===
--- clang/test/Analysis/dead-stores.c
+++ clang/test/Analysis/dead-stores.c
@@ -635,3 +635,27 @@
   volatile int v;
   v = 0; // no warning
 }
+
+struct Foo {
+  int x;
+  int y;
+};
+
+struct Foo rdar34122265_getFoo(void);
+
+int rdar34122265_test(int input) {
+  // This is allowed for defensive programming.
+  struct Foo foo = {0, 0};
+  if (input > 0) {
+foo = rdar34122265_getFoo();
+  } else {
+return 0;
+  }
+  return foo.x + foo.y;
+}
+
+void rdar34122265_test_cast() {
+  // This is allowed for defensive programming.
+  struct Foo foo = {0, 0};
+  (void)foo;
+}
Index: clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/DeadStoresChecker.cpp
@@ -11,17 +11,18 @@
 //
 //===--===//
 
-#include "clang/Lex/Lexer.h"
-#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Attr.h"
 #include "clang/AST/ParentMap.h"
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/Analysis/Analyses/LiveVariables.h"
+#include "clang/Lex/Lexer.h"
+#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
 #include "clang/StaticAnalyzer/Core/Checker.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
 #include "llvm/ADT/BitVector.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/SaveAndRestore.h"
 
@@ -415,8 +416,2

[PATCH] D97361: [clang-tidy] Add readability-redundant-using check

2021-03-29 Thread Yang Fan via Phabricator via cfe-commits
nullptr.cpp added a comment.

In D97361#2609616 , @nullptr.cpp wrote:

> - Restrict to only run on C++ code
> - Ignore `using` defined in macro
> - Support inline namespace
> - Support global namespace

Ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97361

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


[PATCH] D99260: [analyzer] Fix false positives in inner pointer checker (PR49628)

2021-03-29 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added a comment.

In D99260#2650201 , @steakhal wrote:

> I recommend splitting this into two. I would happily accept the part about 
> `std::data()`.
>
> IMO `std::addressof()` should be modelled via `evalCall` as a pure function, 
> instead of hacking it into the `InnerPtrChecker`.

It does make sense to split these in two, but I'm not so sure about `evalCall`. 
 It is definitely not something that `InnerPtrChecker` should be bothered with. 
 Another point is that `std::addressof` might be only one of the function 
receiving a non-const reference and not modifying it, so it would
be nice to have a place in this checker where such exception is made.

> It is overloaded to accept `const T&` as well, so the comment about 
> //"std::addressof function accepts a non-const reference as an argument"// is 
> not entirely true.

But it has a `T &` overload as well, and this is the one causing the FP.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99260

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


[PATCH] D95460: [flang][driver] Add forced form flags and -ffixed-line-length

2021-03-29 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added a comment.

Hi @protze.joachim ,

Interestingly, GCC does not _error_  when using `gfortran` flags:

  $ gcc -ffree-form file.c
  cc1: warning: command line option ‘-ffree-form’ is valid for Fortran but not 
for C

I've implemented similar behavior for Clang in https://reviews.llvm.org/D99353. 
Please, could you take a look and see whether that solves your problem?

-Andrzej


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95460

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


[PATCH] D99320: [RISCV] [1/2] Add intrinsic for Zbb extension

2021-03-29 Thread LevyHsu via Phabricator via cfe-commits
LevyHsu updated this revision to Diff 333798.
LevyHsu added a comment.

1. Generated with git format-patch -o patches/ -2 HEAD -U99
2. clang/lib/Sema/SemaChecking.cpp
  - Rewrote CheckRISCVBuiltinFunctionCall
3. clang/lib/CodeGen/CGBuiltin.cpp
  - IntrinsicTypes = {ResultType};
4. llvm/include/llvm/IR/IntrinsicsRISCV.td
  - The second llvm_any_ty has been changed to LLVMMatchType<0>
5. clang/lib/Headers/riscv_zbb_intrin.h
  - Added corresponding 32/64 orcb
6. llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  - ANY_EXTEND both op0 and op 0 then truncate back to i32 when orc32b under 
RV64
7. llvm/test/CodeGen/RISCV/rv32zbb-intrinsic.ll 
llvm/test/CodeGen/RISCV/rv64zbb-intrinsic.ll 
clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb.c 
clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbb.c
  - Added corresponding testcases.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99320

Files:
  clang/include/clang/Basic/BuiltinsRISCV.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbb.c
  llvm/include/llvm/IR/IntrinsicsRISCV.td
  llvm/lib/Target/RISCV/RISCVISelLowering.cpp
  llvm/lib/Target/RISCV/RISCVInstrInfo.td
  llvm/lib/Target/RISCV/RISCVInstrInfoB.td
  llvm/test/CodeGen/RISCV/rv32zbb-intrinsic.ll
  llvm/test/CodeGen/RISCV/rv64zbb-intrinsic.ll

Index: llvm/test/CodeGen/RISCV/rv64zbb-intrinsic.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/rv64zbb-intrinsic.ll
@@ -0,0 +1,37 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv64 -mattr=+experimental-b -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s -check-prefix=RV64IB
+; RUN: llc -mtriple=riscv64 -mattr=+experimental-zbb -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s -check-prefix=RV64IBB
+
+declare i32 @llvm.riscv.orc.b.i32(i32)
+
+define i32 @orcb32(i32 %a) nounwind {
+; RV64IB-LABEL: orcb32:
+; RV64IB:   # %bb.0:
+; RV64IB-NEXT:orc.b a0, a0
+; RV64IB-NEXT:ret
+;
+; RV64IBB-LABEL: orcb32:
+; RV64IBB:   # %bb.0:
+; RV64IBB-NEXT:orc.b a0, a0
+; RV64IBB-NEXT:ret
+  %tmp = call i32 @llvm.riscv.orc.b.i32(i32 %a)
+ ret i32 %tmp
+}
+
+declare i64 @llvm.riscv.orc.b.i64(i64)
+
+define i64 @orcb64(i64 %a) nounwind {
+; RV64IB-LABEL: orcb64:
+; RV64IB:   # %bb.0:
+; RV64IB-NEXT:orc.b a0, a0
+; RV64IB-NEXT:ret
+;
+; RV64IBB-LABEL: orcb64:
+; RV64IBB:   # %bb.0:
+; RV64IBB-NEXT:orc.b a0, a0
+; RV64IBB-NEXT:ret
+  %tmp = call i64 @llvm.riscv.orc.b.i64(i64 %a)
+ ret i64 %tmp
+}
Index: llvm/test/CodeGen/RISCV/rv32zbb-intrinsic.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/rv32zbb-intrinsic.ll
@@ -0,0 +1,21 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-b -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s -check-prefix=RV32IB
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbb -verify-machineinstrs < %s \
+; RUN:   | FileCheck %s -check-prefix=RV32IBB
+
+declare i32 @llvm.riscv.orc.b.i32(i32)
+
+define i32 @orcb(i32 %a) nounwind {
+; RV32IB-LABEL: orcb:
+; RV32IB:   # %bb.0:
+; RV32IB-NEXT:orc.b a0, a0
+; RV32IB-NEXT:ret
+;
+; RV32IBB-LABEL: orcb:
+; RV32IBB:   # %bb.0:
+; RV32IBB-NEXT:orc.b a0, a0
+; RV32IBB-NEXT:ret
+  %tmp = call i32 @llvm.riscv.orc.b.i32(i32 %a)
+ ret i32 %tmp
+}
Index: llvm/lib/Target/RISCV/RISCVInstrInfoB.td
===
--- llvm/lib/Target/RISCV/RISCVInstrInfoB.td
+++ llvm/lib/Target/RISCV/RISCVInstrInfoB.td
@@ -897,3 +897,7 @@
(srl (and GPR:$rs1, 0x), (i64 16,
   (PACKUW GPR:$rs1, GPR:$rs2)>;
 } // Predicates = [HasStdExtZbp, IsRV64]
+
+let Predicates = [HasStdExtZbb] in {
+def : PatGpr;
+} // Predicates = [HasStdExtZbb]
Index: llvm/lib/Target/RISCV/RISCVInstrInfo.td
===
--- llvm/lib/Target/RISCV/RISCVInstrInfo.td
+++ llvm/lib/Target/RISCV/RISCVInstrInfo.td
@@ -831,6 +831,8 @@
 
 /// Generic pattern classes
 
+class PatGpr
+: Pat<(OpNode GPR:$rs1), (Inst GPR:$rs1)>;
 class PatGprGpr
 : Pat<(OpNode GPR:$rs1, GPR:$rs2), (Inst GPR:$rs1, GPR:$rs2)>;
 class PatGprSimm12
Index: llvm/lib/Target/RISCV/RISCVISelLowering.cpp
===
--- llvm/lib/Target/RISCV/RISCVISelLowering.cpp
+++ llvm/lib/Target/RISCV/RISCVISelLowering.cpp
@@ -198,6 +198,9 @@
 setOperationAction(ISD::SIGN_EXTEND_INREG, MVT::i16, Expand);
   }
 
+  if (Subtarget.hasStdExtZbb() && Subtarget.is64Bit())
+setOperationAction(ISD::INTRINSIC_WO_CHAI

[PATCH] D99152: [AMX] Prototype for vector and amx bitcast.

2021-03-29 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a comment.

In D99152#2649520 , @LuoYuanke wrote:

> In D99152#2647681 , @fhahn wrote:
>
>> I can't see any `load <256 x i32>` in the linked example, just a store. 
>> Could you check the example?
>
> I create another example at https://gcc.godbolt.org/z/v6od5ceEz. In bar() 
> function, you can see the `load <256 x i32>*` in the IR. The bar() function 
> is actually buggy code, because tilec is not initialized by amx intrinsics. 
> We want user call amx intrinsic to load/store tile explicitly. Ideally 
> front-end can detect the issue and report error.

Thanks AFAIK in those cases the conversion intrinsic makes sense to use, 
because you effectively need to convert between 2 types in a non-trivial way. 
@lebedev.ri WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99152

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


[PATCH] D99319: [RISCV] [2/2] Add intrinsic for Zbb extension

2021-03-29 Thread LevyHsu via Phabricator via cfe-commits
LevyHsu updated this revision to Diff 333801.
LevyHsu added a comment.

1. Generated with git format-patch -o patches/ -2 HEAD -U99
2. clang/lib/Headers/riscv_zbb_intrin.h
  - Added corresponding 32/64 orcb intrinsic
  - include error message when user include this file directly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99319

Files:
  clang-tools-extra/clang-include-fixer/find-all-symbols/STLPostfixHeaderMap.cpp
  clang-tools-extra/clangd/index/CanonicalIncludes.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/riscv_zbb_intrin.h
  clang/lib/Headers/rvintrin.h
  clang/test/Headers/rvintrin.c

Index: clang/test/Headers/rvintrin.c
===
--- /dev/null
+++ clang/test/Headers/rvintrin.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple riscv32 -fsyntax-only \
+// RUN:   -target-feature +experimental-zbb %s
+// RUN: %clang_cc1 -triple riscv64 -fsyntax-only \
+// RUN:   -target-feature +experimental-zbb %s
+
+#include 
Index: clang/lib/Headers/rvintrin.h
===
--- /dev/null
+++ clang/lib/Headers/rvintrin.h
@@ -0,0 +1,28 @@
+/* === rvintrin.h --===
+ *
+ * Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+ * See https://llvm.org/LICENSE.txt for license information.
+ * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+ *
+ *===---===
+ */
+
+#ifndef __RVINTRIN_H
+#define __RVINTRIN_H
+
+// Long is 32 bit on riscv32 and 64 bit on riscv64 according to calling 
+// convention.
+#define int_xlen_t long
+#define uint_xlen_t unsigned int_xlen_t
+
+#define __DEFAULT_FN_ATTRS \
+  __attribute__((__always_inline__, __artificial__, __nodebug__))
+
+#if defined(__riscv_zbb)
+#include "riscv_zbb_intrin.h"
+#endif
+
+#undef __DEFAULT_FN_ATTRS
+#undef uint_xlen_t
+#undef int_xlen_t
+#endif // __RVINTRIN_H
Index: clang/lib/Headers/riscv_zbb_intrin.h
===
--- /dev/null
+++ clang/lib/Headers/riscv_zbb_intrin.h
@@ -0,0 +1,40 @@
+/* === riscv_zbb_intrin.h --===
+ *
+ * Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+ * See https://llvm.org/LICENSE.txt for license information.
+ * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+ *
+ *===---===
+ */
+
+#ifndef __RVINTRIN_H  
+#error "Never use  directly; include  instead."
+#endif
+
+#ifndef __RISCV_ZBB_INTRIN_H
+#define __RISCV_ZBB_INTRIN_H
+
+#include 
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+// Zbb
+static __inline__ int_xlen_t __DEFAULT_FN_ATTRS _rv_orc_b(int_xlen_t rs1) {
+  return __builtin_riscv_orc_b(rs1);
+}
+
+static __inline__ int32_t __DEFAULT_FN_ATTRS _rv32_orc_b(int32_t rs1) {
+  return __builtin_riscv32_orc_b(rs1);
+}
+
+static __inline__ int64_t __DEFAULT_FN_ATTRS _rv64_orc_b(int64_t rs1) {
+  return __builtin_riscv64_orc_b(rs1);
+}
+
+#if defined(__cplusplus)
+}
+#endif // if defined(__cplusplus)
+
+#endif // __RISCV_ZBB_INTRIN_H
Index: clang/lib/Headers/CMakeLists.txt
===
--- clang/lib/Headers/CMakeLists.txt
+++ clang/lib/Headers/CMakeLists.txt
@@ -97,6 +97,8 @@
   ptwriteintrin.h
   rdseedintrin.h
   rtmintrin.h
+  rvintrin.h
+  riscv_zbb_intrin.h
   serializeintrin.h
   sgxintrin.h
   s390intrin.h
Index: clang-tools-extra/clangd/index/CanonicalIncludes.cpp
===
--- clang-tools-extra/clangd/index/CanonicalIncludes.cpp
+++ clang-tools-extra/clangd/index/CanonicalIncludes.cpp
@@ -152,6 +152,8 @@
   {"include/prfchwintrin.h", ""},
   {"include/rdseedintrin.h", ""},
   {"include/rtmintrin.h", ""},
+  {"include/rvintrin.h", ""},
+  {"include/riscv_zbb_intrin.h", ""},
   {"include/shaintrin.h", ""},
   {"include/smmintrin.h", ""},
   {"include/stdalign.h", ""},
Index: clang-tools-extra/clang-include-fixer/find-all-symbols/STLPostfixHeaderMap.cpp

[PATCH] D99152: [AMX] Prototype for vector and amx bitcast.

2021-03-29 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In D99152#2655274 , @fhahn wrote:

> In D99152#2649520 , @LuoYuanke wrote:
>
>> In D99152#2647681 , @fhahn wrote:
>>
>>> I can't see any `load <256 x i32>` in the linked example, just a store. 
>>> Could you check the example?
>>
>> I create another example at https://gcc.godbolt.org/z/v6od5ceEz. In bar() 
>> function, you can see the `load <256 x i32>*` in the IR. The bar() function 
>> is actually buggy code, because tilec is not initialized by amx intrinsics. 
>> We want user call amx intrinsic to load/store tile explicitly. Ideally 
>> front-end can detect the issue and report error.
>
> Thanks AFAIK in those cases the conversion intrinsic makes sense to use, 
> because you effectively need to convert between 2 types in a non-trivial way. 
> @lebedev.ri WDYT?

I'm not sure. I think first and foremost the `load`/`store` miscompile should 
be addressed.
I think the rest is confusing because it seems to me that the only reason why 
that `bitcast`
is needed is not correctness reason, but as an opaque optimization barrier.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99152

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


[PATCH] D99488: [SYCL][Doc] Add address space handling section to SYCL documentation

2021-03-29 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

Thanks. I am guessing you will address relevant review comments from D99190 
 in here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99488

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


[PATCH] D98616: [RISCV] Add inline asm constraint 'v' in Clang for RISC-V 'V'.

2021-03-29 Thread Hsiangkai Wang via Phabricator via cfe-commits
HsiangKai updated this revision to Diff 333806.
HsiangKai added a comment.

Use 'vr' for vector registers and 'vm' for vector mask registers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98616

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Basic/Targets/RISCV.h
  clang/test/CodeGen/RISCV/riscv-inline-asm-rvv.c

Index: clang/test/CodeGen/RISCV/riscv-inline-asm-rvv.c
===
--- /dev/null
+++ clang/test/CodeGen/RISCV/riscv-inline-asm-rvv.c
@@ -0,0 +1,36 @@
+// RUN: %clang_cc1 -triple riscv32 -target-feature +experimental-v \
+// RUN: -O2 -emit-llvm %s -o - \
+// RUN: | FileCheck %s
+// RUN: %clang_cc1 -triple riscv64 -target-feature +experimental-v \
+// RUN: -O2 -emit-llvm %s -o - \
+// RUN: | FileCheck %s
+
+// Test RISC-V V-extension specific inline assembly constraints.
+#include 
+
+void test_v_reg() {
+  asm volatile(
+  "vsetvli x1, x0, e32,m2,tu,mu\n"
+  "vadd.vv v1, v2, v3, v0.t"
+  :
+  :
+  : "v1", "x1");
+// CHECK-LABEL: define{{.*}} @test_v_reg
+// CHECK: "~{v1},~{x1}"
+}
+
+vint32m1_t test_vr(vint32m1_t a, vint32m1_t b) {
+// CHECK-LABEL: define{{.*}} @test_vr
+// CHECK: %0 = tail call  asm sideeffect "vadd.vv $0, $1, $2", "=v,v,v"( %a,  %b)
+  vint32m1_t ret;
+  asm volatile ("vadd.vv %0, %1, %2" : "=vr"(ret) : "vr"(a), "vr"(b));
+  return ret;
+}
+
+vbool1_t test_vm(vbool1_t a, vbool1_t b) {
+// CHECK-LABEL: define{{.*}} @test_vm
+// CHECK: %0 = tail call  asm sideeffect "vmand.mm $0, $1, $2", "=v,v,v"( %a,  %b)
+  vbool1_t ret;
+  asm volatile ("vmand.mm %0, %1, %2" : "=vm"(ret) : "vm"(a), "vm"(b));
+  return ret;
+}
Index: clang/lib/Basic/Targets/RISCV.h
===
--- clang/lib/Basic/Targets/RISCV.h
+++ clang/lib/Basic/Targets/RISCV.h
@@ -97,6 +97,8 @@
   bool validateAsmConstraint(const char *&Name,
  TargetInfo::ConstraintInfo &Info) const override;
 
+  std::string convertConstraint(const char *&Constraint) const override;
+
   bool hasFeature(StringRef Feature) const override;
 
   bool handleTargetFeatures(std::vector &Features,
Index: clang/lib/Basic/Targets/RISCV.cpp
===
--- clang/lib/Basic/Targets/RISCV.cpp
+++ clang/lib/Basic/Targets/RISCV.cpp
@@ -31,7 +31,13 @@
   "f0",  "f1",  "f2",  "f3",  "f4",  "f5",  "f6",  "f7",
   "f8",  "f9",  "f10", "f11", "f12", "f13", "f14", "f15",
   "f16", "f17", "f18", "f19", "f20", "f21", "f22", "f23",
-  "f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31"};
+  "f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31",
+
+  // Vector registers
+  "v0",  "v1",  "v2",  "v3",  "v4",  "v5",  "v6",  "v7",
+  "v8",  "v9",  "v10", "v11", "v12", "v13", "v14", "v15",
+  "v16", "v17", "v18", "v19", "v20", "v21", "v22", "v23",
+  "v24", "v25", "v26", "v27", "v28", "v29", "v30", "v31"};
   return llvm::makeArrayRef(GCCRegNames);
 }
 
@@ -81,7 +87,29 @@
 // An address that is held in a general-purpose register.
 Info.setAllowsMemory();
 return true;
+  case 'v':
+// A vector register.
+if (Name[1] == 'r' || Name[1] == 'm') {
+  Info.setAllowsRegister();
+  Name += 1;
+  return true;
+}
+return false;
+  }
+}
+
+std::string RISCVTargetInfo::convertConstraint(const char *&Constraint) const {
+  std::string R;
+  switch (*Constraint) {
+  case 'v':
+R = std::string("v");
+Constraint += 1;
+break;
+  default:
+R = TargetInfo::convertConstraint(Constraint);
+break;
   }
+  return R;
 }
 
 void RISCVTargetInfo::getTargetDefines(const LangOptions &Opts,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99292: [flang][driver] Add support for `-cpp/-nocpp`

2021-03-29 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski updated this revision to Diff 333807.
awarzynski added a comment.

Address PR comments + updated comments + rebase

I refined some comments and added `-fpp` to the list of file extensions. Thank 
you @kiranchandramohan for pointing this out!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99292

Files:
  clang/include/clang/Driver/Options.td
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/include/flang/Frontend/FrontendOptions.h
  flang/include/flang/Frontend/PreprocessorOptions.h
  flang/lib/Frontend/CompilerInstance.cpp
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendAction.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/Frontend/FrontendOptions.cpp
  flang/test/Driver/cpp_nocpp.F90
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/predefined-macros-compiler-version.F90
  flang/test/Driver/predefined-macros-compiler-version.f90

Index: flang/test/Driver/predefined-macros-compiler-version.f90
===
--- /dev/null
+++ flang/test/Driver/predefined-macros-compiler-version.f90
@@ -1,26 +0,0 @@
-! Check that the driver correctly defines macros with the compiler version
-
-! REQUIRES: new-flang-driver
-
-!--
-! FLANG DRIVER (flang-new)
-!--
-! RUN: %flang-new -E %s  2>&1 | FileCheck %s --ignore-case
-
-!-
-! FRONTEND FLANG DRIVER (flang-new -fc1)
-!-
-! RUN: %flang-new -fc1 -E %s  2>&1 | FileCheck %s --ignore-case
-
-!-
-! EXPECTED OUTPUT
-!-
-! CHECK: flang = 1
-! CHECK: flang_major = {{[1-9][0-9]*$}}
-! CHECK: flang_minor = {{[0-9]+$}}
-! CHECK: flang_patchlevel = {{[0-9]+$}}
-
-integer, parameter :: flang = __flang__
-integer, parameter :: flang_major = __flang_major__
-integer, parameter :: flang_minor = __flang_minor__
-integer, parameter :: flang_patchlevel = __flang_patchlevel__
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -19,6 +19,7 @@
 ! HELP-EMPTY:
 ! HELP-NEXT:OPTIONS:
 ! HELP-NEXT: -###   Print (but do not run) the commands to run for this compilation
+! HELP-NEXT: -cpp   Always add standard macro predefinitions
 ! HELP-NEXT: -c Only run preprocess, compile, and assemble steps
 ! HELP-NEXT: -D = Define  to  (or 1 if  omitted)
 ! HELP-NEXT: -E Only run the preprocessor
@@ -46,6 +47,7 @@
 ! HELP-NEXT: -help  Display available options
 ! HELP-NEXT: -IAdd directory to the end of the list of include search paths
 ! HELP-NEXT: -module-dir   Put MODULE files in 
+! HELP-NEXT: -nocpp Never add standard macro predefinitions
 ! HELP-NEXT: -o   Write output to 
 ! HELP-NEXT: -pedantic  Warn on language extensions
 ! HELP-NEXT: -std=   Language standard to compile for
@@ -59,6 +61,7 @@
 ! HELP-FC1:USAGE: flang-new
 ! HELP-FC1-EMPTY:
 ! HELP-FC1-NEXT:OPTIONS:
+! HELP-FC1-NEXT: -cpp   Always add standard macro predefinitions
 ! HELP-FC1-NEXT: -D = Define  to  (or 1 if  omitted)
 ! HELP-FC1-NEXT: -emit-obj Emit native object files
 ! HELP-FC1-NEXT: -E Only run the preprocessor
@@ -97,6 +100,7 @@
 ! HELP-FC1-NEXT: -help  Display available options
 ! HELP-FC1-NEXT: -IAdd directory to the end of the list of include search paths
 ! HELP-FC1-NEXT: -module-dir   Put MODULE files in 
+! HELP-FC1-NEXT: -nocpp Never add standard macro predefinitions
 ! HELP-FC1-NEXT: -o   Write output to 
 ! HELP-FC1-NEXT: -pedantic  Warn on language extensions
 ! HELP-FC1-NEXT: -std=   Language standard to compile for
Index: flang/test/Driver/driver-help-hidden.f90
===
--- flang/test/Driver/driver-help-hidden.f90
+++ flang/test/Driver/driver-help-hidden.f90
@@ -19,6 +19,7 @@
 ! CHECK-EMPTY:
 ! CHECK-NEXT:OPTIONS:
 ! CHECK-NEXT: -###  Print (but do not run) the commands to run for this compilation
+! CHECK-NEXT: -cpp  Always add standard macro predefinitions
 ! CHECK-NEXT: -cOnly run preprocess, compile, and assemble steps
 ! CHECK-NEXT: -D = Define  to  (or 1 if  omitted)
 ! CHECK-NEXT: -EOnly run the preprocessor
@@ -46,6 +47,7 @@
 ! CHECK-NEXT: -help Display available options
 ! CHECK-NEXT: -IAdd directory to the end of the list of include search paths
 ! CHECK-NEXT: -module-dir   Put MODULE files in 
+! CHECK-NEXT: -nocpp Never add standard macro predefinitions
 ! CHECK-NEXT: -o  Wr

[PATCH] D98146: OpaquePtr: Turn inalloca into a type attribute

2021-03-29 Thread Oliver Stannard (Linaro) via Phabricator via cfe-commits
ostannard added a comment.

I've reverted this (07e46367bae 
) because 
it was causing Bindings/Go/go.test to fail on the buoldbots. Example failure at 
http://lab.llvm.org:8011/#/builders/107/builds/6075.


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

https://reviews.llvm.org/D98146

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


[PATCH] D99488: [SYCL][Doc] Add address space handling section to SYCL documentation

2021-03-29 Thread Alexey Bader via Phabricator via cfe-commits
bader added a comment.

In D99488#2655326 , @Anastasia wrote:

> Thanks. I am guessing you will address relevant review comments from D99190 
>  in here?

Yes. I'm working on it. I wanted to make it in a separate update, so it should 
be easy to see what has changed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99488

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


[PATCH] D99488: [SYCL][Doc] Add address space handling section to SYCL documentation

2021-03-29 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

In D99488#2655342 , @bader wrote:

> In D99488#2655326 , @Anastasia wrote:
>
>> Thanks. I am guessing you will address relevant review comments from D99190 
>>  in here?
>
> Yes. I'm working on it. I wanted to make it in a separate update, so it 
> should be easy to see what has changed.

Great! Makes sense.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99488

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


[PATCH] D99152: [AMX] Prototype for vector and amx bitcast.

2021-03-29 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a comment.

In D99152#2655304 , @lebedev.ri wrote:

> In D99152#2655274 , @fhahn wrote:
>
>> In D99152#2649520 , @LuoYuanke 
>> wrote:
>>
>>> In D99152#2647681 , @fhahn wrote:
>>>
 I can't see any `load <256 x i32>` in the linked example, just a store. 
 Could you check the example?
>>>
>>> I create another example at https://gcc.godbolt.org/z/v6od5ceEz. In bar() 
>>> function, you can see the `load <256 x i32>*` in the IR. The bar() function 
>>> is actually buggy code, because tilec is not initialized by amx intrinsics. 
>>> We want user call amx intrinsic to load/store tile explicitly. Ideally 
>>> front-end can detect the issue and report error.
>>
>> Thanks AFAIK in those cases the conversion intrinsic makes sense to use, 
>> because you effectively need to convert between 2 types in a non-trivial 
>> way. @lebedev.ri WDYT?
>
> I'm not sure. I think first and foremost the `load`/`store` miscompile should 
> be addressed.
> I think the rest is confusing because it seems to me that the only reason why 
> that `bitcast`
> is needed is not correctness reason, but as an opaque optimization barrier.

I'm not sure if the loads and store are actually incorrect. `_tile1024i ` is 
defined as `typedef int _tile1024i __attribute__((__vector_size__(1024), 
__aligned__(64)));` and the loads/stores are for assignments/reads from 
variables that have that type, which is `<256 x i32>` in IR. So it is not 
obvious to me why the loads/stores would be wrong, as long as `_tile1024i` is 
defined as it is (if it would be a different type, that all changes).

As a consequence,  `__builtin_ia32_tilezero_internal` & the other builtins need 
to be defined as returning  `_tile1024i` / `<256 x i32>`. I don't think there's 
any other way to specify this, unless you have a dedicated AMX type in the 
frontend. IIUC the current lowering is to call an intrinsic that returns 
`x86_amx` and then a `bitcast` is used for the conversion to the result type 
`<256 x i32>`, with the (incorrect) assumption that the `bitcast` does complex 
conversion between types. Another consequence of the builtins returning 
`_tile1024i` / `<256 x i32>` is that the conversion from the intrinsic result 
to `<256 x i32>` should happen at the place where Clang emits the call to the 
intrinsic directly, not patched up later as it is done now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99152

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


[PATCH] D99152: [AMX] Prototype for vector and amx bitcast.

2021-03-29 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In D99152#2655357 , @fhahn wrote:

> In D99152#2655304 , @lebedev.ri 
> wrote:
>
>> In D99152#2655274 , @fhahn wrote:
>>
>>> In D99152#2649520 , @LuoYuanke 
>>> wrote:
>>>
 In D99152#2647681 , @fhahn wrote:

> I can't see any `load <256 x i32>` in the linked example, just a store. 
> Could you check the example?

 I create another example at https://gcc.godbolt.org/z/v6od5ceEz. In bar() 
 function, you can see the `load <256 x i32>*` in the IR. The bar() 
 function is actually buggy code, because tilec is not initialized by amx 
 intrinsics. We want user call amx intrinsic to load/store tile explicitly. 
 Ideally front-end can detect the issue and report error.
>>>
>>> Thanks AFAIK in those cases the conversion intrinsic makes sense to use, 
>>> because you effectively need to convert between 2 types in a non-trivial 
>>> way. @lebedev.ri WDYT?
>>
>> I'm not sure. I think first and foremost the `load`/`store` miscompile 
>> should be addressed.
>> I think the rest is confusing because it seems to me that the only reason 
>> why that `bitcast`
>> is needed is not correctness reason, but as an opaque optimization barrier.
>
> I'm not sure if the loads and store are actually incorrect. `_tile1024i ` is 
> defined as `typedef int _tile1024i __attribute__((__vector_size__(1024), 
> __aligned__(64)));` and the loads/stores are for assignments/reads from 
> variables that have that type, which is `<256 x i32>` in IR. So it is not 
> obvious to me why the loads/stores would be wrong, as long as `_tile1024i` is 
> defined as it is (if it would be a different type, that all changes).

Didn't @LuoYuanke state:

In D99152#2643821 , @LuoYuanke wrote:

> @lebedev.ri, this patch is mainly for discussing the approach that Florian 
> proposed, so I didn't polish my code. Nevertheless your comments for 
> amx_cast.c is right. For __tile_loadd() is to load a 2d tile from memory. 
> There is an extra parameter stride. As I explain in llvm-dev, it load each 
> row from memory to tile register and then base += stride. So the data is not 
> contiguous in memory.

Note the `So the data is not contiguous in memory.`.
I.e. we won't actually store to `i8* [ptr + 0, ptr + 4096)` byte area.
Is plain `load`/`store` not defined to perform operations on contigious chunks 
of memory?
Am i completely missing the point?

> As a consequence,  `__builtin_ia32_tilezero_internal` & the other builtins 
> need to be defined as returning  `_tile1024i` / `<256 x i32>`. I don't think 
> there's any other way to specify this, unless you have a dedicated AMX type 
> in the frontend. IIUC the current lowering is to call an intrinsic that 
> returns `x86_amx` and then a `bitcast` is used for the conversion to the 
> result type `<256 x i32>`, with the (incorrect) assumption that the `bitcast` 
> does complex conversion between types. Another consequence of the builtins 
> returning `_tile1024i` / `<256 x i32>` is that the conversion from the 
> intrinsic result to `<256 x i32>` should happen at the place where Clang 
> emits the call to the intrinsic directly, not patched up later as it is done 
> now.

/`store`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99152

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


[PATCH] D99484: Use `GNUInstallDirs` to support custom installation dirs.

2021-03-29 Thread John Ericson via Phabricator via cfe-commits
Ericson2314 created this revision.
Herald added subscribers: libc-commits, libcxx-commits, dcaballe, cota, 
teijeong, rdzhabarov, tatianashp, msifontes, jurahul, Kayjukh, grosul1, 
Joonsoo, kerbowa, liufengdb, aartbik, lucyrfox, mgester, arpith-jacob, csigg, 
antiagainst, shauheen, rriddle, mehdi_amini, arphaman, steven_wu, hiraditya, 
mgorny, nhaehnle, jvesely.
Herald added a reviewer: bollu.
Herald added a reviewer: ldionne.
Herald added a reviewer: sscalpone.
Herald added a reviewer: awarzynski.
Herald added projects: libunwind, libc-project.
Herald added a reviewer: libunwind.
Ericson2314 requested review of this revision.
Herald added subscribers: llvm-commits, openmp-commits, lldb-commits, 
Sanitizers, cfe-commits, stephenneuendorffer, nicolasvasilache.
Herald added projects: clang, Sanitizers, LLDB, libc++, OpenMP, libc++abi, 
MLIR, LLVM, clang-tools-extra.
Herald added a reviewer: libc++.
Herald added a reviewer: libc++abi.

This is a new draft of D28234 . I previously 
did the unorthodox thing of
pushing to it when I wasn't the original author, but since this version

- Uses `GNUInstallDirs`, rather than mimics it, as the original author was 
hesitant to do but others requested.
- Is much broader, effecting many more projects than LLVM itself.

I figured it was time to make a new revision.

I am using this patch (and many back-ports) as the basis of
https://github.com/NixOS/nixpkgs/pull/111487 for my distro (NixOS). It
looked like people were generally on board in D28234 
, but I make note of
this here in case extra motivation is useful.

---

As pointed out in the original issue, a central tension is that LLVM
already has some partial support for these sorts of things. Sometimes
GNUInstallDirs alone is more expressive, but sometimes the existing
stuff is, e.g. with the "utils" vs "tools" distinction or perhaps when
everything is being built together.

Another related tension was that the GNUInstallDirs variables may be
relative `CMAKE_INSTALL_PREFIX` *or* absolute paths that need not lead
within that directory. We in fact do the common case in Nixpkgs (and in
my PR), where the package and "-dev" package data (analogizing from
conventional distros) are installed in separate prefixes. Supporting
this fall range of the GNU variables means this patch can't always be a
simple "find and replace" of `bin/`, `lib/`, `include/`, etc., as we
sometimes need to get clever where a leading `CMAKE_INSTALL_PREFIX` was
previously mandatory.

I am not a frequent LLVM contributor, so I didn't want to broach the
topic of removing functionality / breaking changes, so I instead
implemented GNUInstallDirs along side the existing stuff. Existing
custom install dirs are derived from the GNUInstallDirs ones by default,
but may be separately sepcified. Existing prefixes come before
`CMAKE_CONFIGURE_PREFIX`. In a few cases that was a small breaking
change when the default per-project prefix was itself
`CMAKE_CONFIGURE_PREFIX` rather than the empty string, but the majority
aready had the empty string default.

I do think it would be wise for others to remove some of the old install
dir mechanisms, as the LLVM CMake is already quite complex, but I would
strongly prefer to leave that to others who are more familiar with the
project and its main users' needs re compat vs features of the build
system.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99484

Files:
  clang-tools-extra/clang-doc/tool/CMakeLists.txt
  clang-tools-extra/clang-include-fixer/find-all-symbols/tool/CMakeLists.txt
  clang-tools-extra/clang-include-fixer/tool/CMakeLists.txt
  clang-tools-extra/clang-tidy/CMakeLists.txt
  clang-tools-extra/clang-tidy/tool/CMakeLists.txt
  clang-tools-extra/modularize/CMakeLists.txt
  clang/CMakeLists.txt
  clang/cmake/modules/AddClang.cmake
  clang/lib/Headers/CMakeLists.txt
  clang/tools/c-index-test/CMakeLists.txt
  clang/tools/clang-format/CMakeLists.txt
  clang/tools/clang-rename/CMakeLists.txt
  clang/tools/libclang/CMakeLists.txt
  clang/tools/scan-build/CMakeLists.txt
  clang/tools/scan-view/CMakeLists.txt
  clang/utils/hmaptool/CMakeLists.txt
  compiler-rt/CMakeLists.txt
  compiler-rt/cmake/Modules/AddCompilerRT.cmake
  compiler-rt/cmake/Modules/CompilerRTDarwinUtils.cmake
  compiler-rt/cmake/Modules/CompilerRTUtils.cmake
  compiler-rt/cmake/base-config-ix.cmake
  compiler-rt/include/CMakeLists.txt
  compiler-rt/lib/dfsan/CMakeLists.txt
  flang/CMakeLists.txt
  flang/cmake/modules/AddFlang.cmake
  flang/tools/f18/CMakeLists.txt
  flang/tools/flang-driver/CMakeLists.txt
  libc/CMakeLists.txt
  libc/lib/CMakeLists.txt
  libcxx/CMakeLists.txt
  libcxx/cmake/Modules/HandleLibCXXABI.cmake
  libcxx/include/CMakeLists.txt
  libcxx/src/CMakeLists.txt
  libcxxabi/CMakeLists.txt
  libunwind/CMakeLists.txt
  libunwind/src/CMakeLists.txt
  lld/CMakeLists.txt
  lld/cmake/modules/AddLLD.cmake
  lld/tools/lld/CMakeLists.txt
  lldb/CMakeLists.txt
  

[PATCH] D99484: Use `GNUInstallDirs` to support custom installation dirs.

2021-03-29 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

Thank you!
The changes here look about reasonable to me.
I have not checked if there are some changes that were missed.
Usage of `CMAKE_INSTALL_FULL_` is suspect to me. Are you sure those are correct?




Comment at: compiler-rt/cmake/Modules/AddCompilerRT.cmake:513
   install(FILES ${file_name}
-DESTINATION ${COMPILER_RT_INSTALL_PATH}/share
+DESTINATION ${COMPILER_RT_INSTALL_PATH}/${CMAKE_INSTALL_FULL_INCLUDEDIR}
 COMPONENT ${component})

This looks suspect



Comment at: compiler-rt/cmake/Modules/AddCompilerRT.cmake:530
 PERMISSIONS OWNER_READ OWNER_WRITE OWNER_EXECUTE GROUP_READ GROUP_EXECUTE 
WORLD_READ WORLD_EXECUTE
-DESTINATION ${COMPILER_RT_INSTALL_PATH}/bin)
+DESTINATION ${COMPILER_RT_INSTALL_PATH}/${CMAKE_INSTALL_FULL_BINDIR})
 endmacro(add_compiler_rt_script src name)

This looks suspect



Comment at: compiler-rt/cmake/Modules/CompilerRTDarwinUtils.cmake:511
 set(DARWIN_macho_embedded_LIBRARY_INSTALL_DIR
-  ${COMPILER_RT_INSTALL_PATH}/lib/macho_embedded)
+  ${COMPILER_RT_INSTALL_PATH}/${CMAKE_INSTALL_FULL_LIBDIR}/macho_embedded)
   

This looks suspect



Comment at: compiler-rt/cmake/Modules/CompilerRTUtils.cmake:389
 get_compiler_rt_target(${arch} target)
-set(${install_dir} ${COMPILER_RT_INSTALL_PATH}/lib/${target} PARENT_SCOPE)
+set(${install_dir} 
${COMPILER_RT_INSTALL_PATH}/${CMAKE_INSTALL_FULL_LIBDIR}/${target} PARENT_SCOPE)
   else()

This looks suspect



Comment at: compiler-rt/cmake/base-config-ix.cmake:100
   set(COMPILER_RT_LIBRARY_INSTALL_DIR
-${COMPILER_RT_INSTALL_PATH}/lib/${COMPILER_RT_OS_DIR})
+
${COMPILER_RT_INSTALL_PATH}/${CMAKE_INSTALL_FULL_LIBDIR}/${COMPILER_RT_OS_DIR})
 endif()

This looks suspect



Comment at: compiler-rt/include/CMakeLists.txt:72-87
+  DESTINATION 
${COMPILER_RT_INSTALL_PATH}/${CMAKE_INSTALL_FULL_INCLUDEDIR}/sanitizer)
 # Install fuzzer headers.
 install(FILES ${FUZZER_HEADERS}
   COMPONENT compiler-rt-headers
   PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
-  DESTINATION ${COMPILER_RT_INSTALL_PATH}/include/fuzzer)
+  DESTINATION 
${COMPILER_RT_INSTALL_PATH}/${CMAKE_INSTALL_FULL_INCLUDEDIR}/fuzzer)
 # Install xray headers.

This looks suspect



Comment at: compiler-rt/lib/dfsan/CMakeLists.txt:64-65
 add_dependencies(dfsan dfsan_abilist)
 install(FILES ${dfsan_abilist_filename}
-DESTINATION ${COMPILER_RT_INSTALL_PATH}/share)
+DESTINATION ${COMPILER_RT_INSTALL_PATH}/${CMAKE_INSTALL_FULL_DATADIR})

This looks suspect



Comment at: polly/cmake/CMakeLists.txt:85
+set(POLLY_CONFIG_CMAKE_DIR 
"${POLLY_INSTALL_PREFIX}${CMAKE_INSTALL_PREFIX}/${POLLY_INSTALL_PACKAGE_DIR}")
+set(POLLY_CONFIG_LIBRARY_DIRS 
"${POLLY_INSTALL_PREFIX}${CMAKE_INSTALL_FULL_LIBDIR}${LLVM_LIBDIR_SUFFIX}")
 if (POLLY_BUNDLED_ISL)

This looks suspect


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99484

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


[PATCH] D93095: Introduce -Wreserved-identifier

2021-03-29 Thread serge via Phabricator via cfe-commits
serge-sans-paille updated this revision to Diff 333810.
serge-sans-paille added a comment.

Adress final(?) comments from @rsmith and @aaron.ballman :
Don't warn on argument (or template argument) of top-level decl.
Extra test cases
Return an enumeration as part of the test


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

https://reviews.llvm.org/D93095

Files:
  clang/include/clang/AST/Decl.h
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Decl.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/Sema/reserved-identifier.c
  clang/test/Sema/reserved-identifier.cpp

Index: clang/test/Sema/reserved-identifier.cpp
===
--- /dev/null
+++ clang/test/Sema/reserved-identifier.cpp
@@ -0,0 +1,87 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify -Wreserved-identifier %s
+
+int foo__bar() { return 0; }// expected-warning {{identifier 'foo__bar' is reserved because it contains '__'}}
+static int _bar() { return 0; } // expected-warning {{identifier '_bar' is reserved because it starts with '_' at global scope}}
+static int _Bar() { return 0; } // expected-warning {{identifier '_Bar' is reserved because it starts with '_' followed by a capital letter}}
+int _barbouille() { return 0; } // expected-warning {{identifier '_barbouille' is reserved because it starts with '_' at global scope}}
+
+void foo(unsigned int _Reserved) { // expected-warning {{identifier '_Reserved' is reserved because it starts with '_' followed by a capital letter}}
+  unsigned int __1 =   // expected-warning {{identifier '__1' is reserved because it starts with '__'}}
+  _Reserved;   // no-warning
+}
+
+// This one is explicitly skipped by -Wreserved-identifier
+void *_; // no-warning
+
+template  constexpr bool __toucan = true; // expected-warning {{identifier '__toucan' is reserved because it starts with '__'}}
+
+template 
+concept _Barbotine = __toucan; // expected-warning {{identifier '_Barbotine' is reserved because it starts with '_' followed by a capital letter}}
+
+template  // expected-warning {{'__' is reserved because it starts with '__'}}
+struct BarbeNoire {};
+
+template  // no-warning
+struct BarbeJaune {};
+
+template  // expected-warning {{'__' is reserved because it starts with '__'}}
+void BarbeRousse() {}
+
+namespace _Barbidur { // expected-warning {{identifier '_Barbidur' is reserved because it starts with '_' followed by a capital letter}}
+
+struct __barbidou {}; // expected-warning {{identifier '__barbidou' is reserved because it starts with '__'}}
+struct _barbidou {};  // no-warning
+
+int __barbouille; // expected-warning {{identifier '__barbouille' is reserved because it starts with '__'}}
+int _barbouille;  // no-warning
+
+int __babar() { return 0; } // expected-warning {{identifier '__babar' is reserved because it starts with '__'}}
+int _babar() { return 0; }  // no-warning
+
+} // namespace _Barbidur
+
+class __barbapapa { // expected-warning {{identifier '__barbapapa' is reserved because it starts with '__'}}
+  void _barbabelle() {} // no-warning
+  int _Barbalala;   // expected-warning {{identifier '_Barbalala' is reserved because it starts with '_' followed by a capital letter}}
+};
+
+enum class __menu { // expected-warning {{identifier '__menu' is reserved because it starts with '__'}}
+  __some,   // expected-warning {{identifier '__some' is reserved because it starts with '__'}}
+  _Other,   // expected-warning {{identifier '_Other' is reserved because it starts with '_' followed by a capital letter}}
+  _other// no-warning
+};
+
+enum _Menu { // expected-warning {{identifier '_Menu' is reserved because it starts with '_' followed by a capital letter}}
+  _OtheR_,   // expected-warning {{identifier '_OtheR_' is reserved because it starts with '_' followed by a capital letter}}
+  _other_// expected-warning {{identifier '_other_' is reserved because it starts with '_' at global scope}}
+};
+
+enum {
+  __some, // expected-warning {{identifier '__some' is reserved because it starts with '__'}}
+  _Other, // expected-warning {{identifier '_Other' is reserved because it starts with '_' followed by a capital letter}}
+  _other  // expected-warning {{identifier '_other' is reserved because it starts with '_' at global scope}}
+};
+
+static union {
+  int _barbeFleurie; // no-warning
+};
+
+using _Barbamama = __barbapapa; // expected-warning {{identifier '_Barbamama' is reserved because it starts with '_' followed by a capital letter}}
+
+int foobar() {
+  return foo__bar(); // no-warning
+}
+
+namespace {
+int _barbatruc; // no-warning
+}
+
+long double operator"" _BarbeBleue(long double) // expected-warning {{identifier 'operator""_BarbeBleue' is reserved beca

[PATCH] D93095: Introduce -Wreserved-identifier

2021-03-29 Thread serge via Phabricator via cfe-commits
serge-sans-paille marked 10 inline comments as done.
serge-sans-paille added inline comments.



Comment at: clang/include/clang/AST/Decl.h:82
+enum ReservedIdentifierReason {
+  StartsWithUnderscoreAtGlobalScope,
+  StartsWithDoubleUnderscore,

aaron.ballman wrote:
> Because this is not a scoped enum, should these enumerators get an `RIR_` 
> prefix added to them?
I used a class enum with a stream operator instead. Not a big fan of prefixed 
enum ;-)



Comment at: clang/test/Sema/reserved-identifier.c:53
+
+extern char *_strdup(const char *); // expected-warning {{'_strdup' is a 
reserved identifier}}
+

aaron.ballman wrote:
> rsmith wrote:
> > aaron.ballman wrote:
> > > This is a case I don't think we should warn on. As some examples showing 
> > > this sort of thing in the wild:
> > > 
> > > https://codesearch.isocpp.org/actcd19/main/m/mcrl2/mcrl2_201409.0-1/3rd-party/svc/source/lz.cpp
> > > https://codesearch.isocpp.org/actcd19/main/m/mcrl2/mcrl2_201409.0-1/3rd-party/svc/source/svc1.cpp
> > You mean, specifically for `_strdup`? In general, this looks exactly the 
> > like the kind of declaration we'd want to warn on. If we don't want a 
> > warning here, we could perhaps recognize `_strdup` as a builtin lib 
> > function. (I think they shouldn't warn, because we'll inject a builtin 
> > declaration, so this would be a redeclaration. We should test that!)
> > You mean, specifically for _strdup?
> 
> Yes, but it's a more general pattern than just `_strdup`. C code (esp older C 
> code) will sometimes add an external declaration to avoid having to use a 
> `#include` for just one symbol. Additionally, some popular platforms (like 
> Windows) add a bunch of functions in the implementation namespace like 
> `_strdup` (and many, many others).
> 
> Perhaps an option would be to always warn, and if we find that users run into 
> this situation a lot in practice, we could split the diagnostic so that users 
> can control whether to warn on forward declarations of functions.
yeah,that would require checking if the name with trailing underscores is a 
libc function. I agree we should wait for more user feedback to install such 
check. 


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

https://reviews.llvm.org/D93095

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


[PATCH] D99456: [C++2b] Support size_t literals

2021-03-29 Thread Anton Bikineev via Phabricator via cfe-commits
AntonBikineev updated this revision to Diff 333811.
AntonBikineev added a comment.

Fix formatting


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99456

Files:
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/include/clang/Lex/LiteralSupport.h
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Lex/LiteralSupport.cpp
  clang/lib/Lex/PPExpressions.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Lexer/cxx-features.cpp
  clang/test/Lexer/size_t-literal.cpp
  clang/test/SemaCXX/cxx1y-user-defined-literals.cpp
  clang/test/SemaCXX/size_t-literal.cpp

Index: clang/test/SemaCXX/size_t-literal.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/size_t-literal.cpp
@@ -0,0 +1,80 @@
+// RUN: %clang_cc1 -std=c++2b -Werror=c++2b-extensions -fsyntax-only -verify %s
+// RUN: %clang_cc1 -std=c++20 -Werror=c++2b-extensions -fsyntax-only -verify %s
+
+typedef __SIZE_TYPE__ size_t;
+// Assume ptrdiff_t is the signed integer type corresponding to size_t.
+typedef __PTRDIFF_TYPE__ ssize_t;
+
+template 
+struct is_same { static constexpr bool value = false; };
+
+template 
+struct is_same { static constexpr bool value = true; };
+
+#if __cplusplus >= 202101L
+//  expected-no-diagnostics
+#endif
+
+void SSizeT() {
+  auto a1 = 1z;
+#if __cplusplus < 202101L
+  // expected-error@-2 {{size_t suffix for literals is a C++2b extension}}
+#endif
+  static_assert(is_same::value);
+
+  auto a2 = 1Z;
+#if __cplusplus < 202101L
+  // expected-error@-2 {{size_t suffix for literals is a C++2b extension}}
+#endif
+  static_assert(is_same::value);
+}
+
+void SizeT() {
+  auto a1 = 1uz;
+#if __cplusplus < 202101L
+  // expected-error@-2 {{size_t suffix for literals is a C++2b extension}}
+#endif
+  static_assert(is_same::value);
+
+  auto a2 = 1uZ;
+#if __cplusplus < 202101L
+  // expected-error@-2 {{size_t suffix for literals is a C++2b extension}}
+#endif
+  static_assert(is_same::value);
+
+  auto a3 = 1Uz;
+#if __cplusplus < 202101L
+  // expected-error@-2 {{size_t suffix for literals is a C++2b extension}}
+#endif
+  static_assert(is_same::value);
+
+  auto a4 = 1UZ;
+#if __cplusplus < 202101L
+  // expected-error@-2 {{size_t suffix for literals is a C++2b extension}}
+#endif
+  static_assert(is_same::value);
+
+  auto a5 = 1zu;
+#if __cplusplus < 202101L
+  // expected-error@-2 {{size_t suffix for literals is a C++2b extension}}
+#endif
+  static_assert(is_same::value);
+
+  auto a6 = 1Zu;
+#if __cplusplus < 202101L
+  // expected-error@-2 {{size_t suffix for literals is a C++2b extension}}
+#endif
+  static_assert(is_same::value);
+
+  auto a7 = 1zU;
+#if __cplusplus < 202101L
+  // expected-error@-2 {{size_t suffix for literals is a C++2b extension}}
+#endif
+  static_assert(is_same::value);
+
+  auto a8 = 1ZU;
+#if __cplusplus < 202101L
+  // expected-error@-2 {{size_t suffix for literals is a C++2b extension}}
+#endif
+  static_assert(is_same::value);
+}
Index: clang/test/SemaCXX/cxx1y-user-defined-literals.cpp
===
--- clang/test/SemaCXX/cxx1y-user-defined-literals.cpp
+++ clang/test/SemaCXX/cxx1y-user-defined-literals.cpp
@@ -34,7 +34,7 @@
 string s = "foo"s;
 char error = 'x's; // expected-error {{invalid suffix}} expected-error {{expected ';'}}
 
-int _1z = 1z; // expected-error {{invalid suffix}}
+int _1y = 1y; // expected-error {{invalid suffix}}
 int _1b = 1b; // expected-error {{invalid digit}}
 
 complex cf1 = 1if, cf2 = 2.if, cf3 = 0x3if;
Index: clang/test/Lexer/size_t-literal.cpp
===
--- /dev/null
+++ clang/test/Lexer/size_t-literal.cpp
@@ -0,0 +1,154 @@
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify %s
+
+void ValidSuffix() {
+  // Decimal literals.
+  {
+auto a1 = 1z;
+auto a2 = 1Z;
+
+auto a3 = 1uz;
+auto a4 = 1uZ;
+auto a5 = 1Uz;
+auto a6 = 1UZ;
+
+auto a7 = 1zu;
+auto a8 = 1Zu;
+auto a9 = 1zU;
+auto a10 = 1ZU;
+
+auto a11 = 1'2z;
+auto a12 = 1'2Z;
+  }
+  // Hexadecimal literals.
+  {
+auto a1 = 0x1z;
+auto a2 = 0x1Z;
+
+auto a3 = 0x1uz;
+auto a4 = 0x1uZ;
+auto a5 = 0x1Uz;
+auto a6 = 0x1UZ;
+
+auto a7 = 0x1zu;
+auto a8 = 0x1Zu;
+auto a9 = 0x1zU;
+auto a10 = 0x1ZU;
+
+auto a11 = 0x1'2z;
+auto a12 = 0x1'2Z;
+  }
+  // Binary literals.
+  {
+auto a1 = 0b1z;
+auto a2 = 0b1Z;
+
+auto a3 = 0b1uz;
+auto a4 = 0b1uZ;
+auto a5 = 0b1Uz;
+auto a6 = 0b1UZ;
+
+auto a7 = 0b1zu;
+auto a8 = 0b1Zu;
+auto a9 = 0b1zU;
+auto a10 = 0b1ZU;
+
+auto a11 = 0b1'1z;
+auto a12 = 0b1'1Z;
+  }
+  // Octal literals.
+  {
+auto a1 = 01z;
+auto a2 = 01Z;
+
+auto a3 = 01uz;
+auto a4 = 01uZ;
+auto a5 = 01Uz;
+auto a6 = 01UZ;
+
+auto a7 = 01zu;
+auto a8 = 01Zu;
+auto a9 = 01zU;
+auto a10 = 

[PATCH] D99402: [AMDGPU][OpenMP] Add /include to the search path

2021-03-29 Thread Pushpinder Singh via Phabricator via cfe-commits
pdhaliwal added a comment.

The general problem seems bit more involved. I am not that familiar with how 
other architectures/systems handle the library/include path.  Simplest solution 
that I can propose right now is to generalise my revision to other 
architectures for header lookup and similarly for library lookup in case of 
openmp. If there is better solution available please let me know I will be 
happy to implement it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99402

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


[PATCH] D99495: clang-format: [JS] do not collapse - - to --.

2021-03-29 Thread Martin Probst via Phabricator via cfe-commits
mprobst created this revision.
mprobst added a reviewer: krasimir.
mprobst requested review of this revision.
Herald added a project: clang.

In JavaScript, `- -1;` is legal syntax, the language allows unary minus.
However the two tokens must not collapse together: `--1` is prefix
decrement, i.e. different syntax.

Before:

- -1; ==> --1;

After:

- -1; ==> - -1;

This change makes no attempt to format this "nicely", given by all
likelihood this represents a programming mistake by the user, or odd
generated code.

The check is not guarded by language: this appears to be a problem in
Java as well, and will also be beneficial when formatting syntactically
incorrect C++ (e.g. during editing).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99495

Files:
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTestJS.cpp


Index: clang/unittests/Format/FormatTestJS.cpp
===
--- clang/unittests/Format/FormatTestJS.cpp
+++ clang/unittests/Format/FormatTestJS.cpp
@@ -276,6 +276,12 @@
   // ES6 spread operator.
   verifyFormat("someFunction(...a);");
   verifyFormat("var x = [1, ...a, 2];");
+
+  // "- -1" is legal JS syntax, but must not collapse into "--".
+  verifyFormat("- -1;", " - -1;");
+  verifyFormat("-- -1;", " -- -1;");
+  verifyFormat("+ +1;", " + +1;");
+  verifyFormat("++ +1;", " ++ +1;");
 }
 
 TEST_F(FormatTestJS, UnderstandsAmpAmp) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3370,6 +3370,12 @@
  Style.BitFieldColonSpacing == FormatStyle::BFCS_Before;
 return true;
   }
+  // Do not merge "- -" into "--".
+  if ((Left.isOneOf(tok::minus, tok::minusminus) &&
+   Right.isOneOf(tok::minus, tok::minusminus)) ||
+  (Left.isOneOf(tok::plus, tok::plusplus) &&
+   Right.isOneOf(tok::plus, tok::plusplus)))
+return true;
   if (Left.is(TT_UnaryOperator)) {
 if (!Right.is(tok::l_paren)) {
   // The alternative operators for ~ and ! are "compl" and "not".


Index: clang/unittests/Format/FormatTestJS.cpp
===
--- clang/unittests/Format/FormatTestJS.cpp
+++ clang/unittests/Format/FormatTestJS.cpp
@@ -276,6 +276,12 @@
   // ES6 spread operator.
   verifyFormat("someFunction(...a);");
   verifyFormat("var x = [1, ...a, 2];");
+
+  // "- -1" is legal JS syntax, but must not collapse into "--".
+  verifyFormat("- -1;", " - -1;");
+  verifyFormat("-- -1;", " -- -1;");
+  verifyFormat("+ +1;", " + +1;");
+  verifyFormat("++ +1;", " ++ +1;");
 }
 
 TEST_F(FormatTestJS, UnderstandsAmpAmp) {
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3370,6 +3370,12 @@
  Style.BitFieldColonSpacing == FormatStyle::BFCS_Before;
 return true;
   }
+  // Do not merge "- -" into "--".
+  if ((Left.isOneOf(tok::minus, tok::minusminus) &&
+   Right.isOneOf(tok::minus, tok::minusminus)) ||
+  (Left.isOneOf(tok::plus, tok::plusplus) &&
+   Right.isOneOf(tok::plus, tok::plusplus)))
+return true;
   if (Left.is(TT_UnaryOperator)) {
 if (!Right.is(tok::l_paren)) {
   // The alternative operators for ~ and ! are "compl" and "not".
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D93095: Introduce -Wreserved-identifier

2021-03-29 Thread serge via Phabricator via cfe-commits
serge-sans-paille updated this revision to Diff 333812.
serge-sans-paille added a comment.

Fix typo


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

https://reviews.llvm.org/D93095

Files:
  clang/include/clang/AST/Decl.h
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Decl.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/Sema/reserved-identifier.c
  clang/test/Sema/reserved-identifier.cpp

Index: clang/test/Sema/reserved-identifier.cpp
===
--- /dev/null
+++ clang/test/Sema/reserved-identifier.cpp
@@ -0,0 +1,87 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify -Wreserved-identifier %s
+
+int foo__bar() { return 0; }// expected-warning {{identifier 'foo__bar' is reserved because it contains '__'}}
+static int _bar() { return 0; } // expected-warning {{identifier '_bar' is reserved because it starts with '_' at global scope}}
+static int _Bar() { return 0; } // expected-warning {{identifier '_Bar' is reserved because it starts with '_' followed by a capital letter}}
+int _barbouille() { return 0; } // expected-warning {{identifier '_barbouille' is reserved because it starts with '_' at global scope}}
+
+void foo(unsigned int _Reserved) { // expected-warning {{identifier '_Reserved' is reserved because it starts with '_' followed by a capital letter}}
+  unsigned int __1 =   // expected-warning {{identifier '__1' is reserved because it starts with '__'}}
+  _Reserved;   // no-warning
+}
+
+// This one is explicitly skipped by -Wreserved-identifier
+void *_; // no-warning
+
+template  constexpr bool __toucan = true; // expected-warning {{identifier '__toucan' is reserved because it starts with '__'}}
+
+template 
+concept _Barbotine = __toucan; // expected-warning {{identifier '_Barbotine' is reserved because it starts with '_' followed by a capital letter}}
+
+template  // expected-warning {{'__' is reserved because it starts with '__'}}
+struct BarbeNoire {};
+
+template  // no-warning
+struct BarbeJaune {};
+
+template  // expected-warning {{'__' is reserved because it starts with '__'}}
+void BarbeRousse() {}
+
+namespace _Barbidur { // expected-warning {{identifier '_Barbidur' is reserved because it starts with '_' followed by a capital letter}}
+
+struct __barbidou {}; // expected-warning {{identifier '__barbidou' is reserved because it starts with '__'}}
+struct _barbidou {};  // no-warning
+
+int __barbouille; // expected-warning {{identifier '__barbouille' is reserved because it starts with '__'}}
+int _barbouille;  // no-warning
+
+int __babar() { return 0; } // expected-warning {{identifier '__babar' is reserved because it starts with '__'}}
+int _babar() { return 0; }  // no-warning
+
+} // namespace _Barbidur
+
+class __barbapapa { // expected-warning {{identifier '__barbapapa' is reserved because it starts with '__'}}
+  void _barbabelle() {} // no-warning
+  int _Barbalala;   // expected-warning {{identifier '_Barbalala' is reserved because it starts with '_' followed by a capital letter}}
+};
+
+enum class __menu { // expected-warning {{identifier '__menu' is reserved because it starts with '__'}}
+  __some,   // expected-warning {{identifier '__some' is reserved because it starts with '__'}}
+  _Other,   // expected-warning {{identifier '_Other' is reserved because it starts with '_' followed by a capital letter}}
+  _other// no-warning
+};
+
+enum _Menu { // expected-warning {{identifier '_Menu' is reserved because it starts with '_' followed by a capital letter}}
+  _OtheR_,   // expected-warning {{identifier '_OtheR_' is reserved because it starts with '_' followed by a capital letter}}
+  _other_// expected-warning {{identifier '_other_' is reserved because it starts with '_' at global scope}}
+};
+
+enum {
+  __some, // expected-warning {{identifier '__some' is reserved because it starts with '__'}}
+  _Other, // expected-warning {{identifier '_Other' is reserved because it starts with '_' followed by a capital letter}}
+  _other  // expected-warning {{identifier '_other' is reserved because it starts with '_' at global scope}}
+};
+
+static union {
+  int _barbeFleurie; // no-warning
+};
+
+using _Barbamama = __barbapapa; // expected-warning {{identifier '_Barbamama' is reserved because it starts with '_' followed by a capital letter}}
+
+int foobar() {
+  return foo__bar(); // no-warning
+}
+
+namespace {
+int _barbatruc; // no-warning
+}
+
+long double operator"" _BarbeBleue(long double) // expected-warning {{identifier 'operator""_BarbeBleue' is reserved because it starts with '_' followed by a capital letter}}
+{
+  return 0.;
+}
+
+struct _BarbeRouge { // expected-warning {{identifier '_BarbeRouge' is reserved because it starts

[PATCH] D99152: [AMX] Prototype for vector and amx bitcast.

2021-03-29 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a comment.

In D99152#2655371 , @lebedev.ri wrote:

> In D99152#2655357 , @fhahn wrote:
>
>> 

snip

>> I'm not sure if the loads and store are actually incorrect. `_tile1024i ` is 
>> defined as `typedef int _tile1024i __attribute__((__vector_size__(1024), 
>> __aligned__(64)));` and the loads/stores are for assignments/reads from 
>> variables that have that type, which is `<256 x i32>` in IR. So it is not 
>> obvious to me why the loads/stores would be wrong, as long as `_tile1024i` 
>> is defined as it is (if it would be a different type, that all changes).
>
> Didn't @LuoYuanke state:
>
> In D99152#2643821 , @LuoYuanke wrote:
>
>> @lebedev.ri, this patch is mainly for discussing the approach that Florian 
>> proposed, so I didn't polish my code. Nevertheless your comments for 
>> amx_cast.c is right. For __tile_loadd() is to load a 2d tile from memory. 
>> There is an extra parameter stride. As I explain in llvm-dev, it load each 
>> row from memory to tile register and then base += stride. So the data is not 
>> contiguous in memory.
>
> Note the `So the data is not contiguous in memory.`.
> I.e. we won't actually store to `i8* [ptr + 0, ptr + 4096)` byte area.
> Is plain `load`/`store` not defined to perform operations on contigious 
> chunks of memory?
> Am i completely missing the point?

I think that point was not really clear during the discussion. Using `load <256 
x i32>` to lower `__tile_loadd() ` would indeed be incorrect. But I don't think 
that's happening at the moment, at least going from a simple example 
https://gcc.godbolt.org/z/KT5rczn8j

  void foo() {
tilea = __builtin_ia32_tileloadd64_internal(16, 64, buf, 64);
  }

is lowered to

  define dso_local void @foo() #0 {
%1 = call x86_amx @llvm.x86.tileloadd64.internal(i16 16, i16 64, i8* 
getelementptr inbounds ([1024 x i8], [1024 x i8]* @buf, i64 0, i64 0), i64 64)
%2 = bitcast x86_amx %1 to <256 x i32>
store <256 x i32> %2, <256 x i32>* @tilea, align 64
ret void
  }

So we emit an intrinsic to do the strided load and the result is stored to 
continuous memory, which is what the type `_tile1024i` requires. What's not 
modeled correctly is the conversion between the result of 
`@llvm.x86.tileloadd64.internal` and the `store`. It needs to be transferred in 
a flat vector.

Whether we should have `x86_amx` in the first place is a separate question I 
think. Having a builtin type that does not work properly with fundamental 
instructions like `load` or `store` seems prone for errors (what instructions 
actually work with `x86_amx`? Do binary operators work?). Perhaps it would be 
possible and sufficient to have the intrinsics use an opaque type instead of a 
builtin type, like

  %my_x86_amx = type opaque
  
  define %my_x86_amx @foo(%my_x86_amx %x) {
ret %my_x86_amx %x
  }

But I think we should address those 2 issues separately and fix the biggest 
problem (mis-use of `bitcast`) first, perhaps followed up by verifier rules 
rejecting `x86_amx` from un-suitable instructions and go from there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99152

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


[PATCH] D99458: [clang-format] Fix east const pointer alignment of operators

2021-03-29 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius added a comment.

Thinking out loud, do we test `volatile` at all?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99458

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


[PATCH] D91327: [NewPM] Redesign of PreserveCFG Checker

2021-03-29 Thread Yevgeny Rouban via Phabricator via cfe-commits
yrouban updated this revision to Diff 333825.
yrouban added a comment.

just rebased. please review


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

https://reviews.llvm.org/D91327

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/include/llvm/Passes/StandardInstrumentations.h
  llvm/lib/LTO/LTOBackend.cpp
  llvm/lib/Passes/StandardInstrumentations.cpp
  llvm/test/Other/loop-pm-invalidation.ll
  llvm/test/Other/new-pass-manager.ll
  llvm/test/Other/new-pm-O0-defaults.ll
  llvm/test/Other/new-pm-defaults.ll
  llvm/test/Other/new-pm-lto-defaults.ll
  llvm/test/Other/new-pm-thinlto-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-pgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-postlink-samplepgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-pgo-defaults.ll
  llvm/test/Other/new-pm-thinlto-prelink-samplepgo-defaults.ll
  llvm/test/Transforms/LoopRotate/pr35210.ll
  llvm/test/Transforms/SCCP/ipsccp-preserve-analysis.ll
  llvm/tools/opt/NewPMDriver.cpp
  llvm/unittests/IR/PassManagerTest.cpp

Index: llvm/unittests/IR/PassManagerTest.cpp
===
--- llvm/unittests/IR/PassManagerTest.cpp
+++ llvm/unittests/IR/PassManagerTest.cpp
@@ -827,7 +827,7 @@
   FunctionPassManager FPM(/*DebugLogging*/ true);
   PassInstrumentationCallbacks PIC;
   StandardInstrumentations SI(/*DebugLogging*/ true);
-  SI.registerCallbacks(PIC);
+  SI.registerCallbacks(PIC, &FAM);
   FAM.registerPass([&] { return PassInstrumentationAnalysis(&PIC); });
   FAM.registerPass([&] { return DominatorTreeAnalysis(); });
   FAM.registerPass([&] { return AssumptionAnalysis(); });
@@ -873,7 +873,7 @@
   FunctionPassManager FPM(/*DebugLogging*/ true);
   PassInstrumentationCallbacks PIC;
   StandardInstrumentations SI(/*DebugLogging*/ true);
-  SI.registerCallbacks(PIC);
+  SI.registerCallbacks(PIC, &FAM);
   FAM.registerPass([&] { return PassInstrumentationAnalysis(&PIC); });
   FAM.registerPass([&] { return DominatorTreeAnalysis(); });
   FAM.registerPass([&] { return AssumptionAnalysis(); });
@@ -938,7 +938,7 @@
   FunctionPassManager FPM(/*DebugLogging*/ true);
   PassInstrumentationCallbacks PIC;
   StandardInstrumentations SI(/*DebugLogging*/ true);
-  SI.registerCallbacks(PIC);
+  SI.registerCallbacks(PIC, &FAM);
   FAM.registerPass([&] { return PassInstrumentationAnalysis(&PIC); });
   FAM.registerPass([&] { return DominatorTreeAnalysis(); });
   FAM.registerPass([&] { return AssumptionAnalysis(); });
Index: llvm/tools/opt/NewPMDriver.cpp
===
--- llvm/tools/opt/NewPMDriver.cpp
+++ llvm/tools/opt/NewPMDriver.cpp
@@ -275,9 +275,14 @@
   P->CSAction = PGOOptions::CSIRUse;
 }
   }
+  LoopAnalysisManager LAM(DebugPM);
+  FunctionAnalysisManager FAM(DebugPM);
+  CGSCCAnalysisManager CGAM(DebugPM);
+  ModuleAnalysisManager MAM(DebugPM);
+
   PassInstrumentationCallbacks PIC;
   StandardInstrumentations SI(DebugPM, VerifyEachPass);
-  SI.registerCallbacks(PIC);
+  SI.registerCallbacks(PIC, &FAM);
   DebugifyEachInstrumentation Debugify;
   if (DebugifyEach)
 Debugify.registerCallbacks(PIC);
@@ -373,11 +378,6 @@
 }
   }
 
-  LoopAnalysisManager LAM(DebugPM);
-  FunctionAnalysisManager FAM(DebugPM);
-  CGSCCAnalysisManager CGAM(DebugPM);
-  ModuleAnalysisManager MAM(DebugPM);
-
   // Register the AA manager first so that our version is the one used.
   FAM.registerPass([&] { return std::move(AA); });
   // Register our TargetLibraryInfoImpl.
Index: llvm/test/Transforms/SCCP/ipsccp-preserve-analysis.ll
===
--- llvm/test/Transforms/SCCP/ipsccp-preserve-analysis.ll
+++ llvm/test/Transforms/SCCP/ipsccp-preserve-analysis.ll
@@ -16,7 +16,7 @@
 ; NEW-PM: Running pass: IPSCCPPass
 ; NEW-PM-DAG: Running analysis: AssumptionAnalysis on f1
 ; NEW-PM-DAG: Running analysis: AssumptionAnalysis on f2
-; NEW-PM-NOT: Running analysis:
+; NEW-PM-NOT: Running analysis: AssumptionAnalysis
 
 ; IR-LABEL: @f1
 ; IR-LABEL: entry:
Index: llvm/test/Transforms/LoopRotate/pr35210.ll
===
--- llvm/test/Transforms/LoopRotate/pr35210.ll
+++ llvm/test/Transforms/LoopRotate/pr35210.ll
@@ -1,5 +1,5 @@
-;RUN: opt %s -aa-pipeline= -passes='adce,loop(loop-rotate),adce' -S -debug-pass-manager -debug-only=loop-rotate 2>&1 | FileCheck %s
-;RUN: opt %s -aa-pipeline= -passes='adce,loop-mssa(loop-rotate),adce' -S -debug-pass-manager -debug-only=loop-rotate -verify-memoryssa 2>&1 | FileCheck %s --check-prefix=MSSA
+;RUN: opt %s -aa-pipeline= -passes='adce,loop(loop-rotate),adce' -S -verify-cfg-preserved=0 -debug-pass-manager -debug-only=loop-rotate 2>&1 | FileCheck %s
+;RUN: opt %s -aa-pipeline= -passes='adce,loop-mssa(loop-rotate),adce' -S -verify-cfg-preserved=0 -debug-pass-manager -debug-only=loop-rotate -verify-memoryssa 2>&1 | FileCheck %s --check-prefix=MSSA
 ;REQUIRES: asserts
 
 ; This test is t

[PATCH] D99500: [analyzer] Support allocClassWithName in OSObjectCStyleCast checker

2021-03-29 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko created this revision.
vsavchenko added reviewers: NoQ, steakhal, xazax.hun, ASDenysPetrov.
Herald added subscribers: martong, Charusso, dkrupp, donat.nagy, Szelethus, 
mikhail.ramalho, a.sidorin, rnkovacs, szepet, baloghadamsoftware.
vsavchenko requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

`allocClassWithName` allocates an object with the given type.
The type is actually provided as a string argument (type's name).
This creates a possibility for not particularly useful warnings
from the analyzer.

In order to combat with those, this patch checks for casts of the
`allocClassWithName` results to types mentioned directly as its
argument.  All other uses of this method should be reasoned about
as before.

rdar://72165694


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99500

Files:
  clang/lib/StaticAnalyzer/Checkers/OSObjectCStyleCast.cpp
  clang/test/Analysis/os_object_base.h
  clang/test/Analysis/osobjectcstylecastchecker_test.cpp

Index: clang/test/Analysis/osobjectcstylecastchecker_test.cpp
===
--- clang/test/Analysis/osobjectcstylecastchecker_test.cpp
+++ clang/test/Analysis/osobjectcstylecastchecker_test.cpp
@@ -37,3 +37,12 @@
   return b->getCount();
 }
 
+unsigned no_warn_alloc_class_with_name() {
+  OSArray *a = (OSArray *)OSMetaClass::allocClassWithName("OSArray"); // no warning
+  return a->getCount();
+}
+
+unsigned warn_alloc_class_with_name() {
+  OSArray *a = (OSArray *)OSMetaClass::allocClassWithName("OSObject"); // expected-warning{{C-style cast of an OSObject is prone to type confusion attacks; use 'OSRequiredCast' if the object is definitely of type 'OSArray', or 'OSDynamicCast' followed by a null check if unsure}}
+  return a->getCount();
+}
Index: clang/test/Analysis/os_object_base.h
===
--- clang/test/Analysis/os_object_base.h
+++ clang/test/Analysis/os_object_base.h
@@ -66,6 +66,7 @@
 
 struct OSMetaClass : public OSMetaClassBase {
   virtual OSObject * alloc() const;
+  static OSObject * allocClassWithName(const char * name);
   virtual ~OSMetaClass(){}
 };
 
Index: clang/lib/StaticAnalyzer/Checkers/OSObjectCStyleCast.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/OSObjectCStyleCast.cpp
+++ clang/lib/StaticAnalyzer/Checkers/OSObjectCStyleCast.cpp
@@ -32,7 +32,21 @@
   void checkASTCodeBody(const Decl *D, AnalysisManager &AM,
 BugReporter &BR) const;
 };
+} // namespace
+
+namespace clang {
+namespace ast_matchers {
+AST_MATCHER_P(StringLiteral, mentionsBoundType, std::string, BindingID) {
+  return Builder->removeBindings([this, &Node](const BoundNodesMap &Nodes) {
+const auto &BN = Nodes.getNode(this->BindingID);
+if (const auto *ND = BN.get()) {
+  return ND->getName() != Node.getString();
+}
+return true;
+  });
 }
+} // end namespace ast_matchers
+} // end namespace clang
 
 static void emitDiagnostics(const BoundNodes &Nodes,
 BugReporter &BR,
@@ -63,22 +77,41 @@
   return hasType(pointerType(pointee(hasDeclaration(DeclM;
 }
 
-void OSObjectCStyleCastChecker::checkASTCodeBody(const Decl *D, AnalysisManager &AM,
+void OSObjectCStyleCastChecker::checkASTCodeBody(const Decl *D,
+ AnalysisManager &AM,
  BugReporter &BR) const {
 
   AnalysisDeclContext *ADC = AM.getAnalysisDeclContext(D);
 
   auto DynamicCastM = callExpr(callee(functionDecl(hasName("safeMetaCast";
-
-  auto OSObjTypeM = hasTypePointingTo(cxxRecordDecl(isDerivedFrom("OSMetaClassBase")));
+  // 'allocClassWithName' allocates an object with the given type.
+  // The type is actually provided as a string argument (type's name).
+  // This makes the following pattern possible:
+  //
+  // Foo *object = (Foo *)allocClassWithName("Foo");
+  //
+  // While OSRequiredCast can be used here, it is still not a useful warning.
+  auto AllocClassWithNameM = callExpr(
+  callee(functionDecl(hasName("allocClassWithName"))),
+  // Here we want to make sure that the string argument matches the
+  // type in the cast expression.
+  hasArgument(0, stringLiteral(mentionsBoundType(WarnRecordDecl;
+
+  auto OSObjTypeM =
+  hasTypePointingTo(cxxRecordDecl(isDerivedFrom("OSMetaClassBase")));
   auto OSObjSubclassM = hasTypePointingTo(
-cxxRecordDecl(isDerivedFrom("OSObject")).bind(WarnRecordDecl));
-
-  auto CastM = cStyleCastExpr(
-  allOf(hasSourceExpression(allOf(OSObjTypeM, unless(DynamicCastM))),
-  OSObjSubclassM)).bind(WarnAtNode);
-
-  auto Matches = match(stmt(forEachDescendant(CastM)), *D->getBody(), AM.getASTContext());
+  cxxRecordDecl(isDerivedFrom("OSObject")).bind(WarnRecordDecl));
+
+  auto CastM =
+  cStyleCastExpr(
+  

[PATCH] D99190: WIP: [SYCL] Add design document for SYCL mode

2021-03-29 Thread Victor Lomuller via Phabricator via cfe-commits
Naghasan requested changes to this revision.
Naghasan added a comment.
This revision now requires changes to proceed.

Added comment for the front end support part.

I think the document present to much at once, front-end, driver, tool chains, 
SPIR-V backend, compiler-runtime bindings etc.
It is good to have everything eventually, but it would be beneficial to split 
this patch into more focus ones.
Having a link to the main document in your github would still allow one to get 
the big picture.

I see the address space bit has already been split, that's better to keep 
things focused I guess.

In D99190#2650326 , @bader wrote:

> @keryell, thanks for the feedback.
>
> I applied your suggestions with two exceptions:
>
> 1. I'm not sure if other back-ends need special processing for kernel 
> function parameters we apply for SPIR kernels.

I'm not sure TBH, but passing just the object as a whole is not helping DAE 
passes. So either way, it is not a bad thing to have that processing.




Comment at: clang/docs/SYCLSupport.md:51
+virtual calls), generates LLVM IR for the device code only and an "integration
+header" which provides information like kernel name, parameters order and data
+type for the runtime library.

Do you plan on upstreaming your integration header approach ? Even if it is 
useful in some situations and speeds up the creation of a prototype, it comes 
with its complications.

An integration header creates a by-product then used as input for another 
compilation phase. I haven't at the upstream driver capabilities for awhile, 
but I don't think you can model 2 outputs yet. Are  you planing on adding this 
capability ?
If not, wouldn't that forces you to trigger a compilation step just for the 
generation of that files ? If so that puts a strong burden on the compilation 
speed as you now have to process 3 times your input C++ file.



Comment at: clang/docs/SYCLSupport.md:73
+the integration header is used (included) by the SYCL runtime implementation, 
so
+the header must be available before the host compilation starts.*
+

> First, it must be possible to use any host compiler

I don't understand the link with the integration header. SYCL being 
implementable as a library is a design principle of the specs but it doesn't 
means the clang host compiler has to remain a vanilla C++ compiler.

> information provided in the integration header is used (included) by the SYCL 
> runtime implementation, so the header must be available before the host 
> compilation starts

Another approach to the integration header would be for clang as the host 
compiler to generate the used type traits.



Comment at: clang/docs/SYCLSupport.md:123
+traverse all symbols accessible from kernel functions and add them to the
+"device part" of the code marking them with the new SYCL device attribute.
+

OpenMP offload uses a similar approach isn't it? Might be worth to describe how 
the 2 relates to each other and where they diverge. 



Comment at: clang/docs/SYCLSupport.md:128
+SYCL memory objects shared between host and device can be accessed either
+through raw pointers (to "shared" memory allocated using USM methods) or 
special
+`accessor` classes. Raw pointers map to kernel parameters one-to-one without

I find "shared" ambiguous, to CUDA developer shared memory is the OpenCL local 
memory. "Unified" is less prone misinterpretation (and matches the U of USM :).



Comment at: clang/docs/SYCLSupport.md:130
+`accessor` classes. Raw pointers map to kernel parameters one-to-one without
+additional transformations. `accessor` classes require additional processing as
+The "device" implementation of this class contains pointers to the device 
memory

> Raw pointers map to kernel parameters one-to-one without additional 
> transformations

Is this true ? I thought they should be passed as "pointer to global memory" 
(under the OpenCL or CUDA model).



Comment at: clang/docs/SYCLSupport.md:131
+additional transformations. `accessor` classes require additional processing as
+The "device" implementation of this class contains pointers to the device 
memory
+as a class member. OpenCL doesn't allow passing structures with pointer type





Comment at: clang/docs/SYCLSupport.md:132
+The "device" implementation of this class contains pointers to the device 
memory
+as a class member. OpenCL doesn't allow passing structures with pointer type
+members as kernel parameters. All memory objects shared between host and device

Won't be better to refer to SPIR or SPIR-V kernels rather than OpenCL ?

Or even SPIR-like or SPIR-defacto to be even less normative.



Comment at: clang/docs/SYCLSupport.md:134
+members as kernel parameters. All memory objects sha

[PATCH] D98798: Produce waring for performing pointer arithmetic on a null pointer.

2021-03-29 Thread Jamie Schmeiser via Phabricator via cfe-commits
jamieschmeiser added reviewers: rsmith, efriedma, hfinkel.
jamieschmeiser added a comment.

Added more reviewers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98798

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


[PATCH] D98657: [flang][driver] Add options for -Werror

2021-03-29 Thread Arnamoy B via Phabricator via cfe-commits
arnamoy10 updated this revision to Diff 333843.
arnamoy10 added a comment.

Modifying the test cases to:

1. Make it work for `f18` (when `flang-new` is not installed)
2. Adding more options and one test case to check correct functionality with 
`PrescanAction` and `PrescanAndSemaAction`


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

https://reviews.llvm.org/D98657

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/werror.f90
  flang/test/Driver/werror_scan.f

Index: flang/test/Driver/werror_scan.f
===
--- /dev/null
+++ flang/test/Driver/werror_scan.f
@@ -0,0 +1,32 @@
+! Ensure argument -Werror work as expected, this file checks for the functional correctness for
+! actions that extend the PrescanAction
+! TODO: Modify test cases in test/Semantics/ related to f18 when -std= is upstreamed
+
+!--
+! FLANG DRIVER (flang-new)
+!--
+
+!-
+! FRONTEND FLANG DRIVER (flang-new -fc1)
+!-
+! RUN: not %flang_fc1 -fsyntax-only -E -Werror %s  2>&1 | FileCheck %s --check-prefix=WITH
+! RUN: not %flang_fc1 -fsyntax-only -fdebug-dump-parsing-log -Werror %s  2>&1 | FileCheck %s --check-prefix=WITH
+! RUN: not %flang_fc1 -fsyntax-only -fdebug-dump-provenance -Werror %s  2>&1 | FileCheck %s --check-prefix=WITH
+! RUN: not %flang_fc1 -fsyntax-only -fdebug-measure-parse-tree -Werror %s  2>&1 | FileCheck %s --check-prefix=WITH
+! RUN: %flang_fc1 -fsyntax-only -E %s  2>&1 | FileCheck %s --allow-empty --check-prefix=WITHOUT
+! RUN: %flang_fc1 -fsyntax-only -fdebug-dump-parsing-log %s  2>&1 | FileCheck %s --check-prefix=WITHOUT
+! RUN: %flang_fc1 -fsyntax-only -fdebug-dump-provenance %s  2>&1 | FileCheck %s --check-prefix=WITHOUT
+! RUN: %flang_fc1 -fsyntax-only -fdebug-measure-parse-tree %s  2>&1 | FileCheck %s --check-prefix=WITHOUT
+
+!-
+! EXPECTED OUTPUT WITH -Werror
+!-
+! WITH: Could not scan
+
+!-
+! EXPECTED OUTPUT WITHOUT -Werror
+!-
+! WITHOUT-NOT: Could not scan
+
+1 continue
+end
Index: flang/test/Driver/werror.f90
===
--- /dev/null
+++ flang/test/Driver/werror.f90
@@ -0,0 +1,37 @@
+! Ensure argument -Werror work as expected.
+! TODO: Modify test cases in test/Semantics/ related to f18 when -std= is upstreamed
+
+!--
+! FLANG DRIVER (flang-new)
+!--
+
+!-
+! FRONTEND FLANG DRIVER (flang-new -fc1)
+!-
+! RUN: not %flang_fc1 -fsyntax-only -Werror %s  2>&1 | FileCheck %s --check-prefix=WITH
+! RUN: not %flang_fc1 -fsyntax-only -Werror -fdebug-dump-parse-tree %s  2>&1 | FileCheck %s --check-prefix=WITH
+! RUN: not %flang_fc1 -fsyntax-only -Werror -fdebug-unparse-with-symbols %s  2>&1 | FileCheck %s --check-prefix=WITH
+! RUN: not %flang_fc1 -fsyntax-only -Werror -fdebug-unparse %s  2>&1 | FileCheck %s --check-prefix=WITH
+! RUN: not %flang_fc1 -fsyntax-only -Werror -fdebug-dump-symbols %s  2>&1 | FileCheck %s --check-prefix=WITH
+
+
+! RUN: %flang_fc1 -fsyntax-only %s  2>&1 | FileCheck %s --allow-empty --check-prefix=WITHOUT
+! RUN: %flang_fc1 -fsyntax-only -fdebug-dump-parse-tree %s  2>&1 | FileCheck %s --allow-empty --check-prefix=WITHOUT
+! RUN: %flang_fc1 -fsyntax-only -fdebug-unparse-with-symbols %s  2>&1 | FileCheck %s --allow-empty --check-prefix=WITHOUT
+! RUN: %flang_fc1 -fsyntax-only -fdebug-unparse %s  2>&1 | FileCheck %s --allow-empty --check-prefix=WITHOUT
+! RUN: %flang_fc1 -fsyntax-only -fdebug-dump-symbols %s  2>&1 | FileCheck %s --allow-empty --check-prefix=WITHOUT
+
+!-
+! EXPECTED OUTPUT WITH -Werror
+!-
+! WITH: Semantic errors in
+
+!-
+! EXPECTED OUTPUT WITHOUT -Werror
+!-
+! WITHOUT-NOT: Semantic errors in
+
+PROGRAM werror
+REAL, DIMENSION(20, 10) :: A
+FORALL (J=1:N)  A(I, I) = 1
+END PROGRAM werror
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -51,6 +51,7 @@
 ! HELP-NEXT: -std=   Language standard to compile for
 ! HELP-NEXT: -U  Undefine macro 
 ! HELP-NEXT: --version  Print version information
+! HELP-NEXT: -WEnable the specified warn

[PATCH] D99503: Fixes for bug 41870.

2021-03-29 Thread Max Sagebaum via Phabricator via cfe-commits
Max_S created this revision.
Max_S requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Checks for newlines in option Style.EmptyLineBeforeAccessModifier are
now based on the formatted new lines and not on the new lines in the
file.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99503

Files:
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -8889,6 +8889,8 @@
 
 TEST_F(FormatTest, FormatsAccessModifiers) {
   FormatStyle Style = getLLVMStyle();
+  FormatStyle NoEmptyLines = getLLVMStyle();
+  NoEmptyLines.MaxEmptyLinesToKeep = 0;
   EXPECT_EQ(Style.EmptyLineBeforeAccessModifier,
 FormatStyle::ELBAMS_LogicalBlock);
   verifyFormat("struct foo {\n"
@@ -8940,7 +8942,20 @@
"  int j;\n"
"};\n",
Style);
+  verifyFormat("struct foo {\n"
+   "private:\n"
+   "  void f() {}\n"
+   "\n"
+   "private:\n"
+   "  int i;\n"
+   "\n"
+   "public:\n"
+   "protected:\n"
+   "  int j;\n"
+   "};\n",
+   NoEmptyLines);
   Style.EmptyLineBeforeAccessModifier = FormatStyle::ELBAMS_Never;
+  NoEmptyLines.EmptyLineBeforeAccessModifier = FormatStyle::ELBAMS_Never;
   verifyFormat("struct foo {\n"
"private:\n"
"  void f() {}\n"
@@ -8950,6 +8965,16 @@
"  int j;\n"
"};\n",
Style);
+  verifyFormat("struct foo {\n"
+   "private:\n"
+   "  void f() {}\n"
+   "private:\n"
+   "  int i;\n"
+   "public:\n"
+   "protected:\n"
+   "  int j;\n"
+   "};\n",
+   NoEmptyLines);
   verifyFormat("struct foo {\n"
"private:\n"
"  void f() {}\n"
@@ -9011,6 +9036,7 @@
"};\n",
Style);
   Style.EmptyLineBeforeAccessModifier = FormatStyle::ELBAMS_Always;
+  NoEmptyLines.EmptyLineBeforeAccessModifier = FormatStyle::ELBAMS_Always;
   verifyFormat("struct foo {\n"
"private:\n"
"  void f() {}\n"
@@ -9022,6 +9048,18 @@
"  int j;\n"
"};\n",
Style);
+  verifyFormat("struct foo {\n"
+   "private:\n"
+   "  void f() {}\n"
+   "\n"
+   "private:\n"
+   "  int i;\n"
+   "\n"
+   "public:\n"
+   "protected:\n"
+   "  int j;\n"
+   "};\n",
+   NoEmptyLines);
   verifyFormat("struct foo {\n"
"private:\n"
"  void f() {}\n"
Index: clang/lib/Format/UnwrappedLineFormatter.cpp
===
--- clang/lib/Format/UnwrappedLineFormatter.cpp
+++ clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -1254,7 +1254,7 @@
   if (PreviousLine && RootToken.isAccessSpecifier()) {
 switch (Style.EmptyLineBeforeAccessModifier) {
 case FormatStyle::ELBAMS_Never:
-  if (RootToken.NewlinesBefore > 1)
+  if (Newlines > 1)
 Newlines = 1;
   break;
 case FormatStyle::ELBAMS_Leave:
@@ -1262,7 +1262,7 @@
   break;
 case FormatStyle::ELBAMS_LogicalBlock:
   if (PreviousLine->Last->isOneOf(tok::semi, tok::r_brace) &&
-  RootToken.NewlinesBefore <= 1)
+  Newlines <= 1)
 Newlines = 2;
   break;
 case FormatStyle::ELBAMS_Always: {
@@ -1272,7 +1272,7 @@
   else
 previousToken = PreviousLine->Last;
   if ((!previousToken || !previousToken->is(tok::l_brace)) &&
-  RootToken.NewlinesBefore <= 1)
+  Newlines <= 1)
 Newlines = 2;
 } break;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99503: Fixes for bug 41870.

2021-03-29 Thread Max Sagebaum via Phabricator via cfe-commits
Max_S added a comment.

This is patch for a bug reported in 2019 
https://bugs.llvm.org/show_bug.cgi?id=41870


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99503

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


[clang] dcf9617 - [OPENMP]Fix PR49052: Clang crashed when compiling target code with assert(0).

2021-03-29 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2021-03-29T06:36:06-07:00
New Revision: dcf96178cb3490028d9e2937cd8908b7c8fc75e6

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

LOG: [OPENMP]Fix PR49052: Clang crashed when compiling target code with 
assert(0).

Need to insert a basic block during generation of the target region to
avoid crash for the GPU to be able always calling a cleanup action.
This cleanup action is required for the correct emission of the target
region for the GPU.

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

Added: 


Modified: 
clang/lib/CodeGen/CGStmtOpenMP.cpp
clang/test/OpenMP/nvptx_target_codegen.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGStmtOpenMP.cpp 
b/clang/lib/CodeGen/CGStmtOpenMP.cpp
index 2eaa481cd911..9a675a8870a2 100644
--- a/clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ b/clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -5742,6 +5742,7 @@ static void emitTargetRegion(CodeGenFunction &CGF, const 
OMPTargetDirective &S,
 CGF.CGM.getOpenMPRuntime().adjustTargetSpecificDataForLambdas(CGF, S);
 
   CGF.EmitStmt(S.getCapturedStmt(OMPD_target)->getCapturedStmt());
+  CGF.EnsureInsertPoint();
 }
 
 void CodeGenFunction::EmitOMPTargetDeviceFunction(CodeGenModule &CGM,

diff  --git a/clang/test/OpenMP/nvptx_target_codegen.cpp 
b/clang/test/OpenMP/nvptx_target_codegen.cpp
index 56f04cb01f0a..7e32f7391f12 100644
--- a/clang/test/OpenMP/nvptx_target_codegen.cpp
+++ b/clang/test/OpenMP/nvptx_target_codegen.cpp
@@ -394,6 +394,12 @@ int baz(int f, double &a) {
   return f;
 }
 
+extern void assert(int) throw() __attribute__((__noreturn__));
+void unreachable_call() {
+#pragma omp target
+assert(0);
+}
+
 // CHECK-LABEL: define {{.*}}void {{@__omp_offloading_.+static.+347}}_worker()
 // CHECK-DAG: [[OMP_EXEC_STATUS:%.+]] = alloca i8,
 // CHECK-DAG: [[OMP_WORK_FN:%.+]] = alloca i8*,
@@ -632,6 +638,12 @@ int baz(int f, double &a) {
 // CHECK: [[RES:%.+]] = load i32, i32* [[RET]],
 // CHECK: ret i32 [[RES]]
 
+// CHECK: define {{.*}}void {{@__omp_offloading_.+unreachable_call.+l399}}()
+// CHECK: call void @{{.*}}assert{{.*}}(i32 0)
+// CHECK: unreachable
+// CHECK: call void @__kmpc_kernel_deinit(i16 1)
+// CHECK: ret void
+
 // CHECK-LABEL: define {{.*}}void 
{{@__omp_offloading_.+template.+l331}}_worker()
 // CHECK-DAG: [[OMP_EXEC_STATUS:%.+]] = alloca i8,
 // CHECK-DAG: [[OMP_WORK_FN:%.+]] = alloca i8*,



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


[PATCH] D99445: [OPENMP]Fix PR49052: Clang crashed when compiling target code with assert(0).

2021-03-29 Thread Alexey Bataev via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGdcf96178cb34: [OPENMP]Fix PR49052: Clang crashed when 
compiling target code with assert(0). (authored by ABataev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99445

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/nvptx_target_codegen.cpp


Index: clang/test/OpenMP/nvptx_target_codegen.cpp
===
--- clang/test/OpenMP/nvptx_target_codegen.cpp
+++ clang/test/OpenMP/nvptx_target_codegen.cpp
@@ -394,6 +394,12 @@
   return f;
 }
 
+extern void assert(int) throw() __attribute__((__noreturn__));
+void unreachable_call() {
+#pragma omp target
+assert(0);
+}
+
 // CHECK-LABEL: define {{.*}}void {{@__omp_offloading_.+static.+347}}_worker()
 // CHECK-DAG: [[OMP_EXEC_STATUS:%.+]] = alloca i8,
 // CHECK-DAG: [[OMP_WORK_FN:%.+]] = alloca i8*,
@@ -632,6 +638,12 @@
 // CHECK: [[RES:%.+]] = load i32, i32* [[RET]],
 // CHECK: ret i32 [[RES]]
 
+// CHECK: define {{.*}}void {{@__omp_offloading_.+unreachable_call.+l399}}()
+// CHECK: call void @{{.*}}assert{{.*}}(i32 0)
+// CHECK: unreachable
+// CHECK: call void @__kmpc_kernel_deinit(i16 1)
+// CHECK: ret void
+
 // CHECK-LABEL: define {{.*}}void 
{{@__omp_offloading_.+template.+l331}}_worker()
 // CHECK-DAG: [[OMP_EXEC_STATUS:%.+]] = alloca i8,
 // CHECK-DAG: [[OMP_WORK_FN:%.+]] = alloca i8*,
Index: clang/lib/CodeGen/CGStmtOpenMP.cpp
===
--- clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -5742,6 +5742,7 @@
 CGF.CGM.getOpenMPRuntime().adjustTargetSpecificDataForLambdas(CGF, S);
 
   CGF.EmitStmt(S.getCapturedStmt(OMPD_target)->getCapturedStmt());
+  CGF.EnsureInsertPoint();
 }
 
 void CodeGenFunction::EmitOMPTargetDeviceFunction(CodeGenModule &CGM,


Index: clang/test/OpenMP/nvptx_target_codegen.cpp
===
--- clang/test/OpenMP/nvptx_target_codegen.cpp
+++ clang/test/OpenMP/nvptx_target_codegen.cpp
@@ -394,6 +394,12 @@
   return f;
 }
 
+extern void assert(int) throw() __attribute__((__noreturn__));
+void unreachable_call() {
+#pragma omp target
+assert(0);
+}
+
 // CHECK-LABEL: define {{.*}}void {{@__omp_offloading_.+static.+347}}_worker()
 // CHECK-DAG: [[OMP_EXEC_STATUS:%.+]] = alloca i8,
 // CHECK-DAG: [[OMP_WORK_FN:%.+]] = alloca i8*,
@@ -632,6 +638,12 @@
 // CHECK: [[RES:%.+]] = load i32, i32* [[RET]],
 // CHECK: ret i32 [[RES]]
 
+// CHECK: define {{.*}}void {{@__omp_offloading_.+unreachable_call.+l399}}()
+// CHECK: call void @{{.*}}assert{{.*}}(i32 0)
+// CHECK: unreachable
+// CHECK: call void @__kmpc_kernel_deinit(i16 1)
+// CHECK: ret void
+
 // CHECK-LABEL: define {{.*}}void {{@__omp_offloading_.+template.+l331}}_worker()
 // CHECK-DAG: [[OMP_EXEC_STATUS:%.+]] = alloca i8,
 // CHECK-DAG: [[OMP_WORK_FN:%.+]] = alloca i8*,
Index: clang/lib/CodeGen/CGStmtOpenMP.cpp
===
--- clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -5742,6 +5742,7 @@
 CGF.CGM.getOpenMPRuntime().adjustTargetSpecificDataForLambdas(CGF, S);
 
   CGF.EmitStmt(S.getCapturedStmt(OMPD_target)->getCapturedStmt());
+  CGF.EnsureInsertPoint();
 }
 
 void CodeGenFunction::EmitOMPTargetDeviceFunction(CodeGenModule &CGM,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99344: [Analyzer] Track RValue expressions

2021-03-29 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 333848.
martong added a comment.

- Remove handling of assignment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99344

Files:
  clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
  clang/test/Analysis/division-by-zero-track-zero.c
  clang/test/Analysis/division-by-zero-track-zero.cpp
  clang/test/Analysis/nullptr.cpp

Index: clang/test/Analysis/nullptr.cpp
===
--- clang/test/Analysis/nullptr.cpp
+++ clang/test/Analysis/nullptr.cpp
@@ -64,7 +64,7 @@
 
 typedef __INTPTR_TYPE__ intptr_t;
 void zoo1multiply() {
-  char **p = 0; // FIXME-should-be-note:{{'p' initialized to a null pointer value}}
+  char **p = 0; // expected-note{{'p' initialized to a null pointer value}}
   delete *((char **)((intptr_t)p * 2)); // expected-warning{{Dereference of null pointer}}
// expected-note@-1{{Dereference of null pointer}}
 }
Index: clang/test/Analysis/division-by-zero-track-zero.cpp
===
--- /dev/null
+++ clang/test/Analysis/division-by-zero-track-zero.cpp
@@ -0,0 +1,98 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core \
+// RUN:   -analyzer-output=text \
+// RUN:   -verify %s
+
+namespace test_tracking_of_lhs_multiplier {
+  int f(int x, int y) {
+bool p0 = x < 0;  // expected-note {{Assuming 'x' is >= 0}} \
+  // expected-note {{'p0' initialized to 0}}
+int div = p0 * y; // expected-note {{'div' initialized to 0}}
+return 1 / div;   // expected-note {{Division by zero}} \
+  // expected-warning {{Division by zero}}
+  }
+} // namespace test_tracking_of_lhs_multiplier
+
+namespace test_tracking_of_rhs_multiplier {
+  int f(int x, int y) {
+bool p0 = x < 0;  // expected-note {{Assuming 'x' is >= 0}} \
+  // expected-note {{'p0' initialized to 0}}
+int div = y * p0; // expected-note {{'div' initialized to 0}}
+return 1 / div;   // expected-note {{Division by zero}} \
+  // expected-warning {{Division by zero}}
+  }
+} // namespace test_tracking_of_rhs_multiplier
+
+namespace test_tracking_of_nested_multiplier {
+  int f(int x, int y, int z) {
+bool p0 = x < 0;  // expected-note {{Assuming 'x' is >= 0}} \
+  // expected-note {{'p0' initialized to 0}}
+int div = y*z*p0; // expected-note {{'div' initialized to 0}}
+return 1 / div;   // expected-note {{Division by zero}} \
+  // expected-warning {{Division by zero}}
+  }
+} // namespace test_tracking_of_nested_multiplier
+
+namespace test_tracking_through_multiple_stmts {
+  int f(int x, int y) {
+bool p0 = x < 0;  // expected-note {{Assuming 'x' is >= 0}}
+bool p1 = p0 ? 0 : 1; // expected-note {{'p0' is false}} \
+  // expected-note {{'?' condition is false}}
+bool p2 = 1 - p1; // expected-note {{'p2' initialized to 0}}
+int div = p2 * y; // expected-note {{'div' initialized to 0}}
+return 1 / div;   // expected-note {{Division by zero}} \
+  // expected-warning {{Division by zero}}
+  }
+} // namespace test_tracking_through_multiple_stmts
+
+namespace test_tracking_both_lhs_and_rhs {
+  int f(int x, int y) {
+bool p0 = x < 0;   // expected-note {{Assuming 'x' is >= 0}} \
+   // expected-note {{'p0' initialized to 0}}
+bool p1 = y < 0;   // expected-note {{Assuming 'y' is >= 0}} \
+   // expected-note {{'p1' initialized to 0}}
+int div = p0 * p1; // expected-note {{'div' initialized to 0}}
+return 1 / div;// expected-note {{Division by zero}} \
+   // expected-warning {{Division by zero}}
+  }
+} // namespace test_tracking_both_lhs_and_rhs
+
+namespace test_tracking_of_multiplier_and_parens {
+  int f(int x, int y, int z) {
+bool p0 = x < 0;// expected-note {{Assuming 'x' is >= 0}} \
+// expected-note {{'p0' initialized to 0}}
+int div = y*(z*p0); // expected-note {{'div' initialized to 0}}
+return 1 / div; // expected-note {{Division by zero}} \
+// expected-warning {{Division by zero}}
+  }
+} // namespace test_tracking_of_multiplier_and_parens
+
+namespace test_tracking_of_divisible {
+  int f(int x, int y) {
+bool p0 = x < 0;// expected-note {{Assuming 'x' is >= 0}} \
+// expected-note {{'p0' initialized to 0}}
+int div = p0 / y;   // expected-note {{'div' initialized to 0}}
+return 1 / div; // expected-note {{Division by zero}} \
+// expected-warning {{Division by zero}}
+  }
+} // namespace test_tracking_of_divisible
+
+namespace test_tracking_of_modulo {
+  int f(int x, int y) {
+bool p0 = x < 0;// expected-note {{Assuming 'x' is >= 0}} \

[PATCH] D99344: [Analyzer] Track RValue expressions

2021-03-29 Thread Gabor Marton via Phabricator via cfe-commits
martong marked an inline comment as done.
martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:1944-1945
+return;
+  if (!BO->isMultiplicativeOp())
+return;
+

steakhal wrote:
> There are only 3 multiplicative operators:
> ```
> BINARY_OPERATION(Mul, "*")
> BINARY_OPERATION(Div, "/")
> BINARY_OPERATION(Rem, "%")
> ```
> So, the opcode can never be `BO_MulAssign` later.
> The comment for the else block is also inaccurate for the same reason.
Yep, good catch! The reason why the assignment test case passed is that we 
already handle assignment operations in the `FindLastStoreBRVisitor`.

// If this is an assignment expression, we can track the value
// being assigned.
if (Optional P = Succ->getLocationAs())
  if (const BinaryOperator *BO = P->getStmtAs())
if (BO->isAssignmentOp())
  InitE = BO->getRHS();

So, I could just remove the handling of the assignment from the new function.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99344

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


[PATCH] D99152: [AMX] Prototype for vector and amx bitcast.

2021-03-29 Thread LuoYuanke via Phabricator via cfe-commits
LuoYuanke added a comment.

> I think that point was not really clear during the discussion. Using `load 
> <256 x i32>` to lower `__tile_loadd() ` would indeed be incorrect. But I 
> don't think that's happening at the moment, at least going from a simple 
> example https://gcc.godbolt.org/z/KT5rczn8j

The `load/store <256 x i32>` is generated by front-end, because in C language 
tile is a vector <256 x i32>. The `load/store <256 x i32>` is transformed to 
`llvm.x86.tileloadd64.internal/llvm.x86.tilestored64.internal` in 
`lib/Target/X86/X86LowerAMXType.cpp` if the load result is to be an operand of 
amx intrinsics or the store value is returned from amx intrinsics.

>   void foo() {
> tilea = __builtin_ia32_tileloadd64_internal(16, 64, buf, 64);
>   }
>
> is lowered to
>
>   define dso_local void @foo() #0 {
> %1 = call x86_amx @llvm.x86.tileloadd64.internal(i16 16, i16 64, i8* 
> getelementptr inbounds ([1024 x i8], [1024 x i8]* @buf, i64 0, i64 0), i64 64)
> %2 = bitcast x86_amx %1 to <256 x i32>
> store <256 x i32> %2, <256 x i32>* @tilea, align 64
> ret void
>   }
>
> So we emit an intrinsic to do the strided load and the result is stored to 
> continuous memory, which is what the type `_tile1024i` requires. What's not 
> modeled correctly is the conversion between the result of 
> `@llvm.x86.tileloadd64.internal` and the `store`. It needs to be transferred 
> in a flat vector.

Yes.  I agree that it needs to be transferred in a flat vector.

> Whether we should have `x86_amx` in the first place is a separate question I 
> think. Having a builtin type that does not work properly with fundamental 
> instructions like `load` or `store` seems prone for errors (what instructions 
> actually work with `x86_amx`? Do binary operators work?). Perhaps it would be 
> possible and sufficient to have the intrinsics use an opaque type instead of 
> a builtin type, like

We only support tileload, tilestore, tilezero, tiletdp (dot product) 
instructions/intrinsics for `x86_amx`. Is there any opaque type example llvm 
source code for builtin? This example has some error at 
https://gcc.godbolt.org/z/ar6WhjTMz.

>   %my_x86_amx = type opaque
>   
>   define %my_x86_amx @foo(%my_x86_amx %x) {
> ret %my_x86_amx %x
>   }
>
> But I think we should address those 2 issues separately and fix the biggest 
> problem (mis-use of `bitcast`) first, perhaps followed up by verifier rules 
> rejecting `x86_amx` from un-suitable instructions and go from there.

I may further implement this patch and transform/eliminate 
@llvm.x86.vector.amx.cast in `lib/Target/X86/X86LowerAMXType.cpp` which is 
before codegen. There is some effort to implement it, but I'd like to take a 
try.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99152

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


[clang] 0858f0e - [SystemZ][z/OS] Set maximum value to truncate attribute aligned to for static variables on z/OS target

2021-03-29 Thread Fanbo Meng via cfe-commits

Author: Fanbo Meng
Date: 2021-03-29T09:44:33-04:00
New Revision: 0858f0e09e33f62fc1dcc45e0bdec47eee1e23ba

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

LOG: [SystemZ][z/OS] Set maximum value to truncate attribute aligned to for 
static variables on z/OS target

On z/OS there is a hard limitation on on the maximum requestable alignment in 
aligned attribute for static variables. We need to truncate values greater than 
that.

Reviewed By: abhina.sreeskantharajan

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

Added: 


Modified: 
clang/include/clang/Basic/TargetInfo.h
clang/lib/AST/ASTContext.cpp
clang/lib/Basic/TargetInfo.cpp
clang/lib/Basic/Targets/OSTargets.h
clang/test/CodeGen/SystemZ/zos-alignment.c

Removed: 




diff  --git a/clang/include/clang/Basic/TargetInfo.h 
b/clang/include/clang/Basic/TargetInfo.h
index 01ca9ca0d2a8..3ddb706dcf52 100644
--- a/clang/include/clang/Basic/TargetInfo.h
+++ b/clang/include/clang/Basic/TargetInfo.h
@@ -165,6 +165,10 @@ struct TransferrableTargetInfo {
   /// If non-zero, specifies a fixed alignment value for bitfields that follow
   /// zero length bitfield, regardless of the zero length bitfield type.
   unsigned ZeroLengthBitfieldBoundary;
+
+  /// If non-zero, specifies a maximum alignment to truncate alignment
+  /// specified in the aligned attribute of a static variable to this value.
+  unsigned MaxAlignedAttribute;
 };
 
 /// OpenCL type kinds.
@@ -784,6 +788,10 @@ class TargetInfo : public virtual TransferrableTargetInfo,
 return ZeroLengthBitfieldBoundary;
   }
 
+  /// Get the maximum alignment in bits for a static variable with
+  /// aligned attribute.
+  unsigned getMaxAlignedAttribute() const { return MaxAlignedAttribute; }
+
   /// Check whether explicit bitfield alignment attributes should be
   //  honored, as in "__attribute__((aligned(2))) int b : 1;".
   bool useExplicitBitFieldAlignment() const {

diff  --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp
index d52aea88e092..c824bcfa0866 100644
--- a/clang/lib/AST/ASTContext.cpp
+++ b/clang/lib/AST/ASTContext.cpp
@@ -1783,6 +1783,13 @@ CharUnits ASTContext::getDeclAlign(const Decl *D, bool 
ForAlignof) const {
 }
   }
 
+  // Some targets have hard limitation on the maximum requestable alignment in
+  // aligned attribute for static variables.
+  const unsigned MaxAlignedAttr = getTargetInfo().getMaxAlignedAttribute();
+  const auto *VD = dyn_cast(D);
+  if (MaxAlignedAttr && VD && VD->getStorageClass() == SC_Static)
+Align = std::min(Align, MaxAlignedAttr);
+
   return toCharUnitsFromBits(Align);
 }
 

diff  --git a/clang/lib/Basic/TargetInfo.cpp b/clang/lib/Basic/TargetInfo.cpp
index 468c8a24498a..1783da8f9cfd 100644
--- a/clang/lib/Basic/TargetInfo.cpp
+++ b/clang/lib/Basic/TargetInfo.cpp
@@ -107,6 +107,7 @@ TargetInfo::TargetInfo(const llvm::Triple &T) : 
TargetOpts(), Triple(T) {
   UseLeadingZeroLengthBitfield = true;
   UseExplicitBitFieldAlignment = true;
   ZeroLengthBitfieldBoundary = 0;
+  MaxAlignedAttribute = 0;
   HalfFormat = &llvm::APFloat::IEEEhalf();
   FloatFormat = &llvm::APFloat::IEEEsingle();
   DoubleFormat = &llvm::APFloat::IEEEdouble();

diff  --git a/clang/lib/Basic/Targets/OSTargets.h 
b/clang/lib/Basic/Targets/OSTargets.h
index 568f759bfa0d..6e757adfa8bf 100644
--- a/clang/lib/Basic/Targets/OSTargets.h
+++ b/clang/lib/Basic/Targets/OSTargets.h
@@ -794,6 +794,7 @@ class LLVM_LIBRARY_VISIBILITY ZOSTargetInfo : public 
OSTargetInfo {
   ZOSTargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
   : OSTargetInfo(Triple, Opts) {
 this->WCharType = TargetInfo::UnsignedInt;
+this->MaxAlignedAttribute = 128;
 this->UseBitFieldTypeAlignment = false;
 this->UseZeroLengthBitfieldAlignment = true;
 this->UseLeadingZeroLengthBitfield = false;

diff  --git a/clang/test/CodeGen/SystemZ/zos-alignment.c 
b/clang/test/CodeGen/SystemZ/zos-alignment.c
index 703fd1a46c3b..9371a54403e4 100644
--- a/clang/test/CodeGen/SystemZ/zos-alignment.c
+++ b/clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -1,4 +1,16 @@
-// RUN: %clang_cc1 -emit-llvm-only -triple s390x-none-zos 
-fdump-record-layouts %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm-only -triple s390x-none-zos 
-fdump-record-layouts %s | FileCheck %s --check-prefix=CHECK
+// RUN: %clang_cc1 -emit-llvm -triple s390x-none-zos %s -o - | FileCheck %s 
--check-prefix=DECL
+
+static int __attribute__((aligned(32))) v0;
+int __attribute__((aligned(32))) v1;
+typedef int __attribute__((aligned(32))) int32;
+static int32 v2;
+int32 v3;
+int f0() { return v0 + v1 + v2 + v3; }
+// DECL:  @v0 {{.*}} align 16
+// DECL-NEXT: @v1 {{.*}} align 32
+// DECL-NEXT: @v2 {{.*}} align 16
+// DECL-NEXT: @v3 {{.*}} align 32
 
 struct s0 {
 

[PATCH] D98864: [SystemZ][z/OS] Set maximum value to truncate attribute aligned to for static variables on z/OS target

2021-03-29 Thread Fanbo Meng 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 rG0858f0e09e33: [SystemZ][z/OS] Set maximum value to truncate 
attribute aligned to for static… (authored by fanbo-meng).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98864

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/OSTargets.h
  clang/test/CodeGen/SystemZ/zos-alignment.c


Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -1,4 +1,16 @@
-// RUN: %clang_cc1 -emit-llvm-only -triple s390x-none-zos 
-fdump-record-layouts %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm-only -triple s390x-none-zos 
-fdump-record-layouts %s | FileCheck %s --check-prefix=CHECK
+// RUN: %clang_cc1 -emit-llvm -triple s390x-none-zos %s -o - | FileCheck %s 
--check-prefix=DECL
+
+static int __attribute__((aligned(32))) v0;
+int __attribute__((aligned(32))) v1;
+typedef int __attribute__((aligned(32))) int32;
+static int32 v2;
+int32 v3;
+int f0() { return v0 + v1 + v2 + v3; }
+// DECL:  @v0 {{.*}} align 16
+// DECL-NEXT: @v1 {{.*}} align 32
+// DECL-NEXT: @v2 {{.*}} align 16
+// DECL-NEXT: @v3 {{.*}} align 32
 
 struct s0 {
   short a:3;
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -794,6 +794,7 @@
   ZOSTargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
   : OSTargetInfo(Triple, Opts) {
 this->WCharType = TargetInfo::UnsignedInt;
+this->MaxAlignedAttribute = 128;
 this->UseBitFieldTypeAlignment = false;
 this->UseZeroLengthBitfieldAlignment = true;
 this->UseLeadingZeroLengthBitfield = false;
Index: clang/lib/Basic/TargetInfo.cpp
===
--- clang/lib/Basic/TargetInfo.cpp
+++ clang/lib/Basic/TargetInfo.cpp
@@ -107,6 +107,7 @@
   UseLeadingZeroLengthBitfield = true;
   UseExplicitBitFieldAlignment = true;
   ZeroLengthBitfieldBoundary = 0;
+  MaxAlignedAttribute = 0;
   HalfFormat = &llvm::APFloat::IEEEhalf();
   FloatFormat = &llvm::APFloat::IEEEsingle();
   DoubleFormat = &llvm::APFloat::IEEEdouble();
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -1783,6 +1783,13 @@
 }
   }
 
+  // Some targets have hard limitation on the maximum requestable alignment in
+  // aligned attribute for static variables.
+  const unsigned MaxAlignedAttr = getTargetInfo().getMaxAlignedAttribute();
+  const auto *VD = dyn_cast(D);
+  if (MaxAlignedAttr && VD && VD->getStorageClass() == SC_Static)
+Align = std::min(Align, MaxAlignedAttr);
+
   return toCharUnitsFromBits(Align);
 }
 
Index: clang/include/clang/Basic/TargetInfo.h
===
--- clang/include/clang/Basic/TargetInfo.h
+++ clang/include/clang/Basic/TargetInfo.h
@@ -165,6 +165,10 @@
   /// If non-zero, specifies a fixed alignment value for bitfields that follow
   /// zero length bitfield, regardless of the zero length bitfield type.
   unsigned ZeroLengthBitfieldBoundary;
+
+  /// If non-zero, specifies a maximum alignment to truncate alignment
+  /// specified in the aligned attribute of a static variable to this value.
+  unsigned MaxAlignedAttribute;
 };
 
 /// OpenCL type kinds.
@@ -784,6 +788,10 @@
 return ZeroLengthBitfieldBoundary;
   }
 
+  /// Get the maximum alignment in bits for a static variable with
+  /// aligned attribute.
+  unsigned getMaxAlignedAttribute() const { return MaxAlignedAttribute; }
+
   /// Check whether explicit bitfield alignment attributes should be
   //  honored, as in "__attribute__((aligned(2))) int b : 1;".
   bool useExplicitBitFieldAlignment() const {


Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -1,4 +1,16 @@
-// RUN: %clang_cc1 -emit-llvm-only -triple s390x-none-zos -fdump-record-layouts %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm-only -triple s390x-none-zos -fdump-record-layouts %s | FileCheck %s --check-prefix=CHECK
+// RUN: %clang_cc1 -emit-llvm -triple s390x-none-zos %s -o - | FileCheck %s --check-prefix=DECL
+
+static int __attribute__((aligned(32))) v0;
+int __attribute__((aligned(32))) v1;
+typedef int __attribute__((aligned(32))) int32;
+static int32 v2;
+int32 v3;
+int f0() { return v0 + v1 + v2 + v3; }
+// DECL:  @v0 {{.*}} align 16
+// DECL-

[PATCH] D99421: [ASTImporter] Import member specialization/instantiation of enum decls

2021-03-29 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added inline comments.



Comment at: clang/unittests/AST/ASTImporterTest.cpp:6239
 
+TEST_P(ASTImporterOptionSpecificTestBase, ImportEnumMemberSpecializtion) {
+  Decl *FromTU = getTuDecl(




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99421

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


[PATCH] D99488: [SYCL][Doc] Add address space handling section to SYCL documentation

2021-03-29 Thread Alexey Bader via Phabricator via cfe-commits
bader updated this revision to Diff 333853.
bader added a comment.

Applied code review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99488

Files:
  clang/docs/SYCLSupport.md

Index: clang/docs/SYCLSupport.md
===
--- clang/docs/SYCLSupport.md
+++ clang/docs/SYCLSupport.md
@@ -813,6 +813,111 @@
 The SPIR-V specific functions are implemented in for the SYCL host device here:
 `sycl/source/spirv_ops.cpp`.
 
+### Address spaces handling
+
+SYCL specification uses C++ classes to represent pointers to disjoint memory
+regions on an accelerator to enable compilation with standard C++ toolchain and
+SYCL compiler toolchain. Section 3.8.2 of SYCL 2020 specification defines
+[memory model](https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_sycl_device_memory_model),
+section 4.7.7 - [address space classes](https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_address_space_classes)
+and section 5.9 covers [address space deduction](https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_address_space_deduction).
+
+The main address space semantic difference of SYCL mode from OpenCL is that
+SYCL doesn't perform address space qualifier inference detailed in
+[OpenCL C v3.0 s6.7.8](https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#addr-spaces-inference).
+
+Similar to other single-source C++-based GPU programming modes like
+OpenMP/CUDA/HIP, SYCL uses clang's "default" address space for types with no
+address space attributes. This design has two important features: keeps the type system consistent with C++ on one hand and enable tools for emitting device code aligned with SPIR memory model (and other GPU targets).
+
+So inside a function, this variable declaration:
+
+```C++
+int var;
+```
+
+SYCL device compiler turns into
+
+```C++
+VarDecl  var 'int'
+```
+
+OpenCL compiler turn into
+
+```C++
+VarDecl  var '__private int'
+```
+
+Changing variable type has massive and destructive effect in C++. For instance
+this does not compile in C++ for OpenCL mode:
+
+```C++
+template
+struct is_same {
+  static constexpr int value = 0;
+};
+
+template
+struct is_same {
+  static constexpr int value = 1;
+};
+
+void foo(int p) {
+  static_assert(is_same::value, "int is not an int?"); // Fails: p is '__private int' != 'int'
+  static_assert(is_same::value, "int* is not an int*?");  // Fails: p is '__private int*' != '__generic int*'
+}
+```
+
+`multi_ptr` class implementation example:
+
+``` C++
+// check that SYCL mode is ON and we can use non-standard decorations
+#if defined(__SYCL_DEVICE_ONLY__)
+// GPU/accelerator implementation
+template  class multi_ptr {
+  // DecoratedType applies corresponding address space attribute to the type T
+  // DecoratedType::type == "__attribute__((opencl_global)) T"
+  // See sycl/include/CL/sycl/access/access.hpp for more details
+  using pointer_t = typename DecoratedType::type *;
+
+  pointer_t m_Pointer;
+  public:
+  pointer_t get() { return m_Pointer; }
+  T& operator* () { return *reinterpret_cast(m_Pointer); }
+}
+#else
+// CPU/host implementation
+template  class multi_ptr {
+  T *m_Pointer; // regular undecorated pointer
+  public:
+  T *get() { return m_Pointer; }
+  T& operator* () { return *m_Pointer; }
+}
+#endif
+```
+
+Depending on the compiler mode `multi_ptr` will either decorate internal data
+with address space attribute or not.
+
+To utilize existing clang's functionality, we re-use following OpenCL address
+space attributes for decoration pointers implementation:
+
+| Address space attribute | SYCL address_space enumeration |
+|-||
+| `__attribute__((opencl_global))` | global_space, constant_space |
+| `__attribute__((opencl_local))` | local_space |
+| `__attribute__((opencl_private))` | private_space |
+
+TODO: add support for `__attribute__((opencl_global_host))` and
+`__attribute__((opencl_global_device))`.
+
+Default address space represents "Generic-memory", which is a virtual address
+space which overlaps the global, local and private address spaces. SYCL mode
+enables conversion to/from default address space from/to address space
+attributed type.
+
+SPIR target allocates SYCL namespace scope variables in global address space.
+
 ### Compiler/Runtime interface
 
 ## SYCL Runtime architecture
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99190: WIP: [SYCL] Add design document for SYCL mode

2021-03-29 Thread Alexey Bader via Phabricator via cfe-commits
bader marked 8 inline comments as done.
bader added a comment.

@Anastasia, I've addressed the comments for the address space section in 
https://reviews.llvm.org/D99488. Let's move discussion there.




Comment at: clang/docs/SYCLSupport.md:861
+space for types with no address space attributes. During the lowering to LLVM
+IR, the default address space is mapped to the SPIR generic address space.
+Declarations are assigned to the relevant memory region depending on their

Anastasia wrote:
> Ok this is an implementation details but from the language sematic it would 
> be good to describe what logic you are expecting.
> 
> So `Default` address space is primarily used for C/C++ flat memory which 
> means everything in standard C or C++ will be  in `Default` and this is where 
> the local memory is allocated too.
> 
> ```
> When not specified otherwise, objects are allocated by default in a generic 
> address space, which corresponds to the single address space of ISO/IEC 
> 9899:1999.
> 
> ```
> I am guessing this doesn't entirely apply to SYCL? I think this would be 
> important to clarify so it is clear what your semantic of `Default` is. It 
> would make sense to reference OpenCL generic address space or any other 
> documentation if you want to be concise.
I hope that the language semantics defined by the SYCL specification is clear 
enough. Please, see 
https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_address_space_deduction
 for details. The only thing left for implementation to define is address space 
assignment for namespace scope variables. I've added a clarification for that 
at the end of the paragraph.



Comment at: clang/docs/SYCLSupport.md:863
+Declarations are assigned to the relevant memory region depending on their
+declaration context and pointers to them are cast to generic. This design has
+two important features: keeps the type system consistent with C++ on one hand

Anastasia wrote:
> Ok, I suggested to lift this to where you describe the inference. It would be 
> good to elaborate on what objects are bound to what memory segments. You 
> might also refer to OpenCL spec since I believe the memory segments are 
> fairly similar. 
> 
> Can you explain this point a bit more `and pointers to them are cast to 
> generic`? Having an example might help too.
This is a description of how CodeGen library implements Target hooks like 
`getGlobalVarAddressSpace`/`getASTAllocaAddressSpace`. As it's not related to 
SYCL, I just removed this confusing sentence.



Comment at: clang/docs/SYCLSupport.md:864
+declaration context and pointers to them are cast to generic. This design has
+two important features: keeps the type system consistent with C++ on one hand
+and enable tools for emitting device code aligned with SPIR memory model (and

Anastasia wrote:
> Ok, I would put the design goals to the top. 
> 
> Btw I am not sure this is the case "keeps the type system consistent with 
> C++" since your semantic of default address spaces is different to C++. 
> Perhaps you can elaborate more what it means...
Moved right after the links to SYCL specification.

> Btw I am not sure this is the case "keeps the type system consistent with 
> C++" your semantic of default address spaces is different to C++

The point here is that SYCL compiler doesn't change standard C++ types by 
assigning non-default address space attribute implicitly. That way C++ types 
not using extensions are left intact.



Comment at: clang/docs/SYCLSupport.md:886
+
+Changing variable type has massive and destructive effect in C++. For instance
+this does not compile in C++ for OpenCL mode:

Anastasia wrote:
> I don't understand what is the message of this paragraph. The example 
> compiles in accordance with OpenCL language semantic... Perhaps you can 
> elaborate more.
This example demonstrates the problem with compiling C++ code when address 
space type qualifiers are inferred.

> The example compiles in accordance with OpenCL language semantic...

https://godbolt.org/z/9jzxK5xc4 - ToT clang doesn't compile this example.



Comment at: clang/docs/SYCLSupport.md:919
+> **NOTE**: although SYCL device compiler supports
+`__attribute__((opencl_constant))`, the use of this attribute is limited within
+SYCL implementation. An OpenCL constant pointer can not be casted to a pointer

Anastasia wrote:
> I am not sure what limited means? I would suggest being more specific and 
> state something like that there is no binding to the constant memory region. 
> Unless this is something that you intend to support later?
I removed this confusing section. It describes the functionality, which is not 
being considered for upstream yet.



Comment at: clang/docs/SYCLSupport.md:922
+with any other address space (including default).
+
+### Compiler/Runti

[PATCH] D99432: [OPENMP]Fix PR48851: the locals are not globalized in SPMD mode.

2021-03-29 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D99432#2654025 , @jdoerfert wrote:

> In D99432#2653483 , @ABataev wrote:
>
>> In D99432#2653474 , @jdoerfert 
>> wrote:
>>
>>> Can we please always do the globalization, even in the `target teams 
>>> distribute parallel for` case you need it if a thread shares the address of 
>>> a local variable with the team and another thread uses it.
>>
>> Could you give a small example so I could better understand the problem?
>
> I didn't fine my old example, this should do though:
> https://godbolt.org/z/b7axxzxEf
>
> On the host or host offload I see:
> Mine: 0, Other: 42
>
> On a GPU I see:
> CUDA error: Error when synchronizing stream. stream = 0x4294db40, 
> async info ptr = 0x7fffdd939838
> CUDA error: an illegal memory access was encountered
>
>> Shall we globalize the variable in SPMD mode if we pass it by reference/take 
>> address in any case?
>
> Yes. I think that is strictly speaking necessary. We should commit it 
> together with the patches that "undo" globalization though.
>
>>> There is no argument other than "doesn't escape" that Clang can make to 
>>> disprove globalization is needed, IMHO.

It would be better to implement this in a separate patch. Let's fix the bug 
first and then implement the common functionality for locals globalization in 
SPMD mode (probably controlled by the compiler option/flag).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99432

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


[clang] f6f21dc - [OPENMP]Fix PR49636: Assertion `(!Entry.getAddress() || Entry.getAddress() == Addr) && "Resetting with the new address."' failed.

2021-03-29 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2021-03-29T06:55:57-07:00
New Revision: f6f21dcd6c2fa8e44d8c466c5db190aef42beef2

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

LOG: [OPENMP]Fix PR49636: Assertion `(!Entry.getAddress() || Entry.getAddress() 
== Addr) && "Resetting with the new address."' failed.

The original issue is caused by the fact that the variable is allocated
with incorrect type i1 instead of i8. This causes the bitcasting of the
declaration to i8 type and the bitcast expression does not match the
original variable.
To fix the problem, the UndefValue initializer and the original
variable should be emitted with type i8, not i1.

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

Added: 


Modified: 
clang/lib/CodeGen/CodeGenModule.cpp
clang/test/OpenMP/declare_target_codegen.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 3a197e85ef7b..f719f009ea99 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -4256,9 +4256,9 @@ void CodeGenModule::EmitGlobalVarDefinition(const VarDecl 
*D,
D->getType()->isCUDADeviceBuiltinTextureType());
   if (getLangOpts().CUDA &&
   (IsCUDASharedVar || IsCUDAShadowVar || IsCUDADeviceShadowVar))
-Init = llvm::UndefValue::get(getTypes().ConvertType(ASTTy));
+Init = llvm::UndefValue::get(getTypes().ConvertTypeForMem(ASTTy));
   else if (D->hasAttr())
-Init = llvm::UndefValue::get(getTypes().ConvertType(ASTTy));
+Init = llvm::UndefValue::get(getTypes().ConvertTypeForMem(ASTTy));
   else if (!InitExpr) {
 // This is a tentative definition; tentative definitions are
 // implicitly initialized with { 0 }.

diff  --git a/clang/test/OpenMP/declare_target_codegen.cpp 
b/clang/test/OpenMP/declare_target_codegen.cpp
index 1ce211a34d5f..4b9bb41bd917 100644
--- a/clang/test/OpenMP/declare_target_codegen.cpp
+++ b/clang/test/OpenMP/declare_target_codegen.cpp
@@ -26,6 +26,7 @@
 // CHECK-NOT: define {{.*}}{{baz1|baz4|maini1|Base|virtual_}}
 // CHECK-DAG: Bake
 // CHECK-NOT: @{{hhh|ggg|fff|eee}} =
+// CHECK-DAG: @flag = hidden global i8 undef,
 // CHECK-DAG: @aaa = external global i32,
 // CHECK-DAG: @bbb ={{ hidden | }}global i32 0,
 // CHECK-DAG: weak constant %struct.__tgt_offload_entry { i8* bitcast (i32* 
@bbb to i8*),
@@ -53,8 +54,8 @@
 
 #ifndef HEADER
 #define HEADER
-
 #pragma omp declare target
+bool flag [[clang::loader_uninitialized]];
 extern int bbb;
 #pragma omp end declare target
 #pragma omp declare target



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


[PATCH] D99297: [OPENMP]Fix PR49636: Assertion `(!Entry.getAddress() || Entry.getAddress() == Addr) && "Resetting with the new address."' failed.

2021-03-29 Thread Alexey Bataev 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 rGf6f21dcd6c2f: [OPENMP]Fix PR49636: Assertion 
`(!Entry.getAddress() || Entry.getAddress() ==… (authored by ABataev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99297

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/OpenMP/declare_target_codegen.cpp


Index: clang/test/OpenMP/declare_target_codegen.cpp
===
--- clang/test/OpenMP/declare_target_codegen.cpp
+++ clang/test/OpenMP/declare_target_codegen.cpp
@@ -26,6 +26,7 @@
 // CHECK-NOT: define {{.*}}{{baz1|baz4|maini1|Base|virtual_}}
 // CHECK-DAG: Bake
 // CHECK-NOT: @{{hhh|ggg|fff|eee}} =
+// CHECK-DAG: @flag = hidden global i8 undef,
 // CHECK-DAG: @aaa = external global i32,
 // CHECK-DAG: @bbb ={{ hidden | }}global i32 0,
 // CHECK-DAG: weak constant %struct.__tgt_offload_entry { i8* bitcast (i32* 
@bbb to i8*),
@@ -53,8 +54,8 @@
 
 #ifndef HEADER
 #define HEADER
-
 #pragma omp declare target
+bool flag [[clang::loader_uninitialized]];
 extern int bbb;
 #pragma omp end declare target
 #pragma omp declare target
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -4256,9 +4256,9 @@
D->getType()->isCUDADeviceBuiltinTextureType());
   if (getLangOpts().CUDA &&
   (IsCUDASharedVar || IsCUDAShadowVar || IsCUDADeviceShadowVar))
-Init = llvm::UndefValue::get(getTypes().ConvertType(ASTTy));
+Init = llvm::UndefValue::get(getTypes().ConvertTypeForMem(ASTTy));
   else if (D->hasAttr())
-Init = llvm::UndefValue::get(getTypes().ConvertType(ASTTy));
+Init = llvm::UndefValue::get(getTypes().ConvertTypeForMem(ASTTy));
   else if (!InitExpr) {
 // This is a tentative definition; tentative definitions are
 // implicitly initialized with { 0 }.


Index: clang/test/OpenMP/declare_target_codegen.cpp
===
--- clang/test/OpenMP/declare_target_codegen.cpp
+++ clang/test/OpenMP/declare_target_codegen.cpp
@@ -26,6 +26,7 @@
 // CHECK-NOT: define {{.*}}{{baz1|baz4|maini1|Base|virtual_}}
 // CHECK-DAG: Bake
 // CHECK-NOT: @{{hhh|ggg|fff|eee}} =
+// CHECK-DAG: @flag = hidden global i8 undef,
 // CHECK-DAG: @aaa = external global i32,
 // CHECK-DAG: @bbb ={{ hidden | }}global i32 0,
 // CHECK-DAG: weak constant %struct.__tgt_offload_entry { i8* bitcast (i32* @bbb to i8*),
@@ -53,8 +54,8 @@
 
 #ifndef HEADER
 #define HEADER
-
 #pragma omp declare target
+bool flag [[clang::loader_uninitialized]];
 extern int bbb;
 #pragma omp end declare target
 #pragma omp declare target
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -4256,9 +4256,9 @@
D->getType()->isCUDADeviceBuiltinTextureType());
   if (getLangOpts().CUDA &&
   (IsCUDASharedVar || IsCUDAShadowVar || IsCUDADeviceShadowVar))
-Init = llvm::UndefValue::get(getTypes().ConvertType(ASTTy));
+Init = llvm::UndefValue::get(getTypes().ConvertTypeForMem(ASTTy));
   else if (D->hasAttr())
-Init = llvm::UndefValue::get(getTypes().ConvertType(ASTTy));
+Init = llvm::UndefValue::get(getTypes().ConvertTypeForMem(ASTTy));
   else if (!InitExpr) {
 // This is a tentative definition; tentative definitions are
 // implicitly initialized with { 0 }.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99152: [AMX] Prototype for vector and amx bitcast.

2021-03-29 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a comment.

In D99152#2655691 , @LuoYuanke wrote:

>> I think that point was not really clear during the discussion. Using `load 
>> <256 x i32>` to lower `__tile_loadd() ` would indeed be incorrect. But I 
>> don't think that's happening at the moment, at least going from a simple 
>> example https://gcc.godbolt.org/z/KT5rczn8j
>
> The `load/store <256 x i32>` is generated by front-end, because in C language 
> tile is a vector <256 x i32>. The `load/store <256 x i32>` is transformed to 
> `llvm.x86.tileloadd64.internal/llvm.x86.tilestored64.internal` in 
> `lib/Target/X86/X86LowerAMXType.cpp` if the load result is to be an operand 
> of amx intrinsics or the store value is returned from amx intrinsics.

Sure, you can get rid of unnecessary conversions/loads/stores during 
optimizations, if you can operate on AMX tiles directly and do not need to 
store the intermediate results in flat vectors. You can also use strided 
loads/stores to store continuous memory (no stride between columns/rows). But 
what optimizations are applied later do not impact the whether IR emitted by 
Clang is correct or now. It always needs to be correct. Whether to further 
optimizations are correct is a different problem, but we need a specification 
for the builtins, intrinsics and the type before going any further in that 
direction.

>>   void foo() {
>> tilea = __builtin_ia32_tileloadd64_internal(16, 64, buf, 64);
>>   }
>>
>> is lowered to
>>
>>   define dso_local void @foo() #0 {
>> %1 = call x86_amx @llvm.x86.tileloadd64.internal(i16 16, i16 64, i8* 
>> getelementptr inbounds ([1024 x i8], [1024 x i8]* @buf, i64 0, i64 0), i64 
>> 64)
>> %2 = bitcast x86_amx %1 to <256 x i32>
>> store <256 x i32> %2, <256 x i32>* @tilea, align 64
>> ret void
>>   }
>>
>> So we emit an intrinsic to do the strided load and the result is stored to 
>> continuous memory, which is what the type `_tile1024i` requires. What's not 
>> modeled correctly is the conversion between the result of 
>> `@llvm.x86.tileloadd64.internal` and the `store`. It needs to be transferred 
>> in a flat vector.
>
> Yes.  I agree that it needs to be transferred in a flat vector.
>
>> Whether we should have `x86_amx` in the first place is a separate question I 
>> think. Having a builtin type that does not work properly with fundamental 
>> instructions like `load` or `store` seems prone for errors (what 
>> instructions actually work with `x86_amx`? Do binary operators work?). 
>> Perhaps it would be possible and sufficient to have the intrinsics use an 
>> opaque type instead of a builtin type, like
>
> We only support tileload, tilestore, tilezero, tiletdp (dot product) 
> instructions/intrinsics for `x86_amx`. Is there any opaque type example llvm 
> source code for builtin? This example has some error at 
> https://gcc.godbolt.org/z/ar6WhjTMz.

I think you need to set the input to `LLVM IR`: 
https://gcc.godbolt.org/z/WexMjsas9

You should be able to use opaque types with overloaded intrinsics. I don't 
think you define an intrinsic to take a specific opaque type (because it's not 
known up front).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99152

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


[PATCH] D99421: [ASTImporter] Import member specialization/instantiation of enum decls

2021-03-29 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 333858.
martong marked an inline comment as done.
martong added a comment.

- Fix typo


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99421

Files:
  clang/lib/AST/ASTImporter.cpp
  clang/unittests/AST/ASTImporterTest.cpp


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -6236,6 +6236,26 @@
   EXPECT_NE(FromFD->getCapturedVLAType(), ToFD->getCapturedVLAType());
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase, ImportEnumMemberSpecialization) {
+  Decl *FromTU = getTuDecl(
+  R"(
+  template  struct A {
+enum tagname { enumerator };
+  };
+  template struct A;
+  )",
+  Lang_CXX03);
+  auto *FromD = FirstDeclMatcher().match(
+  FromTU, enumDecl(hasName("tagname"),
+   hasParent(classTemplateSpecializationDecl(;
+  ASSERT_TRUE(FromD);
+  ASSERT_TRUE(FromD->getMemberSpecializationInfo());
+
+  auto *ToD = Import(FromD, Lang_CXX03);
+  EXPECT_TRUE(ToD);
+  EXPECT_TRUE(ToD->getMemberSpecializationInfo());
+}
+
 INSTANTIATE_TEST_CASE_P(ParameterizedTests, ASTImporterLookupTableTest,
 DefaultTestValuesForRunOptions, );
 
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -2732,7 +2732,20 @@
   D2->setBraceRange(ToBraceRange);
   D2->setAccess(D->getAccess());
   D2->setLexicalDeclContext(LexicalDC);
-  LexicalDC->addDeclInternal(D2);
+  addDeclToContexts(D, D2);
+
+  if (MemberSpecializationInfo *MemberInfo = D->getMemberSpecializationInfo()) 
{
+TemplateSpecializationKind SK = 
MemberInfo->getTemplateSpecializationKind();
+EnumDecl *FromInst = D->getInstantiatedFromMemberEnum();
+if (Expected ToInstOrErr = import(FromInst))
+  D2->setInstantiationOfMemberEnum(*ToInstOrErr, SK);
+else
+  return ToInstOrErr.takeError();
+if (ExpectedSLoc POIOrErr = import(MemberInfo->getPointOfInstantiation()))
+  D2->getMemberSpecializationInfo()->setPointOfInstantiation(*POIOrErr);
+else
+  return POIOrErr.takeError();
+  }
 
   // Import the definition
   if (D->isCompleteDefinition())


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -6236,6 +6236,26 @@
   EXPECT_NE(FromFD->getCapturedVLAType(), ToFD->getCapturedVLAType());
 }
 
+TEST_P(ASTImporterOptionSpecificTestBase, ImportEnumMemberSpecialization) {
+  Decl *FromTU = getTuDecl(
+  R"(
+  template  struct A {
+enum tagname { enumerator };
+  };
+  template struct A;
+  )",
+  Lang_CXX03);
+  auto *FromD = FirstDeclMatcher().match(
+  FromTU, enumDecl(hasName("tagname"),
+   hasParent(classTemplateSpecializationDecl(;
+  ASSERT_TRUE(FromD);
+  ASSERT_TRUE(FromD->getMemberSpecializationInfo());
+
+  auto *ToD = Import(FromD, Lang_CXX03);
+  EXPECT_TRUE(ToD);
+  EXPECT_TRUE(ToD->getMemberSpecializationInfo());
+}
+
 INSTANTIATE_TEST_CASE_P(ParameterizedTests, ASTImporterLookupTableTest,
 DefaultTestValuesForRunOptions, );
 
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -2732,7 +2732,20 @@
   D2->setBraceRange(ToBraceRange);
   D2->setAccess(D->getAccess());
   D2->setLexicalDeclContext(LexicalDC);
-  LexicalDC->addDeclInternal(D2);
+  addDeclToContexts(D, D2);
+
+  if (MemberSpecializationInfo *MemberInfo = D->getMemberSpecializationInfo()) {
+TemplateSpecializationKind SK = MemberInfo->getTemplateSpecializationKind();
+EnumDecl *FromInst = D->getInstantiatedFromMemberEnum();
+if (Expected ToInstOrErr = import(FromInst))
+  D2->setInstantiationOfMemberEnum(*ToInstOrErr, SK);
+else
+  return ToInstOrErr.takeError();
+if (ExpectedSLoc POIOrErr = import(MemberInfo->getPointOfInstantiation()))
+  D2->getMemberSpecializationInfo()->setPointOfInstantiation(*POIOrErr);
+else
+  return POIOrErr.takeError();
+  }
 
   // Import the definition
   if (D->isCompleteDefinition())
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99421: [ASTImporter] Import member specialization/instantiation of enum decls

2021-03-29 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: clang/unittests/AST/ASTImporterTest.cpp:6239
 
+TEST_P(ASTImporterOptionSpecificTestBase, ImportEnumMemberSpecializtion) {
+  Decl *FromTU = getTuDecl(

balazske wrote:
> 
Thanks, I fixed the typo now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99421

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


[clang] 0411b23 - [OPENMP]Map data field with l-value reference types.

2021-03-29 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2021-03-29T07:07:09-07:00
New Revision: 0411b2331916cc8c7a8be9dd0eb540b731e6d9ce

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

LOG: [OPENMP]Map data field with l-value reference types.

Added initial support dfor the mapping of the data members with l-value
reference types.

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

Added: 
clang/test/OpenMP/target_map_codegen_35.cpp
openmp/libomptarget/test/mapping/data_member_ref.cpp

Modified: 
clang/lib/CodeGen/CGOpenMPRuntime.cpp
clang/test/OpenMP/target_data_use_device_ptr_codegen.cpp
clang/test/OpenMP/target_map_codegen_28.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index 466ff096b585..95859e6e94a7 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -7439,6 +7439,7 @@ class MappableExprsHandler {
 //   S1 s;
 //   double *p;
 //   struct S2 *ps;
+//   int &ref;
 // }
 // S2 s;
 // S2 *ps;
@@ -7482,6 +7483,14 @@ class MappableExprsHandler {
 //  optimizes this entry out, same in the examples below)
 // (***) map the pointee (map: to)
 //
+// map(to: s.ref)
+// &s, &(s.ref), sizeof(int*), TARGET_PARAM (*)
+// &s, &(s.ref), sizeof(int), MEMBER_OF(1) | PTR_AND_OBJ | TO (***)
+// (*) alloc space for struct members, only this is a target parameter
+// (**) map the pointer (nothing to be mapped in this example) (the 
compiler
+//  optimizes this entry out, same in the examples below)
+// (***) map the pointee (map: to)
+//
 // map(s.ps)
 // &s, &(s.ps), sizeof(S2*), TARGET_PARAM | TO | FROM
 //
@@ -7679,6 +7688,7 @@ class MappableExprsHandler {
 uint64_t DimSize = 1;
 
 bool IsNonContiguous = CombinedInfo.NonContigInfo.IsNonContiguous;
+bool IsPrevMemberReference = false;
 
 for (; I != CE; ++I) {
   // If the current component is member of a struct (parent struct) mark 
it.
@@ -7736,12 +7746,16 @@ class MappableExprsHandler {
.getCanonicalType()
->isAnyPointerType()) ||
   I->getAssociatedExpression()->getType()->isAnyPointerType();
+  bool IsMemberReference = isa(I->getAssociatedExpression()) &&
+   MapDecl &&
+   MapDecl->getType()->isLValueReferenceType();
   bool IsNonDerefPointer = IsPointer && !UO && !BO && !IsNonContiguous;
 
   if (OASE)
 ++DimSize;
 
-  if (Next == CE || IsNonDerefPointer || IsFinalArraySection) {
+  if (Next == CE || IsMemberReference || IsNonDerefPointer ||
+  IsFinalArraySection) {
 // If this is not the last component, we expect the pointer to be
 // associated with an array expression or member expression.
 assert((Next == CE ||
@@ -7754,22 +7768,53 @@ class MappableExprsHandler {
"Unexpected expression");
 
 Address LB = Address::invalid();
+Address LowestElem = Address::invalid();
+auto &&EmitMemberExprBase = [](CodeGenFunction &CGF,
+   const MemberExpr *E) {
+  const Expr *BaseExpr = E->getBase();
+  // If this is s.x, emit s as an lvalue.  If it is s->x, emit s as a
+  // scalar.
+  LValue BaseLV;
+  if (E->isArrow()) {
+LValueBaseInfo BaseInfo;
+TBAAAccessInfo TBAAInfo;
+Address Addr =
+CGF.EmitPointerWithAlignment(BaseExpr, &BaseInfo, &TBAAInfo);
+QualType PtrTy = BaseExpr->getType()->getPointeeType();
+BaseLV = CGF.MakeAddrLValue(Addr, PtrTy, BaseInfo, TBAAInfo);
+  } else {
+BaseLV = CGF.EmitOMPSharedLValue(BaseExpr);
+  }
+  return BaseLV;
+};
 if (OAShE) {
-  LB = Address(CGF.EmitScalarExpr(OAShE->getBase()),
-   CGF.getContext().getTypeAlignInChars(
-   OAShE->getBase()->getType()));
-} else {
-  LB = CGF.EmitOMPSharedLValue(I->getAssociatedExpression())
+  LowestElem = LB = Address(CGF.EmitScalarExpr(OAShE->getBase()),
+CGF.getContext().getTypeAlignInChars(
+OAShE->getBase()->getType()));
+} else if (IsMemberReference) {
+  const auto *ME = cast(I->getAssociatedExpression());
+  LValue BaseLVal = EmitMemberExprBase(CGF, ME);
+  LowestElem = CGF.EmitLValueForFieldInitialization(
+  BaseLVal, cast(MapDecl))
+   .getAddress(CGF);
+  LB = CGF.EmitLoadOfReferenceLValue(LowestElem

[PATCH] D98812: [OPENMP]Map data field with l-value reference types.

2021-03-29 Thread Alexey Bataev via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0411b2331916: [OPENMP]Map data field with l-value reference 
types. (authored by ABataev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98812

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/target_data_use_device_ptr_codegen.cpp
  clang/test/OpenMP/target_map_codegen_28.cpp
  clang/test/OpenMP/target_map_codegen_35.cpp
  openmp/libomptarget/test/mapping/data_member_ref.cpp

Index: openmp/libomptarget/test/mapping/data_member_ref.cpp
===
--- /dev/null
+++ openmp/libomptarget/test/mapping/data_member_ref.cpp
@@ -0,0 +1,69 @@
+// RUN: %libomptarget-compilexx-run-and-check-aarch64-unknown-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-powerpc64-ibm-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-powerpc64le-ibm-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-x86_64-pc-linux-gnu
+// RUN: %libomptarget-compilexx-run-and-check-nvptx64-nvidia-cuda
+
+#include 
+
+struct View {
+  int Data;
+};
+
+struct ViewPtr {
+  int *Data;
+};
+
+template  struct Foo {
+  Foo(T &V) : VRef(V) {}
+  T &VRef;
+};
+
+int main() {
+  View V;
+  V.Data = 123456;
+  Foo Bar(V);
+  ViewPtr V1;
+  int Data = 123456;
+  V1.Data = &Data;
+  Foo Baz(V1);
+
+  // CHECK: Host 123456.
+  printf("Host %d.\n", Bar.VRef.Data);
+#pragma omp target map(Bar.VRef)
+  {
+// CHECK: Device 123456.
+printf("Device %d.\n", Bar.VRef.Data);
+V.Data = 654321;
+// CHECK: Device 654321.
+printf("Device %d.\n", Bar.VRef.Data);
+  }
+  // CHECK: Host 654321 654321.
+  printf("Host %d %d.\n", Bar.VRef.Data, V.Data);
+  V.Data = 123456;
+  // CHECK: Host 123456.
+  printf("Host %d.\n", Bar.VRef.Data);
+#pragma omp target map(Bar) map(Bar.VRef)
+  {
+// CHECK: Device 123456.
+printf("Device %d.\n", Bar.VRef.Data);
+V.Data = 654321;
+// CHECK: Device 654321.
+printf("Device %d.\n", Bar.VRef.Data);
+  }
+  // CHECK: Host 654321 654321.
+  printf("Host %d %d.\n", Bar.VRef.Data, V.Data);
+  // CHECK: Host 123456.
+  printf("Host %d.\n", *Baz.VRef.Data);
+#pragma omp target map(*Baz.VRef.Data)
+  {
+// CHECK: Device 123456.
+printf("Device %d.\n", *Baz.VRef.Data);
+*V1.Data = 654321;
+// CHECK: Device 654321.
+printf("Device %d.\n", *Baz.VRef.Data);
+  }
+  // CHECK: Host 654321 654321 654321.
+  printf("Host %d %d %d.\n", *Baz.VRef.Data, *V1.Data, Data);
+  return 0;
+}
Index: clang/test/OpenMP/target_map_codegen_35.cpp
===
--- /dev/null
+++ clang/test/OpenMP/target_map_codegen_35.cpp
@@ -0,0 +1,182 @@
+// expected-no-diagnostics
+#ifndef HEADER
+#define HEADER
+
+///==///
+// RUN: %clang_cc1 -DCK35 -verify -fopenmp -fopenmp-version=50 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefix CK35 --check-prefix CK35-64
+// RUN: %clang_cc1 -DCK35 -fopenmp -fopenmp-version=50 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s  --check-prefix CK35 --check-prefix CK35-64
+// RUN: %clang_cc1 -DCK35 -verify -fopenmp -fopenmp-version=50 -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck %s  --check-prefix CK35 --check-prefix CK35-32
+// RUN: %clang_cc1 -DCK35 -fopenmp -fopenmp-version=50 -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s  --check-prefix CK35 --check-prefix CK35-32
+
+// RUN: %clang_cc1 -DCK35 -verify -fopenmp-simd -fopenmp-version=50 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY32 %s
+// RUN: %clang_cc1 -DCK35 -fopenmp-simd -fopenmp-version=50 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-version=50 -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix SIMD-ONLY32 %s
+// RUN: %clang_cc1 -DCK35 -verify -fopenmp-simd -fopenmp-version=50 -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck --c

[PATCH] D99489: [clang] [PR49736] [C++2b] Correctly reject lambdas with requires clause and no parameter list

2021-03-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Parse/ParseExprCXX.cpp:1435
+
+WarnIfHasCUDATargetAttr();
   } else if (Tok.isOneOf(tok::kw_mutable, tok::arrow, tok::kw___attribute,

Rather than add this in both branches, I'd say to hoist it out of the branches 
and put it after the `else if` below (before the declaration of `ScopeFlags`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99489

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


[PATCH] D91327: [NewPM] Redesign of PreserveCFG Checker

2021-03-29 Thread Jakub Kuderski via Phabricator via cfe-commits
kuhar added a comment.

Just two nits from me. I think it looks fine, but I'm not familiar with the new 
pass manager and don't feel confident enough to approve it.




Comment at: llvm/include/llvm/Passes/StandardInstrumentations.h:134
 
 public:
   static cl::opt VerifyPreservedCFG;

yrouban wrote:
> kuhar wrote:
> > yrouban wrote:
> > > kuhar wrote:
> > > > not necessary anymore
> > > there can bee a need to disabled/enable (e.g. for some tests or for 
> > > debugging).
> > I meant the 'public:'. You made everything public at the very top of the 
> > class.
> sure
I don't think this got fixed.



Comment at: llvm/lib/Passes/StandardInstrumentations.cpp:1096
+  checkCFG(P, F->getName(), *GraphBefore,
+   CFG(F, false /* TrackBBLifetime */));
   });

nit: can you put the commented argument name before the argument?


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

https://reviews.llvm.org/D91327

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


[PATCH] D99506: [OpenMP][NFC] Move the `noinline` to the parallel entry point

2021-03-29 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert created this revision.
jdoerfert added reviewers: tianshilei1992, ye-luo, JonChesterfield.
Herald added subscribers: guansong, yaxunl.
Herald added a reviewer: bollu.
jdoerfert requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

The `noinline` for non-SPMD parallel functions is probably not necessary
but as long as we use it we should put it on the outermost parallel
function, which is the wrapper, not the actual outlined function.

Resolves PR49752


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99506

Files:
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp


Index: clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
@@ -2092,14 +2092,6 @@
   // Force inline this outlined function at its call site.
   Fn->setLinkage(llvm::GlobalValue::InternalLinkage);
 
-  // Ensure we do not inline the function. This is trivially true for the ones
-  // passed to __kmpc_fork_call but the ones calles in serialized regions
-  // could be inlined. This is not a perfect but it is closer to the invariant
-  // we want, namely, every data environment starts with a new function.
-  // TODO: We should pass the if condition to the runtime function and do the
-  //   handling there. Much cleaner code.
-  cast(OutlinedFn)->addFnAttr(llvm::Attribute::NoInline);
-
   Address ZeroAddr = CGF.CreateDefaultAlignTempAlloca(CGF.Int32Ty,
   /*Name=*/".zero.addr");
   CGF.InitTempAlloca(ZeroAddr, CGF.Builder.getInt32(/*C*/ 0));
@@ -4210,6 +4202,15 @@
   auto *Fn = llvm::Function::Create(
   CGM.getTypes().GetFunctionType(CGFI), llvm::GlobalValue::InternalLinkage,
   Twine(OutlinedParallelFn->getName(), "_wrapper"), &CGM.getModule());
+
+  // Ensure we do not inline the function. This is trivially true for the ones
+  // passed to __kmpc_fork_call but the ones calles in serialized regions
+  // could be inlined. This is not a perfect but it is closer to the invariant
+  // we want, namely, every data environment starts with a new function.
+  // TODO: We should pass the if condition to the runtime function and do the
+  //   handling there. Much cleaner code.
+  Fn->addFnAttr(llvm::Attribute::NoInline);
+
   CGM.SetInternalFunctionAttributes(GlobalDecl(), Fn, CGFI);
   Fn->setLinkage(llvm::GlobalValue::InternalLinkage);
   Fn->setDoesNotRecurse();


Index: clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
@@ -2092,14 +2092,6 @@
   // Force inline this outlined function at its call site.
   Fn->setLinkage(llvm::GlobalValue::InternalLinkage);
 
-  // Ensure we do not inline the function. This is trivially true for the ones
-  // passed to __kmpc_fork_call but the ones calles in serialized regions
-  // could be inlined. This is not a perfect but it is closer to the invariant
-  // we want, namely, every data environment starts with a new function.
-  // TODO: We should pass the if condition to the runtime function and do the
-  //   handling there. Much cleaner code.
-  cast(OutlinedFn)->addFnAttr(llvm::Attribute::NoInline);
-
   Address ZeroAddr = CGF.CreateDefaultAlignTempAlloca(CGF.Int32Ty,
   /*Name=*/".zero.addr");
   CGF.InitTempAlloca(ZeroAddr, CGF.Builder.getInt32(/*C*/ 0));
@@ -4210,6 +4202,15 @@
   auto *Fn = llvm::Function::Create(
   CGM.getTypes().GetFunctionType(CGFI), llvm::GlobalValue::InternalLinkage,
   Twine(OutlinedParallelFn->getName(), "_wrapper"), &CGM.getModule());
+
+  // Ensure we do not inline the function. This is trivially true for the ones
+  // passed to __kmpc_fork_call but the ones calles in serialized regions
+  // could be inlined. This is not a perfect but it is closer to the invariant
+  // we want, namely, every data environment starts with a new function.
+  // TODO: We should pass the if condition to the runtime function and do the
+  //   handling there. Much cleaner code.
+  Fn->addFnAttr(llvm::Attribute::NoInline);
+
   CGM.SetInternalFunctionAttributes(GlobalDecl(), Fn, CGFI);
   Fn->setLinkage(llvm::GlobalValue::InternalLinkage);
   Fn->setDoesNotRecurse();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99508: [SystemZ][z/OS] Add test of leading zero length bitfield in const/volatile struct

2021-03-29 Thread Fanbo Meng via Phabricator via cfe-commits
fanbo-meng created this revision.
fanbo-meng added a reviewer: abhina.sreeskantharajan.
fanbo-meng requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99508

Files:
  clang/test/CodeGen/SystemZ/zos-alignment.c


Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -12,6 +12,24 @@
 // DECL-NEXT: @v2 {{.*}} align 16
 // DECL-NEXT: @v3 {{.*}} align 32
 
+const struct cs0 {
+  unsigned long   :0;
+  long longa;
+} CS0 = {};
+// CHECK:  0 | struct cs0
+// CHECK-NEXT:   0:- |   unsigned long
+// CHECK-NEXT: 0 |   long long a
+// CHECK-NEXT:   | [sizeof=8, align=8]
+
+volatile struct vs0 {
+  long:0;
+  short   a;
+} VS0;
+// CHECK:  0 | struct vs0
+// CHECK-NEXT:   0:- |   long
+// CHECK-NEXT: 0 |   short a
+// CHECK-NEXT:   | [sizeof=2, align=2]
+
 struct s0 {
   short a:3;
   long b:5;


Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -12,6 +12,24 @@
 // DECL-NEXT: @v2 {{.*}} align 16
 // DECL-NEXT: @v3 {{.*}} align 32
 
+const struct cs0 {
+  unsigned long   :0;
+  long longa;
+} CS0 = {};
+// CHECK:  0 | struct cs0
+// CHECK-NEXT:   0:- |   unsigned long
+// CHECK-NEXT: 0 |   long long a
+// CHECK-NEXT:   | [sizeof=8, align=8]
+
+volatile struct vs0 {
+  long:0;
+  short   a;
+} VS0;
+// CHECK:  0 | struct vs0
+// CHECK-NEXT:   0:- |   long
+// CHECK-NEXT: 0 |   short a
+// CHECK-NEXT:   | [sizeof=2, align=2]
+
 struct s0 {
   short a:3;
   long b:5;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99292: [flang][driver] Add support for `-cpp/-nocpp`

2021-03-29 Thread Tim Keith via Phabricator via cfe-commits
tskeith added inline comments.



Comment at: clang/include/clang/Driver/Options.td:4302
+def cpp : Flag<["-"], "cpp">, Group,
+  HelpText<"Always add standard macro predefinitions">;
+def nocpp : Flag<["-"], "nocpp">, Group,

This option affects command line macro definitions too. So maybe something like:
`Enable predefined and command line preprocessor macros`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99292

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


[PATCH] D99456: [C++2b] Support size_t literals

2021-03-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman requested changes to this revision.
aaron.ballman added a comment.
This revision now requires changes to proceed.

Thanks for working on this! I think the direction is good in general, but I 
think we should also add tests for use in the preprocessor (`#if 1z == 1`, etc) 
as well as tests for the behavior in C.




Comment at: clang/include/clang/Basic/DiagnosticCommonKinds.td:191
+def ext_cxx2b_size_t_suffix : Extension<
+  "size_t suffix for literals is a C++2b extension">,
+  InGroup;





Comment at: clang/include/clang/Lex/LiteralSupport.h:66
   bool isLongLong : 1;
+  bool isSizeT : 1; // C++2b's z/uz size_t literals
   bool isHalf : 1;  // 1.0h





Comment at: clang/lib/Frontend/InitPreprocessor.cpp:593-595
+  if (LangOpts.CPlusPlus2b) {
+Builder.defineMacro("__cpp_size_t_suffix", "202011L");
+  }





Comment at: clang/lib/Lex/LiteralSupport.cpp:682
+break; // invalid for floats.
+  if (isMicrosoftInteger)
+break; // invalid for Microsoft integers.





Comment at: clang/lib/Lex/PPExpressions.cpp:325-327
+if (!PP.getLangOpts().CPlusPlus2b && Literal.isSizeT) {
+  PP.Diag(PeekTok, diag::ext_cxx2b_size_t_suffix);
+}





Comment at: clang/lib/Lex/PPExpressions.cpp:326
+if (!PP.getLangOpts().CPlusPlus2b && Literal.isSizeT) {
+  PP.Diag(PeekTok, diag::ext_cxx2b_size_t_suffix);
+}

This feature is specific to C++ and needs some sort of diagnostic in C. There 
is not currently a WG14 proposal for this literal suffix, so I think this 
should be an error in that case rather than a warning.



Comment at: clang/lib/Sema/SemaExpr.cpp:3871-3873
+if (!getLangOpts().CPlusPlus2b && Literal.isSizeT) {
+  Diag(Tok.getLocation(), diag::ext_cxx2b_size_t_suffix);
+}





Comment at: clang/lib/Sema/SemaExpr.cpp:3872
+if (!getLangOpts().CPlusPlus2b && Literal.isSizeT) {
+  Diag(Tok.getLocation(), diag::ext_cxx2b_size_t_suffix);
+}

Same diagnostic needs for C here as above.



Comment at: clang/lib/Sema/SemaExpr.cpp:3911
+  if (Literal.isSizeT) {
+assert(Ty.isNull() && "size_t literals can't be Microsoft literals");
+unsigned SizeTSize = Context.getTargetInfo().getTypeWidth(

The assert message doesn't seem to match the predicate -- why does a null 
qualtype imply it's a microsoft literal?



Comment at: clang/test/SemaCXX/size_t-literal.cpp:14-16
+#if __cplusplus >= 202101L
+//  expected-no-diagnostics
+#endif

Rather than check `__cplusplus` like this, I think the RUN lines should specify 
a verify prefix. e.g., `-verify=cxx2b` and then use `cxx2b-no-diagnostics` and 
`-verify=cxx20` and then use `cxx20-warning {{}}`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99456

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


[PATCH] D91630: [Parse] Add parsing support for C++ attributes on using-declarations

2021-03-29 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington updated this revision to Diff 333862.
erik.pilkington marked 4 inline comments as done.
erik.pilkington added a comment.

Address @aaron.ballman's review comments. Also, fix a bug where we failed to 
properly parse an inherited constructor declaration with a trailing attribute.


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

https://reviews.llvm.org/D91630

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Parse/Parser.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/Parser/cxx0x-attributes.cpp
  clang/test/SemaCXX/cxx11-attributes-on-using-declaration.cpp

Index: clang/test/SemaCXX/cxx11-attributes-on-using-declaration.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx11-attributes-on-using-declaration.cpp
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -pedantic -triple x86_64-apple-macos11 -std=c++20 -fsyntax-only -verify %s
+
+static_assert(__has_extension(cxx_attributes_on_using_declarations), "");
+
+namespace NS { typedef int x; }
+
+[[clang::annotate("foo")]] using NS::x; // expected-warning{{ISO C++ does not allow an attribute list to appear here}}
+
+
+[[deprecated]] using NS::x; // expected-warning {{'deprecated' currently has no effect on using-declarations}} expected-warning{{ISO C++ does not allow}}
+using NS::x [[deprecated]]; // expected-warning {{'deprecated' currently has no effect on using-declarations}} expected-warning{{ISO C++ does not allow}}
+using NS::x __attribute__((deprecated)); // expected-warning {{'deprecated' currently has no effect on using-declarations}}
+using NS::x __attribute__((availability(macos,introduced=1))); // expected-warning {{'availability' currently has no effect on using-declarations}}
+
+[[clang::availability(macos,introduced=1)]] using NS::x; // expected-warning {{'availability' currently has no effect on using-declarations}} expected-warning{{ISO C++ does not allow}}
+
+// expected-warning@+1 3 {{ISO C++ does not allow an attribute list to appear here}}
+[[clang::annotate("A")]] using NS::x [[clang::annotate("Y")]], NS::x [[clang::annotate("Z")]];
+
+template 
+struct S : T {
+  [[deprecated]] using typename T::x; // expected-warning{{ISO C++ does not allow}} expected-warning {{'deprecated' currently has no effect on using-declarations}}
+  [[deprecated]] using T::y; // expected-warning{{ISO C++ does not allow}} expected-warning {{'deprecated' currently has no effect on using-declarations}}
+
+  using typename T::z [[deprecated]]; // expected-warning{{ISO C++ does not allow}} expected-warning {{'deprecated' currently has no effect on using-declarations}}
+  using T::a [[deprecated]]; // expected-warning{{ISO C++ does not allow}} expected-warning {{'deprecated' currently has no effect on using-declarations}}
+};
+
+struct Base {};
+
+template 
+struct DepBase1 : B {
+  using B::B [[]];
+
+};
+template 
+struct DepBase2 : B {
+  using B::B __attribute__(());
+};
+
+DepBase1 db1;
+DepBase2 db2;
Index: clang/test/Parser/cxx0x-attributes.cpp
===
--- clang/test/Parser/cxx0x-attributes.cpp
+++ clang/test/Parser/cxx0x-attributes.cpp
@@ -131,12 +131,12 @@
 [[]] static_assert(true, ""); //expected-error {{an attribute list cannot appear here}}
 [[]] asm(""); // expected-error {{an attribute list cannot appear here}}
 
-[[]] using ns::i; // expected-error {{an attribute list cannot appear here}}
+[[]] using ns::i;
 [[unknown]] using namespace ns; // expected-warning {{unknown attribute 'unknown' ignored}}
 [[noreturn]] using namespace ns; // expected-error {{'noreturn' attribute only applies to functions}}
 namespace [[]] ns2 {} // expected-warning {{attributes on a namespace declaration are a C++17 extension}}
 
-using [[]] alignas(4) [[]] ns::i; // expected-error {{an attribute list cannot appear here}}
+using [[]] alignas(4) [[]] ns::i; // expected-error {{an attribute list cannot appear here}} expected-error {{'alignas' attribute only applies to variables, data members and tag types}} expected-warning {{ISO C++}}
 using [[]] alignas(4) [[]] foobar = int; // expected-error {{an attribute list cannot appear here}} expected-error {{'alignas' attribute only applies to}}
 
 void bad_attributes_in_do_while() {
@@ -157,7 +157,16 @@
 [[]] using T = int; // expected-error {{an attribute list cannot appear here}}
 using T [[]] = int; // ok
 template using U [[]] = T;
-using ns::i [[]]; // expected-error {{an attribute list cannot appear here}}
+using ns::i [[]];
+using ns::i [[]], ns::i [[]]; // expected-warning {{use of multiple declarators in a single using declaration is a C++17 extension}}
+struct using_in_struct_base {
+  typedef int i

[PATCH] D90188: Add support for attribute 'using_if_exists'

2021-03-29 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington updated this revision to Diff 333873.
erik.pilkington marked 4 inline comments as done.
erik.pilkington added a comment.

Address review comments.


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

https://reviews.llvm.org/D90188

Files:
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DeclNodes.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/DeclBase.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/Parser/using-if-exists-attr.cpp
  clang/test/SemaCXX/attr-deprecated.cpp
  clang/test/SemaCXX/using-if-exists.cpp
  clang/tools/libclang/CIndex.cpp

Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -6448,6 +6448,7 @@
   case Decl::Concept:
   case Decl::LifetimeExtendedTemporary:
   case Decl::RequiresExprBody:
+  case Decl::UnresolvedUsingIfExists:
 return C;
 
   // Declaration kinds that don't make any sense here, but are
Index: clang/test/SemaCXX/using-if-exists.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/using-if-exists.cpp
@@ -0,0 +1,218 @@
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only %s -verify
+
+#define UIE __attribute__((using_if_exists))
+
+namespace test_basic {
+namespace NS {}
+
+using NS::x UIE; // expected-note{{using declaration annotated with 'using_if_exists' here}}
+x usex(); // expected-error{{reference to unresolved using declaration}}
+
+using NotNS::x UIE; // expected-error{{use of undeclared identifier 'NotNS'}}
+
+using NS::NotNS::x UIE; // expected-error{{no member named 'NotNS' in namespace 'test_basic::NS'}}
+} // test_basic
+
+namespace test_redecl {
+namespace NS {}
+
+using NS::x UIE;
+using NS::x UIE;
+
+namespace NS1 {}
+namespace NS2 {}
+namespace NS3 {
+int A(); // expected-note{{target of using declaration}}
+struct B {}; // expected-note{{target of using declaration}}
+int C(); // expected-note{{conflicting declaration}}
+struct D {}; // expected-note{{conflicting declaration}}
+}
+
+using NS1::A UIE;
+using NS2::A UIE; // expected-note{{using declaration annotated with 'using_if_exists' here}} expected-note{{conflicting declaration}}
+using NS3::A UIE; // expected-error{{target of using declaration conflicts with declaration already in scope}}
+int i = A(); // expected-error{{reference to unresolved using declaration}}
+
+using NS1::B UIE;
+using NS2::B UIE; // expected-note{{conflicting declaration}} expected-note{{using declaration annotated with 'using_if_exists' here}}
+using NS3::B UIE; // expected-error{{target of using declaration conflicts with declaration already in scope}}
+B myB; // expected-error{{reference to unresolved using declaration}}
+
+using NS3::C UIE;
+using NS2::C UIE; // expected-error{{target of using declaration conflicts with declaration already in scope}} expected-note{{target of using declaration}}
+int j = C();
+
+using NS3::D UIE;
+using NS2::D UIE; // expected-error{{target of using declaration conflicts with declaration already in scope}} expected-note{{target of using declaration}}
+D myD;
+} // test_redecl
+
+namespace test_dependent {
+template 
+struct S : B {
+  using B::mf UIE; // expected-note 3 {{using declaration annotated with 'using_if_exists' here}}
+  using typename B::mt UIE; // expected-note{{using declaration annotated with 'using_if_exists' here}}
+};
+
+struct BaseEmpty {
+};
+struct BaseNonEmpty {
+  void mf();
+  typedef int mt;
+};
+
+template 
+struct UseCtor : Base {
+  using Base::Base UIE; // expected-error{{'using_if_exists' attribute cannot be applied to an inheriting constructor}}
+};
+struct BaseCtor {};
+
+void f() {
+  S empty;
+  S nonempty;
+  empty.mf(); // expected-error {{reference to unresolved using declaration}}
+  nonempty.mf();
+  (&empty)->mf(); // expected-error {{reference to unresolved using declaration}}
+  (&nonempty)->mf();
+
+  S::mt y; // expected-error {{reference to unresolved using declaration}}
+  S::mt z;
+
+  S::mf(); // expected-error {{reference to unresolved using declaration}}
+
+  UseCtor usector;
+}
+
+template 
+struct Implicit : B {
+  using B::mf UIE; // expected-note {{using declaration annotated with 'using_if_exists' here}}
+  using typename B::mt UIE; // expected-note 2 {{using declaration annotated with 'using_if_exists' here}}
+
+  void use() 

[PATCH] D90188: Add support for attribute 'using_if_exists'

2021-03-29 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington added inline comments.



Comment at: clang/test/SemaCXX/using-if-exists.cpp:11
+
+using NotNS::x UIE; // expected-error{{use of undeclared identifier 'NotNS'}}
+} // test_basic

Quuxplusone wrote:
> Do you also have a test for `using NS::NotNS::x UIE;`?
> (Both of these `NotNS` tests produce hard errors; `[[using_if_exists]]` does 
> the silent-ignore thing only when the tippymost identifier is nonexistent, 
> not if some intermediate name is nonexistent. This seems reasonable enough.)
Yeah, this is only about the tippymost name :). New patch adds a test for 
non-existent names in the middle, which was previously untested.



Comment at: clang/test/SemaCXX/using-if-exists.cpp:60
+  typedef int mt;
+};
+

Quuxplusone wrote:
> An inheritance case not yet covered here errors out with `error: no matching 
> constructor for initialization of 'Derived'`:
> ```
> struct Base { Base(int); };
> template struct Derived : T {
> using T::T [[clang::using_if_exists]];
> };
> Derived d(1);
> ```
> Does this make sense? Should this attribute perhaps give a hard error if you 
> try to use it to inherit a constructor overload set like this, instead of 
> (apparently) just no-opping the construct?
Hmm, yeah, I don't think that inheriting constructors really make sense with 
this attribute. New patch adds an error.



Comment at: clang/test/SemaCXX/using-if-exists.cpp:79
+  using B::mf UIE; // expected-note {{using declaration annotated with 
'using_if_exists' here}}
+  using typename B::mt UIE; // expected-note 2 {{using declaration annotated 
with 'using_if_exists' here}}
+

Quuxplusone wrote:
> I notice there's a hard `error: 'using_if_exists' attribute cannot be applied 
> to types` on
> 
> using B::operator int UIE;
> 
> Any thoughts on how to disambiguate that grammar?
Hmm, that's an interesting case. I'm not sure what the right approach is. I 
think it would be a bit awkward to decide where to attach the attribute 
depending on what kind of entities the attribute could potentially apply to. 
FWIW this isn't a semantic restriction, since you can always just use the 
prefix syntax: `UIE using B::operator int;`. Maybe @aaron.ballman has some 
thoughts here?



Comment at: clang/test/SemaCXX/using-if-exists.cpp:107
+  using typename Ts::x... UIE; // expected-error 2 {{target of using 
declaration conflicts with declaration already in scope}} 
expected-note{{conflicting declaration}} expected-note{{target of using 
declaration}}
+};
+

Quuxplusone wrote:
> This is a very good test, but it feels to me as if
> ```
> struct B { static int f(int); };
> struct C { };
> template struct D : Ts... {
> using Ts::f... [[clang::using_if_exists]];
> };
> int main() { D::f(1); }
> ```
> ought to be //at least// as well-formed as
> ```
> struct B { static int f(int); };
> struct C { static void f(); };
> template struct D : Ts... {
> using Ts::f... [[clang::using_if_exists]];
> };
> int main() { D::f(1); }
> ```
> I guess what's going on here is that an "unresolved using decl" is considered 
> a separate kind of entity, i.e. `using Ts::f...` will work if //all// 
> `Ts::f...` are variables, or if //all// of them are functions, or if //all// 
> of them are unresolved, but it doesn't work if you have a mix of variables 
> and functions, or variables and unresolveds, or functions and unresolveds. Is 
> that basically correct, and intended? 
> I guess what's going on here is that an "unresolved using decl" is considered 
> a separate kind of entity, i.e. using Ts::f... will work if all Ts::f... are 
> variables, or if all of them are functions, or if all of them are unresolved, 
> but it doesn't work if you have a mix of variables and functions, or 
> variables and unresolveds, or functions and unresolveds. Is that basically 
> correct, and intended?


Yeah, exactly. My mental model for how this attribute works is that an 
unresolved using-declaration introduces an entity that isn't a function, value, 
or type, and is incompatible with all of those. Sometimes, that isn't what you 
want for overloaded functions, like Louis ran into an issue while testing this 
where `remove(const char *)` in `` being unresolved lead to a compile 
error on the declaration of `remove(iter, iter, val)` in ``. That 
seems to basically be the same issue you're seeing in your first test case.

Personally, my inclination is to conservatively just disallow any interplay 
with an unresolved using-declaration and a function, and if we run into a lot 
of problems in practice then we can come up with a more nuanced approach for 
this case without breaking backwards compatibility. WDYT?


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

https://reviews.llvm.org/D90188

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi

[PATCH] D98193: [CUDA][HIP] Allow non-ODR use of host var in device

2021-03-29 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

ping


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

https://reviews.llvm.org/D98193

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


[PATCH] D99152: [AMX] Prototype for vector and amx bitcast.

2021-03-29 Thread LuoYuanke via Phabricator via cfe-commits
LuoYuanke added a comment.

> Whether to further optimizations are correct is a different problem, but we 
> need a specification for the builtins, intrinsics and the type before going 
> any further in that direction.
>
> I think you need to set the input to `LLVM IR`: 
> https://gcc.godbolt.org/z/WexMjsas9
>
> You should be able to use opaque types with overloaded intrinsics. I don't 
> think you define an intrinsic to take a specific opaque type (because it's 
> not known up front).

The opaque type (https://llvm.org/docs/LangRef.html#opaque-structure-types) is 
pretty new to me. I didn't find any example for the opaque type in builtins or 
intrinsics. I am appreciated if you would write an example code (maybe 
tilezero) for the builtins, intrinsics and the type, so that I can understand 
it well. If we use <256 x i32> in builtins and use x86_amx in intrinsics, and 
have an specific intrinsics to covert x86_amx to flat vector <256 x i32>, I am 
able to do it by myself.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99152

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


[PATCH] D99506: [OpenMP][NFC] Move the `noinline` to the parallel entry point

2021-03-29 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield accepted this revision.
JonChesterfield added a comment.
This revision is now accepted and ready to land.

Context in https://bugs.llvm.org/show_bug.cgi?id=49752 is that this resolves a 
regression in stack usage from D94315 .  This 
change looks good. I'm not totally sold on using a function call boundary to 
convey invariants on ICV, but that's an existing property.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99506

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


[PATCH] D99484: Use `GNUInstallDirs` to support custom installation dirs.

2021-03-29 Thread John Ericson via Phabricator via cfe-commits
Ericson2314 added a comment.

@lebedev.ri Those are intentional. I changed `POLLY_INSTALL_PREFIX` and 
`COMPILER_RT_INSTALL_PATH` to be `""` instead of `${CMAKE_INSTALL_PREFIX}` by 
default. If if kept it more as it was, the GNU dir outside the prefix (as I 
needed to do) wouldn't work. I suppose I could instead use 
https://cmake.org/cmake/help/v3.16/command/get_filename_component.html to keep 
those prefix ones as is? But I would still need to use the `_FULL` variables in 
the calculation.

There is 
https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html#command:gnuinstalldirs_get_absolute_install_dir
 which would be nice to use for this, except there is no parameter to make it 
expand relative something other than `CMAKE_INSTALL_PREFIX`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99484

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


[PATCH] D99489: [clang] [PR49736] [C++2b] Correctly reject lambdas with requires clause and no parameter list

2021-03-29 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius added inline comments.



Comment at: clang/lib/Parse/ParseExprCXX.cpp:1435
+
+WarnIfHasCUDATargetAttr();
   } else if (Tok.isOneOf(tok::kw_mutable, tok::arrow, tok::kw___attribute,

aaron.ballman wrote:
> Rather than add this in both branches, I'd say to hoist it out of the 
> branches and put it after the `else if` below (before the declaration of 
> `ScopeFlags`).
True. Will do soon.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99489

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


[PATCH] D99506: [OpenMP][NFC] Move the `noinline` to the parallel entry point

2021-03-29 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a comment.

Is it possible to add a test?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99506

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


[PATCH] D99199: Make -fcrash-diagnostics-dir control the Windows (mini-)dump location

2021-03-29 Thread Paul Robinson via Phabricator via cfe-commits
probinson updated this revision to Diff 333884.
probinson added a comment.

Remove ifdefs, tweak descriptions/comments.


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

https://reviews.llvm.org/D99199

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/crash-diagnostics-dir-2.c
  llvm/lib/Support/Signals.cpp
  llvm/lib/Support/Windows/Signals.inc


Index: llvm/lib/Support/Windows/Signals.inc
===
--- llvm/lib/Support/Windows/Signals.inc
+++ llvm/lib/Support/Windows/Signals.inc
@@ -766,16 +766,18 @@
 if (!GetDumpType(DefaultLocalDumpsKey, DumpType))
   DumpType = MiniDumpNormal;
 
-  // Look to see if a dump location is specified in the registry; first with 
the
+  // Look to see if a dump location is specified on the command line.  If not,
+  // look to see if a dump location is specified in the registry; first with 
the
   // app-specific key and failing that with the global key.  If none are found
   // we'll just create the dump file in the default temporary file location
   // (GetDumpFolder will return false either if the key is NULL or if there is
   // no valid DumpFolder value at its location).
   bool ExplicitDumpDirectorySet = true;
-  SmallString DumpDirectory;
-  if (!GetDumpFolder(AppSpecificKey, DumpDirectory))
-if (!GetDumpFolder(DefaultLocalDumpsKey, DumpDirectory))
-  ExplicitDumpDirectorySet = false;
+  SmallString DumpDirectory(CrashDiagnosticsDirectory);
+  if (DumpDirectory.empty())
+if (!GetDumpFolder(AppSpecificKey, DumpDirectory))
+  if (!GetDumpFolder(DefaultLocalDumpsKey, DumpDirectory))
+ExplicitDumpDirectorySet = false;
 
   int FD;
   SmallString DumpPath;
Index: llvm/lib/Support/Signals.cpp
===
--- llvm/lib/Support/Signals.cpp
+++ llvm/lib/Support/Signals.cpp
@@ -43,6 +43,11 @@
 DisableSymbolication("disable-symbolication",
  cl::desc("Disable symbolizing crash backtraces."),
  cl::location(DisableSymbolicationFlag), cl::Hidden);
+static std::string CrashDiagnosticsDirectory;
+static cl::opt
+CrashDiagnosticsDir("crash-diagnostics-dir", cl::value_desc("directory"),
+cl::desc("Directory for crash diagnostic files."),
+cl::location(CrashDiagnosticsDirectory), cl::Hidden);
 
 constexpr char DisableSymbolizationEnv[] = "LLVM_DISABLE_SYMBOLIZATION";
 constexpr char LLVMSymbolizerPathEnv[] = "LLVM_SYMBOLIZER_PATH";
Index: clang/test/Driver/crash-diagnostics-dir-2.c
===
--- /dev/null
+++ clang/test/Driver/crash-diagnostics-dir-2.c
@@ -0,0 +1,5 @@
+// RUN: %clang -### -fcrash-diagnostics-dir=mydumps -c %s 2>&1 \
+// RUN: | FileCheck %s --check-prefix=OPTION
+// OPTION: "-crash-diagnostics-dir=mydumps"
+// RUN: %clang -### -c %s 2>&1 | FileCheck %s --check-prefix=NOOPTION
+// NOOPTION-NOT: "-crash-diagnostics-dir
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5128,6 +5128,14 @@
   if (D.CCGenDiagnostics)
 CmdArgs.push_back("-disable-pragma-debug-crash");
 
+  // Allow backend to put its diagnostic files in the same place as frontend
+  // crash diagnostics files.
+  if (Args.hasArg(options::OPT_fcrash_diagnostics_dir)) {
+StringRef Dir = Args.getLastArgValue(options::OPT_fcrash_diagnostics_dir);
+CmdArgs.push_back("-mllvm");
+CmdArgs.push_back(Args.MakeArgString("-crash-diagnostics-dir=" + Dir));
+  }
+
   bool UseSeparateSections = isUseSeparateSections(Triple);
 
   if (Args.hasFlag(options::OPT_ffunction_sections,


Index: llvm/lib/Support/Windows/Signals.inc
===
--- llvm/lib/Support/Windows/Signals.inc
+++ llvm/lib/Support/Windows/Signals.inc
@@ -766,16 +766,18 @@
 if (!GetDumpType(DefaultLocalDumpsKey, DumpType))
   DumpType = MiniDumpNormal;
 
-  // Look to see if a dump location is specified in the registry; first with the
+  // Look to see if a dump location is specified on the command line.  If not,
+  // look to see if a dump location is specified in the registry; first with the
   // app-specific key and failing that with the global key.  If none are found
   // we'll just create the dump file in the default temporary file location
   // (GetDumpFolder will return false either if the key is NULL or if there is
   // no valid DumpFolder value at its location).
   bool ExplicitDumpDirectorySet = true;
-  SmallString DumpDirectory;
-  if (!GetDumpFolder(AppSpecificKey, DumpDirectory))
-if (!GetDumpFolder(DefaultLocalDumpsKey, DumpDirectory))
-  ExplicitDumpDirectorySet = false;
+  SmallString DumpDirectory(CrashDiagnosticsDirectory);
+  if (DumpDirectory.empty())
+if (!

[PATCH] D99199: Make -fcrash-diagnostics-dir control the Windows (mini-)dump location

2021-03-29 Thread Paul Robinson via Phabricator via cfe-commits
probinson marked 2 inline comments as done.
probinson added a comment.

Addressed comments.


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

https://reviews.llvm.org/D99199

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


[PATCH] D99508: [SystemZ][z/OS] Add test of leading zero length bitfield in const/volatile struct

2021-03-29 Thread Abhina Sree via Phabricator via cfe-commits
abhina.sreeskantharajan accepted this revision.
abhina.sreeskantharajan added a comment.
This revision is now accepted and ready to land.

LGTM, have a small nit




Comment at: clang/test/CodeGen/SystemZ/zos-alignment.c:26
+  long:0;
+  short   a;
+} VS0;

nit: spacing is off


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99508

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


[PATCH] D99297: [OPENMP]Fix PR49636: Assertion `(!Entry.getAddress() || Entry.getAddress() == Addr) && "Resetting with the new address."' failed.

2021-03-29 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

Nice, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99297

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


[PATCH] D99506: [OpenMP][NFC] Move the `noinline` to the parallel entry point

2021-03-29 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

In D99506#2655948 , @fhahn wrote:

> Is it possible to add a test?

There is a test for the presence of noinline, let me make it more explicit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99506

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


[PATCH] D99488: [SYCL][Doc] Add address space handling section to SYCL documentation

2021-03-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Mostly grammar related review comments, nothing substantive.




Comment at: clang/docs/SYCLSupport.md:816
 
+### Address spaces handling
+





Comment at: clang/docs/SYCLSupport.md:818
+
+SYCL specification uses C++ classes to represent pointers to disjoint memory
+regions on an accelerator to enable compilation with standard C++ toolchain and





Comment at: clang/docs/SYCLSupport.md:819
+SYCL specification uses C++ classes to represent pointers to disjoint memory
+regions on an accelerator to enable compilation with standard C++ toolchain and
+SYCL compiler toolchain. Section 3.8.2 of SYCL 2020 specification defines





Comment at: clang/docs/SYCLSupport.md:825
+
+The main address space semantic difference of SYCL mode from OpenCL is that
+SYCL doesn't perform address space qualifier inference detailed in





Comment at: clang/docs/SYCLSupport.md:826
+The main address space semantic difference of SYCL mode from OpenCL is that
+SYCL doesn't perform address space qualifier inference detailed in
+[OpenCL C v3.0 
s6.7.8](https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#addr-spaces-inference).





Comment at: clang/docs/SYCLSupport.md:827
+SYCL doesn't perform address space qualifier inference detailed in
+[OpenCL C v3.0 
s6.7.8](https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#addr-spaces-inference).
+





Comment at: clang/docs/SYCLSupport.md:831
+OpenMP/CUDA/HIP, SYCL uses clang's "default" address space for types with no
+address space attributes. This design has two important features: keeps the 
type system consistent with C++ on one hand and enable tools for emitting 
device code aligned with SPIR memory model (and other GPU targets).
+

You should also re-wrap for 80 col (whenever we finish talking about what words 
to add).



Comment at: clang/docs/SYCLSupport.md:839
+
+SYCL device compiler turns into
+





Comment at: clang/docs/SYCLSupport.md:845
+
+OpenCL compiler turn into
+





Comment at: clang/docs/SYCLSupport.md:851
+
+Changing variable type has massive and destructive effect in C++. For instance
+this does not compile in C++ for OpenCL mode:





Comment at: clang/docs/SYCLSupport.md:899-900
+
+Depending on the compiler mode `multi_ptr` will either decorate internal data
+with address space attribute or not.
+





Comment at: clang/docs/SYCLSupport.md:902
+
+To utilize existing clang's functionality, we re-use following OpenCL address
+space attributes for decoration pointers implementation:





Comment at: clang/docs/SYCLSupport.md:903
+To utilize existing clang's functionality, we re-use following OpenCL address
+space attributes for decoration pointers implementation:
+





Comment at: clang/docs/SYCLSupport.md:914
+
+Default address space represents "Generic-memory", which is a virtual address
+space which overlaps the global, local and private address spaces. SYCL mode





Comment at: clang/docs/SYCLSupport.md:915
+Default address space represents "Generic-memory", which is a virtual address
+space which overlaps the global, local and private address spaces. SYCL mode
+enables conversion to/from default address space from/to address space





Comment at: clang/docs/SYCLSupport.md:916
+space which overlaps the global, local and private address spaces. SYCL mode
+enables conversion to/from default address space from/to address space
+attributed type.





Comment at: clang/docs/SYCLSupport.md:919
+
+SPIR target allocates SYCL namespace scope variables in global address space.
+




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99488

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


[clang] f1e0c7f - [SystemZ][z/OS] Add test of leading zero length bitfield in const/volatile struct

2021-03-29 Thread Fanbo Meng via cfe-commits

Author: Fanbo Meng
Date: 2021-03-29T12:06:30-04:00
New Revision: f1e0c7fdd72026f62e2c38ee249705fbb9213a30

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

LOG: [SystemZ][z/OS] Add test of leading zero length bitfield in const/volatile 
struct

Reviewed By: abhina.sreeskantharajan

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

Added: 


Modified: 
clang/test/CodeGen/SystemZ/zos-alignment.c

Removed: 




diff  --git a/clang/test/CodeGen/SystemZ/zos-alignment.c 
b/clang/test/CodeGen/SystemZ/zos-alignment.c
index 9371a54403e4..b43968410cec 100644
--- a/clang/test/CodeGen/SystemZ/zos-alignment.c
+++ b/clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -12,6 +12,24 @@ int f0() { return v0 + v1 + v2 + v3; }
 // DECL-NEXT: @v2 {{.*}} align 16
 // DECL-NEXT: @v3 {{.*}} align 32
 
+const struct cs0 {
+  unsigned long   :0;
+  long longa;
+} CS0 = {};
+// CHECK:  0 | struct cs0
+// CHECK-NEXT:   0:- |   unsigned long
+// CHECK-NEXT: 0 |   long long a
+// CHECK-NEXT:   | [sizeof=8, align=8]
+
+volatile struct vs0 {
+  long:0;
+  short   a;
+} VS0;
+// CHECK:  0 | struct vs0
+// CHECK-NEXT:   0:- |   long
+// CHECK-NEXT: 0 |   short a
+// CHECK-NEXT:   | [sizeof=2, align=2]
+
 struct s0 {
   short a:3;
   long b:5;



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


[PATCH] D99508: [SystemZ][z/OS] Add test of leading zero length bitfield in const/volatile struct

2021-03-29 Thread Fanbo Meng via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf1e0c7fdd720: [SystemZ][z/OS] Add test of leading zero 
length bitfield in const/volatile… (authored by fanbo-meng).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99508

Files:
  clang/test/CodeGen/SystemZ/zos-alignment.c


Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -12,6 +12,24 @@
 // DECL-NEXT: @v2 {{.*}} align 16
 // DECL-NEXT: @v3 {{.*}} align 32
 
+const struct cs0 {
+  unsigned long   :0;
+  long longa;
+} CS0 = {};
+// CHECK:  0 | struct cs0
+// CHECK-NEXT:   0:- |   unsigned long
+// CHECK-NEXT: 0 |   long long a
+// CHECK-NEXT:   | [sizeof=8, align=8]
+
+volatile struct vs0 {
+  long:0;
+  short   a;
+} VS0;
+// CHECK:  0 | struct vs0
+// CHECK-NEXT:   0:- |   long
+// CHECK-NEXT: 0 |   short a
+// CHECK-NEXT:   | [sizeof=2, align=2]
+
 struct s0 {
   short a:3;
   long b:5;


Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -12,6 +12,24 @@
 // DECL-NEXT: @v2 {{.*}} align 16
 // DECL-NEXT: @v3 {{.*}} align 32
 
+const struct cs0 {
+  unsigned long   :0;
+  long longa;
+} CS0 = {};
+// CHECK:  0 | struct cs0
+// CHECK-NEXT:   0:- |   unsigned long
+// CHECK-NEXT: 0 |   long long a
+// CHECK-NEXT:   | [sizeof=8, align=8]
+
+volatile struct vs0 {
+  long:0;
+  short   a;
+} VS0;
+// CHECK:  0 | struct vs0
+// CHECK-NEXT:   0:- |   long
+// CHECK-NEXT: 0 |   short a
+// CHECK-NEXT:   | [sizeof=2, align=2]
+
 struct s0 {
   short a:3;
   long b:5;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99506: [OpenMP][NFC] Move the `noinline` to the parallel entry point

2021-03-29 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert updated this revision to Diff 333895.
jdoerfert added a comment.

Add test for nvptx codegen, including wrapper attribute check


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99506

Files:
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/test/OpenMP/nvptx_parallel_codegen.cpp


Index: clang/test/OpenMP/nvptx_parallel_codegen.cpp
===
--- clang/test/OpenMP/nvptx_parallel_codegen.cpp
+++ clang/test/OpenMP/nvptx_parallel_codegen.cpp
@@ -4,7 +4,7 @@
 // RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx64-unknown-unknown 
-fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-ppc-host.bc -o - -disable-llvm-optzns 
-fopenmp-cuda-parallel-target-regions | FileCheck %s --check-prefix CHECK 
--check-prefix CHECK-64 --check-prefix PAR
 // RUN: %clang_cc1 -verify -fopenmp -x c++ -triple i386-unknown-unknown 
-fopenmp-targets=nvptx-nvidia-cuda -emit-llvm-bc %s -o %t-x86-host.bc
 // RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx-unknown-unknown 
-fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-x86-host.bc -o - -disable-llvm-optzns | FileCheck 
%s --check-prefix CHECK --check-prefix CHECK-32 --check-prefix SEQ
-// RUN: %clang_cc1 -verify -fopenmp -fexceptions -fcxx-exceptions -x c++ 
-triple nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s 
-fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - 
-disable-llvm-optzns | FileCheck %s --check-prefix CHECK --check-prefix 
CHECK-32 --check-prefix SEQ
+// RUN: %clang_cc1 -verify -fopenmp -fexceptions -fcxx-exceptions -x c++ 
-triple nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s 
-fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - 
-disable-llvm-optzns -disable-O0-optnone | FileCheck %s --check-prefix CHECK 
--check-prefix CHECK-32 --check-prefix SEQ
 // RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx-unknown-unknown 
-fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s -fopenmp-is-device 
-fopenmp-host-ir-file-path %t-x86-host.bc -o - -disable-llvm-optzns 
-fopenmp-cuda-parallel-target-regions | FileCheck %s --check-prefix CHECK 
--check-prefix CHECK-32 --check-prefix PAR
 // RUN: %clang_cc1 -verify -fopenmp -fexceptions -fcxx-exceptions -x c++ 
-triple nvptx-unknown-unknown -fopenmp-targets=nvptx-nvidia-cuda -emit-llvm %s 
-fopenmp-is-device -fopenmp-host-ir-file-path %t-x86-host.bc -o - 
-disable-llvm-optzns -fopenmp-cuda-parallel-target-regions | FileCheck %s 
--check-prefix CHECK --check-prefix CHECK-32 --check-prefix PAR
 // expected-no-diagnostics
@@ -318,7 +318,8 @@
 // CHECK: [[EXIT]]
 // CHECK: ret void
 
-// CHECK: define internal void [[PARALLEL_FN4]](
+// CHECK: noinline
+// CHECK-NEXT: define internal void [[PARALLEL_FN4]](
 // CHECK: [[A:%.+]] = alloca i[[SZ:32|64]],
 // CHECK: store i[[SZ]] 45, i[[SZ]]* %a,
 // CHECK: call void @__kmpc_barrier(%struct.ident_t* @{{.+}}, i32 %{{.+}})
@@ -326,6 +327,9 @@
 
 // CHECK: declare void @__kmpc_barrier(%struct.ident_t*, i32) #[[#CONVERGENT:]]
 
+// CHECK: Function Attrs: convergent noinline norecurse nounwind
+// CHECK-NEXT: [[PARALLEL_FN4]]_wrapper
+
 // CHECK-LABEL: define {{.*}}void 
{{@__omp_offloading_.+template.+l58}}_worker()
 // CHECK-LABEL: define {{.*}}void {{@__omp_offloading_.+template.+l58}}(
 // CHECK-32: [[A_ADDR:%.+]] = alloca i32,
@@ -373,7 +377,6 @@
 // CHECK:  store i32 [[NEW_CC_VAL]], i32* [[CC]],
 // CHECK:  br label
 
-
 // CHECK: declare i32 @__kmpc_warp_active_thread_mask() #[[#CONVERGENT:]]
 // CHECK: declare void @__kmpc_syncwarp(i32) #[[#CONVERGENT:]]
 
Index: clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
@@ -2093,14 +2093,6 @@
   // Force inline this outlined function at its call site.
   Fn->setLinkage(llvm::GlobalValue::InternalLinkage);
 
-  // Ensure we do not inline the function. This is trivially true for the ones
-  // passed to __kmpc_fork_call but the ones calles in serialized regions
-  // could be inlined. This is not a perfect but it is closer to the invariant
-  // we want, namely, every data environment starts with a new function.
-  // TODO: We should pass the if condition to the runtime function and do the
-  //   handling there. Much cleaner code.
-  cast(OutlinedFn)->addFnAttr(llvm::Attribute::NoInline);
-
   Address ZeroAddr = CGF.CreateDefaultAlignTempAlloca(CGF.Int32Ty,
   /*Name=*/".zero.addr");
   CGF.InitTempAlloca(ZeroAddr, CGF.Builder.getInt32(/*C*/ 0));
@@ -4216,6 +4208,15 @@
   auto *Fn = llvm::Function::Create(
   CGM.getTypes().GetFunctionType(CGFI), llvm::GlobalValue::InternalLinkage,
   Twine(OutlinedParallelFn->ge

[PATCH] D99514: [NFC] clang-formatting zos-alignment.c

2021-03-29 Thread Fanbo Meng via Phabricator via cfe-commits
fanbo-meng created this revision.
fanbo-meng added a reviewer: abhina.sreeskantharajan.
fanbo-meng requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99514

Files:
  clang/test/CodeGen/SystemZ/zos-alignment.c

Index: clang/test/CodeGen/SystemZ/zos-alignment.c
===
--- clang/test/CodeGen/SystemZ/zos-alignment.c
+++ clang/test/CodeGen/SystemZ/zos-alignment.c
@@ -13,8 +13,8 @@
 // DECL-NEXT: @v3 {{.*}} align 32
 
 const struct cs0 {
-  unsigned long   :0;
-  long longa;
+  unsigned long : 0;
+  long long a;
 } CS0 = {};
 // CHECK:  0 | struct cs0
 // CHECK-NEXT:   0:- |   unsigned long
@@ -22,8 +22,8 @@
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
 volatile struct vs0 {
-  long:0;
-  short   a;
+  long : 0;
+  short a;
 } VS0;
 // CHECK:  0 | struct vs0
 // CHECK-NEXT:   0:- |   long
@@ -31,11 +31,11 @@
 // CHECK-NEXT:   | [sizeof=2, align=2]
 
 struct s0 {
-  short a:3;
-  long b:5;
-  int c:1;
-  long d:10;
-  char e:5;
+  short a : 3;
+  long b : 5;
+  int c : 1;
+  long d : 10;
+  char e : 5;
 } S0;
 // CHECK:  0 | struct s0
 // CHECK-NEXT: 0:0-2 |   short a
@@ -46,9 +46,9 @@
 // CHECK-NEXT:   | [sizeof=3, align=1]
 
 struct s1 {
-  char a:7;
-  long b:27;
-  int c:2;
+  char a : 7;
+  long b : 27;
+  int c : 2;
 } S1;
 // CHECK:  0 | struct s1
 // CHECK-NEXT: 0:0-6 |   char a
@@ -57,10 +57,10 @@
 // CHECK-NEXT:   | [sizeof=5, align=1]
 
 struct s2 {
-  char a:7;
-  char  :0;
-  short :0;
-  short :0;
+  char a : 7;
+  char : 0;
+  short : 0;
+  short : 0;
 } S2;
 // CHECK:  0 | struct s2
 // CHECK-NEXT: 0:0-6 |   char a
@@ -71,9 +71,9 @@
 
 struct s3 {
   int a;
-  int b:16;
-  char  :0;
-  char c:1;
+  int b : 16;
+  char : 0;
+  char c : 1;
 } S3;
 // CHECK:  0 | struct s3
 // CHECK-NEXT: 0 |   int a
@@ -83,7 +83,7 @@
 // CHECK-NEXT:   | [sizeof=12, align=4]
 
 struct s4 {
- unsigned int __attribute__((aligned(32))) a;
+  unsigned int __attribute__((aligned(32))) a;
 } S4;
 // CHECK:  0 | struct s4
 // CHECK-NEXT: 0 |   unsigned int a
@@ -91,10 +91,10 @@
 
 struct s5 {
   char a;
-  int  b:19 __attribute__((aligned(4)));
-  int  c:22 __attribute__((aligned(8)));
-  int  :0;
-  int  d:10;
+  int b : 19 __attribute__((aligned(4)));
+  int c : 22 __attribute__((aligned(8)));
+  int : 0;
+  int d : 10;
 } S5;
 // CHECK:  0 | struct s5
 // CHECK-NEXT: 0 |   char a
@@ -105,8 +105,8 @@
 // CHECK-NEXT:   | [sizeof=16, align=8]
 
 struct s6 {
-  char * a;
-  char * b[];
+  char *a;
+  char *b[];
 } S6;
 // CHECK:  0 | struct s6
 // CHECK-NEXT: 0 |   char * a
@@ -114,7 +114,7 @@
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
 struct s7 {
-  long  :0;
+  long : 0;
   short a;
 } S7;
 // CHECK:  0 | struct s7
@@ -124,8 +124,8 @@
 
 #pragma pack(2)
 struct s8 {
-  unsigned long   :0;
-  long long   a;
+  unsigned long : 0;
+  long long a;
 } S8;
 #pragma pack()
 // CHECK:  0 | struct s8
@@ -134,8 +134,8 @@
 // CHECK-NEXT:   | [sizeof=8, align=2]
 
 struct s9 {
-  unsigned int   :0;
-  unsigned short :0;
+  unsigned int : 0;
+  unsigned short : 0;
 } S9;
 // CHECK:  0 | struct s9
 // CHECK-NEXT:   0:- |   unsigned int
@@ -143,7 +143,7 @@
 // CHECK-NEXT:   | [sizeof=0, align=1]
 
 struct s10 {
- unsigned int __attribute__((aligned)) a;
+  unsigned int __attribute__((aligned)) a;
 } S10;
 // CHECK:  0 | struct s10
 // CHECK-NEXT: 0 |   unsigned int a
@@ -151,7 +151,7 @@
 
 struct s11 {
   char a;
-  long :0;
+  long : 0;
   char b;
 } S11;
 // CHECK:  0 | struct s11
@@ -161,9 +161,9 @@
 // CHECK-NEXT:   | [sizeof=16, align=8]
 
 union u0 {
-  unsigned short d1 __attribute__((packed));
-  intd2:10;
-  long   d3;
+  unsigned short d1 __attribute__((packed));
+  int d2 : 10;
+  long d3;
 } U0 __attribute__((aligned(8)));
 // CHECK:  0 | union u0
 // CHECK-NEXT: 0 |   unsigned short d1
@@ -172,8 +172,8 @@
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
 union u1 {
-  unsigned int:0;
-  short   a;
+  unsigned int : 0;
+  short a;
 } U1;
 // CHECK:  0 | union u1
 // CHECK-NEXT:   0:- |   unsigned int
@@ -181,8 +181,8 @@
 // CHECK-NEXT:   | [sizeof=4, align=4]
 
 union u2 {
-  long  :0;
-  short  a;
+  long : 0;
+  short a;
 } U2;
 // CHECK:  0 | union u2
 // CHECK-NEXT:   0:- |   long
@@ -190,8 +190,8 @@
 // CHECK-NEXT:   | [sizeof=8, align=8]
 
 union u3 {
-  unsigned char :0;
-  unsigned short :0;
+  unsigned char : 0;
+  unsigned short : 0;
 } U3;
 // CHECK:  0 | 

[PATCH] D99297: [OPENMP]Fix PR49636: Assertion `(!Entry.getAddress() || Entry.getAddress() == Addr) && "Resetting with the new address."' failed.

2021-03-29 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

LGTM for CUDA.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99297

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


[clang] 9320ac9 - [Clang] Only run test when X86 backend is built.

2021-03-29 Thread Florian Hahn via cfe-commits

Author: Florian Hahn
Date: 2021-03-29T17:27:01+01:00
New Revision: 9320ac9b4965d769632398b620ca3e4af9b56b12

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

LOG: [Clang] Only run test when X86 backend is built.

After c773d0f97304 the remark is only emitted if the loop is profitable
to vectorize, but cannot be vectorized. Hence, it depends on
X86-specific cost-modeling.

Added: 


Modified: 
clang/test/Frontend/optimization-remark-options.c

Removed: 




diff  --git a/clang/test/Frontend/optimization-remark-options.c 
b/clang/test/Frontend/optimization-remark-options.c
index 38dbbfbaccec0..f222eff37a5ef 100644
--- a/clang/test/Frontend/optimization-remark-options.c
+++ b/clang/test/Frontend/optimization-remark-options.c
@@ -1,3 +1,4 @@
+// REQUIRES: x86-registered-target
 // RUN: %clang -O1 -fvectorize -target x86_64-unknown-unknown 
-Rpass-analysis=loop-vectorize -emit-llvm -S %s -o - 2>&1 | FileCheck %s
 
 // CHECK: {{.*}}:9:11: remark: loop not vectorized: cannot prove it is safe to 
reorder floating-point operations; allow reordering by specifying '#pragma 
clang loop vectorize(enable)' before the loop or by providing the compiler 
option '-ffast-math'.



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


[PATCH] D99489: [clang] [PR49736] [C++2b] Correctly reject lambdas with requires clause and no parameter list

2021-03-29 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius updated this revision to Diff 333910.
curdeius added a comment.

- Hoist common code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99489

Files:
  clang/lib/Parse/ParseExprCXX.cpp
  clang/test/Parser/cxx-concepts-requires-clause.cpp
  clang/test/Parser/cxx2a-template-lambdas.cpp
  clang/test/Parser/cxx2b-lambdas.cpp

Index: clang/test/Parser/cxx2b-lambdas.cpp
===
--- clang/test/Parser/cxx2b-lambdas.cpp
+++ clang/test/Parser/cxx2b-lambdas.cpp
@@ -18,8 +18,8 @@
 auto L10 = [] noexcept { return true; };
 auto L11 = [] -> bool { return true; };
 auto L12 = [] consteval {};
-auto L13 = [] requires requires() { true; }
-{};
+auto L13 = []() requires true {};
+auto L14 = [] requires true() requires true {};
 auto L15 = [] [[maybe_unused]]{};
 
 auto XL0 = [] mutable constexpr mutable {};// expected-error{{cannot appear multiple times}}
@@ -32,3 +32,11 @@
// expected-note{{to match this '('}} \
// expected-error{{expected body}} \
// expected-warning{{duplicate 'constexpr'}}
+
+// http://llvm.org/PR49736
+auto XL4 = [] requires true() {}; // expected-error{{expected body}}
+auto XL5 = [] requires true {}; // expected-error{{expected body}}
+auto XL6 = [] requires true requires true {}; // expected-error{{expected body}}
+auto XL7 = [] requires true noexcept requires true {}; // expected-error{{expected body}}
+auto XL8 = [] requires true requires true {}; // expected-error{{expected body}}
+auto XL9 = [] requires true noexcept requires true {}; // expected-error{{expected body}}
Index: clang/test/Parser/cxx2a-template-lambdas.cpp
===
--- clang/test/Parser/cxx2a-template-lambdas.cpp
+++ clang/test/Parser/cxx2a-template-lambdas.cpp
@@ -7,3 +7,30 @@
 auto L2 = [](T1 arg1, T2 arg2) -> T1 { };
 auto L3 = [](auto arg) { T t; };
 auto L4 = []() { };
+
+// http://llvm.org/PR49736
+auto L5 = []{};
+auto L6 = [] noexcept {};
+#if __cplusplus <= 202002L
+// expected-warning@-2 {{is a C++2b extension}}
+#endif
+auto L7 = [] requires true {}; // ?
+auto L8 = [] requires true noexcept {};
+#if __cplusplus <= 202002L
+// expected-warning@-2 {{is a C++2b extension}}
+#endif
+
+auto L9 = [](){};
+auto L10 = []() noexcept {};
+auto L11 = [] requires true(){};
+auto L12 = [] requires true() noexcept {};
+auto L13 = [] requires true() noexcept requires true {};
+auto L14 = []() noexcept requires true {};
+auto L15 = [] requires true(){};
+
+auto XL0 = [] noexcept requires true {}; // expected-error {{expected body}}
+auto XL1 = [] noexcept requires true {}; // expected-error {{expected body}}
+#if __cplusplus <= 202002L
+// expected-warning@-3 {{is a C++2b extension}}
+// expected-warning@-3 {{is a C++2b extension}}
+#endif
Index: clang/test/Parser/cxx-concepts-requires-clause.cpp
===
--- clang/test/Parser/cxx-concepts-requires-clause.cpp
+++ clang/test/Parser/cxx-concepts-requires-clause.cpp
@@ -154,7 +154,9 @@
 
 auto lambda2 = [] (auto x) constexpr -> int requires (sizeof(decltype(x)) == 1) { return 0; };
 
-auto lambda3 = [] requires (sizeof(char) == 1) { };
+auto lambda3 = [] requires(sizeof(char) == 1){};
+
+auto lambda4 = [] requires(sizeof(char) == 1){}; // expected-error {{expected body}}
 #if __cplusplus <= 202002L
 // expected-warning@-2{{is a C++2b extension}}
 #endif
Index: clang/lib/Parse/ParseExprCXX.cpp
===
--- clang/lib/Parse/ParseExprCXX.cpp
+++ clang/lib/Parse/ParseExprCXX.cpp
@@ -1392,12 +1392,6 @@
 /*DeclsInPrototype=*/None, LParenLoc, FunLocalRangeEnd, D,
 TrailingReturnType, TrailingReturnTypeLoc, &DS),
 std::move(Attr), DeclEndLoc);
-
-// Parse requires-clause[opt].
-if (Tok.is(tok::kw_requires))
-  ParseTrailingRequiresClause(D);
-
-WarnIfHasCUDATargetAttr();
   };
 
   if (Tok.is(tok::l_paren)) {
@@ -1433,6 +1427,10 @@
 // Parse lambda-specifiers.
 ParseLambdaSpecifiers(LParenLoc, /*DeclEndLoc=*/T.getCloseLocation(),
   ParamInfo, EllipsisLoc);
+
+// Parse requires-clause[opt].
+if (Tok.is(tok::kw_requires))
+  ParseTrailingRequiresClause(D);
   } else if (Tok.isOneOf(tok::kw_mutable, tok::arrow, tok::kw___attribute,
  tok::kw_constexpr, tok::kw_consteval,
  tok::kw___private, tok::kw___global, tok::kw___local,
@@ -1453,6 +1451,8 @@
   EmptyParamInfo, /*EllipsisLoc=*/NoLoc);
   }
 
+  WarnIfHasCUDATargetAttr();
+
   // FIXME: Rename BlockScope -> ClosureScope if we decide to continue using
   // it.
   unsigned ScopeFlags = 

[clang] d3ff65d - [Clang] Fix line numbers in CHECK lines.

2021-03-29 Thread Florian Hahn via cfe-commits

Author: Florian Hahn
Date: 2021-03-29T17:37:48+01:00
New Revision: d3ff65dc11d797c39bb44621d64eb679c09207de

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

LOG: [Clang] Fix line numbers in CHECK lines.

Added: 


Modified: 
clang/test/Frontend/optimization-remark-options.c

Removed: 




diff  --git a/clang/test/Frontend/optimization-remark-options.c 
b/clang/test/Frontend/optimization-remark-options.c
index f222eff37a5e..3509a388d0f6 100644
--- a/clang/test/Frontend/optimization-remark-options.c
+++ b/clang/test/Frontend/optimization-remark-options.c
@@ -1,7 +1,7 @@
 // REQUIRES: x86-registered-target
 // RUN: %clang -O1 -fvectorize -target x86_64-unknown-unknown 
-Rpass-analysis=loop-vectorize -emit-llvm -S %s -o - 2>&1 | FileCheck %s
 
-// CHECK: {{.*}}:9:11: remark: loop not vectorized: cannot prove it is safe to 
reorder floating-point operations; allow reordering by specifying '#pragma 
clang loop vectorize(enable)' before the loop or by providing the compiler 
option '-ffast-math'.
+// CHECK: {{.*}}:10:11: remark: loop not vectorized: cannot prove it is safe 
to reorder floating-point operations; allow reordering by specifying '#pragma 
clang loop vectorize(enable)' before the loop or by providing the compiler 
option '-ffast-math'.
 
 double foo(int N) {
   double v = 0.0;
@@ -12,7 +12,7 @@ double foo(int N) {
   return v;
 }
 
-// CHECK: {{.*}}:17:3: remark: loop not vectorized: cannot prove it is safe to 
reorder memory operations; allow reordering by specifying '#pragma clang loop 
vectorize(enable)' before the loop. If the arrays will always be independent 
specify '#pragma clang loop vectorize(assume_safety)' before the loop or 
provide the '__restrict__' qualifier with the independent array arguments. 
Erroneous results will occur if these options are incorrectly applied!
+// CHECK: {{.*}}:18:3: remark: loop not vectorized: cannot prove it is safe to 
reorder memory operations; allow reordering by specifying '#pragma clang loop 
vectorize(enable)' before the loop. If the arrays will always be independent 
specify '#pragma clang loop vectorize(assume_safety)' before the loop or 
provide the '__restrict__' qualifier with the independent array arguments. 
Erroneous results will occur if these options are incorrectly applied!
 
 void foo2(int *dw, int *uw, int *A, int *B, int *C, int *D, int N) {
   for (long i = 0; i < N; i++) {



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


[PATCH] D99278: [clang][parser] Allow GNU-style attributes in struct declarations

2021-03-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

To be clear, this is expected to be an NFC change that allows D97362 
 to be applied without breaking bots? If so, 
it'd be helpful to have the changes as part of D97362 
 because they're critical to that review and 
so that we get appropriate CI pre-merge testing.


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

https://reviews.llvm.org/D99278

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


[PATCH] D99338: [clang][parser] Allow GNU-style attributes in enum specifiers

2021-03-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

To be clear, this is expected to be an NFC change that allows D97362 
 to be applied without breaking bots? If so, 
it'd be helpful to have the changes as part of D97362 
 because they're critical to that review and 
so that we get appropriate CI pre-merge testing.


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

https://reviews.llvm.org/D99338

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


[PATCH] D99488: [SYCL][Doc] Add address space handling section to SYCL documentation

2021-03-29 Thread Victor Lomuller via Phabricator via cfe-commits
Naghasan added inline comments.



Comment at: clang/docs/SYCLSupport.md:914-919
+Default address space represents "Generic-memory", which is a virtual address
+space which overlaps the global, local and private address spaces. SYCL mode
+enables conversion to/from default address space from/to address space
+attributed type.
+
+SPIR target allocates SYCL namespace scope variables in global address space.

aaron.ballman wrote:
> 
I think this section should be extended.

Pointers to `Default` address space should get lowered into a pointer to a 
generic address space (or flat to reuse more general terminology).
But depending on the allocation context, the `default` address space of a 
non-pointer type is assigned to a specific address space. This is described in 
https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:commonAddressSpace.

This is also in line with the behaviour of CUDA (small example 
https://godbolt.org/z/veqTfo9PK).



Comment at: clang/docs/SYCLSupport.md:818-819
+
+SYCL specification uses C++ classes to represent pointers to disjoint memory
+regions on an accelerator to enable compilation with standard C++ toolchain and
+SYCL compiler toolchain. Section 3.8.2 of SYCL 2020 specification defines

Or more simply just `SYCL specification uses C++ wrapper classes`.

`multi_ptr` are not "pointers to" but a wrapper around the actual pointer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99488

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


[PATCH] D98146: OpaquePtr: Turn inalloca into a type attribute

2021-03-29 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D98146#2654598 , @arsenm wrote:

> 4fefed65637ec46c8c2edad6b07b5569ac61e9e5 
> 

Please include the "Differential Revision: ..." line in the commit message - it 
automatically closes the review with the details of the commit (including 
updating to show what was committed/what changes were made between review and 
commit) and helps find the review from the commit, etc.


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

https://reviews.llvm.org/D98146

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


[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

2021-03-29 Thread Josh Haberman via Phabricator via cfe-commits
haberman created this revision.
haberman added reviewers: rsmith, aaron.ballman.
haberman requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This is a Clang-only change and depends on the existing "musttail"
support already implemented in LLVM.

The [[clang::musttail]] attribute goes on a return statement, not
a function definition. There are several constraints that the user
must follow when using [[clang::musttail]], and these constraints
are verified by Sema.

Tail calls are supported on regular function calls, calls through a
function pointer, member function calls, and even pointer to member.

Future work would be to throw a warning if a users tries to pass
a pointer or reference to a local variable through a musttail call.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99517

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/JumpDiagnostics.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaStmtAttr.cpp
  clang/test/CodeGen/attr-musttail.cpp
  clang/test/Sema/attr-musttail.cpp

Index: clang/test/Sema/attr-musttail.cpp
===
--- /dev/null
+++ clang/test/Sema/attr-musttail.cpp
@@ -0,0 +1,137 @@
+// RUN: %clang_cc1 -verify -fsyntax-only %s
+
+int Bar();
+
+int Func1() {
+  [[clang::musttail(1, 2)]] Bar(); // expected-error {{'musttail' attribute takes no arguments}}
+  [[clang::musttail]] Bar(); // expected-error {{musttail attribute can only be applied to a return statement}}
+  [[clang::musttail]] return 5; // expected-error {{musttail attribute requires that the return value is a function call}}
+  [[clang::musttail]] return Bar();
+}
+
+int f();
+
+[[clang::musttail]] static int i = f(); // expected-error {{'musttail' attribute cannot be applied to a declaration}}
+
+long g(int x);
+int h(long x);
+
+class Foo {
+ public:
+  int MemberFunction(int x);
+  int MemberFunction2();
+};
+
+int Func2(int x) {
+  // Param arity differs.
+  [[clang::musttail]] return Bar(); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+  // Return type differs.
+  [[clang::musttail]] return g(x); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+  // Param type differs.
+  [[clang::musttail]] return h(x); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+  // "this" pointer differs.
+  Foo foo;
+  [[clang::musttail]] return foo.MemberFunction(x); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+}
+
+int j = 0;
+
+class HasNonTrivialDestructor {
+ public:
+  ~HasNonTrivialDestructor() { j--; }
+};
+
+int ReturnsInt(int x);
+
+int Func3(int x) {
+  HasNonTrivialDestructor foo;  // expected-note {{jump exits scope of variable with non-trivial destructor}}
+  [[clang::musttail]] return ReturnsInt(x);  // expected-error {{musttail attribute does not allow any variables in scope that require destruction}}
+}
+
+int Func4(int x) {
+  HasNonTrivialDestructor foo;  // expected-note {{jump exits scope of variable with non-trivial destructor}}
+  {
+[[clang::musttail]] return ReturnsInt(x);  // expected-error {{musttail attribute does not allow any variables in scope that require destruction}}
+  }
+}
+
+int NonTrivialParam(HasNonTrivialDestructor x);
+
+int Func5(HasNonTrivialDestructor x) {
+  [[clang::musttail]] return NonTrivialParam(x);  // expected-error {{musttail attribute requires that the return value is a function call, which must not create or destroy any temporaries}}
+}
+
+HasNonTrivialDestructor ReturnsNonTrivialValue();
+
+HasNonTrivialDestructor Func6() {
+  [[clang::musttail]] return ReturnsNonTrivialValue();  // expected-error {{musttail attribute requires that the return value is a function call, which must not create or destroy any temporaries}}
+}
+
+int Func8(Foo* foo, int (Foo::*p_mem)()) {
+  [[clang::musttail]] return (foo->*p_mem)(); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+}
+
+int Func10(Foo* foo) {
+  [[clang::musttail]] return foo->MemberFunction2(); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+}
+
+void Func7() {
+  HasNonTrivialDestructor foo;
+  class Nested {
+__attribute__((noinline)) static int NestedMethod(int x) {
+  // This is ok.
+  [[clang::musttail]] return ReturnsInt(x);

[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

2021-03-29 Thread Josh Haberman via Phabricator via cfe-commits
haberman updated this revision to Diff 333914.
haberman added a comment.

- Updated formatting.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99517

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/JumpDiagnostics.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaStmtAttr.cpp
  clang/test/CodeGen/attr-musttail.cpp
  clang/test/Sema/attr-musttail.cpp

Index: clang/test/Sema/attr-musttail.cpp
===
--- /dev/null
+++ clang/test/Sema/attr-musttail.cpp
@@ -0,0 +1,137 @@
+// RUN: %clang_cc1 -verify -fsyntax-only %s
+
+int Bar();
+
+int Func1() {
+  [[clang::musttail(1, 2)]] Bar(); // expected-error {{'musttail' attribute takes no arguments}}
+  [[clang::musttail]] Bar();   // expected-error {{musttail attribute can only be applied to a return statement}}
+  [[clang::musttail]] return 5;// expected-error {{musttail attribute requires that the return value is a function call}}
+  [[clang::musttail]] return Bar();
+}
+
+int f();
+
+[[clang::musttail]] static int i = f(); // expected-error {{'musttail' attribute cannot be applied to a declaration}}
+
+long g(int x);
+int h(long x);
+
+class Foo {
+public:
+  int MemberFunction(int x);
+  int MemberFunction2();
+};
+
+int Func2(int x) {
+  // Param arity differs.
+  [[clang::musttail]] return Bar(); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+  // Return type differs.
+  [[clang::musttail]] return g(x); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+  // Param type differs.
+  [[clang::musttail]] return h(x); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+  // "this" pointer differs.
+  Foo foo;
+  [[clang::musttail]] return foo.MemberFunction(x); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+}
+
+int j = 0;
+
+class HasNonTrivialDestructor {
+public:
+  ~HasNonTrivialDestructor() { j--; }
+};
+
+int ReturnsInt(int x);
+
+int Func3(int x) {
+  HasNonTrivialDestructor foo;  // expected-note {{jump exits scope of variable with non-trivial destructor}}
+  [[clang::musttail]] return ReturnsInt(x); // expected-error {{musttail attribute does not allow any variables in scope that require destruction}}
+}
+
+int Func4(int x) {
+  HasNonTrivialDestructor foo; // expected-note {{jump exits scope of variable with non-trivial destructor}}
+  {
+[[clang::musttail]] return ReturnsInt(x); // expected-error {{musttail attribute does not allow any variables in scope that require destruction}}
+  }
+}
+
+int NonTrivialParam(HasNonTrivialDestructor x);
+
+int Func5(HasNonTrivialDestructor x) {
+  [[clang::musttail]] return NonTrivialParam(x); // expected-error {{musttail attribute requires that the return value is a function call, which must not create or destroy any temporaries}}
+}
+
+HasNonTrivialDestructor ReturnsNonTrivialValue();
+
+HasNonTrivialDestructor Func6() {
+  [[clang::musttail]] return ReturnsNonTrivialValue(); // expected-error {{musttail attribute requires that the return value is a function call, which must not create or destroy any temporaries}}
+}
+
+int Func8(Foo *foo, int (Foo::*p_mem)()) {
+  [[clang::musttail]] return (foo->*p_mem)(); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+}
+
+int Func10(Foo *foo) {
+  [[clang::musttail]] return foo->MemberFunction2(); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+}
+
+void Func7() {
+  HasNonTrivialDestructor foo;
+  class Nested {
+__attribute__((noinline)) static int NestedMethod(int x) {
+  // This is ok.
+  [[clang::musttail]] return ReturnsInt(x);
+}
+  };
+}
+
+struct Data {
+  int (Data::*pmf)();
+  typedef int Func(Data *);
+  static void StaticMethod();
+  void NonStaticMethod() {
+[[clang::musttail]] return StaticMethod(); // expected-error {{musttail attribute requires that caller and callee have identical parameter types and return types}}
+  }
+
+  void BadPMF() {
+// We need to specially handle this, otherwise it can crash the compiler.
+[[clang::musttail]] return ((*this)->*pmf)(); // expected-error {{left hand operand to ->* must be a pointer to class compatible with the right hand operand, but is 'Data'}}
+  }
+};
+
+Data data

[PATCH] D99353: [driver] Make `clang` warn rather then error on `flang` options

2021-03-29 Thread Joachim Protze via Phabricator via cfe-commits
protze.joachim added a comment.

Thank you for working on this! It works for me.
As you mentioned in D95460 , this makes the 
behavior more similar to gcc.

I tested with `-Werror`:

  $ flang -fopenmp test-f77.f -ffree-form -c
  $ clang -fopenmp test-f77.o -ffree-form -lgfortran -Werror && echo $?
  clang-13: warning: command line option ‘-ffree-form’ is only valid in Flang 
mode (i.e. for Fortran input)
  clang-13: error: argument unused during compilation: '-ffree-form' 
[-Werror,-Wunused-command-line-argument]

Since `-Werror` only raises the second warning, 
`-Wno-error=unused-command-line-argument` allows to successfully compile with 
`-Werror`.

  $ clang -fopenmp test-f77.o -ffree-form -lgfortran -Werror 
-Wno-error=unused-command-line-argument && echo $?
  clang-13: warning: command line option ‘-ffree-form’ is only valid in Flang 
mode (i.e. for Fortran input)
  clang-13: warning: argument unused during compilation: '-ffree-form' 
[-Wunused-command-line-argument]
  0

I also tested with `-ffixed-form` and `-ffixed-line-length-132`. The latter 
doesn't work, while `-ffixed-line-length=132` works.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99353

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


[PATCH] D99426: [Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text

2021-03-29 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

In D99426#2653725 , @MaskRay wrote:

> This touches a lot of files. I am a bit worried that it would not be easy for 
> a contributor to know OF_TextWithCRLF is needed to make SystemZ happy.

Right, we need to separate text-ness for System/Z EBCDIC re-encoding from 
Windows CRLF translation. I think it's best to have a separate, positive CRLF 
bit, and to make that spelling longer than OF_Text. I think, in general, more 
problems are caused by extra unintended CRLF than by missing carriage returns.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99426

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


[PATCH] D99514: [NFC] clang-formatting zos-alignment.c

2021-03-29 Thread Abhina Sree via Phabricator via cfe-commits
abhina.sreeskantharajan accepted this revision.
abhina.sreeskantharajan added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99514

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


[PATCH] D17183: Make TargetInfo store an actual DataLayout instead of a string.

2021-03-29 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

I think 1 is OK as long as we can assert that things don't get out of sync. I 
like the idea of putting the prefix next to the data layout string.

In the long run, splitting up Support might be reasonable, and pushing 
DataLayout down out of IR seems like something that could happen at that time. 
I would like to reduce the set of things that tablgen depends on by making 
Support into a smaller library of just system APIs and data structures, moving 
everything else out. Maybe the right way to do that is to leave Support as the 
ambiguous, kitchen sink library, and make a smaller, more targeted library 
under it. We already have the notion of the ADT library in our header structure 
for data structures. We used to have the System library before it was merged 
with Support. I think the only thing blocking this refactoring is the will to 
disentangle the circular dependencies.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D17183

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


[PATCH] D98193: [CUDA][HIP] Allow non-ODR use of host var in device

2021-03-29 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

I think we also may want to check that we allow `sizeof(host_var)` in the GPU 
code.


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

https://reviews.llvm.org/D98193

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


[PATCH] D99005: [clang] Implement P2266 Simpler implicit move

2021-03-29 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov updated this revision to Diff 333925.
mizvekov added a comment.

Small update making some invariants more clear, with some simplifications.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99005

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCoroutine.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CXX/class/class.init/class.copy.elision/p3.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p7-cxx14.cpp
  clang/test/CXX/drs/dr3xx.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/p4-cxx14.cpp
  clang/test/CXX/temp/temp.decls/temp.mem/p5.cpp
  clang/test/SemaCXX/constant-expression-cxx11.cpp
  clang/test/SemaCXX/constant-expression-cxx14.cpp
  clang/test/SemaCXX/coroutine-rvo.cpp
  clang/test/SemaCXX/coroutines.cpp
  clang/test/SemaCXX/deduced-return-type-cxx14.cpp
  clang/test/SemaCXX/return-stack-addr.cpp
  clang/test/SemaCXX/warn-return-std-move.cpp

Index: clang/test/SemaCXX/warn-return-std-move.cpp
===
--- clang/test/SemaCXX/warn-return-std-move.cpp
+++ clang/test/SemaCXX/warn-return-std-move.cpp
@@ -1,8 +1,8 @@
-// RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify=cxx20_2b -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=cxx20_2b -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify=cxx11_17 -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify=cxx11_17 -fcxx-exceptions -Wreturn-std-move %s
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=cxx11_17 -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify=cxx20_2b,cxx2b -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=cxx20_2b   -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify=cxx11_17   -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -verify=cxx11_17   -fcxx-exceptions -Wreturn-std-move %s
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=cxx11_17   -fcxx-exceptions -Wreturn-std-move %s
 
 // RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcxx-exceptions -Wreturn-std-move -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s -check-prefix=CHECK
 // RUN: %clang_cc1 -std=c++14 -fsyntax-only -fcxx-exceptions -Wreturn-std-move -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s -check-prefix=CHECK
@@ -217,8 +217,8 @@
 }
 
 // But if the return type is a reference type, then moving would be wrong.
-Derived& testRetRef1(Derived&& d) { return d; }
-Base& testRetRef2(Derived&& d) { return d; }
+Derived &testRetRef1(Derived &&d) { return d; } // cxx2b-error {{on-const lvalue reference to type 'Derived' cannot bind to a temporary of type 'Derived'}}
+Base &testRetRef2(Derived &&d) { return d; }// cxx2b-error {{non-const lvalue reference to type 'Base' cannot bind to a temporary of type 'Derived'}}
 #if __cplusplus >= 201402L
 auto&& testRetRef3(Derived&& d) { return d; }
 decltype(auto) testRetRef4(Derived&& d) { return (d); }
Index: clang/test/SemaCXX/return-stack-addr.cpp
===
--- clang/test/SemaCXX/return-stack-addr.cpp
+++ clang/test/SemaCXX/return-stack-addr.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify=expected   %s
-// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=expected   %s
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11 %s
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -verify=expected,cxx2b  %s
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify=expected,cxx11_20   %s
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -verify=expected,cxx11_20,cxx11 %s
 
 int* ret_local() {
   int x = 1;
@@ -29,7 +29,8 @@
 
 int& ret_local_ref() {
   int x = 1;
-  return x;  // expected-warning {{reference to stack memory}}
+  return x; // cxx11_20-warning {{reference to stack memory}}
+  // cxx2b-error@-1 {{non-const lvalue reference to type 'int' cannot bind to a temporary of type 'int'}}
 }
 
 int* ret_local_addrOf() {
@@ -154,8 +155,10 @@
   (void) [&]() -> int& { return b; };
   (void) [=]() mutable -> int& { return a; };
   (void) [=]() mutable -> int& { return b; };
-  (void) [&]() -> int& { int a; return a; }; // expected-warning {{reference to stack}}
-  (void) [=]() -> int& { int a; return a; }; // expected-warning {{reference to stack}}
+  (void) [&]() -> int& { int a; return a; }; // cxx11_20-warning {{reference to stack}}
+  // cxx2b-error@-1 {{non-const lvalue reference to type 'int' cannot bind to a temporary of type 'int'}}
+  (void) [=]() -> int& { int a; return a; }; // cxx11_20-warning {{reference to stack}}
+  // cxx2b-e

[PATCH] D99521: [OPENMP]Fix PR48885: Crash in passing firstprivate args to tasks on Apple M1.

2021-03-29 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev created this revision.
ABataev added a reviewer: jdoerfert.
Herald added subscribers: guansong, yaxunl.
ABataev requested review of this revision.
Herald added a project: clang.

Need to bitcast the function pointer passed as a parameter to the real
type to avoid possible problem with calling conventions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99521

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/declare_mapper_codegen.cpp
  clang/test/OpenMP/master_taskloop_firstprivate_codegen.cpp
  clang/test/OpenMP/master_taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/master_taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/master_taskloop_private_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_private_codegen.cpp
  clang/test/OpenMP/nvptx_param_translate.c
  clang/test/OpenMP/parallel_master_taskloop_firstprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_private_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_private_codegen.cpp
  clang/test/OpenMP/target_codegen.cpp
  clang/test/OpenMP/target_depend_codegen.cpp
  clang/test/OpenMP/target_enter_data_codegen.cpp
  clang/test/OpenMP/target_enter_data_depend_codegen.cpp
  clang/test/OpenMP/target_exit_data_codegen.cpp
  clang/test/OpenMP/target_exit_data_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_codegen.cpp
  clang/test/OpenMP/target_parallel_for_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_depend_codegen.cpp
  clang/test/OpenMP/target_simd_depend_codegen.cpp
  clang/test/OpenMP/target_teams_codegen.cpp
  clang/test/OpenMP/target_teams_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_simd_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
  clang/test/OpenMP/target_update_codegen.cpp
  clang/test/OpenMP/target_update_depend_codegen.cpp
  clang/test/OpenMP/task_codegen.cpp
  clang/test/OpenMP/task_firstprivate_codegen.cpp
  clang/test/OpenMP/task_in_reduction_codegen.cpp
  clang/test/OpenMP/task_private_codegen.cpp
  clang/test/OpenMP/taskloop_firstprivate_codegen.cpp
  clang/test/OpenMP/taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/taskloop_private_codegen.cpp
  clang/test/OpenMP/taskloop_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/taskloop_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/taskloop_simd_private_codegen.cpp
  clang/test/OpenMP/taskloop_with_atomic_codegen.cpp

Index: clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
===
--- clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
+++ clang/test/OpenMP/taskloop_with_atomic_codegen.cpp
@@ -27,6 +27,7 @@
 // Check that occupanices var is firstprivatized.
 // CHECK-DAG: atomicrmw add i32* [[FP_OCCUP:%.+]], i32 1 monotonic, align 4
 // CHECK-DAG: [[FP_OCCUP]] = load i32*, i32** [[FP_OCCUP_ADDR:%[^,]+]],
-// CHECK-DAG: call void (i8*, ...) %{{.+}}(i8* %{{.+}}, i32** [[FP_OCCUP_ADDR]])
+// CHECK-DAG: [[FN:%.+]] = bitcast void (i8*, ...)* %{{.*}} to void (i8*,
+// CHECK-DAG: call void [[FN]](i8* %{{.+}}, i32** [[FP_OCCUP_ADDR]])
 
 #endif
Index: clang/test/OpenMP/taskloop_simd_private_codegen.cpp
===
--- clang/test/OpenMP/taskloop_simd_private_codegen.cpp
+++ clang/test/OpenMP/taskloop_simd_private_codegen.cpp
@@ -230,7 +230,8 @@
 // CHECK: [[PRIV_SIVAR_ADDR:%.+]] = alloca i32*,
 // CHECK: store void (i8*, ...)* bitcast (void ([[PRIVATES_MAIN_TY]]*, [[S_DOUBLE_TY]]**, i32**, [2 x [[S_DOUBLE_TY]]]**, [2 x i32]**, i32**)* [[PRIVATES_MAP_FN]] to void (i8*, ...)*), void (i8*, ...)** [[MAP_FN_ADDR:%.+]],
 // CHECK: [[MAP_FN:%.+]] = load void (i8*, ...)*, void (i8*, ...)** [[MAP_FN_ADDR]],
-// CHECK: call void (i8*, ...) [[MAP_FN]](i8* %{{.+}}, [[S_DOUBLE_TY]]** [[PRIV_VAR_ADDR]], i32** [[PRIV_T_VAR_ADDR]], [2 x [[S_DOUBLE_TY]]]** [[PRIV_S_ARR_ADDR]], [2 x i32]** [[PRIV_VEC_ADDR]], i32** [[PRIV_SIVAR_ADDR]])
+// CHECK: [[FN:%.+]] = bitcast void (i8*, ...)* [[MAP_FN]] to void (i8*,
+// CHECK: call void [[FN]](i8* %{{.+}}, [[S_DOUBLE_TY]]** [[PRIV_VAR_ADDR]], i32** [[PRIV_T

[PATCH] D99320: [RISCV] [1/2] Add intrinsic for Zbb extension

2021-03-29 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: clang/include/clang/Basic/BuiltinsRISCV.def:21
+// Zbb extension
+TARGET_BUILTIN(__builtin_riscv_orc_b, "LiLi", "nc", "experimental-zbb")
+TARGET_BUILTIN(__builtin_riscv32_orc_b, "ZiZi", "nc", "experimental-zbb")

Can we select between the 32 and 64 bit version in the header based on 
__riscv_xlen so we only need 2 builtins, rather than 3?



Comment at: clang/include/clang/Basic/BuiltinsRISCV.def:22
+TARGET_BUILTIN(__builtin_riscv_orc_b, "LiLi", "nc", "experimental-zbb")
+TARGET_BUILTIN(__builtin_riscv32_orc_b, "ZiZi", "nc", "experimental-zbb")
+TARGET_BUILTIN(__builtin_riscv64_orc_b, "WiWi", "nc", "experimental-zbb")

All RISCV builtins should start with "__builtin_riscv_". I don't think we 
should use riscv32/riscv64 here. Especially since the 32-bit version is 
available on RV64. So I think these should be named

__builtin_riscv_orc_b_32 and __builtin_riscv_orc_b_64.



Comment at: clang/include/clang/Basic/BuiltinsRISCV.def:23
+TARGET_BUILTIN(__builtin_riscv32_orc_b, "ZiZi", "nc", "experimental-zbb")
+TARGET_BUILTIN(__builtin_riscv64_orc_b, "WiWi", "nc", "experimental-zbb")
+

Ideally this would be "experimental-zbb,64bit" but I'm not sure that the 
frontend knows about "64bit".



Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:4175
+case Intrinsic::riscv_orc_b: {
+  SDValue LHS =
+  DAG.getNode(ISD::ANY_EXTEND, DL, MVT::i64, N->getOperand(0));

"LHS" stands for "left hand side", but operand 0 is the intrinsic ID which 
should already be i64. Only operand 1 needs to be extended. So just do

```
SDValue NewOp1 = DAG.getNode(ISD::ANY_EXTEND, DL, MVT::i64, N->getOperand(1));
SDValue Res = DAG.getNode(N->getOpcode(), DL, MVT::i64, N->getOperand(0), 
NewOp1);
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99320

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


[PATCH] D98193: [CUDA][HIP] Allow non-ODR use of host var in device

2021-03-29 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D98193#2656326 , @tra wrote:

> I think we also may want to check that we allow `sizeof(host_var)` in the GPU 
> code.

We have tests for that at line 94 of test/SemaCUDA/device-use-host-var.cu


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

https://reviews.llvm.org/D98193

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


  1   2   >