[PATCH] D101968: Fix bad mangling of for a closure in the initializer of a variable at global namespace scope.

2021-05-11 Thread John McCall via Phabricator via cfe-commits 
rjmccall accepted this revision.
rjmccall 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/D101968/new/

https://reviews.llvm.org/D101968

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

[PATCH] D102288: [HWASan] Add -fsanitize=lam flag and enable HWASan to use it.

2021-05-11 Thread Vitaly Buka via Phabricator via cfe-commits 
vitalybuka added inline comments.



Comment at: clang/include/clang/Basic/Sanitizers.def:55-59
+// Utilize Intel LAM in sanitizers.  Currently only used in combination with
+// -fsanitize=hwaddress.  This is an experimental flag which may be removed in
+// the future.
+// TODO: Use -mlam instead, if/when it is supported by clang.
+SANITIZER("lam", LAM)

if it's experimental, why not just "-fsanitize=hwaddress -mllvm -havasan-lam=1" 
?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102288

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

[PATCH] D102213: [ASTMatchers] Add forCallable(), a generalization of forFunction().

2021-05-11 Thread Artem Dergachev via Phabricator via cfe-commits 
NoQ added a comment.

In D102213#2750050 , @steveire wrote:

> I'm not certain what strong opinions I've voiced on the mailing list about 
> that. Was it just that I think `hasDescendant` can lead to unexpected matches 
> and a more-specific matcher should always be used when available (such as 
> `hasArgument`)?

Yeah probably :D So, anyway, you sound like the right person to ask: do you 
have any immediate thoughts on a variant of `hasDescendant` that doesn't lead 
to unexpected matches because it stops exploring insides of nested 
declarations? Would that be useful in your endeavors?

> I do think `has`, `hasDescendant`, `hasAncestor` etc have their uses and they 
> get more useful with utilities like `forFunction`.
>
> I don't know anything about objc. Is it possible to have callable decls 
> nested within each other, like in c++? Is it common? `forFunction` is mostly 
> useful for the very common case of lambdas within functions.

ObjC class/interface declarations or method implementations cannot be nested 
into functions. Blocks, however, are like lambdas, they can appear anywhere (in 
fact, blocks and lambdas are implicitly convertible into each other). 
Additionally, in Objective-C++ you can have lambdas nested anywhere including 
methods or blocks and you can still have nested C++ classes everywhere.

> Does it make sense to add an overload for `LambdaExpr` so that you can write 
> `forCallable(lambdaExpr())`?

Dunno, maybe but I've never encountered such use-cases. If at all, the same 
problem applies to `forFunction()` as well.

> Is there a missing test for `forFunction(functionDecl())`?

Uhm yeah, I should add them. There's some code duplication so it's worth it to 
at least duplicate the tests.




Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:7597
+///   but does not match 'int y = 2'.
+AST_MATCHER_P(Stmt, forCallable, internal::Matcher, InnerMatcher) {
+  const auto &Parents = Finder->getASTContext().getParents(Node);

aaron.ballman wrote:
> You should also update Registry.cpp to expose this via the dynamic matchers.
Uh-oh, i knew i was forgetting something!

Do we have a checklist? (Do we want to?)


Repository:
  rC Clang

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

https://reviews.llvm.org/D102213

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

[PATCH] D102303: [ASTMatchers] Fix formatting around forFunction().

2021-05-11 Thread Artem Dergachev via Phabricator via cfe-commits 
NoQ created this revision.
NoQ added reviewers: alexfh, gribozavr2, aaron.ballman, xazax.hun, vsavchenko.
Herald added subscribers: martong, rnkovacs.
NoQ requested review of this revision.

Isolated from D102213 . No functional change 
intended.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D102303

Files:
  clang/docs/LibASTMatchersReference.html
  clang/include/clang/ASTMatchers/ASTMatchers.h


Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -7543,7 +7543,7 @@
   });
 }
 
-/// Matches declaration of the function the statement belongs to
+/// Matches declaration of the function the statement belongs to.
 ///
 /// Given:
 /// \code
@@ -7560,20 +7560,20 @@
   const auto &Parents = Finder->getASTContext().getParents(Node);
 
   llvm::SmallVector Stack(Parents.begin(), Parents.end());
