[PATCH] D101763: [analyzer][ctu] Avoid parsing invocation list again and again during on-demand parsing of CTU

[Ella Ma via Phabricator via cfe-commits]

OikawaKirie updated this revision to Diff 343585.
OikawaKirie added a comment.

Replace `wc -l` with `count`.

Sorry for the spam.


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

https://reviews.llvm.org/D101763

Files:
  clang/include/clang/CrossTU/CrossTranslationUnit.h
  clang/lib/CrossTU/CrossTranslationUnit.cpp
  clang/test/Analysis/multiple-invocation-list-parsing.c

Index: clang/test/Analysis/multiple-invocation-list-parsing.c
===
--- /dev/null
+++ clang/test/Analysis/multiple-invocation-list-parsing.c
@@ -0,0 +1,26 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+
+// RUN: echo "void bar() {}" > %t/importee.c
+// RUN: echo '[{"directory":"%t", "command":"cc -c %t/importee.c", "file":"%t/importee.c"}]' > %t/compile_commands.json
+// RUN: %clang_extdef_map -p %t "%t/importee.c" > %t/externalDefMap.txt
+// RUN: echo "" > %t/invocations.yaml
+
+// RUN: strace -e trace=openat \
+// RUN: %clang_cc1 -fsyntax-only -analyze \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-config experimental-enable-naive-ctu-analysis=true \
+// RUN:   -analyzer-config ctu-dir=%t \
+// RUN:   -analyzer-config ctu-invocation-list=invocations.yaml \
+// RUN:   %s 2>&1 | grep 'invocations\.yaml' | count 1
+
+// REQUIRES: shell, system-linux
+
+void bar();
+
+void foo() {
+  // Import twice to see whether the second import will open the invocation
+  // list again.
+  bar();
+  bar();
+}
Index: clang/lib/CrossTU/CrossTranslationUnit.cpp
===
--- clang/lib/CrossTU/CrossTranslationUnit.cpp
+++ clang/lib/CrossTU/CrossTranslationUnit.cpp
@@ -92,6 +92,10 @@
 
   std::string message(int Condition) const override {
 switch (static_cast(Condition)) {
+case index_error_code::success:
+  // There should not be a success error. Jump to unreachable directly.
+  // Add this case to make the compiler stop complaining.
+  break;
 case index_error_code::unspecified:
   return "An unknown error has occurred.";
 case index_error_code::missing_index_file:
@@ -667,12 +671,15 @@
   /// Lazily initialize the invocation list member used for on-demand parsing.
   if (InvocationList)
 return llvm::Error::success();
+  else if (index_error_code::success != PreviousParsingResult)
+return llvm::make_error(PreviousParsingResult);
 
   llvm::ErrorOr> FileContent =
   llvm::MemoryBuffer::getFile(InvocationListFilePath);
-  if (!FileContent)
-return llvm::make_error(
-index_error_code::invocation_list_file_not_found);
+  if (!FileContent) {
+PreviousParsingResult = index_error_code::invocation_list_file_not_found;
+return llvm::make_error(PreviousParsingResult);
+  }
   std::unique_ptr ContentBuffer = std::move(*FileContent);
   assert(ContentBuffer && "If no error was produced after loading, the pointer "
   "should not be nullptr.");
@@ -680,8 +687,13 @@
   llvm::Expected ExpectedInvocationList =
   parseInvocationList(ContentBuffer->getBuffer(), PathStyle);
 
-  if (!ExpectedInvocationList)
-return ExpectedInvocationList.takeError();
+  // Handle the error to store the code for next call to this function.
+  if (!ExpectedInvocationList) {
+llvm::handleAllErrors(
+ExpectedInvocationList.takeError(),
+[&](const IndexError ) { PreviousParsingResult = E.getCode(); });
+return llvm::make_error(PreviousParsingResult);
+  }
 
   InvocationList = *ExpectedInvocationList;
 
Index: clang/include/clang/CrossTU/CrossTranslationUnit.h
===
--- clang/include/clang/CrossTU/CrossTranslationUnit.h
+++ clang/include/clang/CrossTU/CrossTranslationUnit.h
@@ -38,6 +38,7 @@
 namespace cross_tu {
 
 enum class index_error_code {
+  success = 0,
   unspecified = 1,
   missing_index_file,
   invalid_index_format,
@@ -253,6 +254,7 @@
 /// In case of on-demand parsing, the invocations for parsing the source
 /// files is stored.
 llvm::Optional InvocationList;
+index_error_code PreviousParsingResult = index_error_code::success;
   };
 
   /// Maintain number of AST loads and check for reaching the load limit.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101763: [analyzer][ctu] Avoid parsing invocation list again and again during on-demand parsing of CTU

[Ella Ma via Phabricator via cfe-commits]

OikawaKirie updated this revision to Diff 343582.
OikawaKirie added a comment.

- Update the test case as suggested.
- Add a case branch for the `index_error_code::success` error code in function 
`IndexErrorCategory::message` to silent the compiler warnings.


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

https://reviews.llvm.org/D101763

Files:
  clang/include/clang/CrossTU/CrossTranslationUnit.h
  clang/lib/CrossTU/CrossTranslationUnit.cpp
  clang/test/Analysis/multiple-invocation-list-parsing.c

Index: clang/test/Analysis/multiple-invocation-list-parsing.c
===
--- /dev/null
+++ clang/test/Analysis/multiple-invocation-list-parsing.c
@@ -0,0 +1,29 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+
+// RUN: echo "void bar() {}" > %t/importee.c
+// RUN: echo '[{"directory":"%t", "command":"cc -c %t/importee.c", "file":"%t/importee.c"}]' > %t/compile_commands.json
+// RUN: %clang_extdef_map -p %t "%t/importee.c" > %t/externalDefMap.txt
+// RUN: echo "" > %t/invocations.yaml
+
+// RUN: strace -e trace=openat \
+// RUN: %clang_cc1 -fsyntax-only -analyze \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-config experimental-enable-naive-ctu-analysis=true \
+// RUN:   -analyzer-config ctu-dir=%t \
+// RUN:   -analyzer-config ctu-invocation-list=invocations.yaml \
+// RUN:   %s 2>&1 | grep 'invocations\.yaml' | wc -l | FileCheck %s
+
+// REQUIRES: shell, system-linux
+
+// Check the log for the second open of the invocation list.
+// CHECK: {{1}}
+
+void bar();
+
+void foo() {
+  // Import twice to see whether the second import will open the invocation
+  // list again.
+  bar();
+  bar();
+}
Index: clang/lib/CrossTU/CrossTranslationUnit.cpp
===
--- clang/lib/CrossTU/CrossTranslationUnit.cpp
+++ clang/lib/CrossTU/CrossTranslationUnit.cpp
@@ -92,6 +92,10 @@
 
   std::string message(int Condition) const override {
 switch (static_cast(Condition)) {
+case index_error_code::success:
+  // There should not be a success error. Jump to unreachable directly.
+  // Add this case to make the compiler stop complaining.
+  break;
 case index_error_code::unspecified:
   return "An unknown error has occurred.";
 case index_error_code::missing_index_file:
@@ -667,12 +671,15 @@
   /// Lazily initialize the invocation list member used for on-demand parsing.
   if (InvocationList)
 return llvm::Error::success();
+  else if (index_error_code::success != PreviousParsingResult)
+return llvm::make_error(PreviousParsingResult);
 
   llvm::ErrorOr> FileContent =
   llvm::MemoryBuffer::getFile(InvocationListFilePath);
-  if (!FileContent)
-return llvm::make_error(
-index_error_code::invocation_list_file_not_found);
+  if (!FileContent) {
+PreviousParsingResult = index_error_code::invocation_list_file_not_found;
+return llvm::make_error(PreviousParsingResult);
+  }
   std::unique_ptr ContentBuffer = std::move(*FileContent);
   assert(ContentBuffer && "If no error was produced after loading, the pointer "
   "should not be nullptr.");
@@ -680,8 +687,13 @@
   llvm::Expected ExpectedInvocationList =
   parseInvocationList(ContentBuffer->getBuffer(), PathStyle);
 
-  if (!ExpectedInvocationList)
-return ExpectedInvocationList.takeError();
+  // Handle the error to store the code for next call to this function.
+  if (!ExpectedInvocationList) {
+llvm::handleAllErrors(
+ExpectedInvocationList.takeError(),
+[&](const IndexError ) { PreviousParsingResult = E.getCode(); });
+return llvm::make_error(PreviousParsingResult);
+  }
 
   InvocationList = *ExpectedInvocationList;
 
Index: clang/include/clang/CrossTU/CrossTranslationUnit.h
===
--- clang/include/clang/CrossTU/CrossTranslationUnit.h
+++ clang/include/clang/CrossTU/CrossTranslationUnit.h
@@ -38,6 +38,7 @@
 namespace cross_tu {
 
 enum class index_error_code {
+  success = 0,
   unspecified = 1,
   missing_index_file,
   invalid_index_format,
@@ -253,6 +254,7 @@
 /// In case of on-demand parsing, the invocations for parsing the source
 /// files is stored.
 llvm::Optional InvocationList;
+index_error_code PreviousParsingResult = index_error_code::success;
   };
 
   /// Maintain number of AST loads and check for reaching the load limit.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D92677: Provide default location of sysroot for Baremetal toolchain.

[Petr Hosek via Phabricator via cfe-commits]

phosek added inline comments.



Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:102
+  SmallString<128> SysRootDir;
+  llvm::sys::path::append(SysRootDir, getDriver().Dir, "../lib/clang-runtimes",
+  getDriver().getTargetTriple());

I apologize for raising a comment on an older change but I ran into this 
recently, GCC uses `../sys-root` as the default sysroot location and I think 
it'd be useful for Clang to be consistent.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92677

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

[PATCH] D101601: [SelectionDAG] Make fast and linearize visible by clang -pre-RA-sched

[Pengfei Wang via Phabricator via cfe-commits]

pengfei added inline comments.



Comment at: clang/test/CodeGen/pre-ra-sched.c:1
+// RUN: %clang %s -mllvm -pre-RA-sched=fast -c -o - | FileCheck %s
+// RUN: %clang %s -mllvm -pre-RA-sched=linearize -c -o - | FileCheck %s

Should we add test under llvm/test? A bit strange that changing LLVM code while 
adding test in clang/test.



Comment at: llvm/include/llvm/CodeGen/TargetLowering.h:105
+  Fast,// Fast suboptimal list scheduling
+  Linearize,   // Linearize DAG, no scheduling
+};

This comma should be removed.



Comment at: llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:273-276
+if (TLI->getSchedulingPreference() == Sched::Fast)
+  return createFastDAGScheduler(IS, OptLevel);
+if (TLI->getSchedulingPreference() == Sched::Linearize)
+  return createDAGLinearizer(IS, OptLevel);

I saw they are always registered in ScheduleDAGFast.cpp:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/CodeGen/SelectionDAG/ScheduleDAGFast.cpp#L36
Why do we register them again here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101601

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

[PATCH] D102015: [clang CodeGen] Don't crash on large atomic function parameter.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Objective-C object types also have aggregate evaluation kind.  Those can only 
be used as value types in an old, fragile ObjC ABI, but I believe we haven't 
yet formally decided to remove support for that.  Fortunately, however, there's 
a much better simplification available: this `hasAggregateEvaluationKind(Ty)` 
call is literally doing nothing that couldn't just be a `getAs()` 
call, and then we don't need to worry about it.

...I'm confused about why this code is doing what it's doing with cleanups, 
though.  Why does it only apply when the parameter is indirect?  I believe 
`isParamDestroyedInCallee()` can apply to types that are passed in other ways, 
so where we pushing the destructor for those, and why isn't it good enough to 
handle this case as well?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102015

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

[PATCH] D101868: [clang-format] Adds a formatter for aligning arrays of structs

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks added inline comments.



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:1404
+ isArrayOfStructuresInit(TheLine));
+  if (AlignArrayOfStructuresInit) {
+Penalty += AlignedArrayOfStructuresInitLineFormatter(

feg208 wrote:
> HazardyKnusperkeks wrote:
> > I'm not sure that you should go before the no column limit. In either case 
> > you should have a test case for that.
> I kept the ordering but I will admit to misgivings about it. None of the 
> tests fail and it seems like it needs to be ordered in this way but as a 
> newbie contributor to this project I don't feel confident in that assertion. 
> Do the included tests cover it? What test that isn't currently there would 
> better create issues?
See below.



Comment at: clang/unittests/Format/FormatTest.cpp:16352
 
+template 
+auto createStylesImpl(

This is a nice approach!

Could it be made constexpr? I'm not sure about C++14.



Comment at: clang/unittests/Format/FormatTest.cpp:16371
+   Style);
+}
+

feg208 wrote:
> HazardyKnusperkeks wrote:
> > curdeius wrote:
> > > I think we need more tests:
> > > * with a comma after the last element of array
> > > * with assignment and not only initialization?
> > > * without `struct` keyword
> > > * with short lines/long values to see how wrapping behaves
> > >   * also, with multiple string literals in one struct, e.g. `"hello" 
> > > "world"` (that will get splitted into multiple lines)
> > > * with non-plain-array types (i.e. missing `[]`/`[3]`)
> > > * interaction with other Align* options (e.g. 
> > > `AlignConsecutiveAssignments`, two arrays one after another, 
> > > `AlignConsecutiveDeclarations`).
> > In addition to that I want to see:
> > * How it behaves with a smaller column limit which would be violated if 
> > there is no additional wrapping. There I also want one without 
> > `verifyFormat`.
> > * With no column limit.
> > * Maybe with a `const`, `inline` or something similar. (How about east 
> > `const` vs. west `const`?)
> I added
> 
>   - with a comma after the last element of array
>   - with assignment and not only initialization?
>   - without struct keyword
>   - with short lines/long values to see how wrapping behaves (also multiple 
> string literals) But I still should add another test I think
>   - with non-plain-array types (i.e. missing []/[3])
>   - interaction with other Align* options (e.g. AlignConsecutiveAssignments, 
> two arrays one after another, AlignConsecutiveDeclarations). I will say that 
> I did this in a brute force way. Maybe there is something else I should do 
> here?
>   - With no column limit.
> 
> I still need tests with east and west const and without verifyFormat. For the 
> latter is there an example test I could look at? Idly scrolling through 
> FormatTest.cpp it seems like most stuff uses verifyFormat? Or maybe I 
> misunderstood the request?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
What's missing is to format your last code with a column limit of 20 or so.

Regards using `EXPECT_EQ`:
```
EXPECT_EQ("test demo[] = {\n"
  "{56, 23,\"hello world i am a very long line that really, in any "
  "\"\n"
  "\"just world, ought be split over multiple lines\" },\n"
  "{-1, 93463, \"world\"  },\n"
  "{7,  5, \"!!\" },\n"
  "};\n",
format("test demo[] = {{56, 23, \"hello world i am a very long line that 
really, in any just world, ought be split over multiple lines\"},{-1, 93463, 
\"world\"},{7, 5, \"!!\"},};", Style));
```

This should be done with ColumnLimit 0, 20, 100.

With `verifyFormat` you verify that the formatting is stable, but especially 
with no column limit there is often no stable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101868

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

[clang] 819e0d1 - [CGAtomic] Lift strong requirement for remaining compare_exchange combinations

[Bruno Cardoso Lopes via cfe-commits]

Author: Bruno Cardoso Lopes
Date: 2021-05-06T21:05:20-07:00
New Revision: 819e0d105e84c6081cfcfa0e38fd257b6124553a

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

LOG: [CGAtomic] Lift strong requirement for remaining compare_exchange 
combinations

Follow up on 431e3138a and complete the other possible combinations.

Besides enforcing the new behavior, it also mitigates TSAN false positives when
combining orders that used to be stronger.

Added: 


Modified: 
clang/lib/CodeGen/CGAtomic.cpp
clang/test/CodeGen/atomic-ops.c
clang/test/CodeGenOpenCL/atomic-ops.cl
llvm/lib/AsmParser/LLParser.cpp
llvm/lib/IR/Instructions.cpp
llvm/lib/IR/Verifier.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGAtomic.cpp b/clang/lib/CodeGen/CGAtomic.cpp
index ef016cf24f134..cc85375f08ddf 100644
--- a/clang/lib/CodeGen/CGAtomic.cpp
+++ b/clang/lib/CodeGen/CGAtomic.cpp
@@ -451,47 +451,38 @@ static void emitAtomicCmpXchgFailureSet(CodeGenFunction 
, AtomicExpr *E,
   }
 
   // Create all the relevant BB's
-  llvm::BasicBlock *MonotonicBB = nullptr, *AcquireBB = nullptr,
-   *SeqCstBB = nullptr;
-  MonotonicBB = CGF.createBasicBlock("monotonic_fail", CGF.CurFn);
-  if (SuccessOrder != llvm::AtomicOrdering::Monotonic)
-AcquireBB = CGF.createBasicBlock("acquire_fail", CGF.CurFn);
-  if (SuccessOrder == llvm::AtomicOrdering::SequentiallyConsistent)
-SeqCstBB = CGF.createBasicBlock("seqcst_fail", CGF.CurFn);
-
-  llvm::BasicBlock *ContBB = CGF.createBasicBlock("atomic.continue", 
CGF.CurFn);
-
-  llvm::SwitchInst *SI = CGF.Builder.CreateSwitch(FailureOrderVal, 
MonotonicBB);
-
-  // Emit all the 
diff erent atomics
+  auto *MonotonicBB = CGF.createBasicBlock("monotonic_fail", CGF.CurFn);
+  auto *AcquireBB = CGF.createBasicBlock("acquire_fail", CGF.CurFn);
+  auto *SeqCstBB = CGF.createBasicBlock("seqcst_fail", CGF.CurFn);
+  auto *ContBB = CGF.createBasicBlock("atomic.continue", CGF.CurFn);
 
   // MonotonicBB is arbitrarily chosen as the default case; in practice, this
   // doesn't matter unless someone is crazy enough to use something that
   // doesn't fold to a constant for the ordering.
+  llvm::SwitchInst *SI = CGF.Builder.CreateSwitch(FailureOrderVal, 
MonotonicBB);
+  // Implemented as acquire, since it's the closest in LLVM.
+  SI->addCase(CGF.Builder.getInt32((int)llvm::AtomicOrderingCABI::consume),
+  AcquireBB);
+  SI->addCase(CGF.Builder.getInt32((int)llvm::AtomicOrderingCABI::acquire),
+  AcquireBB);
+  SI->addCase(CGF.Builder.getInt32((int)llvm::AtomicOrderingCABI::seq_cst),
+  SeqCstBB);
+
+  // Emit all the 
diff erent atomics
   CGF.Builder.SetInsertPoint(MonotonicBB);
   emitAtomicCmpXchg(CGF, E, IsWeak, Dest, Ptr, Val1, Val2,
 Size, SuccessOrder, llvm::AtomicOrdering::Monotonic, 
Scope);
   CGF.Builder.CreateBr(ContBB);
 
-  if (AcquireBB) {
-CGF.Builder.SetInsertPoint(AcquireBB);
-emitAtomicCmpXchg(CGF, E, IsWeak, Dest, Ptr, Val1, Val2,
-  Size, SuccessOrder, llvm::AtomicOrdering::Acquire, 
Scope);
-CGF.Builder.CreateBr(ContBB);
-if (SuccessOrder != llvm::AtomicOrdering::Release)
-  SI->addCase(CGF.Builder.getInt32((int)llvm::AtomicOrderingCABI::consume),
-  AcquireBB);
-SI->addCase(CGF.Builder.getInt32((int)llvm::AtomicOrderingCABI::acquire),
-AcquireBB);
-  }
-  if (SeqCstBB) {
-CGF.Builder.SetInsertPoint(SeqCstBB);
-emitAtomicCmpXchg(CGF, E, IsWeak, Dest, Ptr, Val1, Val2, Size, 
SuccessOrder,
-  llvm::AtomicOrdering::SequentiallyConsistent, Scope);
-CGF.Builder.CreateBr(ContBB);
-SI->addCase(CGF.Builder.getInt32((int)llvm::AtomicOrderingCABI::seq_cst),
-SeqCstBB);
-  }
+  CGF.Builder.SetInsertPoint(AcquireBB);
+  emitAtomicCmpXchg(CGF, E, IsWeak, Dest, Ptr, Val1, Val2, Size, SuccessOrder,
+llvm::AtomicOrdering::Acquire, Scope);
+  CGF.Builder.CreateBr(ContBB);
+
+  CGF.Builder.SetInsertPoint(SeqCstBB);
+  emitAtomicCmpXchg(CGF, E, IsWeak, Dest, Ptr, Val1, Val2, Size, SuccessOrder,
+llvm::AtomicOrdering::SequentiallyConsistent, Scope);
+  CGF.Builder.CreateBr(ContBB);
 
   CGF.Builder.SetInsertPoint(ContBB);
 }

diff  --git a/clang/test/CodeGen/atomic-ops.c b/clang/test/CodeGen/atomic-ops.c
index 269406fc3c50f..02edec19bca93 100644
--- a/clang/test/CodeGen/atomic-ops.c
+++ b/clang/test/CodeGen/atomic-ops.c
@@ -490,29 +490,36 @@ void generalFailureOrder(_Atomic(int) *ptr, int *ptr2, 
int success, int fail) {
 
   // CHECK: [[MONOTONIC]]
   // CHECK: switch {{.*}}, label %[[MONOTONIC_MONOTONIC:[0-9a-zA-Z._]+]] [
+  // CHECK-NEXT: i32 1, label %[[MONOTONIC_ACQUIRE:[0-9a-zA-Z._]+]]
+  // CHECK-NEXT: i32 2, label 

[PATCH] D101960: [openmp] Drop requirement on library path environment variables

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added inline comments.



Comment at: openmp/libomptarget/src/rtl.cpp:76
 
+  std::string full_plugin_name;
+  void *handle = dlopen("libomptarget.so", RTLD_NOW);

JonChesterfield wrote:
> JonChesterfield wrote:
> > This logic is cut from D73657 without addressing any of the review 
> > comments. Idea is to look for the offloading plugins next to libomptarget, 
> > instead of in dlopen's default search path. Will address the previous 
> > comments when splitting out to a separate patch.
> There's a D87413 that I didn't know about before seeing a comment on D73657 
> just now. That uses RTLD_DI_LINKMAP with dlinfo instead. I'm leaning towards 
> dladdr because it seems to exist on more platforms but haven't looked into 
> the options closely yet.
This part is factored out as D102043


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

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

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

[Pushpinder Singh via Phabricator via cfe-commits]

pdhaliwal added a comment.

Greg was also interested in having pci ids table in amdgpu-arch. And, keeping 
this table inside the target/amdgpu directory sounds like a good idea. Overall, 
I agree with not having dependency on hsa as it has caused many issues.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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

[PATCH] D101960: [openmp] Drop requirement on library path environment variables

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield updated this revision to Diff 343557.
JonChesterfield added a comment.

- rework logic for finding libomptarget.so


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.h
  openmp/libomptarget/src/rtl.cpp
  openmp/libomptarget/test/lit.cfg

Index: openmp/libomptarget/test/lit.cfg
===
--- openmp/libomptarget/test/lit.cfg
+++ openmp/libomptarget/test/lit.cfg
@@ -70,14 +70,10 @@
 config.test_flags += " -Wl,-rpath," + config.library_dir
 config.test_flags += " -Wl,-rpath," + config.omp_host_rtl_directory
 else: # Unices
-append_dynamic_library_path('LD_LIBRARY_PATH', config.library_dir, ":")
-append_dynamic_library_path('LD_LIBRARY_PATH', \
-config.omp_host_rtl_directory, ":")
+config.test_flags += " -Wl,-rpath," + config.library_dir
+config.test_flags += " -Wl,-rpath," + config.omp_host_rtl_directory
 if config.cuda_libdir:
-append_dynamic_library_path('LD_LIBRARY_PATH', config.cuda_libdir, ":")
-append_dynamic_library_path('LIBRARY_PATH', config.library_dir, ":")
-append_dynamic_library_path('LIBRARY_PATH', \
-config.omp_host_rtl_directory, ":")
+config.test_flags += " -Wl,-rpath," + config.cuda_libdir
 
 # substitutions
 # - for targets that exist in the system create the actual command.
@@ -182,7 +178,8 @@
 config.substitutions.append(("%clangxx", config.test_cxx_compiler))
 config.substitutions.append(("%clang", config.test_c_compiler))
 config.substitutions.append(("%openmp_flags", config.test_openmp_flags))
-if config.cuda_path:
+
+if config.cuda_path and config.cuda_path != 'CUDA_TOOLKIT_ROOT_DIR-NOTFOUND':
   config.substitutions.append(("%cuda_flags", "--cuda-path=" + config.cuda_path))
 else:
   config.substitutions.append(("%cuda_flags", ""))
Index: openmp/libomptarget/src/rtl.cpp
===
--- openmp/libomptarget/src/rtl.cpp
+++ openmp/libomptarget/src/rtl.cpp
@@ -65,6 +65,30 @@
 #endif
 }
 
+namespace {
+std::string findLibomptargetDirectory() {
+  Dl_info dl_info;
+  // look up a symbol which is known to be from libomptarget
+  if (dladdr((void *)&__tgt_register_lib, _info) != 0) {
+std::string libomptargetPath = std::string(dl_info.dli_fname);
+size_t slash = libomptargetPath.find_last_of('/');
+if (slash != std::string::npos) {
+  return libomptargetPath.substr(0, slash + 1); // keep the /
+}
+  }
+  return "";
+}
+
+void *verbose_dlopen(const char *Name) {
+  DP("Loading library '%s'...\n", Name);
+  void *dynlib_handle = dlopen(Name, RTLD_NOW);
+  if (!dynlib_handle) {
+DP("Unable to load library '%s': %s!\n", Name, dlerror());
+  }
+  return dynlib_handle;
+}
+} // namespace
+
 void RTLsTy::LoadRTLs() {
   // Parse environment variable OMP_TARGET_OFFLOAD (if set)
   PM->TargetOffloadPolicy =
@@ -72,19 +96,22 @@
   if (PM->TargetOffloadPolicy == tgt_disabled) {
 return;
   }
-
   DP("Loading RTLs...\n");
+  std::string libomptargetPath = findLibomptargetDirectory();
 
   // Attempt to open all the plugins and, if they exist, check if the interface
   // is correct and if they are supporting any devices.
   for (auto *Name : RTLNames) {
-DP("Loading library '%s'...\n", Name);
-void *dynlib_handle = dlopen(Name, RTLD_NOW);
+std::string adjacentPluginName = libomptargetPath + std::string(Name);
 
+void *dynlib_handle = verbose_dlopen(adjacentPluginName.c_str());
 if (!dynlib_handle) {
-  // Library does not exist or cannot be found.
-  DP("Unable to load library '%s': %s!\n", Name, dlerror());
-  continue;
+  // Try again without the libomptarget library path prefix
+  dynlib_handle = verbose_dlopen(Name);
+  if (!dynlib_handle) {
+// Library does not exist or cannot be found.
+continue;
+  }
 }
 
 DP("Successfully loaded library '%s'!\n", Name);
Index: clang/lib/Driver/ToolChains/CommonArgs.h
===
--- clang/lib/Driver/ToolChains/CommonArgs.h
+++ clang/lib/Driver/ToolChains/CommonArgs.h
@@ -73,6 +73,10 @@
   const llvm::opt::ArgList ,
   llvm::opt::ArgStringList );
 
+void addOpenMPRuntimeSpecificRPath(const ToolChain ,
+   const llvm::opt::ArgList ,
+   llvm::opt::ArgStringList );
+
 void addArchSpecificRPath(const ToolChain , const llvm::opt::ArgList ,
   llvm::opt::ArgStringList );
 /// Returns true, if an OpenMP runtime has been added.
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ 

[PATCH] D101976: [OpenMP] Unified entry point for SPMD & generic kernels in the device RTL

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

In D101976#2742919 , @jdoerfert wrote:

> So what do you wnat me to change for this patch now?

Equivalent change to amdgpu target_impl to the nvptx target_impl, which looks 
like syncthreads should call a new barrier.

Iiuc this has run successfully even without that change so hopefully that's 
sufficient that we won't regress on amdgpu. I'd like to get miniqmc running 
locally to verify as well, but we may not be able to wait for that.




Comment at: openmp/libomptarget/deviceRTLs/common/src/omptarget.cu:195
+
+EXTERN __attribute__((weak))
+int32_t __kmpc_target_init(ident_t *Ident, bool IsSPMD,

why are these weak?



Comment at: openmp/libomptarget/deviceRTLs/nvptx/src/target_impl.cu:65-68
+  asm volatile("barrier.sync %0;"
+   :
+   : "r"(barrier)
+   : "memory");

jdoerfert wrote:
> ABataev wrote:
> > Why not `__syncthreads`? It is safer to use `__syncthreads` as it is 
> > `convergent`. Would be good to mark this code somehow as `convergent` too 
> > to avoid incorrect optimizations
> The problem is that syncthreads is basically a `bar.sync` which is a 
> `barrier.sync.aligned`, if I understood everything properly. This worked so 
> far because the "main thread" (lane 0, last warp) was alone in it's warp and 
> all other threads have been terminated. Now, we simplify the control flow 
> (and later get rid of the last warp) such that the threads of the last warp 
> and the main thread will hit different barriers. The former hit the one in 
> the state machine while the latter will be in `parallel_51`. The `.aligned` 
> version doesn't allow that. Does that make sense?
> 
> I'm not concerned about convergent though, we solved that wholesale: We mark 
> all functions that clang compiles for the GPU via openmp-target as convergent 
> (IIRC). The entire device runtime is certainly convergent.
amdgcn presumably needs the same change. Add a barrier and call it from 
_kmpc_impl_syncthreads.

I think barrier.sync defaults to all threads when the second argument is 
omitted, so we can use the corresponding kmpc call to get the num_threads 
argument for it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101976

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

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

There is a potential hazard here for parallel compilation and to a lesser 
extent testing. (I have just learned that) kfd imposes a process limit which is 
low enough that we may see hsa_init fail under multiple processes.

@jdoerfert you talked me out of embedding a map from pci.ids to architecture as 
we'd have to keep it up to date, and it can diverge from how the runtime 
libraries identify the hardware. I'm starting to think that's the lesser of two 
evils. Would probably look something like

  id = cat-somewhere-in-/sys
  switch(id) {
  default:
return nullptr;
  case 0x67C0:
  case 0x67C1:
  case 0x67C2:
return "gfx803";
  ... // ~ 100 lines on this theme, picks up new entries when new hardware is 
released
  };




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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

Re: [clang] ed87f51 - [PowerPC] Provide some P8-specific altivec overloads for P7

[Nemanja Ivanovic via cfe-commits]

Sorry about the noise this caused.
I somehow managed to look at the wrong log file after running the lit tests
prior to committing this. I have since fixed and re-committed this.

On Thu, May 6, 2021 at 10:01 AM Nico Weber  wrote:

> Reverted in 3761b9a2345aff197707d23a68d4a178489f60e4 for now.
>
> On Thu, May 6, 2021 at 9:58 AM Nico Weber  wrote:
>
>> Looks like this breaks tests: http://45.33.8.238/linux/45985/step_7.txt
>> , https://lab.llvm.org/buildbot/#/builders/139/builds/3818
>>
>> (Is there a phab link for this?)
>>
>> On Thu, May 6, 2021 at 9:37 AM Nemanja Ivanovic via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>>
>>> Author: Nemanja Ivanovic
>>> Date: 2021-05-06T08:37:36-05:00
>>> New Revision: ed87f512bb9eb5c1d44e9a1182ffeaf23d6c5ae8
>>>
>>> URL:
>>> https://github.com/llvm/llvm-project/commit/ed87f512bb9eb5c1d44e9a1182ffeaf23d6c5ae8
>>> DIFF:
>>> https://github.com/llvm/llvm-project/commit/ed87f512bb9eb5c1d44e9a1182ffeaf23d6c5ae8.diff
>>>
>>> LOG: [PowerPC] Provide some P8-specific altivec overloads for P7
>>>
>>> This adds additional support for XL compatibility. There are a number
>>> of functions in altivec.h that produce a single instruction (or a
>>> very short sequence) for Power8 but can be done on Power7 without
>>> scalarization. XL provides these implementations.
>>> This patch adds the following overloads for doubleword vectors:
>>> vec_add
>>> vec_cmpeq
>>> vec_cmpgt
>>> vec_cmpge
>>> vec_cmplt
>>> vec_cmple
>>> vec_sl
>>> vec_sr
>>> vec_sra
>>>
>>> Added:
>>>
>>>
>>> Modified:
>>> clang/lib/Headers/altivec.h
>>> clang/test/CodeGen/builtins-ppc-vsx.c
>>>
>>> Removed:
>>>
>>>
>>>
>>>
>>> 
>>> diff  --git a/clang/lib/Headers/altivec.h b/clang/lib/Headers/altivec.h
>>> index cb4f35caf4d4b..0441c57e3da28 100644
>>> --- a/clang/lib/Headers/altivec.h
>>> +++ b/clang/lib/Headers/altivec.h
>>> @@ -309,6 +309,26 @@ static __inline__ vector unsigned char
>>> __attribute__((__always_inline__))
>>>  vec_add_u128(vector unsigned char __a, vector unsigned char __b) {
>>>return __builtin_altivec_vadduqm(__a, __b);
>>>  }
>>> +#elif defined(__VSX__)
>>> +static __inline__ vector signed long long __ATTRS_o_ai
>>> +vec_add(vector signed long long __a, vector signed long long __b) {
>>> +  vector unsigned int __res =
>>> +  (vector unsigned int)__a + (vector unsigned int)__b;
>>> +  vector unsigned int __carry = __builtin_altivec_vaddcuw(
>>> +  (vector unsigned int)__a, (vector unsigned int)__b);
>>> +#ifdef __LITTLE_ENDIAN__
>>> +  __carry = __builtin_shufflevector(__carry, __carry, 3, 0, 1, 2);
>>> +#else
>>> +  __carry = __builtin_shufflevector(__carry, __carry, 1, 2, 3, 0);
>>> +#endif
>>> +  return (vector signed long long)(__res + __carry);
>>> +}
>>> +
>>> +static __inline__ vector unsigned long long __ATTRS_o_ai
>>> +vec_add(vector unsigned long long __a, vector unsigned long long __b) {
>>> +  return (vector unsigned long long)vec_add((vector signed long
>>> long)__a,
>>> +(vector signed long
>>> long)__b);
>>> +}
>>>  #endif // defined(__POWER8_VECTOR__) && defined(__powerpc64__)
>>>
>>>  static __inline__ vector float __ATTRS_o_ai vec_add(vector float __a,
>>> @@ -1730,7 +1750,31 @@ vec_cmpeq(vector bool long long __a, vector bool
>>> long long __b) {
>>>return (vector bool long long)__builtin_altivec_vcmpequd(
>>>(vector long long)__a, (vector long long)__b);
>>>  }
>>> +#else
>>> +static __inline__ vector bool long long __ATTRS_o_ai
>>> +vec_cmpeq(vector signed long long __a, vector signed long long __b) {
>>> +  vector bool int __wordcmp =
>>> +  vec_cmpeq((vector signed int)__a, (vector signed int)__b);
>>> +#ifdef __LITTLE_ENDIAN__
>>> +  __wordcmp &= __builtin_shufflevector(__wordcmp, __wordcmp, 3, 0, 1,
>>> 2);
>>> +  return (vector bool long long)__builtin_shufflevector(__wordcmp,
>>> __wordcmp, 1,
>>> +1, 3, 3);
>>> +#else
>>> +  __wordcmp &= __builtin_shufflevector(__wordcmp, __wordcmp, 1, 2, 3,
>>> 0);
>>> +  return (vector bool long long)__builtin_shufflevector(__wordcmp,
>>> __wordcmp, 0,
>>> +0, 2, 2);
>>> +#endif
>>> +}
>>>
>>> +static __inline__ vector bool long long __ATTRS_o_ai
>>> +vec_cmpeq(vector unsigned long long __a, vector unsigned long long __b)
>>> {
>>> +  return vec_cmpeq((vector signed long long)__a, (vector signed long
>>> long)__b);
>>> +}
>>> +
>>> +static __inline__ vector bool long long __ATTRS_o_ai
>>> +vec_cmpeq(vector bool long long __a, vector bool long long __b) {
>>> +  return vec_cmpeq((vector signed long long)__a, (vector signed long
>>> long)__b);
>>> +}
>>>  #endif
>>>
>>>  static __inline__ vector bool int __ATTRS_o_ai vec_cmpeq(vector float
>>> __a,
>>> @@ -2018,6 +2062,24 @@ vec_cmpne(vector unsigned long long __a, vector
>>> unsigned long long __b) {
>>>

[PATCH] D101601: [SelectionDAG] Make fast and linearize visible by clang -pre-RA-sched

[TaoPan via Phabricator via cfe-commits]

TaoPan added reviewers: RKSimon, craig.topper.
TaoPan added a comment.

Could you please have a review?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101601

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

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

[Dan Gohman via Phabricator via cfe-commits]

sunfish added inline comments.



Comment at: llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h:39
+  // pointers are lowered to global.get / global.set or local.get / local.set,
+  // as appropriate.
+  WASM_ADDRESS_SPACE_MANAGED = 1

tlively wrote:
> sunfish wrote:
> > tlively wrote:
> > > sunfish wrote:
> > > > Sorry to throw more paint at the bikeshed here, but as someone who's 
> > > > only following along at a high-level here, I found it confusing whether 
> > > > this is talking about the wasm globals themselves, or the objects 
> > > > referred to by reference values in the wasm globals. I think the 
> > > > feature here is talking about the wasm globals themselves, but 
> > > > "managed" initially made me think it might be talking about the objects 
> > > > they reference, which in a browser context especially are "managed" in 
> > > > every sense of the word.
> > > Fair point. What does everyone think about `INDEXED`, because it is used 
> > > to represent objects given static indexes (in the WebAssembly sense) in 
> > > the final binary.
> > Do I understand correctly that global variables and local variables are 
> > being assigned addresses within the same conceptual address space here?
> > 
> > How about `WASM_VARIABLES` or `WASM_VARS`? The wasm spec terms for these 
> > are global variables and local variables.
> > 
> > 
> Sure, that works for me. We may want to rename it in the future if we end up 
> using the same address space for tables and memories, but we can cross that 
> bridge when we get there.
Tables and memories have their own index spaces in wasm, so it seems like 
they'd want their own address spaces here, perhaps 2 and 3, respectively? I 
also agree that we can figure this out later.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

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

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

[Thomas Lively via Phabricator via cfe-commits]

tlively added inline comments.



Comment at: llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h:39
+  // pointers are lowered to global.get / global.set or local.get / local.set,
+  // as appropriate.
+  WASM_ADDRESS_SPACE_MANAGED = 1

sunfish wrote:
> tlively wrote:
> > sunfish wrote:
> > > Sorry to throw more paint at the bikeshed here, but as someone who's only 
> > > following along at a high-level here, I found it confusing whether this 
> > > is talking about the wasm globals themselves, or the objects referred to 
> > > by reference values in the wasm globals. I think the feature here is 
> > > talking about the wasm globals themselves, but "managed" initially made 
> > > me think it might be talking about the objects they reference, which in a 
> > > browser context especially are "managed" in every sense of the word.
> > Fair point. What does everyone think about `INDEXED`, because it is used to 
> > represent objects given static indexes (in the WebAssembly sense) in the 
> > final binary.
> Do I understand correctly that global variables and local variables are being 
> assigned addresses within the same conceptual address space here?
> 
> How about `WASM_VARIABLES` or `WASM_VARS`? The wasm spec terms for these are 
> global variables and local variables.
> 
> 
Sure, that works for me. We may want to rename it in the future if we end up 
using the same address space for tables and memories, but we can cross that 
bridge when we get there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

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

[PATCH] D101139: Create install targets for scan-build-py.

[Yu Shan via Phabricator via cfe-commits]

aabbaabb updated this revision to Diff 343541.
aabbaabb marked 3 inline comments as done.
aabbaabb added a comment.

Renamed lib to libexec and add custom rules to copy files to build output.


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

https://reviews.llvm.org/D101139

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/tools/CMakeLists.txt
  clang/tools/scan-build-py/CMakeLists.txt
  clang/tools/scan-build-py/bin/analyze-build
  clang/tools/scan-build-py/bin/analyze-c++
  clang/tools/scan-build-py/bin/analyze-cc
  clang/tools/scan-build-py/bin/intercept-build
  clang/tools/scan-build-py/bin/intercept-c++
  clang/tools/scan-build-py/bin/intercept-cc
  clang/tools/scan-build-py/bin/scan-build
  clang/tools/scan-build-py/libear/__init__.py
  clang/tools/scan-build-py/libear/config.h.in
  clang/tools/scan-build-py/libear/ear.c
  clang/tools/scan-build-py/libexec/libear/__init__.py
  clang/tools/scan-build-py/libexec/libear/config.h.in
  clang/tools/scan-build-py/libexec/libear/ear.c
  clang/tools/scan-build-py/libexec/libscanbuild/__init__.py
  clang/tools/scan-build-py/libexec/libscanbuild/analyze.py
  clang/tools/scan-build-py/libexec/libscanbuild/arguments.py
  clang/tools/scan-build-py/libexec/libscanbuild/clang.py
  clang/tools/scan-build-py/libexec/libscanbuild/compilation.py
  clang/tools/scan-build-py/libexec/libscanbuild/intercept.py
  clang/tools/scan-build-py/libexec/libscanbuild/report.py
  clang/tools/scan-build-py/libexec/libscanbuild/resources/scanview.css
  clang/tools/scan-build-py/libexec/libscanbuild/resources/selectable.js
  clang/tools/scan-build-py/libexec/libscanbuild/resources/sorttable.js
  clang/tools/scan-build-py/libexec/libscanbuild/shell.py
  clang/tools/scan-build-py/libscanbuild/__init__.py
  clang/tools/scan-build-py/libscanbuild/analyze.py
  clang/tools/scan-build-py/libscanbuild/arguments.py
  clang/tools/scan-build-py/libscanbuild/clang.py
  clang/tools/scan-build-py/libscanbuild/compilation.py
  clang/tools/scan-build-py/libscanbuild/intercept.py
  clang/tools/scan-build-py/libscanbuild/report.py
  clang/tools/scan-build-py/libscanbuild/resources/scanview.css
  clang/tools/scan-build-py/libscanbuild/resources/selectable.js
  clang/tools/scan-build-py/libscanbuild/resources/sorttable.js
  clang/tools/scan-build-py/libscanbuild/shell.py
  clang/tools/scan-build-py/tests/__init__.py
  clang/tools/scan-build-py/tests/unit/test_analyze.py

Index: clang/tools/scan-build-py/tests/unit/test_analyze.py
===
--- clang/tools/scan-build-py/tests/unit/test_analyze.py
+++ clang/tools/scan-build-py/tests/unit/test_analyze.py
@@ -18,9 +18,9 @@
 # scan-build can be easily matched up to compare results.
 def test_directory_name_comparison(self):
 with libear.TemporaryDirectory() as tmpdir, \
- sut.report_directory(tmpdir, False) as report_dir1, \
- sut.report_directory(tmpdir, False) as report_dir2, \
- sut.report_directory(tmpdir, False) as report_dir3:
+ sut.report_directory(tmpdir, False, 'html') as report_dir1, \
+ sut.report_directory(tmpdir, False, 'html') as report_dir2, \
+ sut.report_directory(tmpdir, False, 'html') as report_dir3:
 self.assertLess(report_dir1, report_dir2)
 self.assertLess(report_dir2, report_dir3)
 
Index: clang/tools/scan-build-py/tests/__init__.py
===
--- clang/tools/scan-build-py/tests/__init__.py
+++ clang/tools/scan-build-py/tests/__init__.py
@@ -3,6 +3,12 @@
 # See https://llvm.org/LICENSE.txt for license information.
 # SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 
+import os
+import sys
+
+this_dir = os.path.dirname(os.path.realpath(__file__))
+sys.path.append(os.path.join(os.path.dirname(this_dir), 'libexec'))
+
 import unittest
 
 import tests.unit
Index: clang/tools/scan-build-py/libscanbuild/resources/sorttable.js
===
--- clang/tools/scan-build-py/libscanbuild/resources/sorttable.js
+++ /dev/null
@@ -1,492 +0,0 @@
-/*
-  SortTable
-  version 2
-  7th April 2007
-  Stuart Langridge, http://www.kryogenix.org/code/browser/sorttable/
-
-  Instructions:
-  Download this file
-  Add  to your HTML
-  Add class="sortable" to any table you'd like to make sortable
-  Click on the headers to sort
-
-  Thanks to many, many people for contributions and suggestions.
-  Licenced as X11: http://www.kryogenix.org/code/browser/licence.html
-  This basically means: do what you want with it.
-*/
-
-
-var stIsIE = /*@cc_on!@*/false;
-
-sorttable = {
-  init: function() {
-// quit if this function has already been called
-if (arguments.callee.done) return;
-// flag this function so we don't do the same thing twice
-arguments.callee.done = true;
-// kill the timer
-if (_timer) clearInterval(_timer);
-
-if 

[PATCH] D101868: [clang-format] Adds a formatter for aligning arrays of structs

[Fred Grim via Phabricator via cfe-commits]

feg208 added a comment.

I have a few outstanding questions about additional testing




Comment at: clang/unittests/Format/FormatTest.cpp:16371
+   Style);
+}
+

HazardyKnusperkeks wrote:
> curdeius wrote:
> > I think we need more tests:
> > * with a comma after the last element of array
> > * with assignment and not only initialization?
> > * without `struct` keyword
> > * with short lines/long values to see how wrapping behaves
> >   * also, with multiple string literals in one struct, e.g. `"hello" 
> > "world"` (that will get splitted into multiple lines)
> > * with non-plain-array types (i.e. missing `[]`/`[3]`)
> > * interaction with other Align* options (e.g. 
> > `AlignConsecutiveAssignments`, two arrays one after another, 
> > `AlignConsecutiveDeclarations`).
> In addition to that I want to see:
> * How it behaves with a smaller column limit which would be violated if there 
> is no additional wrapping. There I also want one without `verifyFormat`.
> * With no column limit.
> * Maybe with a `const`, `inline` or something similar. (How about east 
> `const` vs. west `const`?)
I added

  - with a comma after the last element of array
  - with assignment and not only initialization?
  - without struct keyword
  - with short lines/long values to see how wrapping behaves (also multiple 
string literals) But I still should add another test I think
  - with non-plain-array types (i.e. missing []/[3])
  - interaction with other Align* options (e.g. AlignConsecutiveAssignments, 
two arrays one after another, AlignConsecutiveDeclarations). I will say that I 
did this in a brute force way. Maybe there is something else I should do here?
  - With no column limit.

I still need tests with east and west const and without verifyFormat. For the 
latter is there an example test I could look at? Idly scrolling through 
FormatTest.cpp it seems like most stuff uses verifyFormat? Or maybe I 
misunderstood the request?


















Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101868

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

[PATCH] D101868: [clang-format] Adds a formatter for aligning arrays of structs

[Fred Grim via Phabricator via cfe-commits]

feg208 added a comment.

To answer the question of why I think this is different then other alignment 
optionsIt seems to me that each alignment option emphasizes a specific 
thing, be it macros, bitfields, or (maybe closer in spirit) more simple 
declarations and assignments. I think this case is unique and not currently 
addressed by any of the existing alignment mechanisms.




Comment at: clang/include/clang/Format/Format.h:93
 
+  /// if ``true``, when using static initialization for an array of structs
+  /// aligns the fields into columns

curdeius wrote:
> Why static?
I was quoting from an internal ticket but it doesn't make sense. I removed it



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:32
+// The notion here is that we walk through the annotated line looking for
+// things like static initialization of arrays and flag them
+bool isArrayOfStructuresInit(const AnnotatedLine ) {

HazardyKnusperkeks wrote:
> Dot at the end. :)
One of these days I'll learn the English language. Then watch out!



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:37
+  const auto *CurrentToken = Line.First;
+  enum class DetectAsiFsm {
+null,

HazardyKnusperkeks wrote:
> What stands AsiFsm for?
Aligned Structure Initializer Finite State Machine but honestly this entire 
flow was misguided as the suggested tests pointed out. I switched it to 
something that fits (I think) a bit better with a wider array of possible inputs



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:1232
+  } else if (CurrentToken->is(tok::r_brace)) {
+Depth--;
+  }

HazardyKnusperkeks wrote:
> Why postfix, especially if using prefix in the `if`?
just an oversight. In hindsight it does look goofy ehh?



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:1404
+ isArrayOfStructuresInit(TheLine));
+  if (AlignArrayOfStructuresInit) {
+Penalty += AlignedArrayOfStructuresInitLineFormatter(

HazardyKnusperkeks wrote:
> I'm not sure that you should go before the no column limit. In either case 
> you should have a test case for that.
I kept the ordering but I will admit to misgivings about it. None of the tests 
fail and it seems like it needs to be ordered in this way but as a newbie 
contributor to this project I don't feel confident in that assertion. Do the 
included tests cover it? What test that isn't currently there would better 
create issues?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101868

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

[PATCH] D101868: [clang-format] Adds a formatter for aligning arrays of structs

[Fred Grim via Phabricator via cfe-commits]

feg208 updated this revision to Diff 343534.
feg208 marked 8 inline comments as done.
feg208 added a comment.

This addresses most of the review comments. There remain a few tests to add


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101868

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.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
@@ -15,6 +15,8 @@
 #include "llvm/Support/MemoryBuffer.h"
 #include "gtest/gtest.h"
 
+#include 
+
 #define DEBUG_TYPE "format-test"
 
 using clang::tooling::ReplacementTest;
@@ -16347,6 +16349,94 @@
getLLVMStyle());
 }
 
+template 
+auto createStylesImpl(
+const std::array ,
+const std::array ) {
+  std::array Styles;
+  auto StyleIter = Styles.begin();
+  for (const auto  : ACSValues) {
+for (const auto  : ACSValues) {
+  for (const auto  : Limits) {
+auto  = *(StyleIter);
+StyleValue = getLLVMStyle();
+StyleValue.AlignArrayOfStructures = true;
+StyleValue.AlignConsecutiveAssignments = OuterACS;
+StyleValue.AlignConsecutiveDeclarations = InnerACS;
+StyleValue.ColumnLimit = LimitValue;
+++StyleIter;
+  }
+}
+  }
+  return Styles;
+}
+
+auto createStyles() {
+  constexpr static auto N = 5;
+  std::array ACSValues{
+  {FormatStyle::AlignConsecutiveStyle::ACS_None,
+   FormatStyle::AlignConsecutiveStyle::ACS_Consecutive,
+   FormatStyle::AlignConsecutiveStyle::ACS_AcrossEmptyLines,
+   FormatStyle::AlignConsecutiveStyle::ACS_AcrossComments,
+   FormatStyle::AlignConsecutiveStyle::ACS_AcrossEmptyLinesAndComments}};
+  std::array LimitValues{{0, 80}};
+  return createStylesImpl(ACSValues, LimitValues);
+}
+
+TEST_F(FormatTest, CatchAlignArrayOfStructures) {
+  const static auto Styles = createStyles();
+  for (const auto  : Styles) {
+verifyFormat("struct test demo[] = {\n"
+ "{56, 23,\"hello\" },\n"
+ "{-1, 93463, \"world\" },\n"
+ "{7,  5, \"!!\"}\n"
+ "};\n",
+ Style);
+verifyFormat("struct test demo[3] = {\n"
+ "{56, 23,\"hello\" },\n"
+ "{-1, 93463, \"world\" },\n"
+ "{7,  5, \"!!\"}\n"
+ "};\n",
+ Style);
+verifyFormat("struct test demo[3] = {\n"
+ "{int{56}, 23,\"hello\" },\n"
+ "{int{-1}, 93463, \"world\" },\n"
+ "{int{7},  5, \"!!\"}\n"
+ "};\n",
+ Style);
+verifyFormat("struct test demo[] = {\n"
+ "{56, 23,\"hello\" },\n"
+ "{-1, 93463, \"world\" },\n"
+ "{7,  5, \"!!\"},\n"
+ "};\n",
+ Style);
+verifyFormat("test demo[] = {\n"
+ "{56, 23,\"hello\" },\n"
+ "{-1, 93463, \"world\" },\n"
+ "{7,  5, \"!!\"},\n"
+ "};\n",
+ Style);
+verifyFormat("demo = std::array{\n"
+ "test{56, 23,\"hello\" },\n"
+ "test{-1, 93463, \"world\" },\n"
+ "test{7,  5, \"!!\"},\n"
+ "};\n",
+ Style);
+  }
+
+  auto Style = getLLVMStyle();
+  Style.AlignArrayOfStructures = true;
+  verifyFormat(
+  "test demo[] = {\n"
+  "{56, 23,\"hello world i am a very long line that really, in any "
+  "\"\n"
+  "\"just world, ought be split over multiple lines\" },\n"
+  "{-1, 93463, \"world\"  },\n"
+  "{7,  5, \"!!\" },\n"
+  "};\n",
+  Style);
+}
+
 TEST_F(FormatTest, UnderstandsPragmas) {
   verifyFormat("#pragma omp reduction(| : var)");
   verifyFormat("#pragma omp reduction(+ : var)");
Index: clang/lib/Format/UnwrappedLineFormatter.cpp
===
--- clang/lib/Format/UnwrappedLineFormatter.cpp
+++ clang/lib/Format/UnwrappedLineFormatter.cpp
@@ -10,7 +10,11 @@
 #include "NamespaceEndCommentsFixer.h"
 #include "WhitespaceManager.h"
 #include "llvm/Support/Debug.h"
+#include 
+#include 
 #include 
+#include 
+#include 
 
 #define DEBUG_TYPE "format-formatter"
 
@@ -26,6 +30,54 @@
  NextNext && NextNext->is(tok::l_brace);
 }
 
+// The notion here is that we walk through the annotated line looking for
+// things like the 

[clang] c714d03 - [AMDGPU] Expose __builtin_amdgcn_perm for v_perm_b32

[Stanislav Mekhanoshin via cfe-commits]

Author: Stanislav Mekhanoshin
Date: 2021-05-06T16:17:33-07:00
New Revision: c714d037857f9c8e3bbe32e22ec22279121c378d

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

LOG: [AMDGPU] Expose __builtin_amdgcn_perm for v_perm_b32

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

Added: 
llvm/test/CodeGen/AMDGPU/llvm.amdgcn.perm.ll

Modified: 
clang/include/clang/Basic/BuiltinsAMDGPU.def
clang/test/CodeGenOpenCL/builtins-amdgcn-vi.cl
clang/test/SemaOpenCL/builtins-amdgcn-error-vi.cl
llvm/include/llvm/IR/IntrinsicsAMDGPU.td
llvm/lib/Target/AMDGPU/AMDGPUInstrInfo.td
llvm/lib/Target/AMDGPU/AMDGPURegisterBankInfo.cpp
llvm/lib/Target/AMDGPU/SIISelLowering.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsAMDGPU.def 
b/clang/include/clang/Basic/BuiltinsAMDGPU.def
index 9677b1aadb518..7dcbf9a096961 100644
--- a/clang/include/clang/Basic/BuiltinsAMDGPU.def
+++ b/clang/include/clang/Basic/BuiltinsAMDGPU.def
@@ -182,6 +182,7 @@ TARGET_BUILTIN(__builtin_amdgcn_s_memrealtime, "LUi", "n", 
"s-memrealtime")
 TARGET_BUILTIN(__builtin_amdgcn_mov_dpp, "iiIiIiIiIb", "nc", "dpp")
 TARGET_BUILTIN(__builtin_amdgcn_update_dpp, "iiiIiIiIiIb", "nc", "dpp")
 TARGET_BUILTIN(__builtin_amdgcn_s_dcache_wb, "v", "n", "gfx8-insts")
+TARGET_BUILTIN(__builtin_amdgcn_perm, "UiUiUiUi", "nc", "gfx8-insts")
 
 
//===--===//
 // GFX9+ only builtins.

diff  --git a/clang/test/CodeGenOpenCL/builtins-amdgcn-vi.cl 
b/clang/test/CodeGenOpenCL/builtins-amdgcn-vi.cl
index 49faf069c8c68..be594585fad6d 100644
--- a/clang/test/CodeGenOpenCL/builtins-amdgcn-vi.cl
+++ b/clang/test/CodeGenOpenCL/builtins-amdgcn-vi.cl
@@ -7,6 +7,7 @@
 #pragma OPENCL EXTENSION cl_khr_fp16 : enable
 
 typedef unsigned long ulong;
+typedef unsigned int  uint;
 
 // CHECK-LABEL: @test_div_fixup_f16
 // CHECK: call half @llvm.amdgcn.div.fixup.f16
@@ -137,3 +138,10 @@ void test_s_memtime(global ulong* out)
 {
   *out = __builtin_amdgcn_s_memtime();
 }
+
+// CHECK-LABEL: @test_perm
+// CHECK: call i32 @llvm.amdgcn.perm(i32 %a, i32 %b, i32 %s)
+void test_perm(global uint* out, uint a, uint b, uint s)
+{
+  *out = __builtin_amdgcn_perm(a, b, s);
+}

diff  --git a/clang/test/SemaOpenCL/builtins-amdgcn-error-vi.cl 
b/clang/test/SemaOpenCL/builtins-amdgcn-error-vi.cl
index 849c826c5b8cb..c23f4a452d83e 100644
--- a/clang/test/SemaOpenCL/builtins-amdgcn-error-vi.cl
+++ b/clang/test/SemaOpenCL/builtins-amdgcn-error-vi.cl
@@ -2,7 +2,8 @@
 // RUN: %clang_cc1 -triple amdgcn-- -target-cpu tahiti -verify -S -o - %s
 // RUN: %clang_cc1 -triple amdgcn-- -target-cpu hawaii -verify -S -o - %s
 
-void test_vi_s_dcache_wb()
+void test_vi_builtins()
 {
   __builtin_amdgcn_s_dcache_wb(); // expected-error 
{{'__builtin_amdgcn_s_dcache_wb' needs target feature gfx8-insts}}
+  (void)__builtin_amdgcn_perm(1, 2, 3); // expected-error 
{{'__builtin_amdgcn_perm' needs target feature gfx8-insts}}
 }

diff  --git a/llvm/include/llvm/IR/IntrinsicsAMDGPU.td 
b/llvm/include/llvm/IR/IntrinsicsAMDGPU.td
index 7b62b9de79b22..46a7aeb39c9a5 100644
--- a/llvm/include/llvm/IR/IntrinsicsAMDGPU.td
+++ b/llvm/include/llvm/IR/IntrinsicsAMDGPU.td
@@ -1716,6 +1716,12 @@ def int_amdgcn_ds_bpermute :
   Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty],
  [IntrNoMem, IntrConvergent, IntrWillReturn]>;
 
+// llvm.amdgcn.perm   
+def int_amdgcn_perm :
+  GCCBuiltin<"__builtin_amdgcn_perm">,
+  Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty, llvm_i32_ty],
+ [IntrNoMem, IntrSpeculatable, IntrWillReturn]>;
+
 
//===--===//
 // GFX10 Intrinsics
 
//===--===//

diff  --git a/llvm/lib/Target/AMDGPU/AMDGPUInstrInfo.td 
b/llvm/lib/Target/AMDGPU/AMDGPUInstrInfo.td
index c0cb1781abe34..d63bd2e9eb2e0 100644
--- a/llvm/lib/Target/AMDGPU/AMDGPUInstrInfo.td
+++ b/llvm/lib/Target/AMDGPU/AMDGPUInstrInfo.td
@@ -313,7 +313,7 @@ def AMDGPUfdot2_impl : SDNode<"AMDGPUISD::FDOT2",
SDTCisInt<4>]>,
   []>;
 
-def AMDGPUperm : SDNode<"AMDGPUISD::PERM", AMDGPUDTIntTernaryOp, []>;
+def AMDGPUperm_impl : SDNode<"AMDGPUISD::PERM", AMDGPUDTIntTernaryOp, []>;
 
 // SI+ export
 def AMDGPUExportOp : SDTypeProfile<0, 8, [
@@ -463,3 +463,7 @@ def AMDGPUfdot2 : PatFrags<(ops node:$src0, node:$src1, 
node:$src2, node:$clamp)
 def AMDGPUdiv_fmas : PatFrags<(ops node:$src0, node:$src1, node:$src2, 
node:$vcc),
   [(int_amdgcn_div_fmas node:$src0, node:$src1, node:$src2, node:$vcc),
(AMDGPUdiv_fmas_impl node:$src0, node:$src1, node:$src2, node:$vcc)]>;
+
+def AMDGPUperm : PatFrags<(ops node:$src0, node:$src1, node:$src2),
+  

[PATCH] D102030: [clang][Fuchsia] Introduce compat multilibs

[Leonard Chan via Phabricator via cfe-commits]

leonardchan updated this revision to Diff 343526.
leonardchan marked an inline comment as done.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102030

Files:
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-unknown-fuchsia/compat/libc++.so
  clang/test/Driver/fuchsia.cpp


Index: clang/test/Driver/fuchsia.cpp
===
--- clang/test/Driver/fuchsia.cpp
+++ clang/test/Driver/fuchsia.cpp
@@ -144,6 +144,23 @@
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
 // RUN: -fuse-ld=lld 2>&1\
 // RUN: | FileCheck %s 
-check-prefixes=CHECK-MULTILIB-X86,CHECK-MULTILIB-RELATIVE-VTABLES-HWASAN-NOEXCEPT-X86
+
+// Test compat multilibs.
+// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -fc++-abi=itanium \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld 2>&1\
+// RUN: | FileCheck %s 
-check-prefixes=CHECK-MULTILIB-X86,CHECK-MULTILIB-COMPAT-X86
+// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -fc++-abi=itanium 
-fc++-abi=fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld 2>&1\
+// RUN: | FileCheck %s -check-prefixes=CHECK-MULTILIB-X86
+// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -fc++-abi=fuchsia 
-fc++-abi=itanium \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld 2>&1\
+// RUN: | FileCheck %s 
-check-prefixes=CHECK-MULTILIB-X86,CHECK-MULTILIB-COMPAT-X86
 // CHECK-MULTILIB-X86: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
 // CHECK-MULTILIB-ASAN-X86: 
"-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-fuchsia{{/|}}asan"
 // CHECK-MULTILIB-NOEXCEPT-X86: 
"-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-fuchsia{{/|}}noexcept"
@@ -156,4 +173,5 @@
 // CHECK-MULTILIB-HWASAN-NOEXCEPT-X86: 
"-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-fuchsia{{/|}}hwasan+noexcept"
 // CHECK-MULTILIB-RELATIVE-VTABLES-HWASAN-X86: 
"-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-fuchsia{{/|}}relative-vtables+hwasan"
 // CHECK-MULTILIB-RELATIVE-VTABLES-HWASAN-NOEXCEPT-X86: 
"-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-fuchsia{{/|}}relative-vtables+hwasan+noexcept"
+// CHECK-MULTILIB-COMPAT-X86: 
"-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-fuchsia{{/|}}compat"
 // CHECK-MULTILIB-X86: 
"-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-fuchsia"
Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -242,6 +242,8 @@
   .flag("+fsanitize=hwaddress")
   .flag("-fexceptions")
   .flag("+fno-exceptions"));
+  // Use the default Itanium C++ ABI.
+  Multilibs.push_back(Multilib("compat", {}, {}, 
12).flag("+fc++-abi=itanium"));
 
   Multilibs.FilterOut([&](const Multilib ) {
 std::vector RD = FilePaths(M);
@@ -263,6 +265,8 @@
options::OPT_fno_experimental_relative_cxx_abi_vtables,
/*default=*/false),
   "fexperimental-relative-c++-abi-vtables", Flags);
+  addMultilibFlag(Args.getLastArgValue(options::OPT_fcxx_abi_EQ) == "itanium",
+  "fc++-abi=itanium", Flags);
 
   Multilibs.setFilePathsCallback(FilePaths);
 


Index: clang/test/Driver/fuchsia.cpp
===
--- clang/test/Driver/fuchsia.cpp
+++ clang/test/Driver/fuchsia.cpp
@@ -144,6 +144,23 @@
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
 // RUN: -fuse-ld=lld 2>&1\
 // RUN: | FileCheck %s -check-prefixes=CHECK-MULTILIB-X86,CHECK-MULTILIB-RELATIVE-VTABLES-HWASAN-NOEXCEPT-X86
+
+// Test compat multilibs.
+// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -fc++-abi=itanium \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld 2>&1\
+// RUN: | FileCheck %s -check-prefixes=CHECK-MULTILIB-X86,CHECK-MULTILIB-COMPAT-X86
+// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -fc++-abi=itanium -fc++-abi=fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld 2>&1\
+// RUN: | FileCheck %s -check-prefixes=CHECK-MULTILIB-X86
+// RUN: %clangxx %s -### 

[PATCH] D102030: [clang][Fuchsia] Introduce compat multilibs

[Leonard Chan via Phabricator via cfe-commits]

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



Comment at: clang/lib/Driver/ToolChains/Fuchsia.cpp:249-250
+  .flag("+fc++-abi=itanium")
+  .flag("-fexceptions")
+  .flag("+fno-exceptions"));
 

phosek wrote:
> We should probably build the `compat` multilib with exceptions to maximize 
> compatibility.
Can do. So just have the `compat` multilib only then?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102030

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

[PATCH] D102030: [clang][Fuchsia] Introduce compat multilibs

[Petr Hosek via Phabricator via cfe-commits]

phosek added inline comments.



Comment at: clang/lib/Driver/ToolChains/Fuchsia.cpp:249-250
+  .flag("+fc++-abi=itanium")
+  .flag("-fexceptions")
+  .flag("+fno-exceptions"));
 

We should probably build the `compat` multilib with exceptions to maximize 
compatibility.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102030

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

[PATCH] D102030: [clang][Fuchsia] Introduce compat multilibs

[Leonard Chan via Phabricator via cfe-commits]

leonardchan created this revision.
leonardchan added reviewers: phosek, mcgrathr.
leonardchan added a project: clang.
leonardchan requested review of this revision.

These are GCC-compatible multilibs that use the generic Itanium C++ ABI instead 
of the Fuchsia C++ ABI.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102030

Files:
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-unknown-fuchsia/compat+noexcept/libc++.so
  
clang/test/Driver/Inputs/basic_fuchsia_tree/lib/x86_64-unknown-fuchsia/compat/libc++.so
  clang/test/Driver/fuchsia.cpp


Index: clang/test/Driver/fuchsia.cpp
===
--- clang/test/Driver/fuchsia.cpp
+++ clang/test/Driver/fuchsia.cpp
@@ -144,6 +144,28 @@
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
 // RUN: -fuse-ld=lld 2>&1\
 // RUN: | FileCheck %s 
-check-prefixes=CHECK-MULTILIB-X86,CHECK-MULTILIB-RELATIVE-VTABLES-HWASAN-NOEXCEPT-X86
+
+// Test compat multilibs.
+// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -fc++-abi=itanium 
-fno-exceptions \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld 2>&1\
+// RUN: | FileCheck %s 
-check-prefixes=CHECK-MULTILIB-X86,CHECK-MULTILIB-COMPAT-NOEXCEPT-X86
+// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -fc++-abi=itanium \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld 2>&1\
+// RUN: | FileCheck %s 
-check-prefixes=CHECK-MULTILIB-X86,CHECK-MULTILIB-COMPAT-X86
+// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -fc++-abi=itanium 
-fc++-abi=fuchsia \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld 2>&1\
+// RUN: | FileCheck %s -check-prefixes=CHECK-MULTILIB-X86
+// RUN: %clangxx %s -### --target=x86_64-unknown-fuchsia -fc++-abi=fuchsia 
-fc++-abi=itanium \
+// RUN: -ccc-install-dir %S/Inputs/basic_fuchsia_tree/bin \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN: -fuse-ld=lld 2>&1\
+// RUN: | FileCheck %s 
-check-prefixes=CHECK-MULTILIB-X86,CHECK-MULTILIB-COMPAT-X86
 // CHECK-MULTILIB-X86: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
 // CHECK-MULTILIB-ASAN-X86: 
"-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-fuchsia{{/|}}asan"
 // CHECK-MULTILIB-NOEXCEPT-X86: 
"-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-fuchsia{{/|}}noexcept"
@@ -156,4 +178,6 @@
 // CHECK-MULTILIB-HWASAN-NOEXCEPT-X86: 
"-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-fuchsia{{/|}}hwasan+noexcept"
 // CHECK-MULTILIB-RELATIVE-VTABLES-HWASAN-X86: 
"-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-fuchsia{{/|}}relative-vtables+hwasan"
 // CHECK-MULTILIB-RELATIVE-VTABLES-HWASAN-NOEXCEPT-X86: 
"-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-fuchsia{{/|}}relative-vtables+hwasan+noexcept"
+// CHECK-MULTILIB-COMPAT-X86: 
"-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-fuchsia{{/|}}compat"
+// CHECK-MULTILIB-COMPAT-NOEXCEPT-X86: 
"-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-fuchsia{{/|}}compat+noexcept"
 // CHECK-MULTILIB-X86: 
"-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-fuchsia"
Index: clang/lib/Driver/ToolChains/Fuchsia.cpp
===
--- clang/lib/Driver/ToolChains/Fuchsia.cpp
+++ clang/lib/Driver/ToolChains/Fuchsia.cpp
@@ -242,6 +242,12 @@
   .flag("+fsanitize=hwaddress")
   .flag("-fexceptions")
   .flag("+fno-exceptions"));
+  // Use the default Itanium C++ ABI.
+  Multilibs.push_back(Multilib("compat", {}, {}, 
12).flag("+fc++-abi=itanium"));
+  Multilibs.push_back(Multilib("compat+noexcept", {}, {}, 13)
+  .flag("+fc++-abi=itanium")
+  .flag("-fexceptions")
+  .flag("+fno-exceptions"));
 
   Multilibs.FilterOut([&](const Multilib ) {
 std::vector RD = FilePaths(M);
@@ -263,6 +269,8 @@
options::OPT_fno_experimental_relative_cxx_abi_vtables,
/*default=*/false),
   "fexperimental-relative-c++-abi-vtables", Flags);
+  addMultilibFlag(Args.getLastArgValue(options::OPT_fcxx_abi_EQ) == "itanium",
+  "fc++-abi=itanium", Flags);
 
   Multilibs.setFilePathsCallback(FilePaths);
 


Index: clang/test/Driver/fuchsia.cpp
===
--- clang/test/Driver/fuchsia.cpp
+++ clang/test/Driver/fuchsia.cpp
@@ -144,6 +144,28 @@
 // RUN: 

[PATCH] D101572: Make `hasTypeLoc` matcher support more node types.

[Stephen Kelly via Phabricator via cfe-commits]

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

This looks good to me. I tried running it in clang-query, which crashes with a 
matcher like

  m binaryOperator(hasEitherOperand(hasTypeLoc(loc(asString("int")

but it also crashes before your change, so it must be unrelated.

Do you have a commit account or will I commit this for you with the name/email 
in your github commit?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101572

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

[PATCH] D91466: [WIP][clang][Fuchsia] Support HWASan for Fuchsia

[Leonard Chan via Phabricator via cfe-commits]

leonardchan planned changes to this revision.
leonardchan added inline comments.



Comment at: compiler-rt/lib/hwasan/hwasan_dynamic_shadow.cpp:120
+
+void InitShadowGOT() {}
+

Add comment. Fuchsia never uses dynamic shadow, which is what this sets up in 
the Linux implementation.

From linux implemenation:
```
  // Call the ifunc resolver for __hwasan_shadow and fill in its GOT entry. This
  // needs to be done before other ifunc resolvers (which are handled by libc)
  // because a resolver might read __hwasan_shadow.
```



Comment at: compiler-rt/lib/hwasan/hwasan_fuchsia.cpp:46-51
+void InitThreads() {
+  uptr alloc_size = UINT64_C(1) << kShadowBaseAlignment;
+  uptr thread_start = reinterpret_cast(
+  MmapAlignedOrDieOnFatalError(alloc_size, alloc_size, __func__));
+  InitThreadList(thread_start, thread_start + alloc_size);
+}

Compare hwasan thread tracking implementation with asan + fuchsia 
implementation. HWASan uses different sanitizer machinery.



Comment at: compiler-rt/lib/hwasan/hwasan_fuchsia.cpp:53
+
+void InitPrctl() {}
+

This can be replaced with a zircon-equivalent check that checks if TBI is 
enabled. This function is Linux-specific.

TODO: File a bug that tracks this once the TBI stuff is addressed.



Comment at: compiler-rt/lib/hwasan/hwasan_fuchsia.cpp:60
+
+void InstallAtExitHandler() {}
+

See equivalent for other asan+lsan implementations. We use fuchsia sanitizer 
hooks instead of atexit. `__sanitizer_exit_hook` is what's used.



Comment at: compiler-rt/lib/hwasan/hwasan_fuchsia.cpp:64-74
+extern "C" void __hwasan_thread_enter() {
+  hwasanThreadList().CreateCurrentThread()->InitRandomState();
+}
+
+extern "C" void __hwasan_thread_exit() {
+  Thread *t = GetCurrentThread();
+  // Make sure that signal handler can not see a stale current thread pointer.

Don't define these. Move this logic into the hooks.

Ask why these are in the public header when we already have the thread hooks.



Comment at: compiler-rt/lib/hwasan/hwasan_fuchsia.cpp:105-111
+struct AccessInfo {
+  uptr addr;
+  uptr size;
+  bool is_store;
+  bool is_load;
+  bool recover;
+};

leonardchan wrote:
> This could probably be shared code with the Linux implementation. Move out of 
> hwasan.
This is compiler-defined and should be abstracted out. Shouldn't have duplicate 
definitions.



Comment at: compiler-rt/lib/hwasan/hwasan_fuchsia.cpp:105-130
+struct AccessInfo {
+  uptr addr;
+  uptr size;
+  bool is_store;
+  bool is_load;
+  bool recover;
+};

This could probably be shared code with the Linux implementation. Move out of 
hwasan.



Comment at: compiler-rt/lib/hwasan/hwasan_fuchsia.cpp:146-147
+   uptr *registers_frame, size_t outsize) {
+  if (!hwasan_inited)
+return;
+

Ideally, the checks on these uninitialized globals should not be called.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91466

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

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

[Dan Gohman via Phabricator via cfe-commits]

sunfish added inline comments.



Comment at: llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h:39
+  // pointers are lowered to global.get / global.set or local.get / local.set,
+  // as appropriate.
+  WASM_ADDRESS_SPACE_MANAGED = 1

tlively wrote:
> sunfish wrote:
> > Sorry to throw more paint at the bikeshed here, but as someone who's only 
> > following along at a high-level here, I found it confusing whether this is 
> > talking about the wasm globals themselves, or the objects referred to by 
> > reference values in the wasm globals. I think the feature here is talking 
> > about the wasm globals themselves, but "managed" initially made me think it 
> > might be talking about the objects they reference, which in a browser 
> > context especially are "managed" in every sense of the word.
> Fair point. What does everyone think about `INDEXED`, because it is used to 
> represent objects given static indexes (in the WebAssembly sense) in the 
> final binary.
Do I understand correctly that global variables and local variables are being 
assigned addresses within the same conceptual address space here?

How about `WASM_VARIABLES` or `WASM_VARS`? The wasm spec terms for these are 
global variables and local variables.





Comment at: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp:1279
+  if (const GlobalAddressSDNode *GA = dyn_cast(Op))
+return WebAssembly::isManagedAddressSpace(GA->getAddressSpace());
+

sbc100 wrote:
> sunfish wrote:
> > sbc100 wrote:
> > > sunfish wrote:
> > > > tlively wrote:
> > > > > tlively wrote:
> > > > > > Actually, should we enforce that these LLVM IR globals be 
> > > > > > thread_local, since the resulting Wasm globals will be 
> > > > > > thread_local? I don't know if that will affect any optimizations, 
> > > > > > but it seems like a more accurate modeling. If we do that, 
> > > > > > `CoalesceLocalsAndStripAtomics::stripThreadLocals` in 
> > > > > > WebAssemblyTargetMachine.cpp will have to be updated to not strip 
> > > > > > the thread locals corresponding to Wasm globals.
> > > > > I'd be fine handling this in a follow-up if you want to get this 
> > > > > landed.
> > > > Note that this will be true of Worker-based threads, but not of the 
> > > > expected future "wasm native threads". I wonder if this means that 
> > > > clang/llvm will (eventually) need to be aware of this difference.
> > > Don't you think is very likely that even in "wasm native threads" we 
> > > would want to opt into sharing like we do with wasm memories?   That path 
> > > would seem better for compatibility with existing worker-based threading. 
> > >  
> > > 
> > > Obviously once we do have shared wasm globals we will need to modify 
> > > llvm's assumptions, but for now I think it is a reasonable 
> > > assumption/assertion that wasm globals are TLS.
> > Yeah, I agree we'll likely want some way to opt into sharing. So the 
> > difference here is, worker-based threads won't have the option of sharing, 
> > so maybe requiring `thread_local` makes sense. But native threads could opt 
> > into sharing, so they could be `thread_local` or not.
> > 
> Yup.  And who know .. maybe by the time shared globals and native threads are 
> added, Workers might also add shared globals?  
It's possible :-). In any case, I don't think it's anything we need to do 
anything about right now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

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

[PATCH] D77598: Integral template argument suffix and cast printing

[Richard Smith - zygoloid via Phabricator via cfe-commits]

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

Thanks, this looks good to me!

Thank you for your patience :)


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

https://reviews.llvm.org/D77598

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

[PATCH] D101192: Add support for #elifdef and #elifndef

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added inline comments.



Comment at: clang/lib/Lex/PPDirectives.cpp:3254-3265
+  Token MacroNameTok;
+  ReadMacroName(MacroNameTok);
+
+  // Error reading macro name?  If so, diagnostic already issued.
+  if (MacroNameTok.is(tok::eod)) {
+// Skip code until we get to #endif.  This helps with recovery by not
+// emitting an error when the #endif is reached.

Hm, is the strict checking here appropriate? I'd expect skipping to start as 
soon as we hit the `#elifdef` directive, so the restriction on the form of the 
directive should be relaxed and we should just skip to the end of the line. 
("When in a group that is skipped (15.2), the directive syntax is relaxed to 
allow any sequence of preprocessing tokens to occur between the directive name 
and the following new-line character."). For example, given:

```
#if 1
#elif
#endif
```

... we don't diagnose, even though the `#elif` line doesn't match the usual 
form for the directive (a //constant-expression// would require at least one 
token between `elif` and //new-line//), and I'd expect `#elifdef` to behave the 
same way.

With this fixed, the handling of `#elif`, `#elifdef`, and `#elifndef` (when not 
skipping) should be identical other than which callback is invoked; can the 
implementations be combined?



Comment at: clang/lib/Lex/PPDirectives.cpp:3291
+  if (MI) // Mark it used.
+markMacroAsUsed(MI);
+

This doesn't seem right to me: the macro's existence or non-existence does not 
affect preprocessing, so the macro was not used. But I assume this and the 
references to `MD` below will also be removed once this function stops parsing 
a macro name.


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

https://reviews.llvm.org/D101192

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

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

[Petr Hosek via Phabricator via cfe-commits]

phosek updated this revision to Diff 343507.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101479

Files:
  clang/lib/Driver/ToolChains/MSVC.cpp
  clang/test/Driver/Inputs/msvc_libcxx_tree/usr/bin/.keep
  clang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/c++/v1/.keep
  
clang/test/Driver/Inputs/msvc_libcxx_tree/usr/include/x86_64-pc-windows-msvc/c++/v1/.keep
  clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/.keep
  clang/test/Driver/Inputs/msvc_libcxx_tree/usr/lib/x86_64-pc-windows-msvc/.keep
  clang/test/Driver/msvc-libcxx.cpp


Index: clang/test/Driver/msvc-libcxx.cpp
===
--- /dev/null
+++ clang/test/Driver/msvc-libcxx.cpp
@@ -0,0 +1,7 @@
+// RUN: %clangxx -### %s 2>&1 -stdlib=libc++ -fuse-ld=lld \
+// RUN:   --target=x86_64-pc-windows-msvc \
+// RUN:   -ccc-install-dir %S/Inputs/msvc_libcxx_tree/usr/bin \
+// RUN:   | FileCheck %s -check-prefix MSVC-LIBCXX
+// MSVC-LIBCXX: "-internal-isystem" 
"{{.*[/\\]}}include{{/|}}x86_64-pc-windows-msvc{{/|}}c++{{/|}}v1"
+// MSVC-LIBCXX: "-internal-isystem" 
"{{.*[/\\]}}include{{/|}}c++{{/|}}v1"
+// MSVC-LIBCXX: 
"-libpath:{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-pc-windows-msvc"
Index: clang/lib/Driver/ToolChains/MSVC.cpp
===
--- clang/lib/Driver/ToolChains/MSVC.cpp
+++ clang/lib/Driver/ToolChains/MSVC.cpp
@@ -435,6 +435,11 @@
   if (!C.getDriver().IsCLMode() && Args.hasArg(options::OPT_L))
 for (const auto  : Args.getAllArgValues(options::OPT_L))
   CmdArgs.push_back(Args.MakeArgString("-libpath:" + LibPath));
+  // Add library directories for standard library shipped with the toolchain.
+  for (const auto  : TC.getFilePaths()) {
+if (TC.getVFS().exists(LibPath))
+  CmdArgs.push_back(Args.MakeArgString("-libpath:" + LibPath));
+  }
 
   CmdArgs.push_back("-nologo");
 
@@ -1323,7 +1328,36 @@
 
 void MSVCToolChain::AddClangCXXStdlibIncludeArgs(const ArgList ,
  ArgStringList ) const 
{
-  // FIXME: There should probably be logic here to find libc++ on Windows.
+  if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
+  DriverArgs.hasArg(options::OPT_nostdincxx))
+return;
+
+  switch (GetCXXStdlibType(DriverArgs)) {
+  case ToolChain::CST_Libcxx: {
+SmallString<128> P(getDriver().Dir);
+llvm::sys::path::append(P, "..", "include");
+
+std::string Version = detectLibcxxVersion(P);
+if (Version.empty())
+  return;
+
+// First add the per-target include path if it exists.
+SmallString<128> TargetDir(P);
+llvm::sys::path::append(TargetDir, getTripleString(), "c++", Version);
+if (getVFS().exists(TargetDir))
+  addSystemInclude(DriverArgs, CC1Args, TargetDir);
+
+// Second add the generic one.
+SmallString<128> Dir(P);
+llvm::sys::path::append(Dir, "c++", Version);
+addSystemInclude(DriverArgs, CC1Args, Dir);
+break;
+  }
+
+  default:
+// TODO: Shall we report an error for other C++ standard libraries?
+break;
+  }
 }
 
 VersionTuple MSVCToolChain::computeMSVCVersion(const Driver *D,


Index: clang/test/Driver/msvc-libcxx.cpp
===
--- /dev/null
+++ clang/test/Driver/msvc-libcxx.cpp
@@ -0,0 +1,7 @@
+// RUN: %clangxx -### %s 2>&1 -stdlib=libc++ -fuse-ld=lld \
+// RUN:   --target=x86_64-pc-windows-msvc \
+// RUN:   -ccc-install-dir %S/Inputs/msvc_libcxx_tree/usr/bin \
+// RUN:   | FileCheck %s -check-prefix MSVC-LIBCXX
+// MSVC-LIBCXX: "-internal-isystem" "{{.*[/\\]}}include{{/|}}x86_64-pc-windows-msvc{{/|}}c++{{/|}}v1"
+// MSVC-LIBCXX: "-internal-isystem" "{{.*[/\\]}}include{{/|}}c++{{/|}}v1"
+// MSVC-LIBCXX: "-libpath:{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-pc-windows-msvc"
Index: clang/lib/Driver/ToolChains/MSVC.cpp
===
--- clang/lib/Driver/ToolChains/MSVC.cpp
+++ clang/lib/Driver/ToolChains/MSVC.cpp
@@ -435,6 +435,11 @@
   if (!C.getDriver().IsCLMode() && Args.hasArg(options::OPT_L))
 for (const auto  : Args.getAllArgValues(options::OPT_L))
   CmdArgs.push_back(Args.MakeArgString("-libpath:" + LibPath));
+  // Add library directories for standard library shipped with the toolchain.
+  for (const auto  : TC.getFilePaths()) {
+if (TC.getVFS().exists(LibPath))
+  CmdArgs.push_back(Args.MakeArgString("-libpath:" + LibPath));
+  }
 
   CmdArgs.push_back("-nologo");
 
@@ -1323,7 +1328,36 @@
 
 void MSVCToolChain::AddClangCXXStdlibIncludeArgs(const ArgList ,
  ArgStringList ) const {
-  // FIXME: There should probably be logic here to find libc++ on Windows.
+  if (DriverArgs.hasArg(options::OPT_nostdlibinc) ||
+  DriverArgs.hasArg(options::OPT_nostdincxx))
+return;
+
+  

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

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added inline comments.



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp:1279
+  if (const GlobalAddressSDNode *GA = dyn_cast(Op))
+return WebAssembly::isManagedAddressSpace(GA->getAddressSpace());
+

sunfish wrote:
> sbc100 wrote:
> > sunfish wrote:
> > > tlively wrote:
> > > > tlively wrote:
> > > > > Actually, should we enforce that these LLVM IR globals be 
> > > > > thread_local, since the resulting Wasm globals will be thread_local? 
> > > > > I don't know if that will affect any optimizations, but it seems like 
> > > > > a more accurate modeling. If we do that, 
> > > > > `CoalesceLocalsAndStripAtomics::stripThreadLocals` in 
> > > > > WebAssemblyTargetMachine.cpp will have to be updated to not strip the 
> > > > > thread locals corresponding to Wasm globals.
> > > > I'd be fine handling this in a follow-up if you want to get this landed.
> > > Note that this will be true of Worker-based threads, but not of the 
> > > expected future "wasm native threads". I wonder if this means that 
> > > clang/llvm will (eventually) need to be aware of this difference.
> > Don't you think is very likely that even in "wasm native threads" we would 
> > want to opt into sharing like we do with wasm memories?   That path would 
> > seem better for compatibility with existing worker-based threading.  
> > 
> > Obviously once we do have shared wasm globals we will need to modify llvm's 
> > assumptions, but for now I think it is a reasonable assumption/assertion 
> > that wasm globals are TLS.
> Yeah, I agree we'll likely want some way to opt into sharing. So the 
> difference here is, worker-based threads won't have the option of sharing, so 
> maybe requiring `thread_local` makes sense. But native threads could opt into 
> sharing, so they could be `thread_local` or not.
> 
Yup.  And who know .. maybe by the time shared globals and native threads are 
added, Workers might also add shared globals?  


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

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

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

[David Zarzycki via Phabricator via cfe-commits]

davezarzycki added a comment.

Yes, Fedora 34 (x86-64).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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

[PATCH] D101192: Add support for #elifdef and #elifndef

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Ping


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

https://reviews.llvm.org/D101192

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

[PATCH] D97687: [SEH] Fix capture of this in lambda functions

[Olivier Goffart via Phabricator via cfe-commits]

ogoffart added a comment.

Looks like changing CurCodeDecl was not a good idea.
Fixed in https://reviews.llvm.org/D102027


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97687

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

[PATCH] D102027: [SEH] Fix regression with SEH in noexpect functions

[Olivier Goffart via Phabricator via cfe-commits]

ogoffart added a comment.

As reported in https://reviews.llvm.org/D97687#2741449


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102027

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

[PATCH] D102027: [SEH] Fix regression with SEH in noexpect functions

[Olivier Goffart via Phabricator via cfe-commits]

ogoffart created this revision.
ogoffart requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Commit 5baea0560160a693b19022c5d0ba637b6b46b2d8 
 set the 
CurCodeDecl
because it was needed to pass the assert in 
CodeGenFunction::EmitLValueForLambdaField,
But this was not right to do as CodeGenFunction::FinishFunction passes it to 
EmitEndEHSpec
and cause corruption of the EHStack.

  

Revert the part of the commit that changes the CurCodeDecl, and just change the 
assert
to allow more conditions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102027

Files:
  clang/lib/CodeGen/CGException.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/test/CodeGenCXX/exceptions-seh.cpp


Index: clang/test/CodeGenCXX/exceptions-seh.cpp
===
--- clang/test/CodeGenCXX/exceptions-seh.cpp
+++ clang/test/CodeGenCXX/exceptions-seh.cpp
@@ -164,3 +164,5 @@
 // CHECK: store i32 1234, i32* @my_unique_global
 
 // CHECK: attributes #[[NOINLINE]] = { {{.*noinline.*}} }
+
+void seh_in_noexcept() noexcept { __try {} __finally {} }
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -4185,8 +4185,8 @@
 /// Given that we are currently emitting a lambda, emit an l-value for
 /// one of its members.
 LValue CodeGenFunction::EmitLValueForLambdaField(const FieldDecl *Field) {
-  assert(cast(CurCodeDecl)->getParent()->isLambda());
-  assert(cast(CurCodeDecl)->getParent() == Field->getParent());
+  assert(IsOutlinedSEHHelper || 
cast(CurCodeDecl)->getParent()->isLambda());
+  assert(IsOutlinedSEHHelper || cast(CurCodeDecl)->getParent() 
== Field->getParent());
   QualType LambdaTagType =
 getContext().getTagDeclType(Field->getParent());
   LValue LambdaLV = MakeNaturalAlignAddrLValue(CXXABIThisValue, LambdaTagType);
Index: clang/lib/CodeGen/CGException.cpp
===
--- clang/lib/CodeGen/CGException.cpp
+++ clang/lib/CodeGen/CGException.cpp
@@ -1966,7 +1966,6 @@
   StartFunction(GlobalDecl(), RetTy, Fn, FnInfo, Args,
 OutlinedStmt->getBeginLoc(), OutlinedStmt->getBeginLoc());
   CurSEHParent = ParentCGF.CurSEHParent;
-  CurCodeDecl = ParentCGF.CurCodeDecl;
 
   CGM.SetInternalFunctionAttributes(GlobalDecl(), CurFn, FnInfo);
   EmitCapturedLocals(ParentCGF, OutlinedStmt, IsFilter);


Index: clang/test/CodeGenCXX/exceptions-seh.cpp
===
--- clang/test/CodeGenCXX/exceptions-seh.cpp
+++ clang/test/CodeGenCXX/exceptions-seh.cpp
@@ -164,3 +164,5 @@
 // CHECK: store i32 1234, i32* @my_unique_global
 
 // CHECK: attributes #[[NOINLINE]] = { {{.*noinline.*}} }
+
+void seh_in_noexcept() noexcept { __try {} __finally {} }
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -4185,8 +4185,8 @@
 /// Given that we are currently emitting a lambda, emit an l-value for
 /// one of its members.
 LValue CodeGenFunction::EmitLValueForLambdaField(const FieldDecl *Field) {
-  assert(cast(CurCodeDecl)->getParent()->isLambda());
-  assert(cast(CurCodeDecl)->getParent() == Field->getParent());
+  assert(IsOutlinedSEHHelper || cast(CurCodeDecl)->getParent()->isLambda());
+  assert(IsOutlinedSEHHelper || cast(CurCodeDecl)->getParent() == Field->getParent());
   QualType LambdaTagType =
 getContext().getTagDeclType(Field->getParent());
   LValue LambdaLV = MakeNaturalAlignAddrLValue(CXXABIThisValue, LambdaTagType);
Index: clang/lib/CodeGen/CGException.cpp
===
--- clang/lib/CodeGen/CGException.cpp
+++ clang/lib/CodeGen/CGException.cpp
@@ -1966,7 +1966,6 @@
   StartFunction(GlobalDecl(), RetTy, Fn, FnInfo, Args,
 OutlinedStmt->getBeginLoc(), OutlinedStmt->getBeginLoc());
   CurSEHParent = ParentCGF.CurSEHParent;
-  CurCodeDecl = ParentCGF.CurCodeDecl;
 
   CGM.SetInternalFunctionAttributes(GlobalDecl(), CurFn, FnInfo);
   EmitCapturedLocals(ParentCGF, OutlinedStmt, IsFilter);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102026: Thread safety analysis: Allow exlusive/shared joins for managed and asserted capabilities

[Aaron Puchert via Phabricator via cfe-commits]

aaronpuchert created this revision.
aaronpuchert added reviewers: aaron.ballman, delesley.
aaronpuchert requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Similar to how we allow managed and asserted locks to be held and not
held in joining branches, we also allow them to be held shared and
exclusive. The scoped lock should restore the original state at the end
of the scope in any event, and asserted locks need not be released.

We should probably only allow asserted locks to be subsumed by managed,
not by (directly) acquired locks, but that's for another change.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102026

Files:
  clang/lib/Analysis/ThreadSafety.cpp
  clang/test/SemaCXX/warn-thread-safety-analysis.cpp

Index: clang/test/SemaCXX/warn-thread-safety-analysis.cpp
===
--- clang/test/SemaCXX/warn-thread-safety-analysis.cpp
+++ clang/test/SemaCXX/warn-thread-safety-analysis.cpp
@@ -2773,6 +2773,67 @@
   x = 2; // expected-warning {{writing variable 'x' requires holding mutex 'mu' exclusively}}
 }
 
+void exclusiveSharedJoin() {
+  RelockableMutexLock scope(, DeferTraits{});
+  if (b)
+scope.Lock();
+  else
+scope.ReaderLock();
+  // No warning on join point because the lock will be released by the scope object anyway.
+  print(x);
+  x = 2; // expected-warning {{writing variable 'x' requires holding mutex 'mu' exclusively}}
+}
+
+void sharedExclusiveJoin() {
+  RelockableMutexLock scope(, DeferTraits{});
+  if (b)
+scope.ReaderLock();
+  else
+scope.Lock();
+  // No warning on join point because the lock will be released by the scope object anyway.
+  print(x);
+  x = 2; // expected-warning {{writing variable 'x' requires holding mutex 'mu' exclusively}}
+}
+
+void assertJoin() {
+  RelockableMutexLock scope(, DeferTraits{});
+  if (b)
+scope.Lock();
+  else
+mu.AssertHeld();
+  x = 2;
+}
+
+void assertSharedJoin() {
+  RelockableMutexLock scope(, DeferTraits{});
+  if (b)
+scope.ReaderLock();
+  else
+mu.AssertReaderHeld();
+  print(x);
+  x = 2; // expected-warning {{writing variable 'x' requires holding mutex 'mu' exclusively}}
+}
+
+void assertStrongerJoin() {
+  RelockableMutexLock scope(, DeferTraits{});
+  if (b)
+scope.ReaderLock();
+  else
+mu.AssertHeld();
+  print(x);
+  x = 2; // expected-warning {{writing variable 'x' requires holding mutex 'mu' exclusively}}
+}
+
+void assertWeakerJoin() {
+  RelockableMutexLock scope(, DeferTraits{});
+  if (b)
+scope.Lock();
+  else
+mu.AssertReaderHeld();
+  print(x);
+  x = 2; // expected-warning {{writing variable 'x' requires holding mutex 'mu' exclusively}}
+}
+
 void directUnlock() {
   RelockableExclusiveMutexLock scope();
   mu.Unlock();
@@ -4506,8 +4567,8 @@
 
   void test6() {
 mu_.AssertHeld();
-mu_.Unlock();
-  }  // should this be a warning?
+mu_.Unlock(); // should this be a warning?
+  }
 
   void test7() {
 if (c) {
@@ -4528,9 +4589,10 @@
 else {
   mu_.AssertHeld();
 }
+// FIXME: should warn, because it's unclear whether we need to release or not.
 int b = a;
 a = 0;
-mu_.Unlock();
+mu_.Unlock(); // should this be a warning?
   }
 
   void test9() {
@@ -4558,6 +4620,28 @@
 int b = a;
 a = 0;
   }
+
+  void test12() {
+if (c)
+  mu_.ReaderLock(); // expected-warning {{mutex 'mu_' is acquired exclusively and shared in the same scope}}
+else
+  mu_.AssertHeld(); // expected-note {{the other acquisition of mutex 'mu_' is here}}
+// FIXME: should instead warn because it's unclear whether we need to release or not.
+int b = a;
+a = 0;
+mu_.Unlock();
+  }
+
+  void test13() {
+if (c)
+  mu_.Lock(); // expected-warning {{mutex 'mu_' is acquired exclusively and shared in the same scope}}
+else
+  mu_.AssertReaderHeld(); // expected-note {{the other acquisition of mutex 'mu_' is here}}
+// FIXME: should instead warn because it's unclear whether we need to release or not.
+int b = a;
+a = 0;
+mu_.Unlock();
+  }
 };
 
 }  // end namespace AssertHeldTest
Index: clang/lib/Analysis/ThreadSafety.cpp
===
--- clang/lib/Analysis/ThreadSafety.cpp
+++ clang/lib/Analysis/ThreadSafety.cpp
@@ -2194,9 +2194,16 @@
 /// \return  false if we should keep \p A, true if we should keep \p B.
 bool ThreadSafetyAnalyzer::join(const FactEntry , const FactEntry ) {
   if (A.kind() != B.kind()) {
-Handler.handleExclusiveAndShared("mutex", B.toString(), B.loc(), A.loc());
-// Take the exclusive capability to reduce further warnings.
-return B.kind() == LK_Exclusive;
+// For managed capabilities, the destructor should unlock in the right mode
+// anyway. For asserted capabilities no unlocking is needed.
+if ((A.managed() || A.asserted()) && (B.managed() || B.asserted())) {
+  // 

[PATCH] D102025: Thread safety analysis: Factor out function for merging locks (NFC)

[Aaron Puchert via Phabricator via cfe-commits]

aaronpuchert created this revision.
aaronpuchert added a reviewer: aaron.ballman.
aaronpuchert requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

It's going to become a bit more complicated, so let's have it separate.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102025

Files:
  clang/lib/Analysis/ThreadSafety.cpp


Index: clang/lib/Analysis/ThreadSafety.cpp
===
--- clang/lib/Analysis/ThreadSafety.cpp
+++ clang/lib/Analysis/ThreadSafety.cpp
@@ -1050,6 +1050,8 @@
   const CFGBlock* PredBlock,
   const CFGBlock *CurrBlock);
 
+  bool join(const FactEntry , const FactEntry );
+
   void intersectAndWarn(FactSet , const FactSet ,
 SourceLocation JoinLoc, LockErrorKind LEK1,
 LockErrorKind LEK2);
@@ -2186,6 +2188,21 @@
   }
 }
 
+/// Given two facts merging on a join point, decide whether to warn and which
+/// one to keep.
+///
+/// \return  false if we should keep \p A, true if we should keep \p B.
+bool ThreadSafetyAnalyzer::join(const FactEntry , const FactEntry ) {
+  if (A.kind() != B.kind()) {
+Handler.handleExclusiveAndShared("mutex", B.toString(), B.loc(), A.loc());
+// Take the exclusive capability to reduce further warnings.
+return B.kind() == LK_Exclusive;
+  } else {
+// The non-asserted capability is the one we want to track.
+return A.asserted() && !B.asserted();
+  }
+}
+
 /// Compute the intersection of two locksets and issue warnings for any
 /// locks in the symmetric difference.
 ///
@@ -2213,20 +2230,8 @@
 
 FactSet::iterator Iter1 = FSet1.findLockIter(FactMan, LDat2);
 if (Iter1 != FSet1.end()) {
-  const FactEntry  = FactMan[*Iter1];
-  if (LDat1.kind() != LDat2.kind()) {
-Handler.handleExclusiveAndShared("mutex", LDat2.toString(), 
LDat2.loc(),
- LDat1.loc());
-if (LEK1 == LEK_LockedSomePredecessors &&
-LDat1.kind() != LK_Exclusive) {
-  // Take the exclusive lock, which is the one in FSet2.
-  *Iter1 = Fact;
-}
-  } else if (LEK1 == LEK_LockedSomePredecessors && LDat1.asserted() &&
- !LDat2.asserted()) {
-// The non-asserted lock in FSet2 is the one we want to track.
+  if (join(FactMan[*Iter1], LDat2) && LEK1 == LEK_LockedSomePredecessors)
 *Iter1 = Fact;
-  }
 } else {
   LDat2.handleRemovalFromIntersection(FSet2, FactMan, JoinLoc, LEK1,
   Handler);


Index: clang/lib/Analysis/ThreadSafety.cpp
===
--- clang/lib/Analysis/ThreadSafety.cpp
+++ clang/lib/Analysis/ThreadSafety.cpp
@@ -1050,6 +1050,8 @@
   const CFGBlock* PredBlock,
   const CFGBlock *CurrBlock);
 
+  bool join(const FactEntry , const FactEntry );
+
   void intersectAndWarn(FactSet , const FactSet ,
 SourceLocation JoinLoc, LockErrorKind LEK1,
 LockErrorKind LEK2);
@@ -2186,6 +2188,21 @@
   }
 }
 
+/// Given two facts merging on a join point, decide whether to warn and which
+/// one to keep.
+///
+/// \return  false if we should keep \p A, true if we should keep \p B.
+bool ThreadSafetyAnalyzer::join(const FactEntry , const FactEntry ) {
+  if (A.kind() != B.kind()) {
+Handler.handleExclusiveAndShared("mutex", B.toString(), B.loc(), A.loc());
+// Take the exclusive capability to reduce further warnings.
+return B.kind() == LK_Exclusive;
+  } else {
+// The non-asserted capability is the one we want to track.
+return A.asserted() && !B.asserted();
+  }
+}
+
 /// Compute the intersection of two locksets and issue warnings for any
 /// locks in the symmetric difference.
 ///
@@ -2213,20 +2230,8 @@
 
 FactSet::iterator Iter1 = FSet1.findLockIter(FactMan, LDat2);
 if (Iter1 != FSet1.end()) {
-  const FactEntry  = FactMan[*Iter1];
-  if (LDat1.kind() != LDat2.kind()) {
-Handler.handleExclusiveAndShared("mutex", LDat2.toString(), LDat2.loc(),
- LDat1.loc());
-if (LEK1 == LEK_LockedSomePredecessors &&
-LDat1.kind() != LK_Exclusive) {
-  // Take the exclusive lock, which is the one in FSet2.
-  *Iter1 = Fact;
-}
-  } else if (LEK1 == LEK_LockedSomePredecessors && LDat1.asserted() &&
- !LDat2.asserted()) {
-// The non-asserted lock in FSet2 is the one we want to track.
+  if (join(FactMan[*Iter1], LDat2) && LEK1 == LEK_LockedSomePredecessors)
 *Iter1 = Fact;
-  }
 } else {
   LDat2.handleRemovalFromIntersection(FSet2, FactMan, JoinLoc, LEK1,
   Handler);
___
cfe-commits mailing 

[PATCH] D101755: Thread safety analysis: Eliminate parameter from intersectAndWarn (NFC)

[Aaron Puchert via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGd21e1b79ff7d: Thread safety analysis: Eliminate parameter 
from intersectAndWarn (NFC) (authored by aaronpuchert).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101755

Files:
  clang/lib/Analysis/ThreadSafety.cpp


Index: clang/lib/Analysis/ThreadSafety.cpp
===
--- clang/lib/Analysis/ThreadSafety.cpp
+++ clang/lib/Analysis/ThreadSafety.cpp
@@ -1051,14 +1051,12 @@
   const CFGBlock *CurrBlock);
 
   void intersectAndWarn(FactSet , const FactSet ,
-SourceLocation JoinLoc,
-LockErrorKind LEK1, LockErrorKind LEK2,
-bool Modify=true);
+SourceLocation JoinLoc, LockErrorKind LEK1,
+LockErrorKind LEK2);
 
   void intersectAndWarn(FactSet , const FactSet ,
-SourceLocation JoinLoc, LockErrorKind LEK1,
-bool Modify=true) {
-intersectAndWarn(FSet1, FSet2, JoinLoc, LEK1, LEK1, Modify);
+SourceLocation JoinLoc, LockErrorKind LEK1) {
+intersectAndWarn(FSet1, FSet2, JoinLoc, LEK1, LEK1);
   }
 
   void runAnalysis(AnalysisDeclContext );
@@ -2206,8 +2204,7 @@
 const FactSet ,
 SourceLocation JoinLoc,
 LockErrorKind LEK1,
-LockErrorKind LEK2,
-bool Modify) {
+LockErrorKind LEK2) {
   FactSet FSet1Orig = FSet1;
 
   // Find locks in FSet2 that conflict or are not in FSet1, and warn.
@@ -2220,11 +2217,13 @@
   if (LDat1.kind() != LDat2.kind()) {
 Handler.handleExclusiveAndShared("mutex", LDat2.toString(), 
LDat2.loc(),
  LDat1.loc());
-if (Modify && LDat1.kind() != LK_Exclusive) {
+if (LEK1 == LEK_LockedSomePredecessors &&
+LDat1.kind() != LK_Exclusive) {
   // Take the exclusive lock, which is the one in FSet2.
   *Iter1 = Fact;
 }
-  } else if (Modify && LDat1.asserted() && !LDat2.asserted()) {
+  } else if (LEK1 == LEK_LockedSomePredecessors && LDat1.asserted() &&
+ !LDat2.asserted()) {
 // The non-asserted lock in FSet2 is the one we want to track.
 *Iter1 = Fact;
   }
@@ -2242,7 +2241,7 @@
 if (!LDat2) {
   LDat1->handleRemovalFromIntersection(FSet1Orig, FactMan, JoinLoc, LEK2,
Handler);
-  if (Modify)
+  if (LEK2 == LEK_LockedSomePredecessors)
 FSet1.removeLock(FactMan, *LDat1);
 }
   }
@@ -2469,8 +2468,7 @@
 // Do not update EntrySet.
 intersectAndWarn(
 CurrBlockInfo->EntrySet, PrevLockset, PrevBlockInfo->ExitLoc,
-IsLoop ? LEK_LockedSomeLoopIterations : LEK_LockedSomePredecessors,
-!IsLoop);
+IsLoop ? LEK_LockedSomeLoopIterations : 
LEK_LockedSomePredecessors);
   }
 }
 
@@ -2518,10 +2516,8 @@
   CFGBlock *FirstLoopBlock = *SI;
   CFGBlockInfo *PreLoop = [FirstLoopBlock->getBlockID()];
   CFGBlockInfo *LoopEnd = [CurrBlockID];
-  intersectAndWarn(LoopEnd->ExitSet, PreLoop->EntrySet,
-   PreLoop->EntryLoc,
-   LEK_LockedSomeLoopIterations,
-   false);
+  intersectAndWarn(LoopEnd->ExitSet, PreLoop->EntrySet, PreLoop->EntryLoc,
+   LEK_LockedSomeLoopIterations);
 }
   }
 
@@ -2549,11 +2545,8 @@
 ExpectedExitSet.removeLock(FactMan, Lock);
 
   // FIXME: Should we call this function for all blocks which exit the 
function?
-  intersectAndWarn(ExpectedExitSet, Final->ExitSet,
-   Final->ExitLoc,
-   LEK_LockedAtEndOfFunction,
-   LEK_NotLockedAtEndOfFunction,
-   false);
+  intersectAndWarn(ExpectedExitSet, Final->ExitSet, Final->ExitLoc,
+   LEK_LockedAtEndOfFunction, LEK_NotLockedAtEndOfFunction);
 
   Handler.leaveFunction(CurrentFunction);
 }


Index: clang/lib/Analysis/ThreadSafety.cpp
===
--- clang/lib/Analysis/ThreadSafety.cpp
+++ clang/lib/Analysis/ThreadSafety.cpp
@@ -1051,14 +1051,12 @@
   const CFGBlock *CurrBlock);
 
   void intersectAndWarn(FactSet , const FactSet ,
-SourceLocation JoinLoc,
-LockErrorKind LEK1, LockErrorKind LEK2,
-bool Modify=true);
+SourceLocation JoinLoc, LockErrorKind LEK1,
+LockErrorKind LEK2);
 
   

