[PATCH] D102643: [analyzer][Z3][NFC] Use GTEST_SKIP instead of hacks

2021-05-18 Thread Balázs Benics via Phabricator via cfe-commits
steakhal updated this revision to Diff 346061.
steakhal added a comment.

now it should build


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

https://reviews.llvm.org/D102643

Files:
  clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp


Index: clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
===
--- clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
+++ clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
@@ -19,11 +19,10 @@
 #include "llvm/Config/llvm-config.h"
 #include "gtest/gtest.h"
 
-// FIXME: Use GTEST_SKIP() instead if GTest is updated to version 1.10.0
-#ifdef LLVM_WITH_Z3
-#define SKIP_WITHOUT_Z3
-#else
-#define SKIP_WITHOUT_Z3 return
+// LLVM_ENABLE_Z3_SOLVER will define the LLVM_WITH_Z3 to 1 if finds Z3.
+// Otherwise it will be left undefined.
+#ifndef LLVM_WITH_Z3
+#define LLVM_WITH_Z3 0
 #endif
 
 namespace clang {
@@ -109,7 +108,8 @@
 "-Xclang", "-analyzer-config", "-Xclang", "crosscheck-with-z3=true"};
 
 TEST(FalsePositiveRefutationBRVisitor, UnSatInTheMiddleNoReport) {
-  SKIP_WITHOUT_Z3;
+  if (!LLVM_WITH_Z3)
+GTEST_SKIP() << "Requires the LLVM_ENABLE_Z3_SOLVER cmake option.";
   constexpr auto Code = R"(
  void reachedWithContradiction();
  void reachedWithNoContradiction();
@@ -140,7 +140,8 @@
 }
 
 TEST(FalsePositiveRefutationBRVisitor, UnSatAtErrorNodeWithNewSymbolNoReport) {
-  SKIP_WITHOUT_Z3;
+  if (!LLVM_WITH_Z3)
+GTEST_SKIP() << "Requires the LLVM_ENABLE_Z3_SOLVER cmake option.";
   constexpr auto Code = R"(
 void reportIfCanBeTrue(bool);
 void reachedWithNoContradiction();
@@ -172,7 +173,8 @@
 
 TEST(FalsePositiveRefutationBRVisitor,
  UnSatAtErrorNodeDueToRefinedConstraintNoReport) {
-  SKIP_WITHOUT_Z3;
+  if (!LLVM_WITH_Z3)
+GTEST_SKIP() << "Requires the LLVM_ENABLE_Z3_SOLVER cmake option.";
   constexpr auto Code = R"(
 void reportIfCanBeTrue(bool);
 void reachedWithNoContradiction();


Index: clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
===
--- clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
+++ clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
@@ -19,11 +19,10 @@
 #include "llvm/Config/llvm-config.h"
 #include "gtest/gtest.h"
 
-// FIXME: Use GTEST_SKIP() instead if GTest is updated to version 1.10.0
-#ifdef LLVM_WITH_Z3
-#define SKIP_WITHOUT_Z3
-#else
-#define SKIP_WITHOUT_Z3 return
+// LLVM_ENABLE_Z3_SOLVER will define the LLVM_WITH_Z3 to 1 if finds Z3.
+// Otherwise it will be left undefined.
+#ifndef LLVM_WITH_Z3
+#define LLVM_WITH_Z3 0
 #endif
 
 namespace clang {
@@ -109,7 +108,8 @@
 "-Xclang", "-analyzer-config", "-Xclang", "crosscheck-with-z3=true"};
 
 TEST(FalsePositiveRefutationBRVisitor, UnSatInTheMiddleNoReport) {
-  SKIP_WITHOUT_Z3;
+  if (!LLVM_WITH_Z3)
+GTEST_SKIP() << "Requires the LLVM_ENABLE_Z3_SOLVER cmake option.";
   constexpr auto Code = R"(
  void reachedWithContradiction();
  void reachedWithNoContradiction();
@@ -140,7 +140,8 @@
 }
 
 TEST(FalsePositiveRefutationBRVisitor, UnSatAtErrorNodeWithNewSymbolNoReport) {
-  SKIP_WITHOUT_Z3;
+  if (!LLVM_WITH_Z3)
+GTEST_SKIP() << "Requires the LLVM_ENABLE_Z3_SOLVER cmake option.";
   constexpr auto Code = R"(
 void reportIfCanBeTrue(bool);
 void reachedWithNoContradiction();
@@ -172,7 +173,8 @@
 
 TEST(FalsePositiveRefutationBRVisitor,
  UnSatAtErrorNodeDueToRefinedConstraintNoReport) {
-  SKIP_WITHOUT_Z3;
+  if (!LLVM_WITH_Z3)
+GTEST_SKIP() << "Requires the LLVM_ENABLE_Z3_SOLVER cmake option.";
   constexpr auto Code = R"(
 void reportIfCanBeTrue(bool);
 void reachedWithNoContradiction();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D102669: [analyzer][ctu] Fix wrong 'multiple definitions' errors caused by space characters in lookup names when parsing the ctu index file

2021-05-18 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a reviewer: balazske.
steakhal added a comment.

I don't really like having multiple files with the same name.
And the importer TU should be simple to be simply `cat`-ed into a temporal file.
At that point, you could put the importee's content into this file. It would 
result in a single, self-contained test case.

I'm not really familiar with the extdefmap part, but I'm surprised that we are 
using spaces as separators.
Shouldn't we consider using a different character?




Comment at: clang/test/Analysis/ctu-lookup-name-with-space.cpp:7
+// RUN: echo '"%t/importee.cpp" : ["g++", "-c", "%t/importee.cpp"]' > 
%t/invocations.yaml
+// RUN: echo '[{"directory": "%t", "command": "g++ -c %t/importee.cpp", 
"file": "%t/importee.cpp"}, {"directory": "%t", "command": "g++ -c 
%t/trigger.cpp", "file": "%t/trigger.cpp"}]' > %t/compile_commands.json
+

Probably splitting this up into multiple lines would result in a more readable 
solution.

Something along these lines should work:
```
cat >%t/compile_commands.json <&1 | FileCheck importee.cpp
+

Why do you need two separate invocations? Couldn't you just merge these?
I've seen cases where `-verify` was used in conjunction with `FileCheck`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102669

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


[clang] 88ee91c - [ASTimporter] Remove decl from lookup only if it has decl context

2021-05-18 Thread Balazs Benics via cfe-commits

Author: Balazs Benics
Date: 2021-05-18T09:43:20+02:00
New Revision: 88ee91cd87794813f4394f82d2c693c8d766e1d2

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

LOG: [ASTimporter] Remove decl from lookup only if it has decl context

In the case of TypedefDecls we set the DeclContext after we imported it.
It turns out, it could lead to null pointer dereferences during the
cleanup part of a failed import.

This patch demonstrates this issue and fixes it by checking if the
DeclContext is available or not.

Reviewed By: shafik

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

Added: 


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

Removed: 




diff  --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp
index dd11e3662148e..9caa1178c0b7b 100644
--- a/clang/lib/AST/ASTImporter.cpp
+++ b/clang/lib/AST/ASTImporter.cpp
@@ -8383,7 +8383,11 @@ Expected ASTImporter::Import(Decl *FromD) {
   // traverse of the 'to' context).
   auto PosF = ImportedFromDecls.find(ToD);
   if (PosF != ImportedFromDecls.end()) {
-SharedState->removeDeclFromLookup(ToD);
+// In the case of TypedefNameDecl we create the Decl first and only
+// then we import and set its DeclContext. So, the DC might not be set
+// when we reach here.
+if (ToD->getDeclContext())
+  SharedState->removeDeclFromLookup(ToD);
 ImportedFromDecls.erase(PosF);
   }
 

diff  --git a/clang/unittests/AST/ASTImporterTest.cpp 
b/clang/unittests/AST/ASTImporterTest.cpp
index e62203f286572..db87b2ab5e9c0 100644
--- a/clang/unittests/AST/ASTImporterTest.cpp
+++ b/clang/unittests/AST/ASTImporterTest.cpp
@@ -5225,6 +5225,40 @@ TEST_P(ErrorHandlingTest, 
ErrorIsNotPropagatedFromMemberToNamespace) {
   EXPECT_TRUE(ImportedOK);
 }
 
+TEST_P(ErrorHandlingTest, ODRViolationWithinTypedefDecls) {
+  // Importing `z` should fail - instead of crashing - due to an ODR violation.
+  // The `bar::e` typedef sets it's DeclContext after the import is done.
+  // However, if the importation fails, it will be left as a nullptr.
+  // During the cleanup of the failed import, we should check whether the
+  // DeclContext is null or not - instead of dereferencing that 
unconditionally.
+  constexpr auto ToTUCode = R"(
+  namespace X {
+struct bar {
+  int odr_violation;
+};
+  })";
+  constexpr auto FromTUCode = R"(
+  namespace X {
+enum b {};
+struct bar {
+  typedef b e;
+  static e d;
+};
+  }
+  int z = X::bar::d;
+  )";
+  Decl *ToTU = getToTuDecl(ToTUCode, Lang_CXX11);
+  static_cast(ToTU);
+  Decl *FromTU = getTuDecl(FromTUCode, Lang_CXX11);
+  auto *FromZ =
+  FirstDeclMatcher().match(FromTU, varDecl(hasName("z")));
+  ASSERT_TRUE(FromZ);
+  ASSERT_TRUE(FromZ->hasInit());
+
+  auto *ImportedZ = Import(FromZ, Lang_CXX11);
+  EXPECT_FALSE(ImportedZ);
+}
+
 // An error should be set for a class if it had a previous import with an error
 // from another TU.
 TEST_P(ErrorHandlingTest,



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


[PATCH] D102640: [ASTimporter] Remove decl from lookup only if it has decl context

2021-05-18 Thread Balázs Benics via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG88ee91cd8779: [ASTimporter] Remove decl from lookup only if 
it has decl context (authored by steakhal).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102640

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


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -5225,6 +5225,40 @@
   EXPECT_TRUE(ImportedOK);
 }
 
+TEST_P(ErrorHandlingTest, ODRViolationWithinTypedefDecls) {
+  // Importing `z` should fail - instead of crashing - due to an ODR violation.
+  // The `bar::e` typedef sets it's DeclContext after the import is done.
+  // However, if the importation fails, it will be left as a nullptr.
+  // During the cleanup of the failed import, we should check whether the
+  // DeclContext is null or not - instead of dereferencing that 
unconditionally.
+  constexpr auto ToTUCode = R"(
+  namespace X {
+struct bar {
+  int odr_violation;
+};
+  })";
+  constexpr auto FromTUCode = R"(
+  namespace X {
+enum b {};
+struct bar {
+  typedef b e;
+  static e d;
+};
+  }
+  int z = X::bar::d;
+  )";
+  Decl *ToTU = getToTuDecl(ToTUCode, Lang_CXX11);
+  static_cast(ToTU);
+  Decl *FromTU = getTuDecl(FromTUCode, Lang_CXX11);
+  auto *FromZ =
+  FirstDeclMatcher().match(FromTU, varDecl(hasName("z")));
+  ASSERT_TRUE(FromZ);
+  ASSERT_TRUE(FromZ->hasInit());
+
+  auto *ImportedZ = Import(FromZ, Lang_CXX11);
+  EXPECT_FALSE(ImportedZ);
+}
+
 // An error should be set for a class if it had a previous import with an error
 // from another TU.
 TEST_P(ErrorHandlingTest,
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -8383,7 +8383,11 @@
   // traverse of the 'to' context).
   auto PosF = ImportedFromDecls.find(ToD);
   if (PosF != ImportedFromDecls.end()) {
-SharedState->removeDeclFromLookup(ToD);
+// In the case of TypedefNameDecl we create the Decl first and only
+// then we import and set its DeclContext. So, the DC might not be set
+// when we reach here.
+if (ToD->getDeclContext())
+  SharedState->removeDeclFromLookup(ToD);
 ImportedFromDecls.erase(PosF);
   }
 


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -5225,6 +5225,40 @@
   EXPECT_TRUE(ImportedOK);
 }
 
+TEST_P(ErrorHandlingTest, ODRViolationWithinTypedefDecls) {
+  // Importing `z` should fail - instead of crashing - due to an ODR violation.
+  // The `bar::e` typedef sets it's DeclContext after the import is done.
+  // However, if the importation fails, it will be left as a nullptr.
+  // During the cleanup of the failed import, we should check whether the
+  // DeclContext is null or not - instead of dereferencing that unconditionally.
+  constexpr auto ToTUCode = R"(
+  namespace X {
+struct bar {
+  int odr_violation;
+};
+  })";
+  constexpr auto FromTUCode = R"(
+  namespace X {
+enum b {};
+struct bar {
+  typedef b e;
+  static e d;
+};
+  }
+  int z = X::bar::d;
+  )";
+  Decl *ToTU = getToTuDecl(ToTUCode, Lang_CXX11);
+  static_cast(ToTU);
+  Decl *FromTU = getTuDecl(FromTUCode, Lang_CXX11);
+  auto *FromZ =
+  FirstDeclMatcher().match(FromTU, varDecl(hasName("z")));
+  ASSERT_TRUE(FromZ);
+  ASSERT_TRUE(FromZ->hasInit());
+
+  auto *ImportedZ = Import(FromZ, Lang_CXX11);
+  EXPECT_FALSE(ImportedZ);
+}
+
 // An error should be set for a class if it had a previous import with an error
 // from another TU.
 TEST_P(ErrorHandlingTest,
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -8383,7 +8383,11 @@
   // traverse of the 'to' context).
   auto PosF = ImportedFromDecls.find(ToD);
   if (PosF != ImportedFromDecls.end()) {
-SharedState->removeDeclFromLookup(ToD);
+// In the case of TypedefNameDecl we create the Decl first and only
+// then we import and set its DeclContext. So, the DC might not be set
+// when we reach here.
+if (ToD->getDeclContext())
+  SharedState->removeDeclFromLookup(ToD);
 ImportedFromDecls.erase(PosF);
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai

[PATCH] D102640: [ASTimporter] Remove decl from lookup only if it has decl context

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

In D102640#2764759 , @shafik wrote:

> This is a good catch, thank you for fixing this!

Thanks for the quick review!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102640

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


[PATCH] D102592: [sanitizer] Caught global buffer underflow for first variable

2021-05-18 Thread Zhiwei Chen via Phabricator via cfe-commits
condy added a comment.

In D102592#2764085 , @vitalybuka 
wrote:

> Would you mind to add compiler-rt/test/asan which triggers this one?

Yes, I will.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102592

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


[PATCH] D97085: [OpenMP] libomp: implement OpenMP 5.1 inoutset task dependence type

2021-05-18 Thread Andrey Churbanov via Phabricator via cfe-commits
AndreyChurbanov updated this revision to Diff 346071.
AndreyChurbanov added a comment.

rebased


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

https://reviews.llvm.org/D97085

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/depobj_codegen.cpp
  clang/test/OpenMP/target_enter_data_depend_codegen.cpp
  clang/test/OpenMP/target_exit_data_depend_codegen.cpp
  clang/test/OpenMP/target_update_depend_codegen.cpp
  clang/test/OpenMP/task_codegen.c
  clang/test/OpenMP/task_codegen.cpp
  clang/test/OpenMP/task_if_codegen.cpp
  openmp/runtime/src/kmp.h
  openmp/runtime/src/kmp_taskdeps.cpp
  openmp/runtime/src/kmp_taskdeps.h
  openmp/runtime/test/tasking/bug_nested_proxy_task.c
  openmp/runtime/test/tasking/bug_proxy_task_dep_waiting.c
  openmp/runtime/test/tasking/hidden_helper_task/common.h
  openmp/runtime/test/tasking/hidden_helper_task/depend.cpp
  openmp/runtime/test/tasking/hidden_helper_task/gtid.cpp
  openmp/runtime/test/tasking/omp51_task_dep_inoutset.c

Index: openmp/runtime/test/tasking/omp51_task_dep_inoutset.c
===
--- /dev/null
+++ openmp/runtime/test/tasking/omp51_task_dep_inoutset.c
@@ -0,0 +1,258 @@
+// RUN: %libomp-compile-and-run
+// RUN: %libomp-cxx-compile-and-run
+// UNSUPPORTED: gcc
+
+// Tests OMP 5.0 task dependences "mutexinoutset" and 5.1 "inoutset",
+// emulates compiler codegen for new dep kinds
+// Mutually exclusive tasks get same input dependency info array
+//
+// Task tree created:
+//  task0 - task1 (in)
+// \
+//task2 - task3 (inoutset)
+// /
+//  task3 - task4 (in)
+//   /
+//  task6 <-->task7  (mutexinoutset)
+//   \/
+//   task8 (in)
+//
+#include 
+#include 
+
+#ifdef _WIN32
+#include 
+#define mysleep(n) Sleep(n)
+#else
+#include 
+#define mysleep(n) usleep((n)*1000)
+#endif
+
+// to check the # of concurrent tasks (must be 1 for MTX, <3 for other kinds)
+static int volatile checker = 0;
+static int err = 0;
+#ifndef DELAY
+#define DELAY 100
+#endif
+
+// ---
+// internal data to emulate compiler codegen
+typedef struct DEP {
+  size_t addr;
+  size_t len;
+  int flags;
+} dep;
+typedef struct task {
+  void** shareds;
+  void* entry;
+  int part_id;
+  void* destr_thunk;
+  int priority;
+  long long device_id;
+  int f_priv;
+} task_t;
+#define TIED 1
+typedef int(*entry_t)(int, task_t*);
+typedef struct ID {
+  int reserved_1;
+  int flags;
+  int reserved_2;
+  int reserved_3;
+  char *psource;
+} id;
+// thunk routine for tasks with MTX dependency
+int thunk_m(int gtid, task_t* ptask) {
+  int th = omp_get_thread_num();
+  #pragma omp atomic
+++checker;
+  printf("task _%d, th %d\n", ptask->f_priv, th);
+  if (checker != 1) { // no more than 1 task at a time
+err++;
+printf("Error1, checker %d != 1\n", checker);
+  }
+  mysleep(DELAY);
+  if (checker != 1) { // no more than 1 task at a time
+err++;
+printf("Error2, checker %d != 1\n", checker);
+  }
+  #pragma omp atomic
+--checker;
+  return 0;
+}
+// thunk routine for tasks with inoutset dependency
+int thunk_s(int gtid, task_t* ptask) {
+  int th = omp_get_thread_num();
+  #pragma omp atomic
+++checker;
+  printf("task _%d, th %d\n", ptask->f_priv, th);
+  if (checker > 2) { // no more than 2 tasks concurrently
+err++;
+printf("Error1, checker %d > 2\n", checker);
+  }
+  mysleep(DELAY);
+  if (checker > 2) { // no more than 2 tasks concurrently
+err++;
+printf("Error2, checker %d > 2\n", checker);
+  }
+  #pragma omp atomic
+--checker;
+  return 0;
+}
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+int __kmpc_global_thread_num(id*);
+extern task_t* __kmpc_omp_task_alloc(id *loc, int gtid, int flags,
+ size_t sz, size_t shar, entry_t rtn);
+int
+__kmpc_omp_task_with_deps(id *loc, int gtid, task_t *task, int nd, dep *dep_lst,
+  int nd_noalias, dep *noalias_dep_lst);
+static id loc = {0, 2, 0, 0, ";file;func;0;0;;"};
+#ifdef __cplusplus
+} // extern "C"
+#endif
+// End of internal data
+// ---
+
+int main()
+{
+  int i1,i2,i3;
+  omp_set_num_threads(4);
+  omp_set_dynamic(0);
+  #pragma omp parallel
+  {
+#pragma omp single nowait
+{
+  dep sdep[2];
+  task_t *ptr;
+  int gtid = __kmpc_global_thread_num(&loc);
+  int t = omp_get_thread_num();
+  #pragma omp task depend(in: i1, i2)
+  { int th = omp_get_thread_num();
+printf("task 0_%d, th %d\n", t, th);
+#pragma omp atomic
+  ++checker;
+if (checker > 2) { // no more than 2 tasks concurrently
+  err++;
+  printf("Error1, checker %d > 2\n", checker);
+}
+mysleep(DELAY);
+if (checker > 2) { // no more than 2 tasks concurrently
+  err++;
+  printf("E

[PATCH] D97085: [OpenMP] libomp: implement OpenMP 5.1 inoutset task dependence type

2021-05-18 Thread Andrey Churbanov via Phabricator via cfe-commits
AndreyChurbanov added inline comments.



Comment at: openmp/runtime/src/kmp_taskdeps.cpp:344-346
+// link node as successor of all nodes in the prev_set if any
+npredecessors +=
+__kmp_depnode_link_successor(gtid, thread, task, node, prev_set);

protze.joachim wrote:
> If I understand this code right, this has O(n^2) complexity for two sets of 
> size n?
> 
> Consider:
> ```
> for (int i=0; i #pragma omp task depend(in:A)
> work(A,i);
> }
> for (int i=0; i #pragma omp task depend(inoutset:A)
> work(A,i);
> }
> ```
> All n tasks in the first loop would be predecessor for each of the tasks in 
> the second loop. This will also result in n^2 releases/notifications.
> 
> 
> I'd suggest to model the dependencies like:
> ```
> for (int i=0; i #pragma omp task depend(in:A)
> work(A,i);
> }
> #pragma omp taskwait depend(inout:A) nowait
> for (int i=0; i #pragma omp task depend(inoutset:A)
> work(A,i);
> }
> ```
> I.e., add a dummy dependency node between the two sets, which has n 
> predecessors and n successors. You probably understand the depnode code 
> better, than I do, but I think you would only need to add some code in line 
> 357, where `last_set` is moved to `prev_set`.
> This dummy node would reduce linking and releasing complexity to O(n).
This could be a separate research project.  Because such change may cause 
performance regressions on some real codes, so it needs thorough investigation. 
 I mean insertion of an auxiliary dummy node into dependency graph is 
definitely an overhead, which may or may not be overridden by reduction in 
number of edges in the graph.  Or it can be made optional optimization under an 
external control, if there is a significant gain in some particular case.


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

https://reviews.llvm.org/D97085

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


[PATCH] D102592: [sanitizer] Caught global buffer underflow for first variable

2021-05-18 Thread Zhiwei Chen via Phabricator via cfe-commits
condy added a comment.

In D102592#2764357 , @eugenis wrote:

> You are adding a new global to every translation unit.
>
> - Private linkage would not allow them to be merged, this can have 
> significant binary size and RAM overhead.

Do you suggest linkonce linkage?

> - There is no guarantee that any of these globals will end up to the left of 
> any sanitized globals. With -fdata-sections, the linker is free to reorder.
> - It is also not referenced from anything, so -gc-sections is likely to kill 
> it.
>
> It looks like this will only work in very limited circumstances.

Since it's limited, perhaps making it opt-in is a better choice.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102592

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


[PATCH] D102640: [ASTimporter] Remove decl from lookup only if it has decl context

2021-05-18 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

Post commit looks good to me as well.
@steakhal Nice work! @shafik Thanks for the review!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102640

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


[PATCH] D102241: [clang] p1099 4/5: using enum EnumTag

2021-05-18 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:4654
+
+  return ImportUsingShadowDecls(D, ToUsingEnum);
 }

Could it work if you imported the shadow declarations **before** creating the 
`UsingEnumDecl`? I yes, then that would be the preferred approach b/c that 
would fix the `// FIXME: We return error here but the definition is already 
created`.


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

https://reviews.llvm.org/D102241

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


[clang] 3f3642a - [CodeGen] Avoid unused variable warning in Release builds. NFCI.

2021-05-18 Thread Benjamin Kramer via cfe-commits

Author: Benjamin Kramer
Date: 2021-05-18T11:09:12+02:00
New Revision: 3f3642a7631e28e44c248a46703e381d389958a1

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

LOG: [CodeGen] Avoid unused variable warning in Release builds. NFCI.

Added: 


Modified: 
clang/lib/CodeGen/CGCleanup.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGCleanup.cpp b/clang/lib/CodeGen/CGCleanup.cpp
index bfc8f4b724a8..b439204cf047 100644
--- a/clang/lib/CodeGen/CGCleanup.cpp
+++ b/clang/lib/CodeGen/CGCleanup.cpp
@@ -1318,8 +1318,7 @@ void CodeGenFunction::EmitCXXTemporary(const CXXTemporary 
*Temporary,
 static void EmitSehScope(CodeGenFunction &CGF,
  llvm::FunctionCallee &SehCppScope) {
   llvm::BasicBlock *InvokeDest = CGF.getInvokeDest();
-  llvm::BasicBlock *BB = CGF.Builder.GetInsertBlock();
-  assert(BB && InvokeDest);
+  assert(CGF.Builder.GetInsertBlock() && InvokeDest);
   llvm::BasicBlock *Cont = CGF.createBasicBlock("invoke.cont");
   SmallVector BundleList =
   CGF.getBundlesForFunclet(SehCppScope.getCallee());
@@ -1368,4 +1367,4 @@ void CodeGenFunction::EmitSehTryScopeEnd() {
   llvm::FunctionCallee SehCppScope =
   CGM.CreateRuntimeFunction(FTy, "llvm.seh.try.end");
   EmitSehScope(*this, SehCppScope);
-}
\ No newline at end of file
+}



___
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-18 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

LGTM! Thanks!


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

https://reviews.llvm.org/D102248

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


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

2021-05-18 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/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] D102149: [analyzer][ctu] Allow loading invocation list from a compilation database automatically detected from the ctu-dir

2021-05-18 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

Thank you @OikawaKirie for working on this many CTU related patches! I am going 
to find time for a thorough review and going to pursue @gamesh411 as well to do 
the same! On the other hand, it would be really useful if you could build a 
"Stack" from these patches, I mean could you please set which patch depends 
from which other (see "Edit related revisions")?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102149

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


[PATCH] D96524: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64

2021-05-18 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks!




Comment at: clang/lib/Sema/Sema.cpp:304
 addImplicitTypedef("event_t", Context.OCLEventTy);
+
 if (getLangOpts().OpenCLCPlusPlus || getLangOpts().OpenCLVersion >= 200) {

I suggest to drop changes in this file since they are formatting only.



Comment at: clang/test/CodeGenOpenCL/printf.cl:9
 
-#ifdef cl_khr_fp64
+#if defined(cl_khr_fp64) || defined(__opencl_c_fp64)
 typedef __attribute__((ext_vector_type(2))) double double2;

I think we don't technically need this change?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96524

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


[PATCH] D102669: [analyzer][ctu] Fix wrong 'multiple definitions' errors caused by space characters in lookup names when parsing the ctu index file

2021-05-18 Thread Ella Ma via Phabricator via cfe-commits
OikawaKirie marked an inline comment as done.
OikawaKirie added a comment.

In D102669#2765233 , @steakhal wrote:

> I'm not really familiar with the extdefmap part, but I'm surprised that we 
> are using spaces as separators.
> Shouldn't we consider using a different character?

I prefer the idea of changing the delimiter character, but it may lead to 
modifying a lot of test cases.
I think we'd better make this change in another revision in the future if we do 
want to change it.




Comment at: clang/test/Analysis/ctu-lookup-name-with-space.cpp:7
+// RUN: echo '"%t/importee.cpp" : ["g++", "-c", "%t/importee.cpp"]' > 
%t/invocations.yaml
+// RUN: echo '[{"directory": "%t", "command": "g++ -c %t/importee.cpp", 
"file": "%t/importee.cpp"}, {"directory": "%t", "command": "g++ -c 
%t/trigger.cpp", "file": "%t/trigger.cpp"}]' > %t/compile_commands.json
+

steakhal wrote:
> Probably splitting this up into multiple lines would result in a more 
> readable solution.
> 
> Something along these lines should work:
> ```
> cat >%t/compile_commands.json < line 1
> line 2
> ...
> EOL
> ```
The suggestion is great, however I cannot find a way to write the `RUN` 
commands.
Could you please tell me how to write the commands in this way? It is also 
useful to help me merging the test case into one file.



Comment at: clang/test/Analysis/ctu-lookup-name-with-space.cpp:11-23
+// RUN: cd %t && %clang_cc1 -fsyntax-only -analyze \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-config experimental-enable-naive-ctu-analysis=true \
+// RUN:   -analyzer-config ctu-dir=. \
+// RUN:   -analyzer-config ctu-invocation-list=invocations.yaml \
+// RUN:   trigger.cpp 2>&1 | FileCheck importee.cpp
+

steakhal wrote:
> Why do you need two separate invocations? Couldn't you just merge these?
> I've seen cases where `-verify` was used in conjunction with `FileCheck`.
I forgot the `--allow-empty` argument during writing this test case. I will 
merge them in an update.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102669

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


[clang] 642d2f0 - [OpenCL] Fix initialization of __constant constructors without arguments

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

Author: Ole Strohm
Date: 2021-05-18T10:59:53+01:00
New Revision: 642d2f000b26821010793ea1ea6a38a6695fc864

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

LOG: [OpenCL] Fix initialization of __constant constructors without arguments

This fixes the initialization of objects in the __constant
address space that occurs when declaring the object.

Fixes part of PR42566

Reviewed By: Anastasia

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

Added: 
clang/test/CodeGenOpenCLCXX/addrspace-constructors.clcpp
clang/test/SemaOpenCLCXX/addrspace-constructors.clcpp

Modified: 
clang/lib/Sema/SemaDecl.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index db267089be965..c4db147e7efde 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -12635,9 +12635,21 @@ void Sema::ActOnUninitializedDecl(Decl *RealDecl) {
 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()) 
{

diff  --git a/clang/test/CodeGenOpenCLCXX/addrspace-constructors.clcpp 
b/clang/test/CodeGenOpenCLCXX/addrspace-constructors.clcpp
new file mode 100644
index 0..5d81bc57603e7
--- /dev/null
+++ b/clang/test/CodeGenOpenCLCXX/addrspace-constructors.clcpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 %s -emit-llvm -o - -O0 -triple spir-unknown-unknown | 
FileCheck %s
+
+// CHECK: %struct.X = type { i32 }
+
+// CHECK: @ci = dso_local addrspace(2) constant i32 0
+// CHECK: @gi = dso_local addrspace(1) global i32 0
+__constant int ci = 0;
+__global int gi = 0;
+
+struct X {
+  int x;
+
+  // Local variables are handled in local_addrspace_init.clcpp
+  // FIXME: __private and __generic constructors clash for __private variable
+  // X() /*__generic*/ = default;
+  X() __private : x(0) {}
+  X() __global : x(0) {}
+  constexpr X() __constant : x(0) {}
+  constexpr X(int x) __constant : x(x) {}
+};
+
+// CHECK: @cx1 = dso_local addrspace(2) constant %struct.X zeroinitializer
+// CHECK: @cx2 = dso_local addrspace(2) constant %struct.X { i32 1 }
+// CHECK: @gx = dso_local addrspace(1) global %struct.X zeroinitializer
+__constant X cx1;
+__constant X cx2(1);
+__global X gx;
+
+// CHECK: @_ZZ1kE3cx1 = internal addrspace(2) constant %struct.X 
zeroinitializer
+// CHECK: @_ZZ1kE3cx2 = internal addrspace(2) constant %struct.X { i32 1 }
+
+kernel void k() {
+  // Check that the constructor for px is executed
+  // CHECK: %px = alloca %struct.X
+  // CHECK-NEXT: call spir_func void @_ZN1XC1Ev(%struct.X* {{.*}}%px)
+  __private X px;
+
+  __constant X cx1;
+  __constant X cx2(1);
+  // CHECK-NEXT: ret void
+}

diff  --git a/clang/test/SemaOpenCLCXX/addrspace-constructors.clcpp 
b/clang/test/SemaOpenCLCXX/addrspace-constructors.clcpp
new file mode 100644
index 0..9154d579a9b4a
--- /dev/null
+++ b/clang/test/SemaOpenCLCXX/addrspace-constructors.clcpp
@@ -0,0 +1,45 @@
+// 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 

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

2021-05-18 Thread Ole Strohm via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG642d2f000b26: [OpenCL] Fix initialization of __constant 
constructors without arguments (authored by olestrohm).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102248

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

Index: clang/test/SemaOpenCLCXX/addrspace-constructors.clcpp
===
--- /dev/null
+++ clang/test/SemaOpenCLCXX/addrspace-constructors.clcpp
@@ -0,0 +1,45 @@
+// 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;
+  // The address space is deduced to be __generic if omitted
+  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;
+  // Can't default constexpr constructors
+  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/test/CodeGenOpenCLCXX/addrspace-constructors.clcpp
===
--- /dev/null
+++ clang/test/CodeGenOpenCLCXX/addrspace-constructors.clcpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 %s -emit-llvm -o - -O0 -triple spir-unknown-unknown | FileCheck %s
+
+// CHECK: %struct.X = type { i32 }
+
+// CHECK: @ci = dso_local addrspace(2) constant i32 0
+// CHECK: @gi = dso_local addrspace(1) global i32 0
+__constant int ci = 0;
+__global int gi = 0;
+
+struct X {
+  int x;
+
+  // Local variables are handled in local_addrspace_init.clcpp
+  // FIXME: __private and __generic constructors clash for __private variable
+  // X() /*__generic*/ = default;
+  X() __private : x(0) {}
+  X() __global : x(0) {}
+  constexpr X() __constant : x(0) {}
+  constexpr X(int x) __constant : x(x) {}
+};
+
+// CHECK: @cx1 = dso_local addrspace(2) constant %struct.X zeroinitializer
+// CHECK: @cx2 = dso_local addrspace(2) constant %struct.X { i32 1 }
+// CHECK: @gx = dso_local addrspace(1) global %struct.X zeroinitializer
+__constant X cx1;
+__constant X cx2(1);
+__global X gx;
+
+// CHECK: @_ZZ1kE3cx1 = internal addrspace(2) constant %struct.X zeroinitializer
+// CHECK: @_ZZ1kE3cx2 = internal addrspace(2) constant %struct.X { i32 1 }
+
+kernel void k() {
+  // Check that the constructor for px is executed
+  // CHECK: %px = alloca %struct.X
+  // CHECK-NEXT: call spir_func void @_ZN1XC1Ev(%struct.X* {{.*}}%px)
+  __private X px;
+
+  __constant X cx1;
+  __constant X cx2(1);
+  // CHECK-NEXT: ret void
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -12635,9 +12635,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->is

[PATCH] D102149: [analyzer][ctu] Allow loading invocation list from a compilation database automatically detected from the ctu-dir

2021-05-18 Thread Ella Ma via Phabricator via cfe-commits
OikawaKirie added a comment.

In D102149#2765402 , @martong wrote:

> Thank you @OikawaKirie for working on this many CTU related patches! I am 
> going to find time for a thorough review and going to pursue @gamesh411 as 
> well to do the same! On the other hand, it would be really useful if you 
> could build a "Stack" from these patches, I mean could you please set which 
> patch depends from which other (see "Edit related revisions")?

To make it easier to review, all these recently submitted patches are based on 
the `main` branch. Their code does not depend on each other.

Logically, they can be separated into two branches: invocation list and ctu 
index.
The invocation list related patches target on constructing the invocation list 
in ASTLoader from a compilation database. And the problems of using invocation 
lists are also fixed.
Whereas the ctu index related patches mainly focus on the delimiter character 
in the ctu index, which is generated by the `clang-extdef-mapping` tool.

If the "stack" means the logical relations, I will update that later. 
Otherwise, it is OK to start with any of the patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102149

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


[PATCH] D102643: [analyzer][Z3][NFC] Use GTEST_SKIP instead of hacks

2021-05-18 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus accepted this revision.
Szelethus added a comment.
This revision is now accepted and ready to land.

Cheers!


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

https://reviews.llvm.org/D102643

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


[clang] 2ab513c - [SYCL] Enable `opencl_global_[host,device]` attributes for SYCL

2021-05-18 Thread Alexey Bader via cfe-commits

Author: Alexey Bader
Date: 2021-05-18T10:27:35+03:00
New Revision: 2ab513cd3e0648806db7ed1f8170ad4a3d4e7749

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

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

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

Added: 


Modified: 
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

Removed: 




diff  --git a/clang/docs/SYCLSupport.rst b/clang/docs/SYCLSupport.rst
index d45ecfbea53f8..6b529e3eb0127 100644
--- a/clang/docs/SYCLSupport.rst
+++ b/clang/docs/SYCLSupport.rst
@@ -34,10 +34,20 @@ the address space qualifier inference as detailed in
 
 The default address space is "generic-memory", which is a virtual address space
 that overlaps the global, local, and private address spaces. SYCL mode enables
-explicit conversions to/from the default address space from/to the address
-space-attributed type and implicit conversions from the address 
space-attributed
-type to the default address space. All named address spaces are disjoint and
-sub-sets of default address space.
+following conversions:
+
+- explicit conversions to/from the default address space from/to the address
+  space-attributed type
+- implicit conversions from the address space-attributed type to the default
+  address space
+- explicit conversions to/from the global address space from/to the
+  ``__attribute__((opencl_global_device))`` or
+  ``__attribute__((opencl_global_host))`` address space-attributed type
+- implicit conversions from the ``__attribute__((opencl_global_device))`` or
+  ``__attribute__((opencl_global_host))`` address space-attributed type to the
+  global address space
+
+All named address spaces are disjoint and sub-sets of default address space.
 
 The SPIR target allocates SYCL namespace scope variables in the global address
 space.
@@ -93,6 +103,10 @@ space attributes for pointers:
  - SYCL address_space enumeration
* - ``__attribute__((opencl_global))``
  - global_space, constant_space
+   * - ``__attribute__((opencl_global_device))``
+ - global_space
+   * - ``__attribute__((opencl_global_host))``
+ - global_space
* - ``__attribute__((opencl_local))``
  - local_space
* - ``__attribute__((opencl_private))``

diff  --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index 84de51aba5b2d..9f46d53378976 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -486,13 +486,16 @@ class Qualifiers {
// allocated on device, which are a subset of __global.
(A == LangAS::opencl_global && (B == LangAS::opencl_global_device ||
B == LangAS::opencl_global_host)) ||
+   (A == LangAS::sycl_global && (B == LangAS::sycl_global_device ||
+ B == LangAS::sycl_global_host)) ||
// Consider pointer size address spaces to be equivalent to default.
((isPtrSizeAddressSpace(A) || A == LangAS::Default) &&
 (isPtrSizeAddressSpace(B) || B == LangAS::Default)) ||
// Default is a superset of SYCL address spaces.
(A == LangAS::Default &&
 (B == LangAS::sycl_private || B == LangAS::sycl_local ||
- B == LangAS::sycl_global));
+ B == LangAS::sycl_global || B == LangAS::sycl_global_device ||
+ B == LangAS::sycl_global_host));
   }
 
   /// Returns true if the address space in these qualifiers is equal to or

diff  --git a/clang/include/clang/Basic/AddressSpaces.h 
b/clang/include/clang/Basic/AddressSpaces.h
index 5fa031250a629..99bb67fd26d19 100644
--- a/clang/include/clang/Basic/AddressSpaces.h
+++ b/clang/include/clang/Basic/AddressSpaces.h
@@ -46,6 +46,8 @@ enum class LangAS : unsigned {
 
   // SYCL specific address spaces.
   sycl_global,
+  sycl_global_device,
+  sycl_global_host,
   sycl_local,
   sycl_private,
 

diff  --git a/clang/include/clang/Sema/ParsedAttr.h 
b/clang/include/clang/Sema/ParsedAttr.h
index 347925873b30f..f47f557adeb10 100644
--- a/clang/include/clang/Sema/ParsedAttr.h
+++ b/clang/include/clang/Sema/ParsedAttr.h
@@ -657,6 +657,10 @@ class ParsedAttr final
 switch (getKind()) {
 case 

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

2021-05-18 Thread Alexey Bader 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 rG2ab513cd3e06: [SYCL] Enable `opencl_global_[host,device]` 
attributes for SYCL (authored by bader).

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<8388650L>' 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(

[PATCH] D100276: [clang] p1099 3/5: using Enum::member

2021-05-18 Thread Nathan Sidwell via Phabricator via cfe-commits
urnathan added a comment.

good, it appears the patch bot fail is fixed -- it seems unhappy with 
non-tree-like dependency graphs, and tries to apply each reachable patch as 
many times as it is reachable :(
The data race failure seems entirely unconnected with this patch -- please 
correct me if I'm wrong.


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

https://reviews.llvm.org/D100276

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


[PATCH] D102241: [clang] p1099 4/5: using enum EnumTag

2021-05-18 Thread Nathan Sidwell via Phabricator via cfe-commits
urnathan updated this revision to Diff 346107.
urnathan added a comment.

updating to reset dependency graph and coax build bot into working


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

https://reviews.llvm.org/D102241

Files:
  clang-tools-extra/clangd/FindTarget.cpp
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/AST/JSONNodeDumper.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/TextNodeDumper.h
  clang/include/clang/Basic/DeclNodes.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Index/IndexSymbol.h
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Sema/Template.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/Decl.cpp
  clang/lib/AST/DeclBase.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/AST/DeclPrinter.cpp
  clang/lib/AST/JSONNodeDumper.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Index/IndexSymbol.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Sema/SemaCXXScopeSpec.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/test/AST/ast-dump-using-enum.cpp
  clang/test/SemaCXX/cxx20-using-enum.cpp
  clang/tools/libclang/CIndex.cpp

Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -6540,6 +6540,7 @@
   }
 
   case Decl::Using:
+  case Decl::UsingEnum:
 return MakeCursorOverloadedDeclRef(cast(D), D->getLocation(),
TU);
 
Index: clang/test/SemaCXX/cxx20-using-enum.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx20-using-enum.cpp
@@ -0,0 +1,233 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++17 -verify %s
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+
+// p1099 'using enum ELABORATED-ENUM-SPECIFIER ;'
+
+namespace One {
+namespace Bob {
+enum A { a, // expected-note{{declared here}}
+ b,
+ c };
+class C; // expected-note{{previous use}}
+enum class D : int;
+enum class D { d,
+   e,
+   f };
+enum class D : int;
+} // namespace Bob
+
+using enum Bob::A;
+#if __cplusplus < 202002
+// expected-warning@-2{{is a C++20 extension}}
+#endif
+using enum Bob::B; // expected-error{{no enum named 'B'}}
+#if __cplusplus < 202002
+// expected-warning@-2{{is a C++20 extension}}
+#endif
+using enum Bob::C; // expected-error{{tag type that does not match}}
+#if __cplusplus < 202002
+// expected-warning@-2{{is a C++20 extension}}
+#endif
+auto v = a;
+
+A g; // expected-error{{unknown type name 'A'}}
+
+int A;
+
+using enum Bob::D;
+#if __cplusplus < 202002
+// expected-warning@-2{{is a C++20 extension}}
+#endif
+} // namespace One
+
+namespace Two {
+namespace Kevin {
+enum class B { d,
+   e,
+   f };
+}
+
+using enum Kevin::B;
+#if __cplusplus < 202002
+// expected-warning@-2{{is a C++20 extension}}
+#endif
+auto w = e;
+
+} // namespace Two
+
+#if __cplusplus >= 202002
+// Now only check c++20 onwards
+
+namespace Three {
+namespace Stuart {
+enum class C : int; // expected-note{{declared here}}
+}
+
+using enum Stuart::C; // expected-error{{is incomplete}}
+} // namespace Three
+
+namespace Four {
+class Dave {
+public:
+  enum D { a,
+   b,
+   c };
+
+private:
+  enum class E { d, // expected-note{{declared private here}}
+ e,
+ f };
+};
+
+using enum Dave::D;
+using enum Dave::E; // expected-error{{is a private member}}
+
+} // namespace Four
+
+namespace Five {
+enum class A { b,
+   c };
+class Dave {
+public:
+  using enum A;
+  A f = b;
+};
+
+} // namespace Five
+
+namespace Six {
+template  class TPL;
+template <> class TPL {
+public:
+  enum A { a };
+};
+
+template  class USR {
+  using enum TPL::B; // expected-error{{cannot name a dependent type}}
+  using enum TPL::A;
+};
+} // namespace Six
+
+// Now instantiate things
+namespace Seven {
+namespace Stuart {
+enum class A { a,
+   b,
+   c };
+}
+
+static_assert(!int(Stuart::A::a));
+constexpr int Bar() {
+  using enum Stuart::A;
+  return int(b);
+}
+static_assert(Bar() == 1);
+
+template  constexpr int Foo() {
+  using enum Stuart::A;
+  return int(b) + I;
+}
+
+static_assert(Foo<10>() == 11);
+
+template  struct C {
+  using enum Stuart::A;
+  static constexpr int V = int(c) + I;
+
+  enum class D { d,
+ e,
+ f };
+  using enu

[PATCH] D102241: [clang] p1099 4/5: using enum EnumTag

2021-05-18 Thread Nathan Sidwell via Phabricator via cfe-commits
urnathan added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:4654
+
+  return ImportUsingShadowDecls(D, ToUsingEnum);
 }

martong wrote:
> Could it work if you imported the shadow declarations **before** creating the 
> `UsingEnumDecl`? I yes, then that would be the preferred approach b/c that 
> would fix the `// FIXME: We return error here but the definition is already 
> created`.
Unfortunately the shadow decls refer back to the using decl, so we must do it 
in this order.  This is the same comment as in the existing UsingDecl importer, 
not a new fixme unique to using-enum.


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

https://reviews.llvm.org/D102241

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


[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

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

Looks like this is also failing on s390x:

  error: Added modules have incompatible data layouts: 
E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-a:8:16-n32:64 (module) vs 
E-m:e-i1:8:16-i8:8:16-i64:64-f128:64-v128:64-a:8:16-n32:64 (jit)

The problem here is that on s390x we use a different data layout on machines 
with vector registers vs. machines without.   The (module) string above is the 
version without vector registers (which is presumably selected because there is 
no -march= argument and the compiler therefore defaults to an old machine), and 
the (jit) string is the version with vector registers (which is presumably 
because the jit auto-detected that it is running on a new machine).

I guess we should either tell the JIT to not autodetect the current processor, 
or else tell the compiler to target the processor that the JIT autodetected?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96033

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


[PATCH] D97085: [OpenMP] libomp: implement OpenMP 5.1 inoutset task dependence type

2021-05-18 Thread Joachim Protze via Phabricator via cfe-commits
protze.joachim added inline comments.



Comment at: openmp/runtime/src/kmp_taskdeps.cpp:344-346
+// link node as successor of all nodes in the prev_set if any
+npredecessors +=
+__kmp_depnode_link_successor(gtid, thread, task, node, prev_set);

AndreyChurbanov wrote:
> protze.joachim wrote:
> > If I understand this code right, this has O(n^2) complexity for two sets of 
> > size n?
> > 
> > Consider:
> > ```
> > for (int i=0; i > #pragma omp task depend(in:A)
> > work(A,i);
> > }
> > for (int i=0; i > #pragma omp task depend(inoutset:A)
> > work(A,i);
> > }
> > ```
> > All n tasks in the first loop would be predecessor for each of the tasks in 
> > the second loop. This will also result in n^2 releases/notifications.
> > 
> > 
> > I'd suggest to model the dependencies like:
> > ```
> > for (int i=0; i > #pragma omp task depend(in:A)
> > work(A,i);
> > }
> > #pragma omp taskwait depend(inout:A) nowait
> > for (int i=0; i > #pragma omp task depend(inoutset:A)
> > work(A,i);
> > }
> > ```
> > I.e., add a dummy dependency node between the two sets, which has n 
> > predecessors and n successors. You probably understand the depnode code 
> > better, than I do, but I think you would only need to add some code in line 
> > 357, where `last_set` is moved to `prev_set`.
> > This dummy node would reduce linking and releasing complexity to O(n).
> This could be a separate research project.  Because such change may cause 
> performance regressions on some real codes, so it needs thorough 
> investigation.  I mean insertion of an auxiliary dummy node into dependency 
> graph is definitely an overhead, which may or may not be overridden by 
> reduction in number of edges in the graph.  Or it can be made optional 
> optimization under an external control, if there is a significant gain in 
> some particular case.
I don't suggest to insert the auxiliary node in the general case. Just for the 
case that you see a transition of `in` -> `inoutset` or vice versa.

With current task dependencies, you always have 1 node notifying n nodes (`out` 
-> `in`) or n nodes notifying one node (`in` -> `out`). You can see this as an 
amortized O(1) operation per task in the graph.

Here you introduce a code pattern, where n nodes each will need to notify m 
other nodes. This leads to an O(n) operation per task. I'm really worried about 
the complexity of this pattern.
If there is no use case with large n, I don't understand, why `inoutset` was 
introduced in the first place.


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

https://reviews.llvm.org/D97085

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


[PATCH] D102670: [clang-offload-bundler] Add sections and set section flags using one llvm-objcopy invocation

2021-05-18 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/D102670/new/

https://reviews.llvm.org/D102670

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


[PATCH] D102683: [analyzer] Check the checker name, rather than the ProgramPointTag when silencing a checker

2021-05-18 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

While I still see checker silencing as a solution to a problem that shouldn't 
exist, I'm unsure about the amount of tedious and invasive work required to 
make the underlying infrastructure elegant just for the sake of it being 
elegant. Most notably, checker silencing solves the problem where a checker 
finds fatal errors -- disabling such a checker also gets rid of the sink node, 
which makes the entire analysis behave differently. This is desirable, as 
explained by @a.sidorin in 
https://lists.llvm.org/pipermail/cfe-dev/2019-August/063135.html. Although I 
still have concerns about the user interface if we promoted checker silencing 
to be user facing, it might be worth investigating a bit further.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102683

___
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-18 Thread Alexey Bader via Phabricator via cfe-commits
bader accepted this revision.
bader added a comment.
This revision is now accepted and ready to land.

Sorry for the delay.
LGTM. Thanks!


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] D28080: [Docs][OpenCL] Added OpenCL feature description to user manual.

2021-05-18 Thread Alexey Bader via Phabricator via cfe-commits
bader closed this revision.
bader added a comment.
Herald added subscribers: ebevhan, arphaman.

Closed by https://reviews.llvm.org/rG18e165f50d8c1ab3afe7098dc00557d5f1a43cfa.


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

https://reviews.llvm.org/D28080

___
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-18 Thread Paul C. Anagnostopoulos via Phabricator via cfe-commits
Paul-C-Anagnostopoulos added a comment.

Could I get an LGTM on this? I have removed the spurious comment.


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] D102688: [clang-repl] Better match the underlying architecture.

2021-05-18 Thread Vassil Vassilev via Phabricator via cfe-commits
v.g.vassilev created this revision.
v.g.vassilev added reviewers: hubert.reinterpretcast, uweigand.
v.g.vassilev requested review of this revision.

In cases where `-fno-integrated-as` is specified we should overwrite the 
`EmitAssembly` action as well.

We also should rely on the target triple from the process at least until we 
implement out-of-process execution.

This patch should improve clang-repl on AIX.

Discussion available at: https://reviews.llvm.org/D96033


Repository:
  rC Clang

https://reviews.llvm.org/D102688

Files:
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/Interpreter.cpp


Index: clang/lib/Interpreter/Interpreter.cpp
===
--- clang/lib/Interpreter/Interpreter.cpp
+++ clang/lib/Interpreter/Interpreter.cpp
@@ -157,7 +157,7 @@
   ParseDiagnosticArgs(*DiagOpts, ParsedArgs, &Diags);
 
   driver::Driver Driver(/*MainBinaryName=*/ClangArgv[0],
-llvm::sys::getDefaultTargetTriple(), Diags);
+llvm::sys::getProcessTriple(), Diags);
   Driver.setCheckInputsExist(false); // the input comes from mem buffers
   llvm::ArrayRef RF = llvm::makeArrayRef(ClangArgv);
   std::unique_ptr 
Compilation(Driver.BuildCompilation(RF));
Index: clang/lib/Interpreter/IncrementalParser.cpp
===
--- clang/lib/Interpreter/IncrementalParser.cpp
+++ clang/lib/Interpreter/IncrementalParser.cpp
@@ -54,7 +54,8 @@
 Err = llvm::createStringError(
 std::errc::state_not_recoverable,
 "Driver initialization failed. "
-"Incremental mode for action is not supported");
+"Incremental mode for action %d is not supported",
+CI.getFrontendOpts().ProgramAction);
 return Act;
   case frontend::ASTDump:
 LLVM_FALLTHROUGH;
@@ -63,6 +64,8 @@
   case frontend::ParseSyntaxOnly:
 Act = CreateFrontendAction(CI);
 break;
+  case frontend::EmitAssembly:
+LLVM_FALLTHROUGH;
   case frontend::EmitObj:
 LLVM_FALLTHROUGH;
   case frontend::EmitLLVMOnly:


Index: clang/lib/Interpreter/Interpreter.cpp
===
--- clang/lib/Interpreter/Interpreter.cpp
+++ clang/lib/Interpreter/Interpreter.cpp
@@ -157,7 +157,7 @@
   ParseDiagnosticArgs(*DiagOpts, ParsedArgs, &Diags);
 
   driver::Driver Driver(/*MainBinaryName=*/ClangArgv[0],
-llvm::sys::getDefaultTargetTriple(), Diags);
+llvm::sys::getProcessTriple(), Diags);
   Driver.setCheckInputsExist(false); // the input comes from mem buffers
   llvm::ArrayRef RF = llvm::makeArrayRef(ClangArgv);
   std::unique_ptr Compilation(Driver.BuildCompilation(RF));
Index: clang/lib/Interpreter/IncrementalParser.cpp
===
--- clang/lib/Interpreter/IncrementalParser.cpp
+++ clang/lib/Interpreter/IncrementalParser.cpp
@@ -54,7 +54,8 @@
 Err = llvm::createStringError(
 std::errc::state_not_recoverable,
 "Driver initialization failed. "
-"Incremental mode for action is not supported");
+"Incremental mode for action %d is not supported",
+CI.getFrontendOpts().ProgramAction);
 return Act;
   case frontend::ASTDump:
 LLVM_FALLTHROUGH;
@@ -63,6 +64,8 @@
   case frontend::ParseSyntaxOnly:
 Act = CreateFrontendAction(CI);
 break;
+  case frontend::EmitAssembly:
+LLVM_FALLTHROUGH;
   case frontend::EmitObj:
 LLVM_FALLTHROUGH;
   case frontend::EmitLLVMOnly:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

2021-05-18 Thread Vassil Vassilev via Phabricator via cfe-commits
v.g.vassilev added a comment.

@hubert.reinterpretcast, thanks for the feedback. I have created a patch as 
discussed -- https://reviews.llvm.org/D102688

@uweigand, thanks for reaching out. I believe the patch above should fix your 
setup. Could you confirm?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96033

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


[PATCH] D102689: [C++4OpenCL] Allow address space conversion in reinterpret_cast

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

Allow converting between types with different address spaces.

This allows converting a `__private int` to a `__private int`, which is 
currently not possible.
It also allows converting a value to any other address space, which can make 
sense since
the actual bit representation of the values doesn't depend on the address space.

This is the solution I chose currently allows converting between any address 
space
because the address space of `SrcExpr` is erased before entering the function,
so allowing only converting when the address spaces is the same would require 
larger changes.

I'm not sure if this conversion should be allowed, though converting to the 
exact same type definitely should.

Fixes the first issue in PR49221


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102689

Files:
  clang/lib/Sema/SemaCast.cpp
  clang/test/SemaOpenCLCXX/reinterpret-cast.clcpp


Index: clang/test/SemaOpenCLCXX/reinterpret-cast.clcpp
===
--- clang/test/SemaOpenCLCXX/reinterpret-cast.clcpp
+++ clang/test/SemaOpenCLCXX/reinterpret-cast.clcpp
@@ -13,6 +13,11 @@
   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}}
   auto i2_to_i2 = reinterpret_cast(i2);
 
+  __private short s;
+  auto s2 = reinterpret_cast<__private short>(s);
+  auto s3 = reinterpret_cast(s);
+  auto s4 = reinterpret_cast<__global short>(s);
+
   // Only integral types (and pointer/references) can be reinterpret casted to 
themselves.
   // Currently this does not include any opencl types.
   reserve_id_t r_id1;
Index: clang/lib/Sema/SemaCast.cpp
===
--- clang/lib/Sema/SemaCast.cpp
+++ clang/lib/Sema/SemaCast.cpp
@@ -2356,7 +2356,10 @@
 return TC_Failed;
   }
 
-  if (SrcType == DestType) {
+  if (SrcType == DestType ||
+  (Self.LangOpts.OpenCL &&
+Self.Context.removeAddrSpaceQualType(SrcType) ==
+  Self.Context.removeAddrSpaceQualType(DestType))) {
 // C++ 5.2.10p2 has a note that mentions that, subject to all other
 // restrictions, a cast to the same type is allowed so long as it does not
 // cast away constness. In C++98, the intent was not entirely clear here,


Index: clang/test/SemaOpenCLCXX/reinterpret-cast.clcpp
===
--- clang/test/SemaOpenCLCXX/reinterpret-cast.clcpp
+++ clang/test/SemaOpenCLCXX/reinterpret-cast.clcpp
@@ -13,6 +13,11 @@
   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}}
   auto i2_to_i2 = reinterpret_cast(i2);
 
+  __private short s;
+  auto s2 = reinterpret_cast<__private short>(s);
+  auto s3 = reinterpret_cast(s);
+  auto s4 = reinterpret_cast<__global short>(s);
+
   // Only integral types (and pointer/references) can be reinterpret casted to themselves.
   // Currently this does not include any opencl types.
   reserve_id_t r_id1;
Index: clang/lib/Sema/SemaCast.cpp
===
--- clang/lib/Sema/SemaCast.cpp
+++ clang/lib/Sema/SemaCast.cpp
@@ -2356,7 +2356,10 @@
 return TC_Failed;
   }
 
-  if (SrcType == DestType) {
+  if (SrcType == DestType ||
+  (Self.LangOpts.OpenCL &&
+Self.Context.removeAddrSpaceQualType(SrcType) ==
+  Self.Context.removeAddrSpaceQualType(DestType))) {
 // C++ 5.2.10p2 has a note that mentions that, subject to all other
 // restrictions, a cast to the same type is allowed so long as it does not
 // cast away constness. In C++98, the intent was not entirely clear here,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 7d64493 - [DebugInfo][test] Check specific func name to ignore codegen differences

2021-05-18 Thread Jinsong Ji via cfe-commits

Author: Jinsong Ji
Date: 2021-05-18T14:03:27Z
New Revision: 7d6449322ecba2fa34090ca8ed610328febee108

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

LOG: [DebugInfo][test] Check specific func name to ignore codegen differences

We use `CHECK-LABEL: define` to divide input stream into functions,
this works well on most platforms.

But there are cases that some platforms (eg: AIX) may have different
codegen , especially for global constructor and descructors.

On AIX, the codegen will have two more functions: __dtor_b,
__finalize_b, which will fail the test.

The fix is to use specific function name so that we can safely ignore
those unrelated codegen differences.

Reviewed By: dblaikie

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

Added: 


Modified: 
clang/test/CodeGenCXX/debug-info-line.cpp

Removed: 




diff  --git a/clang/test/CodeGenCXX/debug-info-line.cpp 
b/clang/test/CodeGenCXX/debug-info-line.cpp
index 3c09b94b0f8e8..2581ea0712af3 100644
--- a/clang/test/CodeGenCXX/debug-info-line.cpp
+++ b/clang/test/CodeGenCXX/debug-info-line.cpp
@@ -146,7 +146,7 @@ bar b[1] = { //
 (fn(),   //
  bar())};
 
-// CHECK-LABEL: define
+// CHECK-LABEL: define{{.*}}f11
 __complex double f11() {
   __complex double f;
 // CHECK: store {{.*}} !dbg [[DBG_F11:!.*]]



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


[PATCH] D102654: [DebugInfo][test] Check specific func name to ignore codegen differences

2021-05-18 Thread Jinsong Ji via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
jsji marked an inline comment as done.
Closed by commit rG7d6449322ecb: [DebugInfo][test] Check specific func name to 
ignore codegen differences (authored by jsji).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102654

Files:
  clang/test/CodeGenCXX/debug-info-line.cpp


Index: clang/test/CodeGenCXX/debug-info-line.cpp
===
--- clang/test/CodeGenCXX/debug-info-line.cpp
+++ clang/test/CodeGenCXX/debug-info-line.cpp
@@ -146,7 +146,7 @@
 (fn(),   //
  bar())};
 
-// CHECK-LABEL: define
+// CHECK-LABEL: define{{.*}}f11
 __complex double f11() {
   __complex double f;
 // CHECK: store {{.*}} !dbg [[DBG_F11:!.*]]


Index: clang/test/CodeGenCXX/debug-info-line.cpp
===
--- clang/test/CodeGenCXX/debug-info-line.cpp
+++ clang/test/CodeGenCXX/debug-info-line.cpp
@@ -146,7 +146,7 @@
 (fn(),   //
  bar())};
 
-// CHECK-LABEL: define
+// CHECK-LABEL: define{{.*}}f11
 __complex double f11() {
   __complex double f;
 // CHECK: store {{.*}} !dbg [[DBG_F11:!.*]]
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D102492: [clang][AST] Add support for BindingDecl to ASTImporter.

2021-05-18 Thread Balázs Kéri via Phabricator via cfe-commits
balazske updated this revision to Diff 346169.
balazske added a comment.

Improved the test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102492

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

Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -3665,6 +3665,52 @@
   EXPECT_TRUE(ImportedD->getDefinition());
 }
 
+TEST_P(ImportVariables, ImportBindingDecl) {
+  Decl *From, *To;
+  std::tie(From, To) = getImportedDecl(
+  R"(
+  void declToImport() {
+int a[2] = {1,2};
+auto [x1,y1] = a;
+auto& [x2,y2] = a;
+
+struct S {
+  mutable int x1 : 2;
+  volatile double y1;
+};
+S b;
+const auto [x3, y3] = b;
+  };
+  )",
+  Lang_CXX17, "", Lang_CXX17);
+
+  TranslationUnitDecl *FromTU = From->getTranslationUnitDecl();
+  auto *FromF = FirstDeclMatcher().match(
+  FromTU, functionDecl(hasName("declToImport")));
+  auto *ToF = Import(FromF, Lang_CXX17);
+  EXPECT_TRUE(ToF);
+
+  auto VerifyImport = [&](llvm::StringRef BindName) {
+auto *FromB = FirstDeclMatcher().match(
+FromF, bindingDecl(hasName(BindName)));
+ASSERT_TRUE(FromB);
+auto *ToB = Import(FromB, Lang_CXX17);
+EXPECT_TRUE(ToB);
+EXPECT_EQ(FromB->getBinding() != nullptr, ToB->getBinding() != nullptr);
+EXPECT_EQ(FromB->getDecomposedDecl() != nullptr,
+  ToB->getDecomposedDecl() != nullptr);
+EXPECT_EQ(FromB->getHoldingVar() != nullptr,
+  ToB->getHoldingVar() != nullptr);
+  };
+
+  VerifyImport("x1");
+  VerifyImport("y1");
+  VerifyImport("x2");
+  VerifyImport("y2");
+  VerifyImport("x3");
+  VerifyImport("y3");
+}
+
 struct ImportClasses : ASTImporterOptionSpecificTestBase {};
 
 TEST_P(ImportClasses, ImportDefinitionWhenProtoIsInNestedToContext) {
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -481,6 +481,7 @@
 ExpectedDecl VisitAccessSpecDecl(AccessSpecDecl *D);
 ExpectedDecl VisitStaticAssertDecl(StaticAssertDecl *D);
 ExpectedDecl VisitTranslationUnitDecl(TranslationUnitDecl *D);
+ExpectedDecl VisitBindingDecl(BindingDecl *D);
 ExpectedDecl VisitNamespaceDecl(NamespaceDecl *D);
 ExpectedDecl VisitNamespaceAliasDecl(NamespaceAliasDecl *D);
 ExpectedDecl VisitTypedefNameDecl(TypedefNameDecl *D, bool IsAlias);
@@ -2274,6 +2275,36 @@
   return ToD;
 }
 
+ExpectedDecl ASTNodeImporter::VisitBindingDecl(BindingDecl *D) {
+  DeclContext *DC, *LexicalDC;
+  DeclarationName Name;
+  SourceLocation Loc;
+  NamedDecl *ToND;
+  if (Error Err = ImportDeclParts(D, DC, LexicalDC, Name, ToND, Loc))
+return std::move(Err);
+  if (ToND)
+return ToND;
+
+  Error Err = Error::success();
+  auto ToType = importChecked(Err, D->getType());
+  auto ToBinding = importChecked(Err, D->getBinding());
+  auto ToDecomposedDecl = importChecked(Err, D->getDecomposedDecl());
+  if (Err)
+return std::move(Err);
+
+  BindingDecl *ToD;
+  if (GetImportedOrCreateDecl(ToD, D, Importer.getToContext(), DC, Loc,
+  Name.getAsIdentifierInfo()))
+return ToD;
+
+  ToD->setLexicalDeclContext(LexicalDC);
+  DC->addDeclInternal(ToD);
+  ToD->setBinding(ToType, ToBinding);
+  ToD->setDecomposedDecl(ToDecomposedDecl);
+
+  return ToD;
+}
+
 ExpectedDecl ASTNodeImporter::VisitAccessSpecDecl(AccessSpecDecl *D) {
   ExpectedSLoc LocOrErr = import(D->getLocation());
   if (!LocOrErr)
___
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-18 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 accepted this revision.
jansvoboda11 added a comment.
This revision is now accepted and ready to land.

LGTM provided the output file stays the same.


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] D102688: [clang-repl] Better match the underlying architecture.

2021-05-18 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast accepted this revision.
hubert.reinterpretcast added a comment.
This revision is now accepted and ready to land.

LGTM; thanks!


Repository:
  rC Clang

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

https://reviews.llvm.org/D102688

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


[clang] 6381664 - Introduce SYCL 2020 mode

2021-05-18 Thread Aaron Ballman via cfe-commits

Author: Aaron Ballman
Date: 2021-05-18T10:34:14-04:00
New Revision: 6381664580080f015bc0c2ec647853f697cf744a

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

LOG: Introduce SYCL 2020 mode

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.

Added: 


Modified: 
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

Removed: 




diff  --git a/clang/include/clang/Basic/LangOptions.def 
b/clang/include/clang/Basic/LangOptions.def
index 31a42e83fd0e4..20c03987bd027 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -252,7 +252,7 @@ LANGOPT(GPUExcludeWrongSideOverloads, 1, 0, "always exclude 
wrong side overloads
 
 LANGOPT(SYCLIsDevice  , 1, 0, "Generate code for SYCL device")
 LANGOPT(SYCLIsHost, 1, 0, "SYCL host compilation")
-ENUM_LANGOPT(SYCLVersion  , SYCLMajorVersion, 1, SYCL_None, "Version of the 
SYCL standard used")
+ENUM_LANGOPT(SYCLVersion  , SYCLMajorVersion, 2, SYCL_None, "Version of the 
SYCL standard used")
 
 LANGOPT(HIPUseNewLaunchAPI, 1, 0, "Use new kernel launching API for HIP")
 

diff  --git a/clang/include/clang/Basic/LangOptions.h 
b/clang/include/clang/Basic/LangOptions.h
index 524b79b138140..454c101b21425 100644
--- a/clang/include/clang/Basic/LangOptions.h
+++ b/clang/include/clang/Basic/LangOptions.h
@@ -130,6 +130,10 @@ class LangOptions : public LangOptionsBase {
   enum SYCLMajorVersion {
 SYCL_None,
 SYCL_2017,
+SYCL_2020,
+// The "default" SYCL version to be used when none is specified on the
+// frontend command line.
+SYCL_Default = SYCL_2020
   };
 
   /// Clang versions with 
diff erent platform ABI conformance.

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 67d9a2bbc328c..09de6b5a50d00 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5691,8 +5691,8 @@ def fsycl_is_host : Flag<["-"], "fsycl-is-host">,
 def sycl_std_EQ : Joined<["-"], "sycl-std=">, Group,
   Flags<[CC1Option, NoArgumentUnused, CoreOption]>,
   HelpText<"SYCL language standard to compile for.">,
-  Values<"2017,121,1.2.1,sycl-1.2.1">,
-  NormalizedValues<["SYCL_2017", "SYCL_2017", "SYCL_2017", "SYCL_2017"]>,
+  Values<"2020,2017,121,1.2.1,sycl-1.2.1">,
+  NormalizedValues<["SYCL_2020", "SYCL_2017", "SYCL_2017", "SYCL_2017", 
"SYCL_2017"]>,
   NormalizedValuesScope<"LangOptions">,
   MarshallingInfoEnum, "SYCL_None">,
   ShouldParseIf;

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 63ca39ee4e934..afc119263db96 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -4300,8 +4300,8 @@ void Clang::ConstructJob(Compilation &C, const JobAction 
&JA,
 if (Arg *A = Args.getLastArg(options::OPT_sycl_std_EQ)) {
   A->render(Args, CmdArgs);
 } else {
-  // Ensure the default version in SYCL mode is 1.2.1 (aka 2017)
-  CmdArgs.push_back("-sycl-std=2017");
+  // Ensure the default version in SYCL mode is 2020.
+  CmdArgs.push_back("-sycl-std=2020");
 }
   }
 

diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 9cb859f233238..809492a36d3fa 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -3648,6 +3648,16 @@ bool CompilerInvocation::ParseLangArgs(LangOptions 
&Opts, ArgList &Args,
 }
   }
 
+  if ((Args.hasArg(OPT_fsycl_is_device) || Args.hasArg(OPT_fsycl_is_host)) &&
+  !Args.hasArg(OPT_sycl_std_EQ)) {
+// If the user supplied -fsycl-is-device or -fsycl-is-host, but failed to
+// provide -sycl-std=, we want to default it to whatever the default SYCL
+// version is. I could not find a way to express this with the options
+// tablegen because we still want this value to be SYCL_None when the user
+// is not in device or host mode.
+Opts.setSYCLVersion(LangOptions::SYCL_Default);
+  }
+
   if (Opts.ObjC)

[PATCH] D102261: Introduce SYCL 2020 mode

2021-05-18 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman closed this revision.
aaron.ballman added a comment.

Thanks for the review! I've commit in 6381664580080f015bc0c2ec647853f697cf744a 
.


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] D99675: RFC [llvm][clang] Create new intrinsic llvm.arith.fence to control FP optimization at expression level

2021-05-18 Thread Kevin P. Neal via Phabricator via cfe-commits
kpn added a comment.

In D99675#2696327 , @pengfei wrote:

> In D99675#2695424 , @kpn wrote:
>
>> What changes are needed for a backend, and what happens if they aren't done?
>
> As far as I understand it, backend does optimizations based on patterns of 
> the known nodes and MIs. Inserting a new node/MI will block any optimizations 
> across the fence. So it respects the semantics of the intrinsic without 
> target special chenges.
> I'm not sure if there's room for optimization cross the `arithmetic.fence`. 
> If there is and no changes for it, backend may have some performance loss 
> under these circumstances.
>
>> Having something needed for correctness silently not work seems ... 
>> sub-optimal.
>
> I think backend is conservative for optimizations when use the intrinsic. It 
> won't have correctness issue silently, but performance loss might.

OK, that sounds fine, then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99675

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


[PATCH] D102492: [clang][AST] Add support for BindingDecl to ASTImporter.

2021-05-18 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added a comment.

This change in itself is not enough to support `BindingDecl`. The tests pass 
but the resulting AST is not correct because `DecompositionDecl` is not 
imported yet. Still no visible problem happens, the `DecompositionDecl` is just 
visited and imported as a `VarDecl`. The import of `DecompositionDecl` can be 
added later (but I am not sure if without it the new import of `BindingDecl` 
will not cause hidden problems).




Comment at: clang/unittests/AST/ASTImporterTest.cpp:873
+  MatchVerifier Verifier;
+  testImport("int a[2] = {1, 2};"
+ "auto [declToImport, x] = a;",

shafik wrote:
> Can we add a larger variety of tests? Given how simple the `BindingDecl` case 
> seems to be I don't expect any surprises but it would be good to verify that 
> cases like mixed types, references and bit-fields work as expected. 
Improved the test variety a bit. (`std::tuple` is more difficult to handle 
because need for namespace `std`.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102492

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


[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

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

In D96033#2765954 , @v.g.vassilev 
wrote:

> @hubert.reinterpretcast, thanks for the feedback. I have created a patch as 
> discussed -- https://reviews.llvm.org/D102688
>
> @uweigand, thanks for reaching out. I believe the patch above should fix your 
> setup. Could you confirm?

Unfortunately, it does not.  Changing the triple doesn't affect the 
architecture the compiler generates code for.   If you wanted to change the 
compiler to generate code for the architecture the JIT detects, the easiest way 
would probably be to use (the equivalent of) "-march=native", which causes the 
compiler to also auto-detect the current processor in the same way as the JIT 
does.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96033

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


[PATCH] D101986: [InstSimplify] Remove redundant {insert,extract}_vector intrinsic chains

2021-05-18 Thread Paul Walker via Phabricator via cfe-commits
paulwalker-arm added inline comments.



Comment at: llvm/lib/Analysis/InstructionSimplify.cpp:5741-5747
+// (insert_vector _, (extract_vector X, 0), 0) -> X
+unsigned IdxN = cast(Idx)->getZExtValue();
+Value *X = nullptr;
+if (match(SubVec, m_Intrinsic(
+  m_Value(X), m_Zero())) &&
+IdxN == 0 && X->getType() == ReturnType)
+  return X;

Are you sure this transform is correct?  I would have thought the following are 
safe:
```
(insert_vector X, (extract_vector X, 0), 0) -> X
(insert_vector undef, (extract_vector X, 0), 0) -> X
```
when `X->getType() == ReturnType` but nothing else.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101986

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


[clang] 8998a8a - [clang-offload-bundler] Add sections and set section flags using one llvm-objcopy invocation

2021-05-18 Thread Sergey Dmitriev via cfe-commits

Author: Sergey Dmitriev
Date: 2021-05-18T08:44:41-07:00
New Revision: 8998a8aa97f81c758403615ec897ce79c1ccdcad

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

LOG: [clang-offload-bundler] Add sections and set section flags using one 
llvm-objcopy invocation

llvm-objcopy has been changed to support adding a section and updating section 
flags
in one run (D90438), so we can now change clang-offload-bundler to run 
llvm-objcopy
tool only once when creating fat object.

Reviewed By: ABataev

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

Added: 


Modified: 
clang/test/Driver/clang-offload-bundler.c
clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp

Removed: 




diff  --git a/clang/test/Driver/clang-offload-bundler.c 
b/clang/test/Driver/clang-offload-bundler.c
index 32fe6dad1f3f3..f77a240e79b51 100644
--- a/clang/test/Driver/clang-offload-bundler.c
+++ b/clang/test/Driver/clang-offload-bundler.c
@@ -274,8 +274,7 @@
 
 // RUN: clang-offload-bundler -type=o 
-targets=host-%itanium_abi_triple,openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu
 -inputs=%t.o,%t.tgt1,%t.tgt2 -outputs=%t.bundle3.o -### 2>&1 \
 // RUN: | FileCheck %s -DHOST=%itanium_abi_triple -DINOBJ1=%t.o 
-DINOBJ2=%t.tgt1 -DINOBJ3=%t.tgt2 -DOUTOBJ=%t.bundle3.o --check-prefix 
CK-OBJ-CMD
-// CK-OBJ-CMD: llvm-objcopy{{(.exe)?}}" 
"--add-section=__CLANG_OFFLOAD_BUNDLE__host-[[HOST]]={{.*}}" 
"--add-section=__CLANG_OFFLOAD_BUNDLE__openmp-powerpc64le-ibm-linux-gnu=[[INOBJ2]]"
 "--add-section=__CLANG_OFFLOAD_BUNDLE__openmp-x86_64-pc-linux-gnu=[[INOBJ3]]" 
"[[INOBJ1]]" "[[TEMPOBJ:.*]]"
-// CK-OBJ-CMD: llvm-objcopy{{(.exe)?}}" 
"--set-section-flags=__CLANG_OFFLOAD_BUNDLE__host-[[HOST]]=readonly,exclude" 
"--set-section-flags=__CLANG_OFFLOAD_BUNDLE__openmp-powerpc64le-ibm-linux-gnu=readonly,exclude"
 
"--set-section-flags=__CLANG_OFFLOAD_BUNDLE__openmp-x86_64-pc-linux-gnu=readonly,exclude"
 "[[TEMPOBJ]]" "[[OUTOBJ]]"
+// CK-OBJ-CMD: llvm-objcopy{{(.exe)?}}" 
"--add-section=__CLANG_OFFLOAD_BUNDLE__host-[[HOST]]={{.*}}" 
"--set-section-flags=__CLANG_OFFLOAD_BUNDLE__host-[[HOST]]=readonly,exclude" 
"--add-section=__CLANG_OFFLOAD_BUNDLE__openmp-powerpc64le-ibm-linux-gnu=[[INOBJ2]]"
 
"--set-section-flags=__CLANG_OFFLOAD_BUNDLE__openmp-powerpc64le-ibm-linux-gnu=readonly,exclude"
 "--add-section=__CLANG_OFFLOAD_BUNDLE__openmp-x86_64-pc-linux-gnu=[[INOBJ3]]" 
"--set-section-flags=__CLANG_OFFLOAD_BUNDLE__openmp-x86_64-pc-linux-gnu=readonly,exclude"
 "[[INOBJ1]]" "[[OUTOBJ]]"
 
 // RUN: clang-offload-bundler -type=o 
-targets=host-%itanium_abi_triple,openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu
 -inputs=%t.o,%t.tgt1,%t.tgt2 -outputs=%t.bundle3.o
 // RUN: clang-offload-bundler -type=o -inputs=%t.bundle3.o -list | FileCheck 
-check-prefix=CKLST %s

diff  --git a/clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp 
b/clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
index 0b56d19e616c1..74b7a4539aff5 100644
--- a/clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ b/clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -578,11 +578,7 @@ class ObjectFileHandler final : public FileHandler {
 // We will use llvm-objcopy to add target objects sections to the output
 // fat object. These sections should have 'exclude' flag set which tells
 // link editor to remove them from linker inputs when linking executable or
-// shared library. llvm-objcopy currently does not support adding new
-// section and changing flags for the added section in one invocation, and
-// because of that we have to run it two times. First run adds sections and
-// the second changes flags.
-// TODO: change it to one run once llvm-objcopy starts supporting that.
+// shared library.
 
 // Find llvm-objcopy in order to create the bundle binary.
 ErrorOr Objcopy = sys::findProgramByName(
@@ -600,14 +596,8 @@ class ObjectFileHandler final : public FileHandler {
 // Temporary files that need to be removed.
 TempFileHandlerRAII TempFiles;
 
-// Create an intermediate temporary file to save object after the first
-// llvm-objcopy run.
-Expected IntermediateObjOrErr = TempFiles.Create(None);
-if (!IntermediateObjOrErr)
-  return IntermediateObjOrErr.takeError();
-StringRef IntermediateObj = *IntermediateObjOrErr;
-
-// Compose llvm-objcopy command line for add target objects' sections.
+// Compose llvm-objcopy command line for add target objects' sections with
+// appropriate flags.
 BumpPtrAllocator Alloc;
 StringSaver SS{Alloc};
 SmallVector ObjcopyArgs{"llvm-objcopy"};
@@ -627,20 +617,11 @@ class ObjectFileHandler final : public FileHandler {
   ObjcopyArgs.push_back(SS.save(Twine("--add-section

[PATCH] D102670: [clang-offload-bundler] Add sections and set section flags using one llvm-objcopy invocation

2021-05-18 Thread Sergey Dmitriev via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8998a8aa97f8: [clang-offload-bundler] Add sections and set 
section flags using one llvm… (authored by sdmitriev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102670

Files:
  clang/test/Driver/clang-offload-bundler.c
  clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp


Index: clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
===
--- clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
+++ clang/tools/clang-offload-bundler/ClangOffloadBundler.cpp
@@ -578,11 +578,7 @@
 // We will use llvm-objcopy to add target objects sections to the output
 // fat object. These sections should have 'exclude' flag set which tells
 // link editor to remove them from linker inputs when linking executable or
-// shared library. llvm-objcopy currently does not support adding new
-// section and changing flags for the added section in one invocation, and
-// because of that we have to run it two times. First run adds sections and
-// the second changes flags.
-// TODO: change it to one run once llvm-objcopy starts supporting that.
+// shared library.
 
 // Find llvm-objcopy in order to create the bundle binary.
 ErrorOr Objcopy = sys::findProgramByName(
@@ -600,14 +596,8 @@
 // Temporary files that need to be removed.
 TempFileHandlerRAII TempFiles;
 
-// Create an intermediate temporary file to save object after the first
-// llvm-objcopy run.
-Expected IntermediateObjOrErr = TempFiles.Create(None);
-if (!IntermediateObjOrErr)
-  return IntermediateObjOrErr.takeError();
-StringRef IntermediateObj = *IntermediateObjOrErr;
-
-// Compose llvm-objcopy command line for add target objects' sections.
+// Compose llvm-objcopy command line for add target objects' sections with
+// appropriate flags.
 BumpPtrAllocator Alloc;
 StringSaver SS{Alloc};
 SmallVector ObjcopyArgs{"llvm-objcopy"};
@@ -627,20 +617,11 @@
   ObjcopyArgs.push_back(SS.save(Twine("--add-section=") +
 OFFLOAD_BUNDLER_MAGIC_STR + TargetNames[I] 
+
 "=" + InputFile));
-}
-ObjcopyArgs.push_back(InputFileNames[HostInputIndex]);
-ObjcopyArgs.push_back(IntermediateObj);
-
-if (Error Err = executeObjcopy(*Objcopy, ObjcopyArgs))
-  return Err;
-
-// And run llvm-objcopy for the second time to update section flags.
-ObjcopyArgs.resize(1);
-for (unsigned I = 0; I < NumberOfInputs; ++I)
   ObjcopyArgs.push_back(SS.save(Twine("--set-section-flags=") +
 OFFLOAD_BUNDLER_MAGIC_STR + TargetNames[I] 
+
 "=readonly,exclude"));
-ObjcopyArgs.push_back(IntermediateObj);
+}
+ObjcopyArgs.push_back(InputFileNames[HostInputIndex]);
 ObjcopyArgs.push_back(OutputFileNames.front());
 
 if (Error Err = executeObjcopy(*Objcopy, ObjcopyArgs))
Index: clang/test/Driver/clang-offload-bundler.c
===
--- clang/test/Driver/clang-offload-bundler.c
+++ clang/test/Driver/clang-offload-bundler.c
@@ -274,8 +274,7 @@
 
 // RUN: clang-offload-bundler -type=o 
-targets=host-%itanium_abi_triple,openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu
 -inputs=%t.o,%t.tgt1,%t.tgt2 -outputs=%t.bundle3.o -### 2>&1 \
 // RUN: | FileCheck %s -DHOST=%itanium_abi_triple -DINOBJ1=%t.o 
-DINOBJ2=%t.tgt1 -DINOBJ3=%t.tgt2 -DOUTOBJ=%t.bundle3.o --check-prefix 
CK-OBJ-CMD
-// CK-OBJ-CMD: llvm-objcopy{{(.exe)?}}" 
"--add-section=__CLANG_OFFLOAD_BUNDLE__host-[[HOST]]={{.*}}" 
"--add-section=__CLANG_OFFLOAD_BUNDLE__openmp-powerpc64le-ibm-linux-gnu=[[INOBJ2]]"
 "--add-section=__CLANG_OFFLOAD_BUNDLE__openmp-x86_64-pc-linux-gnu=[[INOBJ3]]" 
"[[INOBJ1]]" "[[TEMPOBJ:.*]]"
-// CK-OBJ-CMD: llvm-objcopy{{(.exe)?}}" 
"--set-section-flags=__CLANG_OFFLOAD_BUNDLE__host-[[HOST]]=readonly,exclude" 
"--set-section-flags=__CLANG_OFFLOAD_BUNDLE__openmp-powerpc64le-ibm-linux-gnu=readonly,exclude"
 
"--set-section-flags=__CLANG_OFFLOAD_BUNDLE__openmp-x86_64-pc-linux-gnu=readonly,exclude"
 "[[TEMPOBJ]]" "[[OUTOBJ]]"
+// CK-OBJ-CMD: llvm-objcopy{{(.exe)?}}" 
"--add-section=__CLANG_OFFLOAD_BUNDLE__host-[[HOST]]={{.*}}" 
"--set-section-flags=__CLANG_OFFLOAD_BUNDLE__host-[[HOST]]=readonly,exclude" 
"--add-section=__CLANG_OFFLOAD_BUNDLE__openmp-powerpc64le-ibm-linux-gnu=[[INOBJ2]]"
 
"--set-section-flags=__CLANG_OFFLOAD_BUNDLE__openmp-powerpc64le-ibm-linux-gnu=readonly,exclude"
 "--add-section=__CLANG_OFFLOAD_BUNDLE__openmp-x86_64-pc-linux-gnu=[[INOBJ3]]" 
"--set-section-flags=__CLANG_OFFLOAD_BUNDLE__openmp-x86_64-pc-linux-gnu=readonly,exclude"
 "[[INOBJ1]]" "[[OUTOBJ]]"
 
 // RUN: clang-offload-bundler -type=o 
-targets=host-%i

[PATCH] D102261: Introduce SYCL 2020 mode

2021-05-18 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Looks like this breaks tests on macOS:
http://45.33.8.238/macm1/9739/step_7.txt
http://45.33.8.238/mac/31615/step_7.txt

Please take a look, and please revert for now if it takes a while to fix.


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] D102696: [Analyzer] Find constraints that are directly attached to a BinOp

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

Currently, if we have a constraint on a binary operand and then we add
another constraint to any of the binop's sub-expression then the first
constraint is not considered by the engine:

  int foo() {
if (x + y != 0)
  return 0;
clang_analyzer_eval(x + y == 0); // expected-warning{{TRUE}} OK.
if (y != 0)
  return 0;
clang_analyzer_eval(y == 0); // expected-warning{{TRUE}} OK.
clang_analyzer_eval(x + y == 0); // expected-warning{{TRUE}} FAILS!
  }

Interestingly, if we constrain first y and then (x + y) then the
behaviour is what we'd normally expect:

  int foo() {
if (y != 0)
  return 0;
if (x + y != 0)
  return 0;
clang_analyzer_eval(x + y == 0); // expected-warning{{TRUE}} OK.
clang_analyzer_eval(y == 0); // expected-warning{{TRUE}} OK.
  }

The discrepancy stems from the underlying implementation of the engine:
In the latter case, the Environment of the current ExplodedNode has a
(x + y) -> [0, 0] binding. However, in the first case we have a [y] -> 0
binding in the current ExplodedNode, and when we build the SVal for the
(x + y) expression we simply build up the [x + 0] SVal, i.e. we never
try to find the constraint for (x + y).

In this patch, I add a StmtVisitor that builds up an SVal that
constitutes only from LValue SVals. This SVal then can be used to query
the constraint manager, this way we can find the desired constraint.

Alternative implementation could have been to traverse back in the
Exploded Graph to the Node where we can find the original binding of the
x + y expression. This seemed to be a far from ideal approach as we may
not know how far should we traverse back.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102696

Files:
  clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
  clang/test/Analysis/find-binop-constraints.cpp

Index: clang/test/Analysis/find-binop-constraints.cpp
===
--- /dev/null
+++ clang/test/Analysis/find-binop-constraints.cpp
@@ -0,0 +1,90 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -verify
+
+void clang_analyzer_eval(bool);
+
+int test_legacy_behavior(int x, int y) {
+  if (y != 0)
+return 0;
+  if (x + y != 0)
+return 0;
+  clang_analyzer_eval(x + y == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(y == 0); // expected-warning{{TRUE}}
+  return y / (x + y);  // expected-warning{{Division by zero}}
+}
+
+int test_rhs_further_constrained(int x, int y) {
+  if (x + y != 0)
+return 0;
+  if (y != 0)
+return 0;
+  clang_analyzer_eval(x + y == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(y == 0); // expected-warning{{TRUE}}
+  return 0;
+}
+
+int test_lhs_further_constrained(int x, int y) {
+  if (x + y != 0)
+return 0;
+  if (x != 0)
+return 0;
+  clang_analyzer_eval(x + y == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(x == 0); // expected-warning{{TRUE}}
+  return 0;
+}
+
+int test_lhs_and_rhs_further_constrained(int x, int y) {
+  if (x % y != 1)
+return 0;
+  if (x != 1)
+return 0;
+  if (y != 1)
+return 0;
+  clang_analyzer_eval(x % y == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(y == 1); // expected-warning{{TRUE}}
+  return 0;
+}
+
+int test_binop_when_height_is_2_r(int a, int x, int y, int z) {
+  switch (a) {
+  case 1: {
+if (x + y + z != 0)
+  return 0;
+if (z != 0)
+  return 0;
+clang_analyzer_eval(x + y + z == 0); // expected-warning{{TRUE}}
+clang_analyzer_eval(z == 0); // expected-warning{{TRUE}}
+break;
+  }
+  case 2: {
+if (x + y + z != 0)
+  return 0;
+if (y != 0)
+  return 0;
+clang_analyzer_eval(x + y + z == 0); // expected-warning{{TRUE}}
+clang_analyzer_eval(y == 0); // expected-warning{{TRUE}}
+break;
+  }
+  case 3: {
+if (x + y + z != 0)
+  return 0;
+if (x != 0)
+  return 0;
+clang_analyzer_eval(x + y + z == 0); // expected-warning{{TRUE}}
+clang_analyzer_eval(x == 0); // expected-warning{{TRUE}}
+break;
+  }
+  case 4: {
+if (x + y + z != 0)
+  return 0;
+if (x + y != 0)
+  return 0;
+clang_analyzer_eval(x + y + z == 0); // expected-warning{{TRUE}}
+clang_analyzer_eval(x + y == 0); // expected-warning{{TRUE}}
+break;
+  }
+  }
+  return 0;
+}
Index: clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
===
--- clang/lib/

[clang] ccbac06 - Speculatively fix failing tests from 6381664580080f015bc0c2ec647853f697cf744a

2021-05-18 Thread Aaron Ballman via cfe-commits

Author: Aaron Ballman
Date: 2021-05-18T12:44:58-04:00
New Revision: ccbac06a072b86ea3b46479e478a1abee8520ef8

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

LOG: Speculatively fix failing tests from 
6381664580080f015bc0c2ec647853f697cf744a

This was causing some Mac-specific build failures:
http://45.33.8.238/macm1/9739/step_7.txt
http://45.33.8.238/mac/31615/step_7.txt

As best I can tell with psychic debugging, the /Users/blah path to the
source file is being treated as a macro undef with the clang-cl driver.
This splits the filename off explicitly so hopefully the rest of the
command line arguments will be read properly.

Added: 


Modified: 
clang/test/Driver/sycl.c

Removed: 




diff  --git a/clang/test/Driver/sycl.c b/clang/test/Driver/sycl.c
index af3af91cc062..2a672ccf0692 100644
--- a/clang/test/Driver/sycl.c
+++ b/clang/test/Driver/sycl.c
@@ -22,6 +22,6 @@
 
 // RUN: %clang -### -fsycl  %s 2>&1 | FileCheck %s --check-prefix=DEFAULT
 // RUN: %clangxx -### -fsycl %s 2>&1 | FileCheck %s --check-prefix=DEFAULT
-// RUN: %clang_cl -### -fsycl %s 2>&1 | FileCheck %s --check-prefix=DEFAULT
+// RUN: %clang_cl -### -fsycl -- %s 2>&1 | FileCheck %s --check-prefix=DEFAULT
 
 // DEFAULT: "-sycl-std=2020"



___
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-18 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D102261#2766240 , @thakis wrote:

> Looks like this breaks tests on macOS:
> http://45.33.8.238/macm1/9739/step_7.txt
> http://45.33.8.238/mac/31615/step_7.txt
>
> Please take a look, and please revert for now if it takes a while to fix.

Thank you -- I think I've resolved the issue in 
ccbac06a072b86ea3b46479e478a1abee8520ef8 


~Aaron


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] D102479: [clang][driver] Treat unkonwn -flto= values as -flto

2021-05-18 Thread Steven Wu via Phabricator via cfe-commits
steven_wu added a comment.

I don't think current implementation is the best idea. I think is better to 
make the gcc compatible LTO value to be a clang Driver only option, give them 
an option name, and handle them separately in driver to invoke correct fullLTO 
cc1 command, so that:

- The value remain invalid option for cc1 (CompilerInvocation should just error 
on that, just like now).
- The ignored value should not appear in the help or autocompletion.


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

https://reviews.llvm.org/D102479

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


[PATCH] D101777: [clang] p1099 1/5: [NFC] Break out BaseUsingDecl from UsingDecl

2021-05-18 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:4623
 
-  Expected ToUsingOrErr = import(D->getUsingDecl());
-  if (!ToUsingOrErr)
-return ToUsingOrErr.takeError();
+  Expected ToIntroducerOrErr = import(D->getIntroducer());
+  if (!ToIntroducerOrErr)

It would nice to expand upon the  `ImportUsingShadowDecl` in 
`ASTImporterTest.cpp` as we expand this change to make sure the ASTImporter is 
importing all the cases correctly. Right now we just have a very basic test 
there.


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

https://reviews.llvm.org/D101777

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


[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

2021-05-18 Thread Petr Hosek via Phabricator via cfe-commits
phosek added a comment.

We've started seeing `LLVM ERROR: out of memory` on our 2-stage LTO Linux 
builders after this change landed. It looks like linking `clang-repl` always 
fails on our bot, but I've also seen OOM when linking `ClangCodeGenTests` and 
`FrontendTests`. Do you have any idea why this could be happening? We'd 
appreciate any help since our bots have been broken for several days now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96033

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


[PATCH] D102696: [Analyzer] Find constraints that are directly attached to a BinOp

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

Ok so the state has enough constraints. It's enough to know that `$x + $y == 0` 
and `$y == 0` in order to deduce that `$x + 0 == 0`. But you're saying that we 
don't know how to infer it so instead of making us able to infer it let's make 
us ask the solver easier questions. That's a terrible hack but at this point i 
think we might as well take it. @vsavchenko WDYT, what would it take to fix the 
solver instead?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102696

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


[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

2021-05-18 Thread Vassil Vassilev via Phabricator via cfe-commits
v.g.vassilev added a comment.

In D96033#2766332 , @phosek wrote:

> We've started seeing `LLVM ERROR: out of memory` on our 2-stage LTO Linux 
> builders after this change landed. It looks like linking `clang-repl` always 
> fails on our bot, but I've also seen OOM when linking `ClangCodeGenTests` and 
> `FrontendTests`. Do you have any idea why this could be happening? We'd 
> appreciate any help since our bots have been broken for several days now.

Ouch. Are the bot logs public? If not maybe a stacktrace could be useful. 
`clang-repl` combines a lot of libraries across llvm and clang that usually are 
compiled separately. For instance we put in memory most of the clang frontend, 
the backend and the JIT. Could it be we are hitting some real limit?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96033

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


[PATCH] D101849: [OpenMP][NFC] Refactor Clang OpenMP tests using update_cc_test_checks

2021-05-18 Thread Mike Rice via Phabricator via cfe-commits
mikerice added a comment.

In D101849#2764825 , @ABataev wrote:

> No, it is not required. Most probably, needed to simplify test checks, 
> nothing else.

Thanks.  I'd like to remove the "REQUIRES: x86-registered-target", the -O1 for 
CHECK6,10, and regenerate the CHECK lines.  Unfortunately I am seeing this 
mangling issue (https://bugs.llvm.org/show_bug.cgi?id=49767) when running the 
script. @ggeorgakoudis, how did you get past this to generate the CHECK lines 
in your change?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101849

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


[PATCH] D102683: [analyzer] Check the checker name, rather than the ProgramPointTag when silencing a checker

2021-05-18 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ accepted this revision.
NoQ added a comment.
This revision is now accepted and ready to land.

Oof. Accurate!

>   // Would it be more elegant to create the emitting checkers tag here? Mind 
> that this is a checker that houses many others.

I think the checkers should have a right to attach custom tags to their nodes. 
This right guarantees that they can create multiple different nodes with the 
same state (eg., the error state) and point (eg., the error point). Not sure 
why would they need it but I guess in some cases it may be easier for the 
checker to generate an extra node than to pass existing node around, as the 
existing node may be next to impossible to retrieve given that 
`addTransition()` with the same state will simply return null if the node is 
already there. So, like, the same reason why generally we allow checkers to 
chain nodes instead of forcing them to make all changes in a single transition.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102683

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


[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

2021-05-18 Thread Petr Hosek via Phabricator via cfe-commits
phosek added a comment.

In D96033#2766372 , @v.g.vassilev 
wrote:

> In D96033#2766332 , @phosek wrote:
>
>> We've started seeing `LLVM ERROR: out of memory` on our 2-stage LTO Linux 
>> builders after this change landed. It looks like linking `clang-repl` always 
>> fails on our bot, but I've also seen OOM when linking `ClangCodeGenTests` 
>> and `FrontendTests`. Do you have any idea why this could be happening? We'd 
>> appreciate any help since our bots have been broken for several days now.
>
> Ouch. Are the bot logs public? If not maybe a stacktrace could be useful. 
> `clang-repl` combines a lot of libraries across llvm and clang that usually 
> are compiled separately. For instance we put in memory most of the clang 
> frontend, the backend and the JIT. Could it be we are hitting some real limit?

Yes, they are, see 
https://luci-milo.appspot.com/p/fuchsia/builders/prod/clang-linux-x64, but 
there isn't much information in there unfortunately. It's possible that we're 
hitting some limit, but these bots use 32-core instances with 128GB RAM which 
I'd hope is enough even for the LTO build.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96033

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


[clang] 2919222 - [Driver] Delete -mimplicit-it=

2021-05-18 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-05-18T10:57:24-07:00
New Revision: 2919222d8017f2425a85765b95e4b7c6f8e70ca4

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

LOG: [Driver] Delete -mimplicit-it=

This is a GNU as and Clang cc1as option, not a GCC option.
Users should specify `-Wa,-mimplicit-it=` instead.

Note: mixing the -m option and the -Wa, option doesn't work
`-Wa,-mimplicit-it=never -mimplicit-it=always` =>
`clang (LLVM option parsing): for the --arm-implicit-it option: may only occur 
zero or one times!`

Reviewed By: nickdesaulniers, raj.khem

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/arm-target-as-mimplicit-it.s
clang/test/Driver/as-options.s

Removed: 
clang/test/Driver/arm-implicit-it.s



diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 09de6b5a50d0..a876f48c5596 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -3009,7 +3009,6 @@ def mtls_size_EQ : Joined<["-"], "mtls-size=">, 
Group, Flags<[NoXarchOp
   HelpText<"Specify bit size of immediate TLS offsets (AArch64 ELF only): "
"12 (for 4KB) | 24 (for 16MB, default) | 32 (for 4GB) | 48 (for 
256TB, needs -mcmodel=large)">,
   MarshallingInfoInt>;
-def mimplicit_it_EQ : Joined<["-"], "mimplicit-it=">, Group;
 def mdefault_build_attributes : Joined<["-"], "mdefault-build-attributes">, 
Group;
 def mno_default_build_attributes : Joined<["-"], 
"mno-default-build-attributes">, Group;
 def mconstant_cfstrings : Flag<["-"], "mconstant-cfstrings">, 
Group;

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index afc119263db9..47552dcb6fdf 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2393,22 +2393,6 @@ static void 
CollectArgsForIntegratedAssembler(Compilation &C,
DefaultIncrementalLinkerCompatible))
 CmdArgs.push_back("-mincremental-linker-compatible");
 
-  switch (C.getDefaultToolChain().getArch()) {
-  case llvm::Triple::arm:
-  case llvm::Triple::armeb:
-  case llvm::Triple::thumb:
-  case llvm::Triple::thumbeb:
-if (Arg *A = Args.getLastArg(options::OPT_mimplicit_it_EQ)) {
-  StringRef Value = A->getValue();
-  if (!AddARMImplicitITArgs(Args, CmdArgs, Value))
-D.Diag(diag::err_drv_unsupported_option_argument)
-<< A->getOption().getName() << Value;
-}
-break;
-  default:
-break;
-  }
-
   // If you add more args here, also add them to the block below that
   // starts with "// If CollectArgsForIntegratedAssembler() isn't called 
below".
 
@@ -4353,16 +4337,6 @@ void Clang::ConstructJob(Compilation &C, const JobAction 
&JA,
   Args.ClaimAllArgs(options::OPT_mno_relax_all);
   Args.ClaimAllArgs(options::OPT_mincremental_linker_compatible);
   Args.ClaimAllArgs(options::OPT_mno_incremental_linker_compatible);
-  switch (C.getDefaultToolChain().getArch()) {
-  case llvm::Triple::arm:
-  case llvm::Triple::armeb:
-  case llvm::Triple::thumb:
-  case llvm::Triple::thumbeb:
-Args.ClaimAllArgs(options::OPT_mimplicit_it_EQ);
-break;
-  default:
-break;
-  }
 }
 Args.ClaimAllArgs(options::OPT_Wa_COMMA);
 Args.ClaimAllArgs(options::OPT_Xassembler);

diff  --git a/clang/test/Driver/arm-implicit-it.s 
b/clang/test/Driver/arm-implicit-it.s
deleted file mode 100644
index 48e4bdbe8c95..
--- a/clang/test/Driver/arm-implicit-it.s
+++ /dev/null
@@ -1,24 +0,0 @@
-// RUN: %clang -target armv7--none-eabi -### %s 2>&1 \
-// RUN:| FileCheck %s -check-prefix CHECK-DEFAULT
-
-// RUN: %clang -target armv7--none-eabi -mimplicit-it=arm -### %s 2>&1 \
-// RUN:| FileCheck %s -check-prefix CHECK-ARM
-
-// RUN: %clang -target armv7--none-eabi -mimplicit-it=thumb -### %s 2>&1 \
-// RUN:| FileCheck %s -check-prefix CHECK-THUMB
-
-// RUN: %clang -target armv7--none-eabi -mimplicit-it=never -### %s 2>&1 \
-// RUN:| FileCheck %s -check-prefix CHECK-NEVER
-
-// RUN: %clang -target armv7--none-eabi -mimplicit-it=always -### %s 2>&1 \
-// RUN:| FileCheck %s -check-prefix CHECK-ALWAYS
-
-// RUN: %clang -target armv7--none-eabi -mimplicit-it=thisisnotavalidoption 
-### %s 2>&1 \
-// RUN:| FileCheck %s -check-prefix CHECK-INVALID
-
-// CHECK-DEFAULT-NOT: "-arm-implicit-it
-// CHECK-ARM: "-arm-implicit-it=arm"
-// CHECK-THUMB: "-arm-implicit-it=thumb"
-// CHECK-NEVER: "-arm-implicit-it=never"
-// CHECK-ALWAYS: "-arm-implicit-it=always"
-// CHECK-INVALID: error: unsupported argument 'thisisnotavalidoption' to 
option 'mimplicit-it='

diff  --git 

[PATCH] D102568: [Driver] Delete -mimplicit-it=

2021-05-18 Thread Fangrui Song 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 rG2919222d8017: [Driver] Delete -mimplicit-it= (authored by 
MaskRay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102568

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/arm-implicit-it.s
  clang/test/Driver/arm-target-as-mimplicit-it.s
  clang/test/Driver/as-options.s

Index: clang/test/Driver/as-options.s
===
--- clang/test/Driver/as-options.s
+++ clang/test/Driver/as-options.s
@@ -53,20 +53,6 @@
 // RUN:   -o /dev/null -x assembler-with-cpp %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=WARN --allow-empty %s
 
-// RUN: %clang -mimplicit-it=always -target armv7-linux-gnueabi -E \
-// RUN:   -fintegrated-as -o /dev/null -x c++ %s 2>&1 \
-// RUN:   | FileCheck --check-prefix=NOWARN --allow-empty %s
-// RUN: %clang -mimplicit-it=always -target armv7-linux-gnueabi -E \
-// RUN:   -fno-integrated-as -o /dev/null -x c++ %s 2>&1 \
-// RUN:   | FileCheck --check-prefix=WARN --allow-empty %s
-
-// RUN: %clang -mimplicit-it=always -target armv7-linux-gnueabi -E \
-// RUN:   -fintegrated-as -o /dev/null -x assembler-with-cpp %s 2>&1 \
-// RUN:   | FileCheck --check-prefix=NOWARN --allow-empty %s
-// RUN: %clang -mimplicit-it=always -target armv7-linux-gnueabi -E \
-// RUN:   -fno-integrated-as -o /dev/null -x assembler-with-cpp %s 2>&1 \
-// RUN:   | FileCheck --check-prefix=WARN --allow-empty %s
-
 // RUN: %clang -Wa,-mbig-obj -target i386-pc-windows -E -fintegrated-as \
 // RUN:   -o /dev/null -x c++ %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=NOWARN --allow-empty %s
Index: clang/test/Driver/arm-target-as-mimplicit-it.s
===
--- clang/test/Driver/arm-target-as-mimplicit-it.s
+++ clang/test/Driver/arm-target-as-mimplicit-it.s
@@ -20,13 +20,6 @@
 // RUN: %clang -target arm-linux-gnueabi -### -Wa,-mimplicit-it=always,-mimplicit-it=arm %s 2>&1 | FileCheck %s --check-prefix=ARM
 // RUN: %clang -target arm-linux-gnueabi -### -Wa,-mimplicit-it=always,-mimplicit-it=thumb %s 2>&1 | FileCheck %s --check-prefix=THUMB
 
-/// Mix -implicit-it= (compiler) with -Wa,-mimplicit-it= (assembler), assembler
-/// takes priority. -mllvm -arm-implicit-it= will be repeated, with the
-/// assembler flag appearing last (latter wins).
-// RUN: %clang -target arm-linux-gnueabi -### -mimplicit-it=never -Wa,-mimplicit-it=always %S/Inputs/wildcard1.c 2>&1 | FileCheck %s --check-prefix=NEVER_ALWAYS
-// RUN: %clang -target arm-linux-gnueabi -### -mimplicit-it=always -Wa,-mimplicit-it=never %S/Inputs/wildcard1.c 2>&1 | FileCheck %s --check-prefix=ALWAYS_NEVER
-// RUN: %clang -target arm-linux-gnueabi -### -Wa,-mimplicit-it=never -mimplicit-it=always %S/Inputs/wildcard1.c 2>&1 | FileCheck %s --check-prefix=ALWAYS_NEVER
-
 /// Test invalid input.
 // RUN: %clang -target arm-linux-gnueabi -### -Wa,-mimplicit-it=foo %s 2>&1 | FileCheck %s --check-prefix=INVALID
 // RUN: %clang -target arm-linux-gnueabi -### -Xassembler -mimplicit-it=foo %s 2>&1 | FileCheck %s --check-prefix=XINVALID
@@ -38,7 +31,5 @@
 // NEVER: "-mllvm" "-arm-implicit-it=never"
 // ARM: "-mllvm" "-arm-implicit-it=arm"
 // THUMB: "-mllvm" "-arm-implicit-it=thumb"
-// NEVER_ALWAYS: "-mllvm" "-arm-implicit-it=never" "-mllvm" "-arm-implicit-it=always"
-// ALWAYS_NEVER: "-mllvm" "-arm-implicit-it=always" "-mllvm" "-arm-implicit-it=never"
 // INVALID: error: unsupported argument '-mimplicit-it=foo' to option 'Wa,'
 // XINVALID: error: unsupported argument '-mimplicit-it=foo' to option 'Xassembler'
Index: clang/test/Driver/arm-implicit-it.s
===
--- clang/test/Driver/arm-implicit-it.s
+++ /dev/null
@@ -1,24 +0,0 @@
-// RUN: %clang -target armv7--none-eabi -### %s 2>&1 \
-// RUN:| FileCheck %s -check-prefix CHECK-DEFAULT
-
-// RUN: %clang -target armv7--none-eabi -mimplicit-it=arm -### %s 2>&1 \
-// RUN:| FileCheck %s -check-prefix CHECK-ARM
-
-// RUN: %clang -target armv7--none-eabi -mimplicit-it=thumb -### %s 2>&1 \
-// RUN:| FileCheck %s -check-prefix CHECK-THUMB
-
-// RUN: %clang -target armv7--none-eabi -mimplicit-it=never -### %s 2>&1 \
-// RUN:| FileCheck %s -check-prefix CHECK-NEVER
-
-// RUN: %clang -target armv7--none-eabi -mimplicit-it=always -### %s 2>&1 \
-// RUN:| FileCheck %s -check-prefix CHECK-ALWAYS
-
-// RUN: %clang -target armv7--none-eabi -mimplicit-it=thisisnotavalidoption -### %s 2>&1 \
-// RUN:| FileCheck %s -check-prefix CHECK-INVALID
-
-// CHECK-DEFAULT-NOT: "-arm-implicit-it
-// CHECK-ARM: "-arm-implicit-it=arm"
-// CHECK-THUMB: "-arm-implicit-it=thumb"
-// CHECK-NEVER: "-arm-implicit-it=never"
-// CHECK-ALWAYS: "-arm-implicit-it=always"
-// CHECK-INVALID: err

[PATCH] D102273: [analyzer] LoopUnrolling: fix crash when a loop counter is captured in a lambda by reference

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

I've just been patching up clang-tidy's infinite loop checker and the problem 
sounds s similar. Maybe we should move clang-tidy's alias analysis into 
`libAnalysis` and re-use it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102273

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


[PATCH] D102706: [clang-format] Add new LambdaBodyIndentation option

2021-05-18 Thread Vitali Lovich via Phabricator via cfe-commits
vlovich created this revision.
vlovich added reviewers: MyDeveloperDay, curdeius.
vlovich added a project: clang-format.
vlovich requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Currently the lambda body indents relative to where the lambda signature is 
located. This instead lets the user
choose to align the lambda body relative to the parent scope that contains the 
lambda declaration. Thus:

  someFunction([] {
lambdaBody();
  });

will always have the same indentation of the body even when the lambda 
signature goes on a new line:

  someFunction(
  [] {
lambdaBody();
  });

whereas before `lambdaBody` would be indented 6 spaces.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102706

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -17871,6 +17871,7 @@
" aaa;\n"
"});",
getLLVMStyleWithColumns(60));
+
   verifyFormat("SomeFunction({[&] {\n"
"// comment\n"
"  },\n"
@@ -18423,6 +18424,90 @@
"  });\n"
"});",
LLVMWithBeforeLambdaBody);
+
+  // Lambdas with different indentation styles.
+  Style = getLLVMStyleWithColumns(100);
+  EXPECT_EQ("SomeResult doSomething(SomeObject promise) {\n"
+"  return promise.then(\n"
+"  [this, &someVariable, someObject = std::mv(s)](std::vector evaluated) mutable {\n"
+"return someObject.startAsyncAction().then(\n"
+"[this, &someVariable](AsyncActionResult result) mutable { result.processMore(); });\n"
+"  });\n"
+"}\n",
+format("SomeResult doSomething(SomeObject promise) {\n"
+   "  return promise.then([this, &someVariable, someObject = std::mv(s)](std::vector evaluated) mutable {\n"
+   "return someObject.startAsyncAction().then([this, &someVariable](AsyncActionResult result) mutable {\n"
+   "  result.processMore();\n"
+   "});\n"
+   "  });\n"
+   "}\n",
+   Style));
+  Style.LambdaBodyIndentation = FormatStyle::LBI_OuterScope;
+  verifyFormat("test() {\n"
+   "  ([]() -> {\n"
+   "int b = 32;\n"
+   "return 3;\n"
+   "  }).foo();\n"
+   "}",
+   Style);
+  verifyFormat("test() {\n"
+   "  (\n"
+   "  []() -> {\n"
+   "int b = 32;\n"
+   "return 3;\n"
+   "  },\n"
+   "  foo, bar)\n"
+   "  .foo();\n"
+   "}",
+   Style);
+  verifyFormat("test() {\n"
+   "  ([]() -> {\n"
+   "int b = 32;\n"
+   "return 3;\n"
+   "  })\n"
+   "  .foo()\n"
+   "  .bar();\n"
+   "}",
+   Style);
+  EXPECT_EQ("SomeResult doSomething(SomeObject promise) {\n"
+"  return promise.then(\n"
+"  [this, &someVariable, someObject = std::mv(s)](std::vector evaluated) mutable {\n"
+"return someObject.startAsyncAction().then(\n"
+"[this, &someVariable](AsyncActionResult result) mutable { result.processMore(); });\n"
+"  });\n"
+"}\n",
+format("SomeResult doSomething(SomeObject promise) {\n"
+   "  return promise.then([this, &someVariable, someObject = std::mv(s)](std::vector evaluated) mutable {\n"
+   "return someObject.startAsyncAction().then([this, &someVariable](AsyncActionResult result) mutable {\n"
+   "  result.processMore();\n"
+   "});\n"
+   "  });\n"
+   "}\n",
+   Style));
+  EXPECT_EQ("SomeResult doSomething(SomeObject promise) {\n"
+"  return promise.then([this, &someVariable] {\n"
+"return someObject.startAsyncAction().then(\n"
+"[this, &someVariable](AsyncActionResult result) mutable { result.processMore(); });\n"
+"  });\n"
+"}\n",
+format("SomeResult doSomething(SomeObject promise) {\n"
+   "  return promise.then([this, &someVariable] {\n"
+   "return someObject.startAsyncAction().then([this, &someVariable](AsyncActionResult result) mutable {\n"
+  

[PATCH] D102706: [clang-format] Add new LambdaBodyIndentation option

2021-05-18 Thread Vitali Lovich via Phabricator via cfe-commits
vlovich added a comment.

I'm not 100% certain if the implementation is absolutely correct. For example, 
the `#define A` test case is broken (the closing brace is on the wrong line). 
Additionally, the `pop_back` feels weird but seems to fix all the other cases 
to make the closing brace aligned properly. Maybe some/all of the 
implementation belongs in ContinuationIndenter.cpp instead but I couldn't 
really follow where the best place to do that might be. I can also just leave 
the preprocessor macro case as a known issue for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102706

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


[PATCH] D101849: [OpenMP][NFC] Refactor Clang OpenMP tests using update_cc_test_checks

2021-05-18 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

In D101849#2766411 , @mikerice wrote:

> In D101849#2764825 , @ABataev wrote:
>
>> No, it is not required. Most probably, needed to simplify test checks, 
>> nothing else.
>
> Thanks.  I'd like to remove the "REQUIRES: x86-registered-target", the -O1 
> for CHECK6,10, and regenerate the CHECK lines.  Unfortunately I am seeing 
> this mangling issue (https://bugs.llvm.org/show_bug.cgi?id=49767) when 
> running the script. @ggeorgakoudis, how did you get past this to generate the 
> CHECK lines in your change?

The workaround is to check if the assertion would trigger and just return from 
the function instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101849

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


[PATCH] D102706: [clang-format] Add new LambdaBodyIndentation option

2021-05-18 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks added a comment.

Maybe a bit more test cases with smaller lambdas? Or without the outer 
parenthesis?




Comment at: clang/include/clang/Format/Format.h:2456
+  enum LambdaBodyIndentationKind : unsigned char {
+/// Align lambda body relative to the lambda signature. This is the 
default.
+LBI_Signature,

I think you should add examples, because for me it is not 100% what's the 
difference is.



Comment at: clang/include/clang/Format/Format.h:2462
+
+  LambdaBodyIndentationKind LambdaBodyIndentation;
+

Here should also a comment be added.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102706

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


[PATCH] D99235: [HIP] Change to code object v4

2021-05-18 Thread Greg Rodgers via Phabricator via cfe-commits
gregrodgers added inline comments.



Comment at: clang/lib/Driver/ToolChains/HIP.cpp:116
+  if (getOrCheckAMDGPUCodeObjectVersion(C.getDriver(), Args) >= 4)
+OffloadKind = OffloadKind + "v4";
   for (const auto &II : Inputs) {

yaxunl wrote:
> tra wrote:
> > We do not do it for v2/v3. Could you elaborate on what makes v4 special 
> > that it needs its own offload kind? 
> > 
> > Will you need to target different object versions simultaneously?
> > If yes, how? AFAICT, the version specified is currently global and applies 
> > to all sub-compilations.
> > If not, then do we really need to encode the version in the offload target 
> > name?
> Introducing hipv4 is to differentiate with code object version 2 and 3 which 
> are used by HIP applications compiled by older version of clang. ROCm 
> platform is required to keep binary backward compatibility, i.e., old HIP 
> applications built by ROCm 4.0 should run on ROCm 4.1. The bundle ID has 
> different interpretation depending on whether it is version 2/3 or version 4, 
> e.g. 'gfx906' implies xnack and sramecc off with code object v2/3 but implies 
> xnack and sramecc ANY with v4. Since code object version 2/3 uses 'hip', code 
> object version 4 needs to be different, therefore it uses 'hipv4'.
We need to start thinking in terms of offload requirements of a compiled image 
vs the capabilities of a particular active runtime on a particular GPU.   This 
concept can eliminate the need for a new offload kind.  For AMD, we would add 
the requirement of code object v4 (cov4) if built for code object v4 or 
greater.This means it can only run on a system with that capability.  This 
concept works well with requirements xnack+, xnack-, sramecc+ and sramecc-.
The bundle entry id is the offload-kind, the triple, and the list of image 
requirements.  The gpu type (offload-arch) is really an image requirement.  

In this model, there is no requirement for xnack-any.  The lack of the xnack+ 
or xnack- requirement implies "any" which means it can run on any capable 
machine.  

This is a general model that is extensible.   To make this work, a runtime must 
be able to detect the capabilities for any requirement that could be tagged on 
an image.  In fact, every requirement of an embedded image must have its 
capability detected by the runtime for that offload image to be usable.   
However, a system's runtime could have more capabilities than the requirements 
of an image.   So in the case of xnack, the lack of xnack- or xnack+ will be 
acceptable no matter what the xnack capability of the runtime is.   If the 
compiler driver puts the requirement cov4 in the bundle entry id requirements 
field the runtime will not run that image unless the GPU loader supports v4 or 
greater. 

The clang driver can create the requirement xnack- for code object < 4 on those 
GPUs that support either xnack mode.   This will ensure  the image will 
gracefully fail or use an alternative image if the runtime capability is xnack+.

But the cov4 requirement is mostly unrelated to xnack .  It is about the 
capability of the GPU loader.  If the code object version >= 4, then it will be 
tagged with the cov4 requirement.   This would prevent an old system that does 
not have a newer software stack from running an image with a cov4 requirement. 

This general notion of image requirements and runtime capabilities is 
extensible to other offload architectures.   Suppose cuda version 12 
compilation REQUIRES that a cuda version 12 runtime.   Old runtimes would never 
display cuv12 capability and would fail to run any image created with the 
requirement cuv12.
 






Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99235

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


[PATCH] D101974: [Utils][WIP] Refactor script for cc tests

2021-05-18 Thread Giorgis Georgakoudis via Phabricator via cfe-commits
ggeorgakoudis updated this revision to Diff 346235.
ggeorgakoudis added a comment.

Update correction for implicit simd checks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101974

Files:
  clang/utils/refactor_cc_tests.py

Index: clang/utils/refactor_cc_tests.py
===
--- /dev/null
+++ clang/utils/refactor_cc_tests.py
@@ -0,0 +1,136 @@
+#!/usr/bin/env python3
+
+import argparse
+import re
+import subprocess
+import sys
+import multiprocessing
+from itertools import repeat
+from itertools import starmap
+
+def run_update_cc(filename, llvm_util_dir, llvm_bin):
+# Probably we don't need to those arguments since we added a NOTE line.
+update_cc = [ llvm_util_dir + '/update_cc_test_checks.py', '--llvm-bin', llvm_bin,
+'--include-generated-func',
+'--function-signature',
+'--replace-value-regex', '\"__omp_offloading_[0-9a-z]+_[0-9a-z]+\"',
+'\"reduction_size[.].+[.]\"',
+'\"pl_cond[.].+[.|,]\"',
+'--prefix-filecheck-ir-name', '_',
+filename]
+
+# Run update_cc_test_checks.py.
+print('Running update_cc')
+popen = subprocess.Popen(update_cc, stdout=subprocess.PIPE, stderr=subprocess.PIPE, universal_newlines=True)
+stdout, stderr = popen.communicate()
+if popen.returncode != 0:
+sys.stderr.write('Failed to run update_cc '+ ' '.join(update_cc) + '\n')
+sys.stderr.write(stderr)
+sys.stderr.write(stdout)
+return popen.returncode
+
+return popen.returncode
+
+def refactor(filename, llvm_util_dir, llvm_bin):
+print('Processing file ', filename, '...')
+with open(filename, 'r') as f:
+input_lines = f.readlines()
+output_lines = ''
+cnt = 1
+check_prefix_set = {'CHECK'}
+for line in input_lines:
+# Modify run line.
+if line.startswith('// RUN'):
+# Process FileCheck in line.
+if 'FileCheck' in line:
+m = re.findall(r'--?check-prefix(?:es)?(?:\s|=)(.+?)\s+', line)
+# Extract check prefixes to remove check lines.
+check_prefix_list = []
+for i in m:
+check_prefix_list += i.split(',')
+check_prefix_set.update(set(check_prefix_list))
+# Delete all check prefixes.
+if m:
+line = re.sub(r'(?:-|--)check-prefix(?:es|)(?:\s|=).+?\s+', r'', line)
+
+# Generate implicit check.
+if '-fopenmp-simd' in line and \
+not re.search(r'\b-fopenmp\b', line) and \
+not re.search(r' simd', ''.join(input_lines)):
+if not re.search(r'--implicit-check-not="{{__kmpc|__tgt}}"', line):
+line = line[:-1] + \
+' --implicit-check-not="{{__kmpc|__tgt}}"\n'
+# Generate check prefix using the counter.
+else:
+line = line[:-1] + ' --check-prefix=CHECK%d\n'%(cnt)
+cnt += 1
+
+# Replace generic triple.
+# TODO: add ms_abi_triple
+if '%itanium_abi_triple' in line:
+line = re.sub(r'%itanium_abi_triple', 'x86_64-unknown-linux', line)
+
+if 'clang' in line and not '-triple' in line:
+line = re.sub(r'clang(_cc1|xx)?\s+', r'clang\g<1> -triple x86_64-unknown-linux ', line)
+output_lines += line
+elif line.startswith('// NOTE:'):
+# Skip NOTE line, script will add its own.
+continue
+else:
+check_prefix_regex = '(' + '|'.join(check_prefix_set) + ')'
+# Discard check line.
+if re.match(r'\s*//\s*%s'%(check_prefix_regex), line):
+continue
+
+# Skip empty comment lines to match update_cc handling.
+line_strip = line.strip()
+if line_strip == '//':
+pass
+# Keep line.
+else:
+output_lines += line
+# Add NOTE to avoid omp_offloading line number problems
+NOTE = ('// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py'
+' UTC_ARGS: --function-signature --include-generated-funcs'
+' --replace-value-regex "__omp_offloading_[0-9a-z]+_[0-9a-z]+" "reduction_size[.].+[.]" "pl_cond[.].+[.|,]"'
+' --prefix-filecheck-ir-name _\n')
+output_lines = NOTE + output_lines
+
+with open(filename, 'w') as f:
+f.write(output_lines)
+
+# Run update_cc_test_checks.py.
+ret = run_update_cc(filename, llvm_util_dir, llvm_bin)
+if ret == 0:
+  

[clang] 8dd5ef0 - [clang-repl] Better match the underlying architecture.

2021-05-18 Thread Vassil Vassilev via cfe-commits

Author: Vassil Vassilev
Date: 2021-05-18T19:14:33Z
New Revision: 8dd5ef01ef13e402784bba47f7a24175f5f00325

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

LOG: [clang-repl] Better match the underlying architecture.

In cases where -fno-integrated-as is specified we should overwrite the
EmitAssembly action as well.

We also should rely on the target triple from the process at least until we
implement out-of-process execution.

This patch should improve clang-repl on AIX.

Discussion available at: https://reviews.llvm.org/D96033

Differential revision: https://reviews.llvm.org/D102688

Added: 


Modified: 
clang/lib/Interpreter/IncrementalParser.cpp
clang/lib/Interpreter/Interpreter.cpp

Removed: 




diff  --git a/clang/lib/Interpreter/IncrementalParser.cpp 
b/clang/lib/Interpreter/IncrementalParser.cpp
index 70baabfeb8fbd..84b4d779d43c5 100644
--- a/clang/lib/Interpreter/IncrementalParser.cpp
+++ b/clang/lib/Interpreter/IncrementalParser.cpp
@@ -54,7 +54,8 @@ class IncrementalAction : public WrapperFrontendAction {
 Err = llvm::createStringError(
 std::errc::state_not_recoverable,
 "Driver initialization failed. "
-"Incremental mode for action is not supported");
+"Incremental mode for action %d is not supported",
+CI.getFrontendOpts().ProgramAction);
 return Act;
   case frontend::ASTDump:
 LLVM_FALLTHROUGH;
@@ -63,6 +64,8 @@ class IncrementalAction : public WrapperFrontendAction {
   case frontend::ParseSyntaxOnly:
 Act = CreateFrontendAction(CI);
 break;
+  case frontend::EmitAssembly:
+LLVM_FALLTHROUGH;
   case frontend::EmitObj:
 LLVM_FALLTHROUGH;
   case frontend::EmitLLVMOnly:

diff  --git a/clang/lib/Interpreter/Interpreter.cpp 
b/clang/lib/Interpreter/Interpreter.cpp
index 8de38c0afcd91..79acb5bd68982 100644
--- a/clang/lib/Interpreter/Interpreter.cpp
+++ b/clang/lib/Interpreter/Interpreter.cpp
@@ -157,7 +157,7 @@ IncrementalCompilerBuilder::create(std::vector &ClangArgv) {
   ParseDiagnosticArgs(*DiagOpts, ParsedArgs, &Diags);
 
   driver::Driver Driver(/*MainBinaryName=*/ClangArgv[0],
-llvm::sys::getDefaultTargetTriple(), Diags);
+llvm::sys::getProcessTriple(), Diags);
   Driver.setCheckInputsExist(false); // the input comes from mem buffers
   llvm::ArrayRef RF = llvm::makeArrayRef(ClangArgv);
   std::unique_ptr 
Compilation(Driver.BuildCompilation(RF));



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


[PATCH] D102688: [clang-repl] Better match the underlying architecture.

2021-05-18 Thread Vassil Vassilev via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8dd5ef01ef13: [clang-repl] Better match the underlying 
architecture. (authored by v.g.vassilev).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102688

Files:
  clang/lib/Interpreter/IncrementalParser.cpp
  clang/lib/Interpreter/Interpreter.cpp


Index: clang/lib/Interpreter/Interpreter.cpp
===
--- clang/lib/Interpreter/Interpreter.cpp
+++ clang/lib/Interpreter/Interpreter.cpp
@@ -157,7 +157,7 @@
   ParseDiagnosticArgs(*DiagOpts, ParsedArgs, &Diags);
 
   driver::Driver Driver(/*MainBinaryName=*/ClangArgv[0],
-llvm::sys::getDefaultTargetTriple(), Diags);
+llvm::sys::getProcessTriple(), Diags);
   Driver.setCheckInputsExist(false); // the input comes from mem buffers
   llvm::ArrayRef RF = llvm::makeArrayRef(ClangArgv);
   std::unique_ptr 
Compilation(Driver.BuildCompilation(RF));
Index: clang/lib/Interpreter/IncrementalParser.cpp
===
--- clang/lib/Interpreter/IncrementalParser.cpp
+++ clang/lib/Interpreter/IncrementalParser.cpp
@@ -54,7 +54,8 @@
 Err = llvm::createStringError(
 std::errc::state_not_recoverable,
 "Driver initialization failed. "
-"Incremental mode for action is not supported");
+"Incremental mode for action %d is not supported",
+CI.getFrontendOpts().ProgramAction);
 return Act;
   case frontend::ASTDump:
 LLVM_FALLTHROUGH;
@@ -63,6 +64,8 @@
   case frontend::ParseSyntaxOnly:
 Act = CreateFrontendAction(CI);
 break;
+  case frontend::EmitAssembly:
+LLVM_FALLTHROUGH;
   case frontend::EmitObj:
 LLVM_FALLTHROUGH;
   case frontend::EmitLLVMOnly:


Index: clang/lib/Interpreter/Interpreter.cpp
===
--- clang/lib/Interpreter/Interpreter.cpp
+++ clang/lib/Interpreter/Interpreter.cpp
@@ -157,7 +157,7 @@
   ParseDiagnosticArgs(*DiagOpts, ParsedArgs, &Diags);
 
   driver::Driver Driver(/*MainBinaryName=*/ClangArgv[0],
-llvm::sys::getDefaultTargetTriple(), Diags);
+llvm::sys::getProcessTriple(), Diags);
   Driver.setCheckInputsExist(false); // the input comes from mem buffers
   llvm::ArrayRef RF = llvm::makeArrayRef(ClangArgv);
   std::unique_ptr Compilation(Driver.BuildCompilation(RF));
Index: clang/lib/Interpreter/IncrementalParser.cpp
===
--- clang/lib/Interpreter/IncrementalParser.cpp
+++ clang/lib/Interpreter/IncrementalParser.cpp
@@ -54,7 +54,8 @@
 Err = llvm::createStringError(
 std::errc::state_not_recoverable,
 "Driver initialization failed. "
-"Incremental mode for action is not supported");
+"Incremental mode for action %d is not supported",
+CI.getFrontendOpts().ProgramAction);
 return Act;
   case frontend::ASTDump:
 LLVM_FALLTHROUGH;
@@ -63,6 +64,8 @@
   case frontend::ParseSyntaxOnly:
 Act = CreateFrontendAction(CI);
 break;
+  case frontend::EmitAssembly:
+LLVM_FALLTHROUGH;
   case frontend::EmitObj:
 LLVM_FALLTHROUGH;
   case frontend::EmitLLVMOnly:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D102696: [Analyzer] Find constraints that are directly attached to a BinOp

2021-05-18 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.



In D102696#2766337 , @NoQ wrote:

> Ok so the state has enough constraints. It's enough to know that `$x + $y == 
> 0` and `$y == 0` in order to deduce that `$x + 0 == 0`. But you're saying 
> that we don't know how to infer it so instead of making us able to infer it 
> let's make us ask the solver easier questions. That's a terrible hack but at 
> this point i think we might as well take it. @vsavchenko WDYT, what would it 
> take to fix the solver instead?

Actually, the problem is more subtle than that. The solver is already capable 
of solving such equations, the below test passes on the main branch:

  int test(int x, int y) {
if (y != 0)
  return 0;
if (x + y != 0)
  return 0;
clang_analyzer_eval(x + y == 0); // expected-warning{{TRUE}}
clang_analyzer_eval(y == 0); // expected-warning{{TRUE}}
clang_analyzer_eval(x == 0); // expected-warning{{TRUE}}
return 0;
  }

However, we can generalize the original problem, by using 3 variables. In this 
case no solver is capable of solving b/c we simply don't have enough equations:

  int test(int x, int y, int z) {
if (x + y + z != 0)
  return 0;
if (z != 0)
  return 0;
clang_analyzer_eval(x + y + z == 0);  // UNKNOWN !
clang_analyzer_eval(z == 0);  // OK.
return 0;
  }

The crux of the problem is that we don't ask the right question from the solver 
because we are literally unable to ask the right question (as of main). The 
solver takes an SVal (more precisely a symbolic expression) and can give back 
the related ranges or a concrete value.
We can see that the constraints are there, and they are correct:

  "constraints": [
 { "symbol": "reg_$1", "range": "{ [0, 0] }" },
 { "symbol": "(reg_$0) + (reg_$1) + (reg_$1)", 
"range": "{ [0, 0] }" }
   ],

However, we never try to query "(reg_$0) + (reg_$1) + (reg_$1)", instead we ask the solver separately with "(reg_$0)", "(reg_$0)" and with ""(reg_$0)". This is because of how we bind the SVals to 
the expressions and because of the "constant folding" like mechanism encoded in 
`getKnownValue` and in `simplifySVal`. And, we had bound the ConcreteInt 0 to 
the ImplicitCastExpr of 'z', previously and this fuels the "constant folding" 
mechanism (which is very useful in most cases but causes this logical error).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102696

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


[PATCH] D101849: [OpenMP][NFC] Refactor Clang OpenMP tests using update_cc_test_checks

2021-05-18 Thread Giorgis Georgakoudis via Phabricator via cfe-commits
ggeorgakoudis added a comment.

In D101849#2766411 , @mikerice wrote:

> In D101849#2764825 , @ABataev wrote:
>
>> No, it is not required. Most probably, needed to simplify test checks, 
>> nothing else.
>
> Thanks.  I'd like to remove the "REQUIRES: x86-registered-target", the -O1 
> for CHECK6,10, and regenerate the CHECK lines.  Unfortunately I am seeing 
> this mangling issue (https://bugs.llvm.org/show_bug.cgi?id=49767) when 
> running the script. @ggeorgakoudis, how did you get past this to generate the 
> CHECK lines in your change?

I built without asserts :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101849

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


[PATCH] D101777: [clang] p1099 1/5: [NFC] Break out BaseUsingDecl from UsingDecl

2021-05-18 Thread Nathan Sidwell via Phabricator via cfe-commits
urnathan added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:4623
 
-  Expected ToUsingOrErr = import(D->getUsingDecl());
-  if (!ToUsingOrErr)
-return ToUsingOrErr.takeError();
+  Expected ToIntroducerOrErr = import(D->getIntroducer());
+  if (!ToIntroducerOrErr)

shafik wrote:
> It would nice to expand upon the  `ImportUsingShadowDecl` in 
> `ASTImporterTest.cpp` as we expand this change to make sure the ASTImporter 
> is importing all the cases correctly. Right now we just have a very basic 
> test there.
Please clarify what you are requiring of this patch series. What you describe 
sounds like an orthogonal desire.


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

https://reviews.llvm.org/D101777

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


[PATCH] D102714: [clang-tidy] Fix a crash on invalid code for memset-usage check.

2021-05-18 Thread Haojian Wu via Phabricator via cfe-commits
hokein created this revision.
hokein added a reviewer: gribozavr2.
Herald added a subscriber: xazax.hun.
hokein requested review of this revision.
Herald added a project: clang-tools-extra.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102714

Files:
  clang-tools-extra/clang-tidy/bugprone/SuspiciousMemsetUsageCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/bugprone-suspicious-memset-usage.c


Index: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-suspicious-memset-usage.c
===
--- /dev/null
+++ 
clang-tools-extra/test/clang-tidy/checkers/bugprone-suspicious-memset-usage.c
@@ -0,0 +1,11 @@
+// RUN: %check_clang_tidy  -expect-clang-tidy-error  %s 
bugprone-suspicious-memset-usage %t
+
+void *memset(void *, int, __SIZE_TYPE__);
+void *memset(void *);
+// CHECK-MESSAGES: :[[@LINE-1]]:7: error: conflicting types for 'memset'
+
+void test() {
+  // no crash
+  memset(undefine);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: error: use of undeclared identifier
+}
Index: clang-tools-extra/clang-tidy/bugprone/SuspiciousMemsetUsageCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/SuspiciousMemsetUsageCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/SuspiciousMemsetUsageCheck.cpp
@@ -32,7 +32,7 @@
   // Look for memset(x, '0', z). Probably memset(x, 0, z) was intended.
   Finder->addMatcher(
   callExpr(
-  callee(MemsetDecl),
+  callee(MemsetDecl), argumentCountIs(3),
   hasArgument(1, characterLiteral(equals(static_cast('0')))
  .bind("char-zero-fill")),
   unless(hasArgument(
@@ -43,13 +43,13 @@
   // Look for memset with an integer literal in its fill_char argument.
   // Will check if it gets truncated.
   Finder->addMatcher(
-  callExpr(callee(MemsetDecl),
+  callExpr(callee(MemsetDecl), argumentCountIs(3),
hasArgument(1, integerLiteral().bind("num-fill"))),
   this);
 
   // Look for memset(x, y, 0) as that is most likely an argument swap.
   Finder->addMatcher(
-  callExpr(callee(MemsetDecl),
+  callExpr(callee(MemsetDecl), argumentCountIs(3),
unless(hasArgument(1, anyOf(characterLiteral(equals(
static_cast('0'))),
integerLiteral()


Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-suspicious-memset-usage.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-suspicious-memset-usage.c
@@ -0,0 +1,11 @@
+// RUN: %check_clang_tidy  -expect-clang-tidy-error  %s bugprone-suspicious-memset-usage %t
+
+void *memset(void *, int, __SIZE_TYPE__);
+void *memset(void *);
+// CHECK-MESSAGES: :[[@LINE-1]]:7: error: conflicting types for 'memset'
+
+void test() {
+  // no crash
+  memset(undefine);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: error: use of undeclared identifier
+}
Index: clang-tools-extra/clang-tidy/bugprone/SuspiciousMemsetUsageCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/SuspiciousMemsetUsageCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/SuspiciousMemsetUsageCheck.cpp
@@ -32,7 +32,7 @@
   // Look for memset(x, '0', z). Probably memset(x, 0, z) was intended.
   Finder->addMatcher(
   callExpr(
-  callee(MemsetDecl),
+  callee(MemsetDecl), argumentCountIs(3),
   hasArgument(1, characterLiteral(equals(static_cast('0')))
  .bind("char-zero-fill")),
   unless(hasArgument(
@@ -43,13 +43,13 @@
   // Look for memset with an integer literal in its fill_char argument.
   // Will check if it gets truncated.
   Finder->addMatcher(
-  callExpr(callee(MemsetDecl),
+  callExpr(callee(MemsetDecl), argumentCountIs(3),
hasArgument(1, integerLiteral().bind("num-fill"))),
   this);
 
   // Look for memset(x, y, 0) as that is most likely an argument swap.
   Finder->addMatcher(
-  callExpr(callee(MemsetDecl),
+  callExpr(callee(MemsetDecl), argumentCountIs(3),
unless(hasArgument(1, anyOf(characterLiteral(equals(
static_cast('0'))),
integerLiteral()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D96033: [clang-repl] Land initial infrastructure for incremental parsing

2021-05-18 Thread Vassil Vassilev via Phabricator via cfe-commits
v.g.vassilev added a comment.

In D96033#2766141 , @uweigand wrote:

> In D96033#2765954 , @v.g.vassilev 
> wrote:
>
>> @hubert.reinterpretcast, thanks for the feedback. I have created a patch as 
>> discussed -- https://reviews.llvm.org/D102688
>>
>> @uweigand, thanks for reaching out. I believe the patch above should fix 
>> your setup. Could you confirm?
>
> Unfortunately, it does not.  Changing the triple doesn't affect the 
> architecture the compiler generates code for.   If you wanted to change the 
> compiler to generate code for the architecture the JIT detects, the easiest 
> way would probably be to use (the equivalent of) "-march=native", which 
> causes the compiler to also auto-detect the current processor in the same way 
> as the JIT does.

Ah, okay. Could you try this patch:

  diff --git a/clang/lib/Interpreter/IncrementalExecutor.cpp 
b/clang/lib/Interpreter/IncrementalExecutor.cpp
  index f999e5eceaed..9a368d9122bc 100644
  --- a/clang/lib/Interpreter/IncrementalExecutor.cpp
  +++ b/clang/lib/Interpreter/IncrementalExecutor.cpp
  @@ -26,12 +26,14 @@
   namespace clang {
   
   IncrementalExecutor::IncrementalExecutor(llvm::orc::ThreadSafeContext &TSC,
  - llvm::Error &Err)
  + llvm::Error &Err,
  + const llvm::Triple &Triple)
   : TSCtx(TSC) {
 using namespace llvm::orc;
 llvm::ErrorAsOutParameter EAO(&Err);
   
  -  if (auto JitOrErr = LLJITBuilder().create())
  +  auto JTMB = JITTargetMachineBuilder(Triple);
  +  if (auto JitOrErr = 
LLJITBuilder().setJITTargetMachineBuilder(JTMB).create())
   Jit = std::move(*JitOrErr);
 else {
   Err = JitOrErr.takeError();
  diff --git a/clang/lib/Interpreter/IncrementalExecutor.h 
b/clang/lib/Interpreter/IncrementalExecutor.h
  index c4e33a390942..b4c6ddec1047 100644
  --- a/clang/lib/Interpreter/IncrementalExecutor.h
  +++ b/clang/lib/Interpreter/IncrementalExecutor.h
  @@ -14,6 +14,7 @@
   #define LLVM_CLANG_LIB_INTERPRETER_INCREMENTALEXECUTOR_H
   
   #include "llvm/ADT/StringRef.h"
  +#include "llvm/ADT/Triple.h"
   #include "llvm/ExecutionEngine/Orc/ExecutionUtils.h"
   
   #include 
  @@ -34,7 +35,8 @@ class IncrementalExecutor {
 llvm::orc::ThreadSafeContext &TSCtx;
   
   public:
  -  IncrementalExecutor(llvm::orc::ThreadSafeContext &TSC, llvm::Error &Err);
  +  IncrementalExecutor(llvm::orc::ThreadSafeContext &TSC, llvm::Error &Err,
  +  const llvm::Triple &Triple);
 ~IncrementalExecutor();
   
 llvm::Error addModule(std::unique_ptr M);
  diff --git a/clang/lib/Interpreter/Interpreter.cpp 
b/clang/lib/Interpreter/Interpreter.cpp
  index 79acb5bd6898..025bdb14c54f 100644
  --- a/clang/lib/Interpreter/Interpreter.cpp
  +++ b/clang/lib/Interpreter/Interpreter.cpp
  @@ -16,6 +16,7 @@
   #include "IncrementalExecutor.h"
   #include "IncrementalParser.h"
   
  +#include "clang/AST/ASTContext.h"
   #include "clang/Basic/TargetInfo.h"
   #include "clang/CodeGen/ModuleBuilder.h"
   #include "clang/CodeGen/ObjectFilePCHContainerOperations.h"
  @@ -204,8 +205,11 @@ llvm::Expected 
Interpreter::Parse(llvm::StringRef Code) {
   llvm::Error Interpreter::Execute(Transaction &T) {
 assert(T.TheModule);
 if (!IncrExecutor) {
  +const llvm::Triple &Triple =
  +  getCompilerInstance()->getASTContext().getTargetInfo().getTriple();
   llvm::Error Err = llvm::Error::success();
  -IncrExecutor = std::make_unique(*TSCtx, Err);
  +IncrExecutor = std::make_unique(*TSCtx, Err, 
Triple);
  +
   if (Err)
 return Err;
 }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96033

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


[PATCH] D102715: [AIX] Fix LIT failure on native aix

2021-05-18 Thread Xiangling Liao via Phabricator via cfe-commits
Xiangling_L created this revision.
Xiangling_L added reviewers: hubert.reinterpretcast, sfertile, jasonliu, 
daltenty.
Xiangling_L requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102715

Files:
  clang/test/Sema/struct-packed-align.c


Index: clang/test/Sema/struct-packed-align.c
===
--- clang/test/Sema/struct-packed-align.c
+++ clang/test/Sema/struct-packed-align.c
@@ -167,6 +167,9 @@
 // must maintain ABI backwards compatibility.
 extern int o1[sizeof(struct packed_chars) == 3 ? 1 : -1];
 extern int o2[__alignof(struct packed_chars) == 1 ? 1 : -1];
+#elif defined(_AIX)
+extern int o1[sizeof(struct packed_chars) == 4 ? 1 : -1];
+extern int o2[__alignof(struct packed_chars) == 4 ? 1 : -1];
 #else
 extern int o1[sizeof(struct packed_chars) == 2 ? 1 : -1];
 extern int o2[__alignof(struct packed_chars) == 1 ? 1 : -1];


Index: clang/test/Sema/struct-packed-align.c
===
--- clang/test/Sema/struct-packed-align.c
+++ clang/test/Sema/struct-packed-align.c
@@ -167,6 +167,9 @@
 // must maintain ABI backwards compatibility.
 extern int o1[sizeof(struct packed_chars) == 3 ? 1 : -1];
 extern int o2[__alignof(struct packed_chars) == 1 ? 1 : -1];
+#elif defined(_AIX)
+extern int o1[sizeof(struct packed_chars) == 4 ? 1 : -1];
+extern int o2[__alignof(struct packed_chars) == 4 ? 1 : -1];
 #else
 extern int o1[sizeof(struct packed_chars) == 2 ? 1 : -1];
 extern int o2[__alignof(struct packed_chars) == 1 ? 1 : -1];
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D102706: [clang-format] Add new LambdaBodyIndentation option

2021-05-18 Thread Vitali Lovich via Phabricator via cfe-commits
vlovich added a comment.

In D102706#2766680 , 
@HazardyKnusperkeks wrote:

> Maybe a bit more test cases with smaller lambdas? Or without the outer 
> parenthesis?

I'm not sure I understand this comment. Which test case are you referring to by 
"or without the outer parenthesis"?




Comment at: clang/include/clang/Format/Format.h:2456
+  enum LambdaBodyIndentationKind : unsigned char {
+/// Align lambda body relative to the lambda signature. This is the 
default.
+LBI_Signature,

HazardyKnusperkeks wrote:
> I think you should add examples, because for me it is not 100% what's the 
> difference is.
Good idea. Meant to do that & forgot. In terms of an example, do  you find the 
test case or description in the phabricator message useful or are you looking 
for something else?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102706

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


[PATCH] D102105: [OpenMP][NFC] Refactor cc tests for implicit simd check

2021-05-18 Thread Giorgis Georgakoudis via Phabricator via cfe-commits
ggeorgakoudis updated this revision to Diff 346255.
ggeorgakoudis added a comment.

Update for correct implicit checks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102105

Files:
  clang/test/OpenMP/cancel_codegen.cpp
  clang/test/OpenMP/cancellation_point_codegen.cpp
  clang/test/OpenMP/debug-info-complex-byval.cpp
  clang/test/OpenMP/debug-info-openmp-array.cpp
  clang/test/OpenMP/distribute_codegen.cpp
  clang/test/OpenMP/distribute_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/distribute_private_codegen.cpp
  clang/test/OpenMP/for_firstprivate_codegen.cpp
  clang/test/OpenMP/for_lastprivate_codegen.cpp
  clang/test/OpenMP/for_linear_codegen.cpp
  clang/test/OpenMP/for_private_codegen.cpp
  clang/test/OpenMP/for_reduction_codegen.cpp
  clang/test/OpenMP/for_reduction_task_codegen.cpp
  clang/test/OpenMP/master_taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/openmp_win_codegen.cpp
  clang/test/OpenMP/parallel_codegen.cpp
  clang/test/OpenMP/parallel_copyin_codegen.cpp
  clang/test/OpenMP/parallel_firstprivate_codegen.cpp
  clang/test/OpenMP/parallel_for_codegen.cpp
  clang/test/OpenMP/parallel_for_lastprivate_conditional.cpp
  clang/test/OpenMP/parallel_for_linear_codegen.cpp
  clang/test/OpenMP/parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_if_codegen.cpp
  clang/test/OpenMP/parallel_master_codegen.cpp
  clang/test/OpenMP/parallel_master_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_codegen.cpp
  clang/test/OpenMP/parallel_master_taskloop_lastprivate_codegen.cpp
  clang/test/OpenMP/parallel_private_codegen.cpp
  clang/test/OpenMP/parallel_reduction_codegen.cpp
  clang/test/OpenMP/parallel_reduction_task_codegen.cpp
  clang/test/OpenMP/parallel_sections_codegen.cpp
  clang/test/OpenMP/parallel_sections_reduction_task_codegen.cpp
  clang/test/OpenMP/sections_firstprivate_codegen.cpp
  clang/test/OpenMP/sections_lastprivate_codegen.cpp
  clang/test/OpenMP/sections_private_codegen.cpp
  clang/test/OpenMP/sections_reduction_codegen.cpp
  clang/test/OpenMP/sections_reduction_task_codegen.cpp
  clang/test/OpenMP/single_codegen.cpp
  clang/test/OpenMP/single_firstprivate_codegen.cpp
  clang/test/OpenMP/single_private_codegen.cpp
  clang/test/OpenMP/target_codegen_global_capture.cpp
  clang/test/OpenMP/target_map_codegen_03.cpp
  clang/test/OpenMP/target_parallel_codegen.cpp
  clang/test/OpenMP/target_parallel_for_codegen.cpp
  clang/test/OpenMP/target_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/target_parallel_if_codegen.cpp
  clang/test/OpenMP/target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/target_parallel_reduction_task_codegen.cpp
  clang/test/OpenMP/target_teams_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_collapse_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_dist_schedule_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_firstprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_lastprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_collapse_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_dist_schedule_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_firstprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_lastprivate_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_order_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_private_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_proc_bind_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_reduction_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_schedule_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_private_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_reduction_codegen.cpp
  clang/test/OpenMP/target_teams_num_teams_codegen.cpp
  clang/test/OpenMP/target_teams_thread_limit_codegen.cpp
  clang/test/OpenMP/task_codegen.cpp
  clang/test/OpenMP/task_if_codegen.cpp
  clang/test/OpenMP/task_in_reduction_codegen

[PATCH] D101777: [clang] p1099 1/5: [NFC] Break out BaseUsingDecl from UsingDecl

2021-05-18 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added inline comments.



Comment at: clang/lib/AST/ASTImporter.cpp:4623
 
-  Expected ToUsingOrErr = import(D->getUsingDecl());
-  if (!ToUsingOrErr)
-return ToUsingOrErr.takeError();
+  Expected ToIntroducerOrErr = import(D->getIntroducer());
+  if (!ToIntroducerOrErr)

urnathan wrote:
> shafik wrote:
> > It would nice to expand upon the  `ImportUsingShadowDecl` in 
> > `ASTImporterTest.cpp` as we expand this change to make sure the ASTImporter 
> > is importing all the cases correctly. Right now we just have a very basic 
> > test there.
> Please clarify what you are requiring of this patch series. What you describe 
> sounds like an orthogonal desire.
Sure, happy to clarify. As the functionality is complete, tests should be added 
to verify that the `ASTImporter` correctly deals with the new functionality but 
it would be nice as we add that new test to also expand the tests further but 
that would be optional but probably not too much more work.


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

https://reviews.llvm.org/D101777

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


[PATCH] D102723: [HIP] Tighten checks in hip-include-path.hip test case

2021-05-18 Thread Bjorn Pettersson via Phabricator via cfe-commits
bjope created this revision.
bjope added reviewers: yaxunl, tra, zhuhan0.
bjope requested review of this revision.
Herald added a project: clang.

The checks (both positive and negative checks) in the test case
hip-include-path.hip could mistakenly end up matching the string
"clang" from the InstalledDir in case the build dir for example
was named "/home/username/build-clang/". Intention with this
patch is to tighten up the checks a bit to filter our the
part of the paths that match with InstalledDir when doing the
checks, as well as matching "/lib/clang/" rather than
just "clang/".

Problem was found when building with

  -DCLANG_DEFAULT_RTLIB=compiler-rt
  -DCLANG_DEFAULT_CXX_STDLIB=libc++

and having "clang/" in the path to the build dir.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102723

Files:
  clang/test/Driver/hip-include-path.hip


Index: clang/test/Driver/hip-include-path.hip
===
--- clang/test/Driver/hip-include-path.hip
+++ clang/test/Driver/hip-include-path.hip
@@ -16,36 +16,40 @@
 // RUN:   -std=c++11 --rocm-path=%S/Inputs/rocm -nogpuinc -nogpulib %s 2>&1 \
 // RUN:   | FileCheck -check-prefixes=COMMON,CLANG,NOHIP %s
 
+// COMMON: InstalledDir: [[ROOT:[^"]*]]/bin
+
 // COMMON-LABEL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
-// CLANG-SAME: "-internal-isystem" "{{.*}}clang/{{.*}}/include/cuda_wrappers"
-// NOCLANG-NOT: "{{.*}}clang/{{.*}}/include/cuda_wrappers"
+// CLANG-SAME: "-internal-isystem" 
"[[ROOT]]/lib/clang/{{.*}}/include/cuda_wrappers"
+// NOCLANG-NOT: "[[ROOT]]/lib/clang/{{.*}}/include/cuda_wrappers"
 // HIP-SAME: "-internal-isystem" "{{.*}}Inputs/rocm/include"
 // NOHIP-NOT: "{{.*}}Inputs/rocm/include"
 // HIP-SAME: "-include" "__clang_hip_runtime_wrapper.h"
 // NOHIP-NOT: "-include" "__clang_hip_runtime_wrapper.h"
 // skip check of standard C++ include path
-// CLANG-SAME: "-internal-isystem" "{{.*}}clang/{{.*}}/include"
-// NOCLANG-NOT: "{{.*}}clang/{{.*}}/include"
+// CLANG-SAME: "-internal-isystem" "[[ROOT]]/lib/clang/{{.*}}/include"
+// NOCLANG-NOT: "[[ROOT]]/lib/clang/{{.*}}/include"
 
 // COMMON-LABEL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
-// CLANG-SAME: "-internal-isystem" "{{.*}}clang/{{.*}}/include/cuda_wrappers"
-// NOCLANG-NOT: "{{.*}}clang/{{.*}}/include/cuda_wrappers"
+// CLANG-SAME: "-internal-isystem" 
"[[ROOT]]/lib/clang/{{.*}}/include/cuda_wrappers"
+// NOCLANG-NOT: "[[ROOT]]/lib/clang/{{.*}}/include/cuda_wrappers"
 // HIP-SAME: "-internal-isystem" "{{.*}}Inputs/rocm/include"
 // NOHIP-NOT: "{{.*}}Inputs/rocm/include"
 // HIP-SAME: "-include" "__clang_hip_runtime_wrapper.h"
 // NOHIP-NOT: "-include" "__clang_hip_runtime_wrapper.h"
 // skip check of standard C++ include path
-// CLANG-SAME: "-internal-isystem" "{{.*}}clang/{{.*}}/include"
-// NOCLANG-NOT: "{{.*}}clang/{{.*}}/include"
+// CLANG-SAME: "-internal-isystem" "[[ROOT]]/lib/clang/{{.*}}/include"
+// NOCLANG-NOT: "[[ROOT]]/lib/clang/{{.*}}/include"
 
 // RUN: %clang -c -### -target x86_64-unknown-linux-gnu --cuda-gpu-arch=gfx900 
\
 // RUN:   -std=c++11 --rocm-path=%S/Inputs/rocm -nogpulib %s 2>&1 \
 // RUN:   --hip-version=3.5 | FileCheck -check-prefixes=ROCM35 %s
 
+// ROCM35: InstalledDir: [[ROOT:[^"]*]]/bin
+
 // ROCM35-LABEL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
-// ROCM35-NOT: "{{.*}}clang/{{.*}}/include/cuda_wrappers"
-// ROCM35-SAME: "-internal-isystem" "{{[^"]*}}clang/{{[^"]*}}"
+// ROCM35-NOT: "[[ROOT]]/lib/clang/{{.*}}/include/cuda_wrappers"
+// ROCM35-SAME: "-internal-isystem" "[[ROOT]]/lib/clang/{{[^"]*}}"
 // ROCM35-SAME: "-internal-isystem" "{{[^"]*}}Inputs/rocm/include"
 // ROCM35-NOT: "-include" "__clang_hip_runtime_wrapper.h"
 // skip check of standard C++ include path
-// ROCM35-SAME: "-internal-isystem" "{{[^"]*}}clang/{{[^"]*}}/include"
+// ROCM35-SAME: "-internal-isystem" "[[ROOT]]/lib/clang/{{.*}}/include"


Index: clang/test/Driver/hip-include-path.hip
===
--- clang/test/Driver/hip-include-path.hip
+++ clang/test/Driver/hip-include-path.hip
@@ -16,36 +16,40 @@
 // RUN:   -std=c++11 --rocm-path=%S/Inputs/rocm -nogpuinc -nogpulib %s 2>&1 \
 // RUN:   | FileCheck -check-prefixes=COMMON,CLANG,NOHIP %s
 
+// COMMON: InstalledDir: [[ROOT:[^"]*]]/bin
+
 // COMMON-LABEL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
-// CLANG-SAME: "-internal-isystem" "{{.*}}clang/{{.*}}/include/cuda_wrappers"
-// NOCLANG-NOT: "{{.*}}clang/{{.*}}/include/cuda_wrappers"
+// CLANG-SAME: "-internal-isystem" "[[ROOT]]/lib/clang/{{.*}}/include/cuda_wrappers"
+// NOCLANG-NOT: "[[ROOT]]/lib/clang/{{.*}}/include/cuda_wrappers"
 // HIP-SAME: "-internal-isystem" "{{.*}}Inputs/rocm/include"
 // NOHIP-NOT: "{{.*}}Inputs/rocm/include"
 // HIP-SAME: "-include" "__clang_hip_runtime_wrapper.h"
 // NOHIP-NOT: "-include" "__clang_hip_runtime_wrapper.h"
 // skip check of standard C++ include path
-// CLANG-SAME: "-internal-isystem" "{{.*}}clang/{{.*}}/include"
-// NOCLANG-NOT: "{{.*}}clang/{{.*}}/include"

[PATCH] D102723: [HIP] Tighten checks in hip-include-path.hip test case

2021-05-18 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl accepted this revision.
yaxunl added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102723

___
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-18 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

Sam, this patch has apparently triggered some unwanted side effects. I'm still 
reducing the failures to something that could be used for debugging, but the 
rough symptoms are:

We now end up emitting the code for the host-only static member functions of 
instantiated class templates during device-side compilation.
Clang now complains about not allowed nontrivial static initializers for some 
variables in class templates.


Repository:
  rG LLVM Github Monorepo

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] D102724: Revert "[AIX] Avoid structor alias; die before bad alias codegen"

2021-05-18 Thread Jake Egan via Phabricator via cfe-commits
Jake-Egan created this revision.
Jake-Egan added reviewers: cebowleratibm, jasonliu, sfertile, daltenty, 
DiggerLin, hubert.reinterpretcast.
Herald added subscribers: jeroen.dobbelaere, nemanjai.
Jake-Egan requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

It is no longer needed to avoid structor alias because AIX now has an alias 
implementation.

This reverts commit b116ded57da3530e661f871f4191c59cd9e091cd 
.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102724

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/aix-constructor-alias.c
  llvm/test/CodeGen/PowerPC/aix-alias.ll

Index: llvm/test/CodeGen/PowerPC/aix-alias.ll
===
--- llvm/test/CodeGen/PowerPC/aix-alias.ll
+++ /dev/null
@@ -1,116 +0,0 @@
-; TODO: Add object generation test when visibility for object generation
-;   is implemnted.
-
-; RUN: llc -verify-machineinstrs -mtriple powerpc-ibm-aix-xcoff -mcpu=pwr4 \
-; RUN: -mattr=-altivec -data-sections=false -xcoff-traceback-table=false < %s | \
-; RUN:   FileCheck --check-prefix=ASM %s
-; RUN: llc -verify-machineinstrs -mtriple powerpc64-ibm-aix-xcoff -mcpu=pwr4 \
-; RUN: -mattr=-altivec -data-sections=false -xcoff-traceback-table=false < %s | \
-; RUN:   FileCheck --check-prefix=ASM %s
-
-@var = global i32 42
-@var1 = alias i32, i32* @var
-@var2 = alias i32, i32* @var1
-@var_l = linkonce_odr alias i32, i32* @var
-@var_i = internal alias i32, i32* @var
-@var_h = hidden alias i32, i32* @var
-@var_p = protected alias i32, i32* @var
-
-@array = global [2 x i32] [i32 1, i32 2], align 4
-@x = global i32* bitcast (i8* getelementptr (i8, i8* bitcast ([2 x i32]* @array to i8*), i64 4) to i32*), align 4
-@bitcast_alias = alias i32*, i32** @x
-
-define i32 @fun() {
-  ret i32 0
-}
-
-%FunTy = type i32()
-@fun_weak = weak alias %FunTy, %FunTy* @fun
-@fun_hidden = hidden alias %FunTy, %FunTy* @fun
-@fun_ptr = global i32()* @fun_weak
-
-define i32 @test() {
-entry:
-   %tmp = load i32, i32* @var1
-   %tmp1 = load i32, i32* @var2
-   %tmp0 = load i32, i32* @var_i
-   %tmp2 = call i32 @fun()
-   %tmp3 = add i32 %tmp, %tmp2
-   %tmp4 = call i32 @fun_weak()
-   %tmp5 = add i32 %tmp3, %tmp4
-   %tmp6 = add i32 %tmp1, %tmp5
-   %tmp7 = add i32 %tmp6, %tmp0
-   %fun_ptr1 = alloca i32 ()*
-   store i32 ()* @fun_weak, i32 ()** %fun_ptr1
-   %callee.knr.cast = bitcast i32 ()** %fun_ptr1 to i32 ()*
-   %tmp8 = call i32 %callee.knr.cast()
-   %tmp9 = call i32 @fun_hidden()
-   %tmp10 = add i32 %tmp7, %tmp8
-   %tmp11 = add i32 %tmp10, %tmp9
-   ret i32 %tmp11
-}
-
-; ASM: .globl  fun[DS]
-; ASM-NEXT:.globl  .fun
-; ASM-NEXT:.align  4
-; ASM-NEXT:.csect fun[DS]
-; ASM-NEXT:  fun_weak:   # @fun
-; ASM-NEXT:  fun_hidden:
-; ASM: .csect .text[PR],2
-; ASM-NEXT:  .fun:
-; ASM-NEXT:  .fun_weak:
-; ASM-NEXT:  .fun_hidden:
-; ASM-NEXT:  # %bb.0:
-; ASM-NEXT:li 3, 0
-; ASM-NEXT:blr
-; ASM-NEXT:  # -- End function
-; ASM:   .csect .text[PR],2
-; ASM-NEXT:  .test:
-; ASM-NEXT:  # %bb.0:# %entry
-; ASM: bl .fun
-; ASM-NEXT:nop
-; ASM: bl .fun_weak
-; ASM-NEXT:nop
-; ASM: bl .fun_hidden
-; ASM:   # -- End function
-; ASM-NEXT:.csect .data[RW]
-; ASM-NEXT:.globl  var
-; ASM:   var:
-; ASM-NEXT:  var1:
-; ASM-NEXT:  var2:
-; ASM-NEXT:  var_l:
-; ASM-NEXT:  var_i:
-; ASM-NEXT:  var_h:
-; ASM-NEXT:  var_p:
-; ASM-NEXT:.vbyte  4, 42
-; ASM-NEXT:   .globl array
-; ASM:   array:
-; ASM-NEXT:.vbyte 4, 1 # 0x1
-; ASM-NEXT:.vbyte 4, 2 # 0x2
-; ASM-NEXT:.globl x
-; ASM:   x:
-; ASM-NEXT:  bitcast_alias:
-; ASM-NEXT:.vbyte  {{[0-9]+}}, array+4
-; ASM-NEXT:.globl  fun_ptr
-; ASM:   fun_ptr:
-; ASM-NEXT:.vbyte  {{[0-9]+}}, fun_weak
-; ASM-NEXT:.globl  var1
-; ASM-NEXT:.globl  var2
-; ASM-NEXT:.weak var_l
-; ASM-NEXT:.lglobl var_i
-; ASM-NEXT:.globl  var_h,hidden
-; ASM-NEXT:.globl  var_p,protected
-; ASM-NEXT:.globl bitcast_alias
-; ASM-NEXT:.weak fun_weak
-; ASM-NEXT:.weak .fun_weak
-; ASM-NEXT:.globl  fun_hidden,hidden
-; ASM-NEXT:.globl  .fun_hidden,hidden
-; ASM-NEXT:.toc
-; ASM-NEXT:  L..C0:
-; ASM-NEXT:.tc var1[TC],var1
-; ASM-NEXT:  L..C1:
-; ASM-NEXT:.tc var2[TC],var2
-; ASM-NEXT:  L..C2:
-; ASM-NEXT:.tc var_i[TC],var_i
-; ASM-NEXT:  L..C3:
-; ASM-NEXT:.tc fun_weak[TC],fun_weak
Index: clang/test/Driver/aix-constructor-alias.c
===
--- clang/test/Driver/aix-constructor-alias.c
+++ /dev/null
@@ -1,7 +0,0 @@
-// Check that we don't pass -mconstructor-aliases when compiling for AIX.
-
-// RUN: %clang -### 

[PATCH] D102306: Add gfx1034

2021-05-18 Thread Konstantin Zhuravlyov via Phabricator via cfe-commits
kzhuravl added inline comments.



Comment at: llvm/include/llvm/BinaryFormat/ELF.h:737
   EF_AMDGPU_MACH_AMDGCN_GFX1033   = 0x039,
+  EF_AMDGPU_MACH_AMDGCN_GFX1034   = 0x03e,
   EF_AMDGPU_MACH_AMDGCN_GFX602= 0x03a,

For future reference, MACH values are sorted by value, reserved MACHs need to 
be replaced with real MACHs (see line 742 in this review).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102306

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


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

2021-05-18 Thread Andrew Savonichev via Phabricator via cfe-commits
asavonic added a comment.

ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98895

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


[PATCH] D102724: Revert "[AIX] Avoid structor alias; die before bad alias codegen"

2021-05-18 Thread Jason Liu via Phabricator via cfe-commits
jasonliu added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:4964
   if (!RawTriple.isOSDarwin() && !RawTriple.isNVPTX() &&
-  !RawTriple.isAMDGPU() && !RawTriple.isOSAIX())
+  !RawTriple.isAMDGPU())
 CmdArgs.push_back("-mconstructor-aliases");

Format as clang-format suggest. You could run clang-format or git-clang-format 
just for your commits by the way. 



Comment at: clang/test/Driver/aix-constructor-alias.c:3
-
-// RUN: %clang -### -target powerpc-ibm-aix7.1.0.0 %s -c -o %t.o 2>&1 \
-// RUN:   | FileCheck %s

Instead of removing this file, we want to check if `-mconstructor-aliases` is 
passed in for AIX.
Check if there are other existing files doing it for other target, then you 
just need to add the check for AIX target in other files.



Comment at: llvm/test/CodeGen/PowerPC/aix-alias.ll:4
-
-; RUN: llc -verify-machineinstrs -mtriple powerpc-ibm-aix-xcoff -mcpu=pwr4 \
-; RUN: -mattr=-altivec -data-sections=false -xcoff-traceback-table=false < 
%s | \

I don't think we want to remove the testing of our alias implementation. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102724

___
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-18 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D102237#2767052 , @tra wrote:

> Sam, this patch has apparently triggered some unwanted side effects. I'm 
> still reducing the failures to something that could be used for debugging, 
> but the rough symptoms are:
>
> We now end up emitting the code for the host-only static member functions of 
> instantiated class templates during device-side compilation.
> Clang now complains about not allowed nontrivial static initializers for some 
> variables in class templates.



In D102237#2767052 , @tra wrote:

> Sam, this patch has apparently triggered some unwanted side effects. I'm 
> still reducing the failures to something that could be used for debugging, 
> but the rough symptoms are:
>
> We now end up emitting the code for the host-only static member functions of 
> instantiated class templates during device-side compilation.
> Clang now complains about not allowed nontrivial static initializers for some 
> variables in class templates.

We limit the variables to device or constant variables, e.g. 
https://godbolt.org/z/seh1n7KnY

xxx is emitted because it is implicitly constant, but yyy is not emitted.

It would be interesting to know what kind of variables are emitted.

Would you like the change reverted?


Repository:
  rG LLVM Github Monorepo

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] D102237: [CUDA][HIP] Fix non-ODR-use of static device variable

2021-05-18 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

In D102237#2767131 , @yaxunl wrote:

> 



> It would be interesting to know what kind of variables are emitted.

I'm still reducing the failure.  I'll send you a reproducer once I have it.

> Would you like the change reverted?

We have a bit of time -- till the end of the week.  Let's wait till we have a 
reproducer and a better idea what's going on and whether it's something easy to 
fix.


Repository:
  rG LLVM Github Monorepo

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] D97085: [OpenMP] libomp: implement OpenMP 5.1 inoutset task dependence type

2021-05-18 Thread Andrey Churbanov via Phabricator via cfe-commits
AndreyChurbanov added inline comments.



Comment at: openmp/runtime/src/kmp_taskdeps.cpp:344-346
+// link node as successor of all nodes in the prev_set if any
+npredecessors +=
+__kmp_depnode_link_successor(gtid, thread, task, node, prev_set);

protze.joachim wrote:
> AndreyChurbanov wrote:
> > protze.joachim wrote:
> > > If I understand this code right, this has O(n^2) complexity for two sets 
> > > of size n?
> > > 
> > > Consider:
> > > ```
> > > for (int i=0; i > > #pragma omp task depend(in:A)
> > > work(A,i);
> > > }
> > > for (int i=0; i > > #pragma omp task depend(inoutset:A)
> > > work(A,i);
> > > }
> > > ```
> > > All n tasks in the first loop would be predecessor for each of the tasks 
> > > in the second loop. This will also result in n^2 releases/notifications.
> > > 
> > > 
> > > I'd suggest to model the dependencies like:
> > > ```
> > > for (int i=0; i > > #pragma omp task depend(in:A)
> > > work(A,i);
> > > }
> > > #pragma omp taskwait depend(inout:A) nowait
> > > for (int i=0; i > > #pragma omp task depend(inoutset:A)
> > > work(A,i);
> > > }
> > > ```
> > > I.e., add a dummy dependency node between the two sets, which has n 
> > > predecessors and n successors. You probably understand the depnode code 
> > > better, than I do, but I think you would only need to add some code in 
> > > line 357, where `last_set` is moved to `prev_set`.
> > > This dummy node would reduce linking and releasing complexity to O(n).
> > This could be a separate research project.  Because such change may cause 
> > performance regressions on some real codes, so it needs thorough 
> > investigation.  I mean insertion of an auxiliary dummy node into dependency 
> > graph is definitely an overhead, which may or may not be overridden by 
> > reduction in number of edges in the graph.  Or it can be made optional 
> > optimization under an external control, if there is a significant gain in 
> > some particular case.
> I don't suggest to insert the auxiliary node in the general case. Just for 
> the case that you see a transition of `in` -> `inoutset` or vice versa.
> 
> With current task dependencies, you always have 1 node notifying n nodes 
> (`out` -> `in`) or n nodes notifying one node (`in` -> `out`). You can see 
> this as an amortized O(1) operation per task in the graph.
> 
> Here you introduce a code pattern, where n nodes each will need to notify m 
> other nodes. This leads to an O(n) operation per task. I'm really worried 
> about the complexity of this pattern.
> If there is no use case with large n, I don't understand, why `inoutset` was 
> introduced in the first place.
> I don't suggest to insert the auxiliary node in the general case. Just for 
> the case that you see a transition of `in` -> `inoutset` or vice versa.
> 
> With current task dependencies, you always have 1 node notifying n nodes 
> (`out` -> `in`) or n nodes notifying one node (`in` -> `out`). You can see 
> this as an amortized O(1) operation per task in the graph.
> 
> Here you introduce a code pattern, where n nodes each will need to notify m 
> other nodes. This leads to an O(n) operation per task. I'm really worried 
> about the complexity of this pattern.
No, I don't introduce the pattern, as it already worked for sets of tasks with 
`in` dependency following set of tasks with `mutexinoutset` dependency or vice 
versa.

> If there is no use case with large n, I don't understand, why `inoutset` was 
> introduced in the first place.
I didn't like that `inoutset` was introduced as the clone of "in" in order to 
separate two (big) sets of mutually independent tasks, but this has already 
been added to specification, so we have to implement it. Of cause your 
suggestion can dramatically speed up dependency processing of some trivial case 
with two huge sets of tasks one wit `in` dependency another with `inoutset`; 
but it slightly changes the semantics of user's code, and actually can slowdown 
other cases.  I would let users do such optimizations.  Or compiler can do this 
once it sees big sets of tasks those don't have barrier-like "taskwait nowait". 
 For user this is one line of code, for compiler this is dozen lines of code, 
for runtime library this is pretty big change which does not worth efforts to 
implement, I think.  Especially given that such "optimization" will definitely 
slowdown some cases.  E.g. small set of tasks with `in` dependency can be 
followed single task with `inoutset` in a loop. Why should we slowdown this 
case?  Library has no idea of the structure of user's code.

In general, I don't like the idea when runtime library tries to optimize user's 
code.  Especially along with other changes in the same patch.



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

https://reviews.llvm.org/D97085

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

[PATCH] D102728: [clang][Sema] removes -Wfree-nonheap-object reference param false positive

2021-05-18 Thread Christopher Di Bella via Phabricator via cfe-commits
cjdb created this revision.
cjdb added reviewers: gbiv, manojgupta, aaron.ballman.
Herald added a reviewer: george.burgess.iv.
Herald added subscribers: dcaballe, cota, teijeong, rdzhabarov, tatianashp, 
msifontes, jurahul, Kayjukh, grosul1, Joonsoo, liufengdb, aartbik, lucyrfox, 
mgester, arpith-jacob, antiagainst, shauheen, rriddle, mehdi_amini.
Herald added a reviewer: rriddle.
cjdb requested review of this revision.
Herald added subscribers: cfe-commits, stephenneuendorffer, nicolasvasilache.
Herald added projects: clang, MLIR.

Taking the address of a reference parameter might be valid, and without
CFA, false positives are going to be more trouble than they're worth.

This reverts commit 499571ea835daf786626a0db1e12f890b6cd8f8d 
.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102728

Files:
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/warn-free-nonheap-object.cpp
  mlir/lib/IR/OperationSupport.cpp

Index: mlir/lib/IR/OperationSupport.cpp
===
--- mlir/lib/IR/OperationSupport.cpp
+++ mlir/lib/IR/OperationSupport.cpp
@@ -237,9 +237,7 @@
   if (isDynamicStorage()) {
 TrailingOperandStorage &storage = getDynamicStorage();
 storage.~TrailingOperandStorage();
-// Workaround false positive in -Wfree-nonheap-object
-auto *mem = &storage;
-free(mem);
+free(&storage);
   } else {
 getInlineStorage().~TrailingOperandStorage();
   }
@@ -373,11 +371,8 @@
 new (&newOperands[numOperands]) OpOperand(owner);
 
   // If the current storage is also dynamic, free it.
-  if (isDynamicStorage()) {
-// Workaround false positive in -Wfree-nonheap-object
-auto *mem = &storage;
-free(mem);
-  }
+  if (isDynamicStorage())
+free(&storage);
 
   // Update the storage representation to use the new dynamic storage.
   dynamicStorage.setPointerAndInt(newStorage, true);
Index: clang/test/Sema/warn-free-nonheap-object.cpp
===
--- clang/test/Sema/warn-free-nonheap-object.cpp
+++ clang/test/Sema/warn-free-nonheap-object.cpp
@@ -10,24 +10,40 @@
 
 int GI;
 
+void free_reference(char &x) { ::free(&x); }
+void free_reference(char &&x) { ::free(&x); }
+void std_free_reference(char &x) { std::free(&x); }
+void std_free_reference(char &&x) { std::free(&x); }
+
 struct S {
-  operator char *() { return ptr; }
+  operator char *() { return ptr1; }
 
   void CFree() {
-::free(&ptr); // expected-warning {{attempt to call free on non-heap object 'ptr'}}
-::free(&I);   // expected-warning {{attempt to call free on non-heap object 'I'}}
-::free(ptr);
+::free(&ptr1); // expected-warning {{attempt to call free on non-heap object 'ptr1'}}
+::free(&I);// expected-warning {{attempt to call free on non-heap object 'I'}}
+::free(ptr1);
+free_reference(*ptr2);
+free_reference(static_cast(*ptr3));
   }
 
   void CXXFree() {
-std::free(&ptr); // expected-warning {{attempt to call std::free on non-heap object 'ptr'}}
-std::free(&I);   // expected-warning {{attempt to call std::free on non-heap object 'I'}}
-std::free(ptr);
+std::free(&ptr1); // expected-warning {{attempt to call std::free on non-heap object 'ptr1'}}
+std::free(&I);// expected-warning {{attempt to call std::free on non-heap object 'I'}}
+std::free(ptr1);
+std_free_reference(*ptr2);
+std_free_reference(static_cast(*ptr3));
   }
 
 private:
-  char *ptr = (char *)std::malloc(10);
+  char *ptr1 = (char *)std::malloc(10);
+  char *ptr2 = (char *)std::malloc(10);
+  char *ptr3 = (char *)std::malloc(10);
   static int I;
+
+  static void free_reference(char &x) { ::free(&x); }
+  static void free_reference(char &&x) { ::free(&x); }
+  static void std_free_reference(char &x) { std::free(&x); }
+  static void std_free_reference(char &&x) { std::free(&x); }
 };
 
 int S::I = 0;
@@ -49,6 +65,14 @@
 int *P = &I;
 free(P);
   }
+  {
+char* P = (char *)std::malloc(2);
+free_reference(*P);
+  }
+  {
+char* P = (char *)std::malloc(2);
+free_reference(static_cast(*P));
+  }
   {
 void *P = std::malloc(8);
 free(P); // FIXME diagnosing this would require control flow analysis.
@@ -93,6 +117,14 @@
 void *P = std::malloc(8);
 std::free(P);
   }
+  {
+char* P = (char *)std::malloc(2);
+std_free_reference(*P);
+  }
+  {
+char* P = (char *)std::malloc(2);
+std_free_reference(static_cast(*P));
+  }
   {
 int A[] = {0, 1, 2, 3};
 std::free(A); // expected-warning {{attempt to call std::free on non-heap object 'A'}}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -10463,7 +10463,9 @@
   if (const auto *Lvalue = dyn_cast(UnaryExpr->getSubExpr())) {
 const Decl *D = Lvalue->getDecl();

[PATCH] D102730: [clang-format] Support custom If macros

2021-05-18 Thread Vitali Lovich via Phabricator via cfe-commits
vlovich created this revision.
vlovich added reviewers: curdeius, MyDeveloperDay, HazardyKnusperkeks.
vlovich added a project: clang-format.
vlovich requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Like with ForEachMacros, support user to provide additional macros that act 
like `if` statements.

This makes it possible to support KJ_IF_MAYBE from the cap'n'proto library:
https://github.com/capnproto/capnproto/blob/master/kjdoc/tour.md#maybes.

https://bugs.llvm.org/show_bug.cgi?id=49354


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102730

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/FormatToken.h
  clang/lib/Format/FormatTokenLexer.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -17111,6 +17111,11 @@
   CHECK_PARSE("ForEachMacros: [BOOST_FOREACH, Q_FOREACH]", ForEachMacros,
   BoostAndQForeach);
 
+  Style.IfMacros.clear();
+  std::vector CustomIfs;
+  CustomIfs.push_back("MYIF");
+  CHECK_PARSE("IfMacros: [MYIF]", IfMacros, CustomIfs);
+
   Style.AttributeMacros.clear();
   CHECK_PARSE("BasedOnStyle: LLVM", AttributeMacros,
   std::vector{"__capability"});
@@ -19684,11 +19689,14 @@
 
 TEST_F(FormatTest, SpacesInConditionalStatement) {
   FormatStyle Spaces = getLLVMStyle();
+  Spaces.IfMacros.clear();
+  Spaces.IfMacros.push_back("MYIF");
   Spaces.SpacesInConditionalStatement = true;
   verifyFormat("for ( int i = 0; i; i++ )\n  continue;", Spaces);
   verifyFormat("if ( !a )\n  return;", Spaces);
   verifyFormat("if ( a )\n  return;", Spaces);
   verifyFormat("if constexpr ( a )\n  return;", Spaces);
+  verifyFormat("MYIF( a )\n  return;", Spaces);
   verifyFormat("switch ( a )\ncase 1:\n  return;", Spaces);
   verifyFormat("while ( a )\n  return;", Spaces);
   verifyFormat("while ( (a && b) )\n  return;", Spaces);
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -1363,7 +1363,7 @@
 // Reset token type in case we have already looked at it and then
 // recovered from an error (e.g. failure to find the matching >).
 if (!CurrentToken->isOneOf(
-TT_LambdaLSquare, TT_LambdaLBrace, TT_AttributeMacro,
+TT_LambdaLSquare, TT_LambdaLBrace, TT_AttributeMacro, TT_IfMacro,
 TT_ForEachMacro, TT_TypenameMacro, TT_FunctionLBrace,
 TT_ImplicitStringLiteral, TT_InlineASMBrace, TT_FatArrow,
 TT_LambdaArrow, TT_NamespaceMacro, TT_OverloadedOperator,
@@ -3022,6 +3022,9 @@
 FormatStyle::SBPO_ControlStatementsExceptForEachMacros &&
 Left.is(TT_ForEachMacro))
   return false;
+if (Left.is(TT_IfMacro)) {
+  return false;
+}
 return Line.Type == LT_ObjCDecl || Left.is(tok::semi) ||
(Style.SpaceBeforeParens != FormatStyle::SBPO_Never &&
 (Left.isOneOf(tok::pp_elif, tok::kw_for, tok::kw_while,
Index: clang/lib/Format/FormatTokenLexer.cpp
===
--- clang/lib/Format/FormatTokenLexer.cpp
+++ clang/lib/Format/FormatTokenLexer.cpp
@@ -39,6 +39,8 @@
 
   for (const std::string &ForEachMacro : Style.ForEachMacros)
 Macros.insert({&IdentTable.get(ForEachMacro), TT_ForEachMacro});
+  for (const std::string &IfMacro : Style.IfMacros)
+Macros.insert({&IdentTable.get(IfMacro), TT_IfMacro});
   for (const std::string &AttributeMacro : Style.AttributeMacros)
 Macros.insert({&IdentTable.get(AttributeMacro), TT_AttributeMacro});
   for (const std::string &StatementMacro : Style.StatementMacros)
@@ -1014,6 +1016,9 @@
   tok::pp_define) &&
 it != Macros.end()) {
   FormatTok->setType(it->second);
+  if (it->second == TT_IfMacro) {
+FormatTok->Tok.setKind(tok::kw_if);
+  }
 } else if (FormatTok->is(tok::identifier)) {
   if (MacroBlockBeginRegex.match(Text)) {
 FormatTok->setType(TT_MacroBlockBegin);
Index: clang/lib/Format/FormatToken.h
===
--- clang/lib/Format/FormatToken.h
+++ clang/lib/Format/FormatToken.h
@@ -52,6 +52,7 @@
   TYPE(FunctionDeclarationName)\
   TYPE(FunctionLBrace) \
   TYPE(FunctionTypeLParen) \
+  TYPE(IfMacro)\
   TYPE(ImplicitStringLiteral)  \
   TYPE(InheritanceColon)   

[PATCH] D102730: [clang-format] Support custom If macros

2021-05-18 Thread Vitali Lovich via Phabricator via cfe-commits
vlovich added inline comments.



Comment at: clang/include/clang/Format/Format.h:2098
+  ///
+  /// For example: KJ_IF_MAYBE.
+  std::vector IfMacros;

Should I put a hyperlink to 
https://github.com/capnproto/capnproto/blob/master/kjdoc/tour.md#maybes?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102730

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


[PATCH] D92024: [clang] Implement P0692R1 from C++20 (access checking on specializations and instantiations)

2021-05-18 Thread Alex Orlov via Phabricator via cfe-commits
aorlov updated this revision to Diff 346289.
aorlov added a comment.

Simplified the solution. Replaced RemoveDiagnosticsFromPool with 
SuppressAccessChecks.
@krisb, please, look.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92024

Files:
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseTemplate.cpp
  clang/test/CXX/class.access/class.friend/p1.cpp
  clang/test/CXX/drs/dr1xx.cpp
  clang/test/CXX/temp/temp.spec/func.spec.cpp
  clang/test/CXX/temp/temp.spec/part.spec.cpp
  clang/test/CXX/temp/temp.spec/temp.explicit/p11.cpp
  clang/test/CXX/temp/temp.spec/temp.explicit/p12.cpp

Index: clang/test/CXX/temp/temp.spec/temp.explicit/p12.cpp
===
--- clang/test/CXX/temp/temp.spec/temp.explicit/p12.cpp
+++ clang/test/CXX/temp/temp.spec/temp.explicit/p12.cpp
@@ -43,7 +43,14 @@
 Temp(int x) {}
   };
 
-  template <> class Temp Temp::make() { // expected-error {{'Private' is a private member of 'test2::A'}}
+  template <> class Temp Temp::make() {
 return Temp(0);
   }
+
+  template <>
+  class Temp {
+static Temp make() { // expected-error {{is a private member}}
+  return Temp(0);
+}
+  };
 }
Index: clang/test/CXX/temp/temp.spec/temp.explicit/p11.cpp
===
--- clang/test/CXX/temp/temp.spec/temp.explicit/p11.cpp
+++ /dev/null
@@ -1,19 +0,0 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
-// expected-no-diagnostics
-
-class X {
-  template  class Y {};
-};
-
-class A {
-  class B {};
-  class C {};
-};
-
-// C++0x [temp.explicit] 14.7.2/11:
-//   The usual access checking rules do not apply to names used to specify
-//   explicit instantiations.
-template class X::Y;
-
-// As an extension, this rule is applied to explicit specializations as well.
-template <> class X::Y {};
Index: clang/test/CXX/temp/temp.spec/part.spec.cpp
===
--- /dev/null
+++ clang/test/CXX/temp/temp.spec/part.spec.cpp
@@ -0,0 +1,481 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// C++20 [temp.class.spec] 13.7.5/10
+//   The usual access checking rules do not apply to non-dependent names
+//   used to specify template arguments of the simple-template-id of the
+//   partial specialization.
+//
+// C++20 [temp.spec] 13.9/6:
+//   The usual access checking rules do not apply to names in a declaration
+//   of an explicit instantiation or explicit specialization...
+
+// TODO: add test cases for `enum`
+
+// class for tests
+class TestClass {
+public:
+  class PublicClass {};
+  template  class TemplatePublicClass {};
+
+  using AliasPublicClass = unsigned char;
+
+  void publicFunc();
+  void publicFuncOverloaded();
+  void publicFuncOverloaded(int);
+
+  static void publicStaticFunc();
+  static void publicStaticFuncOverloaded();
+  static void publicStaticFuncOverloaded(int);
+
+  static constexpr int publicStaticInt = 42;
+
+protected:
+  // expected-note@+1 8{{declared protected here}}
+  class ProtectedClass {};
+  template  class TemplateProtectedClass {};
+
+  // expected-note@+1 2{{declared protected here}}
+  using AliasProtectedClass = const char;
+
+  // expected-note@+1 3{{declared protected here}}
+  void protectedFunc();
+  void protectedFuncOverloaded();
+  void protectedFuncOverloaded(int);
+
+  // expected-note@+1 2{{declared protected here}}
+  static void protectedStaticFunc();
+  // expected-note@+1 2{{declared protected here}}
+  static void protectedStaticFuncOverloaded();
+  static void protectedStaticFuncOverloaded(int);
+
+  // expected-note@+1 2{{declared protected here}}
+  static constexpr int protectedStaticInt = 43;
+
+private:
+  // expected-note@+1 10{{declared private here}}
+  class PrivateClass {};
+  // expected-note@+1 {{declared private here}}
+  template  class TemplatePrivateClass {};
+
+  using AliasPrivateClass = char *;
+
+  void privateFunc();
+  void privateFuncOverloaded();
+  void privateFuncOverloaded(int);
+
+  static void privateStaticFunc();
+  static void privateStaticFuncOverloaded();
+  static void privateStaticFuncOverloaded(int);
+
+  static constexpr int privateStaticInt = 44;
+};
+
+void globalFunction() {}
+
+//--//
+
+// template declarations for explicit instantiations
+template  class IT1 {};
+template  class IT2 {};
+template  class IT3 {};
+template  class IT4 {};
+template  class IT5 {};
+template  class IT6 {
+  template  class NIT1 {};
+};
+template  class IT7 {};
+template  class IT8 {};
+template  class IT9 {};
+
+// explicit instantiations
+
+// public
+template class IT1;
+template struct IT1>;
+template class IT1;
+template struct IT2;
+template class IT3;
+template struct IT4<&TestClass::publicFunc>;
+template class IT4<&TestClass::publicFuncOverloaded>;
+template class IT5<&TestClass::p

LLVM buildmaster will be restarted tonight

2021-05-18 Thread Galina Kistanova via cfe-commits
 Hello everyone,

LLVM buildmaster will be restarted at 8PM PST today.

Thanks

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


[PATCH] D102736: Fix tmp files being left on Windows builds.

2021-05-18 Thread Amy Huang via Phabricator via cfe-commits
akhuang created this revision.
akhuang added reviewers: rnk, aganea, amccarth.
Herald added subscribers: dexonsmith, hiraditya.
akhuang requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Clang writes object files by first writing to a .tmp file and then
renaming to the final .obj name. On Windows, if a compile is killed
partway through the .tmp files don't get deleted.

Currently it seems like `RemoveFileOnSignal` takes care of deleting the
tmp files on Linux, but on Windows we need to call
`setDeleteDisposition` on tmp files so that they are deleted when
closed.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102736

Files:
  clang/include/clang/Frontend/CompilerInstance.h
  clang/lib/Frontend/CompilerInstance.cpp
  llvm/include/llvm/Support/FileSystem.h
  llvm/lib/Support/Path.cpp
  llvm/lib/Support/Windows/Path.inc

Index: llvm/lib/Support/Windows/Path.inc
===
--- llvm/lib/Support/Windows/Path.inc
+++ llvm/lib/Support/Windows/Path.inc
@@ -438,6 +438,16 @@
   return std::error_code();
 }
 
+std::error_code duplicateHandle(file_t FromHandle, file_t &ToHandle) {
+  if (!::DuplicateHandle(::GetCurrentProcess(), FromHandle,
+ ::GetCurrentProcess(), &ToHandle, 0, 0,
+ DUPLICATE_SAME_ACCESS)) {
+std::error_code ec = mapWindowsError(GetLastError());
+return ec;
+  }
+  return std::error_code();
+}
+
 static std::error_code rename_internal(HANDLE FromHandle, const Twine &To,
bool ReplaceIfExists) {
   SmallVector ToWide;
Index: llvm/lib/Support/Path.cpp
===
--- llvm/lib/Support/Path.cpp
+++ llvm/lib/Support/Path.cpp
@@ -1306,6 +1306,10 @@
 #endif
   return std::move(Ret);
 }
+
+std::error_code UnmarkFileForDeletion(file_t Handle) {
+  return setDeleteDisposition(Handle, false);
+}
 } // namespace fs
 
 } // namespace sys
Index: llvm/include/llvm/Support/FileSystem.h
===
--- llvm/include/llvm/Support/FileSystem.h
+++ llvm/include/llvm/Support/FileSystem.h
@@ -989,6 +989,22 @@
 inline file_t convertFDToNativeFile(int FD) { return FD; }
 #endif
 
+// On Windows, removes file deletion flag so that the file is not deleted when
+// closed. On non-Windows, this is a no-op.
+std::error_code UnmarkFileForDeletion(file_t Handle);
+
+// Calls Windows function DuplicateHandle. No-op on non-Windows.
+std::error_code duplicateHandle(file_t FromHandle, file_t &ToHandle);
+
+#ifndef _WIN32
+inline std::error_code DontRemoveFileOnClose(file_t Handle) {
+  return std::error_code();
+}
+inline std::error_code duplicateHandle(file_t FromHandle, file_t &ToHandle) {
+  return std::error_code();
+}
+#endif
+
 /// Return an open handle to standard in. On Unix, this is typically FD 0.
 /// Returns kInvalidFile when the stream is closed.
 file_t getStdinHandle();
Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -716,6 +716,9 @@
 if (OF.TempFilename.empty())
   continue;
 
+// On Windows, remove deletion flags so the file can be kept and renamed.
+llvm::sys::fs::UnmarkFileForDeletion(OF.Handle);
+
 // If '-working-directory' was passed, the output filename should be
 // relative to that.
 SmallString<128> NewOutFile(OF.Filename);
@@ -809,6 +812,7 @@
   }
 
   std::string TempFile;
+  int fd;
   if (UseTemporary) {
 // Create a temporary file.
 // Insert - before the extension (if any), and because some tools
@@ -820,10 +824,14 @@
 TempPath += "-";
 TempPath += OutputExtension;
 TempPath += ".tmp";
-int fd;
-std::error_code EC = llvm::sys::fs::createUniqueFile(
-TempPath, fd, TempPath,
-Binary ? llvm::sys::fs::OF_None : llvm::sys::fs::OF_Text);
+llvm::sys::fs::OpenFlags Flags =
+Binary ? llvm::sys::fs::OF_None : llvm::sys::fs::OF_Text;
+// Use OF_Delete on Windows so that file can be marked for deletion.
+#ifdef _WIN32
+Flags |= llvm::sys::fs::OF_Delete;
+#endif
+std::error_code EC =
+llvm::sys::fs::createUniqueFile(TempPath, fd, TempPath, Flags);
 
 if (CreateMissingDirectories &&
 EC == llvm::errc::no_such_file_or_directory) {
@@ -861,8 +869,15 @@
 
   // Add the output file -- but don't try to remove "-", since this means we are
   // using stdin.
+  void *FileHandle = nullptr;
+#ifdef _WIN32
+  if (fd) {
+llvm::sys::fs::duplicateHandle(llvm::sys::fs::convertFDToNativeFile(fd),
+   FileHandle);
+  }
+#endif
   OutputFiles.emplace_back(((OutputPath != "-") ? OutputPath : "").str(),
-   std::move(TempFile));
+ 

[PATCH] D100252: [clang] Fix for "Bug 27113 - MSVC-compat __identifier implementation incomplete"

2021-05-18 Thread Melvin Fox via Phabricator via cfe-commits
super_concat added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100252

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


[PATCH] D102736: Fix tmp files being left on Windows builds.

2021-05-18 Thread Amy Huang via Phabricator via cfe-commits
akhuang added inline comments.



Comment at: clang/lib/Frontend/CompilerInstance.cpp:872
   // using stdin.
+  void *FileHandle = nullptr;
+#ifdef _WIN32

I'm saving the windows HANDLE here instead of using `fd` because for some 
reason calling `_get_osfhandle(fd)` in `UnmarkFileForDeletion` fails. 

It also doesn't work if I don't duplicate the handle, but I don't entirely 
understand why. (I think when we try to rename the file, it fails with file not 
found, so maybe it gets deleted?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102736

___
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-18 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

Here's one example reproducer: https://godbolt.org/z/77M596W89
It's rather hairy, but should be usable for further debugging.

There are no CUDA attributes anywhere in sight, but we do end up emitting a 
host-only constructor for `o_u` which calls `strlen`.


Repository:
  rG LLVM Github Monorepo

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


  1   2   >