-  while(!Stack.empty()) {
+  while (!Stack.empty()) {
 const auto &CurNode = Stack.back();
 Stack.pop_back();
-if(const auto *FuncDeclNode = CurNode.get()) {
-  if(InnerMatcher.matches(*FuncDeclNode, Finder, Builder)) {
+if (const auto *FuncDeclNode = CurNode.get()) {
+  if (InnerMatcher.matches(*FuncDeclNode, Finder, Builder)) {
 return true;
   }
-} else if(const auto *LambdaExprNode = CurNode.get()) {
-  if(InnerMatcher.matches(*LambdaExprNode->getCallOperator(),
-  Finder, Builder)) {
+} else if (const auto *LambdaExprNode = CurNode.get()) {
+  if (InnerMatcher.matches(*LambdaExprNode->getCallOperator(), Finder,
+   Builder)) {
 return true;
   }
 } else {
-  for(const auto &Parent: Finder->getASTContext().getParents(CurNode))
+  for (const auto &Parent : Finder->getASTContext().getParents(CurNode))
 Stack.push_back(Parent);
 }
   }
Index: clang/docs/LibASTMatchersReference.html
===
--- clang/docs/LibASTMatchersReference.html
+++ clang/docs/LibASTMatchersReference.html
@@ -8814,7 +8814,7 @@
 
 
 MatcherStmt>forFunctionMatcherFunctionDecl>
 InnerMatcher
-Matches declaration of 
the function the statement belongs to
+Matches declaration of 
the function the statement belongs to.
 
 Given:
 F& operator=(const F& o) {


Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -7543,7 +7543,7 @@
   });
 }
 
-/// Matches declaration of the function the statement belongs to
+/// Matches declaration of the function the statement belongs to.
 ///
 /// Given:
 /// \code
@@ -7560,20 +7560,20 @@
   const auto &Parents = Finder->getASTContext().getParents(Node);
 
   llvm::SmallVector Stack(Parents.begin(), Parents.end());
-  while(!Stack.empty()) {
+  while (!Stack.empty()) {
 const auto &CurNode = Stack.back();
 Stack.pop_back();
-if(const auto *FuncDeclNode = CurNode.get()) {
-  if(InnerMatcher.matches(*FuncDeclNode, Finder, Builder)) {
+if (const auto *FuncDeclNode = CurNode.get()) {
+  if (InnerMatcher.matches(*FuncDeclNode, Finder, Builder)) {
 return true;
   }
-} else if(const auto *LambdaExprNode = CurNode.get()) {
-  if(InnerMatcher.matches(*LambdaExprNode->getCallOperator(),
-  Finder, Builder)) {
+} else if (const auto *LambdaExprNode = CurNode.get()) {
+  if (InnerMatcher.matches(*LambdaExprNode->getCallOperator(), Finder,
+   Builder)) {
 return true;
   }
 } else {
-  for(const auto &Parent: Finder->getASTContext().getParents(CurNode))
+  for (const auto &Parent : Finder->getASTContext().getParents(CurNode))
 Stack.push_back(Parent);
 }
   }
Index: clang/docs/LibASTMatchersReference.html
===
--- clang/docs/LibASTMatchersReference.html
+++ clang/docs/LibASTMatchersReference.html
@@ -8814,7 +8814,7 @@
 
 
 MatcherStmt>forFunctionMatcherFunctionDecl> InnerMatcher
-Matches declaration of the function the statement belongs to
+Matches declaration of the function the statement belongs to.
 
 Given:
 F& operator=(const F& o) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102213: [ASTMatchers] Add forCallable(), a generalization of forFunction().

2021-05-11 Thread Artem Dergachev via Phabricator via cfe-commits 
NoQ updated this revision to Diff 344646.
NoQ added a comment.

Address comments. Yay, diff is no longer confused!


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

https://reviews.llvm.org/D102213

Files:
  clang/docs/LibASTMatchersReference.html
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/lib/ASTMatchers/Dynamic/Registry.cpp
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -5524,6 +5524,83 @@
   EXPECT_TRUE(notMatches(CppString2, returnStmt(forFunction(hasName("F");
 }
 
+TEST(StatementMatcher, ForCallable) {
+  // These tests are copied over from the forFunction() test above.
+  StringRef CppString1 = "struct PosVec {"
+ "  PosVec& operator=(const PosVec&) {"
+ "auto x = [] { return 1; };"
+ "return *this;"
+ "  }"
+ "};";
+  StringRef CppString2 = "void F() {"
+ "  struct S {"
+ "void F2() {"
+ "   return;"
+ "}"
+ "  };"
+ "}";
+
+  EXPECT_TRUE(
+matches(
+  CppString1,
+  returnStmt(forCallable(functionDecl(hasName("operator="))),
+ has(unaryOperator(hasOperatorName("*"));
+  EXPECT_TRUE(
+notMatches(
+  CppString1,
+  returnStmt(forCallable(functionDecl(hasName("operator="))),
+ has(integerLiteral();
+  EXPECT_TRUE(
+matches(
+  CppString1,
+  returnStmt(forCallable(functionDecl(hasName("operator()"))),
+ has(integerLiteral();
+  EXPECT_TRUE(matches(CppString2,
+  returnStmt(forCallable(functionDecl(hasName("F2"));
+  EXPECT_TRUE(notMatches(CppString2,
+ returnStmt(forCallable(functionDecl(hasName("F"));
+
+  // These tests are specific to forCallable().
+  StringRef ObjCString1 = "@interface I"
+  "-(void) foo;"
+  "@end"
+  "@implementation I"
+  "-(void) foo {"
+  "  void (^block)() = ^{ 0x2b | ~0x2b; };"
+  "}"
+  "@end";
+
+  EXPECT_TRUE(
+matchesObjC(
+  ObjCString1,
+  binaryOperator(forCallable(blockDecl();
+
+  EXPECT_TRUE(
+notMatchesObjC(
+  ObjCString1,
+  binaryOperator(forCallable(objcMethodDecl();
+
+  StringRef ObjCString2 = "@interface I"
+  "-(void) foo;"
+  "@end"
+  "@implementation I"
+  "-(void) foo {"
+  "  0x2b | ~0x2b;"
+  "  void (^block)() = ^{};"
+  "}"
+  "@end";
+
+  EXPECT_TRUE(
+matchesObjC(
+  ObjCString2,
+  binaryOperator(forCallable(objcMethodDecl();
+
+  EXPECT_TRUE(
+notMatchesObjC(
+  ObjCString2,
+  binaryOperator(forCallable(blockDecl();
+}
+
 TEST(Matcher, ForEachOverriden) {
   const auto ForEachOverriddenInClass = [](const char *ClassName) {
 return cxxMethodDecl(ofClass(hasName(ClassName)), isVirtual(),
Index: clang/lib/ASTMatchers/Dynamic/Registry.cpp
===
--- clang/lib/ASTMatchers/Dynamic/Registry.cpp
+++ clang/lib/ASTMatchers/Dynamic/Registry.cpp
@@ -236,6 +236,7 @@
   REGISTER_MATCHER(fieldDecl);
   REGISTER_MATCHER(fixedPointLiteral);
   REGISTER_MATCHER(floatLiteral);
+  REGISTER_MATCHER(forCallable);
   REGISTER_MATCHER(forDecomposition);
   REGISTER_MATCHER(forEach);
   REGISTER_MATCHER(forEachArgumentWithParam);
Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -7580,6 +7580,52 @@
   return false;
 }
 
+/// Matches declaration of the function, method, or block the statement
+/// belongs to. Similar to 'forFunction' but additionally covers Objective-C
+/// methods and blocks.
+///
+/// Given:
+/// \code
+/// -(void) foo {
+///   int x = 1;
+///   dispatch_sync(queue, ^{ int y = 2; });
+/// }
+/// \endcode
+/// declStmt(forCallable(objcMethodDecl()))
+///   matches 'int x = 1'
+///   but does not match 'int y = 2'.
+AST_MATCHER_P(Stmt, forCallable, internal::Matcher, InnerMatcher) {
+  const auto &Parents = Finder->getASTContext().getParents(Node);
+
+  llvm::SmallVector Stack(Parents.begin(), Parents.end());
+  while(!Stack.empty()) {
+const auto &CurNode = Stack.back();

[PATCH] D102306: Add gfx1034

2021-05-11 Thread Aakanksha Patil via Phabricator via cfe-commits 
aakanksha555 created this revision.
aakanksha555 added reviewers: msearles, kzhuravl, rampitec.
Herald added subscribers: dexonsmith, kerbowa, rupprecht, hiraditya, nhaehnle, 
jvesely, arsenm, jholewinski.
Herald added a reviewer: jhenderson.
aakanksha555 requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, MaskRay.
Herald added projects: clang, LLVM.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102306

Files:
  clang/include/clang/Basic/Cuda.h
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/test/CodeGenOpenCL/amdgpu-features.cl
  clang/test/Driver/amdgpu-macros.cl
  clang/test/Driver/amdgpu-mcpu.cl
  clang/test/Misc/target-invalid-cpu-note.c
  llvm/docs/AMDGPUUsage.rst
  llvm/include/llvm/BinaryFormat/ELF.h
  llvm/include/llvm/Support/TargetParser.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/ObjectYAML/ELFYAML.cpp
  llvm/lib/Support/TargetParser.cpp
  llvm/lib/Target/AMDGPU/GCNProcessors.td
  llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp
  llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
  llvm/test/MC/AMDGPU/gfx1011_dlops.s
  llvm/test/MC/AMDGPU/gfx1030_err.s
  llvm/test/MC/AMDGPU/gfx1030_new.s
  llvm/test/MC/Disassembler/AMDGPU/gfx1011_dasm_dlops.txt
  llvm/test/MC/Disassembler/AMDGPU/gfx1030_dasm_new.txt
  llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
  llvm/tools/llvm-readobj/ELFDumper.cpp

Index: llvm/tools/llvm-readobj/ELFDumper.cpp
===
--- llvm/tools/llvm-readobj/ELFDumper.cpp
+++ llvm/tools/llvm-readobj/ELFDumper.cpp
@@ -1478,6 +1478,7 @@
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1031),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1032),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1033),
+  LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1034),  
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_V3),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_SRAMECC_V3)
 };
@@ -1529,6 +1530,7 @@
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1031),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1032),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1033),
+  LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1034),  
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_ANY_V4),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_OFF_V4),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_FEATURE_XNACK_ON_V4),
Index: llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
===
--- llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
+++ llvm/test/Object/AMDGPU/elf-header-flags-mach.yaml
@@ -331,6 +331,9 @@
 # ELF-AMDGCN-GFX1033:   EF_AMDGPU_MACH_AMDGCN_GFX1033 (0x39)
 # YAML-AMDGCN-GFX1033:  Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX1033 ]
 
+# ELF-AMDGCN-GFX1034:   EF_AMDGPU_MACH_AMDGCN_GFX1034 (0x3E)
+# YAML-AMDGCN-GFX1034:  Flags: [ EF_AMDGPU_MACH_AMDGCN_GFX1034 ]
+
 # ELF-AMDGCN-ALL:   ]
 
 
Index: llvm/test/MC/Disassembler/AMDGPU/gfx1030_dasm_new.txt
===
--- llvm/test/MC/Disassembler/AMDGPU/gfx1030_dasm_new.txt
+++ llvm/test/MC/Disassembler/AMDGPU/gfx1030_dasm_new.txt
@@ -2,6 +2,7 @@
 # RUN: llvm-mc -arch=amdgcn -mcpu=gfx1031 -disassemble -show-encoding < %s | FileCheck -check-prefix=GFX10 %s
 # RUN: llvm-mc -arch=amdgcn -mcpu=gfx1032 -disassemble -show-encoding < %s | FileCheck -check-prefix=GFX10 %s
 # RUN: llvm-mc -arch=amdgcn -mcpu=gfx1033 -disassemble -show-encoding < %s | FileCheck -check-prefix=GFX10 %s
+# RUN: llvm-mc -arch=amdgcn -mcpu=gfx1034 -disassemble -show-encoding < %s | FileCheck -check-prefix=GFX10 %s
 
 # GFX10: global_load_dword_addtid v1, s[2:3] offset:16
 0x10,0x80,0x58,0xdc,0x00,0x00,0x02,0x01
Index: llvm/test/MC/Disassembler/AMDGPU/gfx1011_dasm_dlops.txt
===
--- llvm/test/MC/Disassembler/AMDGPU/gfx1011_dasm_dlops.txt
+++ llvm/test/MC/Disassembler/AMDGPU/gfx1011_dasm_dlops.txt
@@ -4,6 +4,7 @@
 # RUN: llvm-mc -arch=amdgcn -mcpu=gfx1031 -disassemble -show-encoding < %s | FileCheck -check-prefix=GFX10 %s
 # RUN: llvm-mc -arch=amdgcn -mcpu=gfx1032 -disassemble -show-encoding < %s | FileCheck -check-prefix=GFX10 %s
 # RUN: llvm-mc -arch=amdgcn -mcpu=gfx1033 -disassemble -show-encoding < %s | FileCheck -check-prefix=GFX10 %s
+# RUN: llvm-mc -arch=amdgcn -mcpu=gfx1034 -disassemble -show-encoding < %s | FileCheck -check-prefix=GFX10 %s
 
 # GFX10: v_dot2_f32_f16 v0, v1, v2, v3   ; encoding: [0x00,0x40,0x13,0xcc,0x01,0x05,0x0e,0x1c]
 0x00,0x40,0x13,0xcc,0x01,0x05,0x0e,0x1c
Index: llvm/test/MC/AMDGPU/gfx1030_new.s
===
--- llvm/test/MC/AMDGPU/gfx1030_new.s
+++ llvm/test/MC/AMDGPU/gfx1030_new.s
@@ -2,6 +2,7 @@
 // RUN: llvm-mc -arch=amdgcn -mcpu=gfx1031 -show-encoding %s | FileChe

[PATCH] D89177: [cmake] Add support for multiple distributions

2021-05-11 Thread Shoaib Meenai via Phabricator via cfe-commits 
smeenai updated this revision to Diff 344666.
smeenai added a comment.

Add release notes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89177

Files:
  clang/cmake/caches/MultiDistributionExample.cmake
  clang/cmake/modules/AddClang.cmake
  clang/cmake/modules/CMakeLists.txt
  clang/cmake/modules/ClangConfig.cmake.in
  flang/cmake/modules/AddFlang.cmake
  flang/cmake/modules/CMakeLists.txt
  flang/cmake/modules/FlangConfig.cmake.in
  lld/cmake/modules/AddLLD.cmake
  lld/cmake/modules/CMakeLists.txt
  lld/cmake/modules/LLDConfig.cmake.in
  llvm/cmake/modules/AddLLVM.cmake
  llvm/cmake/modules/CMakeLists.txt
  llvm/cmake/modules/LLVMConfig.cmake.in
  llvm/cmake/modules/LLVMDistributionSupport.cmake
  llvm/docs/BuildingADistribution.rst
  llvm/docs/ReleaseNotes.rst
  mlir/cmake/modules/AddMLIR.cmake
  mlir/cmake/modules/CMakeLists.txt
  mlir/cmake/modules/MLIRConfig.cmake.in

Index: mlir/cmake/modules/MLIRConfig.cmake.in
===
--- mlir/cmake/modules/MLIRConfig.cmake.in
+++ mlir/cmake/modules/MLIRConfig.cmake.in
@@ -20,7 +20,7 @@
 set_property(GLOBAL PROPERTY MLIR_TRANSLATION_LIBS "@MLIR_TRANSLATION_LIBS@")
 
 # Provide all our library targets to users.
-include("@MLIR_CONFIG_EXPORTS_FILE@")
+@MLIR_CONFIG_INCLUDE_EXPORTS@
 
 # By creating these targets here, subprojects that depend on MLIR's
 # tablegen-generated headers can always depend on these targets whether building
Index: mlir/cmake/modules/CMakeLists.txt
===
--- mlir/cmake/modules/CMakeLists.txt
+++ mlir/cmake/modules/CMakeLists.txt
@@ -1,3 +1,5 @@
+include(LLVMDistributionSupport)
+
 # Generate a list of CMake library targets so that other CMake projects can
 # link against them. LLVM calls its version of this file LLVMExports.cmake, but
 # the usual CMake convention seems to be ${Project}Targets.cmake.
@@ -19,7 +21,7 @@
 # Generate MlirConfig.cmake for the build tree.
 set(MLIR_CONFIG_CMAKE_DIR "${mlir_cmake_builddir}")
 set(MLIR_CONFIG_LLVM_CMAKE_DIR "${llvm_cmake_builddir}")
-set(MLIR_CONFIG_EXPORTS_FILE "\${MLIR_CMAKE_DIR}/MLIRTargets.cmake")
+set(MLIR_CONFIG_INCLUDE_EXPORTS "include(\"\${MLIR_CMAKE_DIR}/MLIRTargets.cmake\")")
 set(MLIR_CONFIG_INCLUDE_DIRS
   "${MLIR_SOURCE_DIR}/include"
   "${MLIR_BINARY_DIR}/include"
@@ -30,7 +32,6 @@
   @ONLY)
 set(MLIR_CONFIG_CMAKE_DIR)
 set(MLIR_CONFIG_LLVM_CMAKE_DIR)
-set(MLIR_CONFIG_EXPORTS_FILE)
 set(MLIR_CONFIG_INCLUDE_DIRS)
 
 # For compatibility with projects that include(MLIRConfig)
@@ -55,7 +56,7 @@
 endforeach(p)
 set(MLIR_CONFIG_CMAKE_DIR "\${MLIR_INSTALL_PREFIX}/${MLIR_INSTALL_PACKAGE_DIR}")
 set(MLIR_CONFIG_LLVM_CMAKE_DIR "\${MLIR_INSTALL_PREFIX}/${LLVM_INSTALL_PACKAGE_DIR}")
-set(MLIR_CONFIG_EXPORTS_FILE "\${MLIR_CMAKE_DIR}/MLIRTargets.cmake")
+get_config_exports_includes(MLIR MLIR_CONFIG_INCLUDE_EXPORTS)
 set(MLIR_CONFIG_INCLUDE_DIRS
   "\${MLIR_INSTALL_PREFIX}/include"
   )
@@ -66,17 +67,12 @@
 set(MLIR_CONFIG_CODE)
 set(MLIR_CONFIG_CMAKE_DIR)
 set(MLIR_CONFIG_LLVM_CMAKE_DIR)
-set(MLIR_CONFIG_EXPORTS_FILE)
 set(MLIR_CONFIG_INCLUDE_DIRS)
 
 if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
   # Not TOOLCHAIN ONLY, so install the MLIR parts as well
   # Include the cmake files so other tools can use mlir-tblgen, etc.
-  get_property(mlir_has_exports GLOBAL PROPERTY MLIR_HAS_EXPORTS)
-  if(mlir_has_exports)
-install(EXPORT MLIRTargets DESTINATION ${MLIR_INSTALL_PACKAGE_DIR}
-COMPONENT mlir-cmake-exports)
-  endif()
+  install_distribution_exports(MLIR)
 
   install(FILES
 ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/MLIRConfig.cmake
Index: mlir/cmake/modules/AddMLIR.cmake
===
--- mlir/cmake/modules/AddMLIR.cmake
+++ mlir/cmake/modules/AddMLIR.cmake
@@ -1,3 +1,5 @@
+include(LLVMDistributionSupport)
+
 function(mlir_tablegen ofn)
   tablegen(MLIR ${ARGV})
   set(TABLEGEN_OUTPUT ${TABLEGEN_OUTPUT} ${CMAKE_CURRENT_BINARY_DIR}/${ofn}
@@ -141,14 +143,7 @@
 # where non-standard library builds can be installed.
 function(add_mlir_library_install name)
   if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
-  set(export_to_mlirtargets)
-  if (${name} IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
-  "mlir-libraries" IN_LIST LLVM_DISTRIBUTION_COMPONENTS OR
-  NOT LLVM_DISTRIBUTION_COMPONENTS)
-  set(export_to_mlirtargets EXPORT MLIRTargets)
-set_property(GLOBAL PROPERTY MLIR_HAS_EXPORTS True)
-  endif()
-
+  get_target_export_arg(${name} MLIR export_to_mlirtargets UMBRELLA mlir-libraries)
   install(TARGETS ${name}
 COMPONENT ${name}
 ${export_to_mlirtargets}
Index: llvm/docs/ReleaseNotes.rst
===
--- llvm/docs/ReleaseNotes.rst
+++ llvm/docs/ReleaseNotes.rst
@@ -64,6 +64,10 @@
 Changes to building LLVM
 
 
+* The build system now supports building

[PATCH] D102288: [HWASan] Add -fsanitize=lam flag and enable HWASan to use it.

2021-05-11 Thread Xiang Zhang via Phabricator via cfe-commits 
xiangzhangllvm added inline comments.



Comment at: compiler-rt/test/hwasan/TestCases/Linux/vfork.c:7
-// Aliasing mode does not support stack tagging.
-// XFAIL: x86_64
 

What does here XFAIL mean, do not test in x86_64 ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102288

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

[clang] febbe4b - [PowerPC] [Clang] Enable float128 feature on VSX targets

2021-05-11 Thread Qiu Chaofan via cfe-commits 

Author: Qiu Chaofan
Date: 2021-05-12T14:33:41+08:00
New Revision: febbe4b5a0ab0cb6f8ada6cd1ead4bb1f565bda8

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

LOG: [PowerPC] [Clang] Enable float128 feature on VSX targets

Reviewed By: nemanjai, steven.zhang

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

Added: 


Modified: 
clang/lib/Basic/Targets/PPC.cpp
clang/test/Driver/ppc-f128-support-check.c

Removed: 




diff  --git a/clang/lib/Basic/Targets/PPC.cpp b/clang/lib/Basic/Targets/PPC.cpp
index cd8cc1aed39ea..21a196ab01435 100644
--- a/clang/lib/Basic/Targets/PPC.cpp
+++ b/clang/lib/Basic/Targets/PPC.cpp
@@ -328,6 +328,12 @@ bool PPCTargetInfo::initFeatureMap(
 .Case("pwr9", true)
 .Case("pwr8", true)
 .Default(false);
+  Features["float128"] = llvm::StringSwitch(CPU)
+ .Case("ppc64le", true)
+ .Case("pwr9", true)
+ .Case("pwr8", true)
+ .Case("pwr7", true)
+ .Default(false);
 
   // ROP Protect is off by default.
   Features["rop-protect"] = false;
@@ -356,9 +362,9 @@ bool PPCTargetInfo::initFeatureMap(
   if (!ppcUserFeaturesCheck(Diags, FeaturesVec))
 return false;
 
-  if (!(ArchDefs & ArchDefinePwr9) && (ArchDefs & ArchDefinePpcgr) &&
+  if (!(ArchDefs & ArchDefinePwr7) && (ArchDefs & ArchDefinePpcgr) &&
   llvm::find(FeaturesVec, "+float128") != FeaturesVec.end()) {
-// We have __float128 on PPC but not power 9 and above.
+// We have __float128 on PPC but not pre-VSX targets.
 Diags.Report(diag::err_opt_not_valid_with_opt) << "-mfloat128" << CPU;
 return false;
   }

diff  --git a/clang/test/Driver/ppc-f128-support-check.c 
b/clang/test/Driver/ppc-f128-support-check.c
index 24748905612ff..616d641f54b96 100644
--- a/clang/test/Driver/ppc-f128-support-check.c
+++ b/clang/test/Driver/ppc-f128-support-check.c
@@ -2,13 +2,17 @@
 // RUN:   -mcpu=pwr9 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
 // RUN:   -mcpu=power9 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
-
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
-// RUN:   -mcpu=pwr8 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
+// RUN:   -mcpu=pwr8 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
+// RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
+// RUN:   -mcpu=pwr7 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
+// RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
+// RUN:   -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
+
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
-// RUN:   -mcpu=pwr7 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
+// RUN:   -mcpu=pwr6 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
-// RUN:   -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
+// RUN:   -mno-vsx -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
 
 #ifdef __FLOAT128__
 static_assert(false, "__float128 enabled");



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

[PATCH] D92815: [PowerPC] [Clang] Enable float128 feature on VSX targets

2021-05-11 Thread Qiu Chaofan via Phabricator via cfe-commits 
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGfebbe4b5a0ab: [PowerPC] [Clang] Enable float128 feature on 
VSX targets (authored by qiucf).

Changed prior to commit:
  https://reviews.llvm.org/D92815?vs=327388&id=344673#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92815

Files:
  clang/lib/Basic/Targets/PPC.cpp
  clang/test/Driver/ppc-f128-support-check.c


Index: clang/test/Driver/ppc-f128-support-check.c
===
--- clang/test/Driver/ppc-f128-support-check.c
+++ clang/test/Driver/ppc-f128-support-check.c
@@ -2,13 +2,17 @@
 // RUN:   -mcpu=pwr9 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
 // RUN:   -mcpu=power9 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
-
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
-// RUN:   -mcpu=pwr8 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
+// RUN:   -mcpu=pwr8 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
+// RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
+// RUN:   -mcpu=pwr7 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
+// RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
+// RUN:   -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
+
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
-// RUN:   -mcpu=pwr7 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
+// RUN:   -mcpu=pwr6 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
-// RUN:   -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
+// RUN:   -mno-vsx -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
 
 #ifdef __FLOAT128__
 static_assert(false, "__float128 enabled");
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -328,6 +328,12 @@
 .Case("pwr9", true)
 .Case("pwr8", true)
 .Default(false);
+  Features["float128"] = llvm::StringSwitch(CPU)
+ .Case("ppc64le", true)
+ .Case("pwr9", true)
+ .Case("pwr8", true)
+ .Case("pwr7", true)
+ .Default(false);
 
   // ROP Protect is off by default.
   Features["rop-protect"] = false;
@@ -356,9 +362,9 @@
   if (!ppcUserFeaturesCheck(Diags, FeaturesVec))
 return false;
 
-  if (!(ArchDefs & ArchDefinePwr9) && (ArchDefs & ArchDefinePpcgr) &&
+  if (!(ArchDefs & ArchDefinePwr7) && (ArchDefs & ArchDefinePpcgr) &&
   llvm::find(FeaturesVec, "+float128") != FeaturesVec.end()) {
-// We have __float128 on PPC but not power 9 and above.
+// We have __float128 on PPC but not pre-VSX targets.
 Diags.Report(diag::err_opt_not_valid_with_opt) << "-mfloat128" << CPU;
 return false;
   }


Index: clang/test/Driver/ppc-f128-support-check.c
===
--- clang/test/Driver/ppc-f128-support-check.c
+++ clang/test/Driver/ppc-f128-support-check.c
@@ -2,13 +2,17 @@
 // RUN:   -mcpu=pwr9 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
 // RUN:   -mcpu=power9 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
-
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
-// RUN:   -mcpu=pwr8 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
+// RUN:   -mcpu=pwr8 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
+// RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
+// RUN:   -mcpu=pwr7 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
+// RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
+// RUN:   -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=HASF128
+
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
-// RUN:   -mcpu=pwr7 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
+// RUN:   -mcpu=pwr6 -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
 // RUN: not %clang -target powerpc64le-unknown-linux-gnu -fsyntax-only \
-// RUN:   -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
+// RUN:   -mno-vsx -mfloat128 %s 2>&1 | FileCheck %s --check-prefix=NOF128
 
 #ifdef __FLOAT128__
 static_assert(false, "__float128 enabled");
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -328,6 +328,12 @

[PATCH] D102313: [docs] Fix documentation for bugprone-dangling-handle

2021-05-11 Thread Malcolm Parsons via Phabricator via cfe-commits 
malcolm.parsons created this revision.
malcolm.parsons added a reviewer: aaron.ballman.
malcolm.parsons requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

string_view isn't experimental anymore.
This check has always handled both forms.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102313

Files:
  clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst


Index: clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst
@@ -3,8 +3,7 @@
 bugprone-dangling-handle
 
 
-Detect dangling references in value handles like
-``std::experimental::string_view``.
+Detect dangling references in value handles like ``std::string_view``.
 These dangling references can be a result of constructing handles from 
temporary
 values, where the temporary is destroyed soon after the handle is created.
 
@@ -35,4 +34,5 @@
 .. option:: HandleClasses
 
A semicolon-separated list of class names that should be treated as handles.
-   By default only ``std::experimental::basic_string_view`` is considered.
+   By default only ``std::basic_string_view`` and
+   ``std::experimental::basic_string_view`` are considered.


Index: clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst
+++ clang-tools-extra/docs/clang-tidy/checks/bugprone-dangling-handle.rst
@@ -3,8 +3,7 @@
 bugprone-dangling-handle
 
 
-Detect dangling references in value handles like
-``std::experimental::string_view``.
+Detect dangling references in value handles like ``std::string_view``.
 These dangling references can be a result of constructing handles from temporary
 values, where the temporary is destroyed soon after the handle is created.
 
@@ -35,4 +34,5 @@
 .. option:: HandleClasses
 
A semicolon-separated list of class names that should be treated as handles.
-   By default only ``std::experimental::basic_string_view`` is considered.
+   By default only ``std::basic_string_view`` and
+   ``std::experimental::basic_string_view`` are considered.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D89177: [cmake] Add support for multiple distributions

2021-05-11 Thread Shoaib Meenai via Phabricator via cfe-commits 
smeenai marked 3 inline comments as done.
smeenai added inline comments.



Comment at: llvm/cmake/modules/LLVMDistributionSupport.cmake:39
+# default (unnamed) distribution.
+set_property(GLOBAL PROPERTY LLVM_DISTRIBUTION_FOR_${target} " ")
+  endforeach()

smeenai wrote:
> phosek wrote:
> > Can we use `EMPTY` or something along those lines to make it more obvious?
> Sure, I'll change it.
Thinking about this more, I prefer `DEFAULT` because it's marking the default 
(unnamed) distribution (and `` is just to make it stand out more and 
be less likely to clash with a user-specified distribution name). I can change 
it if you feel strongly though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89177

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

[PATCH] D102216: JSONLinkDatabase

2021-05-11 Thread Mirzazyanov Gleb via Phabricator via cfe-commits 
Glebuska updated this revision to Diff 344301.
Glebuska edited the summary of this revision.
Glebuska added a comment.

Updating D102216 : JSONLinkDatabase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102216

Files:
  clang/docs/JSONLinkDatabase.rst

Index: clang/docs/JSONLinkDatabase.rst
===
--- /dev/null
+++ clang/docs/JSONLinkDatabase.rst
@@ -0,0 +1,142 @@
+==
+JSON Compilation Database Format Specification
+==
+
+This document describes a format for specifying how to replay single link commands independently of the build system.
+
+Background
+==
+
+Currently, there is `compilation database format `_ , which specified by Clang. Compilation commands are actively used for syntax analysis of code, 
+but there are cases, when the compilation commands cannot provide all the necessary information, for example, look into simple C/C++ code:  
+
+ ::
+
+a.cpp:
+
+int f(int a) {
+return g(a);
+ }
+
+x.cpp:
+
+int g(int a) {
+  return a + 1;
+}
+
+y.cpp:
+
+int g(int a) {
+  return a - 1;
+}
+
+
+A tool may need to know which function is actually called, but this information is only available at linking step as soon as there may be several functions with same name in different units.  
+Using of link database is providing more information for advance software analysis.
+More examples:
+
+1) Unit testing tools which use code analysis need to understand which function is called in order to get correct test result.
+2) IDEs need it to understand which file to go when you click "Go to definition" on a function call.
+
+Format
+
+
+A link database is a JSON file, which consist of an array of “command objects”, where each command object specifies one way a target and first element is a version of format instead of link's command. 
+The contracts for each field in the command object are:
+
+- **command**: The link command executed. The field contains all the flags and files needed to create a target or library. As result of executing all commands, it's a full-build project.
+- **directory** The working directory of the link's command. All paths specified in the command or file fields must be either absolute or relative to this directory.
+- **files** An array which described all the object files, dynamic and static libraries needed for linking.
+- **arguments** The link command executed as list of strings. Either arguments or command is required.
+- **output** The name of the output created by this linking step. This field is optional. It can be used to distinguish different processing modes of the same input.
+
+Using link commands from file can give 3 different types of output:  
+- executable file 
+- static library
+- dynamic library
+
+Example:
+
+ :: 
+
+
+[   
+	{
+	  "command" : "/usr/bin/ar qc libcmstd.a CMakeFiles/cmstd.dir/cm/bits/fs_path.cxx.o CMakeFiles/cmstd.dir/cm/bits/string_view.cxx.o",
+  "directory" : "/home/myuser/exampleProject/build/Utilities/std",
+	  "files" : 
+	  [
+	  "/home/myuser/exampleProject/build/Utilities/std/CMakeFiles/cmstd.dir/cm/bits/fs_path.cxx.o", 
+	  "/home/myuser/exampleProject/build/Utilities/std/CMakeFiles/cmstd.dir/cm/bits/string_view.cxx.o"
+	  ]
+	},
+	{
+	  "command" : "/usr/bin/cc  -Wcast-align -Werror-implicit-function-declaration -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -Wformat-security -Wmissing-format-attribute -fno-common -Wundef CMakeFiles/pseudonl_purify.dir/ret0.c.o -o purify",
+  "directory" : "/home/myuser/exampleProject/build/Tests/CMakeLib/PseudoMemcheck/NoLog",
+	  "files" : 
+	  [
+  "/home/myuser/exampleProject/build/Tests/CMakeLib/PseudoMemcheck/NoLog/CMakeFiles/pseudonl_purify.dir/ret0.c.o"
+	  ]
+	},
+	...
+]
+
+
+
+
+
+
+This example demonstrates command **ar** to create **dynamic library libcmstd.a** and **cc** command to create **purify target**  
+
+In addition to the commands responsible for linking, link database can contain commands specific to the build system:
+Example for CMake build system:
+
+ 1) CMake command for deleting library
+
+ ::
+
+[   
+...
+	{
+	  "command" : "/usr/local/bin/cmake -E rm -f CMakeFiles/library.dir/lib.a",
+  "directory" : "/home/myuser/exampleProject/build/Utilities/std",

[PATCH] D102090: [CMake][ELF] Add -fno-semantic-interposition and -Bsymbolic-functions

2021-05-11 Thread Fangrui Song via Phabricator via cfe-commits 
MaskRay marked an inline comment as done.
MaskRay added a comment.

In D102090#2749473 , @rnk wrote:

> +1 to the idea, but I have no idea if this is the right cmake spot
>
> If we've decided to actually care about the shared library build, should we 
> also consider using `-fvisibility-inlines-hidden`?

Line 329:  `check_cxx_compiler_flag("-fvisibility-inlines-hidden" 
SUPPORTS_FVISIBILITY_INLINES_HIDDEN_FLAG)`.
llvm-project has been using this since 2012. With this flag, taking the address 
of an inline function may be different in different modules.
So -fno-semantic-interposition and -Bsymbolic-functions will now complement the 
existing option:)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102090

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

[PATCH] D101667: Modules: Remove ModuleLoader::OtherUncachedFailure, NFC

2021-05-11 Thread Jan Svoboda via Phabricator via cfe-commits 
jansvoboda11 added a comment.

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101667

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

[PATCH] D101608: [WebAssembly] Support for WebAssembly globals in LLVM IR

2021-05-11 Thread Andy Wingo via Phabricator via cfe-commits 
wingo updated this revision to Diff 344320.
wingo added a comment.

Rename "managed" address space to "wasm vars"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

Files:
  clang/lib/Basic/Targets/WebAssembly.h
  clang/test/CodeGen/target-data.c
  llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h
  llvm/lib/Target/WebAssembly/WebAssemblyFastISel.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyISD.def
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.h
  llvm/lib/Target/WebAssembly/WebAssemblyInstrInfo.td
  llvm/lib/Target/WebAssembly/WebAssemblyInstrRef.td
  llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
  llvm/test/CodeGen/WebAssembly/global-get.ll
  llvm/test/CodeGen/WebAssembly/global-set.ll

Index: llvm/test/CodeGen/WebAssembly/global-set.ll
===
--- /dev/null
+++ llvm/test/CodeGen/WebAssembly/global-set.ll
@@ -0,0 +1,57 @@
+; RUN: llc --mtriple=wasm32-unknown-unknown -asm-verbose=false < %s | FileCheck %s
+
+@i32_global = local_unnamed_addr addrspace(1) global i32 undef
+@i64_global = local_unnamed_addr addrspace(1) global i64 undef
+@f32_global = local_unnamed_addr addrspace(1) global float undef
+@f64_global = local_unnamed_addr addrspace(1) global double undef
+
+define void @set_i32_global(i32 %v) {
+; CHECK-LABEL: set_i32_global:
+; CHECK-NEXT: functype   set_i32_global (i32) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set i32_global
+; CHECK-NEXT: end_function
+  store i32 %v, i32 addrspace(1)* @i32_global
+  ret void
+}
+
+define void @set_i64_global(i64 %v) {
+; CHECK-LABEL: set_i64_global:
+; CHECK-NEXT: functype   set_i64_global (i64) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set i64_global
+; CHECK-NEXT: end_function
+  store i64 %v, i64 addrspace(1)* @i64_global
+  ret void
+}
+
+define void @set_f32_global(float %v) {
+; CHECK-LABEL: set_f32_global:
+; CHECK-NEXT: functype   set_f32_global (f32) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set f32_global
+; CHECK-NEXT: end_function
+  store float %v, float addrspace(1)* @f32_global
+  ret void
+}
+
+define void @set_f64_global(double %v) {
+; CHECK-LABEL: set_f64_global:
+; CHECK-NEXT: functype   set_f64_global (f64) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set f64_global
+; CHECK-NEXT: end_function
+  store double %v, double addrspace(1)* @f64_global
+  ret void
+}
+
+;; LLVM doesn't yet declare proper WebAssembly globals for these values,
+;; instead placing them in linear memory.  To fix in a followup.
+; FIXME-CHECK: .globl i32_global
+; FIXME-CHECK: .globaltype i32_global, i32
+; FIXME-CHECK: .globl i64_global
+; FIXME-CHECK: .globaltype i64_global, i64
+; FIXME-CHECK: .globl f32_global
+; FIXME-CHECK: .globaltype f32_global, f32
+; FIXME-CHECK: .globl f64_global
+; FIXME-CHECK: .globaltype f64_global, f64
Index: llvm/test/CodeGen/WebAssembly/global-get.ll
===
--- /dev/null
+++ llvm/test/CodeGen/WebAssembly/global-get.ll
@@ -0,0 +1,54 @@
+; RUN: llc < %s --mtriple=wasm32-unknown-unknown -asm-verbose=false | FileCheck %s
+
+@i32_global = local_unnamed_addr addrspace(1) global i32 undef
+@i64_global = local_unnamed_addr addrspace(1) global i64 undef
+@f32_global = local_unnamed_addr addrspace(1) global float undef
+@f64_global = local_unnamed_addr addrspace(1) global double undef
+
+define i32 @return_i32_global() {
+; CHECK-LABEL: return_i32_global:
+; CHECK-NEXT: functype   return_i32_global () -> (i32)
+; CHECK-NEXT: global.get i32_global
+; CHECK-NEXT: end_function
+  %v = load i32, i32 addrspace(1)* @i32_global
+  ret i32 %v
+}
+
+define i64 @return_i64_global() {
+; CHECK-LABEL: return_i64_global:
+; CHECK-NEXT: functype   return_i64_global () -> (i64)
+; CHECK-NEXT: global.get i64_global
+; CHECK-NEXT: end_function
+  %v = load i64, i64 addrspace(1)* @i64_global
+  ret i64 %v
+}
+
+define float @return_f32_global() {
+; CHECK-LABEL: return_f32_global:
+; CHECK-NEXT: functype   return_f32_global () -> (f32)
+; CHECK-NEXT: global.get f32_global
+; CHECK-NEXT: end_function
+  %v = load float, float addrspace(1)* @f32_global
+  ret float %v
+}
+
+define double @return_f64_global() {
+; CHECK-LABEL: return_f64_global:
+; CHECK-NEXT: functype   return_f64_global () -> (f64)
+; CHECK-NEXT: global.get f64_global
+; CHECK-NEXT: end_function
+  %v = load double, double addrspace(1)* @f64_global
+  ret double %v
+}
+
+
+;; LLVM doesn't yet declare proper WebAssembly globals for these values,
+;; instead placing them in linear memory.  To fix in a followup.
+; FIXME-CHECK: .globl i32_global
+; FIXME-CHECK: .globaltype i32_global, i32
+; FIXME-CHECK: .globl i64_global
+; FIXME-CHECK: .globaltype i64_global, i64
+; FIXME-CHECK: .globl f32_global
+; FIXME-CHECK: .globaltype f

[PATCH] D101140: [WebAssembly][CodeGen] IR support for WebAssembly local variables

2021-05-11 Thread Andy Wingo via Phabricator via cfe-commits 
wingo updated this revision to Diff 344323.
wingo added a comment.

Update in response to parent commit changes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101140

Files:
  clang/lib/Basic/Targets/WebAssembly.h
  clang/test/CodeGen/target-data.c
  llvm/include/llvm/CodeGen/MIRYamlMapping.h
  llvm/include/llvm/CodeGen/TargetFrameLowering.h
  llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.cpp
  llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h
  llvm/lib/Target/WebAssembly/WebAssemblyExplicitLocals.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyFrameLowering.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyFrameLowering.h
  llvm/lib/Target/WebAssembly/WebAssemblyISD.def
  llvm/lib/Target/WebAssembly/WebAssemblyISelDAGToDAG.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyInstrInfo.td
  llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
  llvm/test/CodeGen/WebAssembly/ir-locals-stackid.ll
  llvm/test/CodeGen/WebAssembly/ir-locals.ll

Index: llvm/test/CodeGen/WebAssembly/ir-locals.ll
===
--- /dev/null
+++ llvm/test/CodeGen/WebAssembly/ir-locals.ll
@@ -0,0 +1,76 @@
+; RUN: llc < %s --mtriple=wasm32-unknown-unknown -asm-verbose=false | FileCheck %s
+
+%i32_cell = type i32 addrspace(1)*
+%i64_cell = type i64 addrspace(1)*
+%f32_cell = type float addrspace(1)*
+%f64_cell = type double addrspace(1)*
+
+define i32 @ir_local_i32(i32 %arg) {
+ ; CHECK-LABEL: ir_local_i32:
+ ; CHECK-NEXT: .functype ir_local_i32 (i32) -> (i32)
+ %retval = alloca i32, addrspace(1)
+ ; CHECK-NEXT: .local i32
+ store i32 %arg, %i32_cell %retval
+ ; CHECK-NEXT: local.get 0
+ ; CHECK-NEXT: local.set 1
+ %reloaded = load i32, %i32_cell %retval
+ ; The DAG combiner infers that %reloaded is the same as %arg and
+ ; ultimately causes "local.get 0" to be emitted instead of
+ ; "local.get 1".
+ ; CHECK-NEXT: local.get 0
+ ret i32 %reloaded
+ ; CHECK-NEXT: end_function
+}
+
+define i64 @ir_local_i64(i64 %arg) {
+ ; CHECK-LABEL: ir_local_i64:
+ ; CHECK-NEXT: .functype ir_local_i64 (i64) -> (i64)
+ %retval = alloca i64, addrspace(1)
+ ; CHECK-NEXT: .local i64
+ store i64 %arg, %i64_cell %retval
+ ; CHECK-NEXT: local.get 0
+ ; CHECK-NEXT: local.set 1
+ %reloaded = load i64, %i64_cell %retval
+ ; See note in ir_local_i32.
+ ; CHECK-NEXT: local.get 0
+ ret i64 %reloaded
+ ; CHECK-NEXT: end_function
+}
+
+define float @ir_local_f32(float %arg) {
+ ; CHECK-LABEL: ir_local_f32:
+ ; CHECK-NEXT: .functype ir_local_f32 (f32) -> (f32)
+ %retval = alloca float, addrspace(1)
+ ; CHECK-NEXT: .local f32
+ ; CHECK-NEXT: local.get 0
+ ; CHECK-NEXT: local.set 1
+ store float %arg, %f32_cell %retval
+ ; See note in ir_local_i32.
+ ; CHECK-NEXT: local.get 0
+ %reloaded = load float, %f32_cell %retval
+ ; CHECK-NEXT: end_function
+ ret float %reloaded
+}
+
+define double @ir_local_f64(double %arg) {
+ ; CHECK-LABEL: ir_local_f64:
+ ; CHECK-NEXT: .functype ir_local_f64 (f64) -> (f64)
+ %retval = alloca double, addrspace(1)
+ ; CHECK-NEXT: .local f64
+ ; CHECK-NEXT: local.get 0
+ ; CHECK-NEXT: local.set 1
+ store double %arg, %f64_cell %retval
+ ; CHECK-NEXT: local.get 0
+ %reloaded = load double, %f64_cell %retval
+ ; CHECK-NEXT: end_function
+ ret double %reloaded
+}
+
+define void @ir_unreferenced_local() {
+ ; CHECK-LABEL: ir_unreferenced_local:
+ ; CHECK-NEXT: .functype ir_unreferenced_local () -> ()
+ %unused = alloca i32, addrspace(1)
+ ; CHECK-NEXT: .local i32
+ ret void
+ ; CHECK-NEXT: end_function
+}
Index: llvm/test/CodeGen/WebAssembly/ir-locals-stackid.ll
===
--- /dev/null
+++ llvm/test/CodeGen/WebAssembly/ir-locals-stackid.ll
@@ -0,0 +1,22 @@
+; RUN: llc -mtriple=wasm32-unknown-unknown -asm-verbose=false < %s | FileCheck %s --check-prefix=CHECKCG
+; RUN: llc -mtriple=wasm32-unknown-unknown -stop-after=finalize-isel < %s | FileCheck %s --check-prefix=CHECKISEL
+
+%f32_cell = type float addrspace(1)*
+
+; CHECKISEL-LABEL: name: ir_local_f32
+; CHECKISEL:   stack:
+; CHECKISEL:   id: 0, name: retval, type: default, offset: 1, size: 1, alignment: 4,
+; CHECKISEL-NEXT:  stack-id: wasm-local
+
+; CHECKCG-LABEL: ir_local_f32:
+; CHECKCG-NEXT: .functype ir_local_f32 (f32) -> (f32)
+; CHECKCG-NEXT: .local f32
+; CHECKCG-NEXT: local.get 0
+; CHECKCG-NEXT: local.set 1
+
+define float @ir_local_f32(float %arg) {
+ %retval = alloca float, addrspace(1)
+ store float %arg, %f32_cell %retval
+ %reloaded = load float, %f32_cell %retval
+ ret float %reloaded
+}
Index: llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
===
--- llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
+++ llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
@@ -120,8 +120,8 @@
 Optional CM, CodeGenOpt::Level OL, bool JIT)
 : L

[clang] 7d20f70 - [OpenCL] [NFC] Fixed underline being too short in rst

2021-05-11 Thread Ole Strohm via cfe-commits 

Author: Ole Strohm
Date: 2021-05-11T09:45:28+01:00
New Revision: 7d20f709ea6da8442a153beda7ecdda07440f046

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

LOG: [OpenCL] [NFC] Fixed underline being too short in rst

Added: 


Modified: 
clang/docs/LanguageExtensions.rst

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index bdb5b3adf39f..235bcac8f00f 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -1814,7 +1814,7 @@ supporting the variadic arguments e.g. majority of CPU 
targets.
   void bar(int a, ...); // error - variadic prototype is not allowed
 
 ``__cl_clang_non_portable_kernel_param_types``
--
+--
 
 With this extension it is possible to enable the use of some restricted types
 in kernel parameters specified in `C++ for OpenCL v1.0 s2.4



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

Re: [clang] e994e74 - [OpenCL] Add clang extension for non-portable kernel parameters.

2021-05-11 Thread Anastasia Stulova via cfe-commits 
Hi Tom,

Thanks for letting me know. It has been fixed by 
https://github.com/llvm/llvm-project/commit/7d20f709ea6da8442a153beda7ecdda07440f046.

And sorry for disruption.

Anastasia

From: Tom Stellard 
Sent: 11 May 2021 06:15
To: Anastasia Stulova ; Anastasia Stulova 
; cfe-commits@lists.llvm.org 
Subject: Re: [clang] e994e74 - [OpenCL] Add clang extension for non-portable 
kernel parameters.

On 5/5/21 6:58 AM, Anastasia Stulova via cfe-commits wrote:
>
> Author: Anastasia Stulova
> Date: 2021-05-05T14:58:23+01:00
> New Revision: e994e74bca49831eb649e7c67955e9de7a1784b6
>
> URL: 
> https://github.com/llvm/llvm-project/commit/e994e74bca49831eb649e7c67955e9de7a1784b6
> DIFF: 
> https://github.com/llvm/llvm-project/commit/e994e74bca49831eb649e7c67955e9de7a1784b6.diff
>
> LOG: [OpenCL] Add clang extension for non-portable kernel parameters.
>
> Added __cl_clang_non_portable_kernel_param_types extension that
> allows using non-portable types as kernel parameters. This allows
> bypassing the portability guarantees from the restrictions specified
> in C++ for OpenCL v1.0 s2.4.
>
> Currently this only disables the restrictions related to the data
> layout. The programmer should ensure the compiler generates the same
> layout for host and device or otherwise the argument should only be
> accessed on the device side. This extension could be extended to other
> case (e.g. permitting size_t) if desired in the future.
>
> Patch by olestrohm (Ole Strohm)!
>

Hi Anastasia,


This change broke the clang-sphinx-docs builder:

https://lab.llvm.org/buildbot/#/builders/92/builds/9110

-Tom

> https://reviews.llvm.org/D101168
>
> Added:
>
>
> Modified:
>  clang/docs/LanguageExtensions.rst
>  clang/include/clang/Basic/OpenCLExtensions.def
>  clang/lib/Basic/Targets/AMDGPU.h
>  clang/lib/Basic/Targets/NVPTX.h
>  clang/lib/Sema/SemaDecl.cpp
>  clang/test/Misc/amdgcn.languageOptsOpenCL.cl
>  clang/test/Misc/nvptx.languageOptsOpenCL.cl
>  clang/test/Misc/r600.languageOptsOpenCL.cl
>  clang/test/SemaOpenCLCXX/invalid-kernel.clcpp
>
> Removed:
>
>
>
> 
> diff  --git a/clang/docs/LanguageExtensions.rst 
> b/clang/docs/LanguageExtensions.rst
> index 5e5382879e0c8..bdb5b3adf39fb 100644
> --- a/clang/docs/LanguageExtensions.rst
> +++ b/clang/docs/LanguageExtensions.rst
> @@ -1813,6 +1813,54 @@ supporting the variadic arguments e.g. majority of CPU 
> targets.
> #pragma OPENCL EXTENSION __cl_clang_variadic_functions : disable
> void bar(int a, ...); // error - variadic prototype is not allowed
>
> +``__cl_clang_non_portable_kernel_param_types``
> +-
> +
> +With this extension it is possible to enable the use of some restricted types
> +in kernel parameters specified in `C++ for OpenCL v1.0 s2.4
> +`_.
> +The restrictions can be relaxed using regular OpenCL extension pragma 
> mechanism
> +detailed in `the OpenCL Extension Specification, section 1.2
> +`_.
> +
> +This is not a conformant behavior and it can only be used when the
> +kernel arguments are not accessed on the host side or the data layout/size
> +between the host and device is known to be compatible.
> +
> +**Example of Use**:
> +
> +.. code-block:: c++
> +
> +  // Plain Old Data type.
> +  struct Pod {
> +int a;
> +int b;
> +  };
> +
> +  // Not POD type because of the constructor.
> +  // Standard layout type because there is only one access control.
> +  struct OnlySL {
> +int a;
> +int b;
> +NotPod() : a(0), b(0) {}
> +  };
> +
> +  // Not standard layout type because of two
> diff erent access controls.
> +  struct NotSL {
> +int a;
> +  private:
> +int b;
> +  }
> +
> +  kernel void kernel_main(
> +Pod a,
> +  #pragma OPENCL EXTENSION __cl_clang_non_portable_kernel_param_types : 
> enable
> +OnlySL b,
> +global NotSL *c,
> +  #pragma OPENCL EXTENSION __cl_clang_non_portable_kernel_param_types : 
> disable
> +global OnlySL *d,
> +  );
> +
>   Legacy 1.x atomics with generic address space
>   -
>
>
> diff  --git a/clang/include/clang/Basic/OpenCLExtensions.def 
> b/clang/include/clang/Basic/OpenCLExtensions.def
> index 5e2977f478f3a..a0f01a2af9c37 100644
> --- a/clang/include/clang/Basic/OpenCLExtensions.def
> +++ b/clang/include/clang/Basic/OpenCLExtensions.def
> @@ -87,6 +87,7 @@ OPENCL_EXTENSION(cl_khr_subgroups, true, 200)
>   OPENCL_EXTENSION(cl_clang_storage_class_specifiers, true, 100)
>   OPENCL_EXTENSION(__cl_clang_function_pointers, true, 100)
>   OPENCL_EXTENSION(__cl_clang_variadic_functions, true, 100)
> +OPENCL_EXTENSION(__cl_clang_non_portable_kernel_param_types, true, 100)
>
>   // AMD OpenCL extensio

[PATCH] D101608: [WebAssembly] Support for WebAssembly globals in LLVM IR

2021-05-11 Thread Andy Wingo 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 rGd7086af2143d: [WebAssembly] Support for WebAssembly globals 
in LLVM IR (authored by pmatos, committed by wingo).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

Files:
  clang/lib/Basic/Targets/WebAssembly.h
  clang/test/CodeGen/target-data.c
  llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h
  llvm/lib/Target/WebAssembly/WebAssemblyFastISel.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyISD.def
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
  llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.h
  llvm/lib/Target/WebAssembly/WebAssemblyInstrInfo.td
  llvm/lib/Target/WebAssembly/WebAssemblyInstrRef.td
  llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp
  llvm/test/CodeGen/WebAssembly/global-get.ll
  llvm/test/CodeGen/WebAssembly/global-set.ll

Index: llvm/test/CodeGen/WebAssembly/global-set.ll
===
--- /dev/null
+++ llvm/test/CodeGen/WebAssembly/global-set.ll
@@ -0,0 +1,57 @@
+; RUN: llc --mtriple=wasm32-unknown-unknown -asm-verbose=false < %s | FileCheck %s
+
+@i32_global = local_unnamed_addr addrspace(1) global i32 undef
+@i64_global = local_unnamed_addr addrspace(1) global i64 undef
+@f32_global = local_unnamed_addr addrspace(1) global float undef
+@f64_global = local_unnamed_addr addrspace(1) global double undef
+
+define void @set_i32_global(i32 %v) {
+; CHECK-LABEL: set_i32_global:
+; CHECK-NEXT: functype   set_i32_global (i32) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set i32_global
+; CHECK-NEXT: end_function
+  store i32 %v, i32 addrspace(1)* @i32_global
+  ret void
+}
+
+define void @set_i64_global(i64 %v) {
+; CHECK-LABEL: set_i64_global:
+; CHECK-NEXT: functype   set_i64_global (i64) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set i64_global
+; CHECK-NEXT: end_function
+  store i64 %v, i64 addrspace(1)* @i64_global
+  ret void
+}
+
+define void @set_f32_global(float %v) {
+; CHECK-LABEL: set_f32_global:
+; CHECK-NEXT: functype   set_f32_global (f32) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set f32_global
+; CHECK-NEXT: end_function
+  store float %v, float addrspace(1)* @f32_global
+  ret void
+}
+
+define void @set_f64_global(double %v) {
+; CHECK-LABEL: set_f64_global:
+; CHECK-NEXT: functype   set_f64_global (f64) -> ()
+; CHECK-NEXT: local.get 0
+; CHECK-NEXT: global.set f64_global
+; CHECK-NEXT: end_function
+  store double %v, double addrspace(1)* @f64_global
+  ret void
+}
+
+;; LLVM doesn't yet declare proper WebAssembly globals for these values,
+;; instead placing them in linear memory.  To fix in a followup.
+; FIXME-CHECK: .globl i32_global
+; FIXME-CHECK: .globaltype i32_global, i32
+; FIXME-CHECK: .globl i64_global
+; FIXME-CHECK: .globaltype i64_global, i64
+; FIXME-CHECK: .globl f32_global
+; FIXME-CHECK: .globaltype f32_global, f32
+; FIXME-CHECK: .globl f64_global
+; FIXME-CHECK: .globaltype f64_global, f64
Index: llvm/test/CodeGen/WebAssembly/global-get.ll
===
--- /dev/null
+++ llvm/test/CodeGen/WebAssembly/global-get.ll
@@ -0,0 +1,54 @@
+; RUN: llc < %s --mtriple=wasm32-unknown-unknown -asm-verbose=false | FileCheck %s
+
+@i32_global = local_unnamed_addr addrspace(1) global i32 undef
+@i64_global = local_unnamed_addr addrspace(1) global i64 undef
+@f32_global = local_unnamed_addr addrspace(1) global float undef
+@f64_global = local_unnamed_addr addrspace(1) global double undef
+
+define i32 @return_i32_global() {
+; CHECK-LABEL: return_i32_global:
+; CHECK-NEXT: functype   return_i32_global () -> (i32)
+; CHECK-NEXT: global.get i32_global
+; CHECK-NEXT: end_function
+  %v = load i32, i32 addrspace(1)* @i32_global
+  ret i32 %v
+}
+
+define i64 @return_i64_global() {
+; CHECK-LABEL: return_i64_global:
+; CHECK-NEXT: functype   return_i64_global () -> (i64)
+; CHECK-NEXT: global.get i64_global
+; CHECK-NEXT: end_function
+  %v = load i64, i64 addrspace(1)* @i64_global
+  ret i64 %v
+}
+
+define float @return_f32_global() {
+; CHECK-LABEL: return_f32_global:
+; CHECK-NEXT: functype   return_f32_global () -> (f32)
+; CHECK-NEXT: global.get f32_global
+; CHECK-NEXT: end_function
+  %v = load float, float addrspace(1)* @f32_global
+  ret float %v
+}
+
+define double @return_f64_global() {
+; CHECK-LABEL: return_f64_global:
+; CHECK-NEXT: functype   return_f64_global () -> (f64)
+; CHECK-NEXT: global.get f64_global
+; CHECK-NEXT: end_function
+  %v = load double, double addrspace(1)* @f64_global
+  ret double %v
+}
+
+
+;; LLVM doesn't yet declare proper WebAssembly globals for these values,
+;; instead placing them in linear memory.  To fix in a followup.
+; FIXME-CHECK: .globl i32_global
+; FIXME-CHECK: .globaltype i32_globa

[clang] d7086af - [WebAssembly] Support for WebAssembly globals in LLVM IR

2021-05-11 Thread Andy Wingo via cfe-commits 

Author: Paulo Matos
Date: 2021-05-11T11:19:29+02:00
New Revision: d7086af2143d58a6535e0837c4d8789c69c6985f

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

LOG: [WebAssembly] Support for WebAssembly globals in LLVM IR

This patch adds support for WebAssembly globals in LLVM IR, representing
them as pointers to global values, in a non-default, non-integral
address space.  Instruction selection legalizes loads and stores to
these pointers to new WebAssemblyISD nodes GLOBAL_GET and GLOBAL_SET.
Once the lowering creates the new nodes, tablegen pattern matches those
and converts them to Wasm global.get/set of the appropriate type.

Based on work by Paulo Matos in https://reviews.llvm.org/D95425.

Reviewed By: pmatos

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

Added: 
llvm/test/CodeGen/WebAssembly/global-get.ll
llvm/test/CodeGen/WebAssembly/global-set.ll

Modified: 
clang/lib/Basic/Targets/WebAssembly.h
clang/test/CodeGen/target-data.c
llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h
llvm/lib/Target/WebAssembly/WebAssemblyFastISel.cpp
llvm/lib/Target/WebAssembly/WebAssemblyISD.def
llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp
llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.h
llvm/lib/Target/WebAssembly/WebAssemblyInstrInfo.td
llvm/lib/Target/WebAssembly/WebAssemblyInstrRef.td
llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp

Removed: 




diff  --git a/clang/lib/Basic/Targets/WebAssembly.h 
b/clang/lib/Basic/Targets/WebAssembly.h
index be5b66a9580b..70115183e46b 100644
--- a/clang/lib/Basic/Targets/WebAssembly.h
+++ b/clang/lib/Basic/Targets/WebAssembly.h
@@ -147,7 +147,7 @@ class LLVM_LIBRARY_VISIBILITY WebAssembly32TargetInfo
   explicit WebAssembly32TargetInfo(const llvm::Triple &T,
const TargetOptions &Opts)
   : WebAssemblyTargetInfo(T, Opts) {
-resetDataLayout("e-m:e-p:32:32-i64:64-n32:64-S128");
+resetDataLayout("e-m:e-p:32:32-i64:64-n32:64-S128-ni:1");
   }
 
 protected:
@@ -166,7 +166,7 @@ class LLVM_LIBRARY_VISIBILITY WebAssembly64TargetInfo
 SizeType = UnsignedLong;
 PtrDiffType = SignedLong;
 IntPtrType = SignedLong;
-resetDataLayout("e-m:e-p:64:64-i64:64-n32:64-S128");
+resetDataLayout("e-m:e-p:64:64-i64:64-n32:64-S128-ni:1");
   }
 
 protected:

diff  --git a/clang/test/CodeGen/target-data.c 
b/clang/test/CodeGen/target-data.c
index ea6cef484341..1d88984530e5 100644
--- a/clang/test/CodeGen/target-data.c
+++ b/clang/test/CodeGen/target-data.c
@@ -108,11 +108,11 @@
 
 // RUN: %clang_cc1 -triple wasm32-unknown-unknown -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=WEBASSEMBLY32
-// WEBASSEMBLY32: target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128"
+// WEBASSEMBLY32: target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128-ni:1"
 
 // RUN: %clang_cc1 -triple wasm64-unknown-unknown -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=WEBASSEMBLY64
-// WEBASSEMBLY64: target datalayout = "e-m:e-p:64:64-i64:64-n32:64-S128"
+// WEBASSEMBLY64: target datalayout = "e-m:e-p:64:64-i64:64-n32:64-S128-ni:1"
 
 // RUN: %clang_cc1 -triple lanai-unknown-unknown -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=LANAI

diff  --git a/llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h 
b/llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h
index 0d9c07cbf1f9..1ec1df5d0c3d 100644
--- a/llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h
+++ b/llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h
@@ -28,6 +28,26 @@ class WebAssemblySubtarget;
 
 namespace WebAssembly {
 
+enum WasmAddressSpace : unsigned {
+  // Default address space, for pointers to linear memory (stack, heap, data).
+  WASM_ADDRESS_SPACE_DEFAULT = 0,
+  // A non-integral address space for pointers to named objects outside of
+  // linear memory: WebAssembly globals or WebAssembly locals.  Loads and 
stores
+  // to these pointers are lowered to global.get / global.set or local.get /
+  // local.set, as appropriate.
+  WASM_ADDRESS_SPACE_WASM_VAR = 1
+};
+
+inline bool isDefaultAddressSpace(unsigned AS) {
+  return AS == WASM_ADDRESS_SPACE_DEFAULT;
+}
+inline bool isWasmVarAddressSpace(unsigned AS) {
+  return AS == WASM_ADDRESS_SPACE_WASM_VAR;
+}
+inline bool isValidAddressSpace(unsigned AS) {
+  return isDefaultAddressSpace(AS) || isWasmVarAddressSpace(AS);
+}
+
 bool isChild(const MachineInstr &MI, const WebAssemblyFunctionInfo &MFI);
 bool mayThrow(const MachineInstr &MI);
 

diff  --git a/llvm/lib/Target/WebAssembly/WebAssemblyFastISel.cpp 
b/llvm/lib/Target/WebAssembly/WebAssemblyFastISel.cpp
index 68e4b9c31b7c..cb0cdf1d8f98 100644
--- a/llvm/lib/Target/WebAssembly/WebAssemblyFastISel.cpp
+++ b/llvm/lib/Target/WebAssembly/We

[PATCH] D102213: [ASTMatchers] Add forCallable(), a generalization of forFunction().

2021-05-11 Thread Stephen Kelly via Phabricator via cfe-commits 
steveire added a comment.

I'm not certain what strong opinions I've voiced on the mailing list about 
that. Was it just that I think `hasDescendant` can lead to unexpected matches 
and a more-specific matcher should always be used when available (such as 
`hasArgument`)? I do think `has`, `hasDescendant`, `hasAncestor` etc have their 
uses and they get more useful with utilities like `forFunction`.

I don't know anything about objc. Is it possible to have callable decls nested 
within each other, like in c++? Is it common? `forFunction` is mostly useful 
for the very common case of lambdas within functions.

Does it make sense to add an overload for `LambdaExpr` so that you can write 
`forCallable(lambdaExpr())`?

Is there a missing test for `forFunction(functionDecl())`?


Repository:
  rC Clang

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

https://reviews.llvm.org/D102213

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

[PATCH] D100980: [OpenCL] Allow use of double type without extension pragma

2021-05-11 Thread Anastasia Stulova via Phabricator via cfe-commits 
Anastasia added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:10006
   "use of %select{type|declaration}0 %1 requires %2 support">;
+def ext_opencl_double_without_pragma : Extension<
+  "Clang permits use of type 'double' regardless pragma if 'cl_khr_fp64' is 
supported">;

azabaznov wrote:
> Anastasia wrote:
> > azabaznov wrote:
> > > nit: this can be extended to use arbitrary type and extension for other 
> > > patches which will eliminate pragmas for types
> > Well, actually I am not sure we should use it elsewhere because I don't 
> > think it really applies universally.
> > The situation for `doubles` seems to be that the older specs were 
> > intructing to use the pragma explicitly.
> > 
> > For the future work we should just avoid adding or using pragma at all 
> > unless it brings beneficial functionality.  
> > Well, actually I am not sure we should use it elsewhere because I don't 
> > think it really applies universally.
> > The situation for doubles seems to be that the older specs were intructing 
> > to use the pragma explicitly.
> 
> The same applies for atomic types, for example 
> (https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#_footnoteref_55):
> 
> //If the device address space is 64-bits, the data types atomic_intptr_t, 
> atomic_uintptr_t, atomic_size_t and atomic_ptrdiff_t are supported if the 
> cl_khr_int64_base_atomics and cl_khr_int64_extended_atomics **extensions are 
> supported and have been enabled**.//
> 
> It seems for me that simplifying the implementation in a way that enabling 
> pragma is not necessary is fine if such warning is diagnosed for atomic types 
> and half type as well. Alternatively, maybe the spec should be fixed by 
> adding `__opencl_c_fp16` and etc. as optional core features?
Ok, this is a different issues in my view:
a. It doesn't explicitly mention the pragma although I assume it is implied.
b. It assumes the pragmas could load and unload the extensions but it has not 
been implemented correctly. As a matter of fact I am removing the requirements 
for the pragma on atomics completely in https://reviews.llvm.org/D100976 
because I see no value in implementing it half way ending up in incorrect and 
inconveninent functionality.

Double support is different to atomics because `double` is actually a reserved 
identifier so disabling it actually works as expected.


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

https://reviews.llvm.org/D100980

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

[PATCH] D100919: [AArch64] Support customizing stack protector guard

2021-05-11 Thread David Spickett via Phabricator via cfe-commits 
DavidSpickett requested changes to this revision.
DavidSpickett added a comment.
This revision now requires changes to proceed.

This is probably not showing up in review queues as it got accepted 
accidentally at some point. I'm going to "Request Changes" then I think you'll 
need to refresh the diff Nick to get it back into active review.
(I don't know of any other way to "give up" an accept revision)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100919

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

[PATCH] D100919: [AArch64] Support customizing stack protector guard

2021-05-11 Thread Dave Green via Phabricator via cfe-commits 
dmgreen added a comment.

I don't know a huge amount about stack protectors.

It's worth adding -verify-machineinstrs to the tests, to check the code passes 
the internal checks.




Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.cpp:1917
+.addDef(Reg)
+.addImm(Options.StackProtectorGuardOffset >> 3);
+  else

What is StackProtectorGuardOffset, and could is be out of range for the load? 
That is something that verify-machineinstrs won't currently check for.



Comment at: llvm/lib/Target/AArch64/AArch64InstrInfo.cpp:1920
+BuildMI(MBB, MI, DL, get(AArch64::LDURXi))
+.addUse(Reg, RegState::Kill)
+.addDef(Reg)

Defs come before Uses in machine instructions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100919

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

[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-11 Thread ChenZheng via Phabricator via cfe-commits 
shchenz updated this revision to Diff 344269.
shchenz marked an inline comment as done.
shchenz added a comment.

1: address @dblaikie comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

Files:
  llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
  llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll


Index: llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
@@ -0,0 +1,43 @@
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   llvm-dwarfdump -debug-info - | FileCheck %s
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -strict-dwarf=true < %s | llvm-dwarfdump -debug-info - | \
+; RUN:   FileCheck %s -check-prefix=STRICT
+
+; If not strict DWARF mode, we expect DW_TAG_rvalue_reference_type at DWARF 3.
+; If strict DWARF mode, we expect DW_TAG_reference_type at DWARF 3 as 
DW_TAG_rvalue_reference_type
+; is a DWARF 4 tag.
+
+; CHECK: DW_TAG_rvalue_reference_type
+; STRICT: DW_TAG_reference_type
+
+define void @_Z3fooOi(i32* dereferenceable(4) %i) !dbg !8 {
+entry:
+  call void @llvm.dbg.value(metadata i32* %i, metadata !14, metadata 
!DIExpression()), !dbg !15
+  ret void, !dbg !16
+}
+
+; Function Attrs: nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata) #1
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5, !6}
+!llvm.ident = !{!7}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, 
producer: "clang version 13.0.0", isOptimized: true, runtimeVersion: 0, 
emissionKind: FullDebug, enums: !2, splitDebugInlining: false, nameTableKind: 
None)
+!1 = !DIFile(filename: "1.cpp", directory: "./")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 3}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!6 = !{i32 7, !"uwtable", i32 1}
+!7 = !{!"clang version 13.0.0"}
+!8 = distinct !DISubprogram(name: "foo", linkageName: "_Z3fooOi", scope: !1, 
file: !1, line: 1, type: !9, scopeLine: 2, flags: DIFlagPrototyped | 
DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: 
!0, retainedNodes: !13)
+!9 = !DISubroutineType(types: !10)
+!10 = !{null, !11}
+!11 = !DIDerivedType(tag: DW_TAG_rvalue_reference_type, baseType: !12, size: 
64)
+!12 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!13 = !{!14}
+!14 = !DILocalVariable(name: "i", arg: 1, scope: !8, file: !1, line: 1, type: 
!11)
+!15 = !DILocation(line: 0, scope: !8)
+!16 = !DILocation(line: 3, column: 1, scope: !8)
Index: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
+++ llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
@@ -386,6 +386,18 @@
 }
 
 DIE &DwarfUnit::createAndAddDIE(dwarf::Tag Tag, DIE &Parent, const DINode *N) {
+  // For strict DWARF mode, only generate tags available to current DWARF
+  // version.
+  if (Asm->TM.Options.DebugStrictDwarf &&
+  DD->getDwarfVersion() < dwarf::TagVersion(Tag)) {
+// See if there is any replacement for some tags.
+if (Tag == dwarf::DW_TAG_rvalue_reference_type &&
+DD->getDwarfVersion() >= 3)
+  Tag = dwarf::DW_TAG_reference_type;
+
+// Assertion for other cases.
+assert(true && "Tag is generated not following strict DWARF!");
+  }
   DIE &Die = Parent.addChild(DIE::get(DIEValueAllocator, Tag));
   if (N)
 insertDIE(N, &Die);


Index: llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
@@ -0,0 +1,43 @@
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   llvm-dwarfdump -debug-info - | FileCheck %s
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -strict-dwarf=true < %s | llvm-dwarfdump -debug-info - | \
+; RUN:   FileCheck %s -check-prefix=STRICT
+
+; If not strict DWARF mode, we expect DW_TAG_rvalue_reference_type at DWARF 3.
+; If strict DWARF mode, we expect DW_TAG_reference_type at DWARF 3 as DW_TAG_rvalue_reference_type
+; is a DWARF 4 tag.
+
+; CHECK: DW_TAG_rvalue_reference_type
+; STRICT: DW_TAG_reference_type
+
+define void @_Z3fooOi(i32* dereferenceable(4) %i) !dbg !8 {
+entry:
+  call void @llvm.dbg.value(metadata i32* %i, metadata !14, metadata !DIExpression()), !dbg !15
+  ret void, !dbg !16
+}
+
+; Function Attrs: nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata) #1
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5, !6}
+!llvm.ident = !{!7}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, producer: "clang version 13.0.0", isOptimized: true, runtimeVersion: 0, e

[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-11 Thread ChenZheng via Phabricator via cfe-commits 
shchenz added a comment.

In D100630#2748899 , @dblaikie wrote:

> Does this cause duplicate DW_TAG_reference_types in the output, if the input 
> IR Has both DW_TAG_reference_type and DW_TAG_rvalue_reference_types?

Yes, it will cause such issue in theory. I can not cook a case that has a 
DW_TAG_reference_type to a DW_TAG_rvalue_reference_types or has a 
DW_TAG_rvalue_reference_types to a DW_TAG_reference_type for now. Is there such 
usage that we both be rvalue-reference and lvalue-reference to a basic type?




Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:391
+  // version.
+  dwarf::Tag FixedTag = (dwarf::Tag)Tag;
+  if (Asm->TM.Options.DebugStrictDwarf &&

dblaikie wrote:
> Rather than adding a cast here, perhaps the parameter type could be updated? 
> (maybe in a separate preliminary commit, though, so as not to muddy this one)
Add a new NFC patch D102207


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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

[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-11 Thread David Blaikie via Phabricator via cfe-commits 
dblaikie added a comment.

In D100630#2749550 , @shchenz wrote:

> In D100630#2748899 , @dblaikie 
> wrote:
>
>> Does this cause duplicate DW_TAG_reference_types in the output, if the input 
>> IR Has both DW_TAG_reference_type and DW_TAG_rvalue_reference_types?
>
> Yes, it will cause such issue in theory. I can not cook a case that has a 
> DW_TAG_reference_type to a DW_TAG_rvalue_reference_types or has a 
> DW_TAG_rvalue_reference_types to a DW_TAG_reference_type for now. Is there 
> such usage that we both be rvalue-reference and lvalue-reference to a basic 
> type?

Ah, I was less thinking of a case of an rvalue reference and a normal reference 
in the same chain - I was thinking more about two unrelated reference types.

Try some code like:

  void f1(int &&x, int &y) {
  }

I'm guessing without this change - you get 'x's type pointing to the 
rvalue_reference_type, 'y's type pointing to the reference_type, and both of 
those pointing to the 'int' DW_TAG_basic_type.

But with this change I'm worried you'll get two copies of the 
DW_TAG_reference_type - one that replaces the rvalue reference, and then the 
real one. Instead you should get one copy that both 'x' and 'y' refer to, I 
think.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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

[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-11 Thread David Blaikie via Phabricator via cfe-commits 
dblaikie added a comment.

In D100630#2749625 , @shchenz wrote:

> In D100630#2749594 , @dblaikie 
> wrote:
>
>> In D100630#2749550 , @shchenz 
>> wrote:
>>
>>> In D100630#2748899 , @dblaikie 
>>> wrote:
>>>
 Does this cause duplicate DW_TAG_reference_types in the output, if the 
 input IR Has both DW_TAG_reference_type and DW_TAG_rvalue_reference_types?
>>>
>>> Yes, it will cause such issue in theory. I can not cook a case that has a 
>>> DW_TAG_reference_type to a DW_TAG_rvalue_reference_types or has a 
>>> DW_TAG_rvalue_reference_types to a DW_TAG_reference_type for now. Is there 
>>> such usage that we both be rvalue-reference and lvalue-reference to a basic 
>>> type?
>>
>> Ah, I was less thinking of a case of an rvalue reference and a normal 
>> reference in the same chain - I was thinking more about two unrelated 
>> reference types.
>>
>> Try some code like:
>>
>>   void f1(int &&x, int &y) {
>>   }
>>
>> I'm guessing without this change - you get 'x's type pointing to the 
>> rvalue_reference_type, 'y's type pointing to the reference_type, and both of 
>> those pointing to the 'int' DW_TAG_basic_type.
>>
>> But with this change I'm worried you'll get two copies of the 
>> DW_TAG_reference_type - one that replaces the rvalue reference, and then the 
>> real one. Instead you should get one copy that both 'x' and 'y' refer to, I 
>> think.
>
> Hmm, yeah, indeed, a duplicated `DW_TAG_reference_type` is generated.
>
>   0x0069:   DW_TAG_reference_type
>   DW_AT_type  (0x006e "int")
>   
>   0x006e:   DW_TAG_base_type
>   DW_AT_name  ("int")
>   DW_AT_encoding  (DW_ATE_signed)
>   DW_AT_byte_size (0x04)
>   
>   0x0075:   DW_TAG_reference_type
>   DW_AT_type  (0x006e "int")
>
> I think rather than fixing the duplicated `DW_TAG_reference_type` in the 
> backend, maybe it is better to fix this strict DWARF issue in the FE like the 
> fix in the previous patch https://reviews.llvm.org/D100630?id=338755
>
> What do you think? @dblaikie

I'd still hope this issue could be addressed in the backend, but yeah - it 
might be non-trivial.

@aprantl @probinson etc - any thoughts on this?




Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:398-399
+
+// Assertion for other cases.
+assert(true && "Tag is generated not following strict DWARF!");
+  }

side note: Not sure what this assertion is for/does?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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

[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-11 Thread ChenZheng via Phabricator via cfe-commits 
shchenz added a comment.

In D100630#2749594 , @dblaikie wrote:

> In D100630#2749550 , @shchenz wrote:
>
>> In D100630#2748899 , @dblaikie 
>> wrote:
>>
>>> Does this cause duplicate DW_TAG_reference_types in the output, if the 
>>> input IR Has both DW_TAG_reference_type and DW_TAG_rvalue_reference_types?
>>
>> Yes, it will cause such issue in theory. I can not cook a case that has a 
>> DW_TAG_reference_type to a DW_TAG_rvalue_reference_types or has a 
>> DW_TAG_rvalue_reference_types to a DW_TAG_reference_type for now. Is there 
>> such usage that we both be rvalue-reference and lvalue-reference to a basic 
>> type?
>
> Ah, I was less thinking of a case of an rvalue reference and a normal 
> reference in the same chain - I was thinking more about two unrelated 
> reference types.
>
> Try some code like:
>
>   void f1(int &&x, int &y) {
>   }
>
> I'm guessing without this change - you get 'x's type pointing to the 
> rvalue_reference_type, 'y's type pointing to the reference_type, and both of 
> those pointing to the 'int' DW_TAG_basic_type.
>
> But with this change I'm worried you'll get two copies of the 
> DW_TAG_reference_type - one that replaces the rvalue reference, and then the 
> real one. Instead you should get one copy that both 'x' and 'y' refer to, I 
> think.

Hmm, yeah, indeed, a duplicated `DW_TAG_reference_type` is generated.

  0x0069:   DW_TAG_reference_type
  DW_AT_type  (0x006e "int")
  
  0x006e:   DW_TAG_base_type
  DW_AT_name  ("int")
  DW_AT_encoding  (DW_ATE_signed)
  DW_AT_byte_size (0x04)
  
  0x0075:   DW_TAG_reference_type
  DW_AT_type  (0x006e "int")

I think rather than fixing the duplicated `DW_TAG_reference_type` in the 
backend, maybe it is better to fix this strict DWARF issue in the FE like the 
fix in the previous patch https://reviews.llvm.org/D100630?id=338755

What do you think? @dblaikie


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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

[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-11 Thread ChenZheng via Phabricator via cfe-commits 
shchenz updated this revision to Diff 344300.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

Files:
  llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
  llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll


Index: llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
@@ -0,0 +1,43 @@
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   llvm-dwarfdump -debug-info - | FileCheck %s
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -strict-dwarf=true < %s | llvm-dwarfdump -debug-info - | \
+; RUN:   FileCheck %s -check-prefix=STRICT
+
+; If not strict DWARF mode, we expect DW_TAG_rvalue_reference_type at DWARF 3.
+; If strict DWARF mode, we expect DW_TAG_reference_type at DWARF 3 as 
DW_TAG_rvalue_reference_type
+; is a DWARF 4 tag.
+
+; CHECK: DW_TAG_rvalue_reference_type
+; STRICT: DW_TAG_reference_type
+
+define void @_Z3fooOi(i32* dereferenceable(4) %i) !dbg !8 {
+entry:
+  call void @llvm.dbg.value(metadata i32* %i, metadata !14, metadata 
!DIExpression()), !dbg !15
+  ret void, !dbg !16
+}
+
+; Function Attrs: nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata) #1
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5, !6}
+!llvm.ident = !{!7}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, 
producer: "clang version 13.0.0", isOptimized: true, runtimeVersion: 0, 
emissionKind: FullDebug, enums: !2, splitDebugInlining: false, nameTableKind: 
None)
+!1 = !DIFile(filename: "1.cpp", directory: "./")
+!2 = !{}
+!3 = !{i32 7, !"Dwarf Version", i32 3}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!6 = !{i32 7, !"uwtable", i32 1}
+!7 = !{!"clang version 13.0.0"}
+!8 = distinct !DISubprogram(name: "foo", linkageName: "_Z3fooOi", scope: !1, 
file: !1, line: 1, type: !9, scopeLine: 2, flags: DIFlagPrototyped | 
DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: 
!0, retainedNodes: !13)
+!9 = !DISubroutineType(types: !10)
+!10 = !{null, !11}
+!11 = !DIDerivedType(tag: DW_TAG_rvalue_reference_type, baseType: !12, size: 
64)
+!12 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
+!13 = !{!14}
+!14 = !DILocalVariable(name: "i", arg: 1, scope: !8, file: !1, line: 1, type: 
!11)
+!15 = !DILocation(line: 0, scope: !8)
+!16 = !DILocation(line: 3, column: 1, scope: !8)
Index: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
+++ llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
@@ -386,6 +386,18 @@
 }
 
 DIE &DwarfUnit::createAndAddDIE(dwarf::Tag Tag, DIE &Parent, const DINode *N) {
+  // For strict DWARF mode, only generate tags available to current DWARF
+  // version.
+  if (Asm->TM.Options.DebugStrictDwarf &&
+  DD->getDwarfVersion() < dwarf::TagVersion(Tag)) {
+// See if there is any replacement for some tags.
+if (Tag == dwarf::DW_TAG_rvalue_reference_type &&
+DD->getDwarfVersion() >= 3)
+  Tag = dwarf::DW_TAG_reference_type;
+else
+  // Assertion for other cases.
+  assert(false && "Tag is generated not following strict DWARF!");
+  }
   DIE &Die = Parent.addChild(DIE::get(DIEValueAllocator, Tag));
   if (N)
 insertDIE(N, &Die);


Index: llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/PowerPC/strict-dwarf-tags.ll
@@ -0,0 +1,43 @@
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu < %s | \
+; RUN:   llvm-dwarfdump -debug-info - | FileCheck %s
+; RUN: llc -filetype=obj -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -strict-dwarf=true < %s | llvm-dwarfdump -debug-info - | \
+; RUN:   FileCheck %s -check-prefix=STRICT
+
+; If not strict DWARF mode, we expect DW_TAG_rvalue_reference_type at DWARF 3.
+; If strict DWARF mode, we expect DW_TAG_reference_type at DWARF 3 as DW_TAG_rvalue_reference_type
+; is a DWARF 4 tag.
+
+; CHECK: DW_TAG_rvalue_reference_type
+; STRICT: DW_TAG_reference_type
+
+define void @_Z3fooOi(i32* dereferenceable(4) %i) !dbg !8 {
+entry:
+  call void @llvm.dbg.value(metadata i32* %i, metadata !14, metadata !DIExpression()), !dbg !15
+  ret void, !dbg !16
+}
+
+; Function Attrs: nofree nosync nounwind readnone speculatable willreturn
+declare void @llvm.dbg.value(metadata, metadata, metadata) #1
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5, !6}
+!llvm.ident = !{!7}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, producer: "clang version 13.0.0", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, splitDebugInlining: false, nameTableKind: None)
+!1

[PATCH] D100630: [Debug-Info][DBX] DW_TAG_rvalue_reference_type should not be generated when dwarf version is smaller than 4

2021-05-11 Thread ChenZheng via Phabricator via cfe-commits 
shchenz added inline comments.



Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:398-399
+
+// Assertion for other cases.
+assert(true && "Tag is generated not following strict DWARF!");
+  }

dblaikie wrote:
> side note: Not sure what this assertion is for/does?
typo :) 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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

[clang] 13ea238 - [OpenCL] Allow use of double type without extension pragma.

2021-05-11 Thread Anastasia Stulova via cfe-commits 

Author: Anastasia Stulova
Date: 2021-05-11T12:54:38+01:00
New Revision: 13ea238b1e1db96ef5fd409e869d9a8ebeef1332

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

LOG: [OpenCL] Allow use of double type without extension pragma.

Simply use of extensions by allowing the use of supported
double types without the pragma. Since earlier standards
instructed that the pragma is used explicitly a new warning
is introduced in pedantic mode to indicate that use of
type without extension pragma enable can be non-portable.

This patch does not break backward compatibility since the
extension pragma is still supported and it makes the behavior
of the compiler less strict by accepting code without extra
pragma statements.

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

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/Sema.cpp
clang/lib/Sema/SemaType.cpp
clang/test/Misc/warning-flags.c
clang/test/SemaOpenCL/extensions.cl

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index f78940a6e6fad..3d665cc76c539 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -10023,6 +10023,9 @@ def err_opencl_variadic_function : Error<
   "invalid prototype, variadic arguments are not allowed in OpenCL">;
 def err_opencl_requires_extension : Error<
   "use of %select{type|declaration}0 %1 requires %2 support">;
+def ext_opencl_double_without_pragma : Extension<
+  "Clang permits use of type 'double' regardless pragma if 'cl_khr_fp64' is"
+  " supported">;
 def warn_opencl_generic_address_space_arg : Warning<
   "passing non-generic address space pointer to %0"
   " may cause dynamic conversion affecting performance">,

diff  --git a/clang/lib/Sema/Sema.cpp b/clang/lib/Sema/Sema.cpp
index 6c78d7325d681..b23140b4589c3 100644
--- a/clang/lib/Sema/Sema.cpp
+++ b/clang/lib/Sema/Sema.cpp
@@ -366,7 +366,6 @@ void Sema::Initialize() {
 "cl_khr_int64_base_atomics cl_khr_int64_extended_atomics");
 }
 
-setOpenCLExtensionForType(Context.DoubleTy, "cl_khr_fp64");
 
 #define EXT_OPAQUE_TYPE(ExtType, Id, Ext)  
\
   if (getOpenCLOptions().isSupported(#Ext, getLangOpts())) {   
\

diff  --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index e3f8b747a783b..9801dd6ffb66e 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -1524,6 +1524,13 @@ static QualType 
ConvertDeclSpecToType(TypeProcessingState &state) {
 break;
   case DeclSpec::TST_float:   Result = Context.FloatTy; break;
   case DeclSpec::TST_double:
+if (S.getLangOpts().OpenCL) {
+  if (!S.getOpenCLOptions().isSupported("cl_khr_fp64", S.getLangOpts()))
+S.Diag(DS.getTypeSpecTypeLoc(), diag::err_opencl_requires_extension)
+  << 0 << Context.DoubleTy << "cl_khr_fp64";
+  else if (!S.getOpenCLOptions().isAvailableOption("cl_khr_fp64", 
S.getLangOpts()))
+S.Diag(DS.getTypeSpecTypeLoc(), 
diag::ext_opencl_double_without_pragma);
+}
 if (DS.getTypeSpecWidth() == TypeSpecifierWidth::Long)
   Result = Context.LongDoubleTy;
 else

diff  --git a/clang/test/Misc/warning-flags.c b/clang/test/Misc/warning-flags.c
index 54e36e1e08845..e4f9069b88c86 100644
--- a/clang/test/Misc/warning-flags.c
+++ b/clang/test/Misc/warning-flags.c
@@ -91,4 +91,4 @@ CHECK-NEXT:   warn_weak_import
 
 The list of warnings in -Wpedantic should NEVER grow.
 
-CHECK: Number in -Wpedantic (not covered by other -W flags): 26
+CHECK: Number in -Wpedantic (not covered by other -W flags): 27

diff  --git a/clang/test/SemaOpenCL/extensions.cl 
b/clang/test/SemaOpenCL/extensions.cl
index b0be017511a80..97380292dcae6 100644
--- a/clang/test/SemaOpenCL/extensions.cl
+++ b/clang/test/SemaOpenCL/extensions.cl
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -pedantic 
-fsyntax-only
 // RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -pedantic 
-fsyntax-only -cl-std=CL1.1
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -fsyntax-only 
-cl-std=CL1.1 -DNOPEDANTIC
 // RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -pedantic 
-fsyntax-only -cl-std=CL1.2 -DFP64
 
 // Test with a target not supporting fp64.
@@ -43,8 +44,20 @@
 #endif
 
 #if (defined(__OPENCL_C_VERSION__) && __OPENCL_C_VERSION__ < 120)
-void f1(double da) { // expected-error {{type 'double' requires cl_khr_fp64 
support}}
-  double d; // expected-error {{type 'double' requires cl_khr_fp64 support}}
+void f1(double da) {
+#ifdef NOFP64
+// expected-error@-2 {{type 'double' requires cl_khr_fp64 support}}
+#elif !defined(NOPEDANTIC)

[PATCH] D100980: [OpenCL] Allow use of double type without extension pragma

2021-05-11 Thread Anastasia Stulova 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 rG13ea238b1e1d: [OpenCL] Allow use of double type without 
extension pragma. (authored by Anastasia).
Herald added a subscriber: ldrumm.
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D100980?vs=341833&id=344360#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100980

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/Misc/warning-flags.c
  clang/test/SemaOpenCL/extensions.cl

Index: clang/test/SemaOpenCL/extensions.cl
===
--- clang/test/SemaOpenCL/extensions.cl
+++ clang/test/SemaOpenCL/extensions.cl
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -pedantic -fsyntax-only
 // RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -pedantic -fsyntax-only -cl-std=CL1.1
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -fsyntax-only -cl-std=CL1.1 -DNOPEDANTIC
 // RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -pedantic -fsyntax-only -cl-std=CL1.2 -DFP64
 
 // Test with a target not supporting fp64.
@@ -43,8 +44,20 @@
 #endif
 
 #if (defined(__OPENCL_C_VERSION__) && __OPENCL_C_VERSION__ < 120)
-void f1(double da) { // expected-error {{type 'double' requires cl_khr_fp64 support}}
-  double d; // expected-error {{type 'double' requires cl_khr_fp64 support}}
+void f1(double da) {
+#ifdef NOFP64
+// expected-error@-2 {{type 'double' requires cl_khr_fp64 support}}
+#elif !defined(NOPEDANTIC)
+// expected-warning@-4{{Clang permits use of type 'double' regardless pragma if 'cl_khr_fp64' is supported}}
+#endif
+  double d;
+#ifdef NOFP64
+// expected-error@-2 {{type 'double' requires cl_khr_fp64 support}}
+#elif !defined(NOPEDANTIC)
+// expected-warning@-4{{Clang permits use of type 'double' regardless pragma if 'cl_khr_fp64' is supported}}
+#endif
+  // FIXME: this diagnostic depends on the extension pragma in the earlier versions.
+  // There is no indication that this behavior is expected.
   (void) 1.0; // expected-warning {{double precision constant requires cl_khr_fp64}}
 }
 #endif
@@ -79,13 +92,11 @@
   double4 d4 = {0.0f, 2.0f, 3.0f, 1.0f};
 #ifdef NOFP64
 // expected-error@-3 {{use of type 'double' requires cl_khr_fp64 support}}
-// expected-error@-3 {{use of type 'double4' (vector of 4 'double' values) requires cl_khr_fp64 support}}
 #endif
 
   (void) 1.0;
-
 #ifdef NOFP64
-// expected-warning@-3{{double precision constant requires cl_khr_fp64, casting to single precision}}
+// expected-warning@-2{{double precision constant requires cl_khr_fp64, casting to single precision}}
 #endif
 }
 
@@ -96,6 +107,11 @@
 
 #if (defined(__OPENCL_C_VERSION__) && __OPENCL_C_VERSION__ < 120)
 void f3(void) {
-  double d; // expected-error {{type 'double' requires cl_khr_fp64 support}}
+  double d;
+#ifdef NOFP64
+// expected-error@-2 {{type 'double' requires cl_khr_fp64 support}}
+#elif !defined(NOPEDANTIC)
+// expected-warning@-4 {{Clang permits use of type 'double' regardless pragma if 'cl_khr_fp64' is supported}}
+#endif
 }
 #endif
Index: clang/test/Misc/warning-flags.c
===
--- clang/test/Misc/warning-flags.c
+++ clang/test/Misc/warning-flags.c
@@ -91,4 +91,4 @@
 
 The list of warnings in -Wpedantic should NEVER grow.
 
-CHECK: Number in -Wpedantic (not covered by other -W flags): 26
+CHECK: Number in -Wpedantic (not covered by other -W flags): 27
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -1524,6 +1524,13 @@
 break;
   case DeclSpec::TST_float:   Result = Context.FloatTy; break;
   case DeclSpec::TST_double:
+if (S.getLangOpts().OpenCL) {
+  if (!S.getOpenCLOptions().isSupported("cl_khr_fp64", S.getLangOpts()))
+S.Diag(DS.getTypeSpecTypeLoc(), diag::err_opencl_requires_extension)
+  << 0 << Context.DoubleTy << "cl_khr_fp64";
+  else if (!S.getOpenCLOptions().isAvailableOption("cl_khr_fp64", S.getLangOpts()))
+S.Diag(DS.getTypeSpecTypeLoc(), diag::ext_opencl_double_without_pragma);
+}
 if (DS.getTypeSpecWidth() == TypeSpecifierWidth::Long)
   Result = Context.LongDoubleTy;
 else
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -366,7 +366,6 @@
 "cl_khr_int64_base_atomics cl_khr_int64_extended_atomics");
 }
 
-setOpenCLExtensionForType(Context.DoubleTy, "cl_khr_fp64");
 
 #define EXT_OPAQUE_TYPE(ExtType, Id, Ext)  \
   if (getOpenCLOptions().isSupported(#Ext, getLang

[PATCH] D99433: [Matrix] Including __builtin_matrix_multiply_add for the matrix type extension.

2021-05-11 Thread Florian Hahn via Phabricator via cfe-commits 
fhahn added a subscriber: effective-light.
fhahn added a comment.

Just FYI, `#pragma clang fp` support for matrix operations has been added in 
be2277fbf233 
 by 
@effective-light in the meantime.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99433

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

[PATCH] D102213: [ASTMatchers] Add forCallable(), a generalization of forFunction().

2021-05-11 Thread Aaron Ballman via Phabricator via cfe-commits 
aaron.ballman added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:7563
+  llvm::SmallVector Stack(Parents.begin(), Parents.end());
+  while (!Stack.empty()) {
+const auto &CurNode = Stack.back();

The formatting changes are good, but should be done in a separate NFC commit as 
they're unrelated.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:7583-7585
+/// Matches declaration of the function, method, or block
+/// the statement belongs to. Similar to 'forFunction' but additionally covers
+/// Objective-C methods and blocks.

It looks like you can re-flow the comments a bit, and add lambdas to the 
description.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:7597
+///   but does not match 'int y = 2'.
+AST_MATCHER_P(Stmt, forCallable, internal::Matcher, InnerMatcher) {
+  const auto &Parents = Finder->getASTContext().getParents(Node);

You should also update Registry.cpp to expose this via the dynamic matchers.


Repository:
  rC Clang

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

https://reviews.llvm.org/D102213

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

[PATCH] D102185: Widen `name` stencil to support `TypeLoc` nodes.

2021-05-11 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits 
ymandel accepted this revision.
ymandel added a comment.
This revision is now accepted and ready to land.

Nice, thanks!

In D102185#2749279 , @steveire wrote:

> Adding Yitzhak as a reviewer. I notice that at least the name of a 
> cxxBaseSpecifier is not supported and I don't know if that (or lack of 
> typeloc support) is desired in the Transformer design.

No, not by design, but good question. I'd be happy to take a patch adding 
`cxxBaseSpecifier` support as well.




Comment at: clang/lib/Tooling/Transformer/RangeSelector.cpp:234
+  TypeLoc Loc = *T;
+  auto ET = T->getAs();
+  if (!ET.isNull()) {

Please use `Loc` instead of `T->`. I find it a bit confusing to see them both 
used.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102185

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

[PATCH] D101790: [clang-tidy] Aliasing: Add support for passing the variable into a function by reference.

2021-05-11 Thread Aaron Ballman via Phabricator via cfe-commits 
aaron.ballman added a comment.

In D101790#2748474 , @NoQ wrote:

> I completely agree with that as well, these are 100% true positives, which is 
> why I left them as fixmes. The reason why I think we can't have them is that 
> we don't have an appropriate alias analysis implemented. Namely, we have two 
> analyses, one inside the checker that leaves out false positives like the one 
> in `negative_by_val()`, the other is the universal/reusable analysis in Utils 
> that i'm patching up that doesn't support happens-before relation.
>
> I believe the right way forward is to unify these analysis by making the 
> analysis in Utils account for happens-before relation. Ideally this means 
> re-implementing it over the CFG which probably isn't even that hard, it's 
> just a simple graph traversal problem. I may look into it in June or so.

I think that sounds like the right way forward. Thank you for looking into the 
unification!


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

https://reviews.llvm.org/D101790

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

[PATCH] D98799: [UniqueLinkageName] Use consistent checks when mangling symbo linkage name and debug linkage name.

2021-05-11 Thread Aaron Ballman via Phabricator via cfe-commits 
aaron.ballman added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names-dwarf.c:34-39
+static int go(a) int a;
+{
+  return glob + a;
+}
+
+

dblaikie wrote:
> aaron.ballman wrote:
> > dblaikie wrote:
> > > hoy wrote:
> > > > dblaikie wrote:
> > > > > dblaikie wrote:
> > > > > > hoy wrote:
> > > > > > > dblaikie wrote:
> > > > > > > > hoy wrote:
> > > > > > > > > dblaikie wrote:
> > > > > > > > > > hoy wrote:
> > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > Does this need to be down here? Or would 
> > > > > > > > > > > > > > > > > > the code be a well exercised if it was up 
> > > > > > > > > > > > > > > > > > next to the go declaration above?
> > > > > > > > > > > > > > > > > Yes, it needs to be here. Otherwise it will 
> > > > > > > > > > > > > > > > > just like the function `bar` above that 
> > > > > > > > > > > > > > > > > doesn't get a uniquefied name. I think moving 
> > > > > > > > > > > > > > > > > the definition up to right after the 
> > > > > > > > > > > > > > > > > declaration hides the declaration.
> > > > > > > > > > > > > > > > Not sure I follow - do you mean that if the go 
> > > > > > > > > > > > > > > > declaration and go definition were next to each 
> > > > > > > > > > > > > > > > other, this test would (mechanically speaking) 
> > > > > > > > > > > > > > > > not validate what the patch? Or that it would 
> > > > > > > > > > > > > > > > be less legible, but still mechanically correct?
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > I think it would be (assuming it's still 
> > > > > > > > > > > > > > > > mechanically correct) more legible to put the 
> > > > > > > > > > > > > > > > declaration next to the definition - the 
> > > > > > > > > > > > > > > > comment describes why the declaration is 
> > > > > > > > > > > > > > > > significant/why the definition is weird, and 
> > > > > > > > > > > > > > > > seeing all that together would be clearer to me 
> > > > > > > > > > > > > > > > than spreading it out/having to look further 
> > > > > > > > > > > > > > > > away to see what's going on.
> > > > > > > > > > > > > > > When the `go` declaration and `go` definition 
> > > > > > > > > > > > > > > were next to each other, the go function won't 
> > > > > > > > > > > > > > > get a uniqufied name at all. The declaration will 
> > > > > > > > > > > > > > > be overwritten by the definition. Only when the 
> > > > > > > > > > > > > > > declaration is seen by others, such the callsite 
> > > > > > > > > > > > > > > in `baz`, the declaration makes a difference by 
> > > > > > > > > > > > > > > having the callsite use a uniqufied name.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Ah! Interesting, good to know. 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Is that worth supporting, I wonder? I guess it 
> > > > > > > > > > > > > > falls out for free/without significant additional 
> > > > > > > > > > > > > > complexity. I worry about the subtlety of the 
> > > > > > > > > > > > > > additional declaration changing the behavior 
> > > > > > > > > > > > > > here... might be a bit surprising/subtle. But maybe 
> > > > > > > > > > > > > > no nice way to avoid it either.
> > > > > > > > > > > > > It would be ideal if user never writes code like 
> > > > > > > > > > > > > that. Unfortunately it exists with legacy code (such 
> > > > > > > > > > > > > as mysql). I think it's worth supporting it from 
> > > > > > > > > > > > > AutoFDO point of view to avoid a silent mismatch 
> > > > > > > > > > > > > between debug linkage name and real linkage name.
> > > > > > > > > > > > Oh, I agree that we shouldn't mismatch debug info and 
> > > > > > > > > > > > the actual symbol name - what I meant was whether code 
> > > > > > > > > > > > like this should get mangled or not when using 
> > > > > > > > > > > > unique-internal-linkage names.
> > > > > > > > > > > > 
> > > > > > > > > > > > I'm now more curious about this:
> > > > > > > > > > > > 
> > > > > > > > > > > > > When the `go` declaration and `go` definition were 
> > > > > > > > > > > > > next to each other, the go function won't get a 
> > > > > > > > > > > > > uniqufied name at all.
> > > > > > > > > > > > 
> > > > > > > > > > > > This doesn't seem to happen with the 
> > > > > > > > > > > > `__attribute__((overloadable))` attribute, for instance 
> > > > > > > > > > > > - so any idea what's different about uniquification 
> > > > > > > > > > > > that's working differently than overloadable?
> > > > > > > > > > > > 
> > > > > > > > > > > > ```
> > > > > > > > > > > > $ cat test.c
> > > > > > > > > > > > __attribute__((overloadable)) static int go(a)

[PATCH] D97449: [Diagnose] Unify MCContext and LLVMContext diagnosing

2021-05-11 Thread David Spickett via Phabricator via cfe-commits 
DavidSpickett added a comment.

@ychen Since this change the warning emitted in `AsmPrinterInlineAsm.cpp` about 
reserved registers no longer has location information for the file that the 
inline asm is in. Here's an example:

  void bar(void)
  {
  __asm__ __volatile__ ( "nop" : : : "sp");
  }
  
  ./bin/clang --target=arm-arm-none-eabi -march=armv7-m -c /tmp/test.c -o 
/dev/null

Before:

  /tmp/test.c:3:28: warning: inline asm clobber list contains reserved 
registers: SP [-Winline-asm]
  __asm__ __volatile__ ( "nop" : : : "sp");
 ^
  :1:1: note: instantiated into assembly here
  nop
  ^
  /tmp/test.c:3:28: note: Reserved registers on the clobber list may not be 
preserved across the asm statement, and clobbering them may lead to undefined 
behaviour.
  __asm__ __volatile__ ( "nop" : : : "sp");
 ^
  :1:1: note: instantiated into assembly here
  nop
  ^
  1 warning generated.

After:

  :1:1: warning: inline asm clobber list contains reserved 
registers: SP
  nop
  
  :1:1: note: Reserved registers on the clobber list may not be 
preserved across the asm statement, and clobbering them may lead to undefined 
behaviour.
  nop
  

(the reason it didn't break any tests is that we only check this message from 
IR and only look for the "contains reserved registers" line)

Can you guide me on how I might correct this?

My current impression is that since this code does `SrcMgr.PrintMessage(Loc, 
SourceMgr::DK_Warning, Msg)` it's one level too deep to get source information 
added to it automatically. And that if this code could use `DK_InlineAsm` that 
would help. However getting hold of the Diagnostic manager from MCContext isn't 
possible currently, perhaps that is by design?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97449

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

[PATCH] D102237: [CUDA][HIP] Fix non-ODR-use of static device variable

2021-05-11 Thread Yaxun Liu via Phabricator via cfe-commits 
yaxunl created this revision.
yaxunl added a reviewer: tra.
yaxunl requested review of this revision.

Currently non-ODR-use of static device variable by host code
causes static device variable to be emitted and registered,
which should not.

This patch fixes that.


https://reviews.llvm.org/D102237

Files:
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CodeGenCUDA/static-device-var-no-rdc.cu
  clang/test/CodeGenCUDA/static-device-var-rdc.cu

Index: clang/test/CodeGenCUDA/static-device-var-rdc.cu
===
--- clang/test/CodeGenCUDA/static-device-var-rdc.cu
+++ clang/test/CodeGenCUDA/static-device-var-rdc.cu
@@ -2,19 +2,19 @@
 // REQUIRES: amdgpu-registered-target
 
 // RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device \
-// RUN:   -fgpu-rdc -emit-llvm -o - -x hip %s | FileCheck \
+// RUN:   -std=c++11 -fgpu-rdc -emit-llvm -o - -x hip %s | FileCheck \
 // RUN:   -check-prefixes=DEV,INT-DEV %s
 
 // RUN: %clang_cc1 -triple x86_64-gnu-linux \
-// RUN:   -fgpu-rdc -emit-llvm -o - -x hip %s | FileCheck \
+// RUN:   -std=c++11 -fgpu-rdc -emit-llvm -o - -x hip %s | FileCheck \
 // RUN:   -check-prefixes=HOST,INT-HOST %s
 
 // RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device -cuid=abc \
-// RUN:   -fgpu-rdc -emit-llvm -o - -x hip %s > %t.dev
+// RUN:   -std=c++11 -fgpu-rdc -emit-llvm -o - -x hip %s > %t.dev
 // RUN: cat %t.dev | FileCheck -check-prefixes=DEV,EXT-DEV %s
 
 // RUN: %clang_cc1 -triple x86_64-gnu-linux -cuid=abc \
-// RUN:   -fgpu-rdc -emit-llvm -o - -x hip %s > %t.host
+// RUN:   -std=c++11 -fgpu-rdc -emit-llvm -o - -x hip %s > %t.host
 // RUN: cat %t.host | FileCheck -check-prefixes=HOST,EXT-HOST %s
 
 // Check host and device compilations use the same postfixes for static
@@ -64,6 +64,11 @@
 // DEV-NOT: @_ZL1z
 static int z;
 
+// Test non-ODR-use of static device variable is not emitted or registered.
+// DEV-NOT: @_ZL1u
+// HOST-NOT: @_ZL1u
+static __device__ int u;
+
 // Test static device variable in inline function, which should not be
 // externalized nor registered.
 // DEV-DAG: @_ZZ6devfunPPKiE1p = linkonce_odr addrspace(4) constant i32 2, comdat
@@ -77,6 +82,7 @@
   const static int w = 1;
   a[0] = x;
   a[1] = y;
+  a[2] = sizeof(u);
   b[0] = &w;
   b[1] = &x2;
   devfun(b);
@@ -88,6 +94,7 @@
   getDeviceSymbol(&x);
   getDeviceSymbol(&y);
   z = 123;
+  decltype(u) tmp;
 }
 
 // HOST: __hipRegisterVar({{.*}}@_ZL1x {{.*}}@[[DEVNAMEX]]
@@ -95,3 +102,4 @@
 // HOST-NOT: __hipRegisterVar({{.*}}@_ZL2x2
 // HOST-NOT: __hipRegisterVar({{.*}}@_ZZ6kernelPiPPKiE1w
 // HOST-NOT: __hipRegisterVar({{.*}}@_ZZ6devfunPPKiE1p
+// HOST-NOT: __hipRegisterVar({{.*}}@_ZL1u
Index: clang/test/CodeGenCUDA/static-device-var-no-rdc.cu
===
--- clang/test/CodeGenCUDA/static-device-var-no-rdc.cu
+++ clang/test/CodeGenCUDA/static-device-var-no-rdc.cu
@@ -72,6 +72,12 @@
 
 static __device__ int w;
 
+// Test non-ODR-use of static device var should not be emitted or registered.
+// DEV-NOT: @_ZL1u
+// HOST-NOT: @_ZL1u
+
+static __device__ int u;
+
 inline __device__ void devfun(const int ** b) {
   const static int p = 2;
   b[0] = &p;
@@ -88,6 +94,7 @@
   a[3] = x3;
   a[4] = x4;
   a[5] = x5;
+  a[6] = sizeof(u);
   b[0] = &w;
   b[1] = &z2;
   b[2] = &local_static_constant;
@@ -108,10 +115,12 @@
   getDeviceSymbol(&w);
   z = 123;
   a[0] = &z2;
+  decltype(u) tmp;
 }
 
 // HOST: __hipRegisterVar({{.*}}@_ZL1x {{.*}}@[[DEVNAMEX]]
 // HOST: __hipRegisterVar({{.*}}@_ZL1y {{.*}}@[[DEVNAMEY]]
 // HOST: __hipRegisterVar({{.*}}@_ZL1w {{.*}}@[[DEVNAMEW]]
+// HOST-NOT: __hipRegisterVar({{.*}}@_ZL1u
 // HOST-NOT: __hipRegisterVar({{.*}}@_ZZ6kernelPiPPKiE1w
 // HOST-NOT: __hipRegisterVar({{.*}}@_ZZ6devfunPPKiE1p
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -17126,10 +17126,7 @@
 CaptureType, DeclRefType,
 FunctionScopeIndexToStopAt);
 
-  // Diagnose ODR-use of host global variables in device functions. Reference
-  // of device global variables in host functions is allowed through shadow
-  // variables therefore it is not diagnosed.
-  if (SemaRef.LangOpts.CUDA && SemaRef.LangOpts.CUDAIsDevice) {
+  if (SemaRef.LangOpts.CUDA) {
 auto *FD = dyn_cast_or_null(SemaRef.CurContext);
 auto Target = SemaRef.IdentifyCUDATarget(FD);
 auto IsEmittedOnDeviceSide = [](VarDecl *Var) {
@@ -17145,9 +17142,28 @@
   }
   return false;
 };
-if (Var && Var->hasGlobalStorage() && !IsEmittedOnDeviceSide(Var)) {
-  SemaRef.targetDiag(Loc, diag::err_ref_bad_target)
-  << /*host*/ 2 << /*variable*/ 1 << Var << Target;
+if (Var && Var->hasGlobalStorage()) {
+  if (SemaRef.LangOpts.CUDAIsDevice && !IsEmittedOnDeviceSide(Var)) {
+// Diagnose ODR-use of host global variables in device functions.
+// Reference of device glob

[PATCH] D97449: [Diagnose] Unify MCContext and LLVMContext diagnosing

2021-05-11 Thread David Spickett via Phabricator via cfe-commits 
DavidSpickett added a comment.

  Can you guide me on how I might correct this?

Actually, now I see that MCContext has reportWarning/reportError and just needs 
a reportNote. I'll have something for you to review shortly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97449

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

[PATCH] D102238: [TableGen] [Clang] Clean up arm_mve.td file

2021-05-11 Thread Paul C. Anagnostopoulos via Phabricator via cfe-commits 
Paul-C-Anagnostopoulos created this revision.
Paul-C-Anagnostopoulos added reviewers: lattner, jansvoboda11, craig.topper, 
dblaikie.
Herald added subscribers: dmgreen, kristof.beyls.
Paul-C-Anagnostopoulos requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch does a little cleanup on the arm_mve.td TableGen file.

Could someone give me suggestions on how to test this? It builds fine, but I'm 
not sure how to test it. Of course, I will make sure that the resulting .inc 
files don't change. Anything else?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102238

Files:
  clang/include/clang/Basic/arm_mve.td


Index: clang/include/clang/Basic/arm_mve.td
===
--- clang/include/clang/Basic/arm_mve.td
+++ clang/include/clang/Basic/arm_mve.td
@@ -575,7 +575,8 @@
 }
 
 foreach half = [ "b", "t" ] in {
-  defvar halfconst = !if(!eq(half, "b"), 0, 1);
+  defvar halfconst = !ne(half, "b");
+  defvar halfconst = !if(!eq(half, "b"), 0, 1);
 
   let params = [f32], pnt = PNT_None in {
 def vcvt#half#q_f16: Intrinsic<
@@ -1153,8 +1154,9 @@
 
 multiclass DyadicImmShift {
-  defvar intparams = !if(!eq(!cast(outtype), !cast(Vector)),
- [Vector], [outtype, Vector]);
+  defvar intparams = !if(!eq(outtype, Vector), [Vector], [outtype, Vector]);
+  defvar intparams = !if(!eq(!cast(outtype), 
!cast(Vector)),
+ [Vector], [outtype, Vector]);
 
   def q_n: Intrinsic<
   outtype, (args outtype:$a, Vector:$b, imm:$sh),
@@ -1532,9 +1534,10 @@
   //
   // So this foldl expression implements what you'd write in Python as
   // [srctype for srctype in T.All if srctype != desttype]
-  let params = !foldl([], T.All, tlist, srctype, !listconcat(tlist,
-  !if(!eq(!cast(desttype),!cast(srctype)),[],[srctype])))
-  in {
+  let params = !filter(srctype, T.All, !ne(srctype, desttype)) in {
+  let params = !foldl([], T.All, tlist, srctype, !listconcat(tlist,
+  
!if(!eq(!cast(desttype),!cast(srctype)),[],[srctype])))
+  in {
 def "vreinterpretq_" # desttype: Intrinsic<
 VecOf, (args Vector:$x), (vreinterpret $x, VecOf)>;
   }
@@ -1576,8 +1579,11 @@
   defvar is_dest_float = !eq(desttype.kind, "f");
   defvar is_dest_unsigned = !eq(desttype.kind, "u");
   // First immediate operand of the LLVM intrinsic
-  defvar unsigned_flag = !if(is_dest_float, (unsignedflag Scalar),
- !if(is_dest_unsigned, V.True, V.False));
+  defvar unsigned_flag = !cond(is_dest_float : (unsignedflag Scalar),
+   is_dest_unsigned : V.True,
+   true : V.False);
+  defvar unsigned_flag = !if(is_dest_float, (unsignedflag Scalar),
+ !if(is_dest_unsigned, V.True, V.False));
   // For float->int conversions _n and _x_n intrinsics are not polymorphic
   // because the signedness of the destination type cannot be inferred.
   defvar pnt_nx = !if(is_dest_float, PNT_2Type, PNT_None);


Index: clang/include/clang/Basic/arm_mve.td
===
--- clang/include/clang/Basic/arm_mve.td
+++ clang/include/clang/Basic/arm_mve.td
@@ -575,7 +575,8 @@
 }
 
 foreach half = [ "b", "t" ] in {
-  defvar halfconst = !if(!eq(half, "b"), 0, 1);
+  defvar halfconst = !ne(half, "b");
+  defvar halfconst = !if(!eq(half, "b"), 0, 1);
 
   let params = [f32], pnt = PNT_None in {
 def vcvt#half#q_f16: Intrinsic<
@@ -1153,8 +1154,9 @@
 
 multiclass DyadicImmShift {
-  defvar intparams = !if(!eq(!cast(outtype), !cast(Vector)),
- [Vector], [outtype, Vector]);
+  defvar intparams = !if(!eq(outtype, Vector), [Vector], [outtype, Vector]);
+  defvar intparams = !if(!eq(!cast(outtype), !cast(Vector)),
+ [Vector], [outtype, Vector]);
 
   def q_n: Intrinsic<
   outtype, (args outtype:$a, Vector:$b, imm:$sh),
@@ -1532,9 +1534,10 @@
   //
   // So this foldl expression implements what you'd write in Python as
   // [srctype for srctype in T.All if srctype != desttype]
-  let params = !foldl([], T.All, tlist, srctype, !listconcat(tlist,
-  !if(!eq(!cast(desttype),!cast(srctype)),[],[srctype])))
-  in {
+  let params = !filter(srctype, T.All, !ne(srctype, desttype)) in {
+  let params = !foldl([], T.All, tlist, srctype, !listconcat(tlist,
+  !if(!eq(!cast(desttype),!cast(srctype)),[],[srctype])))
+  in {
 def "vreinterpretq_" # desttype: Intrinsic<
 VecOf, (args Vector:$x), (vreinterpret $x, VecOf)>;
   }
@@ -1576,8 +1579,11 @@
   defvar is_dest_float = !eq(desttype.kind, "f");
   defvar is_dest_unsigned = !eq(desttype.kind, "u");
   // First immediate operand of the LLVM intrinsic
-  defvar unsigned_flag = !if(is_dest_float, (unsignedflag Scalar),
- !if(is_dest_unsigned, V.True, V.

[PATCH] D100396: [SYCL] Enable `opencl_global_[host,device]` attributes for SYCL

2021-05-11 Thread Alexey Bader via Phabricator via cfe-commits 
bader updated this revision to Diff 344393.
bader added a comment.

Apply code review suggestions and rebase on ToT.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100396

Files:
  clang/docs/SYCLSupport.rst
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AddressSpaces.h
  clang/include/clang/Sema/ParsedAttr.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Basic/Targets/TCE.h
  clang/lib/Basic/Targets/X86.h
  clang/test/CodeGenSYCL/address-space-conversions.cpp
  clang/test/SemaSYCL/address-space-conversions.cpp
  clang/test/SemaTemplate/address_space-dependent.cpp

Index: clang/test/SemaTemplate/address_space-dependent.cpp
===
--- clang/test/SemaTemplate/address_space-dependent.cpp
+++ clang/test/SemaTemplate/address_space-dependent.cpp
@@ -43,7 +43,7 @@
 
 template 
 void tooBig() {
-  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388590)}}
+  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388588)}}
 }
 
 template 
@@ -101,7 +101,7 @@
   car<1, 2, 3>(); // expected-note {{in instantiation of function template specialization 'car<1, 2, 3>' requested here}}
   HasASTemplateFields<1> HASTF;
   neg<-1>(); // expected-note {{in instantiation of function template specialization 'neg<-1>' requested here}}
-  correct<0x7FFFED>();
+  correct<0x7FFFEB>();
   tooBig<8388650>(); // expected-note {{in instantiation of function template specialization 'tooBig<8388650>' requested here}}
 
   __attribute__((address_space(1))) char *x;
Index: clang/test/SemaSYCL/address-space-conversions.cpp
===
--- clang/test/SemaSYCL/address-space-conversions.cpp
+++ clang/test/SemaSYCL/address-space-conversions.cpp
@@ -61,4 +61,15 @@
   void *v = GLOB;
   (void)i;
   (void)v;
+
+  __attribute__((opencl_global_host)) int *GLOB_HOST;
+  bar(*GLOB_HOST);
+  bar2(*GLOB_HOST);
+  GLOB = GLOB_HOST;
+  GLOB_HOST = GLOB; // expected-error {{assigning '__global int *' to '__global_host int *' changes address space of pointer}}
+  __attribute__((opencl_global_device)) int *GLOB_DEVICE;
+  bar(*GLOB_DEVICE);
+  bar2(*GLOB_DEVICE);
+  GLOB = GLOB_DEVICE;
+  GLOB_DEVICE = GLOB; // expected-error {{assigning '__global int *' to '__global_device int *' changes address space of pointer}}
 }
Index: clang/test/CodeGenSYCL/address-space-conversions.cpp
===
--- clang/test/CodeGenSYCL/address-space-conversions.cpp
+++ clang/test/CodeGenSYCL/address-space-conversions.cpp
@@ -29,6 +29,10 @@
   // CHECK-DAG: [[PRIV:%[a-zA-Z0-9]+]] = alloca i32*
   // CHECK-DAG: [[PRIV]].ascast = addrspacecast i32** [[PRIV]] to i32* addrspace(4)*
   __attribute__((opencl_private)) int *PRIV;
+  // CHECK-DAG: [[GLOB_DEVICE:%[a-zA-Z0-9]+]] = alloca i32 addrspace(5)*
+  __attribute__((opencl_global_device)) int *GLOBDEVICE;
+  // CHECK-DAG: [[GLOB_HOST:%[a-zA-Z0-9]+]] = alloca i32 addrspace(6)*
+  __attribute__((opencl_global_host)) int *GLOBHOST;
 
   // Explicit conversions
   // From names address spaces to default address space
@@ -57,6 +61,15 @@
   // CHECK-DAG: [[NoAS_CAST:%[a-zA-Z0-9]+]] = addrspacecast i32 addrspace(4)* [[NoAS_LOAD]] to i32*
   // CHECK-DAG: store i32* [[NoAS_CAST]], i32* addrspace(4)* [[PRIV]].ascast
   PRIV = (__attribute__((opencl_private)) int *)NoAS;
+  // From opencl_global_[host/device] address spaces to opencl_global
+  // CHECK-DAG: [[GLOBDEVICE_LOAD:%[a-zA-Z0-9]+]] = load i32 addrspace(5)*, i32 addrspace(5)* addrspace(4)* [[GLOB_DEVICE]].ascast
+  // CHECK-DAG: [[GLOBDEVICE_CAST:%[a-zA-Z0-9]+]] = addrspacecast i32 addrspace(5)* [[GLOBDEVICE_LOAD]] to i32 addrspace(1)*
+  // CHECK-DAG: store i32 addrspace(1)* [[GLOBDEVICE_CAST]], i32 addrspace(1)* addrspace(4)* [[GLOB]].ascast
+  GLOB = (__attribute__((opencl_global)) int *)GLOBDEVICE;
+  // CHECK-DAG: [[GLOBHOST_LOAD:%[a-zA-Z0-9]+]] = load i32 addrspace(6)*, i32 addrspace(6)* addrspace(4)* [[GLOB_HOST]].ascast
+  // CHECK-DAG: [[GLOBHOST_CAST:%[a-zA-Z0-9]+]] = addrspacecast i32 addrspace(6)* [[GLOBHOST_LOAD]] to i32 addrspace(1)*
+  // CHECK-DAG: store i32 addrspace(1)* [[GLOBHOST_CAST]], i32 addrspace(1)* addrspace(4)* [[GLOB]].ascast
+  GLOB = (__attribute__((opencl_global)) int *)GLOBHOST;
 
   bar(*GLOB);
   // CHECK-DAG: [[GLOB_LOAD:%[a-zA-Z0-9]+]] = load i32 addrspace(1)*, i32 addrspace(1)* addrspace(4)* [[GLOB]].ascast
Index: clang/lib/Basic/Targets/X86.h
===
--- clang/lib/Basic/Targets/X86.h
+++ clang/lib/Basic/Targets/X86.h
@@ -3

[PATCH] D100396: [SYCL] Enable `opencl_global_[host,device]` attributes for SYCL

2021-05-11 Thread Alexey Bader via Phabricator via cfe-commits 
bader marked 3 inline comments as done.
bader added inline comments.



Comment at: clang/test/SemaSYCL/address-space-conversions.cpp:74
+  GLOB = GLOB_DEVICE;
+  GLOB_DEVICE = GLOB; // expected-error {{assigning '__global int *' to 
'__global_device int *' changes address space of pointer}}
 }

Anastasia wrote:
> Let's add explicit casts too.
Done.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100396

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

[PATCH] D102240: [analyzer][solver] Prevent use of a null state

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

rdar://77686137


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102240

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/PR50268.c


Index: clang/test/Analysis/PR50268.c
===
--- /dev/null
+++ clang/test/Analysis/PR50268.c
@@ -0,0 +1,12 @@
+// RUN: %clang_analyze_cc1 -w -analyzer-checker=core -verify %s
+
+// expected-no-diagnostics
+
+unsigned long a, c;
+int b;
+void d() {
+  c -= a;
+  0 >= b;
+  c != b;
+  c ? 0 : 2; // expected no crash
+}
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -1487,15 +1487,18 @@
   // This is an infeasible assumption.
   return nullptr;
 
-ProgramStateRef NewState = setConstraint(State, Sym, NewConstraint);
-if (auto Equality = EqualityInfo::extract(Sym, Int, Adjustment)) {
-  // If the original assumption is not Sym + Adjustment !=/ Int,
-  // we should invert IsEquality flag.
-  Equality->IsEquality = Equality->IsEquality != EQ;
-  return track(NewState, *Equality);
+if (ProgramStateRef NewState = setConstraint(State, Sym, NewConstraint)) {
+  if (auto Equality = EqualityInfo::extract(Sym, Int, Adjustment)) {
+// If the original assumption is not Sym + Adjustment !=/ Int,
+// we should invert IsEquality flag.
+Equality->IsEquality = Equality->IsEquality != EQ;
+return track(NewState, *Equality);
+  }
+
+  return NewState;
 }
 
-return NewState;
+return nullptr;
   }
 
   ProgramStateRef track(ProgramStateRef State, EqualityInfo ToTrack) {


Index: clang/test/Analysis/PR50268.c
===
--- /dev/null
+++ clang/test/Analysis/PR50268.c
@@ -0,0 +1,12 @@
+// RUN: %clang_analyze_cc1 -w -analyzer-checker=core -verify %s
+
+// expected-no-diagnostics
+
+unsigned long a, c;
+int b;
+void d() {
+  c -= a;
+  0 >= b;
+  c != b;
+  c ? 0 : 2; // expected no crash
+}
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -1487,15 +1487,18 @@
   // This is an infeasible assumption.
   return nullptr;
 
-ProgramStateRef NewState = setConstraint(State, Sym, NewConstraint);
-if (auto Equality = EqualityInfo::extract(Sym, Int, Adjustment)) {
-  // If the original assumption is not Sym + Adjustment !=/ Int,
-  // we should invert IsEquality flag.
-  Equality->IsEquality = Equality->IsEquality != EQ;
-  return track(NewState, *Equality);
+if (ProgramStateRef NewState = setConstraint(State, Sym, NewConstraint)) {
+  if (auto Equality = EqualityInfo::extract(Sym, Int, Adjustment)) {
+// If the original assumption is not Sym + Adjustment !=/ Int,
+// we should invert IsEquality flag.
+Equality->IsEquality = Equality->IsEquality != EQ;
+return track(NewState, *Equality);
+  }
+
+  return NewState;
 }
 
-return NewState;
+return nullptr;
   }
 
   ProgramStateRef track(ProgramStateRef State, EqualityInfo ToTrack) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D100276: [clang] p1099 using enum part 1

2021-05-11 Thread Nathan Sidwell via Phabricator via cfe-commits 
urnathan updated this revision to Diff 344396.
urnathan edited the summary of this revision.
urnathan edited reviewers, added: davrec; removed: Quuxplusone.
urnathan added a comment.

This update relies upon D101777  & D102239 
 (let's see if I can figure out how to note 
that elsewhere)


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

https://reviews.llvm.org/D100276

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p3.cpp
  clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p7-cxx20.cpp
  clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p7.cpp
  clang/test/SemaCXX/enum-scoped.cpp

Index: clang/test/SemaCXX/enum-scoped.cpp
===
--- clang/test/SemaCXX/enum-scoped.cpp
+++ clang/test/SemaCXX/enum-scoped.cpp
@@ -301,8 +301,8 @@
   int E::*p; // expected-error {{does not point into a class}}
   using E::f; // expected-error {{no member named 'f'}}
 
-  using E::a; // expected-error {{using declaration cannot refer to a scoped enumerator}}
-  E b = a; // expected-error {{undeclared}}
+  using E::a; // expected-warning {{using declaration naming a scoped enumerator is a C++20 extension}}
+  E b = a;
 }
 
 namespace test11 {
Index: clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p7.cpp
===
--- clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p7.cpp
+++ clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p7.cpp
@@ -1,4 +1,11 @@
 // RUN: %clang_cc1 -std=c++11 -verify %s
+// RUN: %clang_cc1 -std=c++17 -verify %s
+// RUN: %clang_cc1 -std=c++20 -verify %s
 
 enum class EC { ec };
-using EC::ec; // expected-error {{using declaration cannot refer to a scoped enumerator}}
+using EC::ec;
+#if __cplusplus < 202002
+// expected-warning@-2 {{using declaration naming a scoped enumerator is a C++20 extension}}
+#else
+// expected-no-diagnostics
+#endif
Index: clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p7-cxx20.cpp
===
--- /dev/null
+++ clang/test/CXX/dcl.dcl/basic.namespace/namespace.udecl/p7-cxx20.cpp
@@ -0,0 +1,271 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++17 -verify %s
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+
+// p1099 'using SCOPEDENUM::MEMBER;'
+
+namespace Zero {
+namespace Bob {
+enum class Kevin {
+  Stuart,
+  AlsoStuart
+#if __cplusplus >= 202002L
+// expected-note@-3{{target of using declaration}}
+// expected-note@-3{{target of using declaration}}
+#endif
+};
+} // namespace Bob
+
+using Bob::Kevin::Stuart;
+#if __cplusplus < 202002L
+// expected-warning@-2{{using declaration naming a scoped enumerator is a C++20 extension}}
+#else
+using Bob::Kevin::Stuart;
+
+auto b = Stuart;
+
+namespace Foo {
+int Stuart;   // expected-note{{conflicting declaration}}
+using Bob::Kevin::Stuart; // expected-error{{target of using declaration conflicts}}
+
+using Bob::Kevin::AlsoStuart; // expected-note{{using declaration}}
+int AlsoStuart;   // expected-error{{declaration conflicts with target}}
+} // namespace Foo
+#endif
+
+} // namespace Zero
+
+namespace One {
+
+// derived from [namespace.udecl]/3
+enum class button { up,
+down };
+struct S {
+  using button::up;
+#if __cplusplus < 202002L
+  // expected-warning@-2{{a C++20 extension}}
+  // expected-error@-3{{using declaration in class}}
+#else
+  button b = up;
+#endif
+};
+
+#if __cplusplus >= 202002L
+// some more
+struct T : S {
+  button c = up;
+};
+#endif
+enum E2 { e2 };
+} // namespace One
+
+namespace Two {
+enum class E1 { e1 };
+
+struct S {
+  using One::e2;
+#if __cplusplus < 202002L
+  // expected-error@-2{{using declaration in class}}
+#else
+  One::E2 c = e2;
+#endif
+};
+
+} // namespace Two
+
+namespace Three {
+
+enum E3 { e3 };
+struct e3;
+
+struct S {
+  using Three::e3; // expected-error{{using declaration in class}}
+
+  enum class E4 { e4 };
+  enum E5 { e5 };
+};
+
+using S::e5;
+using S::E4::e4;
+#if __cplusplus < 202002L
+// expected-error@-3{{using declaration cannot refer to class member}}
+// expected-note@-4{{use a constexpr variable instead}}
+// expected-warning@-4{{a C++20 extension}}
+// expected-error@-5{{using declaration cannot refer to class member}}
+// expected-note@-6{{use a constexpr variable instead}}
+#else
+auto a = e4;
+auto b = e5;
+#endif
+} // namespace Three
+
+namespace Four {
+
+template 
+struct TPL {
+  enum class E1 { e1 };
+  struct IN {
+enum class E2 { e2 };
+  };
+
+protected:
+  enum class E3 { e3 }; // expected-note{{declared protected here}}
+};
+
+using TPL::E1::e1;
+#if __cplusplus < 202002L
+// expected-warning@-2{{a C++20 extension}}
+// expected-err

[PATCH] D100396: [SYCL] Enable `opencl_global_[host,device]` attributes for SYCL

2021-05-11 Thread Alexey Bader via Phabricator via cfe-commits 
bader updated this revision to Diff 344399.
bader marked an inline comment as done.
bader added a comment.

Added explicit cast checks to Sema tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100396

Files:
  clang/docs/SYCLSupport.rst
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AddressSpaces.h
  clang/include/clang/Sema/ParsedAttr.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Basic/Targets/TCE.h
  clang/lib/Basic/Targets/X86.h
  clang/test/CodeGenSYCL/address-space-conversions.cpp
  clang/test/SemaSYCL/address-space-conversions.cpp
  clang/test/SemaTemplate/address_space-dependent.cpp

Index: clang/test/SemaTemplate/address_space-dependent.cpp
===
--- clang/test/SemaTemplate/address_space-dependent.cpp
+++ clang/test/SemaTemplate/address_space-dependent.cpp
@@ -43,7 +43,7 @@
 
 template 
 void tooBig() {
-  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388590)}}
+  __attribute__((address_space(I))) int *bounds; // expected-error {{address space is larger than the maximum supported (8388588)}}
 }
 
 template 
@@ -101,7 +101,7 @@
   car<1, 2, 3>(); // expected-note {{in instantiation of function template specialization 'car<1, 2, 3>' requested here}}
   HasASTemplateFields<1> HASTF;
   neg<-1>(); // expected-note {{in instantiation of function template specialization 'neg<-1>' requested here}}
-  correct<0x7FFFED>();
+  correct<0x7FFFEB>();
   tooBig<8388650>(); // expected-note {{in instantiation of function template specialization 'tooBig<8388650>' requested here}}
 
   __attribute__((address_space(1))) char *x;
Index: clang/test/SemaSYCL/address-space-conversions.cpp
===
--- clang/test/SemaSYCL/address-space-conversions.cpp
+++ clang/test/SemaSYCL/address-space-conversions.cpp
@@ -61,4 +61,17 @@
   void *v = GLOB;
   (void)i;
   (void)v;
+
+  __attribute__((opencl_global_host)) int *GLOB_HOST;
+  bar(*GLOB_HOST);
+  bar2(*GLOB_HOST);
+  GLOB = GLOB_HOST;
+  GLOB_HOST = GLOB; // expected-error {{assigning '__global int *' to '__global_host int *' changes address space of pointer}}
+  GLOB_HOST = static_cast<__attribute__((opencl_global_host)) int *>(GLOB); // expected-error {{static_cast from '__global int *' to '__global_host int *' is not allowed}}
+  __attribute__((opencl_global_device)) int *GLOB_DEVICE;
+  bar(*GLOB_DEVICE);
+  bar2(*GLOB_DEVICE);
+  GLOB = GLOB_DEVICE;
+  GLOB_DEVICE = GLOB; // expected-error {{assigning '__global int *' to '__global_device int *' changes address space of pointer}}
+  GLOB_DEVICE = static_cast<__attribute__((opencl_global_device)) int *>(GLOB); // expected-error {{static_cast from '__global int *' to '__global_device int *' is not allowed}}
 }
Index: clang/test/CodeGenSYCL/address-space-conversions.cpp
===
--- clang/test/CodeGenSYCL/address-space-conversions.cpp
+++ clang/test/CodeGenSYCL/address-space-conversions.cpp
@@ -29,6 +29,10 @@
   // CHECK-DAG: [[PRIV:%[a-zA-Z0-9]+]] = alloca i32*
   // CHECK-DAG: [[PRIV]].ascast = addrspacecast i32** [[PRIV]] to i32* addrspace(4)*
   __attribute__((opencl_private)) int *PRIV;
+  // CHECK-DAG: [[GLOB_DEVICE:%[a-zA-Z0-9]+]] = alloca i32 addrspace(5)*
+  __attribute__((opencl_global_device)) int *GLOBDEVICE;
+  // CHECK-DAG: [[GLOB_HOST:%[a-zA-Z0-9]+]] = alloca i32 addrspace(6)*
+  __attribute__((opencl_global_host)) int *GLOBHOST;
 
   // Explicit conversions
   // From names address spaces to default address space
@@ -57,6 +61,15 @@
   // CHECK-DAG: [[NoAS_CAST:%[a-zA-Z0-9]+]] = addrspacecast i32 addrspace(4)* [[NoAS_LOAD]] to i32*
   // CHECK-DAG: store i32* [[NoAS_CAST]], i32* addrspace(4)* [[PRIV]].ascast
   PRIV = (__attribute__((opencl_private)) int *)NoAS;
+  // From opencl_global_[host/device] address spaces to opencl_global
+  // CHECK-DAG: [[GLOBDEVICE_LOAD:%[a-zA-Z0-9]+]] = load i32 addrspace(5)*, i32 addrspace(5)* addrspace(4)* [[GLOB_DEVICE]].ascast
+  // CHECK-DAG: [[GLOBDEVICE_CAST:%[a-zA-Z0-9]+]] = addrspacecast i32 addrspace(5)* [[GLOBDEVICE_LOAD]] to i32 addrspace(1)*
+  // CHECK-DAG: store i32 addrspace(1)* [[GLOBDEVICE_CAST]], i32 addrspace(1)* addrspace(4)* [[GLOB]].ascast
+  GLOB = (__attribute__((opencl_global)) int *)GLOBDEVICE;
+  // CHECK-DAG: [[GLOBHOST_LOAD:%[a-zA-Z0-9]+]] = load i32 addrspace(6)*, i32 addrspace(6)* addrspace(4)* [[GLOB_HOST]].ascast
+  // CHECK-DAG: [[GLOBHOST_CAST:%[a-zA-Z0-9]+]] = addrspacecast i32 addrspace(6)* [[GLOBHOST_LOAD]] to i32 addrspace(1)*
+  // CHECK-DAG: store i32 addrspace(1)* [[GLOBHOST_CAST]], i32 addrspace(1)* addrspace(4)* [[G

[PATCH] D102065: [AMDGPU][OpenMP] Emit textual IR for -emit-llvm -S

2021-05-11 Thread Pushpinder Singh via Phabricator via cfe-commits 
pdhaliwal added a comment.

This is not working as expected. And has resulted in broken libomptarget tests. 
Reverting this until I find a different fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102065

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

[PATCH] D101935: [clang] Search runtimes build tree for openmp runtime

2021-05-11 Thread Shilei Tian via Phabricator via cfe-commits 
tianshilei1992 requested changes to this revision.
tianshilei1992 added a comment.
This revision now requires changes to proceed.

From my perspective, this is not a good direction. No need to bother Clang 
driver for one case of testing. `LIBRARY_PATH` needs to be set correctly by lit 
instead of hardcoded the logic in the driver.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101935

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

[clang] eca3d68 - Revert "[AMDGPU][OpenMP] Emit textual IR for -emit-llvm -S"

2021-05-11 Thread Pushpinder Singh via cfe-commits 

Author: Pushpinder Singh
Date: 2021-05-11T10:07:13-05:00
New Revision: eca3d68399246765bc6e8c94ffb4d5927b1add12

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

LOG: Revert "[AMDGPU][OpenMP] Emit textual IR for -emit-llvm -S"

This reverts commit 7f78e409d0280c62209e1a7dc8c6d1409acc9184.

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/amdgpu-openmp-toolchain.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index c4ea67ea93660..0cad688873b7c 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4394,13 +4394,7 @@ void Clang::ConstructJob(Compilation &C, const JobAction 
&JA,
   CmdArgs.push_back("-emit-llvm");
 } else if (JA.getType() == types::TY_LLVM_BC ||
JA.getType() == types::TY_LTO_BC) {
-  // Emit textual llvm IR for AMDGPU offloading for -emit-llvm -S
-  if (Triple.isAMDGCN() && IsOpenMPDevice) {
-if (Args.hasArg(options::OPT_S) && Args.hasArg(options::OPT_emit_llvm))
-  CmdArgs.push_back("-emit-llvm");
-  } else {
-CmdArgs.push_back("-emit-llvm-bc");
-  }
+  CmdArgs.push_back("-emit-llvm-bc");
 } else if (JA.getType() == types::TY_IFS ||
JA.getType() == types::TY_IFS_CPP) {
   StringRef ArgStr =

diff  --git a/clang/test/Driver/amdgpu-openmp-toolchain.c 
b/clang/test/Driver/amdgpu-openmp-toolchain.c
index e4b89dcedf01f..5f2bdff549607 100644
--- a/clang/test/Driver/amdgpu-openmp-toolchain.c
+++ b/clang/test/Driver/amdgpu-openmp-toolchain.c
@@ -71,6 +71,3 @@
 // CHECK-C: "x86_64-unknown-linux-gnu" - "clang"
 // CHECK-C: "x86_64-unknown-linux-gnu" - "clang::as"
 // CHECK-C: "x86_64-unknown-linux-gnu" - "offload bundler"
-
-// RUN:   %clang -### --target=x86_64-unknown-linux-gnu -emit-llvm -S -fopenmp 
-fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa 
-march=gfx803 -nogpulib %s 2>&1 | FileCheck %s --check-prefix=CHECK-EMIT-LLVM-IR
-// CHECK-EMIT-LLVM-IR: clang{{.*}}"-cc1"{{.*}}"-triple" 
"amdgcn-amd-amdhsa"{{.*}}"-emit-llvm"



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

[PATCH] D102064: Parse vector bool when stdbool.h and altivec.h are included

2021-05-11 Thread Hubert Tong via Phabricator via cfe-commits 
hubert.reinterpretcast added inline comments.



Comment at: clang/lib/Parse/ParseDecl.cpp:7331-7332
 }
-if (Next.getIdentifierInfo() == Ident_bool) {
+if ((Next.getIdentifierInfo() == Ident_bool) ||
+Next.getIdentifierInfo() == Ident_Bool) {
   Tok.setKind(tok::kw___vector);

Minor nit: remove (inconsistently applied) extra parentheses.



Comment at: clang/lib/Parse/Parser.cpp:515
 
+  if (getLangOpts().AltiVec)
+Ident_Bool = &PP.getIdentifierTable().get("_Bool");

No need for an extra `if` block. Just need to figure out which block above this 
should go in.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102064

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

[PATCH] D101935: [clang] Search runtimes build tree for openmp runtime

2021-05-11 Thread Jon Chesterfield via Phabricator via cfe-commits 
JonChesterfield added a comment.

More compelling than the testing case is that openmp is presently unusable 
without setting ld_library_path. This is part of fixing that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101935

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

[PATCH] D102238: [TableGen] [Clang] Clean up arm_mve.td file

2021-05-11 Thread Dave Green via Phabricator via cfe-commits 
dmgreen added a reviewer: simon_tatham.
dmgreen added a comment.

Testing the inc files sounds good to me. There are also tests in places like 
clang/test/CodeGen/arm-mve-intrinsics that will test this, which seem to all be 
passing? Anything that does `#include `


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102238

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

[PATCH] D101935: [clang] Search runtimes build tree for openmp runtime

2021-05-11 Thread Shilei Tian via Phabricator via cfe-commits 
tianshilei1992 added a comment.

Unlike others, such as `/usr/local/lib` or `/usr/local/cuda`, it is not a 
standard place. It doesn't make too much sense to hardcode it in the driver.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101935

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

[PATCH] D102238: [TableGen] [Clang] Clean up arm_mve.td file

2021-05-11 Thread Simon Tatham via Phabricator via cfe-commits 
simon_tatham added a comment.

For this kind of pure refactoring on a `.td` file, my usual approach to testing 
it is to run the file through Tablegen without any output option (i.e. just in 
the default `-print-records` mode), before and after the change. In this case, 
I'd think, you ought to be able to expect bit-for-bit identical output – and if 
you get it, then you can be pretty confident that all the directly useful 
output modes won't have changed either.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102238

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

[PATCH] D102244: [llvm][AsmPrinter] Restore source location to register clobber warning

2021-05-11 Thread David Spickett via Phabricator via cfe-commits 
DavidSpickett created this revision.
Herald added a subscriber: hiraditya.
DavidSpickett requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Since 5de2d189e6ad466a1f0616195e8c524a4eb3cbc0 
 this 
particular warning
hasn't had the location of the source file containing the inline
assembly.

To fix this report the warning and note via MCContext rather than directly
using the source manager.

This message is already tested via IR in llvm. However we won't have
the required location info there so I've added a C file test in clang
to cover it.
(though strictly, this is testing llvm code)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102244

Files:
  clang/test/Misc/inline-asm-clobber-warning.c
  llvm/include/llvm/MC/MCContext.h
  llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
  llvm/lib/MC/MCContext.cpp


Index: llvm/lib/MC/MCContext.cpp
===
--- llvm/lib/MC/MCContext.cpp
+++ llvm/lib/MC/MCContext.cpp
@@ -964,6 +964,12 @@
   }
 }
 
+void MCContext::reportNote(SMLoc Loc, const Twine &Msg) {
+  reportCommon(Loc, [&](SMDiagnostic &D, const SourceMgr *SMP) {
+D = SMP->GetMessage(Loc, SourceMgr::DK_Note, Msg);
+  });
+}
+
 void MCContext::reportFatalError(SMLoc Loc, const Twine &Msg) {
   reportError(Loc, Msg);
 
Index: llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
+++ llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
@@ -542,8 +542,8 @@
 "Reserved registers on the clobber list may not be "
 "preserved across the asm statement, and clobbering them may "
 "lead to undefined behaviour.";
-SrcMgr.PrintMessage(Loc, SourceMgr::DK_Warning, Msg);
-SrcMgr.PrintMessage(Loc, SourceMgr::DK_Note, Note);
+MMI->getContext().reportWarning(Loc, Msg);
+MMI->getContext().reportNote(Loc, Note);
   }
 
   emitInlineAsm(OS.str(), getSubtargetInfo(), TM.Options.MCOptions, LocMD,
Index: llvm/include/llvm/MC/MCContext.h
===
--- llvm/include/llvm/MC/MCContext.h
+++ llvm/include/llvm/MC/MCContext.h
@@ -805,6 +805,7 @@
 void diagnose(const SMDiagnostic &SMD);
 void reportError(SMLoc L, const Twine &Msg);
 void reportWarning(SMLoc L, const Twine &Msg);
+void reportNote(SMLoc L, const Twine &Msg);
 // Unrecoverable error has occurred. Display the best diagnostic we can
 // and bail via exit(1). For now, most MC backend errors are unrecoverable.
 // FIXME: We should really do something about that.
Index: clang/test/Misc/inline-asm-clobber-warning.c
===
--- /dev/null
+++ clang/test/Misc/inline-asm-clobber-warning.c
@@ -0,0 +1,26 @@
+/// This test checks that the warning includes the location in the C source
+/// file that contains the inline asm. Instead of saying  for both.
+/// Although this warning is emitted in llvm it cannot be tested from IR as
+/// it does not have that location information at that stage.
+
+// RUN: %clang -target arm-arm-none-eabi -march=armv7-m -c %s -o /dev/null \
+// RUN:   2>&1 | FileCheck %s
+
+// REQUIRES: arm-registered-target
+
+void bar(void) {
+__asm__ __volatile__ ( "nop" : : : "sp");
+}
+
+// CHECK:  inline-asm-clobber-warning.c:12:28: warning: inline asm clobber 
list contains reserved registers: SP [-Winline-asm]
+// CHECK-NEXT: __asm__ __volatile__ ( "nop" : : : "sp");
+// CHECK-NEXT:^
+// CHECK-NEXT: :1:1: note: instantiated into assembly here
+// CHECK-NEXT: nop
+// CHECK-NEXT: ^
+// CHECK-NEXT: inline-asm-clobber-warning.c:12:28: note: Reserved registers on 
the clobber list may not be preserved across the asm statement, and clobbering 
them may lead to undefined behaviour.
+// CHECK-NEXT: __asm__ __volatile__ ( "nop" : : : "sp");
+// CHECK-NEXT:^
+// CHECK-NEXT: :1:1: note: instantiated into assembly here
+// CHECK-NEXT: nop
+// CHECK-NEXT: ^


Index: llvm/lib/MC/MCContext.cpp
===
--- llvm/lib/MC/MCContext.cpp
+++ llvm/lib/MC/MCContext.cpp
@@ -964,6 +964,12 @@
   }
 }
 
+void MCContext::reportNote(SMLoc Loc, const Twine &Msg) {
+  reportCommon(Loc, [&](SMDiagnostic &D, const SourceMgr *SMP) {
+D = SMP->GetMessage(Loc, SourceMgr::DK_Note, Msg);
+  });
+}
+
 void MCContext::reportFatalError(SMLoc Loc, const Twine &Msg) {
   reportError(Loc, Msg);
 
Index: llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
+++ llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
@@ -542,8 +542,8

[clang] dfc1e31 - Produce warning for performing pointer arithmetic on a null pointer.

2021-05-11 Thread Jamie Schmeiser via cfe-commits 

Author: Jamie Schmeiser
Date: 2021-05-11T11:29:50-04:00
New Revision: dfc1e31d49fe1380c9bab43373995df5fed15e6d

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

LOG: Produce warning for performing pointer arithmetic on a null pointer.

Summary:
Test and produce warning for subtracting a pointer from null or subtracting
null from a pointer.  Reuse existing warning that this is undefined
behaviour.  Also add unit test for both warnings.

Reformat to satisfy clang-format.

Respond to review comments:  add additional test.

Respond to review comments:  Do not issue warning for nullptr - nullptr
in C++.

Fix indenting to satisfy clang-format.

Respond to review comments:  Add C++ tests.

Author: Jamie Schmeiser 
Reviewed By: efriedma (Eli Friedman), nickdesaulniers (Nick Desaulniers)
Differential Revision: https://reviews.llvm.org/D98798

Added: 
clang/test/Sema/pointer-addition.cpp

Modified: 
clang/lib/Sema/SemaExpr.cpp
clang/test/Sema/pointer-addition.c

Removed: 




diff  --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index 73d7675eb189f..1390c17de9ece 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -10779,7 +10779,17 @@ QualType Sema::CheckSubtractionOperands(ExprResult 
&LHS, ExprResult &RHS,
LHS.get(), RHS.get()))
 return QualType();
 
-  // FIXME: Add warnings for nullptr - ptr.
+  bool LHSIsNullPtr = LHS.get()->IgnoreParenCasts()->isNullPointerConstant(
+  Context, Expr::NPC_ValueDependentIsNotNull);
+  bool RHSIsNullPtr = RHS.get()->IgnoreParenCasts()->isNullPointerConstant(
+  Context, Expr::NPC_ValueDependentIsNotNull);
+
+  // Subtracting nullptr or from nullptr should produce
+  // a warning expect nullptr - nullptr is valid in C++ [expr.add]p7
+  if (LHSIsNullPtr && (!getLangOpts().CPlusPlus || !RHSIsNullPtr))
+diagnoseArithmeticOnNullPointer(*this, Loc, LHS.get(), false);
+  if (RHSIsNullPtr && (!getLangOpts().CPlusPlus || !LHSIsNullPtr))
+diagnoseArithmeticOnNullPointer(*this, Loc, RHS.get(), false);
 
   // The pointee type may have zero size.  As an extension, a structure or
   // union may have zero size or an array may have zero length.  In this

diff  --git a/clang/test/Sema/pointer-addition.c 
b/clang/test/Sema/pointer-addition.c
index 562f05340f7cb..ab641bd132363 100644
--- a/clang/test/Sema/pointer-addition.c
+++ b/clang/test/Sema/pointer-addition.c
@@ -29,4 +29,7 @@ void a(S* b, void* c) {
   // Cases that don't match the GNU inttoptr idiom get a 
diff erent warning.
   f = (char*)0 - i; // expected-warning {{performing pointer arithmetic on a 
null pointer has undefined behavior}}
   int *g = (int*)0 + i; // expected-warning {{performing pointer arithmetic on 
a null pointer has undefined behavior}}
+  f = (char*)((char*)0 - f); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
+  f = (char*)(f - (char*)0); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
+  f = (char*)((char*)0 - (char*)0); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}} expected-warning 
{{performing pointer arithmetic on a null pointer has undefined behavior}}
 }

diff  --git a/clang/test/Sema/pointer-addition.cpp 
b/clang/test/Sema/pointer-addition.cpp
new file mode 100644
index 0..5e09034ed9651
--- /dev/null
+++ b/clang/test/Sema/pointer-addition.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify -pedantic -Wextra -std=c++11
+
+void a() {
+  char *f = (char*)0;
+  f = (char*)((char*)0 - f); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
+  f = (char*)(f - (char*)0); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
+  f = (char*)((char*)0 - (char*)0); // valid in C++
+}



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

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

2021-05-11 Thread Jamie Schmeiser via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rGdfc1e31d49fe: Produce warning for performing pointer 
arithmetic on a null pointer. (authored by jamieschmeiser).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98798

Files:
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/pointer-addition.c
  clang/test/Sema/pointer-addition.cpp


Index: clang/test/Sema/pointer-addition.cpp
===
--- /dev/null
+++ clang/test/Sema/pointer-addition.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify -pedantic -Wextra -std=c++11
+
+void a() {
+  char *f = (char*)0;
+  f = (char*)((char*)0 - f); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
+  f = (char*)(f - (char*)0); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
+  f = (char*)((char*)0 - (char*)0); // valid in C++
+}
Index: clang/test/Sema/pointer-addition.c
===
--- clang/test/Sema/pointer-addition.c
+++ clang/test/Sema/pointer-addition.c
@@ -29,4 +29,7 @@
   // Cases that don't match the GNU inttoptr idiom get a different warning.
   f = (char*)0 - i; // expected-warning {{performing pointer arithmetic on a 
null pointer has undefined behavior}}
   int *g = (int*)0 + i; // expected-warning {{performing pointer arithmetic on 
a null pointer has undefined behavior}}
+  f = (char*)((char*)0 - f); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
+  f = (char*)(f - (char*)0); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}}
+  f = (char*)((char*)0 - (char*)0); // expected-warning {{performing pointer 
arithmetic on a null pointer has undefined behavior}} expected-warning 
{{performing pointer arithmetic on a null pointer has undefined behavior}}
 }
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -10779,7 +10779,17 @@
LHS.get(), RHS.get()))
 return QualType();
 
-  // FIXME: Add warnings for nullptr - ptr.
+  bool LHSIsNullPtr = LHS.get()->IgnoreParenCasts()->isNullPointerConstant(
+  Context, Expr::NPC_ValueDependentIsNotNull);
+  bool RHSIsNullPtr = RHS.get()->IgnoreParenCasts()->isNullPointerConstant(
+  Context, Expr::NPC_ValueDependentIsNotNull);
+
+  // Subtracting nullptr or from nullptr should produce
+  // a warning expect nullptr - nullptr is valid in C++ [expr.add]p7
+  if (LHSIsNullPtr && (!getLangOpts().CPlusPlus || !RHSIsNullPtr))
+diagnoseArithmeticOnNullPointer(*this, Loc, LHS.get(), false);
+  if (RHSIsNullPtr && (!getLangOpts().CPlusPlus || !LHSIsNullPtr))
+diagnoseArithmeticOnNullPointer(*this, Loc, RHS.get(), false);
 
   // The pointee type may have zero size.  As an extension, a structure or
   // union may have zero size or an array may have zero length.  In this


Index: clang/test/Sema/pointer-addition.cpp
===
--- /dev/null
+++ clang/test/Sema/pointer-addition.cpp
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify -pedantic -Wextra -std=c++11
+
+void a() {
+  char *f = (char*)0;
+  f = (char*)((char*)0 - f); // expected-warning {{performing pointer arithmetic on a null pointer has undefined behavior}}
+  f = (char*)(f - (char*)0); // expected-warning {{performing pointer arithmetic on a null pointer has undefined behavior}}
+  f = (char*)((char*)0 - (char*)0); // valid in C++
+}
Index: clang/test/Sema/pointer-addition.c
===
--- clang/test/Sema/pointer-addition.c
+++ clang/test/Sema/pointer-addition.c
@@ -29,4 +29,7 @@
   // Cases that don't match the GNU inttoptr idiom get a different warning.
   f = (char*)0 - i; // expected-warning {{performing pointer arithmetic on a null pointer has undefined behavior}}
   int *g = (int*)0 + i; // expected-warning {{performing pointer arithmetic on a null pointer has undefined behavior}}
+  f = (char*)((char*)0 - f); // expected-warning {{performing pointer arithmetic on a null pointer has undefined behavior}}
+  f = (char*)(f - (char*)0); // expected-warning {{performing pointer arithmetic on a null pointer has undefined behavior}}
+  f = (char*)((char*)0 - (char*)0); // expected-warning {{performing pointer arithmetic on a null pointer has undefined behavior}} expected-warning {{performing pointer arithmetic on a null pointer has undefined behavior}}
 }
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp

[PATCH] D101479: [Driver] Support libc++ in MSVC

2021-05-11 Thread Adrian McCarthy via Phabricator via cfe-commits 
amccarth added a comment.

In D101479#2748475 , @mstorsjo wrote:

> In D101479#2748189 , @amccarth 
> wrote:
>
>> In D101479#2733354 , @mstorsjo 
>> wrote:
>>
>>> Not sure if we want the desicion between static and shared libc++ be 
>>> coupled with `/MT` and `/MD`, as one can quite plausibly want to use e.g. a 
>>> static libc++ with `/MD`.
>>
>> I don't understand this.  When would someone want to use `/MD` and not get 
>> the DLL version of the run-time libraries?
>
> Whether one wants to link against the CRT statically or dynamically, and 
> libc++ statically or dynamically, are two entirely separate things. I would 
> e.g. expect that Chrome is built with a statically linked libc++ but linked 
> against the dynamic CRT.

Ah, thanks for explaining that!  In the VC++ stack, `/MD` and `/MT` make the 
DLL/static choice for the CRT, the C++ standard library, and the compiler 
runtime.[1]  It never occurred to me that someone might want to select these 
independently.

[1]:  
https://docs.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features?view=msvc-160


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101479

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

[PATCH] D102244: [llvm][AsmPrinter] Restore source location to register clobber warning

2021-05-11 Thread David Spickett via Phabricator via cfe-commits 
DavidSpickett added a reviewer: ychen.
DavidSpickett added a comment.

This works as expected, let me know if this is the intended use relative to the 
changes you made.

The existing test in llvm `llvm/test/CodeGen/AArch64/inline-asm-clobber.ll` 
never reported the location in the .ll file so I can't test it there. (which 
might be its own issue) I looked for any similar tests but didn't find 
anything, testing from clang with a C file seems like the only way.




Comment at: clang/test/Misc/inline-asm-clobber-warning.c:26
+// CHECK-NEXT: nop
+// CHECK-NEXT: ^

I think this `^` is wrong because we don't/can't account for the asm printer 
tabbing in the instruction.

I still wanted to check that there are `^` just because it's one aspect of the 
location information.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102244

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

[PATCH] D101519: [C++4OpenCL] Fix reinterpret_cast of vectors

2021-05-11 Thread Ole Strohm via Phabricator via cfe-commits 
olestrohm updated this revision to Diff 344408.
olestrohm added a comment.

I tried to add a special case for 3 and 4 element vectors, but that caused 
issues in codgen, so I've left it as a FIXME for now.


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

https://reviews.llvm.org/D101519

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CodeGenOpenCLCXX/reinterpret_cast.clcpp
  clang/test/SemaOpenCLCXX/reinterpret-cast.clcpp

Index: clang/test/SemaOpenCLCXX/reinterpret-cast.clcpp
===
--- /dev/null
+++ clang/test/SemaOpenCLCXX/reinterpret-cast.clcpp
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 %s -pedantic -verify -fsyntax-only
+
+typedef int int2 __attribute__((ext_vector_type(2)));
+typedef int int3 __attribute__((ext_vector_type(3)));
+typedef int int4 __attribute__((ext_vector_type(4)));
+
+kernel void foo() {
+  long l1;
+  auto l_to_i2 = reinterpret_cast(l1);
+  int2 i2;
+  auto i2_to_l = reinterpret_cast(i2);
+  auto i2_to_i = reinterpret_cast(i2); // expected-error{{reinterpret_cast from vector 'int2' (vector of 2 'int' values) to scalar 'int' of different size}}
+
+  reserve_id_t r_id1;
+  auto r_id2 = reinterpret_cast(r_id1); // expected-error{{reinterpret_cast from 'reserve_id_t' to 'reserve_id_t' is not allowed}}
+}
Index: clang/test/CodeGenOpenCLCXX/reinterpret_cast.clcpp
===
--- /dev/null
+++ clang/test/CodeGenOpenCLCXX/reinterpret_cast.clcpp
@@ -0,0 +1,17 @@
+//RUN: %clang_cc1 %s -triple spir -emit-llvm -O0 -o - | FileCheck %s
+
+typedef int int2 __attribute__((ext_vector_type(2)));
+typedef int int4 __attribute__((ext_vector_type(4)));
+typedef long long2 __attribute__((ext_vector_type(2)));
+
+//CHECK-LABEL: define{{.*}} spir_func void @_Z3barPU3AS1Dv2_i
+void bar(global int2 *in) {
+  //CHECK: bitcast <2 x i32> %{{[0-9]+}} to i64
+  auto l = reinterpret_cast(in[0]);
+  //CHECK: bitcast i64 %{{[0-9]+}} to <2 x i32>
+  auto i2 = reinterpret_cast(l);
+
+  int4 i4;
+  //CHECK: bitcast <4 x i32> %{{[0-9]+}} to <2 x i64>
+  auto l2 = reinterpret_cast(i4);
+}
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -7344,6 +7344,25 @@
  matSrcType->getNumColumns() == matDestType->getNumColumns();
 }
 
+bool Sema::areVectorTypesSameSize(QualType srcTy, QualType destTy) {
+  assert(destTy->isVectorType() || srcTy->isVectorType());
+
+  uint64_t srcLen, destLen;
+  QualType srcEltTy, destEltTy;
+  if (!breakDownVectorType(srcTy, srcLen, srcEltTy))
+return false;
+  if (!breakDownVectorType(destTy, destLen, destEltTy))
+return false;
+
+  // ASTContext::getTypeSize will return the size rounded up to a
+  // power of 2, so instead of using that, we need to use the raw
+  // element size multiplied by the element count.
+  uint64_t srcEltSize = Context.getTypeSize(srcEltTy);
+  uint64_t destEltSize = Context.getTypeSize(destEltTy);
+
+  return (srcLen * srcEltSize == destLen * destEltSize);
+}
+
 /// Are the two types lax-compatible vector types?  That is, given
 /// that one of them is a vector, do they have equal storage sizes,
 /// where the storage size is the number of elements times the element
@@ -7362,18 +7381,7 @@
   if (srcTy->isScalarType() && destTy->isExtVectorType()) return false;
   if (destTy->isScalarType() && srcTy->isExtVectorType()) return false;
 
-  uint64_t srcLen, destLen;
-  QualType srcEltTy, destEltTy;
-  if (!breakDownVectorType(srcTy, srcLen, srcEltTy)) return false;
-  if (!breakDownVectorType(destTy, destLen, destEltTy)) return false;
-
-  // ASTContext::getTypeSize will return the size rounded up to a
-  // power of 2, so instead of using that, we need to use the raw
-  // element size multiplied by the element count.
-  uint64_t srcEltSize = Context.getTypeSize(srcEltTy);
-  uint64_t destEltSize = Context.getTypeSize(destEltTy);
-
-  return (srcLen * srcEltSize == destLen * destEltSize);
+  return areVectorTypesSameSize(srcTy, destTy);
 }
 
 /// Is this a legal conversion between two types, one of which is
Index: clang/lib/Sema/SemaCast.cpp
===
--- clang/lib/Sema/SemaCast.cpp
+++ clang/lib/Sema/SemaCast.cpp
@@ -2328,6 +2328,16 @@
   return TC_Success;
 }
 
+if (Self.LangOpts.OpenCL && !CStyle) {
+  if (DestType->isExtVectorType() || SrcType->isExtVectorType()) {
+// FIXME: Allow for reinterpret cast between 3 and 4 element vectors
+if (Self.areVectorTypesSameSize(SrcType, DestType)) {
+  Kind = CK_BitCast;
+  return TC_Success;
+}
+  }
+}
+
 // Otherwise, pick a reasonable diagnostic.
 if (!destIsVector)
   msg = diag::err_bad_cxx_cast_vector_to_scalar_different_size;
Index: clang/include/clang/Sema/Sema.h

[PATCH] D101479: [Driver] Support libc++ in MSVC

2021-05-11 Thread Martin Storsjö via Phabricator via cfe-commits 
mstorsjo added a comment.

In D101479#2750765 , @amccarth wrote:

> Ah, thanks for explaining that!  In the VC++ stack, `/MD` and `/MT` make the 
> DLL/static choice for the CRT, the C++ standard library, and the compiler 
> runtime.[1]  It never occurred to me that someone might want to select these 
> independently.

Yup. As those components come from a different vendor than libc++, and have 
different distribution strategies/policies (and since there's some amount of 
shared global state in the CRT, which further affect how one can/should use it) 
one may want to link them in different ways.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101479

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

[PATCH] D101935: [clang] Search runtimes build tree for openmp runtime

2021-05-11 Thread Jon Chesterfield via Phabricator via cfe-commits 
JonChesterfield added a comment.

I'm not so sure about that. With the other stuff in flight, it would let us 
build openmp apps from the clang build directory. That's useful for quicker 
build/debug cycles, as well as for lit tests that can be run by copying into a 
shell. At zero runtime cost when the library is found elsewhere, and trivial 
extra code in the driver.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101935

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

[PATCH] D102238: [TableGen] [Clang] Clean up arm_mve.td file

2021-05-11 Thread Simon Tatham via Phabricator via cfe-commits 
simon_tatham added a comment.

For example, that's how I tested the refactoring in D72690 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102238

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

[PATCH] D102248: [C++4OpenCL] Fix initialization of __constant constructors without arguments

2021-05-11 Thread Ole Strohm via Phabricator via cfe-commits 
olestrohm created this revision.
olestrohm added reviewers: Anastasia, svenvh.
olestrohm added a project: clang.
Herald added subscribers: ldrumm, yaxunl.
olestrohm requested review of this revision.
Herald added a subscriber: cfe-commits.

This fixes the implicit initialization that uses constructors in the __constant 
address space without arguments.

It also adds several tests to make sure that constructors in other address 
spaces also work, since these have not yet been tested.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102248

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaOpenCLCXX/addrspace-constructors.clcpp


Index: clang/test/SemaOpenCLCXX/addrspace-constructors.clcpp
===
--- /dev/null
+++ clang/test/SemaOpenCLCXX/addrspace-constructors.clcpp
@@ -0,0 +1,44 @@
+// RUN: %clang_cc1 %s -pedantic -verify -fsyntax-only
+
+__constant int g1; // expected-error {{variable in constant address space must 
be initialized}}
+__constant int g2 = 0;
+
+struct X {
+  int x;
+  constexpr X() __constant : x(0) {}
+  constexpr X(int x) __constant : x(x) {}
+};
+
+//expected-note@+2{{candidate constructor (the implicit copy constructor) not 
viable: no known conversion from 'int' to 'const __generic Y' for 1st argument}}
+//expected-note@+1{{candidate constructor (the implicit move constructor) not 
viable: no known conversion from 'int' to '__generic Y' for 1st argument}}
+struct Y {
+  int y;
+  Y() __generic = default; // expected-note{{candidate constructor not viable: 
requires 0 arguments, but 1 was provided}}
+};
+
+kernel void k() {
+  __constant X cx1;
+  __constant X cx2(1);
+  __local X lx;
+
+  __private Y py;
+  __constant Y cy1; // expected-error{{variable in constant address space must 
be initialized}}
+  __constant Y cy2(1); // expected-error{{no matching constructor for 
initialization of '__constant Y'}}
+}
+
+struct Z {
+  int z;
+  Z() = default; // expected-note{{previous definition is here}}
+  Z() __generic = default; // expected-error {{constructor cannot be 
redeclared}}
+
+  Z() __private = default;
+  Z() __local = default;
+  Z() __global = default;
+  constexpr Z() __constant : z(0) {}
+};
+
+struct W {
+  int w;
+  constexpr W() __constant = default; // expected-error {{defaulted definition 
of default constructor is not constexpr}}
+};
+
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -12638,9 +12638,21 @@
 if (!Var->isInvalidDecl() &&
 Var->getType().getAddressSpace() == LangAS::opencl_constant &&
 Var->getStorageClass() != SC_Extern && !Var->getInit()) {
-  Diag(Var->getLocation(), diag::err_opencl_constant_no_init);
-  Var->setInvalidDecl();
-  return;
+  bool hasConstExprDefaultConstructor = false;
+  if (CXXRecordDecl *RD = Var->getType()->getAsCXXRecordDecl()) {
+for (auto *ctor : RD->ctors()) {
+  if (ctor->isConstexpr() && ctor->getNumParams() == 0 &&
+  ctor->getMethodQualifiers().getAddressSpace() ==
+  LangAS::opencl_constant) {
+hasConstExprDefaultConstructor = true;
+  }
+}
+  }
+  if (!hasConstExprDefaultConstructor) {
+Diag(Var->getLocation(), diag::err_opencl_constant_no_init);
+Var->setInvalidDecl();
+return;
+  }
 }
 
 if (!Var->isInvalidDecl() && RealDecl->hasAttr()) 
{


Index: clang/test/SemaOpenCLCXX/addrspace-constructors.clcpp
===
--- /dev/null
+++ clang/test/SemaOpenCLCXX/addrspace-constructors.clcpp
@@ -0,0 +1,44 @@
+// RUN: %clang_cc1 %s -pedantic -verify -fsyntax-only
+
+__constant int g1; // expected-error {{variable in constant address space must be initialized}}
+__constant int g2 = 0;
+
+struct X {
+  int x;
+  constexpr X() __constant : x(0) {}
+  constexpr X(int x) __constant : x(x) {}
+};
+
+//expected-note@+2{{candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const __generic Y' for 1st argument}}
+//expected-note@+1{{candidate constructor (the implicit move constructor) not viable: no known conversion from 'int' to '__generic Y' for 1st argument}}
+struct Y {
+  int y;
+  Y() __generic = default; // expected-note{{candidate constructor not viable: requires 0 arguments, but 1 was provided}}
+};
+
+kernel void k() {
+  __constant X cx1;
+  __constant X cx2(1);
+  __local X lx;
+
+  __private Y py;
+  __constant Y cy1; // expected-error{{variable in constant address space must be initialized}}
+  __constant Y cy2(1); // expected-error{{no matching constructor for initialization of '__constant Y'}}
+}
+
+struct Z {
+  int z;
+  Z() = default; // expected-note{{previous definition is here}}
+  Z() __generic = default; // expected-error {{constructor cannot be redeclared}}
+

[PATCH] D102064: Parse vector bool when stdbool.h and altivec.h are included

2021-05-11 Thread Zarko Todorovski via Phabricator via cfe-commits 
ZarkoCA updated this revision to Diff 344426.
ZarkoCA edited the summary of this revision.
ZarkoCA added reviewers: uweigand, neumannh.
ZarkoCA added a comment.

- clean up code per comments
- Add test case for Z targets since that target is also affected


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102064

Files:
  clang/include/clang/Parse/Parser.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/Parser.cpp
  clang/test/Parser/altivec-bool.c

Index: clang/test/Parser/altivec-bool.c
===
--- /dev/null
+++ clang/test/Parser/altivec-bool.c
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -triple=powerpc64-unknown-linux-gnu \
+// RUN:-target-feature +altivec -fsyntax-only %s
+// RUN: %clang_cc1 -triple=powerpc64le-unknown-linux-gnu \
+// RUN:-target-feature +altivec -fsyntax-only %s
+// RUN: %clang_cc1 -triple=powerpc64-ibm-aix-xcoff \
+// RUN:-target-feature +altivec -fsyntax-only %s
+// RUN: %clang_cc1 -triple=powerpc-ibm-aix-xcoff \
+// RUN:-target-feature +altivec -fsyntax-only %s
+// RUN: %clang_cc1 -triple=powerpc-unknown-linux-gnu \
+// RUN:-target-feature +altivec -fsyntax-only %s
+// RUN: %clang_cc1 -triple=s390x-linux-gnu -target-cpu arch11 \
+// RUN:-fzvector -fsyntax-only %s
+// RUN: %clang_cc1 -triple=s390x-ibm-zos -target-cpu arch11 \
+// RUN:-fzvector -fsyntax-only %s
+
+__vector bool char bc;
+__vector bool short bsh;
+__vector bool short int bshi;
+__vector bool int bi;
+__vector _Bool char bc;
+__vector _Bool short bsh;
+__vector _Bool short int bshi;
+__vector _Bool int bi;
Index: clang/lib/Parse/Parser.cpp
===
--- clang/lib/Parse/Parser.cpp
+++ clang/lib/Parse/Parser.cpp
@@ -503,10 +503,12 @@
 
   Ident_vector = nullptr;
   Ident_bool = nullptr;
+  Ident_Bool = nullptr;
   Ident_pixel = nullptr;
   if (getLangOpts().AltiVec || getLangOpts().ZVector) {
 Ident_vector = &PP.getIdentifierTable().get("vector");
 Ident_bool = &PP.getIdentifierTable().get("bool");
+Ident_Bool = &PP.getIdentifierTable().get("_Bool");
   }
   if (getLangOpts().AltiVec)
 Ident_pixel = &PP.getIdentifierTable().get("pixel");
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -7334,6 +7334,7 @@
   case tok::kw_float:
   case tok::kw_double:
   case tok::kw_bool:
+  case tok::kw__Bool:
   case tok::kw___bool:
   case tok::kw___pixel:
 Tok.setKind(tok::kw___vector);
@@ -7343,7 +7344,8 @@
   Tok.setKind(tok::kw___vector);
   return true;
 }
-if (Next.getIdentifierInfo() == Ident_bool) {
+if (Next.getIdentifierInfo() == Ident_bool ||
+Next.getIdentifierInfo() == Ident_Bool) {
   Tok.setKind(tok::kw___vector);
   return true;
 }
@@ -7368,6 +7370,7 @@
 case tok::kw_float:
 case tok::kw_double:
 case tok::kw_bool:
+case tok::kw__Bool:
 case tok::kw___bool:
 case tok::kw___pixel:
   isInvalid = DS.SetTypeAltiVecVector(true, Loc, PrevSpec, DiagID, Policy);
@@ -7377,8 +7380,10 @@
 isInvalid = DS.SetTypeAltiVecVector(true, Loc, PrevSpec, DiagID,Policy);
 return true;
   }
-  if (Next.getIdentifierInfo() == Ident_bool) {
-isInvalid = DS.SetTypeAltiVecVector(true, Loc, PrevSpec, DiagID,Policy);
+  if (Next.getIdentifierInfo() == Ident_bool ||
+  Next.getIdentifierInfo() == Ident_Bool) {
+isInvalid =
+DS.SetTypeAltiVecVector(true, Loc, PrevSpec, DiagID, Policy);
 return true;
   }
   break;
Index: clang/include/clang/Parse/Parser.h
===
--- clang/include/clang/Parse/Parser.h
+++ clang/include/clang/Parse/Parser.h
@@ -118,10 +118,12 @@
   /// Ident_super - IdentifierInfo for "super", to support fast
   /// comparison.
   IdentifierInfo *Ident_super;
-  /// Ident_vector, Ident_bool - cached IdentifierInfos for "vector" and
-  /// "bool" fast comparison.  Only present if AltiVec or ZVector are enabled.
+  /// Ident_vector, Ident_bool, Ident_Bool - cached IdentifierInfos for "vector"
+  /// and "bool" fast comparison.  Only present if AltiVec or ZVector are
+  /// enabled.
   IdentifierInfo *Ident_vector;
   IdentifierInfo *Ident_bool;
+  IdentifierInfo *Ident_Bool;
   /// Ident_pixel - cached IdentifierInfos for "pixel" fast comparison.
   /// Only present if AltiVec enabled.
   IdentifierInfo *Ident_pixel;
@@ -879,6 +881,7 @@
 
 if (Tok.getIdentifierInfo() != Ident_vector &&
 Tok.getIdentifierInfo() != Ident_bool &&
+Tok.getIdentifierInfo() != Ident_Bool &&
 (!getLangOpts().AltiVec || Tok.getIdentifierInfo() != Ident_pixel))
   return false;
 
__

[PATCH] D102064: Parse vector bool when stdbool.h and altivec.h are included

2021-05-11 Thread Neumann Hon via Phabricator via cfe-commits 
Everybody0523 added a comment.

Minor nitpick, but is there a term that encompasses both the Z Vector syntax 
and altivec? Since the test checks both Z and PPC it's a little odd that the 
test's filename only references altivec.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102064

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

[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

2021-05-11 Thread Douglas Chen via Phabricator via cfe-commits 
dougpuob added a comment.

Hi @njames93:
Could you do me a favor? Because it is my first patch, something I'm not sure. 
I'm confused about can I land this patch now? I read the "LLVM Code-Review 
Policy and Practices" document, it said patches can be landed if received a 
LGTM, but seems you are still reviewing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86671

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

[PATCH] D102240: [analyzer][solver] Prevent use of a null state

2021-05-11 Thread Balázs Benics via Phabricator via cfe-commits 
steakhal added a comment.

Dam, we will be always haunted by these.
Looks good btw.
The test looks somewhat artificial - like a raw `creduce` result.

Do you think It worth the effort to make it look like it was written by a human?
I also somewhy prefer function parameters to globals for this specific use-case.

This seems to depend on the `-analyzer-config eagerly-assume=true`. We should 
probably add this option explicitly, just in case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102240

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

[PATCH] D100991: Fix parsing of vector keyword in presence of conflicting uses.

2021-05-11 Thread Jamie Schmeiser via Phabricator via cfe-commits 
jamieschmeiser added a comment.

ping


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

https://reviews.llvm.org/D100991

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

[PATCH] D102064: Parse vector bool when stdbool.h and altivec.h are included

2021-05-11 Thread Ulrich Weigand via Phabricator via cfe-commits 
uweigand added a comment.

This means the implementation now deviates from the documented vector extension 
syntax, right?   I guess it's strictly an extension of the documented syntax, 
but that may still lead to incompatibilities with other compilers for the 
platform.  If we want to make such a change, should it be synchronized with 
e.g. GCC, XL, etc. ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102064

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

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

2021-05-11 Thread Sanne Wouda via Phabricator via cfe-commits 
sanwou01 added subscribers: dmgreen, sanwou01.
sanwou01 added a comment.

Hi, we've got a ~6% regression in SPEC INT 2006 462.libquantum on AArch64 (both 
-flto and -Ofast) that comes back to this change. See here for a reproducer 
https://godbolt.org/z/dq98Gqqxn (-fno-vectorize is not strictly necessary, but 
it does make the difference easier to spot).  @dmgreen mentioned to me that we 
could probably fix this up in the AArch64 backend, but a fix in the mid-end 
might be more generally useful too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101191

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

[PATCH] D102251: Suppress Deferred Diagnostics in discarded statements.

2021-05-11 Thread Erich Keane via Phabricator via cfe-commits 
erichkeane created this revision.
erichkeane added reviewers: yaxunl, bader, ABataev, aaron.ballman.
erichkeane requested review of this revision.
Herald added a project: clang.

It doesn't really make sense to emit language specific diagnostics
in a discarded statement, and suppressing these diagnostics results in a
programming pattern that many users will feel is quite useful.

Basically, this makes sure we only emit errors from the 'true' side of a
'constexpr if'.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102251

Files:
  clang/include/clang/AST/Stmt.h
  clang/lib/AST/Stmt.cpp
  clang/lib/Sema/Sema.cpp
  clang/test/SemaCUDA/deferred-diags.cu

Index: clang/test/SemaCUDA/deferred-diags.cu
===
--- clang/test/SemaCUDA/deferred-diags.cu
+++ clang/test/SemaCUDA/deferred-diags.cu
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fcxx-exceptions -fcuda-is-device -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fcxx-exceptions -fcuda-is-device -fsyntax-only -std=c++17 -verify %s
 
 #include "Inputs/cuda.h"
 
@@ -8,29 +8,55 @@
   // expected-error@-1 2{{cannot use 'throw' in __host__ __device__ function}}
 }
 