[clang] d21e1b7 - Thread safety analysis: Eliminate parameter from intersectAndWarn (NFC)

[Aaron Puchert via cfe-commits]

Author: Aaron Puchert
Date: 2021-05-06T23:07:42+02:00
New Revision: d21e1b79ff7d40bca537c30da706e31e48483f21

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

LOG: Thread safety analysis: Eliminate parameter from intersectAndWarn (NFC)

We were modifying precisely when intersecting the lock sets of multiple
predecessors without back edge. That's no coincidence: we can't modify
on back edges, it doesn't make sense to modify at the end of a function,
and otherwise we always want to intersect on forward edges, because we
can build a new lock set for those.

Reviewed By: aaron.ballman

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

Added: 


Modified: 
clang/lib/Analysis/ThreadSafety.cpp

Removed: 




diff  --git a/clang/lib/Analysis/ThreadSafety.cpp 
b/clang/lib/Analysis/ThreadSafety.cpp
index 4377fc58a1d55..83410ebc2cae3 100644
--- a/clang/lib/Analysis/ThreadSafety.cpp
+++ b/clang/lib/Analysis/ThreadSafety.cpp
@@ -1051,14 +1051,12 @@ class ThreadSafetyAnalyzer {
   const CFGBlock *CurrBlock);
 
   void intersectAndWarn(FactSet , const FactSet ,
-SourceLocation JoinLoc,
-LockErrorKind LEK1, LockErrorKind LEK2,
-bool Modify=true);
+SourceLocation JoinLoc, LockErrorKind LEK1,
+LockErrorKind LEK2);
 
   void intersectAndWarn(FactSet , const FactSet ,
-SourceLocation JoinLoc, LockErrorKind LEK1,
-bool Modify=true) {
-intersectAndWarn(FSet1, FSet2, JoinLoc, LEK1, LEK1, Modify);
+SourceLocation JoinLoc, LockErrorKind LEK1) {
+intersectAndWarn(FSet1, FSet2, JoinLoc, LEK1, LEK1);
   }
 
   void runAnalysis(AnalysisDeclContext );