+inline __host__ __device__ void hasInvalid2() {
+  throw NULL;
+  // expected-error@-1 2{{cannot use 'throw' in __host__ __device__ function}}
+}
+
+inline __host__ __device__ void hasInvalidDiscarded() {
+  // This is only used in the discarded statements below, so this should not diagnose.
+  throw NULL;
+}
+
 static __device__ void use0() {
   hasInvalid(); // expected-note {{called by 'use0'}}
   hasInvalid(); // expected-note {{called by 'use0'}}
+
+  if constexpr (true) {
+hasInvalid2(); // expected-note {{called by 'use0'}}
+  } else {
+hasInvalidDiscarded();
+  }
+
+  if constexpr (false) {
+hasInvalidDiscarded();
+  } else {
+hasInvalid2(); // expected-note {{called by 'use0'}}
+  }
+
+  if constexpr (false) {
+hasInvalidDiscarded();
+  }
 }
 
 // To avoid excessive diagnostic messages, deferred diagnostics are only
 // emitted the first time a function is called.
 static __device__ void use1() {
-  use0(); // expected-note 2{{called by 'use1'}}
+  use0(); // expected-note 4{{called by 'use1'}}
   use0();
 }
 
 static __device__ void use2() {
-  use1(); // expected-note 2{{called by 'use2'}}
+  use1(); // expected-note 4{{called by 'use2'}}
   use1();
 }
 
 static __device__ void use3() {
-  use2(); // expected-note 2{{called by 'use3'}}
+  use2(); // expected-note 4{{called by 'use3'}}
   use2();
 }
 
 __global__ void use4() {
-  use3(); // expected-note 2{{called by 'use4'}}
+  use3(); // expected-note 4{{called by 'use4'}}
   use3();
 }
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -1666,6 +1666,18 @@
   }
 }
   }
+
+  void VisitIfStmt(IfStmt *If) {
+// Only evaluate the non-discarded side of a constexpr-if.
+if (Optional SubStmt = If->getNondiscardedCase(S.Context)) {
+  // The non-discarded statement could can be a non-existent 'else', so make
+  // sure we don't try to visit it.
+  if (*SubStmt)
+Inherited::Visit(*SubStmt);
+} else {
+  Inherited::VisitStmt(If);
+}
+  }
 };
 } // namespace
 
Index: clang/lib/AST/Stmt.cpp
===
--- clang/lib/AST/Stmt.cpp
+++ clang/lib/AST/Stmt.cpp
@@ -989,12 +989,20 @@
   return isa(getCond());
 }
 
-Optional IfStmt::getNondiscardedCase(const ASTContext &Ctx) const {
+Optional IfStmt::getNondiscardedCase(const ASTContext &Ctx) {
   if (!isConstexpr() || getCond()->isValueDependent())
 return None;
   return !getCond()->EvaluateKnownConstInt(Ctx) ? getElse() : getThen();
 }
 
+Optional
+IfStmt::getNondiscardedCase(const ASTContext &Ctx) const {
+  if (Optional Result =
+  const_cast(this)->getNondiscardedCase(Ctx))
+return *Result;
+  return None;
+}
+
 ForStmt::ForStmt(const ASTContext &C, Stmt *Init, Expr *Cond, VarDecl *condVar,
  Expr *Inc, Stmt *Body, SourceLocation FL, SourceLocation LP,
  SourceLocation RP)
Index: clang/include/clang/AST/Stmt.h
===
--- clang/include/clang/AST/Stmt.h
+++ clang/include/clang/AST/Stmt.h
@@ -2080,6 +2080,7 @@
   /// If this is an 'if constexpr', determine which substatement will be taken.
   /// Otherwise, or if the condition is value-dependent, returns None.
   Optional getNondiscardedCase(const ASTContext &Ctx) const;
+  Optional getNondiscardedCase(const ASTContext &Ctx);
 
   bool isObjCAvailabilityCheck() const;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101191: [InstCombine] Fully disable select to and/or i1 folding

2021-05-11 Thread Nikita Popov via Phabricator via cfe-commits 
nikic added a comment.

In D101191#2751002 , @sanwou01 wrote:

> Hi, we've got a ~6% regression in SPEC INT 2006 462.libquantum on AArch64 
> (both -flto and -Ofast) that comes back to this change. See here for a 
> reproducer https://godbolt.org/z/dq98Gqqxn (-fno-vectorize is not strictly 
> necessary, but it does make the difference easier to spot).  @dmgreen 
> mentioned to me that we could probably fix this up in the AArch64 backend, 
> but a fix in the mid-end might be more generally useful too.