@@ -2206,8 +2204,7 @@ void ThreadSafetyAnalyzer::intersectAndWarn(FactSet 
,
 const FactSet ,
 SourceLocation JoinLoc,
 LockErrorKind LEK1,
-LockErrorKind LEK2,
-bool Modify) {
+LockErrorKind LEK2) {
   FactSet FSet1Orig = FSet1;
 
   // Find locks in FSet2 that conflict or are not in FSet1, and warn.
@@ -2220,11 +2217,13 @@ void ThreadSafetyAnalyzer::intersectAndWarn(FactSet 
,
   if (LDat1.kind() != LDat2.kind()) {
 Handler.handleExclusiveAndShared("mutex", LDat2.toString(), 
LDat2.loc(),
  LDat1.loc());
-if (Modify && LDat1.kind() != LK_Exclusive) {
+if (LEK1 == LEK_LockedSomePredecessors &&
+LDat1.kind() != LK_Exclusive) {
   // Take the exclusive lock, which is the one in FSet2.
   *Iter1 = Fact;
 }
-  } else if (Modify && LDat1.asserted() && !LDat2.asserted()) {
+  } else if (LEK1 == LEK_LockedSomePredecessors && LDat1.asserted() &&
+ !LDat2.asserted()) {
 // The non-asserted lock in FSet2 is the one we want to track.
 *Iter1 = Fact;
   }
@@ -2242,7 +2241,7 @@ void ThreadSafetyAnalyzer::intersectAndWarn(FactSet 
,
 if (!LDat2) {
   LDat1->handleRemovalFromIntersection(FSet1Orig, FactMan, JoinLoc, LEK2,
Handler);
-  if (Modify)
+  if (LEK2 == LEK_LockedSomePredecessors)
 FSet1.removeLock(FactMan, *LDat1);
 }
   }
@@ -2469,8 +2468,7 @@ void 
ThreadSafetyAnalyzer::runAnalysis(AnalysisDeclContext ) {
 // Do not update EntrySet.
 intersectAndWarn(
 CurrBlockInfo->EntrySet, PrevLockset, PrevBlockInfo->ExitLoc,
-IsLoop ? LEK_LockedSomeLoopIterations : LEK_LockedSomePredecessors,
-!IsLoop);
+IsLoop ? LEK_LockedSomeLoopIterations : 
LEK_LockedSomePredecessors);
   }
 }
 
@@ -2518,10 +2516,8 @@ void 
ThreadSafetyAnalyzer::runAnalysis(AnalysisDeclContext ) {
   CFGBlock *FirstLoopBlock = *SI;
   CFGBlockInfo *PreLoop = [FirstLoopBlock->getBlockID()];
   CFGBlockInfo *LoopEnd = [CurrBlockID];
-  intersectAndWarn(LoopEnd->ExitSet, PreLoop->EntrySet,
-   PreLoop->EntryLoc,
-   LEK_LockedSomeLoopIterations,
-   false);
+  intersectAndWarn(LoopEnd->ExitSet, PreLoop->EntrySet, PreLoop->EntryLoc,
+   LEK_LockedSomeLoopIterations);
 }
   }
 