Thanks for the report! This looks like the "one hot merge" optimization, which 
is indeed disabled by this patch, because it is incorrect in the current form 
(onehot_merge.ll). We can bring back this optimization in InstCombine, but need 
to freeze one of the operands (c2 in your example).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101191

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

[PATCH] D99797: [analyzer] Implemented RangeSet::Factory::unite function to handle intersections and adjacency

2021-05-11 Thread Denys Petrov via Phabricator via cfe-commits 
ASDenysPetrov updated this revision to Diff 34.
ASDenysPetrov added a comment.

Minor performance improvement. Add more comments.


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

https://reviews.llvm.org/D99797

Files:
  
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/unittests/StaticAnalyzer/RangeSetTest.cpp

Index: clang/unittests/StaticAnalyzer/RangeSetTest.cpp
===
--- clang/unittests/StaticAnalyzer/RangeSetTest.cpp
+++ clang/unittests/StaticAnalyzer/RangeSetTest.cpp
@@ -61,6 +61,9 @@
   static constexpr BaseType getMax() {
 return std::numeric_limits::max();
   }
+  // MID is a value in the middle of the range
+  // which unary minus does not affect on,
+  // e.g. int8/int32(0), uint8(128), uint32(2147483648).
   static constexpr BaseType getMid() {
 return isSigned() ? 0 : ~(fromInt(-1) / fromInt(2));
   }