@@ -2549,11 +2545,8 @@ void 
ThreadSafetyAnalyzer::runAnalysis(AnalysisDeclContext ) {
 ExpectedExitSet.removeLock(FactMan, Lock);
 
   // FIXME: Should we call this function for all blocks which exit the 
function?
-  intersectAndWarn(ExpectedExitSet, 

[PATCH] D70094: [clang-tidy] new altera ID dependent backward branch check

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman closed this revision.
aaron.ballman added a comment.

In D70094#2742760 , @ffrankies wrote:

> @aaron.ballman Thank you! As far as I'm aware, this is the last check that we 
> are planning to submit, so if I do get commit access now it's likely to be 
> unused. However, if that does change, then yes I would be interested in 
> obtaining commit access. For now, can you please commit this on my behalf? My 
> github username is ffrankies .

Ah, good to know! Thank you for the new check -- I've commit on your behalf in 
83af66e18e3d3760d56ea7e3bdbff3428ae7730d 



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

https://reviews.llvm.org/D70094

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

[clang-tools-extra] 83af66e - new altera ID dependent backward branch check

[Aaron Ballman via cfe-commits]

Author: Frank Derry Wanye
Date: 2021-05-06T17:01:39-04:00
New Revision: 83af66e18e3d3760d56ea7e3bdbff3428ae7730d

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

LOG: new altera ID dependent backward branch check

This lint check is a part of the FLOCL (FPGA Linters for OpenCL) project
out of the Synergy Lab at Virginia Tech.

FLOCL is a set of lint checks aimed at FPGA developers who write code
in OpenCL.

The altera ID dependent backward branch lint check finds ID dependent
variables and fields used within loops, and warns of their usage. Using
these variables in loops can lead to performance degradation.

Added: 
clang-tools-extra/clang-tidy/altera/IdDependentBackwardBranchCheck.cpp
clang-tools-extra/clang-tidy/altera/IdDependentBackwardBranchCheck.h

clang-tools-extra/docs/clang-tidy/checks/altera-id-dependent-backward-branch.rst

clang-tools-extra/test/clang-tidy/checkers/altera-id-dependent-backward-branch.cpp

Modified: 
clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
clang-tools-extra/clang-tidy/altera/CMakeLists.txt
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/docs/clang-tidy/checks/list.rst

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp 
b/clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
index a6c29e03f7aa8..17458771d6358 100644
--- a/clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
+++ b/clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
@@ -9,6 +9,7 @@
 #include "../ClangTidy.h"
 #include "../ClangTidyModule.h"
 #include "../ClangTidyModuleRegistry.h"
+#include "IdDependentBackwardBranchCheck.h"
 #include "KernelNameRestrictionCheck.h"
 #include "SingleWorkItemBarrierCheck.h"
 #include "StructPackAlignCheck.h"
@@ -23,6 +24,8 @@ namespace altera {
 class AlteraModule : public ClangTidyModule {
 public:
   void addCheckFactories(ClangTidyCheckFactories ) override {
+CheckFactories.registerCheck(
+"altera-id-dependent-backward-branch");
 CheckFactories.registerCheck(
 "altera-kernel-name-restriction");
 CheckFactories.registerCheck(

diff  --git a/clang-tools-extra/clang-tidy/altera/CMakeLists.txt 
b/clang-tools-extra/clang-tidy/altera/CMakeLists.txt
index c8a883d0750c5..cf8104b9d8426 100644
--- a/clang-tools-extra/clang-tidy/altera/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/altera/CMakeLists.txt
@@ -5,6 +5,7 @@ set(LLVM_LINK_COMPONENTS
 
 add_clang_library(clangTidyAlteraModule
   AlteraTidyModule.cpp
+  IdDependentBackwardBranchCheck.cpp
   KernelNameRestrictionCheck.cpp
   SingleWorkItemBarrierCheck.cpp
   StructPackAlignCheck.cpp

diff  --git 
a/clang-tools-extra/clang-tidy/altera/IdDependentBackwardBranchCheck.cpp 
b/clang-tools-extra/clang-tidy/altera/IdDependentBackwardBranchCheck.cpp
new file mode 100644
index 0..09cddb220877a
--- /dev/null
+++ b/clang-tools-extra/clang-tidy/altera/IdDependentBackwardBranchCheck.cpp
@@ -0,0 +1,264 @@
+//===--- IdDependentBackwardBranchCheck.cpp - clang-tidy 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "IdDependentBackwardBranchCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace altera {
+
+void IdDependentBackwardBranchCheck::registerMatchers(MatchFinder *Finder) {
+  // Prototype to identify all variables which hold a thread-variant ID.
+  // First Matcher just finds all the direct assignments of either ID call.
+  const auto ThreadID = expr(hasDescendant(callExpr(callee(functionDecl(
+  anyOf(hasName("get_global_id"), hasName("get_local_id")));
+
+  const auto RefVarOrField = forEachDescendant(
+  stmt(anyOf(declRefExpr(to(varDecl())).bind("assign_ref_var"),
+ memberExpr(member(fieldDecl())).bind("assign_ref_field";
+
+  Finder->addMatcher(
+  compoundStmt(
+  // Bind on actual get_local/global_id calls.
+  forEachDescendant(
+  stmt(
+  
anyOf(declStmt(hasDescendant(varDecl(hasInitializer(ThreadID))
+   .bind("tid_dep_var"))),
+binaryOperator(allOf(
+isAssignmentOperator(), hasRHS(ThreadID),
+hasLHS(anyOf(
+declRefExpr(to(varDecl().bind("tid_dep_var"))),
+memberExpr(member(
+   

[PATCH] D101976: [OpenMP] Unified entry point for SPMD & generic kernels in the device RTL

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D101976#2742788 , @JonChesterfield 
wrote:

> In D101976#2742188 , @jdoerfert 
> wrote:
>
>> In D101976#2742166 , 
>> @JonChesterfield wrote:
>>
>>> What are the required semantics of the barrier operations? Amdgcn builds 
>>> them on shared memory, so probably needs a change to the corresponding 
>>> target_impl to match
>>
>> I have *not* tested AMDGCN but I was not expecting a problem. The semantics 
>> I need here is: 
>>  warp N, thread 0 hits a barrier instruction I0
>>  warp N, threads 1-31 hit  a barrier instruction I1
>>  the entire warp synchronizes and moves on.
>
> One hazard is the amdgpu devicertl only has one barrier. D102016 
>  makes it simpler to add a second. I'd 
> guess we want named_sync to call one barrier and syncthreads to call a 
> different one, so we should probably rename those functions. The LDS barrier 
> implementation needs to know how many threads to wait for, we may be OK 
> passing 'all the threads' down from the __syncthreads entry point.
>
> The other is the single instruction pointer per wavefront, like pre-volta 
> nvidia cards (which I believe we also expect to work). I'm not sure whether 
> totally independent barriers will work, or whether we'll need to arrange for 
> thread 0 and thread 1-31 to call the two different barriers at the same point 
> in control flow.

So what do you wnat me to change for this patch now?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101976

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

[PATCH] D101139: Create install targets for scan-build-py.

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

Looking at `libear/__init__.py`, it's basically replicating CMake build to the 
point where it even emulates CMake template expansion, see 
https://github.com/llvm/llvm-project/blob/a3a8a1a15b524d91b5308db68e9d293b34cd88dd/clang/tools/scan-build-py/libear/__init__.py#L204.
 Given that we already use CMake, I think we should just build libear with 
CMake and ship libear as shared library and then modify 
https://github.com/llvm/llvm-project/blob/a3a8a1a15b524d91b5308db68e9d293b34cd88dd/clang/tools/scan-build-py/libscanbuild/intercept.py#L113
 to use the prebuilt version instead of building it every time. However, given 
that this change is already pretty large, I'm also fine if we do it in a follow 
up change.




Comment at: clang/tools/scan-build-py/CMakeLists.txt:1-7
+set (bin
+ "bin/analyze-build"
+ "bin/analyze-c++"
+ "bin/analyze-cc"
+ "bin/intercept-build"
+ "bin/intercept-c++"
+ "bin/intercept-cc")

I'd prefer to install all of these into `libexec` to match Perl `scan-build`.



Comment at: clang/tools/scan-build-py/CMakeLists.txt:27
+# Need to rename analyze-build to analyze-build-py to prevent overwriting
+# scan-build peral implementation.
+install (PROGRAMS "bin/scan-build"





Comment at: clang/tools/scan-build-py/CMakeLists.txt:28
+# scan-build peral implementation.
+install (PROGRAMS "bin/scan-build"
+  DESTINATION bin

A property we're trying to keep is that the build layout matches the 
installation layout, so in addition to installing files, we also need a custom 
target to copy these files into the build output directory. This is what Perl 
scan-build does as well, see 
https://github.com/llvm/llvm-project/blob/a3a8a1a15b524d91b5308db68e9d293b34cd88dd/clang/tools/scan-build/CMakeLists.txt#L41


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

https://reviews.llvm.org/D101139

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

[PATCH] D102001: [Index] Ignore nullptr decls for indexing

[Argyrios Kyrtzidis via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa3a8a1a15b52: [Index] Ignore nullptr decls for indexing 
(authored by ahoppen, committed by akyrtzi).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102001

Files:
  clang/lib/Index/IndexDecl.cpp


Index: clang/lib/Index/IndexDecl.cpp
===
--- clang/lib/Index/IndexDecl.cpp
+++ clang/lib/Index/IndexDecl.cpp
@@ -759,7 +759,7 @@
 }
 
 bool IndexingContext::indexTopLevelDecl(const Decl *D) {
-  if (D->getLocation().isInvalid())
+  if (!D || D->getLocation().isInvalid())
 return true;
 
   if (isa(D))


Index: clang/lib/Index/IndexDecl.cpp
===
--- clang/lib/Index/IndexDecl.cpp
+++ clang/lib/Index/IndexDecl.cpp
@@ -759,7 +759,7 @@
 }
 
 bool IndexingContext::indexTopLevelDecl(const Decl *D) {
-  if (D->getLocation().isInvalid())
+  if (!D || D->getLocation().isInvalid())
 return true;
 
   if (isa(D))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] a3a8a1a - [Index] Ignore nullptr decls for indexing

[Argyrios Kyrtzidis via cfe-commits]

Author: Alex Hoppen
Date: 2021-05-06T13:12:26-07:00
New Revision: a3a8a1a15b524d91b5308db68e9d293b34cd88dd

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

LOG: [Index] Ignore nullptr decls for indexing

We can end up with a call to `indexTopLevelDecl(D)` with `D == nullptr` in 
non-assert builds e.g. when indexing a module in `indexModule` and
- `ASTReader::GetDecl` returns `nullptr` if `Index >= DeclsLoaded.size()`, thus 
returning `nullptr`
=> `ModuleDeclIterator::operator*` returns `nullptr`
=> we call `IndexCtx.indexTopLevelDecl` with `nullptr`

Be resilient and just ignore the `nullptr` decls during indexing.

Reviewed By: akyrtzi

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

Added: 


Modified: 
clang/lib/Index/IndexDecl.cpp

Removed: 




diff  --git a/clang/lib/Index/IndexDecl.cpp b/clang/lib/Index/IndexDecl.cpp
index 2ba323e63575..00adb3644ff2 100644
--- a/clang/lib/Index/IndexDecl.cpp
+++ b/clang/lib/Index/IndexDecl.cpp
@@ -759,7 +759,7 @@ bool IndexingContext::indexDeclContext(const DeclContext 
*DC) {
 }
 
 bool IndexingContext::indexTopLevelDecl(const Decl *D) {
-  if (D->getLocation().isInvalid())
+  if (!D || D->getLocation().isInvalid())
 return true;
 
   if (isa(D))



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

[PATCH] D102018: [WebAssembly] Use functions instead of macros for const SIMD intrinsics

[Thomas Lively via Phabricator via cfe-commits]

tlively created this revision.
tlively added a reviewer: aheejin.
Herald added subscribers: wingo, ecnelises, sunfish, jgravelle-google, sbc100, 
dschuff.
tlively requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

To improve hygiene, consistency, and usability, it would be good to replace all
the macro intrinsics in wasm_simd128.h with functions. The reason for using
macros in the first place was to enforce the use of constants for some arguments
using `_Static_assert` with `__builtin_constant_p`. This commit switches to
using functions and uses the `__diagnose_if__` attribute rather than
`_Static_assert` to enforce constantness.

The remaining macro intrinsics cannot be made into functions until the builtin
functions they are implemented with can be replaced with normal code patterns
because the builtin functions themselves require that their arguments are
constants.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102018

Files:
  clang/lib/Headers/wasm_simd128.h
  clang/test/Headers/wasm.c

Index: clang/test/Headers/wasm.c
===
--- clang/test/Headers/wasm.c
+++ clang/test/Headers/wasm.c
@@ -420,7 +420,7 @@
 
 // CHECK-LABEL: @test_f32x4_const_splat(
 // CHECK-NEXT:  entry:
-// CHECK-NEXT:ret <4 x i32> 
+// CHECK-NEXT:ret <4 x i32> 
 //
 v128_t test_f32x4_const_splat() {
   return wasm_f32x4_const_splat(42);
@@ -428,7 +428,7 @@
 
 // CHECK-LABEL: @test_f64x2_const_splat(
 // CHECK-NEXT:  entry:
-// CHECK-NEXT:ret <4 x i32> 
+// CHECK-NEXT:ret <4 x i32> 
 //
 v128_t test_f64x2_const_splat() {
   return wasm_f64x2_const_splat(42);
Index: clang/lib/Headers/wasm_simd128.h
===
--- clang/lib/Headers/wasm_simd128.h
+++ clang/lib/Headers/wasm_simd128.h
@@ -48,8 +48,9 @@
   __attribute__((__always_inline__, __nodebug__, __target__("simd128"),\
  __min_vector_width__(128)))
 
-#define __REQUIRE_CONSTANT(e)  \
-  _Static_assert(__builtin_constant_p(e), "Expected constant")
+#define __REQUIRE_CONSTANT(c)  \
+  __attribute__((__diagnose_if__(!__builtin_constant_p(c), \
+ #c " must be constant", "error")))
 
 static __inline__ v128_t __DEFAULT_FN_ATTRS wasm_v128_load(const void *__mem) {
   // UB-free unaligned access copied from xmmintrin.h
@@ -246,88 +247,90 @@
   return (v128_t)(__f64x2){__c0, __c1};
 }
 
-#define wasm_i8x16_const(__c0, __c1, __c2, __c3, __c4, __c5, __c6, __c7, __c8, \
- __c9, __c10, __c11, __c12, __c13, __c14, __c15)   \
-  __extension__({  \
-__REQUIRE_CONSTANT(__c0);  \
-__REQUIRE_CONSTANT(__c1);  \
-__REQUIRE_CONSTANT(__c2);  \
-__REQUIRE_CONSTANT(__c3);  \
-__REQUIRE_CONSTANT(__c4);  \
-__REQUIRE_CONSTANT(__c5);  \
-__REQUIRE_CONSTANT(__c6);  \
-__REQUIRE_CONSTANT(__c7);  \
-__REQUIRE_CONSTANT(__c8);  \
-__REQUIRE_CONSTANT(__c9);  \
-__REQUIRE_CONSTANT(__c10); \
-__REQUIRE_CONSTANT(__c11); \
-__REQUIRE_CONSTANT(__c12); \
-__REQUIRE_CONSTANT(__c13); \
-__REQUIRE_CONSTANT(__c14); \
-__REQUIRE_CONSTANT(__c15); \
-(v128_t)(__i8x16){__c0, __c1, __c2,  __c3,  __c4,  __c5,  __c6,  __c7, \
-  __c8, __c9, __c10, __c11, __c12, __c13, __c14, __c15};   \
-  })
-
-#define wasm_i16x8_const(__c0, __c1, __c2, __c3, __c4, __c5, __c6, __c7)   \
-  __extension__({  \
-__REQUIRE_CONSTANT(__c0);  \
-__REQUIRE_CONSTANT(__c1);  \
-__REQUIRE_CONSTANT(__c2);  \
-__REQUIRE_CONSTANT(__c3);  \
-__REQUIRE_CONSTANT(__c4);  \
-__REQUIRE_CONSTANT(__c5);

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

[Eli Friedman via Phabricator via cfe-commits]

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

LGTM


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

https://reviews.llvm.org/D98798

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

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

[Jamie Schmeiser via Phabricator via cfe-commits]

jamieschmeiser updated this revision to Diff 343483.
jamieschmeiser added a comment.

Respond to review comments: add C++ test.


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

https://reviews.llvm.org/D98798

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


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


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

[PATCH] D101976: [OpenMP] Unified entry point for SPMD & generic kernels in the device RTL

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

In D101976#2742188 , @jdoerfert wrote:

> In D101976#2742166 , 
> @JonChesterfield wrote:
>
>> What are the required semantics of the barrier operations? Amdgcn builds 
>> them on shared memory, so probably needs a change to the corresponding 
>> target_impl to match
>
> I have *not* tested AMDGCN but I was not expecting a problem. The semantics I 
> need here is: 
>  warp N, thread 0 hits a barrier instruction I0
>  warp N, threads 1-31 hit  a barrier instruction I1
>  the entire warp synchronizes and moves on.

One hazard is the amdgpu devicertl only has one barrier. D102016 
 makes it simpler to add a second. I'd guess 
we want named_sync to call one barrier and syncthreads to call a different one, 
so we should probably rename those functions. The LDS barrier implementation 
needs to know how many threads to wait for, we may be OK passing 'all the 
threads' down from the __syncthreads entry point.

The other is the single instruction pointer per wavefront, like pre-volta 
nvidia cards (which I believe we also expect to work). I'm not sure whether 
totally independent barriers will work, or whether we'll need to arrange for 
thread 0 and thread 1-31 to call the two different barriers at the same point 
in control flow.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101976

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

[PATCH] D70094: [clang-tidy] new altera ID dependent backward branch check

[Frank Derry Wanye via Phabricator via cfe-commits]

ffrankies marked 2 inline comments as done.
ffrankies added a comment.

@aaron.ballman Thank you! As far as I'm aware, this is the last check that we 
are planning to submit, so if I do get commit access now it's likely to be 
unused. However, if that does change, then yes I would be interested in 
obtaining commit access. For now, can you please commit this on my behalf? My 
github username is ffrankies .


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

https://reviews.llvm.org/D70094

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

[PATCH] D102015: [clang CodeGen] Don't crash on large atomic function parameter.

[Eli Friedman via Phabricator via cfe-commits]

efriedma created this revision.
efriedma added reviewers: rsmith, ahatanak, rjmccall.
Herald added a subscriber: jfb.
efriedma requested review of this revision.
Herald added a project: clang.

I wouldn't recommend writing code like the testcase; a function parameter isn't 
atomic, so using an atomic type doesn't really make sense.  But it's valid, so 
clang shouldn't crash on it.

The code was assuming hasAggregateEvaluationKind(Ty) implies Ty is a 
RecordType, which isn't true.  Looking at the code, I think the only other 
possibility for a parameter is an atomic type, though.  Atomic types are always 
trivially destructible, I think.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102015

Files:
  clang/lib/CodeGen/CGDecl.cpp
  clang/test/CodeGen/big-atomic-ops.c


Index: clang/test/CodeGen/big-atomic-ops.c
===
--- clang/test/CodeGen/big-atomic-ops.c
+++ clang/test/CodeGen/big-atomic-ops.c
@@ -311,4 +311,9 @@
   // CHECK: }
 }
 
+// Check this doesn't crash
+// CHECK: @test_atomic_array_param(
+void test_atomic_array_param(_Atomic(struct foo) a) {
+}
+
 #endif
Index: clang/lib/CodeGen/CGDecl.cpp
===
--- clang/lib/CodeGen/CGDecl.cpp
+++ clang/lib/CodeGen/CGDecl.cpp
@@ -2474,6 +2474,7 @@
 // Don't push a cleanup in a thunk for a method that will also emit a
 // cleanup.
 if (hasAggregateEvaluationKind(Ty) && !CurFuncIsThunk &&
+!Ty->isAtomicType() &&
 Ty->castAs()->getDecl()->isParamDestroyedInCallee()) {
   if (QualType::DestructionKind DtorKind =
   D.needsDestruction(getContext())) {


Index: clang/test/CodeGen/big-atomic-ops.c
===
--- clang/test/CodeGen/big-atomic-ops.c
+++ clang/test/CodeGen/big-atomic-ops.c
@@ -311,4 +311,9 @@
   // CHECK: }
 }
 
+// Check this doesn't crash
+// CHECK: @test_atomic_array_param(
+void test_atomic_array_param(_Atomic(struct foo) a) {
+}
+
 #endif
Index: clang/lib/CodeGen/CGDecl.cpp
===
--- clang/lib/CodeGen/CGDecl.cpp
+++ clang/lib/CodeGen/CGDecl.cpp
@@ -2474,6 +2474,7 @@
 // Don't push a cleanup in a thunk for a method that will also emit a
 // cleanup.
 if (hasAggregateEvaluationKind(Ty) && !CurFuncIsThunk &&
+!Ty->isAtomicType() &&
 Ty->castAs()->getDecl()->isParamDestroyedInCallee()) {
   if (QualType::DestructionKind DtorKind =
   D.needsDestruction(getContext())) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101967: [Driver] Use x86-64 libc++ headers with -m32

[Petr Hosek via Phabricator via cfe-commits]

phosek abandoned this revision.
phosek added a comment.

After some further discussion, we've decided to generate a `__config_site` in 
our build only for the specific purpose.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101967

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

[PATCH] D102013: [Fuchsia][CMake] Update OSX deployment target

[Petr Hosek 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 rG8cb191b724b7: [Fuchsia][CMake] Update OSX deployment target 
(authored by phosek).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102013

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/cmake/caches/Fuchsia.cmake


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -36,7 +36,7 @@
 set(LLVM_ENABLE_ASSERTIONS ON CACHE BOOL "")
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 if(APPLE)
-  set(MACOSX_DEPLOYMENT_TARGET 10.7 CACHE STRING "")
+  set(CMAKE_OSX_DEPLOYMENT_TARGET "10.13" CACHE STRING "")
 elseif(MSVC)
   set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded" CACHE STRING "")
 endif()
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -42,7 +42,7 @@
 
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 if (APPLE)
-  set(MACOSX_DEPLOYMENT_TARGET 10.7 CACHE STRING "")
+  set(CMAKE_OSX_DEPLOYMENT_TARGET "10.13" CACHE STRING "")
 elseif(MSVC)
   set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded" CACHE STRING "")
 endif()


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -36,7 +36,7 @@
 set(LLVM_ENABLE_ASSERTIONS ON CACHE BOOL "")
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 if(APPLE)
-  set(MACOSX_DEPLOYMENT_TARGET 10.7 CACHE STRING "")
+  set(CMAKE_OSX_DEPLOYMENT_TARGET "10.13" CACHE STRING "")
 elseif(MSVC)
   set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded" CACHE STRING "")
 endif()
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -42,7 +42,7 @@
 
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 if (APPLE)
-  set(MACOSX_DEPLOYMENT_TARGET 10.7 CACHE STRING "")
+  set(CMAKE_OSX_DEPLOYMENT_TARGET "10.13" CACHE STRING "")
 elseif(MSVC)
   set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded" CACHE STRING "")
 endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 8cb191b - [Fuchsia][CMake] Update OSX deployment target

[Petr Hosek via cfe-commits]

Author: Petr Hosek
Date: 2021-05-06T12:06:16-07:00
New Revision: 8cb191b724b734a7432a63eb49f54cb9f4333d51

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

LOG: [Fuchsia][CMake] Update OSX deployment target

Use correct spelling of CMAKE_OSX_DEPLOYMENT_TARGET and bump the
minimum version to 10.13 which matches what we use for host tools
in Fuchsia.

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

Added: 


Modified: 
clang/cmake/caches/Fuchsia-stage2.cmake
clang/cmake/caches/Fuchsia.cmake

Removed: 




diff  --git a/clang/cmake/caches/Fuchsia-stage2.cmake 
b/clang/cmake/caches/Fuchsia-stage2.cmake
index f83ef1f3ac66..2cc25ba1fda8 100644
--- a/clang/cmake/caches/Fuchsia-stage2.cmake
+++ b/clang/cmake/caches/Fuchsia-stage2.cmake
@@ -42,7 +42,7 @@ set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
 
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 if (APPLE)
-  set(MACOSX_DEPLOYMENT_TARGET 10.7 CACHE STRING "")
+  set(CMAKE_OSX_DEPLOYMENT_TARGET "10.13" CACHE STRING "")
 elseif(MSVC)
   set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded" CACHE STRING "")
 endif()

diff  --git a/clang/cmake/caches/Fuchsia.cmake 
b/clang/cmake/caches/Fuchsia.cmake
index d61b5e6f04e4..92097da92a59 100644
--- a/clang/cmake/caches/Fuchsia.cmake
+++ b/clang/cmake/caches/Fuchsia.cmake
@@ -36,7 +36,7 @@ set(ENABLE_X86_RELAX_RELOCATIONS ON CACHE BOOL "")
 set(LLVM_ENABLE_ASSERTIONS ON CACHE BOOL "")
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 if(APPLE)
-  set(MACOSX_DEPLOYMENT_TARGET 10.7 CACHE STRING "")
+  set(CMAKE_OSX_DEPLOYMENT_TARGET "10.13" CACHE STRING "")
 elseif(MSVC)
   set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded" CACHE STRING "")
 endif()



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

[PATCH] D97680: [OpenMP] Simplify GPU memory globalization

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 343469.
jhuber6 added a comment.

Rebasing. The previous change to the test files required massive changes that 
made the file size too big to upload, so context is limited.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97680

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/OpenMP/assumes_include_nvptx.cpp
  clang/test/OpenMP/declare_target_codegen_globalization.cpp
  clang/test/OpenMP/nvptx_data_sharing.cpp
  clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/nvptx_multi_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_nested_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_for_codegen.cpp
  clang/test/OpenMP/nvptx_target_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_proc_bind_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/nvptx_teams_codegen.cpp
  clang/test/OpenMP/nvptx_teams_reduction_codegen.cpp
  clang/test/OpenMP/target_parallel_debug_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
  llvm/lib/Transforms/IPO/OpenMPOpt.cpp
  llvm/test/Transforms/OpenMP/globalization_remarks.ll
  llvm/test/Transforms/PhaseOrdering/openmp-opt-module.ll
  openmp/libomptarget/deviceRTLs/common/src/data_sharing.cu
  openmp/libomptarget/deviceRTLs/interface.h

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

[PATCH] D91466: [WIP][clang][Fuchsia] Support HWASan for Fuchsia

[Leonard Chan via Phabricator via cfe-commits]

leonardchan updated this revision to Diff 343468.
leonardchan added a comment.

Rebased.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91466

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  compiler-rt/cmake/config-ix.cmake
  compiler-rt/lib/hwasan/CMakeLists.txt
  compiler-rt/lib/hwasan/hwasan_dynamic_shadow.cpp
  compiler-rt/lib/hwasan/hwasan_fuchsia.cpp
  compiler-rt/lib/hwasan/hwasan_interceptors.cpp
  compiler-rt/lib/hwasan/hwasan_interface_internal.h
  compiler-rt/lib/hwasan/hwasan_poisoning.cpp
  compiler-rt/lib/hwasan/hwasan_thread.cpp
  compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_fuchsia.h
  compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup.cpp

Index: compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup.cpp
===
--- compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup.cpp
+++ compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup.cpp
@@ -54,6 +54,11 @@
   return false;
 }
 
+// TODO: We should also have an offline implementation. This function was
+// initially undefined when building hwasan. It's probably just because no one
+// used this until now that we didn't see this before.
+bool Symbolizer::SymbolizeFrame(uptr addr, FrameInfo *info) { return false; }
+
 // This is used in some places for suppression checking, which we
 // don't really support for Fuchsia.  It's also used in UBSan to
 // identify a PC location to a function name, so we always fill in
Index: compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_fuchsia.h
===
--- /dev/null
+++ compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_fuchsia.h
@@ -0,0 +1,25 @@
+//===-- sanitizer_platform_limits_fuchsia.h ---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file is a part of Sanitizer common code.
+//
+// Sizes and layouts of platform-specific Fuchsia data structures.
+//===--===//
+
+#ifndef SANITIZER_PLATFORM_LIMITS_FUCHSIA_H
+#define SANITIZER_PLATFORM_LIMITS_FUCHSIA_H
+
+#if SANITIZER_FUCHSIA
+
+namespace __sanitizer {
+struct __sanitizer_struct_mallinfo {};
+}  // namespace __sanitizer
+
+#endif  // SANITIZER_FUCHSIA
+
+#endif
Index: compiler-rt/lib/hwasan/hwasan_thread.cpp
===
--- compiler-rt/lib/hwasan/hwasan_thread.cpp
+++ compiler-rt/lib/hwasan/hwasan_thread.cpp
@@ -51,12 +51,18 @@
   // ScopedTaggingDisable needs GetCurrentThread to be set up.
   ScopedTaggingDisabler disabler;
 
+#if !SANITIZER_FUCHSIA
   uptr tls_size;
   uptr stack_size;
   GetThreadStackAndTls(IsMainThread(), _bottom_, _size, _begin_,
_size);
   stack_top_ = stack_bottom_ + stack_size;
   tls_end_ = tls_begin_ + tls_size;
+#else
+  __sanitizer::GetThreadStackTopAndBottom(true, _top_,
+  _bottom_);
+  tls_end_ = tls_begin_ = 0;
+#endif
 
   if (stack_bottom_) {
 int local;
Index: compiler-rt/lib/hwasan/hwasan_poisoning.cpp
===
--- compiler-rt/lib/hwasan/hwasan_poisoning.cpp
+++ compiler-rt/lib/hwasan/hwasan_poisoning.cpp
@@ -22,6 +22,10 @@
 uptr TagMemoryAligned(uptr p, uptr size, tag_t tag) {
   CHECK(IsAligned(p, kShadowAlignment));
   CHECK(IsAligned(size, kShadowAlignment));
+#if SANITIZER_FUCHSIA
+  __sanitizer_fill_shadow(p, size, tag,
+  common_flags()->clear_shadow_mmap_threshold);
+#else
   uptr shadow_start = MemToShadow(p);
   uptr shadow_size = MemToShadowSize(size);
 
@@ -40,6 +44,7 @@
   } else {
 internal_memset((void *)shadow_start, tag, shadow_size);
   }
+#endif
   return AddTagToPointer(p, tag);
 }
 
Index: compiler-rt/lib/hwasan/hwasan_interface_internal.h
===
--- compiler-rt/lib/hwasan/hwasan_interface_internal.h
+++ compiler-rt/lib/hwasan/hwasan_interface_internal.h
@@ -15,7 +15,12 @@
 #define HWASAN_INTERFACE_INTERNAL_H
 
 #include "sanitizer_common/sanitizer_internal_defs.h"
+#if SANITIZER_FUCHSIA
+#include "sanitizer_common/sanitizer_platform_limits_fuchsia.h"
+#endif
+#if SANITIZER_POSIX
 #include "sanitizer_common/sanitizer_platform_limits_posix.h"
+#endif
 #include 
 
 extern "C" {
Index: compiler-rt/lib/hwasan/hwasan_interceptors.cpp
===
--- compiler-rt/lib/hwasan/hwasan_interceptors.cpp
+++ compiler-rt/lib/hwasan/hwasan_interceptors.cpp
@@ -21,7 +21,12 

[PATCH] D102013: [Fuchsia][CMake] Update OSX deployment target

[Petr Hosek via Phabricator via cfe-commits]

phosek created this revision.
phosek added reviewers: leonardchan, haowei, mcgrathr, gulfem.
Herald added a subscriber: mgorny.
phosek requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Use correct spelling of CMAKE_OSX_DEPLOYMENT_TARGET and bump the
minimum version to 10.13 which matches what we use for host tools
in Fuchsia.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102013

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  clang/cmake/caches/Fuchsia.cmake


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -36,7 +36,7 @@
 set(LLVM_ENABLE_ASSERTIONS ON CACHE BOOL "")
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 if(APPLE)
-  set(MACOSX_DEPLOYMENT_TARGET 10.7 CACHE STRING "")
+  set(CMAKE_OSX_DEPLOYMENT_TARGET "10.13" CACHE STRING "")
 elseif(MSVC)
   set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded" CACHE STRING "")
 endif()
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -42,7 +42,7 @@
 
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 if (APPLE)
-  set(MACOSX_DEPLOYMENT_TARGET 10.7 CACHE STRING "")
+  set(CMAKE_OSX_DEPLOYMENT_TARGET "10.13" CACHE STRING "")
 elseif(MSVC)
   set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded" CACHE STRING "")
 endif()


Index: clang/cmake/caches/Fuchsia.cmake
===
--- clang/cmake/caches/Fuchsia.cmake
+++ clang/cmake/caches/Fuchsia.cmake
@@ -36,7 +36,7 @@
 set(LLVM_ENABLE_ASSERTIONS ON CACHE BOOL "")
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 if(APPLE)
-  set(MACOSX_DEPLOYMENT_TARGET 10.7 CACHE STRING "")
+  set(CMAKE_OSX_DEPLOYMENT_TARGET "10.13" CACHE STRING "")
 elseif(MSVC)
   set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded" CACHE STRING "")
 endif()
Index: clang/cmake/caches/Fuchsia-stage2.cmake
===
--- clang/cmake/caches/Fuchsia-stage2.cmake
+++ clang/cmake/caches/Fuchsia-stage2.cmake
@@ -42,7 +42,7 @@
 
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 if (APPLE)
-  set(MACOSX_DEPLOYMENT_TARGET 10.7 CACHE STRING "")
+  set(CMAKE_OSX_DEPLOYMENT_TARGET "10.13" CACHE STRING "")
 elseif(MSVC)
   set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded" CACHE STRING "")
 endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D101873: [clang] Support clang -fpic -fno-semantic-interposition for AArch64

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D101873#2741903 , @peter.smith 
wrote:

> In D101873#2741299 , @MaskRay wrote:
>
>> https://gist.github.com/MaskRay/2d4dfcfc897341163f734afb59f689c6 has more 
>> information about -fno-semantic-interposition.
>>
>>> Can Clang default to -fno-semantic-interposition?
>>
>> I think we can probably make non-x86 default to -fno-semantic-interposition 
>> (dso_local inference, given D72197 . x86 
>> may find default -fno-semantic-interposition too aggressive.
>
> Thanks for the link, and the explanation that -fno-semantic-interposition is 
> not the default.
>
> I'm not (yet) convinced that we could make -fno-semantic-interposition the 
> default, primarily due to data and not functions, I agree that 
> interpositioning functions is rarely used. For data the classic example for 
> symbol-interposition was errno, a shared library can't know if any other 
> library or executable will define it so it must define, but it must use only 
> one value for the definition. I'm not sure if that still holds in today's 
> environment with shared C libraries used by practically everything but I 
> think the principle still applies.

errno needs to be thread-local. C11 7.5.2 says "and errno which expands to a 
modifiable lvalue that has type int and thread local storage duration, the 
value of which is set to a positive error number by several library functions."
Do you mean that in some environment it may be defined in more than one shared 
object?

> Looking at the gist I've got one concern for AArch64 and Arm. The ABI relies 
> on thunks which are only defined for symbols of type STT_FUNC. Changing 
> branches to STT_FUNC to STT_SECTION will break long range thunks on AArch64 
> and interworking for Arm (there is a possibility that the bottom bit for 
> STT_FUNC may get used in the future for AArch64 as well). This is solvable by 
> keeping the local label and setting STT_FUNC on it.

I'll unlikely touch 32-bit arm.

For aarch64, aaelf64/aaelf64.rst says

  A linker may use a veneer (a sequence of instructions) to implement a 
relocated branch if the relocation is either
  
  ``R__CALL26``, ``R__JUMP26`` or ``R__PLT32`` and:
  
  - The target symbol has type ``STT_FUNC``.
  
  - Or, the target symbol and relocated place are in separate sections input to 
the linker.
  
  - Or, the target symbol is undefined (external to the link unit).

If `bl .Lhigh_target$local` and `.Lhigh_target$local` are in the same section, 
the fixup is resolved at assembly time;
otherwise, they are in separate sections and satisfy the ABI requirement.

I just changed `bl high_target` in `test/lld/ELF/aarch64-thunk-script.s` and 
noticed that both GNU ld and ld.lld can produce a thunk, regardless of the 
symbol type.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101873

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

[libunwind] 8408d3f - [libunwind] NFC: Use macros to accommodate differences in representation of PowerPC assemblers

[Xing Xue via cfe-commits]

Author: Xing Xue
Date: 2021-05-06T14:33:38-04:00
New Revision: 8408d3f2d814b19da450ff162f47981b55a9703a

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

LOG: [libunwind] NFC: Use macros to accommodate differences in representation 
of PowerPC assemblers

Summary:
This NFC patch replaces the representation of registers and the left shift 
operator in the PowerPC assembly code to allow it to be consumed by the GNU 
flavored assembler and the AIX assembler.

* Registers - change the representation of PowperPC registers from %rn, %fn, 
%vsn, and %vrn to the register number alone, e.g., n. The GNU flavored 
assembler and the AIX assembler are able to determine the register kind based 
on the context of the instruction in which the register is used.

* Left shift operator - use macro PPC_LEFT_SHIFT to represent the left shift 
operator. The left shift operator in the AIX assembly language is < instead of 
<<

Reviewed by: sfertile, MaskRay, compnerd

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

Added: 


Modified: 
libunwind/src/UnwindRegistersRestore.S
libunwind/src/UnwindRegistersSave.S
libunwind/src/assembly.h

Removed: 




diff  --git a/libunwind/src/UnwindRegistersRestore.S 
b/libunwind/src/UnwindRegistersRestore.S
index 6d12d93cb102..d8bf1adee416 100644
--- a/libunwind/src/UnwindRegistersRestore.S
+++ b/libunwind/src/UnwindRegistersRestore.S
@@ -134,7 +134,7 @@ 
DEFINE_LIBUNWIND_FUNCTION(_ZN9libunwind15Registers_ppc646jumptoEv)
 
 // load register (GPR)
 #define PPC64_LR(n) \
-  ld%r##n, (8 * (n + 2))(%r3)
+  ldn, (8 * (n + 2))(3)
 
   // restore integral registers
   // skip r0 for now
@@ -176,12 +176,12 @@ 
DEFINE_LIBUNWIND_FUNCTION(_ZN9libunwind15Registers_ppc646jumptoEv)
   // (note that this also restores floating point registers and V registers,
   // because part of VS is mapped to these registers)
 
-  addi  %r4, %r3, PPC64_OFFS_FP
+  addi  4, 3, PPC64_OFFS_FP
 
 // load VS register
 #define PPC64_LVS(n) \
-  lxvd2x  %vs##n, 0, %r4;\
-  addi%r4, %r4, 16
+  lxvd2x  n, 0, 4   ;\
+  addi4, 4, 16
 
   // restore the first 32 VS regs (and also all floating point regs)
   PPC64_LVS(0)
@@ -220,23 +220,23 @@ 
DEFINE_LIBUNWIND_FUNCTION(_ZN9libunwind15Registers_ppc646jumptoEv)
   // use VRSAVE to conditionally restore the remaining VS regs,
   // that are where the V regs are mapped
 
-  ld%r5, PPC64_OFFS_VRSAVE(%r3)   // test VRsave
-  cmpwi %r5, 0
+  ld5, PPC64_OFFS_VRSAVE(3)   // test VRsave
+  cmpwi 5, 0
   beq   Lnovec
 
 // conditionally load VS
 #define PPC64_CLVS_BOTTOM(n)   \
   beqLdone##n ;\
-  addi   %r4, %r3, PPC64_OFFS_FP + n * 16 ;\
-  lxvd2x %vs##n, 0, %r4   ;\
+  addi   4, 3, PPC64_OFFS_FP + n * 16 ;\
+  lxvd2x n, 0, 4  ;\
 Ldone##n:
 
-#define PPC64_CLVSl(n)   \
-  andis. %r0, %r5, (1<<(47-n))  ;\
+#define PPC64_CLVSl(n)\
+  andis. 0, 5, (1 PPC_LEFT_SHIFT(47-n))  ;\
 PPC64_CLVS_BOTTOM(n)
 
-#define PPC64_CLVSh(n)   \
-  andi.  %r0, %r5, (1<<(63-n))  ;\
+#define PPC64_CLVSh(n)\
+  andi.  0, 5, (1 PPC_LEFT_SHIFT(63-n))  ;\
 PPC64_CLVS_BOTTOM(n)
 
   PPC64_CLVSl(32)
@@ -276,7 +276,7 @@ PPC64_CLVS_BOTTOM(n)
 
 // load FP register
 #define PPC64_LF(n) \
-  lfd   %f##n, (PPC64_OFFS_FP + n * 16)(%r3)
+  lfd   n, (PPC64_OFFS_FP + n * 16)(3)
 
   // restore float registers
   PPC64_LF(0)
@@ -314,30 +314,30 @@ PPC64_CLVS_BOTTOM(n)
 
 #if defined(__ALTIVEC__)
   // restore vector registers if any are in use
-  ld%r5, PPC64_OFFS_VRSAVE(%r3)   // test VRsave
-  cmpwi %r5, 0
+  ld5, PPC64_OFFS_VRSAVE(3)   // test VRsave
+  cmpwi 5, 0
   beq   Lnovec
 
-  subi  %r4, %r1, 16
+  subi  4, 1, 16
   // r4 is now a 16-byte aligned pointer into the red zone
   // the _vectorScalarRegisters may not be 16-byte aligned
   // so copy via red zone temp buffer
 
 #define PPC64_CLV_UNALIGNED_BOTTOM(n)\
   beqLdone##n   ;\
-  ld %r0, (PPC64_OFFS_V + n * 16)(%r3)  ;\
-  std%r0, 0(%r4);\
-  ld %r0, (PPC64_OFFS_V + n * 16 + 8)(%r3)  ;\
-  std%r0, 8(%r4);\
-  lvx%v##n, 0, %r4  ;\
+  ld 0, (PPC64_OFFS_V + n * 16)(3)  ;\
+  std0, 0(4);\
+  ld 0, (PPC64_OFFS_V + n * 16 + 8)(3)  ;\
+  std0, 8(4);\
+  lvxn, 0, 4;\
 Ldone  ## n:
 
-#define PPC64_CLV_UNALIGNEDl(n)  \
-  andis. %r0, %r5, (1<<(15-n))  ;\
+#define PPC64_CLV_UNALIGNEDl(n) \
+  andis. 0, 5, (1 PPC_LEFT_SHIFT(15-n));\
 

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

[Dan Gohman via Phabricator via cfe-commits]

sunfish added inline comments.



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp:1279
+  if (const GlobalAddressSDNode *GA = dyn_cast(Op))
+return WebAssembly::isManagedAddressSpace(GA->getAddressSpace());
+

sbc100 wrote:
> sunfish wrote:
> > tlively wrote:
> > > tlively wrote:
> > > > Actually, should we enforce that these LLVM IR globals be thread_local, 
> > > > since the resulting Wasm globals will be thread_local? I don't know if 
> > > > that will affect any optimizations, but it seems like a more accurate 
> > > > modeling. If we do that, 
> > > > `CoalesceLocalsAndStripAtomics::stripThreadLocals` in 
> > > > WebAssemblyTargetMachine.cpp will have to be updated to not strip the 
> > > > thread locals corresponding to Wasm globals.
> > > I'd be fine handling this in a follow-up if you want to get this landed.
> > Note that this will be true of Worker-based threads, but not of the 
> > expected future "wasm native threads". I wonder if this means that 
> > clang/llvm will (eventually) need to be aware of this difference.
> Don't you think is very likely that even in "wasm native threads" we would 
> want to opt into sharing like we do with wasm memories?   That path would 
> seem better for compatibility with existing worker-based threading.  
> 
> Obviously once we do have shared wasm globals we will need to modify llvm's 
> assumptions, but for now I think it is a reasonable assumption/assertion that 
> wasm globals are TLS.
Yeah, I agree we'll likely want some way to opt into sharing. So the difference 
here is, worker-based threads won't have the option of sharing, so maybe 
requiring `thread_local` makes sense. But native threads could opt into 
sharing, so they could be `thread_local` or not.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

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

[PATCH] D101967: [Driver] Use x86-64 libc++ headers with -m32

[Roland McGrath via Phabricator via cfe-commits]

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

lgtm. I'm not sure what better to do that's especially cleaner, except actually 
just installing i386-fuchsia header subdirs.  The easy way to do that would be 
to just build it all for the target, but we don't have fuchsia libc for that 
target so it would be a new configuration for bare metal libc++ and we don't 
actually have anybody who really needs libc++ compiled for that target, only 
the headers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101967

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

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

[Sam Clegg via Phabricator via cfe-commits]

sbc100 added inline comments.



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp:1279
+  if (const GlobalAddressSDNode *GA = dyn_cast(Op))
+return WebAssembly::isManagedAddressSpace(GA->getAddressSpace());
+

sunfish wrote:
> tlively wrote:
> > tlively wrote:
> > > Actually, should we enforce that these LLVM IR globals be thread_local, 
> > > since the resulting Wasm globals will be thread_local? I don't know if 
> > > that will affect any optimizations, but it seems like a more accurate 
> > > modeling. If we do that, 
> > > `CoalesceLocalsAndStripAtomics::stripThreadLocals` in 
> > > WebAssemblyTargetMachine.cpp will have to be updated to not strip the 
> > > thread locals corresponding to Wasm globals.
> > I'd be fine handling this in a follow-up if you want to get this landed.
> Note that this will be true of Worker-based threads, but not of the expected 
> future "wasm native threads". I wonder if this means that clang/llvm will 
> (eventually) need to be aware of this difference.
Don't you think is very likely that even in "wasm native threads" we would want 
to opt into sharing like we do with wasm memories?   That path would seem 
better for compatibility with existing worker-based threading.  

Obviously once we do have shared wasm globals we will need to modify llvm's 
assumptions, but for now I think it is a reasonable assumption/assertion that 
wasm globals are TLS.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

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

[PATCH] D101873: [clang] Support clang -fpic -fno-semantic-interposition for AArch64

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

In D101873#2741903 , @peter.smith 
wrote:

> Looking at the gist I've got one concern for AArch64 and Arm. The ABI relies 
> on thunks which are only defined for symbols of type STT_FUNC. Changing 
> branches to STT_FUNC to STT_SECTION will break long range thunks on AArch64 
> and interworking for Arm (there is a possibility that the bottom bit for 
> STT_FUNC may get used in the future for AArch64 as well). This is solvable by 
> keeping the local label and setting STT_FUNC on it.

Ooh, I missed this.  Yes, we need the symbol attributes.  On 32-bit Arm, that 
includes a .thumb_func directive (MCStreamer::emitThumbFunc) in addition to the 
STT_FUNC attribute.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101873

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

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

[Thomas Lively via Phabricator via cfe-commits]

tlively added inline comments.



Comment at: llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h:39
+  // pointers are lowered to global.get / global.set or local.get / local.set,
+  // as appropriate.
+  WASM_ADDRESS_SPACE_MANAGED = 1

sunfish wrote:
> Sorry to throw more paint at the bikeshed here, but as someone who's only 
> following along at a high-level here, I found it confusing whether this is 
> talking about the wasm globals themselves, or the objects referred to by 
> reference values in the wasm globals. I think the feature here is talking 
> about the wasm globals themselves, but "managed" initially made me think it 
> might be talking about the objects they reference, which in a browser context 
> especially are "managed" in every sense of the word.
Fair point. What does everyone think about `INDEXED`, because it is used to 
represent objects given static indexes (in the WebAssembly sense) in the final 
binary.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

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

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

[Dan Gohman via Phabricator via cfe-commits]

sunfish added inline comments.



Comment at: llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.h:39
+  // pointers are lowered to global.get / global.set or local.get / local.set,
+  // as appropriate.
+  WASM_ADDRESS_SPACE_MANAGED = 1

Sorry to throw more paint at the bikeshed here, but as someone who's only 
following along at a high-level here, I found it confusing whether this is 
talking about the wasm globals themselves, or the objects referred to by 
reference values in the wasm globals. I think the feature here is talking about 
the wasm globals themselves, but "managed" initially made me think it might be 
talking about the objects they reference, which in a browser context especially 
are "managed" in every sense of the word.



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp:1279
+  if (const GlobalAddressSDNode *GA = dyn_cast(Op))
+return WebAssembly::isManagedAddressSpace(GA->getAddressSpace());
+

tlively wrote:
> tlively wrote:
> > Actually, should we enforce that these LLVM IR globals be thread_local, 
> > since the resulting Wasm globals will be thread_local? I don't know if that 
> > will affect any optimizations, but it seems like a more accurate modeling. 
> > If we do that, `CoalesceLocalsAndStripAtomics::stripThreadLocals` in 
> > WebAssemblyTargetMachine.cpp will have to be updated to not strip the 
> > thread locals corresponding to Wasm globals.
> I'd be fine handling this in a follow-up if you want to get this landed.
Note that this will be true of Worker-based threads, but not of the expected 
future "wasm native threads". I wonder if this means that clang/llvm will 
(eventually) need to be aware of this difference.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

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

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

[Thomas Lively via Phabricator via cfe-commits]

tlively added inline comments.



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp:1279
+  if (const GlobalAddressSDNode *GA = dyn_cast(Op))
+return WebAssembly::isManagedAddressSpace(GA->getAddressSpace());
+

tlively wrote:
> Actually, should we enforce that these LLVM IR globals be thread_local, since 
> the resulting Wasm globals will be thread_local? I don't know if that will 
> affect any optimizations, but it seems like a more accurate modeling. If we 
> do that, `CoalesceLocalsAndStripAtomics::stripThreadLocals` in 
> WebAssemblyTargetMachine.cpp will have to be updated to not strip the thread 
> locals corresponding to Wasm globals.
I'd be fine handling this in a follow-up if you want to get this landed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

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

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

[Thomas Lively via Phabricator via cfe-commits]

tlively added inline comments.



Comment at: llvm/lib/Target/WebAssembly/WebAssemblyISelLowering.cpp:1279
+  if (const GlobalAddressSDNode *GA = dyn_cast(Op))
+return WebAssembly::isManagedAddressSpace(GA->getAddressSpace());
+

Actually, should we enforce that these LLVM IR globals be thread_local, since 
the resulting Wasm globals will be thread_local? I don't know if that will 
affect any optimizations, but it seems like a more accurate modeling. If we do 
that, `CoalesceLocalsAndStripAtomics::stripThreadLocals` in 
WebAssemblyTargetMachine.cpp will have to be updated to not strip the thread 
locals corresponding to Wasm globals.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

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

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

[Sam Clegg via Phabricator via cfe-commits]

sbc100 accepted this revision.
sbc100 added a comment.

managed seems reasonable yes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

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

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

[Thomas Lively via Phabricator via cfe-commits]

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

This LGTM! `MANAGED` sounds like a good address space name to me. @sbc100, do 
you have any final comments?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101608

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

[PATCH] D101793: [clang][AST] Improve AST Reader/Writer memory footprint

[Wei Wang via Phabricator via cfe-commits]

weiwang added a comment.

In D101793#2735336 , @yaxunl wrote:

> Decls in Sema::DeclsToCheckForDeferredDiags is supposed to be unique. 
> Therefore the fact that '1,734,387,685 out of 1,734,404,000 elements are the 
> same' is surprising. Did this happen when you compile the source code and 
> write AST? What language was the source code? C++, OpenMP, or CUDA? What was 
> the decl that got duplicated? Thanks.

Sorry for the late reply.

This happens during a single compilation instance, and emits a module file from 
a big list of module map files and headers. I believe the code is pure C++. 
Because of the huge amount of duplications, the memory RSS shoots to over 50GB. 
I'll update once having more information.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101793

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

[PATCH] D33029: [clang-format] add option for dangling parenthesis

[Andrew Somerville via Phabricator via cfe-commits]

catskul added a comment.

It's all good for me. Sorry for slow responses. My time to work on this is few 
and far between. I'm happy if anyone picks it up or any energy put into this. 
Would love to see it land.


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

https://reviews.llvm.org/D33029

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

[PATCH] D101979: [WebAssembly] Fix argument types in SIMD narrowing intrinsics

[Thomas Lively 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 rGb198b9b8974b: [WebAssembly] Fix argument types in SIMD 
narrowing intrinsics (authored by tlively).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101979

Files:
  clang/lib/Headers/wasm_simd128.h
  clang/test/Headers/wasm.c


Index: clang/test/Headers/wasm.c
===
--- clang/test/Headers/wasm.c
+++ clang/test/Headers/wasm.c
@@ -1,7 +1,7 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --force-update
 // REQUIRES: webassembly-registered-target, asserts
 
-// RUN: %clang %s -O2 -emit-llvm -S -o - -target wasm32-unknown-unknown 
-msimd128 -Wcast-qual -Werror | FileCheck %s
+// RUN: %clang %s -O2 -emit-llvm -S -o - -target wasm32-unknown-unknown 
-msimd128 -Wcast-qual -fno-lax-vector-conversions -Werror | FileCheck %s
 
 #include 
 
Index: clang/lib/Headers/wasm_simd128.h
===
--- clang/lib/Headers/wasm_simd128.h
+++ clang/lib/Headers/wasm_simd128.h
@@ -1197,8 +1197,8 @@
 
 static __inline__ v128_t __DEFAULT_FN_ATTRS
 wasm_u8x16_narrow_i16x8(v128_t __a, v128_t __b) {
-  return (v128_t)__builtin_wasm_narrow_u_i8x16_i16x8((__u16x8)__a,
- (__u16x8)__b);
+  return (v128_t)__builtin_wasm_narrow_u_i8x16_i16x8((__i16x8)__a,
+ (__i16x8)__b);
 }
 
 static __inline__ v128_t __DEFAULT_FN_ATTRS
@@ -1209,8 +1209,8 @@
 
 static __inline__ v128_t __DEFAULT_FN_ATTRS
 wasm_u16x8_narrow_i32x4(v128_t __a, v128_t __b) {
-  return (v128_t)__builtin_wasm_narrow_u_i16x8_i32x4((__u32x4)__a,
- (__u32x4)__b);
+  return (v128_t)__builtin_wasm_narrow_u_i16x8_i32x4((__i32x4)__a,
+ (__i32x4)__b);
 }
 
 static __inline__ v128_t __DEFAULT_FN_ATTRS


Index: clang/test/Headers/wasm.c
===
--- clang/test/Headers/wasm.c
+++ clang/test/Headers/wasm.c
@@ -1,7 +1,7 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --force-update
 // REQUIRES: webassembly-registered-target, asserts
 
-// RUN: %clang %s -O2 -emit-llvm -S -o - -target wasm32-unknown-unknown -msimd128 -Wcast-qual -Werror | FileCheck %s
+// RUN: %clang %s -O2 -emit-llvm -S -o - -target wasm32-unknown-unknown -msimd128 -Wcast-qual -fno-lax-vector-conversions -Werror | FileCheck %s
 
 #include 
 
Index: clang/lib/Headers/wasm_simd128.h
===
--- clang/lib/Headers/wasm_simd128.h
+++ clang/lib/Headers/wasm_simd128.h
@@ -1197,8 +1197,8 @@
 
 static __inline__ v128_t __DEFAULT_FN_ATTRS
 wasm_u8x16_narrow_i16x8(v128_t __a, v128_t __b) {
-  return (v128_t)__builtin_wasm_narrow_u_i8x16_i16x8((__u16x8)__a,
- (__u16x8)__b);
+  return (v128_t)__builtin_wasm_narrow_u_i8x16_i16x8((__i16x8)__a,
+ (__i16x8)__b);
 }
 
 static __inline__ v128_t __DEFAULT_FN_ATTRS
@@ -1209,8 +1209,8 @@
 
 static __inline__ v128_t __DEFAULT_FN_ATTRS
 wasm_u16x8_narrow_i32x4(v128_t __a, v128_t __b) {
-  return (v128_t)__builtin_wasm_narrow_u_i16x8_i32x4((__u32x4)__a,
- (__u32x4)__b);
+  return (v128_t)__builtin_wasm_narrow_u_i16x8_i32x4((__i32x4)__a,
+ (__i32x4)__b);
 }
 
 static __inline__ v128_t __DEFAULT_FN_ATTRS
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] b198b9b - [WebAssembly] Fix argument types in SIMD narrowing intrinsics

[Thomas Lively via cfe-commits]

Author: Thomas Lively
Date: 2021-05-06T10:07:45-07:00
New Revision: b198b9b8974b19c9e8493f8d70c85ac54182597a

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

LOG: [WebAssembly] Fix argument types in SIMD narrowing intrinsics

The builtins were updated to take signed parameters in 627a52695537, but the
intrinsics that use those builtins were not updated as well. The intrinsic test
did not catch this sign mismatch because it is only reported as an error under
-fno-lax-vector-conversions.

This commit fixes the type mismatch and adds -fno-lax-vector-conversions to the
test to catch similar problems in the future.

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

Added: 


Modified: 
clang/lib/Headers/wasm_simd128.h
clang/test/Headers/wasm.c

Removed: 




diff  --git a/clang/lib/Headers/wasm_simd128.h 
b/clang/lib/Headers/wasm_simd128.h
index e6fb0496e514..cd11f096dd95 100644
--- a/clang/lib/Headers/wasm_simd128.h
+++ b/clang/lib/Headers/wasm_simd128.h
@@ -1197,8 +1197,8 @@ wasm_i8x16_narrow_i16x8(v128_t __a, v128_t __b) {
 
 static __inline__ v128_t __DEFAULT_FN_ATTRS
 wasm_u8x16_narrow_i16x8(v128_t __a, v128_t __b) {
-  return (v128_t)__builtin_wasm_narrow_u_i8x16_i16x8((__u16x8)__a,
- (__u16x8)__b);
+  return (v128_t)__builtin_wasm_narrow_u_i8x16_i16x8((__i16x8)__a,
+ (__i16x8)__b);
 }
 
 static __inline__ v128_t __DEFAULT_FN_ATTRS
@@ -1209,8 +1209,8 @@ wasm_i16x8_narrow_i32x4(v128_t __a, v128_t __b) {
 
 static __inline__ v128_t __DEFAULT_FN_ATTRS
 wasm_u16x8_narrow_i32x4(v128_t __a, v128_t __b) {
-  return (v128_t)__builtin_wasm_narrow_u_i16x8_i32x4((__u32x4)__a,
- (__u32x4)__b);
+  return (v128_t)__builtin_wasm_narrow_u_i16x8_i32x4((__i32x4)__a,
+ (__i32x4)__b);
 }
 
 static __inline__ v128_t __DEFAULT_FN_ATTRS

diff  --git a/clang/test/Headers/wasm.c b/clang/test/Headers/wasm.c
index f5076ae3af30..409da99d43a7 100644
--- a/clang/test/Headers/wasm.c
+++ b/clang/test/Headers/wasm.c
@@ -1,7 +1,7 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --force-update
 // REQUIRES: webassembly-registered-target, asserts
 
-// RUN: %clang %s -O2 -emit-llvm -S -o - -target wasm32-unknown-unknown 
-msimd128 -Wcast-qual -Werror | FileCheck %s
+// RUN: %clang %s -O2 -emit-llvm -S -o - -target wasm32-unknown-unknown 
-msimd128 -Wcast-qual -fno-lax-vector-conversions -Werror | FileCheck %s
 
 #include 
 



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

[PATCH] D102001: [Index] Ignore nullptr decls for indexing

[Alex Hoppen via Phabricator via cfe-commits]

ahoppen created this revision.
Herald added a subscriber: arphaman.
ahoppen requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

We can end up with a call to `indexTopLevelDecl(D)` with `D == nullptr` in 
non-assert builds e.g. when indexing a module in `indexModule` and

- `ASTReader::GetDecl` returns `nullptr` if `Index >= DeclsLoaded.size()`, thus 
returning `nullptr`

> `ModuleDeclIterator::operator*` returns `nullptr`
===

> we call `IndexCtx.indexTopLevelDecl` with `nullptr`
=

Be resilient and just ignore the `nullptr` decls during indexing.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102001

Files:
  clang/lib/Index/IndexDecl.cpp


Index: clang/lib/Index/IndexDecl.cpp
===
--- clang/lib/Index/IndexDecl.cpp
+++ clang/lib/Index/IndexDecl.cpp
@@ -759,7 +759,7 @@
 }
 
 bool IndexingContext::indexTopLevelDecl(const Decl *D) {
-  if (D->getLocation().isInvalid())
+  if (!D || D->getLocation().isInvalid())
 return true;
 
   if (isa(D))


Index: clang/lib/Index/IndexDecl.cpp
===
--- clang/lib/Index/IndexDecl.cpp
+++ clang/lib/Index/IndexDecl.cpp
@@ -759,7 +759,7 @@
 }
 
 bool IndexingContext::indexTopLevelDecl(const Decl *D) {
-  if (D->getLocation().isInvalid())
+  if (!D || D->getLocation().isInvalid())
 return true;
 
   if (isa(D))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D93525: [clang-offload-bundler] Add unbundling of archives containing bundled object files into device specific archives

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

Can we split this patch now and make progress?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93525

___
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

[Giorgis Georgakoudis via Phabricator via cfe-commits]

ggeorgakoudis updated this revision to Diff 343438.
ggeorgakoudis added a comment.

Update regex for removing old checklines


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,133 @@
+#!/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):
+input_lines = ''
+print('Processing file ', filename, '...')
+with open(filename, 'r') as f:
+output_lines = ''
+cnt = 1
+check_prefix_set = {'CHECK'}
+for line in f:
+input_lines += line
+# 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):
+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:
+# Done, return 1.
+return 1
+else:
+with open(filename, 'w') as f:
+  f.write(input_lines)
+# Failed, return 0.
+return 0
+
+def main():
+parser = 

[PATCH] D101259: [clang-tidy] Fix cppcoreguidelines-pro-type-vararg false positives with __builtin_ms_va_list

[Douglas Yung via Phabricator via cfe-commits]

dyung added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-type-vararg-ms.cpp:7
+
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-type-vararg %t
+

jubnzv wrote:
> probinson wrote:
> > probinson wrote:
> > > TWeaver wrote:
> > > > njames93 wrote:
> > > > > TWeaver wrote:
> > > > > > Is the missing FileCheck call here on purpose? it seems to me that 
> > > > > > the CHECK-MESSAGES aren't actually being verified by this test?
> > > > > > 
> > > > > > unless I'm missing something.
> > > > > > 
> > > > > > TIA
> > > > > `check_clang_tidy` invokes FileCheck. Does something else make you 
> > > > > think these labels are being tested?? 
> > > > whilst investigating an unrelated issue on our internal branch, I tried 
> > > > editting the check lines in this test and wasn't able to create a 
> > > > failure. but if I add
> > > > 
> > > > '| FileCheck %s -check-prefix=CHECK-MESSAGES' to the run line and then 
> > > > edit the checks, I can induce an error.
> > > > 
> > > > This could be an issue on our internal branch though... :shrug: thanks 
> > > > for the speedy reply.
> > > I'm suspicious that our downstream problem is because the test is 
> > > assuming that the target is Windows, just because the host is.  That's 
> > > not true for us (or anyone with a Windows-hosted cross-compiler).  Does 
> > > clang-tidy accept a target triple?
> > Or possibly the test could be set up to require a Windows target, rather 
> > than a Windows host.
> I'm not sure that there is a way to pass a target triple to `clang-tidy`.
> 
> But `llvm-lit` should not run this test on non-Windows host because of 
> `REQUIRES: system-windows`. For example, when I trying to run it on my Debian 
> machine (`llvm-lit 
> clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-pro-type-vararg-ms.cpp
>  -v`) I got the following result:
> 
> ```
> -- Testing: 1 tests, 1 workers --
> UNSUPPORTED: Clang Tools :: 
> clang-tidy/checkers/cppcoreguidelines-pro-type-vararg-ms.cpp (1 of 1)
> 
> Testing Time: 0.01s
>   Unsupported: 1
> ```
Our problem is the opposite, we are running a cross compiler hosted on Windows, 
but targeting a non-Windows platform (PS4 in our case).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101259

___
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

[Giorgis Georgakoudis via Phabricator via cfe-commits]

ggeorgakoudis added a comment.

In D101849#2741980 , @DavidSpickett 
wrote:

> I've required X86 target for this test to get our bots green again.

Thanks David for the workaround. I agree with Johannes's comments below. It 
looks like a bug.


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] D101960: [openmp] Drop requirement on library path environment variables

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

Yes. Libomp and libomptarget are in the same directory, so the rpath/runpath 
change catches both of them. Libomptarget then needs to find the plugins to 
load, either through library path or something equivalent to the above.




Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:648
 
+void tools::addOpenMPRuntimeSpecificRPath(const ToolChain ,
+  const ArgList ,

lebedev.ri wrote:
> JonChesterfield wrote:
> > Similar to other functions in this file, derived from aomp (by deleting 
> > some stuff for finding a debug version of the library)
> > 
> > I can make my peace with runpath instead if people are keen to override 
> > this with LD_LIBRARY_PATH. The rest of clang's toolchains wire things up 
> > with rpath but that doesn't mean we have to make the same choice here.
> I think it would be a shame if this would be the only thing
> that *doesn't* support being overriden with `LD_LIBRARY_PATH`.
> I'm not sure about `libomptarget`, but it i think it would be good to keep 
> such possibility for `libomp`.
The search order is 'rpath' then 'LD_LIBRARY_PATH' then 'runpath'. Presently we 
set no default at all and require the user to set LD_LIBRARY_PATH or manually 
link the right library. So using runpath here is backwards compatible, in that 
all the scripts out there that use LD_LIBRARY_PATH will continue to work. That 
may force our hand here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101960

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

[PATCH] D101952: [OpenMP] Fix non-determinism in clang copyin codegen

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D101952#2742237 , @DavidSpickett 
wrote:

> Thanks! I'll test our Arm build and revert the requires once I've confirmed 
> it passes.

This is not the fix you need.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101952

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

[PATCH] D101952: [OpenMP] Fix non-determinism in clang copyin codegen

[David Spickett via Phabricator via cfe-commits]

DavidSpickett added a comment.

Thanks! I'll test our Arm build and revert the requires once I've confirmed it 
passes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101952

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

[PATCH] D101785: [clangd][ObjC] Highlight Objc Ivar refs

[David Goldman via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG159dd447fe98: [clangd][ObjC] Highlight Objc Ivar refs 
(authored by dgoldman).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101785

Files:
  clang-tools-extra/clangd/FindTarget.cpp
  clang-tools-extra/clangd/unittests/FindTargetTests.cpp
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -687,6 +687,21 @@
 @implementation $Class[[Foo]]($Namespace_decl[[Bar]])
 @end
   )cpp",
+  R"cpp(
+// ObjC: Properties and Ivars.
+@interface $Class_decl[[Foo]] {
+  int $Field_decl[[_someProperty]];
+}
+@property(nonatomic, assign) int $Field_decl[[someProperty]];
+@end
+@implementation $Class_decl[[Foo]]
+@synthesize someProperty = _someProperty;
+- (int)$Method_decl[[doSomething]] {
+  self.$Field[[someProperty]] = self.$Field[[someProperty]] + 1;
+  self->$Field[[_someProperty]] = $Field[[_someProperty]] + 1;
+}
+@end
+  )cpp",
   // Member imported from dependent base
   R"cpp(
 template  struct $Class_decl[[Base]] {
Index: clang-tools-extra/clangd/unittests/FindTargetTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindTargetTests.cpp
+++ clang-tools-extra/clangd/unittests/FindTargetTests.cpp
@@ -1607,6 +1607,21 @@
"5: targets = {t}, decl\n"
"6: targets = {t}\n"
"7: targets = {}\n"},
+   // Objective-C: instance variables
+   {
+   R"cpp(
+@interface I {
+@public
+  I *_z;
+}
+@end
+I *f;
+void foo() {
+  $0^f->$1^_z = 0;
+}
+  )cpp",
+   "0: targets = {f}\n"
+   "1: targets = {I::_z}\n"},
// Objective-C: properties
{
R"cpp(
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -780,6 +780,13 @@
   explicitReferenceTargets(DynTypedNode::create(*E), {}, Resolver)});
 }
 
+void VisitObjCIvarRefExpr(const ObjCIvarRefExpr *OIRE) {
+  Refs.push_back(ReferenceLoc{NestedNameSpecifierLoc(),
+  OIRE->getLocation(),
+  /*IsDecl=*/false,
+  {OIRE->getDecl()}});
+}
+
 void VisitObjCMessageExpr(const ObjCMessageExpr *E) {
   // The name may have several tokens, we can only report the first.
   Refs.push_back(ReferenceLoc{NestedNameSpecifierLoc(),


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -687,6 +687,21 @@
 @implementation $Class[[Foo]]($Namespace_decl[[Bar]])
 @end
   )cpp",
+  R"cpp(
+// ObjC: Properties and Ivars.
+@interface $Class_decl[[Foo]] {
+  int $Field_decl[[_someProperty]];
+}
+@property(nonatomic, assign) int $Field_decl[[someProperty]];
+@end
+@implementation $Class_decl[[Foo]]
+@synthesize someProperty = _someProperty;
+- (int)$Method_decl[[doSomething]] {
+  self.$Field[[someProperty]] = self.$Field[[someProperty]] + 1;
+  self->$Field[[_someProperty]] = $Field[[_someProperty]] + 1;
+}
+@end
+  )cpp",
   // Member imported from dependent base
   R"cpp(
 template  struct $Class_decl[[Base]] {
Index: clang-tools-extra/clangd/unittests/FindTargetTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindTargetTests.cpp
+++ clang-tools-extra/clangd/unittests/FindTargetTests.cpp
@@ -1607,6 +1607,21 @@
"5: targets = {t}, decl\n"
"6: targets = {t}\n"
"7: targets = {}\n"},
+   // Objective-C: instance variables
+   {
+   R"cpp(
+@interface I {
+@public
+  I *_z;
+}
+@end
+I *f;
+void foo() {
+  $0^f->$1^_z = 0;
+}
+  )cpp",
+   "0: targets = {f}\n"
+   "1: targets = {I::_z}\n"},
// Objective-C: properties
{
   

[clang-tools-extra] 159dd44 - [clangd][ObjC] Highlight Objc Ivar refs

[David Goldman via cfe-commits]

Author: David Goldman
Date: 2021-05-06T11:41:49-04:00
New Revision: 159dd447fe98f558879343d660b5bfe90779609f

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

LOG: [clangd][ObjC] Highlight Objc Ivar refs

Treat them just like we do for properties - as a `property` semantic
token although ideally we could differentiate the two.

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

Added: 


Modified: 
clang-tools-extra/clangd/FindTarget.cpp
clang-tools-extra/clangd/unittests/FindTargetTests.cpp
clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/FindTarget.cpp 
b/clang-tools-extra/clangd/FindTarget.cpp
index d4cb2fe79111..4789d28ecf48 100644
--- a/clang-tools-extra/clangd/FindTarget.cpp
+++ b/clang-tools-extra/clangd/FindTarget.cpp
@@ -780,6 +780,13 @@ llvm::SmallVector refInStmt(const Stmt *S,
   explicitReferenceTargets(DynTypedNode::create(*E), {}, Resolver)});
 }
 
+void VisitObjCIvarRefExpr(const ObjCIvarRefExpr *OIRE) {
+  Refs.push_back(ReferenceLoc{NestedNameSpecifierLoc(),
+  OIRE->getLocation(),
+  /*IsDecl=*/false,
+  {OIRE->getDecl()}});
+}
+
 void VisitObjCMessageExpr(const ObjCMessageExpr *E) {
   // The name may have several tokens, we can only report the first.
   Refs.push_back(ReferenceLoc{NestedNameSpecifierLoc(),

diff  --git a/clang-tools-extra/clangd/unittests/FindTargetTests.cpp 
b/clang-tools-extra/clangd/unittests/FindTargetTests.cpp
index f32081ac472c..beca7c292583 100644
--- a/clang-tools-extra/clangd/unittests/FindTargetTests.cpp
+++ b/clang-tools-extra/clangd/unittests/FindTargetTests.cpp
@@ -1607,6 +1607,21 @@ TEST_F(FindExplicitReferencesTest, All) {
"5: targets = {t}, decl\n"
"6: targets = {t}\n"
"7: targets = {}\n"},
+   // Objective-C: instance variables
+   {
+   R"cpp(
+@interface I {
+@public
+  I *_z;
+}
+@end
+I *f;
+void foo() {
+  $0^f->$1^_z = 0;
+}
+  )cpp",
+   "0: targets = {f}\n"
+   "1: targets = {I::_z}\n"},
// Objective-C: properties
{
R"cpp(

diff  --git a/clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp 
b/clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
index 815ef92c932e..a2e8f797ad28 100644
--- a/clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ b/clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -687,6 +687,21 @@ sizeof...($TemplateParameter[[Elements]]);
 @implementation $Class[[Foo]]($Namespace_decl[[Bar]])
 @end
   )cpp",
+  R"cpp(
+// ObjC: Properties and Ivars.
+@interface $Class_decl[[Foo]] {
+  int $Field_decl[[_someProperty]];
+}
+@property(nonatomic, assign) int $Field_decl[[someProperty]];
+@end
+@implementation $Class_decl[[Foo]]
+@synthesize someProperty = _someProperty;
+- (int)$Method_decl[[doSomething]] {
+  self.$Field[[someProperty]] = self.$Field[[someProperty]] + 1;
+  self->$Field[[_someProperty]] = $Field[[_someProperty]] + 1;
+}
+@end
+  )cpp",
   // Member imported from dependent base
   R"cpp(
 template  struct $Class_decl[[Base]] {



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

[PATCH] D101843: [OpenCL] Add clang extension for bitfields

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:1748
+With this extension it is possible to enable bitfields in structs
+or unions using regular OpenCL extension pragma mechanism detailed in
+`the OpenCL Extension Specification, section 1.2





Comment at: clang/lib/Sema/SemaDecl.cpp:16798
 }
 // OpenCL v1.2 s6.9.c: bitfields are not supported.
+if (BitWidth && !getOpenCLOptions().isAvailableOption(





Comment at: clang/test/SemaOpenCL/unsupported.cl:11
+#ifndef BITFIELDS_EXT
+// expected-error@-2 {{bit-fields are not supported in OpenCL}}
+#endif

The extension has "bitfields" in the name but most diagnostics (including this 
one) spell it as "bit-fields".  I wonder what the least surprising name would 
be?  It seems Clang tends to use the hyphenated form in diagnostics and the 
non-hyphenated form in e.g. option names (e.g. `fsigned-bitfields`), so using 
the non-hyphenated form in the extension name is probably fine.


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

https://reviews.llvm.org/D101843

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

[PATCH] D101976: [OpenMP] Unified entry point for SPMD & generic kernels in the device RTL

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D101976#2742166 , @JonChesterfield 
wrote:

> What are the required semantics of the barrier operations? Amdgcn builds them 
> on shared memory, so probably needs a change to the corresponding target_impl 
> to match

I have *not* tested AMDGCN but I was not expecting a problem. The semantics I 
need here is: 
 warp N, thread 0 hits a barrier instruction I0
 warp N, threads 1-31 hit  a barrier instruction I1
 the entire warp synchronizes and moves on.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101976

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

[PATCH] D101976: [OpenMP] Unified entry point for SPMD & generic kernels in the device RTL

[Jon Chesterfield via Phabricator via cfe-commits]

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

What are the required semantics of the barrier operations? Amdgcn builds them 
on shared memory, so probably needs a change to the corresponding target_impl 
to match


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101976

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

[PATCH] D101236: [ASTImporter] Import definitions required for layout of [[no_unique_address]] from LLDB

[Raphael Isemann via Phabricator via cfe-commits]

teemperor added a comment.

Just to be clear, I am not sure when/if D101950 
 is ready. It's mostly blocked by me not 
having the time to work on it, so depending how my schedule is this might land 
soon or far in the future. Just linked it here as this (temporary) workaround 
would be on the list of things I would revert when D101950 
 lands. But in the meantime I'm ok with this 
workaround patch as I said above.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101236

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

[PATCH] D101236: [ASTImporter] Import definitions required for layout of [[no_unique_address]] from LLDB

[Jan Kratochvil via Phabricator via cfe-commits]

jankratochvil abandoned this revision.
jankratochvil added a comment.

IIUC it will get replaced by D101950 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101236

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

[PATCH] D101976: [OpenMP] Unified entry point for SPMD & generic kernels in the device RTL

[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




Comment at: openmp/libomptarget/deviceRTLs/interface.h:421
+ bool UseGenericStateMachine,
+   bool RequiresFullRuntime);
+EXTERN void __kmpc_target_deinit(ident_t *Ident, bool IsSPMD,

Formatting


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101976

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

[PATCH] D100976: [OpenCL] Simplify use of C11 atomic types

[Marco Antognini via Phabricator via cfe-commits]

mantognini added a comment.

> This change removes the requirement on pragma when atomic types from the 
> extensions are supported because the behavior is not conformant. With this 
> change, the developers can use atomic types from the extensions if they are 
> supported without enabling the pragma because disabling the pragma doesn't do 
> anything useful but only prevents the use of already available identifiers 
> for types and issues extra diagnostics. This makes semantics consistent with 
> the atomic functions that are also available when the extension is supported 
> without any need for the pragma.

That sounds reasonable to me. Decreasing code complexity and reducing the 
"surprise-factor" for users by being more consistent is good indeed.




Comment at: clang/test/Parser/opencl-atomics-cl20.cl:12
 void atomic_types_test() {
-// OpenCL v2.0 s6.13.11.6 defines supported atomic types.
+  // OpenCL v2.0 s6.13.11.6 defines supported atomic types.
+

nit: there are a few tabs in this files you may want to remove before 
submitting.



Comment at: clang/test/Parser/opencl-atomics-cl20.cl:34
   atomic_ptrdiff_t pd;
-// OpenCL v2.0 s6.13.11.8, _Atomic type specifier and _Atomic type qualifier
-// are not supported by OpenCL.
-  _Atomic int i; // expected-error {{use of undeclared identifier '_Atomic'}}
-}
-#ifndef CL20
-// expected-error@-16 {{use of undeclared identifier 'atomic_int'}}
-// expected-error@-16 {{use of undeclared identifier 'atomic_uint'}}
-// expected-error@-16 {{use of undeclared identifier 'atomic_long'}}
-// expected-error@-16 {{use of undeclared identifier 'atomic_ulong'}}
-// expected-error@-16 {{use of undeclared identifier 'atomic_float'}}
-// expected-error@-16 {{use of undeclared identifier 'atomic_double'}}
-// expected-error@-16 {{use of undeclared identifier 'atomic_flag'}}
-// expected-error@-16 {{use of undeclared identifier 'atomic_intptr_t'}}
-// expected-error@-16 {{use of undeclared identifier 'atomic_uintptr_t'}}
-// expected-error@-16 {{use of undeclared identifier 'atomic_size_t'}}
-// expected-error@-16 {{use of undeclared identifier 'atomic_ptrdiff_t'}}
-#elif !EXT
-// expected-error@-26 {{use of type 'atomic_long' (aka '_Atomic(long)') 
requires cl_khr_int64_base_atomics support}}
-// expected-error@-27 {{use of type 'atomic_long' (aka '_Atomic(long)') 
requires cl_khr_int64_extended_atomics support}}
-// expected-error@-27 {{use of type 'atomic_ulong' (aka '_Atomic(unsigned 
long)') requires cl_khr_int64_base_atomics support}}
-// expected-error@-28 {{use of type 'atomic_ulong' (aka '_Atomic(unsigned 
long)') requires cl_khr_int64_extended_atomics support}}
-// expected-error@-27 {{use of type 'atomic_double' (aka '_Atomic(double)') 
requires cl_khr_int64_base_atomics support}}
-// expected-error@-28 {{use of type 'atomic_double' (aka '_Atomic(double)') 
requires cl_khr_int64_extended_atomics support}}
-#if __LP64__
-// expected-error-re@-28 {{use of type 'atomic_intptr_t' (aka 
'_Atomic({{.+}})') requires cl_khr_int64_base_atomics support}}
-// expected-error-re@-29 {{use of type 'atomic_intptr_t' (aka 
'_Atomic({{.+}})') requires cl_khr_int64_extended_atomics support}}
-// expected-error-re@-29 {{use of type 'atomic_uintptr_t' (aka 
'_Atomic({{.+}})') requires cl_khr_int64_base_atomics support}}
-// expected-error-re@-30 {{use of type 'atomic_uintptr_t' (aka 
'_Atomic({{.+}})') requires cl_khr_int64_extended_atomics support}}
-// expected-error-re@-30 {{use of type 'atomic_size_t' (aka '_Atomic({{.+}})') 
requires cl_khr_int64_base_atomics support}}
-// expected-error-re@-31 {{use of type 'atomic_size_t' (aka '_Atomic({{.+}})') 
requires cl_khr_int64_extended_atomics support}}
-// expected-error-re@-31 {{use of type 'atomic_ptrdiff_t' (aka 
'_Atomic({{.+}})') requires cl_khr_int64_base_atomics support}}
-// expected-error-re@-32 {{use of type 'atomic_ptrdiff_t' (aka 
'_Atomic({{.+}})') requires cl_khr_int64_extended_atomics support}}
+#if !defined(LANG_VER_OK) || !defined(cl_khr_int64_base_atomics)
+// expected-error@-8 {{use of undeclared identifier 'atomic_long'}}

Shouldn't that be 
```
!(defined(cl_khr_int64_extended_atomics) && defined(cl_khr_int64_base_atomics))
```
for atomic_long and atomic_ulong, and covering double for atomic_double?

Alternatively, if the goal isn't to have 100% coverage in this test of all 
these variations (which would be fine I believe), then a comment could clarify 
the intent.


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

https://reviews.llvm.org/D100976

___
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

[Anton Zabaznov via Phabricator via cfe-commits]

azabaznov updated this revision to Diff 343417.
azabaznov added a comment.

Rebased to use `::validateOpenCLTarget`. Decided to use explicit simulatneous 
extensions/feature disabling in command line due to API spec limitations:

clGetDeviceInfo: Will not describe support for the cl_khr_3d_image_writes 
extension if device does not support writing to 3D image objects.

Will update docs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96524

Files:
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CodeGenOpenCL/printf.cl
  clang/test/Misc/opencl-c-3.0.incorrect_options.cl
  clang/test/SemaOpenCL/extensions.cl
  clang/test/SemaOpenCL/fp64-fp16-options.cl

Index: clang/test/SemaOpenCL/fp64-fp16-options.cl
===
--- clang/test/SemaOpenCL/fp64-fp16-options.cl
+++ clang/test/SemaOpenCL/fp64-fp16-options.cl
@@ -4,6 +4,7 @@
 
 // Test with a target not supporting fp64.
 // RUN: %clang_cc1 %s -triple r600-unknown-unknown -target-cpu r600 -verify -pedantic -fsyntax-only -DNOFP64 -DNOFP16
+// RUN: %clang_cc1 -cl-std=CL3.0 %s -triple r600-unknown-unknown -target-cpu r600 -verify -pedantic -fsyntax-only -DNOFP64 -DNOFP16
 
 // Test with some extensions enabled or disabled by cmd-line args
 //
@@ -15,12 +16,18 @@
 // RUN: %clang_cc1 %s -triple r600-unknown-unknown -target-cpu r600 -verify -pedantic -fsyntax-only -cl-ext=+all
 // RUN: %clang_cc1 %s -triple r600-unknown-unknown -target-cpu r600 -verify -pedantic -fsyntax-only -cl-ext=+all,-cl_khr_fp64 -DNOFP64
 // RUN: %clang_cc1 %s -triple r600-unknown-unknown -target-cpu r600 -verify -pedantic -fsyntax-only -cl-ext=-all,+cl_khr_fp64 -DNOFP16
+// RUN: %clang_cc1 -cl-std=CL3.0 %s -triple spir-unknown-unknown -verify -pedantic -fsyntax-only -cl-ext=-all -DNOFP64 -DNOFP16
+// RUN: %clang_cc1 -cl-std=CL3.0 %s -triple r600-unknown-unknown -target-cpu r600 -verify -pedantic -fsyntax-only -cl-ext=+all -DFP64
+// RUN: %clang_cc1 -cl-std=CL3.0 %s -triple r600-unknown-unknown -target-cpu r600 -verify -pedantic -fsyntax-only -cl-ext=+all,-__opencl_c_fp64,-cl_khr_fp64 -DNOFP64
 //
 // Concatenating
 // RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -pedantic -fsyntax-only -cl-ext=-cl_khr_fp64 -cl-ext=+cl_khr_fp64
 // RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -pedantic -fsyntax-only -cl-ext=-cl_khr_fp64,+cl_khr_fp64
 // RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -pedantic -fsyntax-only -cl-ext=-all -cl-ext=+cl_khr_fp64 -cl-ext=+cl_khr_fp16 -cl-ext=-cl_khr_fp64 -DNOFP64
 // RUN: %clang_cc1 %s -triple spir-unknown-unknown -verify -pedantic -fsyntax-only -cl-ext=-all -cl-ext=+cl_khr_fp64,-cl_khr_fp64,+cl_khr_fp16 -DNOFP64
+// RUN: %clang_cc1 -cl-std=CL3.0 %s -triple spir-unknown-unknown -verify -pedantic -fsyntax-only -cl-ext=-__opencl_c_fp64,-cl_khr_fp64 -cl-ext=+__opencl_c_fp64,+cl_khr_fp64 -DFP64
+// RUN: %clang_cc1 -cl-std=CL3.0 %s -triple spir-unknown-unknown -verify -pedantic -fsyntax-only -cl-ext=-__opencl_c_fp64,+__opencl_c_fp64,+cl_khr_fp64 -DFP64
+// RUN: %clang_cc1 -cl-std=CL3.0 %s -triple spir-unknown-unknown -verify -pedantic -fsyntax-only -cl-ext=-__opencl_c_fp64,-cl_khr_fp64 -DNOFP64
 
 // Test with -finclude-default-header, which includes opencl-c.h. opencl-c.h
 // disables all extensions by default, but supported core extensions for a
@@ -72,20 +79,33 @@
 void f2(void) {
   double d;
 #ifdef NOFP64
-// expected-error@-2{{use of type 'double' requires cl_khr_fp64 support}}
+#if (defined(__OPENCL_C_VERSION__) && __OPENCL_C_VERSION__ == 300)
+// expected-error@-3{{use of type 'double' requires __opencl_c_fp64 support}}
+#else
+// expected-error@-5{{use of type 'double' requires cl_khr_fp64 support}}
+#endif
 #endif
 
   typedef double double4 __attribute__((ext_vector_type(4)));
   double4 d4 = {0.0f, 2.0f, 3.0f, 1.0f};
 #ifdef NOFP64
-// expected-error@-3 {{use of type 'double' requires cl_khr_fp64 support}}
-// expected-error@-3 {{use of type 'double4' (vector of 4 'double' values) requires cl_khr_fp64 support}}
+#if (defined(__OPENCL_C_VERSION__) && __OPENCL_C_VERSION__ == 300)
+// expected-error@-4 {{use of type 'double' requires __opencl_c_fp64 support}}
+// expected-error@-4 {{use of type 'double4' (vector of 4 'double' values) requires __opencl_c_fp64 support}}
+#else
+// expected-error@-7 {{use of type 'double' requires cl_khr_fp64 support}}
+// expected-error@-7 {{use of type 'double4' (vector of 4 'double' values) requires cl_khr_fp64 support}}
+#endif
 #endif
 
   (void) 1.0;
 
 #ifdef NOFP64
-// expected-warning@-3{{double precision constant requires cl_khr_fp64, casting to single precision}}
+#if 

[PATCH] D101785: [clangd][ObjC] Highlight Objc Ivar refs

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101785

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

[PATCH] D101921: [MC] Make it possible for targets to define their own MCObjectFileInfo

[Philipp Krones via Phabricator via cfe-commits]

flip1995 created this revision.
Herald added subscribers: dcaballe, cota, teijeong, dexonsmith, rdzhabarov, 
tatianashp, msifontes, jurahul, Kayjukh, grosul1, Joonsoo, liufengdb, aartbik, 
lucyrfox, mgester, arpith-jacob, csigg, antiagainst, shauheen, rriddle, 
mehdi_amini, rupprecht, gbedwell, hiraditya.
Herald added a reviewer: andreadb.
Herald added a reviewer: jhenderson.
Herald added a reviewer: MaskRay.
flip1995 updated this revision to Diff 343324.
flip1995 edited the summary of this revision.
flip1995 added a comment.
Herald added subscribers: luismarques, s.egerton, PkmX, simoncook.
flip1995 published this revision for review.
Herald added subscribers: llvm-commits, cfe-commits, stephenneuendorffer, 
nicolasvasilache.
Herald added a reviewer: herhut.
Herald added projects: clang, MLIR, LLVM.

rebased


This MCObjectFileInfo is then used to determine things like section
alignment.

For example, this commit removes the hard-coded 4-byte alignment for
text sections and uses the alignment defined by the target specific
MCObjectFileInfo.

This is a follow up to https://reviews.llvm.org/D101462 and prepares for the
RISCV backend defining the text section alignment depending on the enabled
extensions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D101921

Files:
  clang/lib/Parse/ParseStmtAsm.cpp
  clang/tools/driver/cc1as_main.cpp
  llvm/include/llvm/MC/MCContext.h
  llvm/include/llvm/MC/MCObjectFileInfo.h
  llvm/include/llvm/Support/TargetRegistry.h
  llvm/lib/DWARFLinker/DWARFStreamer.cpp
  llvm/lib/MC/MCELFStreamer.cpp
  llvm/lib/MC/MCObjectFileInfo.cpp
  llvm/lib/Object/ModuleSymbolTable.cpp
  llvm/tools/llvm-dwp/llvm-dwp.cpp
  llvm/tools/llvm-exegesis/lib/SnippetFile.cpp
  llvm/tools/llvm-mc-assemble-fuzzer/llvm-mc-assemble-fuzzer.cpp
  llvm/tools/llvm-mc/llvm-mc.cpp
  llvm/tools/llvm-mca/llvm-mca.cpp
  llvm/tools/llvm-ml/llvm-ml.cpp
  llvm/tools/llvm-objdump/llvm-objdump.cpp
  llvm/tools/llvm-profgen/ProfiledBinary.cpp
  llvm/unittests/MC/SystemZ/SystemZAsmLexerTest.cpp
  mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp

Index: mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp
===
--- mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp
+++ mlir/lib/Dialect/GPU/Transforms/SerializeToHsaco.cpp
@@ -168,9 +168,11 @@
   target->createMCAsmInfo(*mri, this->triple, mcOptions));
   mai->setRelaxELFRelocations(true);
 
-  llvm::MCObjectFileInfo mofi;
-  llvm::MCContext ctx(triple, mai.get(), mri.get(), , , );
-  mofi.initMCObjectFileInfo(ctx, /*PIC=*/false, /*LargeCodeModel=*/false);
+  llvm::MCContext ctx(triple, mai.get(), mri.get(), /*MOFI=*/nullptr, ,
+  );
+  std::unique_ptr mofi(target->createMCObjectFileInfo(
+  ctx, /*PIC=*/false, /*LargeCodeModel=*/false));
+  ctx.setObjectFileInfo(mofi.get());
 
   SmallString<128> cwd;
   if (!llvm::sys::fs::current_path(cwd))
Index: llvm/unittests/MC/SystemZ/SystemZAsmLexerTest.cpp
===
--- llvm/unittests/MC/SystemZ/SystemZAsmLexerTest.cpp
+++ llvm/unittests/MC/SystemZ/SystemZAsmLexerTest.cpp
@@ -62,6 +62,7 @@
   std::unique_ptr MRI;
   std::unique_ptr MUPMAI;
   std::unique_ptr MII;
+  std::unique_ptr MOFI;
   std::unique_ptr Str;
   std::unique_ptr Parser;
   std::unique_ptr Ctx;
@@ -74,7 +75,6 @@
   const Target *TheTarget;
 
   const MCTargetOptions MCOptions;
-  MCObjectFileInfo MOFI;
 
   SystemZAsmLexerTest() {
 // We will use the SystemZ triple, because of missing
@@ -112,9 +112,11 @@
 SrcMgr.AddNewSourceBuffer(std::move(Buffer), SMLoc());
 EXPECT_EQ(Buffer, nullptr);
 
-Ctx.reset(new MCContext(Triple, MUPMAI.get(), MRI.get(), , STI.get(),
-, ));
-MOFI.initMCObjectFileInfo(*Ctx, /*PIC=*/false, /*LargeCodeModel=*/false);
+Ctx.reset(new MCContext(Triple, MUPMAI.get(), MRI.get(), /*MOFI=*/nullptr,
+STI.get(), , ));
+MOFI.reset(TheTarget->createMCObjectFileInfo(*Ctx, /*PIC=*/false,
+ /*LargeCodeModel=*/false));
+Ctx->setObjectFileInfo(MOFI.get());
 
 Str.reset(TheTarget->createNullStreamer(*Ctx));
 
Index: llvm/tools/llvm-profgen/ProfiledBinary.cpp
===
--- llvm/tools/llvm-profgen/ProfiledBinary.cpp
+++ llvm/tools/llvm-profgen/ProfiledBinary.cpp
@@ -332,9 +332,11 @@
   if (!MII)
 exitWithError("no instruction info for target " + TripleName, FileName);
 
-  MCObjectFileInfo MOFI;
-  MCContext Ctx(Triple(TripleName), AsmInfo.get(), MRI.get(), , STI.get());
-  MOFI.initMCObjectFileInfo(Ctx, /*PIC=*/false);
+  MCContext Ctx(Triple(TripleName), AsmInfo.get(), MRI.get(), /*MOFI=*/nullptr,
+STI.get());
+  std::unique_ptr MOFI(
+  TheTarget->createMCObjectFileInfo(Ctx, /*PIC=*/false));
+  Ctx.setObjectFileInfo(MOFI.get());
   

[clang] 1faf3b1 - [PowerPC] Re-commit ed87f512bb9eb5c1d44e9a1182ffeaf23d6c5ae8

[Nemanja Ivanovic via cfe-commits]

Author: Nemanja Ivanovic
Date: 2021-05-06T09:50:12-05:00
New Revision: 1faf3b195e71dbc469d658d450949439dbf92f9f

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

LOG: [PowerPC] Re-commit ed87f512bb9eb5c1d44e9a1182ffeaf23d6c5ae8

This was reverted in 3761b9a2345aff197707d23a68d4a178489f60e4 just
as I was about to commit the fix. This patch inlcudes the
necessary fix.

Added: 


Modified: 
clang/lib/Headers/altivec.h
clang/test/CodeGen/builtins-ppc-p8vector.c
clang/test/CodeGen/builtins-ppc-vsx.c

Removed: 




diff  --git a/clang/lib/Headers/altivec.h b/clang/lib/Headers/altivec.h
index cb4f35caf4d4b..e28d234880fbb 100644
--- a/clang/lib/Headers/altivec.h
+++ b/clang/lib/Headers/altivec.h
@@ -309,6 +309,26 @@ static __inline__ vector unsigned char 
__attribute__((__always_inline__))
 vec_add_u128(vector unsigned char __a, vector unsigned char __b) {
   return __builtin_altivec_vadduqm(__a, __b);
 }
+#elif defined(__VSX__)
+static __inline__ vector signed long long __ATTRS_o_ai
+vec_add(vector signed long long __a, vector signed long long __b) {
+  vector unsigned int __res =
+  (vector unsigned int)__a + (vector unsigned int)__b;
+  vector unsigned int __carry = __builtin_altivec_vaddcuw(
+  (vector unsigned int)__a, (vector unsigned int)__b);
+#ifdef __LITTLE_ENDIAN__
+  __carry = __builtin_shufflevector(__carry, __carry, 3, 0, 1, 2);
+#else
+  __carry = __builtin_shufflevector(__carry, __carry, 1, 2, 3, 0);
+#endif
+  return (vector signed long long)(__res + __carry);
+}
+
+static __inline__ vector unsigned long long __ATTRS_o_ai
+vec_add(vector unsigned long long __a, vector unsigned long long __b) {
+  return (vector unsigned long long)vec_add((vector signed long long)__a,
+(vector signed long long)__b);
+}
 #endif // defined(__POWER8_VECTOR__) && defined(__powerpc64__)
 
 static __inline__ vector float __ATTRS_o_ai vec_add(vector float __a,
@@ -1730,7 +1750,31 @@ vec_cmpeq(vector bool long long __a, vector bool long 
long __b) {
   return (vector bool long long)__builtin_altivec_vcmpequd(
   (vector long long)__a, (vector long long)__b);
 }
+#elif defined(__VSX__)
+static __inline__ vector bool long long __ATTRS_o_ai
+vec_cmpeq(vector signed long long __a, vector signed long long __b) {
+  vector bool int __wordcmp =
+  vec_cmpeq((vector signed int)__a, (vector signed int)__b);
+#ifdef __LITTLE_ENDIAN__
+  __wordcmp &= __builtin_shufflevector(__wordcmp, __wordcmp, 3, 0, 1, 2);
+  return (vector bool long long)__builtin_shufflevector(__wordcmp, __wordcmp, 
1,
+1, 3, 3);
+#else
+  __wordcmp &= __builtin_shufflevector(__wordcmp, __wordcmp, 1, 2, 3, 0);
+  return (vector bool long long)__builtin_shufflevector(__wordcmp, __wordcmp, 
0,
+0, 2, 2);
+#endif
+}
 
+static __inline__ vector bool long long __ATTRS_o_ai
+vec_cmpeq(vector unsigned long long __a, vector unsigned long long __b) {
+  return vec_cmpeq((vector signed long long)__a, (vector signed long long)__b);
+}
+
+static __inline__ vector bool long long __ATTRS_o_ai
+vec_cmpeq(vector bool long long __a, vector bool long long __b) {
+  return vec_cmpeq((vector signed long long)__a, (vector signed long long)__b);
+}
 #endif
 
 static __inline__ vector bool int __ATTRS_o_ai vec_cmpeq(vector float __a,
@@ -2018,6 +2062,24 @@ vec_cmpne(vector unsigned long long __a, vector unsigned 
long long __b) {
   return (vector bool long long)
 ~(__builtin_altivec_vcmpequd((vector long long)__a, (vector long 
long)__b));
 }
+#elif defined(__VSX__)
+static __inline__ vector bool long long __ATTRS_o_ai
+vec_cmpne(vector bool long long __a, vector bool long long __b) {
+  return (vector bool long long)~(
+  vec_cmpeq((vector signed long long)__a, (vector signed long long)__b));
+}
+
+static __inline__ vector bool long long __ATTRS_o_ai
+vec_cmpne(vector signed long long __a, vector signed long long __b) {
+  return (vector bool long long)~(
+  vec_cmpeq((vector signed long long)__a, (vector signed long long)__b));
+}
+
+static __inline__ vector bool long long __ATTRS_o_ai
+vec_cmpne(vector unsigned long long __a, vector unsigned long long __b) {
+  return (vector bool long long)~(
+  vec_cmpeq((vector signed long long)__a, (vector signed long long)__b));
+}
 #endif
 
 #ifdef __VSX__
@@ -2070,6 +2132,46 @@ static __inline__ vector bool long long __ATTRS_o_ai
 vec_cmpgt(vector unsigned long long __a, vector unsigned long long __b) {
   return (vector bool long long)__builtin_altivec_vcmpgtud(__a, __b);
 }
+#elif defined(__VSX__)
+static __inline__ vector bool long long __ATTRS_o_ai
+vec_cmpgt(vector signed long long __a, vector signed long long __b) 

[PATCH] D101785: [clangd][ObjC] Highlight Objc Ivar refs

[David Goldman via Phabricator via cfe-commits]

dgoldman added a comment.

In D101785#2741535 , @kadircet wrote:

> Thanks! Can you also add a test to `FindExplicitReferencesTest.All` ? as 
> that's where the underlying change lies.
>
> To disambiguate properties and ivars, what if we used modifiers? I suppose we 
> can mark properties with `abstract` modifier, but i am not an obj-c person so 
> it might be better for you to vet such an idea.

Done. I don't think a modifier would make sense though - they're not really 
abstract. I think it would be better if there was a Field token type, like the 
Field symbol kind.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101785

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

[PATCH] D101785: [clangd][ObjC] Highlight Objc Ivar refs

[David Goldman via Phabricator via cfe-commits]

dgoldman updated this revision to Diff 343409.
dgoldman added a comment.

Add another test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101785

Files:
  clang-tools-extra/clangd/FindTarget.cpp
  clang-tools-extra/clangd/unittests/FindTargetTests.cpp
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -687,6 +687,21 @@
 @implementation $Class[[Foo]]($Namespace_decl[[Bar]])
 @end
   )cpp",
+  R"cpp(
+// ObjC: Properties and Ivars.
+@interface $Class_decl[[Foo]] {
+  int $Field_decl[[_someProperty]];
+}
+@property(nonatomic, assign) int $Field_decl[[someProperty]];
+@end
+@implementation $Class_decl[[Foo]]
+@synthesize someProperty = _someProperty;
+- (int)$Method_decl[[doSomething]] {
+  self.$Field[[someProperty]] = self.$Field[[someProperty]] + 1;
+  self->$Field[[_someProperty]] = $Field[[_someProperty]] + 1;
+}
+@end
+  )cpp",
   // Member imported from dependent base
   R"cpp(
 template  struct $Class_decl[[Base]] {
Index: clang-tools-extra/clangd/unittests/FindTargetTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindTargetTests.cpp
+++ clang-tools-extra/clangd/unittests/FindTargetTests.cpp
@@ -1607,6 +1607,21 @@
"5: targets = {t}, decl\n"
"6: targets = {t}\n"
"7: targets = {}\n"},
+   // Objective-C: instance variables
+   {
+   R"cpp(
+@interface I {
+@public
+  I *_z;
+}
+@end
+I *f;
+void foo() {
+  $0^f->$1^_z = 0;
+}
+  )cpp",
+   "0: targets = {f}\n"
+   "1: targets = {I::_z}\n"},
// Objective-C: properties
{
R"cpp(
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -780,6 +780,13 @@
   explicitReferenceTargets(DynTypedNode::create(*E), {}, Resolver)});
 }
 
+void VisitObjCIvarRefExpr(const ObjCIvarRefExpr *OIRE) {
+  Refs.push_back(ReferenceLoc{NestedNameSpecifierLoc(),
+  OIRE->getLocation(),
+  /*IsDecl=*/false,
+  {OIRE->getDecl()}});
+}
+
 void VisitObjCMessageExpr(const ObjCMessageExpr *E) {
   // The name may have several tokens, we can only report the first.
   Refs.push_back(ReferenceLoc{NestedNameSpecifierLoc(),


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -687,6 +687,21 @@
 @implementation $Class[[Foo]]($Namespace_decl[[Bar]])
 @end
   )cpp",
+  R"cpp(
+// ObjC: Properties and Ivars.
+@interface $Class_decl[[Foo]] {
+  int $Field_decl[[_someProperty]];
+}
+@property(nonatomic, assign) int $Field_decl[[someProperty]];
+@end
+@implementation $Class_decl[[Foo]]
+@synthesize someProperty = _someProperty;
+- (int)$Method_decl[[doSomething]] {
+  self.$Field[[someProperty]] = self.$Field[[someProperty]] + 1;
+  self->$Field[[_someProperty]] = $Field[[_someProperty]] + 1;
+}
+@end
+  )cpp",
   // Member imported from dependent base
   R"cpp(
 template  struct $Class_decl[[Base]] {
Index: clang-tools-extra/clangd/unittests/FindTargetTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindTargetTests.cpp
+++ clang-tools-extra/clangd/unittests/FindTargetTests.cpp
@@ -1607,6 +1607,21 @@
"5: targets = {t}, decl\n"
"6: targets = {t}\n"
"7: targets = {}\n"},
+   // Objective-C: instance variables
+   {
+   R"cpp(
+@interface I {
+@public
+  I *_z;
+}
+@end
+I *f;
+void foo() {
+  $0^f->$1^_z = 0;
+}
+  )cpp",
+   "0: targets = {f}\n"
+   "1: targets = {I::_z}\n"},
// Objective-C: properties
{
R"cpp(
Index: clang-tools-extra/clangd/FindTarget.cpp

[PATCH] D101976: [OpenMP] Unified entry point for SPMD & generic kernels in the device RTL

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added inline comments.



Comment at: openmp/libomptarget/deviceRTLs/nvptx/src/target_impl.cu:65-68
+  asm volatile("barrier.sync %0;"
+   :
+   : "r"(barrier)
+   : "memory");

ABataev wrote:
> Why not `__syncthreads`? It is safer to use `__syncthreads` as it is 
> `convergent`. Would be good to mark this code somehow as `convergent` too to 
> avoid incorrect optimizations
The problem is that syncthreads is basically a `bar.sync` which is a 
`barrier.sync.aligned`, if I understood everything properly. This worked so far 
because the "main thread" (lane 0, last warp) was alone in it's warp and all 
other threads have been terminated. Now, we simplify the control flow (and 
later get rid of the last warp) such that the threads of the last warp and the 
main thread will hit different barriers. The former hit the one in the state 
machine while the latter will be in `parallel_51`. The `.aligned` version 
doesn't allow that. Does that make sense?

I'm not concerned about convergent though, we solved that wholesale: We mark 
all functions that clang compiles for the GPU via openmp-target as convergent 
(IIRC). The entire device runtime is certainly convergent.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101976

___
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

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D101849#2741980 , @DavidSpickett 
wrote:

> I've required X86 target for this test to get our bots green again.

We can have that as a workaround sure.

> Either way this seems like a bug given that clang usually doesn't require the 
> llvm backend for a particular target.

I agree, something is amiss.

> We will probably remove the fopenmp-simd check lines again now, but this is 
> still something we might want to investigate, non-determinism has the 
> tendency to come back and bite you.


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