@@ -160,7 +163,7 @@
 
   void checkAdd(RawRangeSet RawLHS, RawRangeSet RawRHS,
 RawRangeSet RawExpected) {
-wrap(&Self::checkAddImpl, RawRHS, RawLHS, RawExpected);
+wrap(&Self::checkAddImpl, RawLHS, RawRHS, RawExpected);
   }
 
   void checkAdd(RawRangeSet RawLHS, BaseType RawRHS, RawRangeSet RawExpected) {
@@ -168,6 +171,29 @@
  RawExpected);
   }
 
+  template 
+  void checkUniteImpl(RangeSet LHS, RHSType RHS, RangeSet Expected) {
+RangeSet Result = F.unite(LHS, RHS);
+EXPECT_EQ(Result, Expected)
+<< "while uniting " << toString(LHS) << " and " << toString(RHS);
+  }
+
+  void checkUnite(RawRangeSet RawLHS, RawRange RawRHS,
+  RawRangeSet RawExpected) {
+wrap(&Self::checkUniteImpl, RawLHS, RawRHS, RawExpected);
+  }
+
+  void checkUnite(RawRangeSet RawLHS, RawRangeSet RawRHS,
+  RawRangeSet RawExpected) {
+wrap(&Self::checkUniteImpl, RawLHS, RawRHS, RawExpected);
+  }
+
+  void checkUnite(RawRangeSet RawLHS, BaseType RawRHS,
+  RawRangeSet RawExpected) {
+wrap(&Self::checkUniteImpl, RawLHS, RawRHS,
+ RawExpected);
+  }
+
   void checkDeleteImpl(const llvm::APSInt &Point, RangeSet From,
RangeSet Expected) {
 RangeSet Result = F.deletePoint(From, Point);
@@ -195,9 +221,6 @@
 
   constexpr TypeParam MIN = TestFixture::getMin();
   constexpr TypeParam MAX = TestFixture::getMax();
-  // MID is a value in the middle of the range
-  // which unary minus does not affect on,
-  // e.g. int8/int32(0), uint8(128), uint32(2147483648).
   constexpr TypeParam MID = TestFixture::getMid();
   constexpr TypeParam A = MID - TestFixture::fromInt(42 + 42);
   constexpr TypeParam B = MID - TestFixture::fromInt(42);
@@ -347,3 +370,201 @@
   // Check that delete of the point not from the range set works as expected.
   this->checkDelete(10, {{0, 5}, {20, 30}}, {{0, 5}, {20, 30}});
 }
+
+TYPED_TEST(RangeSetTest, RangeSetUniteTest) {
+
+  // Use next values of the range {MIN, A, B, MID, C, D, MAX}.
+  constexpr TypeParam MIN = TestFixture::getMin();
+  constexpr TypeParam MAX = TestFixture::getMax();
+  constexpr TypeParam MID = TestFixture::getMid();
+  constexpr TypeParam A = MID - TestFixture::fromInt(42 + 42);
+  constexpr TypeParam B = MID - TestFixture::fromInt(42);
+  constexpr TypeParam C = -B;
+  constexpr TypeParam D = -A;
+
+  // LHS and RHS is empty.
+  // RHS =>
+  // LHS => =
+  //___   ___
+  this->checkUnite({}, {}, {});
+
+  // RHS is empty.
+  // RHS =>
+  // LHS =>_=_
+  //__/_\__   __/_\__
+  this->checkUnite({{A, B}}, {}, {{A, B}});
+  this->checkUnite({{A, B}, {C, D}}, {}, {{A, B}, {C, D}});
+
+  // LHS is empty.
+  // RHS => ___
+  // LHS =>/   \=_
+  //__/_\__   __/_\__
+  this->checkUnite({}, B, {{B, B}});
+  this->checkUnite({}, {B, C}, {{B, C}});
+  this->checkUnite({}, {{MIN, B}, {C, MAX}}, {{MIN, B}, {C, MAX}});
+
+  // RHS is detached from LHS.
+  // RHS => ___
+  // LHS =>___ /   \=___ _
+  //__/___\___/_\__   __/___\___/_\__
+  this->checkUnite({{A, C}}, D, {{A, C}, {D, D}});
+  this->checkUnite({{MID, C}, {D, MAX}}, A, {{A, A}, {MID, C}, {D, MAX}});
+  this->checkUnite({{A, B}}, {MID, D}, {{A, B}, {MID, D}});
+  this->checkUnite({{MIN, A}, {D, MAX}}, {B, C}, {{MIN, A}, {B, C}, {D, MAX}});
+  this->checkUnite({{B, MID}, {D, MAX}}, {{MIN, A}, {C, C}},
+   {{MIN, A}, {B, MID}, {C, C}, {D, MAX}});
+  this->checkUnite({{MIN, A}, {C, C}}, {{B, MID}, {D, MAX}},
+   {{MIN, A}, {B, MID}, {C, C}, {D, MAX}});
+  this->checkUnite({{MAX, MAX}}, {A, B}, {{A, B}, {MAX, MAX}});
+  this->checkUnite({{MIN, MIN}}, {A, B}, {{MIN, MIN}, {A, B}});
+
+  // RHS is inside LHS.
+  // RHS => ___
+  // LHS

[PATCH] D102064: Parse vector bool when stdbool.h and altivec.h are included

2021-05-11 Thread Zarko Todorovski via Phabricator via cfe-commits 
ZarkoCA added a comment.

In D102064#2751001 , @uweigand wrote:

> This means the implementation now deviates from the documented vector 
> extension syntax, right?   I guess it's strictly an extension of the 
> documented syntax, but that may still lead to incompatibilities with other 
> compilers for the platform.  If we want to make such a change, should it be 
> synchronized with e.g. GCC, XL, etc. ?

GCC and XL already accept this syntax on Linux on Power and AIX.

For example this simple test case:

  #include 
  #include 
  
  vector bool char bc;

Can compile with GCC 9/10 and XLC 16.1 on Linux on Power. On AIX, GCC 8.3 on 
AIX and XLC 16.1 can also compile it successfully.  Latest main trunk clang 
throws up an error on those platforms.

From offline conversation it looks like XLC on z/OS can also compile the test 
case. @Everybody0523 can confirm for sure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102064

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

[PATCH] D102251: Suppress Deferred Diagnostics in discarded statements.

2021-05-11 Thread Alexey Bataev via Phabricator via cfe-commits 
ABataev added inline comments.



Comment at: clang/include/clang/AST/Stmt.h:2082-2083
   /// Otherwise, or if the condition is value-dependent, returns None.
   Optional getNondiscardedCase(const ASTContext &Ctx) const;
+  Optional getNondiscardedCase(const ASTContext &Ctx);
 

Do you really need `Optional` here? Just nullptr is not enough?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102251

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

[PATCH] D102064: Parse vector bool when stdbool.h and altivec.h are included

2021-05-11 Thread Zarko Todorovski via Phabricator via cfe-commits 
ZarkoCA added a comment.

In D102064#2750930 , @Everybody0523 
wrote:

> Minor nitpick, but is there a term that encompasses both the Z Vector syntax 
> and altivec? Since the test checks both Z and PPC it's a little odd that the 
> test's filename only references altivec.

That's a good point, I can rename the file to `altivec-zvector-bool.c`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102064

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

[PATCH] D86881: Make -fvisibility-inlines-hidden apply to static local variables in inline functions on Darwin

2021-05-11 Thread Fangrui Song via Phabricator via cfe-commits 
MaskRay added a comment.

Agreed. This feels like a workaround. Can the offending projects be fixed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86881

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

[PATCH] D102251: Suppress Deferred Diagnostics in discarded statements.

2021-05-11 Thread Erich Keane via Phabricator via cfe-commits 
erichkeane added inline comments.



Comment at: clang/include/clang/AST/Stmt.h:2082-2083
   /// Otherwise, or if the condition is value-dependent, returns None.
   Optional getNondiscardedCase(const ASTContext &Ctx) const;
+  Optional getNondiscardedCase(const ASTContext &Ctx);
 

ABataev wrote:
> Do you really need `Optional` here? Just nullptr is not enough?
Yes for 2 reasons:
1- This is the existing interface, I didn't see reason to change it.

2- Optional::None and nullptr are two different 'cases'.  None is returned here 
when this is not a constexpr-if.  Nullptr is returned in cases where it _IS_ a 
constexpr-if, but the nondiscarded case is not present.  For example:

if (foo) {} // Returns None.

if constexpr (false) {} // Returns nullptr.

if constexpr (false) else {} // Returns the 'else' compound statement.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102251

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

[PATCH] D102251: Suppress Deferred Diagnostics in discarded statements.

2021-05-11 Thread Alexey Bataev via Phabricator via cfe-commits 
ABataev accepted this revision.
ABataev added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102251

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

[PATCH] D98799: [UniqueLinkageName] Use consistent checks when mangling symbo linkage name and debug linkage name.

2021-05-11 Thread David Blaikie via Phabricator via cfe-commits 
dblaikie added inline comments.



Comment at: clang/test/CodeGen/unique-internal-linkage-names-dwarf.c:34-39
+static int go(a) int a;
+{
+  return glob + a;
+}
+
+

aaron.ballman wrote:
> dblaikie wrote:
> > aaron.ballman wrote:
> > > dblaikie wrote:
> > > > hoy wrote:
> > > > > dblaikie wrote:
> > > > > > dblaikie wrote:
> > > > > > > hoy wrote:
> > > > > > > > dblaikie wrote:
> > > > > > > > > hoy wrote:
> > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > hoy wrote:
> > > > > > > > > > > > > > > > > > dblaikie wrote:
> > > > > > > > > > > > > > > > > > > Does this need to be down here? Or would 
> > > > > > > > > > > > > > > > > > > the code be a well exercised if it was up 
> > > > > > > > > > > > > > > > > > > next to the go declaration above?
> > > > > > > > > > > > > > > > > > Yes, it needs to be here. Otherwise it will 
> > > > > > > > > > > > > > > > > > just like the function `bar` above that 
> > > > > > > > > > > > > > > > > > doesn't get a uniquefied name. I think 
> > > > > > > > > > > > > > > > > > moving the definition up to right after the 
> > > > > > > > > > > > > > > > > > declaration hides the declaration.
> > > > > > > > > > > > > > > > > Not sure I follow - do you mean that if the 
> > > > > > > > > > > > > > > > > go declaration and go definition were next to 
> > > > > > > > > > > > > > > > > each other, this test would (mechanically 
> > > > > > > > > > > > > > > > > speaking) not validate what the patch? Or 
> > > > > > > > > > > > > > > > > that it would be less legible, but still 
> > > > > > > > > > > > > > > > > mechanically correct?
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > I think it would be (assuming it's still 
> > > > > > > > > > > > > > > > > mechanically correct) more legible to put the 
> > > > > > > > > > > > > > > > > declaration next to the definition - the 
> > > > > > > > > > > > > > > > > comment describes why the declaration is 
> > > > > > > > > > > > > > > > > significant/why the definition is weird, and 
> > > > > > > > > > > > > > > > > seeing all that together would be clearer to 
> > > > > > > > > > > > > > > > > me than spreading it out/having to look 
> > > > > > > > > > > > > > > > > further away to see what's going on.
> > > > > > > > > > > > > > > > When the `go` declaration and `go` definition 
> > > > > > > > > > > > > > > > were next to each other, the go function won't 
> > > > > > > > > > > > > > > > get a uniqufied name at all. The declaration 
> > > > > > > > > > > > > > > > will be overwritten by the definition. Only 
> > > > > > > > > > > > > > > > when the declaration is seen by others, such 
> > > > > > > > > > > > > > > > the callsite in `baz`, the declaration makes a 
> > > > > > > > > > > > > > > > difference by having the callsite use a 
> > > > > > > > > > > > > > > > uniqufied name.
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Ah! Interesting, good to know. 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Is that worth supporting, I wonder? I guess it 
> > > > > > > > > > > > > > > falls out for free/without significant additional 
> > > > > > > > > > > > > > > complexity. I worry about the subtlety of the 
> > > > > > > > > > > > > > > additional declaration changing the behavior 
> > > > > > > > > > > > > > > here... might be a bit surprising/subtle. But 
> > > > > > > > > > > > > > > maybe no nice way to avoid it either.
> > > > > > > > > > > > > > It would be ideal if user never writes code like 
> > > > > > > > > > > > > > that. Unfortunately it exists with legacy code 
> > > > > > > > > > > > > > (such as mysql). I think it's worth supporting it 
> > > > > > > > > > > > > > from AutoFDO point of view to avoid a silent 
> > > > > > > > > > > > > > mismatch between debug linkage name and real 
> > > > > > > > > > > > > > linkage name.
> > > > > > > > > > > > > Oh, I agree that we shouldn't mismatch debug info and 
> > > > > > > > > > > > > the actual symbol name - what I meant was whether 
> > > > > > > > > > > > > code like this should get mangled or not when using 
> > > > > > > > > > > > > unique-internal-linkage names.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I'm now more curious about this:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > When the `go` declaration and `go` definition were 
> > > > > > > > > > > > > > next to each other, the go function won't get a 
> > > > > > > > > > > > > > uniqufied name at all.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > This doesn't seem to happen with the 
> > > > > > > > > > > > > `__attribute__((overloadable))` attribute, for 
> > > > > > > > > > > > > instance - so any idea what

[PATCH] D102064: Parse vector bool when stdbool.h and altivec.h are included

2021-05-11 Thread Ulrich Weigand via Phabricator via cfe-commits 
uweigand added a comment.

In D102064#2751089 , @ZarkoCA wrote:

> In D102064#2751001 , @uweigand 
> wrote:
>
>> This means the implementation now deviates from the documented vector 
>> extension syntax, right?   I guess it's strictly an extension of the 
>> documented syntax, but that may still lead to incompatibilities with other 
>> compilers for the platform.  If we want to make such a change, should it be 
>> synchronized with e.g. GCC, XL, etc. ?
>
> GCC and XL already accept this syntax on Linux on Power and AIX.
>
> For example this simple test case:
>
>   #include 
>   #include 
>   
>   vector bool char bc;
>
> Can compile with GCC 9/10 and XLC 16.1 on Linux on Power. On AIX, GCC 8.3 on 
> AIX and XLC 16.1 can also compile it successfully.  Latest main trunk clang 
> throws up an error on those platforms.
>
> From offline conversation it looks like XLC on z/OS can also compile the test 
> case. @Everybody0523 can confirm for sure.

Interesting.   On Z using GCC I currently get this error:

  vbool.c:2:1: error: invalid vector type for attribute ‘vector_size’
  2 | vector _Bool x;

But looking at the GCC sources, it seems we actually intended to support this 
use as well, there's just a bug.   Given that, I think I'd be fine with adding 
this to LLVM -- I'll make sure the GCC bug gets fixed as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102064

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

[PATCH] D102134: [docs]Updated the AMD GPU Attributes documentation

2021-05-11 Thread PoojaYadav via Phabricator via cfe-commits 
pooja2299 added a comment.

In D102134#2747649 , @aaron.ballman 
wrote:

> Minor wordsmithing on the documentation changes, but more importantly: why is 
> the correct fix to the documentation as opposed to changing the default max 
> working group size?

Hi @aaron.ballman .Thanks for feedback. I am an outreachy applicant and totally 
new to this project. I am currently trying to understand the code base. So 
thought to update the documentation meanwhile. Later on we can change the 
default max working group size with your suggestion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102134

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

[PATCH] D102064: Parse vector bool when stdbool.h and altivec.h are included

2021-05-11 Thread Zarko Todorovski via Phabricator via cfe-commits 
ZarkoCA added a comment.

In D102064#2751160 , @uweigand wrote:

> In D102064#2751089 , @ZarkoCA wrote:
>
>> In D102064#2751001 , @uweigand 
>> wrote:
>>
>>> This means the implementation now deviates from the documented vector 
>>> extension syntax, right?   I guess it's strictly an extension of the 
>>> documented syntax, but that may still lead to incompatibilities with other 
>>> compilers for the platform.  If we want to make such a change, should it be 
>>> synchronized with e.g. GCC, XL, etc. ?
>>
>> GCC and XL already accept this syntax on Linux on Power and AIX.
>>
>> For example this simple test case:
>>
>>   #include 
>>   #include 
>>   
>>   vector bool char bc;
>>
>> Can compile with GCC 9/10 and XLC 16.1 on Linux on Power. On AIX, GCC 8.3 on 
>> AIX and XLC 16.1 can also compile it successfully.  Latest main trunk clang 
>> throws up an error on those platforms.
>>
>> From offline conversation it looks like XLC on z/OS can also compile the 
>> test case. @Everybody0523 can confirm for sure.
>
> Interesting.   On Z using GCC I currently get this error:
>
>   vbool.c:2:1: error: invalid vector type for attribute ‘vector_size’
>   2 | vector _Bool x;
>
> But looking at the GCC sources, it seems we actually intended to support this 
> use as well, there's just a bug.   Given that, I think I'd be fine with 
> adding this to LLVM -- I'll make sure the GCC bug gets fixed as well.

Thank you for looking at GCC on Z. That was the only case where I didn't have 
information from.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102064

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

[PATCH] D102064: Parse vector bool when stdbool.h and altivec.h are included

2021-05-11 Thread Neumann Hon via Phabricator via cfe-commits 
Everybody0523 added a comment.

xlc on z/OS will compile

  vector _Bool char bc;

on any language level high enough to recognize _Bool as a valid keyword.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102064

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

[PATCH] D102251: Suppress Deferred Diagnostics in discarded statements.

2021-05-11 Thread Erich Keane via Phabricator via cfe-commits 
erichkeane added a comment.

In D102251#2751101 , @ABataev wrote:

> LG

Thanks!  I'm going to give @yaxunl a day to take a look that this, particularly 
since the only test I could come up with was CUDA based.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102251

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

[PATCH] D102251: Suppress Deferred Diagnostics in discarded statements.

2021-05-11 Thread Alexey Bataev via Phabricator via cfe-commits 
ABataev added a comment.

In D102251#2751226 , @erichkeane 
wrote:

> In D102251#2751101 , @ABataev wrote:
>
>> LG
>
> Thanks!  I'm going to give @yaxunl a day to take a look that this, 
> particularly since the only test I could come up with was CUDA based.

Yep!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102251

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

[clang] 0fd0a01 - [git-clang-format] Do not apply clang-format to symlinks

2021-05-11 Thread Pirama Arumuga Nainar via cfe-commits 

Author: Pirama Arumuga Nainar
Date: 2021-05-11T10:34:40-07:00
New Revision: 0fd0a010a1ed2ce761d20bfc6378e5bbaa75c8de

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

LOG: [git-clang-format] Do not apply clang-format to symlinks

This fixes PR46992.

Git stores symlinks as text files and we should not format them even if
they have one of the requested extensions.

(Move the call to `cd_to_toplevel()` up a few lines so we can also print
the skipped symlinks during verbose output.)

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/tools/clang-format/git-clang-format

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index bb8a28ed236ba..17351278974df 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -244,6 +244,9 @@ clang-format
   accepts ``AllIfsAndElse`` value that allows to put "else if" and "else" short
   statements on a single line. (Fixes https://llvm.org/PR50019.)
 
+- ``git-clang-format`` no longer formats changes to symbolic links. (Fixes
+  https://llvm.org/PR46992.)
+
 libclang
 
 

diff  --git a/clang/tools/clang-format/git-clang-format 
b/clang/tools/clang-format/git-clang-format
index ccd2f50fa4ad2..3646b4ff41d7f 100755
--- a/clang/tools/clang-format/git-clang-format
+++ b/clang/tools/clang-format/git-clang-format
@@ -137,10 +137,15 @@ def main():
   if opts.verbose >= 1:
 ignored_files = set(changed_lines)
   filter_by_extension(changed_lines, opts.extensions.lower().split(','))
+  # The computed 
diff  outputs absolute paths, so we must cd before accessing
+  # those files.
+  cd_to_toplevel()
+  filter_symlinks(changed_lines)
   if opts.verbose >= 1:
 ignored_files.
diff erence_update(changed_lines)
 if ignored_files:
-  print('Ignoring changes in the following files (wrong extension):')
+  print(
+'Ignoring changes in the following files (wrong extension or 
symlink):')
   for filename in ignored_files:
 print('%s' % filename)
 if changed_lines:
@@ -151,9 +156,6 @@ def main():
 if opts.verbose >= 0:
   print('no modified files to format')
 return
-  # The computed 
diff  outputs absolute paths, so we must cd before accessing
-  # those files.
-  cd_to_toplevel()
   if len(commits) > 1:
 old_tree = commits[1]
 new_tree = run_clang_format_and_save_to_tree(changed_lines,
@@ -337,6 +339,13 @@ def filter_by_extension(dictionary, allowed_extensions):
   del dictionary[filename]
 
 
+def filter_symlinks(dictionary):
+  """Delete every key in `dictionary` that is a symlink."""
+  for filename in list(dictionary.keys()):
+if os.path.islink(filename):
+  del dictionary[filename]
+
+
 def cd_to_toplevel():
   """Change to the top level of the git repository."""
   toplevel = run('git', 'rev-parse', '--show-toplevel')



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

[PATCH] D101878: [git-clang-format] Do not apply clang-format to symlinks

2021-05-11 Thread Pirama Arumuga Nainar via Phabricator via cfe-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rG0fd0a010a1ed: [git-clang-format] Do not apply clang-format 
to symlinks (authored by pirama).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101878

Files:
  clang/docs/ReleaseNotes.rst
  clang/tools/clang-format/git-clang-format


Index: clang/tools/clang-format/git-clang-format
===
--- clang/tools/clang-format/git-clang-format
+++ clang/tools/clang-format/git-clang-format
@@ -137,10 +137,15 @@
   if opts.verbose >= 1:
 ignored_files = set(changed_lines)
   filter_by_extension(changed_lines, opts.extensions.lower().split(','))
+  # The computed diff outputs absolute paths, so we must cd before accessing
+  # those files.
+  cd_to_toplevel()
+  filter_symlinks(changed_lines)
   if opts.verbose >= 1:
 ignored_files.difference_update(changed_lines)
 if ignored_files:
-  print('Ignoring changes in the following files (wrong extension):')
+  print(
+'Ignoring changes in the following files (wrong extension or 
symlink):')
   for filename in ignored_files:
 print('%s' % filename)
 if changed_lines:
@@ -151,9 +156,6 @@
 if opts.verbose >= 0:
   print('no modified files to format')
 return
-  # The computed diff outputs absolute paths, so we must cd before accessing
-  # those files.
-  cd_to_toplevel()
   if len(commits) > 1:
 old_tree = commits[1]
 new_tree = run_clang_format_and_save_to_tree(changed_lines,
@@ -337,6 +339,13 @@
   del dictionary[filename]
 
 
+def filter_symlinks(dictionary):
+  """Delete every key in `dictionary` that is a symlink."""
+  for filename in list(dictionary.keys()):
+if os.path.islink(filename):
+  del dictionary[filename]
+
+
 def cd_to_toplevel():
   """Change to the top level of the git repository."""
   toplevel = run('git', 'rev-parse', '--show-toplevel')
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -244,6 +244,9 @@
   accepts ``AllIfsAndElse`` value that allows to put "else if" and "else" short
   statements on a single line. (Fixes https://llvm.org/PR50019.)
 
+- ``git-clang-format`` no longer formats changes to symbolic links. (Fixes
+  https://llvm.org/PR46992.)
+
 libclang
 
 


Index: clang/tools/clang-format/git-clang-format
===
--- clang/tools/clang-format/git-clang-format
+++ clang/tools/clang-format/git-clang-format
@@ -137,10 +137,15 @@
   if opts.verbose >= 1:
 ignored_files = set(changed_lines)
   filter_by_extension(changed_lines, opts.extensions.lower().split(','))
+  # The computed diff outputs absolute paths, so we must cd before accessing
+  # those files.
+  cd_to_toplevel()
+  filter_symlinks(changed_lines)
   if opts.verbose >= 1:
 ignored_files.difference_update(changed_lines)
 if ignored_files:
-  print('Ignoring changes in the following files (wrong extension):')
+  print(
+'Ignoring changes in the following files (wrong extension or symlink):')
   for filename in ignored_files:
 print('%s' % filename)
 if changed_lines:
@@ -151,9 +156,6 @@
 if opts.verbose >= 0:
   print('no modified files to format')
 return
-  # The computed diff outputs absolute paths, so we must cd before accessing
-  # those files.
-  cd_to_toplevel()
   if len(commits) > 1:
 old_tree = commits[1]
 new_tree = run_clang_format_and_save_to_tree(changed_lines,
@@ -337,6 +339,13 @@
   del dictionary[filename]
 
 
+def filter_symlinks(dictionary):
+  """Delete every key in `dictionary` that is a symlink."""
+  for filename in list(dictionary.keys()):
+if os.path.islink(filename):
+  del dictionary[filename]
+
+
 def cd_to_toplevel():
   """Change to the top level of the git repository."""
   toplevel = run('git', 'rev-parse', '--show-toplevel')
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -244,6 +244,9 @@
   accepts ``AllIfsAndElse`` value that allows to put "else if" and "else" short
   statements on a single line. (Fixes https://llvm.org/PR50019.)
 
+- ``git-clang-format`` no longer formats changes to symbolic links. (Fixes
+  https://llvm.org/PR46992.)
+
 libclang
 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102237: [CUDA][HIP] Fix non-ODR-use of static device variable

2021-05-11 Thread Artem Belevich via Phabricator via cfe-commits 
tra accepted this revision.
tra added a comment.
This revision is now accepted and ready to land.

LGTM with few nits.




Comment at: clang/lib/Sema/SemaExpr.cpp:17145
 };
-if (Var && Var->hasGlobalStorage() && !IsEmittedOnDeviceSide(Var)) {
-  SemaRef.targetDiag(Loc, diag::err_ref_bad_target)
-  << /*host*/ 2 << /*variable*/ 1 << Var << Target;
+if (Var && Var->hasGlobalStorage()) {
+  if (SemaRef.LangOpts.CUDAIsDevice && !IsEmittedOnDeviceSide(Var)) {

This can be collapsed with the `if (SemaRef.LangOpts.CUDA) ` above.



Comment at: clang/test/CodeGenCUDA/static-device-var-rdc.cu:100-105
 // HOST: __hipRegisterVar({{.*}}@_ZL1x {{.*}}@[[DEVNAMEX]]
 // HOST: __hipRegisterVar({{.*}}@_ZL1y {{.*}}@[[DEVNAMEY]]
 // HOST-NOT: __hipRegisterVar({{.*}}@_ZL2x2
 // HOST-NOT: __hipRegisterVar({{.*}}@_ZZ6kernelPiPPKiE1w
 // HOST-NOT: __hipRegisterVar({{.*}}@_ZZ6devfunPPKiE1p
+// HOST-NOT: __hipRegisterVar({{.*}}@_ZL1u

Positive checks should be `-DAG` and negative checks should be done in a 
separate `RUN` as we can't really guarantee the order in which registration 
calls are emitted.


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

https://reviews.llvm.org/D102237

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

[PATCH] D102251: Suppress Deferred Diagnostics in discarded statements.

2021-05-11 Thread Artem Belevich via Phabricator via cfe-commits 
tra accepted this revision.
tra added a comment.

LGTM for CUDA. This matches the intent of deferred diags -- we only emit them 
if we get to generate the code for the sources that triggered them, so they 
should not show up for the false constexpr branches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102251

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

[PATCH] D102238: [TableGen] [Clang] Clean up arm_mve.td file

2021-05-11 Thread Craig Topper via Phabricator via cfe-commits 
craig.topper added inline comments.



Comment at: clang/include/clang/Basic/arm_mve.td:579
+  defvar halfconst = !ne(half, "b");
+  defvar halfconst = !if(!eq(half, "b"), 0, 1);
 

Did you intend to leave the old lines commented out?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102238

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

[PATCH] D102185: Widen `name` stencil to support `TypeLoc` nodes.

2021-05-11 Thread Weston Carvalho via Phabricator via cfe-commits 
SilensAngelusNex updated this revision to Diff 344486.
SilensAngelusNex added a comment.

`T->` => `Loc.`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102185

Files:
  clang/include/clang/Tooling/Transformer/RangeSelector.h
  clang/lib/Tooling/Transformer/RangeSelector.cpp
  clang/unittests/Tooling/RangeSelectorTest.cpp


Index: clang/unittests/Tooling/RangeSelectorTest.cpp
===
--- clang/unittests/Tooling/RangeSelectorTest.cpp
+++ clang/unittests/Tooling/RangeSelectorTest.cpp
@@ -457,6 +457,35 @@
   EXPECT_THAT_EXPECTED(select(name(Init), Match), HasValue("field"));
 }
 
+TEST(RangeSelectorTest, NameOpTypeLoc) {
+  StringRef Code = R"cc(
+namespace ns {
+struct Foo {
+  Foo();
+  Foo(int);
+  Foo(int, int);
+};
+}  // namespace ns
+
+ns::Foo a;
+auto b = ns::Foo(3);
+auto c = ns::Foo(1, 2);
+  )cc";
+  const char *CtorTy = "ctor_ty";
+  // Matches declaration of `a`
+  TestMatch MatchA = matchCode(
+  Code, varDecl(hasName("a"), hasTypeLoc(typeLoc().bind(CtorTy;
+  EXPECT_THAT_EXPECTED(select(name(CtorTy), MatchA), HasValue("Foo"));
+  // Matches call of Foo(int)
+  TestMatch MatchB = matchCode(
+  Code, cxxFunctionalCastExpr(hasTypeLoc(typeLoc().bind(CtorTy;
+  EXPECT_THAT_EXPECTED(select(name(CtorTy), MatchB), HasValue("Foo"));
+  // Matches call of Foo(int, int)
+  TestMatch MatchC = matchCode(
+  Code, cxxTemporaryObjectExpr(hasTypeLoc(typeLoc().bind(CtorTy;
+  EXPECT_THAT_EXPECTED(select(name(CtorTy), MatchC), HasValue("Foo"));
+}
+
 TEST(RangeSelectorTest, NameOpErrors) {
   EXPECT_THAT_EXPECTED(selectFromTrivial(name("unbound_id")),
Failed(withUnboundNodeMessage()));
Index: clang/lib/Tooling/Transformer/RangeSelector.cpp
===
--- clang/lib/Tooling/Transformer/RangeSelector.cpp
+++ clang/lib/Tooling/Transformer/RangeSelector.cpp
@@ -8,6 +8,7 @@
 
 #include "clang/Tooling/Transformer/RangeSelector.h"
 #include "clang/AST/Expr.h"
+#include "clang/AST/TypeLoc.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Lex/Lexer.h"
@@ -228,8 +229,16 @@
   SourceLocation L = I->getMemberLocation();
   return CharSourceRange::getTokenRange(L, L);
 }
+if (const auto *T = Node.get()) {
+  TypeLoc Loc = *T;
+  auto ET = Loc.getAs();
+  if (!ET.isNull()) {
+Loc = ET.getNamedTypeLoc();
+  }
+  return CharSourceRange::getTokenRange(Loc.getSourceRange());
+}
 return typeError(ID, Node.getNodeKind(),
- "DeclRefExpr, NamedDecl, CXXCtorInitializer");
+ "DeclRefExpr, NamedDecl, CXXCtorInitializer, TypeLoc");
   };
 }
 
Index: clang/include/clang/Tooling/Transformer/RangeSelector.h
===
--- clang/include/clang/Tooling/Transformer/RangeSelector.h
+++ clang/include/clang/Tooling/Transformer/RangeSelector.h
@@ -73,9 +73,9 @@
 /// binding in the match result.
 RangeSelector member(std::string ID);
 
-/// Given a node with a "name", (like \c NamedDecl, \c DeclRefExpr or \c
-/// CxxCtorInitializer) selects the name's token.  Only selects the final
-/// identifier of a qualified name, but not any qualifiers or template
+/// Given a node with a "name", (like \c NamedDecl, \c DeclRefExpr, \c
+/// CxxCtorInitializer, and \c TypeLoc) selects the name's token.  Only selects
+/// the final identifier of a qualified name, but not any qualifiers or 
template
 /// arguments.  For example, for `::foo::bar::baz` and `::foo::bar::baz`,
 /// it selects only `baz`.
 ///


Index: clang/unittests/Tooling/RangeSelectorTest.cpp
===
--- clang/unittests/Tooling/RangeSelectorTest.cpp
+++ clang/unittests/Tooling/RangeSelectorTest.cpp
@@ -457,6 +457,35 @@
   EXPECT_THAT_EXPECTED(select(name(Init), Match), HasValue("field"));
 }
 
+TEST(RangeSelectorTest, NameOpTypeLoc) {
+  StringRef Code = R"cc(
+namespace ns {
+struct Foo {
+  Foo();
+  Foo(int);
+  Foo(int, int);
+};
+}  // namespace ns
+
+ns::Foo a;
+auto b = ns::Foo(3);
+auto c = ns::Foo(1, 2);
+  )cc";
+  const char *CtorTy = "ctor_ty";
+  // Matches declaration of `a`
+  TestMatch MatchA = matchCode(
+  Code, varDecl(hasName("a"), hasTypeLoc(typeLoc().bind(CtorTy;
+  EXPECT_THAT_EXPECTED(select(name(CtorTy), MatchA), HasValue("Foo"));
+  // Matches call of Foo(int)
+  TestMatch MatchB = matchCode(
+  Code, cxxFunctionalCastExpr(hasTypeLoc(typeLoc().bind(CtorTy;
+  EXPECT_THAT_EXPECTED(select(name(CtorTy), MatchB), HasValue("Foo"));
+  // Matches call of Foo(int, int)
+  TestMatch MatchC = matchCode(
+  Code, cxxTemporaryObjectExpr(hasTypeLoc(typeLoc().bind(CtorTy;
+

[PATCH] D102238: [TableGen] [Clang] Clean up arm_mve.td file

2021-05-11 Thread Paul C. Anagnostopoulos via Phabricator via cfe-commits 
Paul-C-Anagnostopoulos added inline comments.



Comment at: clang/include/clang/Basic/arm_mve.td:579
+  defvar halfconst = !ne(half, "b");
+  defvar halfconst = !if(!eq(half, "b"), 0, 1);
 

craig.topper wrote:
> Did you intend to leave the old lines commented out?
Just for the first review, in case anyone found anything crazy. I'll remove 
them when I update the review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102238

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

[PATCH] D102261: Introduce SYCL 2020 mode

2021-05-11 Thread Aaron Ballman via Phabricator via cfe-commits 
aaron.ballman created this revision.
aaron.ballman added reviewers: bader, erichkeane, jansvoboda11.
Herald added subscribers: Naghasan, dexonsmith, dang, Anastasia, ebevhan, 
yaxunl.
aaron.ballman requested review of this revision.
Herald added a project: clang.

Currently, we have support for SYCL 1.2.1 (also known as SYCL 2017). This patch 
introduces the start of support for SYCL 2020 mode, which is the latest SYCL 
standard available at 
(https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html). 
This sets the default SYCL to be 2020 in the driver, and introduces the notion 
of a "default" version (set to 2020) when cc1 is in SYCL mode but there was no 
explicit `-sycl-std=` specified on the command line.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102261

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/test/Driver/sycl.c
  clang/test/Preprocessor/sycl-macro.cpp
  clang/unittests/Frontend/CompilerInvocationTest.cpp

Index: clang/unittests/Frontend/CompilerInvocationTest.cpp
===
--- clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -566,18 +566,102 @@
   ASSERT_THAT(GeneratedArgs, Not(Contains(HasSubstr("-sycl-std=";
 }
 
-TEST_F(CommandLineTest, ConditionalParsingIfTrueFlagNotPresent) {
+TEST_F(CommandLineTest, ConditionalParsingIfNonsenseSyclStdArg) {
+  const char *Args[] = {"-fsycl-is-device", "-sycl-std=garbage"};
+
+  CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags);
+
+  ASSERT_TRUE(Diags->hasErrorOccurred());
+  ASSERT_TRUE(Invocation.getLangOpts()->SYCLIsDevice);
+  ASSERT_FALSE(Invocation.getLangOpts()->SYCLIsHost);
+  ASSERT_EQ(Invocation.getLangOpts()->getSYCLVersion(), LangOptions::SYCL_None);
+
+  Invocation.generateCC1CommandLine(GeneratedArgs, *this);
+
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-fsycl-is-device")));
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fsycl-is-host";
+  ASSERT_THAT(GeneratedArgs, Not(Contains(HasSubstr("-sycl-std=";
+}
+
+TEST_F(CommandLineTest, ConditionalParsingIfOddSyclStdArg1) {
+  const char *Args[] = {"-fsycl-is-device", "-sycl-std=121"};
+
+  CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags);
+
+  ASSERT_FALSE(Diags->hasErrorOccurred());
+  ASSERT_TRUE(Invocation.getLangOpts()->SYCLIsDevice);
+  ASSERT_FALSE(Invocation.getLangOpts()->SYCLIsHost);
+  ASSERT_EQ(Invocation.getLangOpts()->getSYCLVersion(), LangOptions::SYCL_2017);
+
+  Invocation.generateCC1CommandLine(GeneratedArgs, *this);
+
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-fsycl-is-device")));
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fsycl-is-host";
+  ASSERT_THAT(GeneratedArgs, Contains(HasSubstr("-sycl-std=2017")));
+}
+
+TEST_F(CommandLineTest, ConditionalParsingIfOddSyclStdArg2) {
+  const char *Args[] = {"-fsycl-is-device", "-sycl-std=1.2.1"};
+
+  CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags);
+
+  ASSERT_FALSE(Diags->hasErrorOccurred());
+  ASSERT_TRUE(Invocation.getLangOpts()->SYCLIsDevice);
+  ASSERT_FALSE(Invocation.getLangOpts()->SYCLIsHost);
+  ASSERT_EQ(Invocation.getLangOpts()->getSYCLVersion(), LangOptions::SYCL_2017);
+
+  Invocation.generateCC1CommandLine(GeneratedArgs, *this);
+
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-fsycl-is-device")));
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fsycl-is-host";
+  ASSERT_THAT(GeneratedArgs, Contains(HasSubstr("-sycl-std=2017")));
+}
+
+TEST_F(CommandLineTest, ConditionalParsingIfOddSyclStdArg3) {
+  const char *Args[] = {"-fsycl-is-device", "-sycl-std=sycl-1.2.1"};
+
+  CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags);
+
+  ASSERT_FALSE(Diags->hasErrorOccurred());
+  ASSERT_TRUE(Invocation.getLangOpts()->SYCLIsDevice);
+  ASSERT_FALSE(Invocation.getLangOpts()->SYCLIsHost);
+  ASSERT_EQ(Invocation.getLangOpts()->getSYCLVersion(), LangOptions::SYCL_2017);
+
+  Invocation.generateCC1CommandLine(GeneratedArgs, *this);
+
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-fsycl-is-device")));
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fsycl-is-host";
+  ASSERT_THAT(GeneratedArgs, Contains(HasSubstr("-sycl-std=2017")));
+}
+
+TEST_F(CommandLineTest, ConditionalParsingIfTrueFlagNotPresentHost) {
   const char *Args[] = {"-fsycl-is-host"};
 
   CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags);
 
   ASSERT_FALSE(Diags->hasErrorOccurred());
-  ASSERT_EQ(Invocation.getLangOpts()->getSYCLVersion(), LangOptions::SYCL_None);
+  ASSERT_EQ(Invocation.getLangOpts()->getSYCLVersion(),
+LangOptions::SYCL_Default);
 
   Invocation.generateCC1CommandLine(GeneratedArgs, *this);
 
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-fsycl-is-host")));
-  A

[PATCH] D102261: Introduce SYCL 2020 mode

2021-05-11 Thread Erich Keane via Phabricator via cfe-commits 
erichkeane added a comment.

LGTM, but want others to look first.




Comment at: clang/lib/Frontend/InitPreprocessor.cpp:481
   Builder.defineMacro("CL_SYCL_LANGUAGE_VERSION", "121");
+  Builder.defineMacro("SYCL_LANGUAGE_VERSION", "201707");
+} else if (LangOpts.getSYCLVersion() == LangOptions::SYCL_2020) {

This seems very related, but perhaps a part of a different patch?  I think I'm 
probably OK bringing this in during this patch, but it isn't strictly related 
to adding 2020 support.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102261

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

[PATCH] D102261: Introduce SYCL 2020 mode

2021-05-11 Thread Aaron Ballman via Phabricator via cfe-commits 
aaron.ballman added inline comments.



Comment at: clang/lib/Frontend/InitPreprocessor.cpp:481
   Builder.defineMacro("CL_SYCL_LANGUAGE_VERSION", "121");
+  Builder.defineMacro("SYCL_LANGUAGE_VERSION", "201707");
+} else if (LangOpts.getSYCLVersion() == LangOptions::SYCL_2020) {

erichkeane wrote:
> This seems very related, but perhaps a part of a different patch?  I think 
> I'm probably OK bringing this in during this patch, but it isn't strictly 
> related to adding 2020 support.
Oops, I'll remove that one, you're right that it's unrelated. Thanks!



Comment at: clang/test/Preprocessor/sycl-macro.cpp:13
 // CHECK-SYCL-STD:#define CL_SYCL_LANGUAGE_VERSION 121
+// CHECK-SYCL-STD:#define SYCL_LANGUAGE_VERSION 201707
+// CHECK-SYCL-STD-2020:#define SYCL_LANGUAGE_VERSION 202001

This change is unrelated as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102261

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

[PATCH] D102261: Introduce SYCL 2020 mode

2021-05-11 Thread Aaron Ballman via Phabricator via cfe-commits 
aaron.ballman updated this revision to Diff 344496.
aaron.ballman added a comment.

Remove some accidental additional changes for SYCL 2017.


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

https://reviews.llvm.org/D102261

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/test/Driver/sycl.c
  clang/test/Preprocessor/sycl-macro.cpp
  clang/unittests/Frontend/CompilerInvocationTest.cpp

Index: clang/unittests/Frontend/CompilerInvocationTest.cpp
===
--- clang/unittests/Frontend/CompilerInvocationTest.cpp
+++ clang/unittests/Frontend/CompilerInvocationTest.cpp
@@ -566,18 +566,102 @@
   ASSERT_THAT(GeneratedArgs, Not(Contains(HasSubstr("-sycl-std=";
 }
 
-TEST_F(CommandLineTest, ConditionalParsingIfTrueFlagNotPresent) {
+TEST_F(CommandLineTest, ConditionalParsingIfNonsenseSyclStdArg) {
+  const char *Args[] = {"-fsycl-is-device", "-sycl-std=garbage"};
+
+  CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags);
+
+  ASSERT_TRUE(Diags->hasErrorOccurred());
+  ASSERT_TRUE(Invocation.getLangOpts()->SYCLIsDevice);
+  ASSERT_FALSE(Invocation.getLangOpts()->SYCLIsHost);
+  ASSERT_EQ(Invocation.getLangOpts()->getSYCLVersion(), LangOptions::SYCL_None);
+
+  Invocation.generateCC1CommandLine(GeneratedArgs, *this);
+
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-fsycl-is-device")));
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fsycl-is-host";
+  ASSERT_THAT(GeneratedArgs, Not(Contains(HasSubstr("-sycl-std=";
+}
+
+TEST_F(CommandLineTest, ConditionalParsingIfOddSyclStdArg1) {
+  const char *Args[] = {"-fsycl-is-device", "-sycl-std=121"};
+
+  CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags);
+
+  ASSERT_FALSE(Diags->hasErrorOccurred());
+  ASSERT_TRUE(Invocation.getLangOpts()->SYCLIsDevice);
+  ASSERT_FALSE(Invocation.getLangOpts()->SYCLIsHost);
+  ASSERT_EQ(Invocation.getLangOpts()->getSYCLVersion(), LangOptions::SYCL_2017);
+
+  Invocation.generateCC1CommandLine(GeneratedArgs, *this);
+
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-fsycl-is-device")));
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fsycl-is-host";
+  ASSERT_THAT(GeneratedArgs, Contains(HasSubstr("-sycl-std=2017")));
+}
+
+TEST_F(CommandLineTest, ConditionalParsingIfOddSyclStdArg2) {
+  const char *Args[] = {"-fsycl-is-device", "-sycl-std=1.2.1"};
+
+  CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags);
+
+  ASSERT_FALSE(Diags->hasErrorOccurred());
+  ASSERT_TRUE(Invocation.getLangOpts()->SYCLIsDevice);
+  ASSERT_FALSE(Invocation.getLangOpts()->SYCLIsHost);
+  ASSERT_EQ(Invocation.getLangOpts()->getSYCLVersion(), LangOptions::SYCL_2017);
+
+  Invocation.generateCC1CommandLine(GeneratedArgs, *this);
+
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-fsycl-is-device")));
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fsycl-is-host";
+  ASSERT_THAT(GeneratedArgs, Contains(HasSubstr("-sycl-std=2017")));
+}
+
+TEST_F(CommandLineTest, ConditionalParsingIfOddSyclStdArg3) {
+  const char *Args[] = {"-fsycl-is-device", "-sycl-std=sycl-1.2.1"};
+
+  CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags);
+
+  ASSERT_FALSE(Diags->hasErrorOccurred());
+  ASSERT_TRUE(Invocation.getLangOpts()->SYCLIsDevice);
+  ASSERT_FALSE(Invocation.getLangOpts()->SYCLIsHost);
+  ASSERT_EQ(Invocation.getLangOpts()->getSYCLVersion(), LangOptions::SYCL_2017);
+
+  Invocation.generateCC1CommandLine(GeneratedArgs, *this);
+
+  ASSERT_THAT(GeneratedArgs, Contains(StrEq("-fsycl-is-device")));
+  ASSERT_THAT(GeneratedArgs, Not(Contains(StrEq("-fsycl-is-host";
+  ASSERT_THAT(GeneratedArgs, Contains(HasSubstr("-sycl-std=2017")));
+}
+
+TEST_F(CommandLineTest, ConditionalParsingIfTrueFlagNotPresentHost) {
   const char *Args[] = {"-fsycl-is-host"};
 
   CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags);
 
   ASSERT_FALSE(Diags->hasErrorOccurred());
-  ASSERT_EQ(Invocation.getLangOpts()->getSYCLVersion(), LangOptions::SYCL_None);
+  ASSERT_EQ(Invocation.getLangOpts()->getSYCLVersion(),
+LangOptions::SYCL_Default);
 
   Invocation.generateCC1CommandLine(GeneratedArgs, *this);
 
   ASSERT_THAT(GeneratedArgs, Contains(StrEq("-fsycl-is-host")));
-  ASSERT_THAT(GeneratedArgs, Not(Contains(HasSubstr("-sycl-std=";
+  ASSERT_THAT(GeneratedArgs, Contains(HasSubstr("-sycl-std=")));
+}
+
+TEST_F(CommandLineTest, ConditionalParsingIfTrueFlagNotPresentDevice) {
+  const char *Args[] = {"-fsycl-is-device"};
+
+  CompilerInvocation::CreateFromArgs(Invocation, Args, *Diags);
+
+  ASSERT_FALSE(Diags->hasErrorOccurred());
+  ASSERT_EQ(Invocation.getLangOpts()->getSYCLVersion(),
+LangOptions::SYCL_Default);
+
+  Invocation.generateCC1CommandLine(GeneratedArgs, *this);
+
+  ASSERT_THAT(GeneratedArgs, Contain

  1   2   >