[PATCH] D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info

2021-09-10 Thread Henry Linjamäki via Phabricator via cfe-commits
linjamaki marked 2 inline comments as done.
linjamaki added inline comments.



Comment at: clang/lib/Basic/Targets.cpp:609
   }
+  case llvm::Triple::spirv32: {
+if (os != llvm::Triple::UnknownOS ||

Anastasia wrote:
> I wonder how complete is the support of logical addressing SPIR-V triple? It 
> seems like you don't test it in the clang invocation at the moment and it is 
> therefore missing from `TargetInfo`. 
> 
> Do you have plans to implement it in the subsequent patches? If not it might 
> be better to leave it out for now.
I removed the spirvlogical triple. AFAIK, this triple has zero sized pointers 
and I don't know if the LLVM is ready for that yet.



Comment at: clang/test/CodeGenOpenCL/spirv32_target.cl:12
+kernel void foo(global long *arg) {
+  int res1[sizeof(my_st)  == 12 ? 1 : -1];
+  int res2[sizeof(void *) ==  4 ? 1 : -1];

Anastasia wrote:
> Are these lines tested somehow? You could change this into C++ for OpenCL 
> test and use `static_assert` or find some other ways to test this...
> 
> However, this testing seems to overlap with the lines at the end... Could you 
> please elaborate on the intent of this test?
> 
> Also if you don't plan this to be fundamentally different from testing of 
> 64bit triple I think this should be merged with `spirv64_target.cl`. It will 
> make things easier for the maintenance and further evolution.
I used spir{32,64}_target.cl as a base for checking codegen for SPIR-V with the 
only difference being the triple check. The lines give an compile error (e.g. 
error: 'res1' declared as an array with a negative size) if the sizeof 
operators give unexpected result. 

I'll merge this file with the spirv64_target.cl.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109144

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


[PATCH] D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info

2021-09-10 Thread Henry Linjamäki via Phabricator via cfe-commits
linjamaki updated this revision to Diff 371802.
linjamaki marked 2 inline comments as done.
linjamaki edited the summary of this revision.
linjamaki added a comment.

Merge two tests together.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109144

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/SPIR.cpp
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Headers/opencl-c-base.h
  clang/lib/Headers/opencl-c.h
  clang/test/CodeGenOpenCL/spirv_target.cl
  clang/test/Headers/opencl-c-header.cl
  clang/test/Preprocessor/predefined-macros.c
  llvm/include/llvm/ADT/Triple.h
  llvm/lib/Support/Triple.cpp
  llvm/unittests/ADT/TripleTest.cpp

Index: llvm/unittests/ADT/TripleTest.cpp
===
--- llvm/unittests/ADT/TripleTest.cpp
+++ llvm/unittests/ADT/TripleTest.cpp
@@ -224,6 +224,16 @@
   EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
   EXPECT_EQ(Triple::UnknownOS, T.getOS());
 
+  T = Triple("spirv32-unknown-unknown");
+  EXPECT_EQ(Triple::spirv32, T.getArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
+  T = Triple("spirv64-unknown-unknown");
+  EXPECT_EQ(Triple::spirv64, T.getArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UnknownOS, T.getOS());
+
   T = Triple("x86_64-unknown-ananas");
   EXPECT_EQ(Triple::x86_64, T.getArch());
   EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
@@ -865,6 +875,16 @@
   EXPECT_FALSE(T.isArch32Bit());
   EXPECT_TRUE(T.isArch64Bit());
 
+  T.setArch(Triple::spirv32);
+  EXPECT_FALSE(T.isArch16Bit());
+  EXPECT_TRUE(T.isArch32Bit());
+  EXPECT_FALSE(T.isArch64Bit());
+
+  T.setArch(Triple::spirv64);
+  EXPECT_FALSE(T.isArch16Bit());
+  EXPECT_FALSE(T.isArch32Bit());
+  EXPECT_TRUE(T.isArch64Bit());
+
   T.setArch(Triple::sparc);
   EXPECT_FALSE(T.isArch16Bit());
   EXPECT_TRUE(T.isArch32Bit());
@@ -1000,6 +1020,14 @@
   EXPECT_EQ(Triple::spir, T.get32BitArchVariant().getArch());
   EXPECT_EQ(Triple::spir64, T.get64BitArchVariant().getArch());
 
+  T.setArch(Triple::spirv32);
+  EXPECT_EQ(Triple::spirv32, T.get32BitArchVariant().getArch());
+  EXPECT_EQ(Triple::spirv64, T.get64BitArchVariant().getArch());
+
+  T.setArch(Triple::spirv64);
+  EXPECT_EQ(Triple::spirv32, T.get32BitArchVariant().getArch());
+  EXPECT_EQ(Triple::spirv64, T.get64BitArchVariant().getArch());
+
   T.setArch(Triple::wasm32);
   EXPECT_EQ(Triple::wasm32, T.get32BitArchVariant().getArch());
   EXPECT_EQ(Triple::wasm64, T.get64BitArchVariant().getArch());
Index: llvm/lib/Support/Triple.cpp
===
--- llvm/lib/Support/Triple.cpp
+++ llvm/lib/Support/Triple.cpp
@@ -67,6 +67,8 @@
   case sparcv9:return "sparcv9";
   case spir64: return "spir64";
   case spir:   return "spir";
+  case spirv32:return "spirv32";
+  case spirv64:return "spirv64";
   case systemz:return "s390x";
   case tce:return "tce";
   case tcele:  return "tcele";
@@ -147,6 +149,10 @@
 
   case spir:
   case spir64:  return "spir";
+
+  case spirv32:
+  case spirv64: return "spirv";
+
   case kalimba: return "kalimba";
   case lanai:   return "lanai";
   case shave:   return "shave";
@@ -323,6 +329,8 @@
 .Case("hsail64", hsail64)
 .Case("spir", spir)
 .Case("spir64", spir64)
+.Case("spirv32", spirv32)
+.Case("spirv64", spirv64)
 .Case("kalimba", kalimba)
 .Case("lanai", lanai)
 .Case("shave", shave)
@@ -456,6 +464,8 @@
 .Case("hsail64", Triple::hsail64)
 .Case("spir", Triple::spir)
 .Case("spir64", Triple::spir64)
+.Case("spirv32", Triple::spirv32)
+.Case("spirv64", Triple::spirv64)
 .StartsWith("kalimba", Triple::kalimba)
 .Case("lanai", Triple::lanai)
 .Case("renderscript32", Triple::renderscript32)
@@ -753,6 +763,11 @@
   case Triple::wasm32:
   case Triple::wasm64:
 return Triple::Wasm;
+
+  case Triple::spirv32:
+  case Triple::spirv64:
+// TODO: In future this will be Triple::SPIRV.
+return Triple::UnknownObjectFormat;
   }
   llvm_unreachable("unknown architecture");
 }
@@ -1298,6 +1313,7 @@
   case llvm::Triple::sparc:
   case llvm::Triple::sparcel:
   case llvm::Triple::spir:
+  case llvm::Triple::spirv32:
   case llvm::Triple::tce:
   case llvm::Triple::tcele:
   case llvm::Triple::thumb:
@@ -1324,6 +1340,7 @@
   case llvm::Triple::riscv64:
   case llvm::Triple::sparcv9:
   case llvm::Triple::spir64:
+  case llvm::Triple::spirv64:
   case llvm::Triple::systemz:
   case llvm::Triple::ve:
   case llvm::Triple::wasm64:
@@ -1383,6 +1400,7 @@
   case Triple::sparc:
   case Triple::sparcel:
   case Triple::spir:
+  cas

[PATCH] D63497: Add support for openSUSE RISC-V triple

2021-09-10 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.
Herald added subscribers: vkmr, frasercrmck, luismarques, sameer.abuasal, Jim.

hexchain pointed me to this patch and asked why Suse can add a triple here... 
So here are some explanations:

We should avoid adding more target triples to `CollectLibDirsAndTriples`.
Every riscv64 user will waste some `fstat` or `openat`.
(If there are 100 distros customizing riscv64, apparently we shouldn't 
enumerate them.)

The list is mainly there so that `clang --target=riscv64` can magically pick 
`riscv64-linux-gnu` (and other `RISCV64Triples` triples).
This behavior is really recommended for newer architectures and OSes.

They should just specify the full triple `clang --target=riscv64-suse-linux`. 
This doesn't require you to add anything to the list.

If on riscv64-suse-linux, `clang` for some reason doesn't recognize 
`riscv64-suse-linux`.
The correct fix is to make `LLVM_DEFAULT_TARGET_TRIPLE` `riscv64-suse-linux`.
This doesn't need any hardcoded value from `RISCV64Triples`.

---

So why cannot we clean these  `RISCV64Triples`?
Perhaps the reason is that some users are unfortunately relying on the behavior.
Deleting these values will be the correct way forward but they can be unhappy 
temporarily.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D63497

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


[PATCH] D106809: [clang-offload-bundler] Make Bundle Entry ID backward compatible

2021-09-10 Thread Konrad Wilhelm Kleine via Phabricator via cfe-commits
kwk added a comment.

@saiislam please have a look into why this happens. Is the 
`-debug-only=CodeObjectCompatibility` maybe a left-over of some sort?




Comment at: clang/test/Driver/clang-offload-bundler.c:405
+// Tests to check compatibility between Bundle Entry ID formats i.e. between 
presence/absence of extra hyphen in case of missing environment field
+// RUN: clang-offload-bundler -unbundle -type=a 
-targets=openmp-amdgcn-amd-amdhsa--gfx906,openmp-amdgcn-amd-amdhsa-gfx908 
-inputs=%t.input-archive.a 
-outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a 
-debug-only=CodeObjectCompatibility 2>&1 | FileCheck %s 
-check-prefix=BUNDLECOMPATIBILITY
+// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa-gfx906]   :   [Target: 
openmp-amdgcn-amd-amdhsa--gfx906]

RKSimon wrote:
> @saiislam This is causing an issue on a thinlto buildbot: 
> https://lab.llvm.org/buildbot/#/builders/67/builds/4148
@saiislam We're seeing the same issue in one of our [downstream 
builders](https://download.copr.fedorainfracloud.org/results/kkleine/llvm-snapshots/fedora-rawhide-x86_64/02687097-clang/builder-live.log.gz):
 

```
: 'RUN: at line 405';   clang-offload-bundler -unbundle -type=a 
-targets=openmp-amdgcn-amd-amdhsa--gfx906,openmp-amdgcn-amd-amdhsa-gfx908 
-inputs=/builddir/build/BUILD/clang-14.0.0.src/redhat-linux-build/test/Driver/Output/clang-offload-bundler.c.tmp.input-archive.a
 
-outputs=/builddir/build/BUILD/clang-14.0.0.src/redhat-linux-build/test/Driver/Output/clang-offload-bundler.c.tmp-archive-gfx906-simple.a,/builddir/build/BUILD/clang-14.0.0.src/redhat-linux-build/test/Driver/Output/clang-offload-bundler.c.tmp-archive-gfx908-simple.a
 -debug-only=CodeObjectCompatibility 2>&1 | /usr/bin/FileCheck 
/builddir/build/BUILD/clang-14.0.0.src/test/Driver/clang-offload-bundler.c 
-check-prefix=BUNDLECOMPATIBILITY
--
Exit Code: 1

Command Output (stderr):
--
/builddir/build/BUILD/clang-14.0.0.src/test/Driver/clang-offload-bundler.c:406:25:
 error: BUNDLECOMPATIBILITY: expected string not found in input
// BUNDLECOMPATIBILITY: Compatible: Exact match: [CodeObject: 
openmp-amdgcn-amd-amdhsa-gfx906] : [Target: openmp-amdgcn-amd-amdhsa--gfx906]
^
:1:1: note: scanning from here
clang-offload-bundler: Unknown command line argument 
'-debug-only=CodeObjectCompatibility'. Try: 'clang-offload-bundler --help'
^

Input file: 
Check file: 
/builddir/build/BUILD/clang-14.0.0.src/test/Driver/clang-offload-bundler.c

-dump-input=help explains the following input dump.

Input was:
<<
   1: clang-offload-bundler: Unknown command line argument 
'-debug-only=CodeObjectCompatibility'. Try: 'clang-offload-bundler --help' 
check:406 
X~~~
 error: no match found
   2: clang-offload-bundler: Did you mean 
'--unbundle=CodeObjectCompatibility'? 
check:406 
~~
>>

--
```




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106809

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


[PATCH] D108560: [clang-tidy] Add support for NOLINTBEGIN ... NOLINTEND comments to suppress clang-tidy warnings over multiple lines

2021-09-10 Thread Salman Javed via Phabricator via cfe-commits
salman-javed-nz added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp:6
+
+// NOLINTEND
+class B1 { B1(int i); };

aaron.ballman wrote:
> Do you think this should be diagnosed as a sign of user confusion with the 
> markings?
For a stray `NOLINTEND` like this one, I don't think so. The original warning 
is still raised, so I see this as clang-tidy failing safe. The user is forced 
to fix their mistake before the warning goes away.

The consequences are of the same severity as misusing the existing `NOLINT` and 
`NOLINTNEXTLINE` markers, e.g. putting `NOLINT` on the wrong line, or adding a 
blank line after `NOLINTNEXTLINE`.



Comment at: 
clang-tools-extra/test/clang-tidy/infrastructure/nolintbeginend.cpp:86
+
+// NOLINTBEGIN
+class H1 { H1(int i); };

aaron.ballman wrote:
> Should this be diagnosed as user confusion?
> 
> My concern in both of these cases isn't so much that someone writes this 
> intentionally, but that one of the begin/end pair gets removed accidentally 
> when refactoring. Helping the user to identify *where* the unmatched 
> delimiters are seems like it could be user-friendly behavior.
The consequences of this one are higher, as there is the potential to suppress 
warnings unintentionally and allow clang-tidy rule violations to go undetected. 
I agree that something more could be done here.

I can think of two improvements:

1. In `LineIsMarkedWithNOLINT()`, when a `NOLINTBEGIN` is found, only return 
true if the corresponding `NOLINTEND` is found as well. Raise the original 
warning if the `NOLINTEND` is omitted.

2. Raise an additional warning regarding the unmatched pair of delimiters. Some 
guidance on how to implement it would be appreciated. In the call stack of the 
`LineIsMarkedWithNOLINT()` function, I can't see any exposed functionality to 
generate new diagnostics on the fly. Would a new clang-tidy check be the place 
to implement this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108560

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


[clang] b2528fc - [clang][deps] Stop using `ClangTool` for virtual files

2021-09-10 Thread Jan Svoboda via cfe-commits

Author: Diana Picus
Date: 2021-09-10T10:19:27+02:00
New Revision: b2528fc49035588b69cec2b4bfba87a0d3eb725d

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

LOG: [clang][deps] Stop using `ClangTool` for virtual files

This patch changes how the dependency scanner creates the fake input file when 
scanning dependencies of a single module (introduced in D109485). The scanner 
now has its own `InMemoryFilesystem` which sits under the minimizing FS (when 
that's requested). This makes it possible to drop the duplicate work in 
`DependencyScanningActions::runInvocation` that sets up the main file ID. 
Besides that, this patch makes it possible to land D108979, where we drop 
`ClangTool` entirely.

Depends on D109485.

Reviewed By: dexonsmith

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

Added: 


Modified: 
clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp

Removed: 




diff  --git 
a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h 
b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
index 3ae3bcda7239..8ede14bdc4f7 100644
--- a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
+++ b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
@@ -92,7 +92,10 @@ class DependencyScanningWorker {
   std::shared_ptr PCHContainerOps;
   std::unique_ptr PPSkipMappings;
 
+  /// The physical filesystem overlaid by `InMemoryFS`.
   llvm::IntrusiveRefCntPtr RealFS;
+  /// The in-memory filesystem laid on top the physical filesystem in `RealFS`.
+  llvm::IntrusiveRefCntPtr InMemoryFS;
   /// The file system that is used by each worker when scanning for
   /// dependencies. This filesystem persists accross multiple compiler
   /// invocations.

diff  --git a/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp 
b/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
index 10385ab35669..389bd1678fba 100644
--- a/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ b/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -141,11 +141,10 @@ class DependencyScanningAction : public 
tooling::ToolAction {
   StringRef WorkingDirectory, DependencyConsumer &Consumer,
   llvm::IntrusiveRefCntPtr DepFS,
   ExcludedPreprocessorDirectiveSkipMapping *PPSkipMappings,
-  ScanningOutputFormat Format, llvm::Optional ModuleName = None,
-  llvm::Optional FakeMemBuffer = None)
+  ScanningOutputFormat Format, llvm::Optional ModuleName = None)
   : WorkingDirectory(WorkingDirectory), Consumer(Consumer),
 DepFS(std::move(DepFS)), PPSkipMappings(PPSkipMappings), 
Format(Format),
-ModuleName(ModuleName), FakeMemBuffer(FakeMemBuffer) {}
+ModuleName(ModuleName) {}
 
   bool runInvocation(std::shared_ptr Invocation,
  FileManager *FileMgr,
@@ -215,16 +214,6 @@ class DependencyScanningAction : public 
tooling::ToolAction {
 .ExcludedConditionalDirectiveSkipMappings = PPSkipMappings;
 }
 
-if (ModuleName.hasValue()) {
-  SmallString<128> FullPath(*ModuleName);
-  llvm::sys::fs::make_absolute(WorkingDirectory, FullPath);
-  SourceManager &SrcMgr = Compiler.getSourceManager();
-  FileMgr->getVirtualFile(FullPath.c_str(), FakeMemBuffer->getBufferSize(),
-  0);
-  FileID MainFileID = SrcMgr.createFileID(*FakeMemBuffer);
-  SrcMgr.setMainFileID(MainFileID);
-}
-
 // Create the dependency collector that will collect the produced
 // dependencies.
 //
@@ -280,7 +269,6 @@ class DependencyScanningAction : public tooling::ToolAction 
{
   ExcludedPreprocessorDirectiveSkipMapping *PPSkipMappings;
   ScanningOutputFormat Format;
   llvm::Optional ModuleName;
-  llvm::Optional FakeMemBuffer;
 };
 
 } // end anonymous namespace
@@ -298,7 +286,12 @@ DependencyScanningWorker::DependencyScanningWorker(
   PCHContainerOps->registerWriter(
   std::make_unique());
 
-  RealFS = llvm::vfs::createPhysicalFileSystem();
+  auto OverlayFS = llvm::makeIntrusiveRefCnt(
+  llvm::vfs::createPhysicalFileSystem());
+  InMemoryFS = llvm::makeIntrusiveRefCnt();
+  OverlayFS->pushOverlay(InMemoryFS);
+  RealFS = OverlayFS;
+
   if (Service.canSkipExcludedPPRanges())
 PPSkipMappings =
 std::make_unique();
@@ -329,13 +322,10 @@ llvm::Error DependencyScanningWorker::computeDependencies(
 const CompilationDatabase &CDB, DependencyConsumer &Consumer,
 llvm::Optional ModuleName) {
   RealFS->setCurrentWorkingDirectory(WorkingDirectory);
-  std::unique_ptr FakeMemBuffer =
-  ModuleName.hasValue() ? llvm::MemoryBuffer::getMemBuff

[PATCH] D109498: [clang][deps] Stop using `ClangTool` for virtual files

2021-09-10 Thread Jan Svoboda via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGb2528fc49035: [clang][deps] Stop using `ClangTool` for 
virtual files (authored by rovka, committed by jansvoboda11).

Changed prior to commit:
  https://reviews.llvm.org/D109498?vs=371570&id=371817#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109498

Files:
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp

Index: clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -141,11 +141,10 @@
   StringRef WorkingDirectory, DependencyConsumer &Consumer,
   llvm::IntrusiveRefCntPtr DepFS,
   ExcludedPreprocessorDirectiveSkipMapping *PPSkipMappings,
-  ScanningOutputFormat Format, llvm::Optional ModuleName = None,
-  llvm::Optional FakeMemBuffer = None)
+  ScanningOutputFormat Format, llvm::Optional ModuleName = None)
   : WorkingDirectory(WorkingDirectory), Consumer(Consumer),
 DepFS(std::move(DepFS)), PPSkipMappings(PPSkipMappings), Format(Format),
-ModuleName(ModuleName), FakeMemBuffer(FakeMemBuffer) {}
+ModuleName(ModuleName) {}
 
   bool runInvocation(std::shared_ptr Invocation,
  FileManager *FileMgr,
@@ -215,16 +214,6 @@
 .ExcludedConditionalDirectiveSkipMappings = PPSkipMappings;
 }
 
-if (ModuleName.hasValue()) {
-  SmallString<128> FullPath(*ModuleName);
-  llvm::sys::fs::make_absolute(WorkingDirectory, FullPath);
-  SourceManager &SrcMgr = Compiler.getSourceManager();
-  FileMgr->getVirtualFile(FullPath.c_str(), FakeMemBuffer->getBufferSize(),
-  0);
-  FileID MainFileID = SrcMgr.createFileID(*FakeMemBuffer);
-  SrcMgr.setMainFileID(MainFileID);
-}
-
 // Create the dependency collector that will collect the produced
 // dependencies.
 //
@@ -280,7 +269,6 @@
   ExcludedPreprocessorDirectiveSkipMapping *PPSkipMappings;
   ScanningOutputFormat Format;
   llvm::Optional ModuleName;
-  llvm::Optional FakeMemBuffer;
 };
 
 } // end anonymous namespace
@@ -298,7 +286,12 @@
   PCHContainerOps->registerWriter(
   std::make_unique());
 
-  RealFS = llvm::vfs::createPhysicalFileSystem();
+  auto OverlayFS = llvm::makeIntrusiveRefCnt(
+  llvm::vfs::createPhysicalFileSystem());
+  InMemoryFS = llvm::makeIntrusiveRefCnt();
+  OverlayFS->pushOverlay(InMemoryFS);
+  RealFS = OverlayFS;
+
   if (Service.canSkipExcludedPPRanges())
 PPSkipMappings =
 std::make_unique();
@@ -329,13 +322,10 @@
 const CompilationDatabase &CDB, DependencyConsumer &Consumer,
 llvm::Optional ModuleName) {
   RealFS->setCurrentWorkingDirectory(WorkingDirectory);
-  std::unique_ptr FakeMemBuffer =
-  ModuleName.hasValue() ? llvm::MemoryBuffer::getMemBuffer(" ") : nullptr;
   return runWithDiags(DiagOpts.get(), [&](DiagnosticConsumer &DC) {
 /// Create the tool that uses the underlying file system to ensure that any
 /// file system requests that are made by the driver do not go through the
 /// dependency scanning filesystem.
-SmallString<128> FullPath;
 tooling::ClangTool Tool(CDB,
 ModuleName.hasValue() ? ModuleName->str() : Input,
 PCHContainerOps, RealFS, Files);
@@ -343,21 +333,15 @@
 Tool.setRestoreWorkingDir(false);
 Tool.setPrintErrorMessage(false);
 Tool.setDiagnosticConsumer(&DC);
-DependencyScanningAction Action(
-WorkingDirectory, Consumer, DepFS, PPSkipMappings.get(), Format,
-ModuleName,
-FakeMemBuffer
-? llvm::Optional(*FakeMemBuffer.get())
-: None);
+DependencyScanningAction Action(WorkingDirectory, Consumer, DepFS,
+PPSkipMappings.get(), Format, ModuleName);
 
 if (ModuleName.hasValue()) {
-  Tool.mapVirtualFile(*ModuleName, FakeMemBuffer->getBuffer());
-  FullPath = *ModuleName;
-  llvm::sys::fs::make_absolute(WorkingDirectory, FullPath);
+  InMemoryFS->addFile(*ModuleName, 0, llvm::MemoryBuffer::getMemBuffer(""));
   Tool.appendArgumentsAdjuster(
   [&](const tooling::CommandLineArguments &Args, StringRef FileName) {
 tooling::CommandLineArguments AdjustedArgs(Args);
-AdjustedArgs.push_back(std::string(FullPath));
+AdjustedArgs.emplace_back(*ModuleName);
 return AdjustedArgs;
   });
 }
Index: clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
===
--- clang/include/clang/Tooling/DependencyScanning

[PATCH] D109582: [clang-format] Restrict the special handling for K&R C to C/C++

2021-09-10 Thread Owen Pan via Phabricator via cfe-commits
owenpan created this revision.
owenpan added reviewers: krasimir, MyDeveloperDay, HazardyKnusperkeks.
owenpan added a project: clang-format.
owenpan requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Commits 58494c856a15 
, 
f6bc614546e1 
, and 
0fc27ef19670 
 added 
special handlings for K&R C function definitions and caused some JavaScript 
regressions which were addressed in https://reviews.llvm.org/D107267 and 
https://reviews.llvm.org/D108538. This patch could have prevented these known 
regressions and will fix any unknown ones.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109582

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -8277,6 +8277,12 @@
   verifyFormat("int\n"
"f(a)",
Style);
+  verifyFormat("bool\n"
+   "f(size_t = 0, bool b = false)\n"
+   "{\n"
+   "  return !b;\n"
+   "}",
+   Style);
 
   // The return breaking style doesn't affect:
   // * function and object definitions with attribute-like macros
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2398,7 +2398,7 @@
 
 // This function heuristically determines whether 'Current' starts the name of 
a
 // function declaration.
-static bool isFunctionDeclarationName(const FormatToken &Current,
+static bool isFunctionDeclarationName(bool IsCpp, const FormatToken &Current,
   const AnnotatedLine &Line) {
   auto skipOperatorName = [](const FormatToken *Next) -> const FormatToken * {
 for (; Next; Next = Next->Next) {
@@ -2476,14 +2476,21 @@
   if (Next->MatchingParen->Next &&
   Next->MatchingParen->Next->is(TT_PointerOrReference))
 return true;
-  // Check for K&R C function definitions, e.g.:
+
+  // Check for K&R C function definitions (and C++ function definitions with
+  // unnamed parameters), e.g.:
   //   int f(i)
   //   {
   // return i + 1;
   //   }
-  if (Next->Next && Next->Next->is(tok::identifier) &&
+  //   bool g(size_t = 0, bool b = false)
+  //   {
+  // return !b;
+  //   }
+  if (IsCpp && Next->Next && Next->Next->is(tok::identifier) &&
   !Line.endsWith(tok::semi))
 return true;
+
   for (const FormatToken *Tok = Next->Next; Tok && Tok != Next->MatchingParen;
Tok = Tok->Next) {
 if (Tok->is(TT_TypeDeclarationParen))
@@ -2544,7 +2551,7 @@
 calculateArrayInitializerColumnList(Line);
 
   while (Current) {
-if (isFunctionDeclarationName(*Current, Line))
+if (isFunctionDeclarationName(Style.isCpp(), *Current, Line))
   Current->setType(TT_FunctionDeclarationName);
 if (Current->is(TT_LineComment)) {
   if (Current->Previous->is(BK_BracedInit) &&


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -8277,6 +8277,12 @@
   verifyFormat("int\n"
"f(a)",
Style);
+  verifyFormat("bool\n"
+   "f(size_t = 0, bool b = false)\n"
+   "{\n"
+   "  return !b;\n"
+   "}",
+   Style);
 
   // The return breaking style doesn't affect:
   // * function and object definitions with attribute-like macros
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2398,7 +2398,7 @@
 
 // This function heuristically determines whether 'Current' starts the name of a
 // function declaration.
-static bool isFunctionDeclarationName(const FormatToken &Current,
+static bool isFunctionDeclarationName(bool IsCpp, const FormatToken &Current,
   const AnnotatedLine &Line) {
   auto skipOperatorName = [](const FormatToken *Next) -> const FormatToken * {
 for (; Next; Next = Next->Next) {
@@ -2476,14 +2476,21 @@
   if (Next->MatchingParen->Next &&
   Next->MatchingParen->Next->is(TT_PointerOrReference))
 return true;
-  // Check for K&R C function definitions, e.g.:
+
+  // Check for K&R C function definitions (and C++ function definitions with
+  // unnamed parameters), e.g.:
   //   int f(i)
   //   {
   // return i + 1;
   //   }
-  if (Next->Next && Next->Next->is(tok::identifier) &&
+  

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

2021-09-10 Thread Justas Janickas via Phabricator via cfe-commits
Topotuna accepted this revision.
Topotuna added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks


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

https://reviews.llvm.org/D109327

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


[clang] 146ec74 - [clang][deps] NFC: Stop going through ClangTool

2021-09-10 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2021-09-10T11:02:41+02:00
New Revision: 146ec74a8382dc820809d0a2bf4b918d0b5e6603

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

LOG: [clang][deps] NFC: Stop going through ClangTool

The dependency scanner currently uses `ClangTool` to invoke the dependency 
scanning action.

However, `ClangTool` seems to be the wrong level of abstraction. It's intended 
to be run over a collection of compile commands, which we actively avoid via 
`SingleCommandCompilationDatabase`. It automatically injects `-fsyntax-only` 
and other flags, which we avoid by calling `clearArgumentsAdjusters()`. It 
deduces the resource directory based on the current executable path, which we'd 
like to change to deducing from `argv[0]`.

Internally, `ClangTool` uses `ToolInvocation` which seems to be more in line 
with what the dependency scanner tries to achieve. This patch switches to 
directly using `ToolInvocation` instead. NFC.

Reviewed By: dexonsmith

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

Added: 


Modified: 
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp

Removed: 




diff  --git a/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp 
b/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
index 389bd1678fba..4ee01df4f807 100644
--- a/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ b/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -321,31 +321,38 @@ llvm::Error DependencyScanningWorker::computeDependencies(
 const std::string &Input, StringRef WorkingDirectory,
 const CompilationDatabase &CDB, DependencyConsumer &Consumer,
 llvm::Optional ModuleName) {
+  // Reset what might have been modified in the previous worker invocation.
   RealFS->setCurrentWorkingDirectory(WorkingDirectory);
+  if (Files)
+Files->setVirtualFileSystem(RealFS);
+
+  llvm::IntrusiveRefCntPtr CurrentFiles =
+  Files ? Files : new FileManager(FileSystemOptions(), RealFS);
+
+  // FIXME: Avoid this copy.
+  std::vector CompileCommands = CDB.getCompileCommands(Input);
+  const std::vector &CommandLine =
+  CompileCommands.front().CommandLine;
+
+  Optional> ModifiedCommandLine;
+  if (ModuleName.hasValue()) {
+ModifiedCommandLine = CommandLine;
+InMemoryFS->addFile(*ModuleName, 0, llvm::MemoryBuffer::getMemBuffer(""));
+ModifiedCommandLine->emplace_back(*ModuleName);
+  }
+
+  const std::vector &FinalCommandLine =
+  ModifiedCommandLine ? *ModifiedCommandLine : CommandLine;
+
   return runWithDiags(DiagOpts.get(), [&](DiagnosticConsumer &DC) {
-/// Create the tool that uses the underlying file system to ensure that any
-/// file system requests that are made by the driver do not go through the
-/// dependency scanning filesystem.
-tooling::ClangTool Tool(CDB,
-ModuleName.hasValue() ? ModuleName->str() : Input,
-PCHContainerOps, RealFS, Files);
-Tool.clearArgumentsAdjusters();
-Tool.setRestoreWorkingDir(false);
-Tool.setPrintErrorMessage(false);
-Tool.setDiagnosticConsumer(&DC);
 DependencyScanningAction Action(WorkingDirectory, Consumer, DepFS,
 PPSkipMappings.get(), Format, ModuleName);
-
-if (ModuleName.hasValue()) {
-  InMemoryFS->addFile(*ModuleName, 0, 
llvm::MemoryBuffer::getMemBuffer(""));
-  Tool.appendArgumentsAdjuster(
-  [&](const tooling::CommandLineArguments &Args, StringRef FileName) {
-tooling::CommandLineArguments AdjustedArgs(Args);
-AdjustedArgs.emplace_back(*ModuleName);
-return AdjustedArgs;
-  });
-}
-
-return !Tool.run(&Action);
+// Create an invocation that uses the underlying file system to ensure that
+// any file system requests that are made by the driver do not go through
+// the dependency scanning filesystem.
+ToolInvocation Invocation(FinalCommandLine, &Action, CurrentFiles.get(),
+  PCHContainerOps);
+Invocation.setDiagnosticConsumer(&DC);
+return Invocation.run();
   });
 }



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


[PATCH] D108979: [clang][deps] NFC: Stop going through ClangTool

2021-09-10 Thread Jan Svoboda 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 rG146ec74a8382: [clang][deps] NFC: Stop going through 
ClangTool (authored by jansvoboda11).

Changed prior to commit:
  https://reviews.llvm.org/D108979?vs=370545&id=371832#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108979

Files:
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp


Index: clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -321,31 +321,38 @@
 const std::string &Input, StringRef WorkingDirectory,
 const CompilationDatabase &CDB, DependencyConsumer &Consumer,
 llvm::Optional ModuleName) {
+  // Reset what might have been modified in the previous worker invocation.
   RealFS->setCurrentWorkingDirectory(WorkingDirectory);
+  if (Files)
+Files->setVirtualFileSystem(RealFS);
+
+  llvm::IntrusiveRefCntPtr CurrentFiles =
+  Files ? Files : new FileManager(FileSystemOptions(), RealFS);
+
+  // FIXME: Avoid this copy.
+  std::vector CompileCommands = CDB.getCompileCommands(Input);
+  const std::vector &CommandLine =
+  CompileCommands.front().CommandLine;
+
+  Optional> ModifiedCommandLine;
+  if (ModuleName.hasValue()) {
+ModifiedCommandLine = CommandLine;
+InMemoryFS->addFile(*ModuleName, 0, llvm::MemoryBuffer::getMemBuffer(""));
+ModifiedCommandLine->emplace_back(*ModuleName);
+  }
+
+  const std::vector &FinalCommandLine =
+  ModifiedCommandLine ? *ModifiedCommandLine : CommandLine;
+
   return runWithDiags(DiagOpts.get(), [&](DiagnosticConsumer &DC) {
-/// Create the tool that uses the underlying file system to ensure that any
-/// file system requests that are made by the driver do not go through the
-/// dependency scanning filesystem.
-tooling::ClangTool Tool(CDB,
-ModuleName.hasValue() ? ModuleName->str() : Input,
-PCHContainerOps, RealFS, Files);
-Tool.clearArgumentsAdjusters();
-Tool.setRestoreWorkingDir(false);
-Tool.setPrintErrorMessage(false);
-Tool.setDiagnosticConsumer(&DC);
 DependencyScanningAction Action(WorkingDirectory, Consumer, DepFS,
 PPSkipMappings.get(), Format, ModuleName);
-
-if (ModuleName.hasValue()) {
-  InMemoryFS->addFile(*ModuleName, 0, 
llvm::MemoryBuffer::getMemBuffer(""));
-  Tool.appendArgumentsAdjuster(
-  [&](const tooling::CommandLineArguments &Args, StringRef FileName) {
-tooling::CommandLineArguments AdjustedArgs(Args);
-AdjustedArgs.emplace_back(*ModuleName);
-return AdjustedArgs;
-  });
-}
-
-return !Tool.run(&Action);
+// Create an invocation that uses the underlying file system to ensure that
+// any file system requests that are made by the driver do not go through
+// the dependency scanning filesystem.
+ToolInvocation Invocation(FinalCommandLine, &Action, CurrentFiles.get(),
+  PCHContainerOps);
+Invocation.setDiagnosticConsumer(&DC);
+return Invocation.run();
   });
 }


Index: clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -321,31 +321,38 @@
 const std::string &Input, StringRef WorkingDirectory,
 const CompilationDatabase &CDB, DependencyConsumer &Consumer,
 llvm::Optional ModuleName) {
+  // Reset what might have been modified in the previous worker invocation.
   RealFS->setCurrentWorkingDirectory(WorkingDirectory);
+  if (Files)
+Files->setVirtualFileSystem(RealFS);
+
+  llvm::IntrusiveRefCntPtr CurrentFiles =
+  Files ? Files : new FileManager(FileSystemOptions(), RealFS);
+
+  // FIXME: Avoid this copy.
+  std::vector CompileCommands = CDB.getCompileCommands(Input);
+  const std::vector &CommandLine =
+  CompileCommands.front().CommandLine;
+
+  Optional> ModifiedCommandLine;
+  if (ModuleName.hasValue()) {
+ModifiedCommandLine = CommandLine;
+InMemoryFS->addFile(*ModuleName, 0, llvm::MemoryBuffer::getMemBuffer(""));
+ModifiedCommandLine->emplace_back(*ModuleName);
+  }
+
+  const std::vector &FinalCommandLine =
+  ModifiedCommandLine ? *ModifiedCommandLine : CommandLine;
+
   return runWithDiags(DiagOpts.get(), [&](DiagnosticConsumer &DC) {
-/// Create the tool that uses the underlying file system to ensure that any
-/// file system requests that are made by the driver do not go through the
-/// dependen

[PATCH] D109366: [OpenCL] Tests C++ for OpenCL version macros

2021-09-10 Thread Justas Janickas via Phabricator via cfe-commits
Topotuna updated this revision to Diff 371831.
Topotuna added a comment.

Reuses `--check-prefix=CHECK-CLCPP10` for default C++ for OpenCL command line 
version


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

https://reviews.llvm.org/D109366

Files:
  clang/test/Preprocessor/predefined-macros.c


Index: clang/test/Preprocessor/predefined-macros.c
===
--- clang/test/Preprocessor/predefined-macros.c
+++ clang/test/Preprocessor/predefined-macros.c
@@ -137,6 +137,10 @@
 // RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-FRM
 // RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++ \
 // RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-CLCPP10
+// RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++1.0 \
+// RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-CLCPP10
+// RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++2021 \
+// RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-CLCPP2021
 // CHECK-CL10: #define CL_VERSION_1_0 100
 // CHECK-CL10: #define CL_VERSION_1_1 110
 // CHECK-CL10: #define CL_VERSION_1_2 120
@@ -174,9 +178,15 @@
 // CHECK-CL30-NOT: #define __FAST_RELAXED_MATH__ 1
 // CHECK-FRM: #define __FAST_RELAXED_MATH__ 1
 // CHECK-CLCPP10: #define __CL_CPP_VERSION_1_0__ 100
+// CHECK-CLCPP10: #define __CL_CPP_VERSION_2021__ 202100
 // CHECK-CLCPP10: #define __OPENCL_CPP_VERSION__ 100
 // CHECK-CLCPP10-NOT: #define __FAST_RELAXED_MATH__ 1
 // CHECK-CLCPP10-NOT: #define __ENDIAN_LITTLE__ 1
+// CHECK-CLCPP2021: #define __CL_CPP_VERSION_1_0__ 100
+// CHECK-CLCPP2021: #define __CL_CPP_VERSION_2021__ 202100
+// CHECK-CLCPP2021: #define __OPENCL_CPP_VERSION__ 202100
+// CHECK-CLCPP2021-NOT: #define __FAST_RELAXED_MATH__ 1
+// CHECK-CLCPP2021-NOT: #define __ENDIAN_LITTLE__ 1
 
 // RUN: %clang_cc1 %s -E -dM -o - -x cl \
 // RUN:   | FileCheck %s --check-prefix=MSCOPE


Index: clang/test/Preprocessor/predefined-macros.c
===
--- clang/test/Preprocessor/predefined-macros.c
+++ clang/test/Preprocessor/predefined-macros.c
@@ -137,6 +137,10 @@
 // RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-FRM
 // RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++ \
 // RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-CLCPP10
+// RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++1.0 \
+// RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-CLCPP10
+// RUN: %clang_cc1 %s -E -dM -o - -x cl -cl-std=clc++2021 \
+// RUN:   | FileCheck -match-full-lines %s --check-prefix=CHECK-CLCPP2021
 // CHECK-CL10: #define CL_VERSION_1_0 100
 // CHECK-CL10: #define CL_VERSION_1_1 110
 // CHECK-CL10: #define CL_VERSION_1_2 120
@@ -174,9 +178,15 @@
 // CHECK-CL30-NOT: #define __FAST_RELAXED_MATH__ 1
 // CHECK-FRM: #define __FAST_RELAXED_MATH__ 1
 // CHECK-CLCPP10: #define __CL_CPP_VERSION_1_0__ 100
+// CHECK-CLCPP10: #define __CL_CPP_VERSION_2021__ 202100
 // CHECK-CLCPP10: #define __OPENCL_CPP_VERSION__ 100
 // CHECK-CLCPP10-NOT: #define __FAST_RELAXED_MATH__ 1
 // CHECK-CLCPP10-NOT: #define __ENDIAN_LITTLE__ 1
+// CHECK-CLCPP2021: #define __CL_CPP_VERSION_1_0__ 100
+// CHECK-CLCPP2021: #define __CL_CPP_VERSION_2021__ 202100
+// CHECK-CLCPP2021: #define __OPENCL_CPP_VERSION__ 202100
+// CHECK-CLCPP2021-NOT: #define __FAST_RELAXED_MATH__ 1
+// CHECK-CLCPP2021-NOT: #define __ENDIAN_LITTLE__ 1
 
 // RUN: %clang_cc1 %s -E -dM -o - -x cl \
 // RUN:   | FileCheck %s --check-prefix=MSCOPE
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 729f7b1 - [clang][deps] NFC: Remove CompilationDatabase from DependencyScanningWorker API

2021-09-10 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2021-09-10T11:23:12+02:00
New Revision: 729f7b122081a078731a132cf4a8971c5c9fda8f

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

LOG: [clang][deps] NFC: Remove CompilationDatabase from 
DependencyScanningWorker API

This patch simplifies the dependency scanner API. Depends on D108979.

Reviewed By: dexonsmith

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

Added: 


Modified: 
clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp

Removed: 




diff  --git 
a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h 
b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
index 8ede14bdc4f7..58f2f72da971 100644
--- a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
+++ b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
@@ -74,16 +74,15 @@ class DependencyScanningWorker {
 public:
   DependencyScanningWorker(DependencyScanningService &Service);
 
-  /// Run the dependency scanning tool for a given clang driver invocation (as
-  /// specified for the given Input in the CDB), and report the discovered
-  /// dependencies to the provided consumer. If \p ModuleName isn't empty, this
-  /// function reports the dependencies of module \p ModuleName.
+  /// Run the dependency scanning tool for a given clang driver command-line,
+  /// and report the discovered dependencies to the provided consumer. If \p
+  /// ModuleName isn't empty, this function reports the dependencies of module
+  /// \p ModuleName.
   ///
   /// \returns A \c StringError with the diagnostic output if clang errors
   /// occurred, success otherwise.
-  llvm::Error computeDependencies(const std::string &Input,
-  StringRef WorkingDirectory,
-  const CompilationDatabase &CDB,
+  llvm::Error computeDependencies(StringRef WorkingDirectory,
+  const std::vector &CommandLine,
   DependencyConsumer &Consumer,
   llvm::Optional ModuleName = None);
 

diff  --git a/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp 
b/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
index a7969b358d9c..b083d09c8bff 100644
--- a/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
+++ b/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
@@ -110,11 +110,13 @@ llvm::Expected 
DependencyScanningTool::getDependencyFile(
   // behavior.
   assert(Compilations.getAllCompileCommands().size() == 1 &&
  "Expected a compilation database with a single command!");
-  std::string Input = Compilations.getAllCompileCommands().front().Filename;
+  // FIXME: Avoid this copy.
+  std::vector CommandLine =
+  Compilations.getAllCompileCommands().front().CommandLine;
 
   MakeDependencyPrinterConsumer Consumer;
-  auto Result = Worker.computeDependencies(Input, CWD, Compilations, Consumer,
-   ModuleName);
+  auto Result =
+  Worker.computeDependencies(CWD, CommandLine, Consumer, ModuleName);
   if (Result)
 return std::move(Result);
   std::string Output;
@@ -196,11 +198,13 @@ DependencyScanningTool::getFullDependencies(
   // behavior.
   assert(Compilations.getAllCompileCommands().size() == 1 &&
  "Expected a compilation database with a single command!");
-  std::string Input = Compilations.getAllCompileCommands().front().Filename;
+  // FIXME: Avoid this copy.
+  std::vector CommandLine =
+  Compilations.getAllCompileCommands().front().CommandLine;
 
   FullDependencyPrinterConsumer Consumer(AlreadySeen);
-  llvm::Error Result = Worker.computeDependencies(Input, CWD, Compilations,
-  Consumer, ModuleName);
+  llvm::Error Result =
+  Worker.computeDependencies(CWD, CommandLine, Consumer, ModuleName);
   if (Result)
 return std::move(Result);
   return Consumer.getFullDependencies();

diff  --git a/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp 
b/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
index 4ee01df4f807..c8aa801ed5d6 100644
--- a/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ b/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -318,9 +318,8 @@ static llvm::Error runWithDiags(
 }
 
 llvm::Error DependencyScanningWorker::computeDependencies(
-const std::string &Input, StringRef WorkingDirectory,
-const CompilationDatabase &CDB, DependencyConsumer &Consumer

[PATCH] D108980: [clang][deps] NFC: Remove CompilationDatabase from DependencyScanningWorker API

2021-09-10 Thread Jan Svoboda 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 rG729f7b122081: [clang][deps] NFC: Remove CompilationDatabase 
from DependencyScanningWorker API (authored by jansvoboda11).

Changed prior to commit:
  https://reviews.llvm.org/D108980?vs=369663&id=371840#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108980

Files:
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
  clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp


Index: clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -318,9 +318,8 @@
 }
 
 llvm::Error DependencyScanningWorker::computeDependencies(
-const std::string &Input, StringRef WorkingDirectory,
-const CompilationDatabase &CDB, DependencyConsumer &Consumer,
-llvm::Optional ModuleName) {
+StringRef WorkingDirectory, const std::vector &CommandLine,
+DependencyConsumer &Consumer, llvm::Optional ModuleName) {
   // Reset what might have been modified in the previous worker invocation.
   RealFS->setCurrentWorkingDirectory(WorkingDirectory);
   if (Files)
@@ -329,11 +328,6 @@
   llvm::IntrusiveRefCntPtr CurrentFiles =
   Files ? Files : new FileManager(FileSystemOptions(), RealFS);
 
-  // FIXME: Avoid this copy.
-  std::vector CompileCommands = CDB.getCompileCommands(Input);
-  const std::vector &CommandLine =
-  CompileCommands.front().CommandLine;
-
   Optional> ModifiedCommandLine;
   if (ModuleName.hasValue()) {
 ModifiedCommandLine = CommandLine;
Index: clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
@@ -110,11 +110,13 @@
   // behavior.
   assert(Compilations.getAllCompileCommands().size() == 1 &&
  "Expected a compilation database with a single command!");
-  std::string Input = Compilations.getAllCompileCommands().front().Filename;
+  // FIXME: Avoid this copy.
+  std::vector CommandLine =
+  Compilations.getAllCompileCommands().front().CommandLine;
 
   MakeDependencyPrinterConsumer Consumer;
-  auto Result = Worker.computeDependencies(Input, CWD, Compilations, Consumer,
-   ModuleName);
+  auto Result =
+  Worker.computeDependencies(CWD, CommandLine, Consumer, ModuleName);
   if (Result)
 return std::move(Result);
   std::string Output;
@@ -196,11 +198,13 @@
   // behavior.
   assert(Compilations.getAllCompileCommands().size() == 1 &&
  "Expected a compilation database with a single command!");
-  std::string Input = Compilations.getAllCompileCommands().front().Filename;
+  // FIXME: Avoid this copy.
+  std::vector CommandLine =
+  Compilations.getAllCompileCommands().front().CommandLine;
 
   FullDependencyPrinterConsumer Consumer(AlreadySeen);
-  llvm::Error Result = Worker.computeDependencies(Input, CWD, Compilations,
-  Consumer, ModuleName);
+  llvm::Error Result =
+  Worker.computeDependencies(CWD, CommandLine, Consumer, ModuleName);
   if (Result)
 return std::move(Result);
   return Consumer.getFullDependencies();
Index: clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
===
--- clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
+++ clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
@@ -74,16 +74,15 @@
 public:
   DependencyScanningWorker(DependencyScanningService &Service);
 
-  /// Run the dependency scanning tool for a given clang driver invocation (as
-  /// specified for the given Input in the CDB), and report the discovered
-  /// dependencies to the provided consumer. If \p ModuleName isn't empty, this
-  /// function reports the dependencies of module \p ModuleName.
+  /// Run the dependency scanning tool for a given clang driver command-line,
+  /// and report the discovered dependencies to the provided consumer. If \p
+  /// ModuleName isn't empty, this function reports the dependencies of module
+  /// \p ModuleName.
   ///
   /// \returns A \c StringError with the diagnostic output if clang errors
   /// occurred, success otherwise.
-  llvm::Error computeDependencies(const std::string &Input,
-  StringRef WorkingDirectory,
-  const CompilationDatabase &CDB,
+  llvm::Error computeDependencie

[PATCH] D106809: [clang-offload-bundler] Make Bundle Entry ID backward compatible

2021-09-10 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam added a comment.

In D106809#2993666 , @kwk wrote:

> @saiislam please have a look into why this happens. Is the 
> `-debug-only=CodeObjectCompatibility` maybe a left-over of some sort?

No, it is not a left-over. I was using this debug output to show that new and 
old bundle entry ID formats are compatible with each other.

I am taking a look on how to fix this. Thanks for pointing it out @RKSimon and 
@kwk .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106809

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


[PATCH] D106804: [test-suite] Add tests for FP classification intrinsics

2021-09-10 Thread Serge Pavlov via Phabricator via cfe-commits
sepavloff added a comment.

In D106804#2991411 , @RKSimon wrote:

> Do we have test-suite buildbot coverage on anything other than x86? Cross 
> platform uses of long double is always fun

The following build bots have a stage named `test-suite`:

clang-ppc64be-linux-lnt
clang-ppc64le-linux-lnt
clang-s390x-linux-lnt
clang-armv7-lnt
clang-native-arm-lnt-perf
clang-aarch64-full-2stage
clang-armv7-vfpv3-full-2stage
clang-thumbv7-full-2stage
clang-cmake-x86_64-avx2-linux-perf
clang-cmake-x86_64-avx2-linux

So it looks like major targets are represented in testing.


Repository:
  rT test-suite

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

https://reviews.llvm.org/D106804

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


[PATCH] D108981: [clang][deps] NFC: Remove CompilationDatabase from DependencyScanningTool API

2021-09-10 Thread Jan Svoboda 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 rG0ebf61963bb6: [clang][deps] NFC: Remove CompilationDatabase 
from DependencyScanningTool API (authored by jansvoboda11).

Changed prior to commit:
  https://reviews.llvm.org/D108981?vs=369664&id=371855#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108981

Files:
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
  clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
  clang/tools/clang-scan-deps/ClangScanDeps.cpp

Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -513,10 +513,8 @@
   for (unsigned I = 0; I < Pool.getThreadCount(); ++I)
 WorkerTools.push_back(std::make_unique(Service));
 
-  std::vector Inputs;
-  for (tooling::CompileCommand Cmd :
-   AdjustingCompilations->getAllCompileCommands())
-Inputs.emplace_back(Cmd);
+  std::vector Inputs =
+  AdjustingCompilations->getAllCompileCommands();
 
   std::atomic HadErrors(false);
   FullDeps FD;
@@ -532,7 +530,7 @@
 &DependencyOS, &Errs]() {
   llvm::StringSet<> AlreadySeenModules;
   while (true) {
-const SingleCommandCompilationDatabase *Input;
+const tooling::CompileCommand *Input;
 std::string Filename;
 std::string CWD;
 size_t LocalIndex;
@@ -543,14 +541,13 @@
 return;
   LocalIndex = Index;
   Input = &Inputs[Index++];
-  tooling::CompileCommand Cmd = Input->getAllCompileCommands()[0];
-  Filename = std::move(Cmd.Filename);
-  CWD = std::move(Cmd.Directory);
+  Filename = std::move(Input->Filename);
+  CWD = std::move(Input->Directory);
 }
 // Run the tool on it.
 if (Format == ScanningOutputFormat::Make) {
   auto MaybeFile = WorkerTools[I]->getDependencyFile(
-  *Input, CWD,
+  Input->CommandLine, CWD,
   ModuleName.empty()
   ? None
   : llvm::Optional(ModuleName.c_str()));
@@ -559,7 +556,7 @@
 HadErrors = true;
 } else {
   auto MaybeFullDeps = WorkerTools[I]->getFullDependencies(
-  *Input, CWD, AlreadySeenModules,
+  Input->CommandLine, CWD, AlreadySeenModules,
   ModuleName.empty()
   ? None
   : llvm::Optional(ModuleName.c_str()));
Index: clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
@@ -50,7 +50,7 @@
 : Worker(Service) {}
 
 llvm::Expected DependencyScanningTool::getDependencyFile(
-const tooling::CompilationDatabase &Compilations, StringRef CWD,
+const std::vector &CommandLine, StringRef CWD,
 llvm::Optional ModuleName) {
   /// Prints out all of the gathered dependencies into a string.
   class MakeDependencyPrinterConsumer : public DependencyConsumer {
@@ -103,17 +103,6 @@
 std::vector Dependencies;
   };
 
-  // We expect a single command here because if a source file occurs multiple
-  // times in the original CDB, then `computeDependencies` would run the
-  // `DependencyScanningAction` once for every time the input occured in the
-  // CDB. Instead we split up the CDB into single command chunks to avoid this
-  // behavior.
-  assert(Compilations.getAllCompileCommands().size() == 1 &&
- "Expected a compilation database with a single command!");
-  // FIXME: Avoid this copy.
-  std::vector CommandLine =
-  Compilations.getAllCompileCommands().front().CommandLine;
-
   MakeDependencyPrinterConsumer Consumer;
   auto Result =
   Worker.computeDependencies(CWD, CommandLine, Consumer, ModuleName);
@@ -126,7 +115,7 @@
 
 llvm::Expected
 DependencyScanningTool::getFullDependencies(
-const tooling::CompilationDatabase &Compilations, StringRef CWD,
+const std::vector &CommandLine, StringRef CWD,
 const llvm::StringSet<> &AlreadySeen,
 llvm::Optional ModuleName) {
   class FullDependencyPrinterConsumer : public DependencyConsumer {
@@ -191,17 +180,6 @@
 const llvm::StringSet<> &AlreadySeen;
   };
 
-  // We expect a single command here because if a source file occurs multiple
-  // times in the original CDB, then `computeDependencies` would run the
-  // `DependencyScanningAction` once for every time the input occured in the
-  // CDB. Instead we split up the CDB into single command chunks to avoid this
-  // behavio

[clang] 0ebf619 - [clang][deps] NFC: Remove CompilationDatabase from DependencyScanningTool API

2021-09-10 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2021-09-10T12:31:27+02:00
New Revision: 0ebf61963bb6cb95b4036061dbe476523f622987

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

LOG: [clang][deps] NFC: Remove CompilationDatabase from DependencyScanningTool 
API

This patch simplifies the dependency scanner API. Depends on D108980.

Reviewed By: dexonsmith

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

Added: 


Modified: 
clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
clang/tools/clang-scan-deps/ClangScanDeps.cpp

Removed: 




diff  --git 
a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h 
b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
index c26b6e91d90ce..9e2ff82f56144 100644
--- a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
+++ b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningTool.h
@@ -83,8 +83,8 @@ class DependencyScanningTool {
   /// \returns A \c StringError with the diagnostic output if clang errors
   /// occurred, dependency file contents otherwise.
   llvm::Expected
-  getDependencyFile(const tooling::CompilationDatabase &Compilations,
-StringRef CWD, llvm::Optional ModuleName = 
None);
+  getDependencyFile(const std::vector &CommandLine, StringRef CWD,
+llvm::Optional ModuleName = None);
 
   /// Collect the full module dependency graph for the input, ignoring any
   /// modules which have already been seen. If \p ModuleName isn't empty, this
@@ -99,7 +99,7 @@ class DependencyScanningTool {
   /// \returns a \c StringError with the diagnostic output if clang errors
   /// occurred, \c FullDependencies otherwise.
   llvm::Expected
-  getFullDependencies(const tooling::CompilationDatabase &Compilations,
+  getFullDependencies(const std::vector &CommandLine,
   StringRef CWD, const llvm::StringSet<> &AlreadySeen,
   llvm::Optional ModuleName = None);
 

diff  --git 
a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h 
b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
index 58f2f72da9717..88029e7f76ada 100644
--- a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
+++ b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
@@ -14,7 +14,6 @@
 #include "clang/Basic/LLVM.h"
 #include "clang/Frontend/PCHContainerOperations.h"
 #include "clang/Lex/PreprocessorExcludedConditionalDirectiveSkipMapping.h"
-#include "clang/Tooling/CompilationDatabase.h"
 #include "clang/Tooling/DependencyScanning/DependencyScanningService.h"
 #include "clang/Tooling/DependencyScanning/ModuleDepCollector.h"
 #include "llvm/Support/Error.h"
@@ -30,24 +29,6 @@ namespace dependencies {
 
 class DependencyScanningWorkerFilesystem;
 
-/// Compilation database that holds and reports a single compile command.
-class SingleCommandCompilationDatabase : public CompilationDatabase {
-  CompileCommand Command;
-
-public:
-  SingleCommandCompilationDatabase(CompileCommand Cmd)
-  : Command(std::move(Cmd)) {}
-
-  std::vector
-  getCompileCommands(StringRef FilePath) const override {
-return {Command};
-  }
-
-  std::vector getAllCompileCommands() const override {
-return {Command};
-  }
-};
-
 class DependencyConsumer {
 public:
   virtual ~DependencyConsumer() {}

diff  --git a/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp 
b/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
index b083d09c8bff3..391e68bb089f9 100644
--- a/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
+++ b/clang/lib/Tooling/DependencyScanning/DependencyScanningTool.cpp
@@ -50,7 +50,7 @@ DependencyScanningTool::DependencyScanningTool(
 : Worker(Service) {}
 
 llvm::Expected DependencyScanningTool::getDependencyFile(
-const tooling::CompilationDatabase &Compilations, StringRef CWD,
+const std::vector &CommandLine, StringRef CWD,
 llvm::Optional ModuleName) {
   /// Prints out all of the gathered dependencies into a string.
   class MakeDependencyPrinterConsumer : public DependencyConsumer {
@@ -103,17 +103,6 @@ llvm::Expected 
DependencyScanningTool::getDependencyFile(
 std::vector Dependencies;
   };
 
-  // We expect a single command here because if a source file occurs multiple
-  // times in the original CDB, then `computeDependencies` would run the
-  // `DependencyScanningAction` once for every time the input occured in the
-  // CDB. Instead we split up the CDB into single command chunks to avoid this
-  // behavior.
-  assert(C

[clang] a052bac - [clang][deps] NFC: Extract ModuleName initialization

2021-09-10 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2021-09-10T12:44:39+02:00
New Revision: a052bacc766f25fe9a765dd4710c83f1683c059e

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

LOG: [clang][deps] NFC: Extract ModuleName initialization

Added: 


Modified: 
clang/tools/clang-scan-deps/ClangScanDeps.cpp

Removed: 




diff  --git a/clang/tools/clang-scan-deps/ClangScanDeps.cpp 
b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
index 8f8906d89a66..6595efa182ce 100644
--- a/clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ b/clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -544,22 +544,19 @@ int main(int argc, const char **argv) {
   Filename = std::move(Input->Filename);
   CWD = std::move(Input->Directory);
 }
+Optional MaybeModuleName;
+if (!ModuleName.empty())
+  MaybeModuleName = ModuleName;
 // Run the tool on it.
 if (Format == ScanningOutputFormat::Make) {
   auto MaybeFile = WorkerTools[I]->getDependencyFile(
-  Input->CommandLine, CWD,
-  ModuleName.empty()
-  ? None
-  : llvm::Optional(ModuleName.c_str()));
+  Input->CommandLine, CWD, MaybeModuleName);
   if (handleMakeDependencyToolResult(Filename, MaybeFile, DependencyOS,
  Errs))
 HadErrors = true;
 } else {
   auto MaybeFullDeps = WorkerTools[I]->getFullDependencies(
-  Input->CommandLine, CWD, AlreadySeenModules,
-  ModuleName.empty()
-  ? None
-  : llvm::Optional(ModuleName.c_str()));
+  Input->CommandLine, CWD, AlreadySeenModules, MaybeModuleName);
   if (handleFullDependencyToolResult(Filename, MaybeFullDeps, FD,
  LocalIndex, DependencyOS, Errs))
 HadErrors = true;



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


[PATCH] D106809: [clang-offload-bundler] Make Bundle Entry ID backward compatible

2021-09-10 Thread Douglas Yung via Phabricator via cfe-commits
dyung added a comment.

In D106809#2994067 , @saiislam wrote:

> In D106809#2993666 , @kwk wrote:
>
>> @saiislam please have a look into why this happens. Is the 
>> `-debug-only=CodeObjectCompatibility` maybe a left-over of some sort?
>
> No, it is not a left-over. I was using this debug output to show that new and 
> old bundle entry ID formats are compatible with each other.
>
> I am taking a look on how to fix this. Thanks for pointing it out @RKSimon 
> and @kwk .

We are also seeing this issue on our internal build bot that builds a "release" 
configuration.

If you must use "-debug-only" in your test, a fix could be to add "REQUIRES: 
asserts" to the test, but that would mean the test would then be completely 
skipped in release builds. A better solution might be to break out the run line 
with "-debug-only" to a separate test file which does have a "REQUIRES: 
asserts" line so that we still run everything else that we can.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106809

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


[PATCH] D106809: [clang-offload-bundler] Make Bundle Entry ID backward compatible

2021-09-10 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam added a comment.

In D106809#2994169 , @dyung wrote:

> In D106809#2994067 , @saiislam 
> wrote:
>
>> In D106809#2993666 , @kwk wrote:
>>
>>> @saiislam please have a look into why this happens. Is the 
>>> `-debug-only=CodeObjectCompatibility` maybe a left-over of some sort?
>>
>> No, it is not a left-over. I was using this debug output to show that new 
>> and old bundle entry ID formats are compatible with each other.
>>
>> I am taking a look on how to fix this. Thanks for pointing it out @RKSimon 
>> and @kwk .
>
> We are also seeing this issue on our internal build bot that builds a 
> "release" configuration.
>
> If you must use "-debug-only" in your test, a fix could be to add "REQUIRES: 
> asserts" to the test, but that would mean the test would then be completely 
> skipped in release builds. A better solution might be to break out the run 
> line with "-debug-only" to a separate test file which does have a "REQUIRES: 
> asserts" line so that we still run everything else that we can.

Thanks for the suggestion. I am going to remove the -debug-only test because 
the same can be tested by changing bundler entry ID format in one of the tests 
above.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106809

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


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

2021-09-10 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia closed this revision.
Anastasia added a comment.

this is now on the release branch 
https://github.com/llvm/llvm-project/commit/9723fc15338e83737d0c5f7cbf415e7f1d9d1ec3


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

https://reviews.llvm.org/D109327

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


[PATCH] D109592: [clang-offload-bundler] Fix compatibility testing for non-assert builds

2021-09-10 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam created this revision.
saiislam added reviewers: RKSimon, kwk, dyung.
saiislam requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

Test using debug-only=CodeObjectComaptibility was failing in
non-assert builds, so it has been removed. Same testing has
been embedded in existing RUN lines and comment has been provided.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109592

Files:
  clang/test/Driver/clang-offload-bundler.c


Index: clang/test/Driver/clang-offload-bundler.c
===
--- clang/test/Driver/clang-offload-bundler.c
+++ clang/test/Driver/clang-offload-bundler.c
@@ -386,7 +386,11 @@
 // RUN: clang-offload-bundler -type=o 
-targets=host-%itanium_abi_triple,openmp-amdgcn-amd-amdhsa--gfx903 
-inputs=%t.o,%t.tgt1 -outputs=%t.simple1.bundle
 // RUN: llvm-ar cr %t.input-archive.a %t.simple.bundle %t.simple1.bundle
 
-// RUN: clang-offload-bundler -unbundle -type=a 
-targets=openmp-amdgcn-amd-amdhsa-gfx906,openmp-amdgcn-amd-amdhsa-gfx908 
-inputs=%t.input-archive.a 
-outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a
+// Test creation of device specific archive as well as compatibility between
+// Bundle Entry ID formats i.e. between presence/absence of extra hyphen in
+// case of missing environment field. Note that targets here are using
+// different bundle entry ID format as compared targets in input-archive.a
+// RUN: clang-offload-bundler -unbundle -type=a 
-targets=openmp-amdgcn-amd-amdhsa--gfx906,openmp-amdgcn-amd-amdhsa-gfx908 
-inputs=%t.input-archive.a 
-outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a
 // RUN: llvm-ar t %t-archive-gfx906-simple.a | FileCheck %s 
-check-prefix=GFX906
 // GFX906: simple-openmp-amdgcn-amd-amdhsa-gfx906
 // RUN: llvm-ar t %t-archive-gfx908-simple.a | FileCheck %s 
-check-prefix=GFX908
@@ -401,11 +405,6 @@
 // RUN: cat %t-archive-gfx803-empty.a | FileCheck %s -check-prefix=EMPTYARCHIVE
 // EMPTYARCHIVE: !
 
-// Tests to check compatibility between Bundle Entry ID formats i.e. between 
presence/absence of extra hyphen in case of missing environment field
-// RUN: clang-offload-bundler -unbundle -type=a 
-targets=openmp-amdgcn-amd-amdhsa--gfx906,openmp-amdgcn-amd-amdhsa-gfx908 
-inputs=%t.input-archive.a 
-outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a 
-debug-only=CodeObjectCompatibility 2>&1 | FileCheck %s 
-check-prefix=BUNDLECOMPATIBILITY
-// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa-gfx906]   :   [Target: 
openmp-amdgcn-amd-amdhsa--gfx906]
-// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa--gfx908]  :   [Target: 
openmp-amdgcn-amd-amdhsa-gfx908]
-
 // Some code so that we can create a binary out of this file.
 int A = 0;
 void test_func(void) {


Index: clang/test/Driver/clang-offload-bundler.c
===
--- clang/test/Driver/clang-offload-bundler.c
+++ clang/test/Driver/clang-offload-bundler.c
@@ -386,7 +386,11 @@
 // RUN: clang-offload-bundler -type=o -targets=host-%itanium_abi_triple,openmp-amdgcn-amd-amdhsa--gfx903 -inputs=%t.o,%t.tgt1 -outputs=%t.simple1.bundle
 // RUN: llvm-ar cr %t.input-archive.a %t.simple.bundle %t.simple1.bundle
 
-// RUN: clang-offload-bundler -unbundle -type=a -targets=openmp-amdgcn-amd-amdhsa-gfx906,openmp-amdgcn-amd-amdhsa-gfx908 -inputs=%t.input-archive.a -outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a
+// Test creation of device specific archive as well as compatibility between
+// Bundle Entry ID formats i.e. between presence/absence of extra hyphen in
+// case of missing environment field. Note that targets here are using
+// different bundle entry ID format as compared targets in input-archive.a
+// RUN: clang-offload-bundler -unbundle -type=a -targets=openmp-amdgcn-amd-amdhsa--gfx906,openmp-amdgcn-amd-amdhsa-gfx908 -inputs=%t.input-archive.a -outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a
 // RUN: llvm-ar t %t-archive-gfx906-simple.a | FileCheck %s -check-prefix=GFX906
 // GFX906: simple-openmp-amdgcn-amd-amdhsa-gfx906
 // RUN: llvm-ar t %t-archive-gfx908-simple.a | FileCheck %s -check-prefix=GFX908
@@ -401,11 +405,6 @@
 // RUN: cat %t-archive-gfx803-empty.a | FileCheck %s -check-prefix=EMPTYARCHIVE
 // EMPTYARCHIVE: !
 
-// Tests to check compatibility between Bundle Entry ID formats i.e. between presence/absence of extra hyphen in case of missing environment field
-// RUN: clang-offload-bundler -unbundle -type=a -targets=openmp-amdgcn-amd-amdhsa--gfx906,openmp-amdgcn-amd-amdhsa-gfx908 -inputs=%t.input-archive.a -outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a -debug-only=CodeObjectCompatibility 2>&1 | FileCheck %s -check-prefix=BUNDLECOMPATIBILITY
-// BUNDLECOMPATIBILITY: Compatible: Exact match:

[clang] cff03d5 - [OpenCL][Docs] Update OpenCL 3.0 implementation status.

2021-09-10 Thread Anastasia Stulova via cfe-commits

Author: Anastasia Stulova
Date: 2021-09-10T12:17:11+01:00
New Revision: cff03d5fc48700b73ae863d4f25e780e74dff33e

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

LOG: [OpenCL][Docs] Update OpenCL 3.0 implementation status.

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

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

Added: 


Modified: 
clang/docs/OpenCLSupport.rst

Removed: 




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

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

2021-09-10 Thread Anastasia Stulova via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGcff03d5fc487: [OpenCL][Docs] Update OpenCL 3.0 
implementation status. (authored by Anastasia).
Herald added a subscriber: ldrumm.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109320

Files:
  clang/docs/OpenCLSupport.rst


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

[clang] 9685631 - [OpenCL][Docs] Added ref to libclcxx

2021-09-10 Thread Anastasia Stulova via cfe-commits

Author: Anastasia Stulova
Date: 2021-09-10T12:29:11+01:00
New Revision: 9685631cbeb85592b713206dd660312dcb7bd9cb

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

LOG: [OpenCL][Docs] Added ref to libclcxx

Linked libclcxx GitHub project page in C++ libraries
for OpenCL section on OpenCLSupport page.

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

Added: 


Modified: 
clang/docs/OpenCLSupport.rst

Removed: 




diff  --git a/clang/docs/OpenCLSupport.rst b/clang/docs/OpenCLSupport.rst
index d9309df89a26..0d7ebca899f7 100644
--- a/clang/docs/OpenCLSupport.rst
+++ b/clang/docs/OpenCLSupport.rst
@@ -458,3 +458,7 @@ The possible clang invocation to compile the example is as 
follows:
 Note that `type_traits` is a header only library and therefore no extra
 linking step against the standard libraries is required. See full example
 in `Compiler Explorer `_.
+
+More OpenCL specific C++ library implementations built on top of libcxx
+are available in `libclcxx `_
+project.



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


[PATCH] D109526: [OpenCL][Docs] Added ref to libclcxx

2021-09-10 Thread Anastasia Stulova via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG9685631cbeb8: [OpenCL][Docs] Added ref to libclcxx (authored 
by Anastasia).
Herald added a subscriber: ldrumm.
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D109526?vs=371635&id=371872#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109526

Files:
  clang/docs/OpenCLSupport.rst


Index: clang/docs/OpenCLSupport.rst
===
--- clang/docs/OpenCLSupport.rst
+++ clang/docs/OpenCLSupport.rst
@@ -458,3 +458,7 @@
 Note that `type_traits` is a header only library and therefore no extra
 linking step against the standard libraries is required. See full example
 in `Compiler Explorer `_.
+
+More OpenCL specific C++ library implementations built on top of libcxx
+are available in `libclcxx `_
+project.


Index: clang/docs/OpenCLSupport.rst
===
--- clang/docs/OpenCLSupport.rst
+++ clang/docs/OpenCLSupport.rst
@@ -458,3 +458,7 @@
 Note that `type_traits` is a header only library and therefore no extra
 linking step against the standard libraries is required. See full example
 in `Compiler Explorer `_.
+
+More OpenCL specific C++ library implementations built on top of libcxx
+are available in `libclcxx `_
+project.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] e08911e - [clang][tooling] Accept custom diagnostic options in ToolInvocation

2021-09-10 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2021-09-10T13:31:17+02:00
New Revision: e08911e17b2bf7030a587bbf158e6a4fe0164f38

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

LOG: [clang][tooling] Accept custom diagnostic options in ToolInvocation

This patch allows the clients of `ToolInvocation` to provide custom diagnostic 
options to be used during driver -> cc1 command-line transformation and parsing.

Tests covering this functionality are in a follow-up commit. To make this 
testable, the `DiagnosticsEngine` needs to be properly initialized via 
`CompilerInstance::createDiagnostics`.

Reviewed By: dexonsmith, arphaman

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

Added: 


Modified: 
clang/include/clang/Tooling/Tooling.h
clang/lib/Tooling/Tooling.cpp

Removed: 




diff  --git a/clang/include/clang/Tooling/Tooling.h 
b/clang/include/clang/Tooling/Tooling.h
index 73d09662562b..56880724fbe3 100644
--- a/clang/include/clang/Tooling/Tooling.h
+++ b/clang/include/clang/Tooling/Tooling.h
@@ -268,11 +268,17 @@ class ToolInvocation {
 
   ~ToolInvocation();
 
-  /// Set a \c DiagnosticConsumer to use during parsing.
+  /// Set a \c DiagnosticConsumer to use during driver command-line parsing and
+  /// the action invocation itself.
   void setDiagnosticConsumer(DiagnosticConsumer *DiagConsumer) {
 this->DiagConsumer = DiagConsumer;
   }
 
+  /// Set a \c DiagnosticOptions to use during driver command-line parsing.
+  void setDiagnosticOptions(DiagnosticOptions *DiagOpts) {
+this->DiagOpts = DiagOpts;
+  }
+
   /// Run the clang invocation.
   ///
   /// \returns True if there were no errors during execution.
@@ -290,6 +296,7 @@ class ToolInvocation {
   FileManager *Files;
   std::shared_ptr PCHContainerOps;
   DiagnosticConsumer *DiagConsumer = nullptr;
+  DiagnosticOptions *DiagOpts = nullptr;
 };
 
 /// Utility to run a FrontendAction over a set of files.

diff  --git a/clang/lib/Tooling/Tooling.cpp b/clang/lib/Tooling/Tooling.cpp
index 2a051c4e2b29..383fb59fd4f3 100644
--- a/clang/lib/Tooling/Tooling.cpp
+++ b/clang/lib/Tooling/Tooling.cpp
@@ -343,10 +343,17 @@ bool ToolInvocation::run() {
   for (const std::string &Str : CommandLine)
 Argv.push_back(Str.c_str());
   const char *const BinaryName = Argv[0];
-  IntrusiveRefCntPtr DiagOpts =
-  CreateAndPopulateDiagOpts(Argv);
-  TextDiagnosticPrinter DiagnosticPrinter(
-  llvm::errs(), &*DiagOpts);
+
+  // Parse diagnostic options from the driver command-line only if none were
+  // explicitly set.
+  IntrusiveRefCntPtr ParsedDiagOpts;
+  DiagnosticOptions *DiagOpts = this->DiagOpts;
+  if (!DiagOpts) {
+ParsedDiagOpts = CreateAndPopulateDiagOpts(Argv);
+DiagOpts = &*ParsedDiagOpts;
+  }
+
+  TextDiagnosticPrinter DiagnosticPrinter(llvm::errs(), DiagOpts);
   DiagnosticsEngine Diagnostics(
   IntrusiveRefCntPtr(new DiagnosticIDs()), &*DiagOpts,
   DiagConsumer ? DiagConsumer : &DiagnosticPrinter, false);



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


[PATCH] D108976: [clang][tooling] Accept custom diagnostic options in ToolInvocation

2021-09-10 Thread Jan Svoboda 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 rGe08911e17b2b: [clang][tooling] Accept custom diagnostic 
options in ToolInvocation (authored by jansvoboda11).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108976

Files:
  clang/include/clang/Tooling/Tooling.h
  clang/lib/Tooling/Tooling.cpp


Index: clang/lib/Tooling/Tooling.cpp
===
--- clang/lib/Tooling/Tooling.cpp
+++ clang/lib/Tooling/Tooling.cpp
@@ -343,10 +343,17 @@
   for (const std::string &Str : CommandLine)
 Argv.push_back(Str.c_str());
   const char *const BinaryName = Argv[0];
-  IntrusiveRefCntPtr DiagOpts =
-  CreateAndPopulateDiagOpts(Argv);
-  TextDiagnosticPrinter DiagnosticPrinter(
-  llvm::errs(), &*DiagOpts);
+
+  // Parse diagnostic options from the driver command-line only if none were
+  // explicitly set.
+  IntrusiveRefCntPtr ParsedDiagOpts;
+  DiagnosticOptions *DiagOpts = this->DiagOpts;
+  if (!DiagOpts) {
+ParsedDiagOpts = CreateAndPopulateDiagOpts(Argv);
+DiagOpts = &*ParsedDiagOpts;
+  }
+
+  TextDiagnosticPrinter DiagnosticPrinter(llvm::errs(), DiagOpts);
   DiagnosticsEngine Diagnostics(
   IntrusiveRefCntPtr(new DiagnosticIDs()), &*DiagOpts,
   DiagConsumer ? DiagConsumer : &DiagnosticPrinter, false);
Index: clang/include/clang/Tooling/Tooling.h
===
--- clang/include/clang/Tooling/Tooling.h
+++ clang/include/clang/Tooling/Tooling.h
@@ -268,11 +268,17 @@
 
   ~ToolInvocation();
 
-  /// Set a \c DiagnosticConsumer to use during parsing.
+  /// Set a \c DiagnosticConsumer to use during driver command-line parsing and
+  /// the action invocation itself.
   void setDiagnosticConsumer(DiagnosticConsumer *DiagConsumer) {
 this->DiagConsumer = DiagConsumer;
   }
 
+  /// Set a \c DiagnosticOptions to use during driver command-line parsing.
+  void setDiagnosticOptions(DiagnosticOptions *DiagOpts) {
+this->DiagOpts = DiagOpts;
+  }
+
   /// Run the clang invocation.
   ///
   /// \returns True if there were no errors during execution.
@@ -290,6 +296,7 @@
   FileManager *Files;
   std::shared_ptr PCHContainerOps;
   DiagnosticConsumer *DiagConsumer = nullptr;
+  DiagnosticOptions *DiagOpts = nullptr;
 };
 
 /// Utility to run a FrontendAction over a set of files.


Index: clang/lib/Tooling/Tooling.cpp
===
--- clang/lib/Tooling/Tooling.cpp
+++ clang/lib/Tooling/Tooling.cpp
@@ -343,10 +343,17 @@
   for (const std::string &Str : CommandLine)
 Argv.push_back(Str.c_str());
   const char *const BinaryName = Argv[0];
-  IntrusiveRefCntPtr DiagOpts =
-  CreateAndPopulateDiagOpts(Argv);
-  TextDiagnosticPrinter DiagnosticPrinter(
-  llvm::errs(), &*DiagOpts);
+
+  // Parse diagnostic options from the driver command-line only if none were
+  // explicitly set.
+  IntrusiveRefCntPtr ParsedDiagOpts;
+  DiagnosticOptions *DiagOpts = this->DiagOpts;
+  if (!DiagOpts) {
+ParsedDiagOpts = CreateAndPopulateDiagOpts(Argv);
+DiagOpts = &*ParsedDiagOpts;
+  }
+
+  TextDiagnosticPrinter DiagnosticPrinter(llvm::errs(), DiagOpts);
   DiagnosticsEngine Diagnostics(
   IntrusiveRefCntPtr(new DiagnosticIDs()), &*DiagOpts,
   DiagConsumer ? DiagConsumer : &DiagnosticPrinter, false);
Index: clang/include/clang/Tooling/Tooling.h
===
--- clang/include/clang/Tooling/Tooling.h
+++ clang/include/clang/Tooling/Tooling.h
@@ -268,11 +268,17 @@
 
   ~ToolInvocation();
 
-  /// Set a \c DiagnosticConsumer to use during parsing.
+  /// Set a \c DiagnosticConsumer to use during driver command-line parsing and
+  /// the action invocation itself.
   void setDiagnosticConsumer(DiagnosticConsumer *DiagConsumer) {
 this->DiagConsumer = DiagConsumer;
   }
 
+  /// Set a \c DiagnosticOptions to use during driver command-line parsing.
+  void setDiagnosticOptions(DiagnosticOptions *DiagOpts) {
+this->DiagOpts = DiagOpts;
+  }
+
   /// Run the clang invocation.
   ///
   /// \returns True if there were no errors during execution.
@@ -290,6 +296,7 @@
   FileManager *Files;
   std::shared_ptr PCHContainerOps;
   DiagnosticConsumer *DiagConsumer = nullptr;
+  DiagnosticOptions *DiagOpts = nullptr;
 };
 
 /// Utility to run a FrontendAction over a set of files.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D108621: [HIPSPV] Add CUDA->SPIR-V address space mapping

2021-09-10 Thread Henry Linjamäki via Phabricator via cfe-commits
linjamaki updated this revision to Diff 371877.
linjamaki added a comment.

Enable HIP-to-SPIR-V address space mapping only for SPIR-V targets.

Patch now depends on D109144 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108621

Files:
  clang/lib/Basic/Targets/SPIR.h
  clang/test/CodeGenHIP/hipspv-addr-spaces.cpp


Index: clang/test/CodeGenHIP/hipspv-addr-spaces.cpp
===
--- /dev/null
+++ clang/test/CodeGenHIP/hipspv-addr-spaces.cpp
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 -triple spirv64 -x hip -emit-llvm -fcuda-is-device \
+// RUN:   -o - %s | FileCheck %s
+
+#define __device__ __attribute__((device))
+#define __shared__ __attribute__((shared))
+#define __constant__ __attribute__((constant))
+
+// CHECK: %struct.foo_t = type { i32, i32 addrspace(4)* }
+
+// CHECK: @d ={{.*}} addrspace(1) externally_initialized global
+__device__ int d;
+
+// CHECK: @c ={{.*}} addrspace(1) externally_initialized global
+__constant__ int c;
+
+// CHECK: @s ={{.*}} addrspace(3) global
+__shared__ int s;
+
+// CHECK: @foo ={{.*}} addrspace(1) externally_initialized global %struct.foo_t
+__device__ struct foo_t {
+  int i;
+  int* pi;
+} foo;
+
+// CHECK: define{{.*}} spir_func i32 addrspace(4)* @_Z3barPi(i32 addrspace(4)*
+__device__ int* bar(int *x) {
+  return x;
+}
+
+// CHECK: define{{.*}} spir_func i32 addrspace(4)* @_Z5baz_dv()
+__device__ int* baz_d() {
+  // CHECK: ret i32 addrspace(4)* addrspacecast (i32 addrspace(1)* @d to i32 
addrspace(4)*
+  return &d;
+}
+
+// CHECK: define{{.*}} spir_func i32 addrspace(4)* @_Z5baz_cv()
+__device__ int* baz_c() {
+  // CHECK: ret i32 addrspace(4)* addrspacecast (i32 addrspace(1)* @c to i32 
addrspace(4)*
+  return &c;
+}
+
+// CHECK: define{{.*}} spir_func i32 addrspace(4)* @_Z5baz_sv()
+__device__ int* baz_s() {
+  // CHECK: ret i32 addrspace(4)* addrspacecast (i32 addrspace(3)* @s to i32 
addrspace(4)*
+  return &s;
+}
Index: clang/lib/Basic/Targets/SPIR.h
===
--- clang/lib/Basic/Targets/SPIR.h
+++ clang/lib/Basic/Targets/SPIR.h
@@ -56,9 +56,14 @@
 0, // opencl_generic
 0, // opencl_global_device
 0, // opencl_global_host
-0, // cuda_device
-0, // cuda_constant
-0, // cuda_shared
+// cuda_* address space mapping is intended for HIPSPV (HIP to SPIR-V
+// translation). This mapping is enabled when the language mode is HIP.
+1, // cuda_device
+// cuda_constant pointer can be casted to default/"flat" pointer, but in
+// SPIR-V casts between constant and generic pointers are not allowed. For
+// this reason cuda_constant is mapped to SPIR-V CrossWorkgroup.
+1, // cuda_constant
+3, // cuda_shared
 1, // sycl_global
 5, // sycl_global_device
 6, // sycl_global_host
@@ -219,6 +224,16 @@
   bool hasFeature(StringRef Feature) const override {
 return Feature == "spirv";
   }
+
+  void adjust(DiagnosticsEngine &Diags, LangOptions &Opts) override {
+BaseSPIRTargetInfo::adjust(Diags, Opts);
+// Guarded so we don't override address space map setting set by
+// BaseSPIRTargetInfo::adjust.
+if (Opts.HIP && Opts.CUDAIsDevice)
+  // Enable address space mapping from HIP to SPIR-V.
+  // See comment on the SPIRDefIsGenMap table.
+  setAddressSpaceMap(/*DefaultIsGeneric=*/true);
+  }
 };
 
 class LLVM_LIBRARY_VISIBILITY SPIRV32TargetInfo : public SPIRVTargetInfo {


Index: clang/test/CodeGenHIP/hipspv-addr-spaces.cpp
===
--- /dev/null
+++ clang/test/CodeGenHIP/hipspv-addr-spaces.cpp
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 -triple spirv64 -x hip -emit-llvm -fcuda-is-device \
+// RUN:   -o - %s | FileCheck %s
+
+#define __device__ __attribute__((device))
+#define __shared__ __attribute__((shared))
+#define __constant__ __attribute__((constant))
+
+// CHECK: %struct.foo_t = type { i32, i32 addrspace(4)* }
+
+// CHECK: @d ={{.*}} addrspace(1) externally_initialized global
+__device__ int d;
+
+// CHECK: @c ={{.*}} addrspace(1) externally_initialized global
+__constant__ int c;
+
+// CHECK: @s ={{.*}} addrspace(3) global
+__shared__ int s;
+
+// CHECK: @foo ={{.*}} addrspace(1) externally_initialized global %struct.foo_t
+__device__ struct foo_t {
+  int i;
+  int* pi;
+} foo;
+
+// CHECK: define{{.*}} spir_func i32 addrspace(4)* @_Z3barPi(i32 addrspace(4)*
+__device__ int* bar(int *x) {
+  return x;
+}
+
+// CHECK: define{{.*}} spir_func i32 addrspace(4)* @_Z5baz_dv()
+__device__ int* baz_d() {
+  // CHECK: ret i32 addrspace(4)* addrspacecast (i32 addrspace(1)* @d to i32 addrspace(4)*
+  return &d;
+}
+
+// CHECK: define{{.*}} spir_func i32 addrspace(4)* @_Z5baz_cv()
+__device__ int* baz_c() {
+  // CHECK: ret i32 addrspace(4)* addrspacecast (i32 addrspace(1)* @c to i32 addrspace(4)*
+  return &c;
+

[clang] 1e760b5 - [clang][deps] Use correct DiagnosticOptions for command-line handling

2021-09-10 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2021-09-10T13:44:35+02:00
New Revision: 1e760b5902615c38079948f31a96724a88a75dd8

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

LOG: [clang][deps] Use correct DiagnosticOptions for command-line handling

In this patch the dependency scanner starts using proper `DiagnosticOptions` 
parsed from the actual TU command-line in order to mimic what the actual 
compiler would do. The actual functionality will be enabled and tested in 
follow-up patches. (This split is necessary to avoid temporary regression.)

Depends on D108976.

Reviewed By: dexonsmith, arphaman

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

Added: 


Modified: 
clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp

Removed: 




diff  --git 
a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h 
b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
index 88029e7f76ad..824013fd6081 100644
--- a/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
+++ b/clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
@@ -68,7 +68,6 @@ class DependencyScanningWorker {
   llvm::Optional ModuleName = None);
 
 private:
-  IntrusiveRefCntPtr DiagOpts;
   std::shared_ptr PCHContainerOps;
   std::unique_ptr PPSkipMappings;
 

diff  --git a/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp 
b/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
index c8aa801ed5d6..faf7d36bf87b 100644
--- a/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ b/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -276,8 +276,6 @@ class DependencyScanningAction : public tooling::ToolAction 
{
 DependencyScanningWorker::DependencyScanningWorker(
 DependencyScanningService &Service)
 : Format(Service.getFormat()) {
-  DiagOpts = new DiagnosticOptions();
-
   PCHContainerOps = std::make_shared();
   PCHContainerOps->registerReader(
   std::make_unique());
@@ -302,16 +300,20 @@ DependencyScanningWorker::DependencyScanningWorker(
 Files = new FileManager(FileSystemOptions(), RealFS);
 }
 
-static llvm::Error runWithDiags(
-DiagnosticOptions *DiagOpts,
-llvm::function_ref BodyShouldSucceed) {
+static llvm::Error
+runWithDiags(DiagnosticOptions *DiagOpts,
+ llvm::function_ref
+ BodyShouldSucceed) {
+  // Avoid serializing diagnostics.
+  DiagOpts->DiagnosticSerializationFile.clear();
+
   // Capture the emitted diagnostics and report them to the client
   // in the case of a failure.
   std::string DiagnosticOutput;
   llvm::raw_string_ostream DiagnosticsOS(DiagnosticOutput);
   TextDiagnosticPrinter DiagPrinter(DiagnosticsOS, DiagOpts);
 
-  if (BodyShouldSucceed(DiagPrinter))
+  if (BodyShouldSucceed(DiagPrinter, *DiagOpts))
 return llvm::Error::success();
   return llvm::make_error(DiagnosticsOS.str(),
  llvm::inconvertibleErrorCode());
@@ -338,15 +340,24 @@ llvm::Error DependencyScanningWorker::computeDependencies(
   const std::vector &FinalCommandLine =
   ModifiedCommandLine ? *ModifiedCommandLine : CommandLine;
 
-  return runWithDiags(DiagOpts.get(), [&](DiagnosticConsumer &DC) {
-DependencyScanningAction Action(WorkingDirectory, Consumer, DepFS,
-PPSkipMappings.get(), Format, ModuleName);
-// Create an invocation that uses the underlying file system to ensure that
-// any file system requests that are made by the driver do not go through
-// the dependency scanning filesystem.
-ToolInvocation Invocation(FinalCommandLine, &Action, CurrentFiles.get(),
-  PCHContainerOps);
-Invocation.setDiagnosticConsumer(&DC);
-return Invocation.run();
-  });
+  std::vector FinalCCommandLine(CommandLine.size(), nullptr);
+  llvm::transform(CommandLine, FinalCCommandLine.begin(),
+  [](const std::string &Str) { return Str.c_str(); });
+
+  return runWithDiags(CreateAndPopulateDiagOpts(FinalCCommandLine).release(),
+  [&](DiagnosticConsumer &DC, DiagnosticOptions &DiagOpts) 
{
+DependencyScanningAction Action(
+WorkingDirectory, Consumer, DepFS,
+PPSkipMappings.get(), Format, ModuleName);
+// Create an invocation that uses the underlying file
+// system to ensure that any file system requests that
+// are made by the driver do not go through the
+// dependency scannin

[PATCH] D108982: [clang][deps] Use correct DiagnosticOptions for command-line handling

2021-09-10 Thread Jan Svoboda 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 rG1e760b590261: [clang][deps] Use correct DiagnosticOptions 
for command-line handling (authored by jansvoboda11).

Changed prior to commit:
  https://reviews.llvm.org/D108982?vs=370260&id=371879#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108982

Files:
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp


Index: clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -276,8 +276,6 @@
 DependencyScanningWorker::DependencyScanningWorker(
 DependencyScanningService &Service)
 : Format(Service.getFormat()) {
-  DiagOpts = new DiagnosticOptions();
-
   PCHContainerOps = std::make_shared();
   PCHContainerOps->registerReader(
   std::make_unique());
@@ -302,16 +300,20 @@
 Files = new FileManager(FileSystemOptions(), RealFS);
 }
 
-static llvm::Error runWithDiags(
-DiagnosticOptions *DiagOpts,
-llvm::function_ref BodyShouldSucceed) {
+static llvm::Error
+runWithDiags(DiagnosticOptions *DiagOpts,
+ llvm::function_ref
+ BodyShouldSucceed) {
+  // Avoid serializing diagnostics.
+  DiagOpts->DiagnosticSerializationFile.clear();
+
   // Capture the emitted diagnostics and report them to the client
   // in the case of a failure.
   std::string DiagnosticOutput;
   llvm::raw_string_ostream DiagnosticsOS(DiagnosticOutput);
   TextDiagnosticPrinter DiagPrinter(DiagnosticsOS, DiagOpts);
 
-  if (BodyShouldSucceed(DiagPrinter))
+  if (BodyShouldSucceed(DiagPrinter, *DiagOpts))
 return llvm::Error::success();
   return llvm::make_error(DiagnosticsOS.str(),
  llvm::inconvertibleErrorCode());
@@ -338,15 +340,24 @@
   const std::vector &FinalCommandLine =
   ModifiedCommandLine ? *ModifiedCommandLine : CommandLine;
 
-  return runWithDiags(DiagOpts.get(), [&](DiagnosticConsumer &DC) {
-DependencyScanningAction Action(WorkingDirectory, Consumer, DepFS,
-PPSkipMappings.get(), Format, ModuleName);
-// Create an invocation that uses the underlying file system to ensure that
-// any file system requests that are made by the driver do not go through
-// the dependency scanning filesystem.
-ToolInvocation Invocation(FinalCommandLine, &Action, CurrentFiles.get(),
-  PCHContainerOps);
-Invocation.setDiagnosticConsumer(&DC);
-return Invocation.run();
-  });
+  std::vector FinalCCommandLine(CommandLine.size(), nullptr);
+  llvm::transform(CommandLine, FinalCCommandLine.begin(),
+  [](const std::string &Str) { return Str.c_str(); });
+
+  return runWithDiags(CreateAndPopulateDiagOpts(FinalCCommandLine).release(),
+  [&](DiagnosticConsumer &DC, DiagnosticOptions &DiagOpts) 
{
+DependencyScanningAction Action(
+WorkingDirectory, Consumer, DepFS,
+PPSkipMappings.get(), Format, ModuleName);
+// Create an invocation that uses the underlying file
+// system to ensure that any file system requests that
+// are made by the driver do not go through the
+// dependency scanning filesystem.
+ToolInvocation Invocation(FinalCommandLine, &Action,
+  CurrentFiles.get(),
+  PCHContainerOps);
+Invocation.setDiagnosticConsumer(&DC);
+Invocation.setDiagnosticOptions(&DiagOpts);
+return Invocation.run();
+  });
 }
Index: clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
===
--- clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
+++ clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
@@ -68,7 +68,6 @@
   llvm::Optional ModuleName = None);
 
 private:
-  IntrusiveRefCntPtr DiagOpts;
   std::shared_ptr PCHContainerOps;
   std::unique_ptr PPSkipMappings;
 


Index: clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -276,8 +276,

[clang] 8dc76ab - [clang][tooling] Properly initialize DiagnosticsEngine for cc1 command-line construction

2021-09-10 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2021-09-10T13:54:24+02:00
New Revision: 8dc76ab7995b6dbc50dd9472f95c40484396b90e

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

LOG: [clang][tooling] Properly initialize DiagnosticsEngine for cc1 
command-line construction

In `ToolInvocation::run`, the driver -> cc1 command-line transformation uses 
`DiagnosticsEngine` that wasn't completely initialized. This patch ensures 
`ProcessWarningOptions(DiagnosticsEngine&, const DiagnosticOptions &)` is 
called.

Depends on D108982.

Reviewed By: dexonsmith

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

Added: 


Modified: 
clang/lib/Tooling/Tooling.cpp
clang/unittests/Tooling/ToolingTest.cpp

Removed: 




diff  --git a/clang/lib/Tooling/Tooling.cpp b/clang/lib/Tooling/Tooling.cpp
index 383fb59fd4f3b..6314615f83c86 100644
--- a/clang/lib/Tooling/Tooling.cpp
+++ b/clang/lib/Tooling/Tooling.cpp
@@ -354,16 +354,16 @@ bool ToolInvocation::run() {
   }
 
   TextDiagnosticPrinter DiagnosticPrinter(llvm::errs(), DiagOpts);
-  DiagnosticsEngine Diagnostics(
-  IntrusiveRefCntPtr(new DiagnosticIDs()), &*DiagOpts,
-  DiagConsumer ? DiagConsumer : &DiagnosticPrinter, false);
+  IntrusiveRefCntPtr Diagnostics =
+  CompilerInstance::createDiagnostics(
+  &*DiagOpts, DiagConsumer ? DiagConsumer : &DiagnosticPrinter, false);
   // Although `Diagnostics` are used only for command-line parsing, the custom
   // `DiagConsumer` might expect a `SourceManager` to be present.
-  SourceManager SrcMgr(Diagnostics, *Files);
-  Diagnostics.setSourceManager(&SrcMgr);
+  SourceManager SrcMgr(*Diagnostics, *Files);
+  Diagnostics->setSourceManager(&SrcMgr);
 
   const std::unique_ptr Driver(
-  newDriver(&Diagnostics, BinaryName, &Files->getVirtualFileSystem()));
+  newDriver(&*Diagnostics, BinaryName, &Files->getVirtualFileSystem()));
   // The "input file not found" diagnostics from the driver are useful.
   // The driver is only aware of the VFS working directory, but some clients
   // change this at the FileManager level instead.
@@ -375,11 +375,11 @@ bool ToolInvocation::run() {
   if (!Compilation)
 return false;
   const llvm::opt::ArgStringList *const CC1Args = getCC1Arguments(
-  &Diagnostics, Compilation.get());
+  &*Diagnostics, Compilation.get());
   if (!CC1Args)
 return false;
   std::unique_ptr Invocation(
-  newInvocation(&Diagnostics, *CC1Args, BinaryName));
+  newInvocation(&*Diagnostics, *CC1Args, BinaryName));
   return runInvocation(BinaryName, Compilation.get(), std::move(Invocation),
std::move(PCHContainerOps));
 }

diff  --git a/clang/unittests/Tooling/ToolingTest.cpp 
b/clang/unittests/Tooling/ToolingTest.cpp
index fe85304860069..d5aa8b763669a 100644
--- a/clang/unittests/Tooling/ToolingTest.cpp
+++ b/clang/unittests/Tooling/ToolingTest.cpp
@@ -224,6 +224,82 @@ TEST(ToolInvocation, TestVirtualModulesCompilation) {
   EXPECT_TRUE(Invocation.run());
 }
 
+struct ErrorCountingDiagnosticConsumer : public DiagnosticConsumer {
+  ErrorCountingDiagnosticConsumer() : NumErrorsSeen(0) {}
+  void HandleDiagnostic(DiagnosticsEngine::Level DiagLevel,
+const Diagnostic &Info) override {
+if (DiagLevel == DiagnosticsEngine::Level::Error)
+  ++NumErrorsSeen;
+  }
+  unsigned NumErrorsSeen;
+};
+
+TEST(ToolInvocation, DiagnosticsEngineProperlyInitializedForCC1Construction) {
+  llvm::IntrusiveRefCntPtr OverlayFileSystem(
+  new llvm::vfs::OverlayFileSystem(llvm::vfs::getRealFileSystem()));
+  llvm::IntrusiveRefCntPtr InMemoryFileSystem(
+  new llvm::vfs::InMemoryFileSystem);
+  OverlayFileSystem->pushOverlay(InMemoryFileSystem);
+  llvm::IntrusiveRefCntPtr Files(
+  new FileManager(FileSystemOptions(), OverlayFileSystem));
+
+  std::vector Args;
+  Args.push_back("tool-executable");
+  Args.push_back("-target");
+  // Invalid argument that by default results in an error diagnostic:
+  Args.push_back("i386-apple-ios14.0-simulator");
+  // Argument that downgrades the error into a warning:
+  Args.push_back("-Wno-error=invalid-ios-deployment-target");
+  Args.push_back("-fsyntax-only");
+  Args.push_back("test.cpp");
+
+  clang::tooling::ToolInvocation Invocation(
+  Args, std::make_unique(), Files.get());
+  InMemoryFileSystem->addFile(
+  "test.cpp", 0, llvm::MemoryBuffer::getMemBuffer("int a() {}\n"));
+  ErrorCountingDiagnosticConsumer Consumer;
+  Invocation.setDiagnosticConsumer(&Consumer);
+  EXPECT_TRUE(Invocation.run());
+  // Check that `-Wno-error=invalid-ios-deployment-target` downgraded the error
+  // into a warning.
+  EXPECT_EQ(Consumer.NumErrorsSeen, 0u);
+}
+
+TEST(ToolInvocation, CustomDiagnosticOptionsOverwriteParsedOnes) {
+  llvm::IntrusiveRefCntPtr OverlayFileSy

[PATCH] D108974: [clang][tooling] Properly initialize DiagnosticsEngine for cc1 command-line construction

2021-09-10 Thread Jan Svoboda 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 rG8dc76ab7995b: [clang][tooling] Properly initialize 
DiagnosticsEngine for cc1 command-line… (authored by jansvoboda11).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108974

Files:
  clang/lib/Tooling/Tooling.cpp
  clang/unittests/Tooling/ToolingTest.cpp

Index: clang/unittests/Tooling/ToolingTest.cpp
===
--- clang/unittests/Tooling/ToolingTest.cpp
+++ clang/unittests/Tooling/ToolingTest.cpp
@@ -224,6 +224,82 @@
   EXPECT_TRUE(Invocation.run());
 }
 
+struct ErrorCountingDiagnosticConsumer : public DiagnosticConsumer {
+  ErrorCountingDiagnosticConsumer() : NumErrorsSeen(0) {}
+  void HandleDiagnostic(DiagnosticsEngine::Level DiagLevel,
+const Diagnostic &Info) override {
+if (DiagLevel == DiagnosticsEngine::Level::Error)
+  ++NumErrorsSeen;
+  }
+  unsigned NumErrorsSeen;
+};
+
+TEST(ToolInvocation, DiagnosticsEngineProperlyInitializedForCC1Construction) {
+  llvm::IntrusiveRefCntPtr OverlayFileSystem(
+  new llvm::vfs::OverlayFileSystem(llvm::vfs::getRealFileSystem()));
+  llvm::IntrusiveRefCntPtr InMemoryFileSystem(
+  new llvm::vfs::InMemoryFileSystem);
+  OverlayFileSystem->pushOverlay(InMemoryFileSystem);
+  llvm::IntrusiveRefCntPtr Files(
+  new FileManager(FileSystemOptions(), OverlayFileSystem));
+
+  std::vector Args;
+  Args.push_back("tool-executable");
+  Args.push_back("-target");
+  // Invalid argument that by default results in an error diagnostic:
+  Args.push_back("i386-apple-ios14.0-simulator");
+  // Argument that downgrades the error into a warning:
+  Args.push_back("-Wno-error=invalid-ios-deployment-target");
+  Args.push_back("-fsyntax-only");
+  Args.push_back("test.cpp");
+
+  clang::tooling::ToolInvocation Invocation(
+  Args, std::make_unique(), Files.get());
+  InMemoryFileSystem->addFile(
+  "test.cpp", 0, llvm::MemoryBuffer::getMemBuffer("int a() {}\n"));
+  ErrorCountingDiagnosticConsumer Consumer;
+  Invocation.setDiagnosticConsumer(&Consumer);
+  EXPECT_TRUE(Invocation.run());
+  // Check that `-Wno-error=invalid-ios-deployment-target` downgraded the error
+  // into a warning.
+  EXPECT_EQ(Consumer.NumErrorsSeen, 0u);
+}
+
+TEST(ToolInvocation, CustomDiagnosticOptionsOverwriteParsedOnes) {
+  llvm::IntrusiveRefCntPtr OverlayFileSystem(
+  new llvm::vfs::OverlayFileSystem(llvm::vfs::getRealFileSystem()));
+  llvm::IntrusiveRefCntPtr InMemoryFileSystem(
+  new llvm::vfs::InMemoryFileSystem);
+  OverlayFileSystem->pushOverlay(InMemoryFileSystem);
+  llvm::IntrusiveRefCntPtr Files(
+  new FileManager(FileSystemOptions(), OverlayFileSystem));
+
+  std::vector Args;
+  Args.push_back("tool-executable");
+  Args.push_back("-target");
+  // Invalid argument that by default results in an error diagnostic:
+  Args.push_back("i386-apple-ios14.0-simulator");
+  // Argument that downgrades the error into a warning:
+  Args.push_back("-Wno-error=invalid-ios-deployment-target");
+  Args.push_back("-fsyntax-only");
+  Args.push_back("test.cpp");
+
+  clang::tooling::ToolInvocation Invocation(
+  Args, std::make_unique(), Files.get());
+  InMemoryFileSystem->addFile(
+  "test.cpp", 0, llvm::MemoryBuffer::getMemBuffer("int a() {}\n"));
+  ErrorCountingDiagnosticConsumer Consumer;
+  Invocation.setDiagnosticConsumer(&Consumer);
+
+  auto DiagOpts = llvm::makeIntrusiveRefCnt();
+  Invocation.setDiagnosticOptions(&*DiagOpts);
+
+  EXPECT_TRUE(Invocation.run());
+  // Check that `-Wno-error=invalid-ios-deployment-target` didn't downgrade the
+  // error into a warning due to being overwritten by custom diagnostic options.
+  EXPECT_EQ(Consumer.NumErrorsSeen, 1u);
+}
+
 struct DiagnosticConsumerExpectingSourceManager : public DiagnosticConsumer {
   bool SawSourceManager;
 
Index: clang/lib/Tooling/Tooling.cpp
===
--- clang/lib/Tooling/Tooling.cpp
+++ clang/lib/Tooling/Tooling.cpp
@@ -354,16 +354,16 @@
   }
 
   TextDiagnosticPrinter DiagnosticPrinter(llvm::errs(), DiagOpts);
-  DiagnosticsEngine Diagnostics(
-  IntrusiveRefCntPtr(new DiagnosticIDs()), &*DiagOpts,
-  DiagConsumer ? DiagConsumer : &DiagnosticPrinter, false);
+  IntrusiveRefCntPtr Diagnostics =
+  CompilerInstance::createDiagnostics(
+  &*DiagOpts, DiagConsumer ? DiagConsumer : &DiagnosticPrinter, false);
   // Although `Diagnostics` are used only for command-line parsing, the custom
   // `DiagConsumer` might expect a `SourceManager` to be present.
-  SourceManager SrcMgr(Diagnostics, *Files);
-  Diagnostics.setSourceManager(&SrcMgr);
+  SourceManager SrcMgr(*Diagnostics, *Files);
+  Diagnostics->setSourceManager(&SrcMgr);
 
   const std::unique_ptr Driver(
-  newDriver(&Diagno

[clang] fbe00c6 - [OpenCL][Docs] Update OpenCL 3.0 status info.

2021-09-10 Thread Anastasia Stulova via cfe-commits

Author: Anastasia Stulova
Date: 2021-09-10T13:07:07+01:00
New Revision: fbe00c6874f1f0c496d64933a1a899448b2a

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

LOG: [OpenCL][Docs] Update OpenCL 3.0 status info.

Update info on OpenCLSupport page to reflect changes
committed after release 13 branched.

Added: 


Modified: 
clang/docs/OpenCLSupport.rst

Removed: 




diff  --git a/clang/docs/OpenCLSupport.rst b/clang/docs/OpenCLSupport.rst
index 0d7ebca899f7..7bfb471cc381 100644
--- a/clang/docs/OpenCLSupport.rst
+++ b/clang/docs/OpenCLSupport.rst
@@ -385,9 +385,9 @@ implementation status.
 
+--+-+-+--+--+
 | Feature optionality  | Blocks and Device-side kernel enqueue 
including builtin functions | :none:`unclaimed`|
  |
 
+--+-+-+--+--+
-| Feature optionality  | Pipes including builtin functions 
| :part:`worked on`| https://reviews.llvm.org/D107154 
(frontend) and https://reviews.llvm.org/D105858 (functions) |
+| Feature optionality  | Pipes including builtin functions 
| :good:`done` | https://reviews.llvm.org/D107154 
(frontend) and https://reviews.llvm.org/D105858 (functions) |
 
+--+-+-+--+--+
-| Feature optionality  | Work group collective builtin functions   
| :part:`worked on`| https://reviews.llvm.org/D105858   
  |
+| Feature optionality  | Work group collective builtin functions   
| :good:`done` | https://reviews.llvm.org/D105858   
  |
 
+--+-+-+--+--+
 | Feature optionality  | Image types and builtin functions 
| :good:`done` | https://reviews.llvm.org/D103911 
(frontend) and https://reviews.llvm.org/D107539 (functions) |
 
+--+-+-+--+--+



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


[PATCH] D97699: [analyzer] Add InvalidPtrChecker

2021-09-10 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

> And about `checkDeadSymbols`,  I get your point, but I am interested why 
> checker has different behavior on these two examples:
>
>   a1 int main(int argc, char **argv, char *envp[]) {
>   a2   putenv((char*) "NAME=VALUE"); // envp invalidated
>   a3   envp[0]; // gives error
>   a4 }
>
>
>
>   b1 int main(int argc, char **argv, char *envp[]) {
>   b2   char **e = envp;
>   b3   putenv((char*) "NAME=VALUE"); // envp invalidated
>   b4   e[0]; // does not give error
>   b5 } 
>
> If I manually force keeping `envp` region in state when I check `if 
> (!SymReaper.isLiveRegion(E)) {` , then it reports as expected.

This is because we use the result of the live variable analysis to drive the 
cleanup mechanism (i.e. garbage collection) of the analyzer. This data-flow 
analysis is finished before the path sensitive symbolic execution is started. 
In the first example, `envp` becomes dead at line `a3` because that is the last 
point where we read it. In the second exmplae, `envp` becomes dead at line `b2` 
because that is the last location where we read it's value. And it seems like 
our live variable analysis does not handle aliasing.
In my humble opinion, the engine should be using a lexical based scoping 
analysis to drive the callbacks of `checkDeadSymbols`. Or, perhaps, we should 
have another callback that is called at the end of the scope based lifetime. 
(RFC @NoQ). Currently, the engine might report a symbol/region as dead even if 
that is still live in the lexical scoping sense.
On the other hand, having the cleanup mechanism eagerly removing dead symbols 
and all of their dependency helps the analyzer to keep it's State as small as 
absolutely needed, all the time. This way it can be as terse in the memory and 
as fast in runtime as possible.


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

https://reviews.llvm.org/D97699

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


[PATCH] D109592: [clang-offload-bundler] Fix compatibility testing for non-assert builds

2021-09-10 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon added a comment.

Could you keep the test coverage by splitting off the debug tests into another 
file with a "REQUIRES: assert" lit tag?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109592

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


[PATCH] D109599: [PowerPC][MMA] Allow MMA builtin types in pre-P10 compilation units

2021-09-10 Thread Kamau Bridgeman via Phabricator via cfe-commits
kamaub created this revision.
kamaub added reviewers: PowerPC, nemanjai, lei, saghir, stefanp.
Herald added subscribers: steven.zhang, shchenz, kbarton.
kamaub requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch allows the use of__vector_quad and __vector_pair, PPC MMA builtin
types, on all PowerPC 64-bit compilation units. When these types are
made available the builtins that use them automatically become available
so semantic checking for mma and pair vector memop __builtins is also
expanded to ensure these builtin function call are only allowed on
Power10 and new architectures. All related test cases are updated to
ensure test coverage.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109599

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/AST/ast-dump-ppc-types.c
  clang/test/CodeGen/builtins-ppc-pair-mma.c
  clang/test/CodeGen/ppc-mma-types.c
  clang/test/CodeGenCXX/ppc-mangle-mma-types.cpp
  clang/test/Sema/ppc-pair-mma-types.c

Index: clang/test/Sema/ppc-pair-mma-types.c
===
--- clang/test/Sema/ppc-pair-mma-types.c
+++ clang/test/Sema/ppc-pair-mma-types.c
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -fsyntax-only \
-// RUN:   -target-cpu future %s -verify
+// RUN:   -target-cpu pwr10 %s -verify
 
 // The use of PPC MMA types is strongly restricted. Non-pointer MMA variables
 // can only be declared in functions and a limited number of operations are
Index: clang/test/CodeGenCXX/ppc-mangle-mma-types.cpp
===
--- clang/test/CodeGenCXX/ppc-mangle-mma-types.cpp
+++ clang/test/CodeGenCXX/ppc-mangle-mma-types.cpp
@@ -1,4 +1,8 @@
-// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu future %s \
+// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu pwr10 %s \
+// RUN:   -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu pwr9 %s \
+// RUN:   -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu pwr8 %s \
 // RUN:   -emit-llvm -o - | FileCheck %s
 
 // CHECK: _Z2f1Pu13__vector_quad
Index: clang/test/CodeGen/ppc-mma-types.c
===
--- clang/test/CodeGen/ppc-mma-types.c
+++ clang/test/CodeGen/ppc-mma-types.c
@@ -1,5 +1,9 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu future \
+// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu pwr10 \
+// RUN:   -emit-llvm -O3 -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu pwr9 \
+// RUN:   -emit-llvm -O3 -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu pwr8 \
 // RUN:   -emit-llvm -O3 -o - %s | FileCheck %s
 
 // CHECK-LABEL: @test1(
Index: clang/test/CodeGen/builtins-ppc-pair-mma.c
===
--- clang/test/CodeGen/builtins-ppc-pair-mma.c
+++ clang/test/CodeGen/builtins-ppc-pair-mma.c
@@ -1,5 +1,5 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang_cc1 -O3 -triple powerpc64le-unknown-unknown -target-cpu future -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -O3 -triple powerpc64le-unknown-unknown -target-cpu pwr10 -emit-llvm %s -o - | FileCheck %s
 
 // CHECK-LABEL: @test1(
 // CHECK-NEXT:  entry:
Index: clang/test/AST/ast-dump-ppc-types.c
===
--- clang/test/AST/ast-dump-ppc-types.c
+++ clang/test/AST/ast-dump-ppc-types.c
@@ -1,13 +1,9 @@
-// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu future \
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu pwr10 \
 // RUN:   -ast-dump -ast-dump-filter __vector %s | FileCheck %s
-// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu future \
-// RUN:   -target-feature -mma -ast-dump %s | FileCheck %s \
-// RUN:   --check-prefix=CHECK-NO-MMA
-// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu future \
-// RUN:   -target-feature -paired-vector-memops -ast-dump %s | FileCheck %s \
-// RUN:   --check-prefix=CHECK-NO-PAIRED
 // RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu pwr9 \
-// RUN:   -ast-dump %s | FileCheck %s --check-prefix=CHECK-PWR9
+// RUN:   -ast-dump -ast-dump-filter __vector %s | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu pwr8 \
+// RUN:   -ast-dump -ast-dump-filter __vector %s | FileCheck %s
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -ast-dump %s | FileCheck %s \
 // RUN:   --check-prefix=CHECK-X86_64
 // RUN: %clang_cc1 -triple arm-unkno

[PATCH] D109592: [clang-offload-bundler] Fix compatibility testing for non-assert builds

2021-09-10 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam updated this revision to Diff 371895.
saiislam added a comment.

Moved debug-only based tests to a separate file which requires "asserts".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109592

Files:
  clang/test/Driver/clang-offload-bundler-asserts-on.c
  clang/test/Driver/clang-offload-bundler.c


Index: clang/test/Driver/clang-offload-bundler.c
===
--- clang/test/Driver/clang-offload-bundler.c
+++ clang/test/Driver/clang-offload-bundler.c
@@ -401,11 +401,6 @@
 // RUN: cat %t-archive-gfx803-empty.a | FileCheck %s -check-prefix=EMPTYARCHIVE
 // EMPTYARCHIVE: !
 
-// Tests to check compatibility between Bundle Entry ID formats i.e. between 
presence/absence of extra hyphen in case of missing environment field
-// RUN: clang-offload-bundler -unbundle -type=a 
-targets=openmp-amdgcn-amd-amdhsa--gfx906,openmp-amdgcn-amd-amdhsa-gfx908 
-inputs=%t.input-archive.a 
-outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a 
-debug-only=CodeObjectCompatibility 2>&1 | FileCheck %s 
-check-prefix=BUNDLECOMPATIBILITY
-// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa-gfx906]   :   [Target: 
openmp-amdgcn-amd-amdhsa--gfx906]
-// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa--gfx908]  :   [Target: 
openmp-amdgcn-amd-amdhsa-gfx908]
-
 // Some code so that we can create a binary out of this file.
 int A = 0;
 void test_func(void) {
Index: clang/test/Driver/clang-offload-bundler-asserts-on.c
===
--- /dev/null
+++ clang/test/Driver/clang-offload-bundler-asserts-on.c
@@ -0,0 +1,27 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: asserts
+// UNSUPPORTED: darwin
+
+
+// RUN: %clang -O0 -target %itanium_abi_triple %s -c -o %t.o
+// RUN: echo 'Content of device file 1' > %t.tgt1
+// RUN: echo 'Content of device file 2' > %t.tgt2
+
+//
+// Check code object compatibility for archive unbundling
+//
+// Create few code object bundles and archive them to create an input archive
+// RUN: clang-offload-bundler -type=o 
-targets=host-%itanium_abi_triple,openmp-amdgcn-amd-amdhsa-gfx906,openmp-amdgcn-amd-amdhsa--gfx908
 -inputs=%t.o,%t.tgt1,%t.tgt2 -outputs=%t.simple.bundle
+// RUN: clang-offload-bundler -type=o 
-targets=host-%itanium_abi_triple,openmp-amdgcn-amd-amdhsa--gfx903 
-inputs=%t.o,%t.tgt1 -outputs=%t.simple1.bundle
+// RUN: llvm-ar cr %t.input-archive.a %t.simple.bundle %t.simple1.bundle
+
+// Tests to check compatibility between Bundle Entry ID formats i.e. between 
presence/absence of extra hyphen in case of missing environment field
+// RUN: clang-offload-bundler -unbundle -type=a 
-targets=openmp-amdgcn-amd-amdhsa--gfx906,openmp-amdgcn-amd-amdhsa-gfx908 
-inputs=%t.input-archive.a 
-outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a 
-debug-only=CodeObjectCompatibility 2>&1 | FileCheck %s 
-check-prefix=BUNDLECOMPATIBILITY
+// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa-gfx906]   :   [Target: 
openmp-amdgcn-amd-amdhsa--gfx906]
+// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa--gfx908]  :   [Target: 
openmp-amdgcn-amd-amdhsa-gfx908]
+
+// Some code so that we can create a binary out of this file.
+int A = 0;
+void test_func(void) {
+  ++A;
+}


Index: clang/test/Driver/clang-offload-bundler.c
===
--- clang/test/Driver/clang-offload-bundler.c
+++ clang/test/Driver/clang-offload-bundler.c
@@ -401,11 +401,6 @@
 // RUN: cat %t-archive-gfx803-empty.a | FileCheck %s -check-prefix=EMPTYARCHIVE
 // EMPTYARCHIVE: !
 
-// Tests to check compatibility between Bundle Entry ID formats i.e. between presence/absence of extra hyphen in case of missing environment field
-// RUN: clang-offload-bundler -unbundle -type=a -targets=openmp-amdgcn-amd-amdhsa--gfx906,openmp-amdgcn-amd-amdhsa-gfx908 -inputs=%t.input-archive.a -outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a -debug-only=CodeObjectCompatibility 2>&1 | FileCheck %s -check-prefix=BUNDLECOMPATIBILITY
-// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: openmp-amdgcn-amd-amdhsa-gfx906]   :   [Target: openmp-amdgcn-amd-amdhsa--gfx906]
-// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: openmp-amdgcn-amd-amdhsa--gfx908]  :   [Target: openmp-amdgcn-amd-amdhsa-gfx908]
-
 // Some code so that we can create a binary out of this file.
 int A = 0;
 void test_func(void) {
Index: clang/test/Driver/clang-offload-bundler-asserts-on.c
===
--- /dev/null
+++ clang/test/Driver/clang-offload-bundler-asserts-on.c
@@ -0,0 +1,27 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: assert

[clang] 993f60a - [clang][deps] Sanitize both instances of DiagnosticOptions

2021-09-10 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2021-09-10T14:47:21+02:00
New Revision: 993f60ae32de001ac9ac1ff512f2adf339e265c8

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

LOG: [clang][deps] Sanitize both instances of DiagnosticOptions

During dependency scanning, we generally want to suppress -Werror. Apply the 
same logic to the DiagnosticOptions instance used for command-line parsing.

This fixes a test failure on the PS4 bot, where the system header directory 
could not be found, which was reported due to -Werror being on the command line 
and not being sanitized.

Added: 


Modified: 
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
clang/test/ClangScanDeps/error.cpp

Removed: 




diff  --git a/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp 
b/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
index faf7d36bf87b8..e4d49756ce6b4 100644
--- a/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ b/clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -133,6 +133,16 @@ deduceDepTarget(const std::string &OutputFile,
   return makeObjFileName(InputFiles.front().getFile());
 }
 
+/// Sanitize diagnostic options for dependency scan.
+static void sanitizeDiagOpts(DiagnosticOptions &DiagOpts) {
+  // Don't print 'X warnings and Y errors generated'.
+  DiagOpts.ShowCarets = false;
+  // Don't write out diagnostic file.
+  DiagOpts.DiagnosticSerializationFile.clear();
+  // Don't treat warnings as errors.
+  DiagOpts.Warnings.push_back("no-error");
+}
+
 /// A clang tool that runs the preprocessor in a mode that's optimized for
 /// dependency scanning for the given compiler invocation.
 class DependencyScanningAction : public tooling::ToolAction {
@@ -157,13 +167,8 @@ class DependencyScanningAction : public 
tooling::ToolAction {
 CompilerInstance Compiler(std::move(PCHContainerOps));
 Compiler.setInvocation(std::move(Invocation));
 
-// Don't print 'X warnings and Y errors generated'.
-Compiler.getDiagnosticOpts().ShowCarets = false;
-// Don't write out diagnostic file.
-Compiler.getDiagnosticOpts().DiagnosticSerializationFile.clear();
-// Don't treat warnings as errors.
-Compiler.getDiagnosticOpts().Warnings.push_back("no-error");
 // Create the compiler's actual diagnostics engine.
+sanitizeDiagOpts(Compiler.getDiagnosticOpts());
 Compiler.createDiagnostics(DiagConsumer, /*ShouldOwnClient=*/false);
 if (!Compiler.hasDiagnostics())
   return false;
@@ -304,8 +309,7 @@ static llvm::Error
 runWithDiags(DiagnosticOptions *DiagOpts,
  llvm::function_ref
  BodyShouldSucceed) {
-  // Avoid serializing diagnostics.
-  DiagOpts->DiagnosticSerializationFile.clear();
+  sanitizeDiagOpts(*DiagOpts);
 
   // Capture the emitted diagnostics and report them to the client
   // in the case of a failure.

diff  --git a/clang/test/ClangScanDeps/error.cpp 
b/clang/test/ClangScanDeps/error.cpp
index e18bf302af26f..d94ba4c03e508 100644
--- a/clang/test/ClangScanDeps/error.cpp
+++ b/clang/test/ClangScanDeps/error.cpp
@@ -21,10 +21,6 @@
 // CHECK-NEXT: error:
 // CHECK-NEXT: Error while scanning dependencies
 // CHECK-NEXT: fatal error: 'missing.h' file not found
-// CHECK-NEXT: "missing.h"
-// CHECK-NEXT: ^
 // CHECK-NEXT: Error while scanning dependencies
 // CHECK-NEXT: fatal error: 'missing.h' file not found
-// CHECK-NEXT: "missing.h"
-// CHECK-NEXT: ^
 // CHECK-NEXT: EOF



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


[PATCH] D109158: [clang][deps] Test diagnostic options are being respected

2021-09-10 Thread Jan Svoboda 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 rG7afabc2e4e86: [clang][deps] Test diagnostic options are 
being respected (authored by jansvoboda11).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D109158?vs=370271&id=371901#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109158

Files:
  llvm/clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template
  llvm/clang/test/ClangScanDeps/Inputs/diagnostics/mod.h
  llvm/clang/test/ClangScanDeps/Inputs/diagnostics/module.modulemap
  llvm/clang/test/ClangScanDeps/Inputs/diagnostics/tu.c
  llvm/clang/test/ClangScanDeps/diagnostics.c


Index: llvm/clang/test/ClangScanDeps/diagnostics.c
===
--- /dev/null
+++ llvm/clang/test/ClangScanDeps/diagnostics.c
@@ -0,0 +1,49 @@
+// RUN: rm -rf %t && mkdir %t
+// RUN: cp %S/Inputs/diagnostics/* %t
+
+// RUN: sed "s|DIR|%/t|g" %S/Inputs/diagnostics/cdb.json.template > %t/cdb.json
+// RUN: echo -%t > %t/result.json
+// RUN: clang-scan-deps -compilation-database %t/cdb.json -format 
experimental-full 2>&1 >> %t/result.json
+// RUN: cat %t/result.json | sed 's:\?:/:g' | FileCheck %s
+
+// Check that the scanner injects '-Wno-error' option and invalid command-line
+// arguments like '-target i386-apple-ios14.0-simulator' do not result in 
error.
+
+// CHECK-NOT:  error:
+// CHECK:  -[[PREFIX:.*]]
+// CHECK-NEXT: {
+// CHECK-NEXT:   "modules": [
+// CHECK-NEXT: {
+// CHECK-NEXT:   "clang-module-deps": [],
+// CHECK-NEXT:   "clang-modulemap-file": "[[PREFIX]]/module.modulemap",
+// CHECK-NEXT:   "command-line": [
+// CHECK-NEXT: "-cc1"
+// CHECK:],
+// CHECK-NEXT:   "context-hash": "[[HASH_MOD:.*]]",
+// CHECK-NEXT:   "file-deps": [
+// CHECK-NEXT: "[[PREFIX]]/mod.h"
+// CHECK-NEXT: "[[PREFIX]]/module.modulemap"
+// CHECK-NEXT:   ],
+// CHECK-NEXT:   "name": "mod"
+// CHECK-NEXT: }
+// CHECK-NEXT:   ],
+// CHECK-NEXT:   "translation-units": [
+// CHECK-NEXT: {
+// CHECK-NEXT:   "clang-context-hash": "[[HASH_TU:.*]],
+// CHECK-NEXT:   "clang-module-deps": [
+// CHECK-NEXT: {
+// CHECK-NEXT:   "context-hash": "[[HASH_MOD]]",
+// CHECK-NEXT:   "module-name": "mod"
+// CHECK-NEXT: }
+// CHECK-NEXT:   ],
+// CHECK-NEXT:   "command-line": [
+// CHECK-NEXT: "-fno-implicit-modules"
+// CHECK-NEXT: "-fno-implicit-module-maps"
+// CHECK-NEXT:   ],
+// CHECK-NEXT:   "file-deps": [
+// CHECK-NEXT: "[[PREFIX]]/tu.c"
+// CHECK-NEXT:   ],
+// CHECK-NEXT:   "input-file": "[[PREFIX]]/tu.c"
+// CHECK-NEXT: }
+// CHECK-NEXT:   ]
+// CHECK-NEXT: }
Index: llvm/clang/test/ClangScanDeps/Inputs/diagnostics/tu.c
===
--- /dev/null
+++ llvm/clang/test/ClangScanDeps/Inputs/diagnostics/tu.c
@@ -0,0 +1 @@
+#include "mod.h"
Index: llvm/clang/test/ClangScanDeps/Inputs/diagnostics/module.modulemap
===
--- /dev/null
+++ llvm/clang/test/ClangScanDeps/Inputs/diagnostics/module.modulemap
@@ -0,0 +1 @@
+module mod { header "mod.h" }
Index: llvm/clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template
===
--- /dev/null
+++ llvm/clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template
@@ -0,0 +1,7 @@
+[
+  {
+"directory": "DIR",
+"command": "clang -c DIR/tu.c -fmodules -target 
i386-apple-ios14.0-simulator -o DIR/tu.o",
+"file": "DIR/tu.c"
+  }
+]


Index: llvm/clang/test/ClangScanDeps/diagnostics.c
===
--- /dev/null
+++ llvm/clang/test/ClangScanDeps/diagnostics.c
@@ -0,0 +1,49 @@
+// RUN: rm -rf %t && mkdir %t
+// RUN: cp %S/Inputs/diagnostics/* %t
+
+// RUN: sed "s|DIR|%/t|g" %S/Inputs/diagnostics/cdb.json.template > %t/cdb.json
+// RUN: echo -%t > %t/result.json
+// RUN: clang-scan-deps -compilation-database %t/cdb.json -format experimental-full 2>&1 >> %t/result.json
+// RUN: cat %t/result.json | sed 's:\?:/:g' | FileCheck %s
+
+// Check that the scanner injects '-Wno-error' option and invalid command-line
+// arguments like '-target i386-apple-ios14.0-simulator' do not result in error.
+
+// CHECK-NOT:  error:
+// CHECK:  -[[PREFIX:.*]]
+// CHECK-NEXT: {
+// CHECK-NEXT:   "modules": [
+// CHECK-NEXT: {
+// CHECK-NEXT:   "clang-module-deps": [],
+// CHECK-NEXT:   "clang-modulemap-file": "[[PREFIX]]/module.modulemap",
+// CHECK-NEXT:   "command-line": [
+// CHECK-NEXT: "-cc1"
+// CHECK:],
+// CHECK-NEXT:   "context-hash": "[[HASH_MOD:.*]]",
+// CHECK-N

[PATCH] D109592: [clang-offload-bundler] Fix compatibility testing for non-assert builds

2021-09-10 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon accepted this revision.
RKSimon added a comment.
This revision is now accepted and ready to land.

LGTM with one minor




Comment at: clang/test/Driver/clang-offload-bundler-asserts-on.c:6
+
+// RUN: %clang -O0 -target %itanium_abi_triple %s -c -o %t.o
+// RUN: echo 'Content of device file 1' > %t.tgt1

Add the stage description comments from the original file?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109592

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


[PATCH] D109541: Increase expected line number for ExtDebugInfo.cpp

2021-09-10 Thread Jake Egan via Phabricator via cfe-commits
Jake-Egan updated this revision to Diff 371908.
Jake-Egan added a comment.

Added a comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109541

Files:
  clang/test/Modules/ExtDebugInfo.cpp


Index: clang/test/Modules/ExtDebugInfo.cpp
===
--- clang/test/Modules/ExtDebugInfo.cpp
+++ clang/test/Modules/ExtDebugInfo.cpp
@@ -24,6 +24,8 @@
 @import DebugCXX;
 #endif
 
+// Set the line number so that the LIT check expected line number doesn't have 
to be updated after adding/removing a line in the RUN section.
+#line 50
 using DebugCXX::Struct;
 
 Struct s;
@@ -204,8 +206,7 @@
 // CHECK: ![[GLOBAL_ANON]] = !DICompositeType(tag: DW_TAG_structure_type,
 // CHECK-SAME:  name: "InAnonymousNamespace", {{.*}}DIFlagFwdDecl)
 
-
-// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: 
!{{[0-9]+}}, entity: ![[STRUCT]], file: ![[CPP]], line: 27)
+// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: 
!{{[0-9]+}}, entity: ![[STRUCT]], file: ![[CPP]], line: 50)
 
 // CHECK: !DICompileUnit(
 // CHECK-SAME:   splitDebugFilename:


Index: clang/test/Modules/ExtDebugInfo.cpp
===
--- clang/test/Modules/ExtDebugInfo.cpp
+++ clang/test/Modules/ExtDebugInfo.cpp
@@ -24,6 +24,8 @@
 @import DebugCXX;
 #endif
 
+// Set the line number so that the LIT check expected line number doesn't have to be updated after adding/removing a line in the RUN section.
+#line 50
 using DebugCXX::Struct;
 
 Struct s;
@@ -204,8 +206,7 @@
 // CHECK: ![[GLOBAL_ANON]] = !DICompositeType(tag: DW_TAG_structure_type,
 // CHECK-SAME:  name: "InAnonymousNamespace", {{.*}}DIFlagFwdDecl)
 
-
-// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: !{{[0-9]+}}, entity: ![[STRUCT]], file: ![[CPP]], line: 27)
+// CHECK: !DIImportedEntity(tag: DW_TAG_imported_declaration, scope: !{{[0-9]+}}, entity: ![[STRUCT]], file: ![[CPP]], line: 50)
 
 // CHECK: !DICompileUnit(
 // CHECK-SAME:   splitDebugFilename:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 4a25c3f - [clang-offload-bundler] Fix compatibility testing for non-assert builds

2021-09-10 Thread Saiyedul Islam via cfe-commits

Author: Saiyedul Islam
Date: 2021-09-10T18:57:03+05:30
New Revision: 4a25c3fb61942c629907ae50462087c3fbb8703a

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

LOG: [clang-offload-bundler] Fix compatibility testing for non-assert builds

Test using debug-only=CodeObjectComaptibility was failing in
non-assert builds, so it has been moved to a different file which
requires assert.

Reviewed By: RKSimon

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

Added: 
clang/test/Driver/clang-offload-bundler-asserts-on.c

Modified: 
clang/test/Driver/clang-offload-bundler.c

Removed: 




diff  --git a/clang/test/Driver/clang-offload-bundler-asserts-on.c 
b/clang/test/Driver/clang-offload-bundler-asserts-on.c
new file mode 100644
index 0..c11028d16343a
--- /dev/null
+++ b/clang/test/Driver/clang-offload-bundler-asserts-on.c
@@ -0,0 +1,31 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: asserts
+// UNSUPPORTED: darwin
+
+// Generate the file we can bundle.
+// RUN: %clang -O0 -target %itanium_abi_triple %s -c -o %t.o
+
+//
+// Generate a couple of files to bundle with.
+//
+// RUN: echo 'Content of device file 1' > %t.tgt1
+// RUN: echo 'Content of device file 2' > %t.tgt2
+
+//
+// Check code object compatibility for archive unbundling
+//
+// Create few code object bundles and archive them to create an input archive
+// RUN: clang-offload-bundler -type=o 
-targets=host-%itanium_abi_triple,openmp-amdgcn-amd-amdhsa-gfx906,openmp-amdgcn-amd-amdhsa--gfx908
 -inputs=%t.o,%t.tgt1,%t.tgt2 -outputs=%t.simple.bundle
+// RUN: clang-offload-bundler -type=o 
-targets=host-%itanium_abi_triple,openmp-amdgcn-amd-amdhsa--gfx903 
-inputs=%t.o,%t.tgt1 -outputs=%t.simple1.bundle
+// RUN: llvm-ar cr %t.input-archive.a %t.simple.bundle %t.simple1.bundle
+
+// Tests to check compatibility between Bundle Entry ID formats i.e. between 
presence/absence of extra hyphen in case of missing environment field
+// RUN: clang-offload-bundler -unbundle -type=a 
-targets=openmp-amdgcn-amd-amdhsa--gfx906,openmp-amdgcn-amd-amdhsa-gfx908 
-inputs=%t.input-archive.a 
-outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a 
-debug-only=CodeObjectCompatibility 2>&1 | FileCheck %s 
-check-prefix=BUNDLECOMPATIBILITY
+// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa-gfx906]   :   [Target: 
openmp-amdgcn-amd-amdhsa--gfx906]
+// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa--gfx908]  :   [Target: 
openmp-amdgcn-amd-amdhsa-gfx908]
+
+// Some code so that we can create a binary out of this file.
+int A = 0;
+void test_func(void) {
+  ++A;
+}

diff  --git a/clang/test/Driver/clang-offload-bundler.c 
b/clang/test/Driver/clang-offload-bundler.c
index d201dd4103892..9eb305d4d0eeb 100644
--- a/clang/test/Driver/clang-offload-bundler.c
+++ b/clang/test/Driver/clang-offload-bundler.c
@@ -401,11 +401,6 @@
 // RUN: cat %t-archive-gfx803-empty.a | FileCheck %s -check-prefix=EMPTYARCHIVE
 // EMPTYARCHIVE: !
 
-// Tests to check compatibility between Bundle Entry ID formats i.e. between 
presence/absence of extra hyphen in case of missing environment field
-// RUN: clang-offload-bundler -unbundle -type=a 
-targets=openmp-amdgcn-amd-amdhsa--gfx906,openmp-amdgcn-amd-amdhsa-gfx908 
-inputs=%t.input-archive.a 
-outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a 
-debug-only=CodeObjectCompatibility 2>&1 | FileCheck %s 
-check-prefix=BUNDLECOMPATIBILITY
-// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa-gfx906]   :   [Target: 
openmp-amdgcn-amd-amdhsa--gfx906]
-// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa--gfx908]  :   [Target: 
openmp-amdgcn-amd-amdhsa-gfx908]
-
 // Some code so that we can create a binary out of this file.
 int A = 0;
 void test_func(void) {



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


[PATCH] D109592: [clang-offload-bundler] Fix compatibility testing for non-assert builds

2021-09-10 Thread Saiyedul Islam via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
saiislam marked an inline comment as done.
Closed by commit rG4a25c3fb6194: [clang-offload-bundler] Fix compatibility 
testing for non-assert builds (authored by saiislam).

Changed prior to commit:
  https://reviews.llvm.org/D109592?vs=371895&id=371910#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109592

Files:
  clang/test/Driver/clang-offload-bundler-asserts-on.c
  clang/test/Driver/clang-offload-bundler.c


Index: clang/test/Driver/clang-offload-bundler.c
===
--- clang/test/Driver/clang-offload-bundler.c
+++ clang/test/Driver/clang-offload-bundler.c
@@ -401,11 +401,6 @@
 // RUN: cat %t-archive-gfx803-empty.a | FileCheck %s -check-prefix=EMPTYARCHIVE
 // EMPTYARCHIVE: !
 
-// Tests to check compatibility between Bundle Entry ID formats i.e. between 
presence/absence of extra hyphen in case of missing environment field
-// RUN: clang-offload-bundler -unbundle -type=a 
-targets=openmp-amdgcn-amd-amdhsa--gfx906,openmp-amdgcn-amd-amdhsa-gfx908 
-inputs=%t.input-archive.a 
-outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a 
-debug-only=CodeObjectCompatibility 2>&1 | FileCheck %s 
-check-prefix=BUNDLECOMPATIBILITY
-// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa-gfx906]   :   [Target: 
openmp-amdgcn-amd-amdhsa--gfx906]
-// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa--gfx908]  :   [Target: 
openmp-amdgcn-amd-amdhsa-gfx908]
-
 // Some code so that we can create a binary out of this file.
 int A = 0;
 void test_func(void) {
Index: clang/test/Driver/clang-offload-bundler-asserts-on.c
===
--- /dev/null
+++ clang/test/Driver/clang-offload-bundler-asserts-on.c
@@ -0,0 +1,31 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: asserts
+// UNSUPPORTED: darwin
+
+// Generate the file we can bundle.
+// RUN: %clang -O0 -target %itanium_abi_triple %s -c -o %t.o
+
+//
+// Generate a couple of files to bundle with.
+//
+// RUN: echo 'Content of device file 1' > %t.tgt1
+// RUN: echo 'Content of device file 2' > %t.tgt2
+
+//
+// Check code object compatibility for archive unbundling
+//
+// Create few code object bundles and archive them to create an input archive
+// RUN: clang-offload-bundler -type=o 
-targets=host-%itanium_abi_triple,openmp-amdgcn-amd-amdhsa-gfx906,openmp-amdgcn-amd-amdhsa--gfx908
 -inputs=%t.o,%t.tgt1,%t.tgt2 -outputs=%t.simple.bundle
+// RUN: clang-offload-bundler -type=o 
-targets=host-%itanium_abi_triple,openmp-amdgcn-amd-amdhsa--gfx903 
-inputs=%t.o,%t.tgt1 -outputs=%t.simple1.bundle
+// RUN: llvm-ar cr %t.input-archive.a %t.simple.bundle %t.simple1.bundle
+
+// Tests to check compatibility between Bundle Entry ID formats i.e. between 
presence/absence of extra hyphen in case of missing environment field
+// RUN: clang-offload-bundler -unbundle -type=a 
-targets=openmp-amdgcn-amd-amdhsa--gfx906,openmp-amdgcn-amd-amdhsa-gfx908 
-inputs=%t.input-archive.a 
-outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a 
-debug-only=CodeObjectCompatibility 2>&1 | FileCheck %s 
-check-prefix=BUNDLECOMPATIBILITY
+// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa-gfx906]   :   [Target: 
openmp-amdgcn-amd-amdhsa--gfx906]
+// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: 
openmp-amdgcn-amd-amdhsa--gfx908]  :   [Target: 
openmp-amdgcn-amd-amdhsa-gfx908]
+
+// Some code so that we can create a binary out of this file.
+int A = 0;
+void test_func(void) {
+  ++A;
+}


Index: clang/test/Driver/clang-offload-bundler.c
===
--- clang/test/Driver/clang-offload-bundler.c
+++ clang/test/Driver/clang-offload-bundler.c
@@ -401,11 +401,6 @@
 // RUN: cat %t-archive-gfx803-empty.a | FileCheck %s -check-prefix=EMPTYARCHIVE
 // EMPTYARCHIVE: !
 
-// Tests to check compatibility between Bundle Entry ID formats i.e. between presence/absence of extra hyphen in case of missing environment field
-// RUN: clang-offload-bundler -unbundle -type=a -targets=openmp-amdgcn-amd-amdhsa--gfx906,openmp-amdgcn-amd-amdhsa-gfx908 -inputs=%t.input-archive.a -outputs=%t-archive-gfx906-simple.a,%t-archive-gfx908-simple.a -debug-only=CodeObjectCompatibility 2>&1 | FileCheck %s -check-prefix=BUNDLECOMPATIBILITY
-// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: openmp-amdgcn-amd-amdhsa-gfx906]   :   [Target: openmp-amdgcn-amd-amdhsa--gfx906]
-// BUNDLECOMPATIBILITY: Compatible: Exact match:[CodeObject: openmp-amdgcn-amd-amdhsa--gfx908]  :   [Target: openmp-amdgcn-amd-amdhsa-gfx908]
-
 // Some code so that we can create a binary out of this file.
 int A = 0;
 void test_func(void)

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

2021-09-10 Thread Andrew Savonichev via Phabricator via cfe-commits
asavonic updated this revision to Diff 371912.
asavonic added a comment.

Rebased


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109315

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

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

[PATCH] D109544: [OpenMP] Add flag for setting debug in the offloading device

2021-09-10 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 updated this revision to Diff 371914.
jhuber6 added a comment.

Adding constant to `llvm.used`. This is most likely easier than dealing with 
weak external linkage.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109544

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/OpenMP/target_debug_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp

Index: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
===
--- llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
+++ llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
@@ -34,6 +34,7 @@
 #include "llvm/Transforms/Utils/BasicBlockUtils.h"
 #include "llvm/Transforms/Utils/CodeExtractor.h"
 #include "llvm/Transforms/Utils/LoopPeel.h"
+#include "llvm/Transforms/Utils/ModuleUtils.h"
 #include "llvm/Transforms/Utils/UnrollLoop.h"
 
 #include 
@@ -244,6 +245,18 @@
   assert(OutlineInfos.empty() && "There must be no outstanding outlinings");
 }
 
+GlobalValue *OpenMPIRBuilder::createDebugKind(unsigned DebugKind) {
+  IntegerType *I32Ty = Type::getInt32Ty(M.getContext());
+  auto *GV = new GlobalVariable(
+  M, I32Ty,
+  /* isConstant = */ true, GlobalValue::PrivateLinkage,
+  ConstantInt::get(I32Ty, DebugKind), "__omp_rtl_debug_kind");
+
+  llvm::appendToUsed(M, {GV});
+
+  return GV;
+}
+
 Value *OpenMPIRBuilder::getOrCreateIdent(Constant *SrcLocStr,
  IdentFlag LocFlags,
  unsigned Reserve2Flags) {
Index: llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
===
--- llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
+++ llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
@@ -683,6 +683,10 @@
   omp::IdentFlag Flags = omp::IdentFlag(0),
   unsigned Reserve2Flags = 0);
 
+  /// Create a global value containing the \p DebugLevel to control debuggin in
+  /// the module.
+  GlobalValue *createDebugKind(unsigned DebugLevel);
+
   /// Generate control flow and cleanup for cancellation.
   ///
   /// \param CancelFlag Flag indicating if the cancellation is performed.
Index: clang/test/OpenMP/target_debug_codegen.cpp
===
--- /dev/null
+++ clang/test/OpenMP/target_debug_codegen.cpp
@@ -0,0 +1,23 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --check-globals --global-value-regex "(__omp_rtl_debug_kind|llvm\.used)"
+// Test target codegen - host bc file has to be created first.
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-target-new-runtime -fopenmp-target-debug -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix=CHECK
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-target-new-runtime -fopenmp-target-debug=111 -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s --check-prefix=CHECK-EQ
+// expected-no-diagnostics
+
+#ifndef HEADER
+#define HEADER
+
+//.
+// CHECK: @__omp_rtl_debug_kind = private constant i32 1
+// CHECK: @llvm.used = appending global [1 x i8*] [i8* bitcast (i32* @__omp_rtl_debug_kind to i8*)], section "llvm.metadata"
+//.
+// CHECK-EQ: @__omp_rtl_debug_kind = private constant i32 111
+// CHECK-EQ: @llvm.used = appending global [1 x i8*] [i8* bitcast (i32* @__omp_rtl_debug_kind to i8*)], section "llvm.metadata"
+//.
+void foo() {
+#pragma omp target
+  { }
+}
+
+#endif
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3460,6 +3460,13 @@
   GenerateArg(Args, OPT_fopenmp_version_EQ, Twine(Opts.OpenMP), SA);
   }
 
+  if (Opts.OpenMPTargetNewRuntime)
+GenerateArg(Args, OPT_fopenmp_target_new_runtime, SA);
+
+  if (Opts.OpenMPTargetDebug != 0)
+GenerateArg(Args, OPT_fopenmp_target_debug_EQ,
+Twine(Opts.OpenMPTargetDebug), SA);
+
   if (Opts.OpenMPCUDANumSMs != 0)
 GenerateArg(Args, OPT_fopenmp_cuda_number_of_sm_EQ,
 Twine(Opts.OpenMPCUDANumSMs), SA);
@@ -3838,6 +3845,9 @@
   Opts.OpenMP && Args.hasArg(options::OPT_fopenmp_enable_irbuilder);
   bool IsTarg

[PATCH] D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info

2021-09-10 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/test/CodeGenOpenCL/spirv32_target.cl:12
+kernel void foo(global long *arg) {
+  int res1[sizeof(my_st)  == 12 ? 1 : -1];
+  int res2[sizeof(void *) ==  4 ? 1 : -1];

linjamaki wrote:
> Anastasia wrote:
> > Are these lines tested somehow? You could change this into C++ for OpenCL 
> > test and use `static_assert` or find some other ways to test this...
> > 
> > However, this testing seems to overlap with the lines at the end... Could 
> > you please elaborate on the intent of this test?
> > 
> > Also if you don't plan this to be fundamentally different from testing of 
> > 64bit triple I think this should be merged with `spirv64_target.cl`. It 
> > will make things easier for the maintenance and further evolution.
> I used spir{32,64}_target.cl as a base for checking codegen for SPIR-V with 
> the only difference being the triple check. The lines give an compile error 
> (e.g. error: 'res1' declared as an array with a negative size) if the sizeof 
> operators give unexpected result. 
> 
> I'll merge this file with the spirv64_target.cl.
> 
Ok, you could consider adding `-verify` and 

`//expected-no-diagnostics`

Even though FileCheck should not succeed but it is going to be more clear that 
some functionality is tested via diagnostics for the future modifications. 

However, you seem to be testing pointer size in the two lines below which also 
seem to be tested via `//CHECK` directives... not sure whether both are needed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109144

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


[PATCH] D109144: [SPIR-V] Add SPIR-V triple architecture and clang target info

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

LGTM! Thanks.

Please, address suggested test simplifications in the final commit if 
applicable.

I am also not sure if more types should be tested from the data layout... but 
my guess is that testing could be improved in the subsequent commits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109144

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


[PATCH] D109366: [OpenCL] Tests C++ for OpenCL version macros

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

LGTM! Thanks


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

https://reviews.llvm.org/D109366

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


[PATCH] D97699: [analyzer] Add InvalidPtrChecker

2021-09-10 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

Nice work!




Comment at: clang/lib/StaticAnalyzer/Checkers/cert/InvalidPtrChecker.cpp:159
+// Note: This pointer has type 'const MemRegion *'
+REGISTER_TRAIT_WITH_PROGRAMSTATE(EnvPtrRegion, const void *)
+

Why is it `const void *`? Why can't we use `const MemRegion *` and get rid of 
the ugly reinterpret_cast?  There must be a reason ,which I'd like to see 
documented in the comments. 



Comment at: clang/lib/StaticAnalyzer/Checkers/cert/InvalidPtrChecker.cpp:163
+// memory region returned by previous call of this function
+REGISTER_MAP_WITH_PROGRAMSTATE(PreviousCallResultMap, const char *,
+   const MemRegion *)

I think we could use the canonical `FunctionDecl*` as the key instead of `const 
char *`. Then all the `eval` functions like `evalGetenv` and alike could be 
substituted with one simple function.



Comment at: clang/lib/StaticAnalyzer/Checkers/cert/InvalidPtrChecker.cpp:221-224
+  const auto *SymRegOfRetVal = dyn_cast(RetVal.getAsRegion());
+  State = State->set(
+  FunctionName.data(),
+  const_cast(SymRegOfRetVal->getBaseRegion()));

Would it be possible to add a `NoteTag` here and eliminate the 
`PreviousCallVisitor`?



Comment at: clang/lib/StaticAnalyzer/Checkers/cert/InvalidPtrChecker.cpp:342
+
+void InvalidPtrChecker::checkDeadSymbols(SymbolReaper &SymReaper,
+ CheckerContext &C) const {

I think we should delete the code of this callback, since we can't use it.


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

https://reviews.llvm.org/D97699

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


[PATCH] D108621: [HIPSPV] Add CUDA->SPIR-V address space mapping

2021-09-10 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/lib/Basic/Targets/SPIR.h:59
+// translation). This mapping is enabled when the language mode is HIP.
+1, // cuda_device
+// cuda_constant pointer can be casted to default/"flat" pointer, but in

bader wrote:
> Anastasia wrote:
> > I am slightly confused as in the LLVM project those address spaces are for 
> > SPIR not SPIR-V though. It is however used outside of LLVM project by some 
> > tools like SPIRV-LLVM Translator as a path to SPIR-V, but it has only been 
> > done as a workaround since we had no SPIR-V support in the LLVM project 
> > yet. And if we are adding it let's do it clean to avoid/resolve any 
> > confusion.
> > 
> > I think we need to keep both because some vendors do target/use SPIR but 
> > not SPIR-V.
> > 
> > So if you are interested in SPIR-V and not SPIR you should probably add a 
> > new target that will make things cleaner.
> > I think we need to keep both because some vendors do target/use SPIR but 
> > not SPIR-V.
> 
> @Anastasia, could you elaborate more on the difference between SPIR and 
> SPIR-V?
> I would like to understand what these terms mean in the context of LLVM 
> project.
Their conceptual differences are just that they are two different intermediate 
formats.

The important thing to highlight is that it is not impossible that some vendors 
use SPIR (without using SPIR-V) even despite the fact it has been discontinued 
by Khronos. 

Nobody has deprecated or discontinued SPIR in the LLVM project yet.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108621

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


[PATCH] D108621: [HIPSPV] Add CUDA->SPIR-V address space mapping

2021-09-10 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/lib/Basic/Targets/SPIR.h:233
+if (Opts.HIP && Opts.CUDAIsDevice)
+  // Enable address space mapping from HIP to SPIR-V.
+  // See comment on the SPIRDefIsGenMap table.

My guess is that this is not only HIP specific but for example the same applies 
to SYCL.

I am not sure if it makes more sense to move this into a `BaseSPIRTargetInfo` 
since this is not really SPIR-V specific logic. It is just a clang design 
misalignment between two address space concepts that has to be addressed 
properly at some point.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108621

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


[PATCH] D109126: [PowerPC] [NFC] Add Big-Endian checks for existing MMA tests

2021-09-10 Thread Ahsan Saghir via Phabricator via cfe-commits
saghir updated this revision to Diff 371919.
saghir added a comment.

Rebased.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109126

Files:
  clang/test/CodeGen/builtins-ppc-pair-mma.c
  clang/test/Sema/ppc-pair-mma-types.c
  clang/test/SemaCXX/ppc-pair-mma-types.cpp


Index: clang/test/SemaCXX/ppc-pair-mma-types.cpp
===
--- clang/test/SemaCXX/ppc-pair-mma-types.cpp
+++ clang/test/SemaCXX/ppc-pair-mma-types.cpp
@@ -1,5 +1,7 @@
 // RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -fsyntax-only \
-// RUN:   -fcxx-exceptions -target-cpu future %s -verify
+// RUN:   -fcxx-exceptions -target-cpu pwr10 %s -verify
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown -fsyntax-only \
+// RUN:   -fcxx-exceptions -target-cpu pwr10 %s -verify
 
 // vector quad
 
Index: clang/test/Sema/ppc-pair-mma-types.c
===
--- clang/test/Sema/ppc-pair-mma-types.c
+++ clang/test/Sema/ppc-pair-mma-types.c
@@ -1,5 +1,7 @@
 // RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -fsyntax-only \
-// RUN:   -target-cpu future %s -verify
+// RUN:   -target-cpu pwr10 %s -verify
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown -fsyntax-only \
+// RUN:   -target-cpu pwr10 %s -verify
 
 // The use of PPC MMA types is strongly restricted. Non-pointer MMA variables
 // can only be declared in functions and a limited number of operations are
Index: clang/test/CodeGen/builtins-ppc-pair-mma.c
===
--- clang/test/CodeGen/builtins-ppc-pair-mma.c
+++ clang/test/CodeGen/builtins-ppc-pair-mma.c
@@ -1,5 +1,8 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang_cc1 -O3 -triple powerpc64le-unknown-unknown -target-cpu future 
-emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -O3 -triple powerpc64le-unknown-unknown -target-cpu pwr10 \
+// RUN:  -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -O3 -triple powerpc64-unknown-unknown -target-cpu pwr10 \
+// RUN: -emit-llvm %s -o - | FileCheck %s
 
 // CHECK-LABEL: @test1(
 // CHECK-NEXT:  entry:


Index: clang/test/SemaCXX/ppc-pair-mma-types.cpp
===
--- clang/test/SemaCXX/ppc-pair-mma-types.cpp
+++ clang/test/SemaCXX/ppc-pair-mma-types.cpp
@@ -1,5 +1,7 @@
 // RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -fsyntax-only \
-// RUN:   -fcxx-exceptions -target-cpu future %s -verify
+// RUN:   -fcxx-exceptions -target-cpu pwr10 %s -verify
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown -fsyntax-only \
+// RUN:   -fcxx-exceptions -target-cpu pwr10 %s -verify
 
 // vector quad
 
Index: clang/test/Sema/ppc-pair-mma-types.c
===
--- clang/test/Sema/ppc-pair-mma-types.c
+++ clang/test/Sema/ppc-pair-mma-types.c
@@ -1,5 +1,7 @@
 // RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -fsyntax-only \
-// RUN:   -target-cpu future %s -verify
+// RUN:   -target-cpu pwr10 %s -verify
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown -fsyntax-only \
+// RUN:   -target-cpu pwr10 %s -verify
 
 // The use of PPC MMA types is strongly restricted. Non-pointer MMA variables
 // can only be declared in functions and a limited number of operations are
Index: clang/test/CodeGen/builtins-ppc-pair-mma.c
===
--- clang/test/CodeGen/builtins-ppc-pair-mma.c
+++ clang/test/CodeGen/builtins-ppc-pair-mma.c
@@ -1,5 +1,8 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang_cc1 -O3 -triple powerpc64le-unknown-unknown -target-cpu future -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -O3 -triple powerpc64le-unknown-unknown -target-cpu pwr10 \
+// RUN:  -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -O3 -triple powerpc64-unknown-unknown -target-cpu pwr10 \
+// RUN: -emit-llvm %s -o - | FileCheck %s
 
 // CHECK-LABEL: @test1(
 // CHECK-NEXT:  entry:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D109078: [clang][driver][AIX] Add system libc++ header paths to driver

2021-09-10 Thread Zarko Todorovski via Phabricator via cfe-commits
ZarkoCA added inline comments.



Comment at: clang/test/Driver/aix-toolchain-include.cpp:31
+// CHECK-INTERNAL-INCLUDE:  "-isysroot" "[[SYSROOT:[^"]+]]"
+// CHECK-INTERNAL-INCLUDE-CXX:  "-internal-isystem" 
"[[SYSROOT]]/opt/IBM/openxlCSDK/include/c++/v1"
+// CHECK-INTERNAL-INCLUDE-CXX:  "-D__LIBC_NO_CPP_MATH_OVERLOADS__"

It looks like this test is failing the pre-merge check on the x86 bot because 
this variable isn't captured correctly.
From what I can see, I think you can fix this by capturing it in the RUN line 
instead. 

Eg. I found this `test/Driver/darwin-header-search-libcxx.cpp` and 
https://llvm.org/docs/CommandGuide/FileCheck.html#cmdoption-filecheck-d-var.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109078

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


[PATCH] D109506: [RFC] Print current request context along with the stack trance in clangd

2021-09-10 Thread Emma Blink via Phabricator via cfe-commits
0x1eaf added a comment.

Thank you for such a prompt and thorough review!

Please consider all the comments I haven't replied to acknowledged and I'm 
going to resolve the issues with the next update.




Comment at: clang-tools-extra/clangd/JSONTransport.cpp:117
+  OS << "Signalled while processing message:\n";
+  OS << JSON << "\r\n";
+});

sammccall wrote:
> why \r?
the message itself is terminated with `\r\n` in the protocol and I just 
mimicked it for no good reason — will correct



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:1381
+  auto &OS = llvm::errs();
+  OS << "Signalled during AST action:\n";
+  auto &Command = FileInputs.CompileCommand;

sammccall wrote:
> the name of the action is available as CurrentRequest->Action, which I think 
> is safe to either pass into this function or read directly here.
I've noticed the the action name is always hardcoded as “Build AST ({version})” 
and just logged the version directly below, but I guess it's not forward 
compatible, so I'm going to log both…



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:1392
+  OS << "Contents:\n";
+  OS << FileInputs.Contents << "\n";
+}

sammccall wrote:
> sammccall wrote:
> > hmm, this is potentially really useful (could gather full reproducers) but 
> > also is going to dominate the output and make it annoying to see the stack 
> > traces/other details. I'm worried this may make this feature net-negative 
> > for a majority of users, who won't find the right parts of the output to 
> > report...
> > 
> > How critical do you think this is for debugging crashes in practice? (I 
> > suspect fairly important!)
> > Since we're taking liberties with async-signal-safety anyway, it might be 
> > possible to get this sent to a tempfile, which might be more useful. In any 
> > case, we might want full file dumps to be off by default outside of 
> > environments where anyone is likely to actually try to get the reproducers.
> > 
> > I'd probably suggest leaving this out of the initial patch entirely so we 
> > can focus on getting the rest of the mechanism right.
> another thought along the lines of reproducers (but nothing for this patch)...
> 
> If we're working on a file and have a preamble, then the headers that make up 
> the preamble are relevant. In practice it's hard to reproduce bug reports we 
> get because we need all their headers. If we're using a preamble then just 
> dumping all the filenames it includes would make it possible for some tool to 
> take the crash report and zip up a reproducer.
> 
> (This probably needs the ability to run all of the handlers for the current 
> thread, not just the top of the stack, since we acquire the relevant preamble 
> later)
> How critical do you think this is for debugging crashes in practice?

For us it would likely be of utmost importance as our VSCode extension routes 
requests to [Glean](https://glean.software) until local clangd finishes the 
compilation, so clangd ends up mostly being used for modified files, and the 
crashes might be unreproducible on the original source…

> I'd probably suggest leaving this out of the initial patch entirely so we can 
> focus on getting the rest of the mechanism right.

Alright, will remove the file contents with the next update.

> In any case, we might want full file dumps to be off by default outside of 
> environments where anyone is likely to actually try to get the reproducers.

What would be the best way to re-add it in a subsequent revision: make it 
configurable via a command line option, or via an environment variable? And if 
it's just an env var, maybe we could include it conditionally in this revision?

> If we're using a preamble then just dumping all the filenames it includes 
> would make it possible for some tool to take the crash report and zip up a 
> reproducer.

We had discussions within the team about potentially implementing a similar 
tool, but the rough idea was to rely on VCS to collect the changes as the delta 
would normally be smaller than bundling all the headers that the TU includes. 
But if the VCS-agnostic approach would be simpler and more portable — I'm all 
for it :)



Comment at: clang-tools-extra/clangd/support/ThreadSignalHandler.cpp:15
+
+static llvm::sys::ThreadLocal CurrentCallback;
+

sammccall wrote:
> sammccall wrote:
> > sammccall wrote:
> > > we assume `thread_local` in clangd (see support/Context.ccp)
> > > 
> > > It's possible that llvm::sys::ThreadLocal happens to play nicer with 
> > > signal handlers in practice (none of these are completely safe!), but 
> > > unless we've seen some concrete evidence I'd rather just have `static 
> > > thread_local ThreadSignalHandlerCallback*` here
> > we can quite easily support a stack of handlers, such that we dump *all* 
> > living handlers on the crashing thread.
> > 
> > just give e

[PATCH] D97699: [analyzer] Add InvalidPtrChecker

2021-09-10 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/cert/InvalidPtrChecker.cpp:159
+// Note: This pointer has type 'const MemRegion *'
+REGISTER_TRAIT_WITH_PROGRAMSTATE(EnvPtrRegion, const void *)
+

martong wrote:
> Why is it `const void *`? Why can't we use `const MemRegion *` and get rid of 
> the ugly reinterpret_cast?  There must be a reason ,which I'd like to see 
> documented in the comments. 
The trait is only specialized to `const void*` and `void*` see here:

https://github.com/llvm/llvm-project/blob/main/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramStateTrait.h#L298-L323

```lang=C++
template <> struct ProgramStatePartialTrait
template <> struct ProgramStatePartialTrait
```

I'm not exactly sure why don't we specialize to //any// pointer type of type 
`T`.


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

https://reviews.llvm.org/D97699

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


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

2021-09-10 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LG, let's wait for @Fznamznon though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109315

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


[PATCH] D109361: [clang][Driver] Pick the last --driver-mode in case of multiple ones

2021-09-10 Thread Hans Wennborg via Phabricator via cfe-commits
hans added a comment.

In D109361#2986687 , @hans wrote:

> Thanks! I tried this locally and it fixes the issue I mentioned on D109361 
> 

Corection: it fixes the issue that that I mentioned on D106789 
 obviously.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109361

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


[PATCH] D109607: [X86][WIP] Refactor GetSSETypeAtOffset

2021-09-10 Thread Pengfei Wang via Phabricator via cfe-commits
pengfei created this revision.
pengfei requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109607

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/X86/avx512fp16-abi.c

Index: clang/test/CodeGen/X86/avx512fp16-abi.c
===
--- clang/test/CodeGen/X86/avx512fp16-abi.c
+++ clang/test/CodeGen/X86/avx512fp16-abi.c
@@ -147,3 +147,13 @@
   x.e = e;
   return x;
 }
+
+struct float2 {
+  struct {};
+  float a;
+  float b;
+};
+
+float pr51813(floata s) {
+  return s.a;
+}
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -3377,22 +3377,18 @@
   return false;
 }
 
-/// ContainsFloatAtOffset - Return true if the specified LLVM IR type has a
-/// float member at the specified offset.  For example, {int,{float}} has a
-/// float at offset 4.  It is conservatively correct for this routine to return
-/// false.
-static bool ContainsFloatAtOffset(llvm::Type *IRType, unsigned IROffset,
-  const llvm::DataLayout &TD) {
-  // Base case if we find a float.
-  if (IROffset == 0 && IRType->isFloatTy())
-return true;
+/// getTypeAtOffset - Return a first class type at the specified offset.
+static llvm::Type *getTypeAtOffset(llvm::Type *IRType, unsigned IROffset,
+   const llvm::DataLayout &TD) {
+  if (IROffset == 0 && IRType->isFirstClassType())
+return IRType;
 
   // If this is a struct, recurse into the field at the specified offset.
   if (llvm::StructType *STy = dyn_cast(IRType)) {
 const llvm::StructLayout *SL = TD.getStructLayout(STy);
 unsigned Elt = SL->getElementContainingOffset(IROffset);
 IROffset -= SL->getElementOffset(Elt);
-return ContainsFloatAtOffset(STy->getElementType(Elt), IROffset, TD);
+return getTypeAtOffset(STy->getElementType(Elt), IROffset, TD);
   }
 
   // If this is an array, recurse into the field at the specified offset.
@@ -3400,40 +3396,10 @@
 llvm::Type *EltTy = ATy->getElementType();
 unsigned EltSize = TD.getTypeAllocSize(EltTy);
 IROffset -= IROffset/EltSize*EltSize;
-return ContainsFloatAtOffset(EltTy, IROffset, TD);
+return getTypeAtOffset(EltTy, IROffset, TD);
   }
 
-  return false;
-}
-
-/// ContainsHalfAtOffset - Return true if the specified LLVM IR type has a
-/// half member at the specified offset.  For example, {int,{half}} has a
-/// half at offset 4.  It is conservatively correct for this routine to return
-/// false.
-/// FIXME: Merge with ContainsFloatAtOffset
-static bool ContainsHalfAtOffset(llvm::Type *IRType, unsigned IROffset,
- const llvm::DataLayout &TD) {
-  // Base case if we find a float.
-  if (IROffset == 0 && IRType->isHalfTy())
-return true;
-
-  // If this is a struct, recurse into the field at the specified offset.
-  if (llvm::StructType *STy = dyn_cast(IRType)) {
-const llvm::StructLayout *SL = TD.getStructLayout(STy);
-unsigned Elt = SL->getElementContainingOffset(IROffset);
-IROffset -= SL->getElementOffset(Elt);
-return ContainsHalfAtOffset(STy->getElementType(Elt), IROffset, TD);
-  }
-
-  // If this is an array, recurse into the field at the specified offset.
-  if (llvm::ArrayType *ATy = dyn_cast(IRType)) {
-llvm::Type *EltTy = ATy->getElementType();
-unsigned EltSize = TD.getTypeAllocSize(EltTy);
-IROffset -= IROffset / EltSize * EltSize;
-return ContainsHalfAtOffset(EltTy, IROffset, TD);
-  }
-
-  return false;
+  return nullptr;
 }
 
 /// GetSSETypeAtOffset - Return a type that will be passed by the backend in the
@@ -3441,40 +3407,33 @@
 llvm::Type *X86_64ABIInfo::
 GetSSETypeAtOffset(llvm::Type *IRType, unsigned IROffset,
QualType SourceTy, unsigned SourceOffset) const {
-  // If the high 32 bits are not used, we have three choices. Single half,
-  // single float or two halfs.
-  if (BitsContainNoUserData(SourceTy, SourceOffset * 8 + 32,
-SourceOffset * 8 + 64, getContext())) {
-if (ContainsFloatAtOffset(IRType, IROffset, getDataLayout()))
-  return llvm::Type::getFloatTy(getVMContext());
-if (ContainsHalfAtOffset(IRType, IROffset + 2, getDataLayout()))
-  return llvm::FixedVectorType::get(llvm::Type::getHalfTy(getVMContext()),
-2);
-
-return llvm::Type::getHalfTy(getVMContext());
-  }
-
-  // We want to pass as <2 x float> if the LLVM IR type contains a float at
-  // offset+0 and offset+4. Walk the LLVM IR type to find out if this is the
-  // case.
-  if (ContainsFloatAtOffset(IRType, IROffset, getDataLayout()) &&
-  ContainsFloatAtOffset(IRType, IROffset + 4, getDataLayout()))
-return llvm::FixedVectorType::get(llvm::Type::getF

[PATCH] D109531: [CSSPGO] Enable pseudo probe instrumentation in O0 mode.

2021-09-10 Thread Sergey Pupyrev via Phabricator via cfe-commits
spupyrev added a comment.

In D109531#2993394 , @wmi wrote:

> In D109531#2992721 , @hoy wrote:
>
>> In D109531#2992702 , @wenlei wrote:
>>
>>> The change makes sense given instr PGO also happens for O0. But 
>>> practically, if a file is being built with O0, do we care about its profile 
>>> given we're not really optimizing it anyways? Functions from O0 modules are 
>>> not supposed to be inlined into O1 
>>> + modules either.
>>
>> We probably don't care about performance for O0 build. The change is for 
>> consistency, also makes the compiler happy which otherwise will complain 
>> about "Pseudo-probe-based profile requires SampleProfileProbePass" for O0 
>> modules that don't have probes.
>
> The complain message is emitted in SampleProfileLoader::doInitialization. 
> llvm will not run SampleProfileLoader pass for O0 module. Why there is the 
> complain?

We've encountered this exception while building an old version of gcc (8.3) 
with llvm-12. As Hongtao pointed out, they sometimes try to build targets with 
"-flto" but without "-O2/O3 ". 
Surely, the right "fix" would be to modify the gcc build scripts (which is 
possibly already done in later gcc releases); this workaround is to make sure 
we can also process "incorrect" builds.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109531

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


[PATCH] D109608: [clang][ASTImporter] Generic attribute import handling (first step).

2021-09-10 Thread Balázs Kéri via Phabricator via cfe-commits
balazske created this revision.
Herald added subscribers: whisperity, martong, teemperor, gamesh411, Szelethus, 
dkrupp.
Herald added a reviewer: a.sidorin.
Herald added a reviewer: shafik.
balazske requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Import of Attr objects was incomplete in ASTImporter.
This change introduces support for a generic way of importing an attribute.
For an usage example import of the attribute AssertCapability is
added to ASTImporter.
Updating the old attribute import code and adding new attributes or extending
the generic functions (if needed) is future work.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109608

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

Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -6406,6 +6406,82 @@
 ToSM.getBufferOrFake(ImportedID, SourceLocation()).getBuffer());
 }
 
+struct ImportAttributes : public ASTImporterOptionSpecificTestBase {
+  void checkAttrImportCommon(const Attr *From, const Attr *To,
+ const Decl *ToD) {
+
+// Verify that dump does not crash because invalid data.
+ToD->dump();
+
+EXPECT_EQ(From->getParsedKind(), To->getParsedKind());
+EXPECT_EQ(From->getSyntax(), To->getSyntax());
+if (From->getAttrName()) {
+  EXPECT_TRUE(To->getAttrName());
+  EXPECT_STREQ(From->getAttrName()->getNameStart(),
+   To->getAttrName()->getNameStart());
+} else {
+  EXPECT_FALSE(To->getAttrName());
+}
+if (From->getScopeName()) {
+  EXPECT_TRUE(To->getScopeName());
+  EXPECT_STREQ(From->getScopeName()->getNameStart(),
+   To->getScopeName()->getNameStart());
+} else {
+  EXPECT_FALSE(To->getScopeName());
+}
+EXPECT_EQ(From->getSpellingListIndex(), To->getSpellingListIndex());
+EXPECT_STREQ(From->getSpelling(), To->getSpelling());
+EXPECT_EQ(From->isInherited(), To->isInherited());
+EXPECT_EQ(From->isImplicit(), To->isImplicit());
+EXPECT_EQ(From->isPackExpansion(), To->isPackExpansion());
+EXPECT_EQ(From->isLateParsed(), To->isLateParsed());
+  }
+
+  template 
+  void importAttr(const char *Code, AT *&FromAttr, AT *&ToAttr) {
+static_assert(std::is_base_of::value, "AT should be an Attr");
+static_assert(std::is_base_of::value, "DT should be a Decl");
+
+Decl *FromTU = getTuDecl(Code, Lang_CXX11, "input.cc");
+DT *FromD =
+FirstDeclMatcher().match(FromTU, namedDecl(hasName("test")));
+ASSERT_TRUE(FromD);
+
+DT *ToD = Import(FromD, Lang_CXX11);
+ASSERT_TRUE(ToD);
+
+FromAttr = FromD->template getAttr();
+ToAttr = ToD->template getAttr();
+ASSERT_TRUE(FromAttr);
+EXPECT_TRUE(ToAttr);
+
+checkAttrImportCommon(FromAttr, ToAttr, ToD);
+  }
+
+  template  void checkImported(const T *From, const T *To) {
+EXPECT_TRUE(To);
+EXPECT_NE(From, To);
+  }
+
+  template 
+  void checkImportVariadicArg(const llvm::iterator_range &From,
+  const llvm::iterator_range &To) {
+for (auto FromI = From.begin(), ToI = To.begin(); FromI != From.end();
+ ++FromI, ++ToI) {
+  ASSERT_NE(ToI, To.end());
+  checkImported(*FromI, *ToI);
+}
+  }
+};
+
+template <>
+void ImportAttributes::checkImported(const Decl *From, const Decl *To) {
+  EXPECT_TRUE(To);
+  EXPECT_NE(From, To);
+  EXPECT_EQ(To->getTranslationUnitDecl(),
+ToAST->getASTContext().getTranslationUnitDecl());
+}
+
 TEST_P(ASTImporterOptionSpecificTestBase, ImportExprOfAlignmentAttr) {
   // Test if import of these packed and aligned attributes does not trigger an
   // error situation where source location from 'From' context is referenced in
@@ -6466,6 +6542,17 @@
 ToAttr->getAttributeSpellingListIndex());
   EXPECT_EQ(FromAttr->getType()->getName(), ToAttr->getType()->getName());
 }
+
+TEST_P(ImportAttributes, ImportAssertCapability) {
+  AssertCapabilityAttr *FromAttr, *ToAttr;
+  importAttr(
+  R"(
+  void test(int A1, int A2) __attribute__((assert_capability(A1, A2)));
+  )",
+  FromAttr, ToAttr);
+  checkImportVariadicArg(FromAttr->args(), ToAttr->args());
+}
+
 template 
 auto ExtendWithOptions(const T &Values, const std::vector &Args) {
   auto Copy = Values;
@@ -6849,5 +6936,8 @@
 INSTANTIATE_TEST_SUITE_P(ParameterizedTests, ImportWithExternalSource,
  DefaultTestValuesForRunOptions);
 
+INSTANTIATE_TEST_SUITE_P(ParameterizedTests, ImportAttributes,
+ DefaultTestValuesForRunOptions);
+
 } // end namespace ast_matchers
 } // end namespace clang
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib

[PATCH] D109609: [C++4OpenCL] Add support for multiple address spaced destructors

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

This patch aims to add initial support for multiple address spaced destructors.
Currently this parses fine and the destructors are correctly added to the class,
but there is no logic to choose the correct destructor for a variable in a 
specific address space.
Currently it always picks the first destructor defined in the source code, 
regardless of the 
address space of the variable.

This is not aiming to be a complete implementation, as destructors are used in 
a very large
number of locations, and so doing all of it in one patch would be very 
difficult to review and code.

The goals for this patch is thus to add basic support for destructors, and to 
build a framework for
additional work to be done on this front.
Since this feature won't be completed in this patch, I have attempted to ensure 
that no C++
functionality is changed, to ensure that the changes will only affect C++ for 
OpenCL.
This also has the effect that whenever destructors aren't correctly implemented 
it will fallback
to default behaviour, which is exactly the same currently happens.

In summary destructors in C++ for OpenCL are currently unusable for multiple 
destructors. With
this patch the feature will be usable in the most common situation, and every 
bug that currently 
exists that isn't covered by the changes I have made here will continue to be 
bugs. The hope is that
this patch therefore is almost entirely a positive, since while it doesn't fix 
every bug, it will make the
feature actually work, and will create a base to fix the other bugs as they are 
discovered.

This is why it's mostly implemented through default parameters, as that will 
allow this change to
remain as small as it is, while also allowing further fixes to come along later.

The feature is also C++ for OpenCL specific to let the fast path remain when 
not utilizing the
address spaces, as this new implementation will be slower than the bitfields 
that C++ currently
uses, but I hope this can also be optimized in the future if it turns out to be 
very slow.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109609

Files:
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/DeclCXX.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/test/SemaOpenCLCXX/addrspace-destructors.clcpp

Index: clang/test/SemaOpenCLCXX/addrspace-destructors.clcpp
===
--- /dev/null
+++ clang/test/SemaOpenCLCXX/addrspace-destructors.clcpp
@@ -0,0 +1,50 @@
+// RUN: %clang_cc1 %s -pedantic -ast-dump | FileCheck %s
+
+// CHECK: CXXDestructorDecl {{.*}} used ~ExactDtor 'void () __private noexcept'
+struct ExactDtor {
+ ~ExactDtor() __private;
+};
+
+// CHECK: CXXDestructorDecl
+// CHECK-NOT: used
+// CHECK-SAME: ~OverloadedDtor 'void () __generic'
+// CHECK: CXXDestructorDecl {{.*}} used ~OverloadedDtor 'void () __private noexcept'
+struct OverloadedDtor {
+ ~OverloadedDtor() __generic;
+ ~OverloadedDtor() __private;
+};
+
+// CHECK: CXXDestructorDecl
+// CHECK-NOT: used
+// CHECK-SAME: ~ImplicitDtor 'void () __global'
+// CHECK: CXXDestructorDecl {{.*}} implicit used ~ImplicitDtor 'void () __private noexcept'
+struct ImplicitDtor {
+~ImplicitDtor() __global;
+};
+
+// CHECK: CXXDestructorDecl {{.*}} used ~Templated 'void () __generic noexcept'
+// CHECK: CXXDestructorDecl
+// CHECK-NOT: used
+// CHECK-SAME: ~Templated 'void () __global'
+template 
+struct Templated {
+~Templated() __generic;
+~Templated() __global;
+};
+
+// CHECK: CXXDestructorDecl {{.*}} used ~BothUsed 'void () __private noexcept'
+// CHECK: CXXDestructorDecl {{.*}} used ~BothUsed 'void () __global noexcept'
+struct BothUsed {
+~BothUsed() __private;
+~BothUsed() __global;
+};
+
+__global BothUsed g_inheriting;
+
+kernel void k() {
+__private ExactDtor exact;
+__private OverloadedDtor overloaded;
+__private ImplicitDtor implicit;
+__private Templated templated;
+__private BothUsed inheriting;
+}
Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -3054,13 +3054,10 @@
   Functions.append(Operators.begin(), Operators.end());
 }
 
-Sema::SpecialMemberOverloadResult Sema::LookupSpecialMember(CXXRecordDecl *RD,
-   CXXSpecialMember SM,
-   bool ConstArg,
-   bool VolatileArg,
-   bool RValueThis,
-

[PATCH] D87118: Add an explicit toggle for the static analyzer in clang-tidy

2021-09-10 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson added inline comments.
Herald added subscribers: manas, steakhal.
Herald added a project: clang-tools-extra.



Comment at: clang/lib/CMakeLists.txt:24
 add_subdirectory(IndexSerialization)
-if(CLANG_ENABLE_STATIC_ANALYZER)
-  add_subdirectory(StaticAnalyzer)

thakis wrote:
> hans wrote:
> > Why does removing the condition here work?
> As far as I understand, it just impacts which targets CMake generates. 
> clang/lib/FrontendTool/CMakeLists.txt only adds the dep on 
> clangStaticAnalyzerFrontend if CLANG_ENABLE_STATIC_ANALYZER is set, so this 
> doesn't change what gets built for "clang". If you build all targets, this 
> will now always build the analyzer sources and I suppose it makes it a bit 
> easier to accidentally depend on clangStaticAnalyzerFrontend , but I don't 
> know of another way to be able to link this into clang-tidy when it's not 
> built at all over here.
I just noticed that my builds (just a plain `ninja`) are compiling all static 
analyzer sources. I am explicitly passing `-DCLANG_ENABLE_STATIC_ANALYZER=OFF` 
to cmake (and not building any clang-tools-extra).
I feel like this was not happening before so it's possible there was some CMake 
change more recently that is now causing this behaviour.

I tried setting EXCLUDE_FROM_ALL 
(https://cmake.org/cmake/help/latest/prop_tgt/EXCLUDE_FROM_ALL.html) on the 
directories and targets but that didn't fix the issue for me.

How about changing the condition to
`if (CLANG_TIDY_ENABLE_STATIC_ANALYZER OR CLANG_ENABLE_STATIC_ANALYZER)`? Or 
will that not work since CLANG_TIDY_ENABLE_STATIC_ANALYZER isn't defined yet?


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

https://reviews.llvm.org/D87118

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


[PATCH] D109531: [CSSPGO] Enable pseudo probe instrumentation in O0 mode.

2021-09-10 Thread Wei Mi via Phabricator via cfe-commits
wmi added a comment.

In D109531#2993484 , @hoy wrote:

> In D109531#2993394 , @wmi wrote:
>
>> In D109531#2992721 , @hoy wrote:
>>
>>> In D109531#2992702 , @wenlei 
>>> wrote:
>>>
 The change makes sense given instr PGO also happens for O0. But 
 practically, if a file is being built with O0, do we care about its 
 profile given we're not really optimizing it anyways? Functions from O0 
 modules are not supposed to be inlined into O1 
 + modules either.
>>>
>>> We probably don't care about performance for O0 build. The change is for 
>>> consistency, also makes the compiler happy which otherwise will complain 
>>> about "Pseudo-probe-based profile requires SampleProfileProbePass" for O0 
>>> modules that don't have probes.
>>
>> The complain message is emitted in SampleProfileLoader::doInitialization. 
>> llvm will not run SampleProfileLoader pass for O0 module. Why there is the 
>> complain?
>
> Good question. It could happen in lto postlink which by default optimizes in 
> -O2 mode. More specifically, with the following command, both `cc1` and `lld` 
> will run in default mode, which is -O0 for cc1 and -O2 for lld.
>
>   clang -flto 1.cpp -v -fuse-ld=lld

I see. It seems a problem only exposed in monolithic lto. Could you add some 
comment before the change in PassBuilder.cpp?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109531

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


[PATCH] D109506: [RFC] Print current request context along with the stack trance in clangd

2021-09-10 Thread Emma Blink via Phabricator via cfe-commits
0x1eaf added inline comments.



Comment at: clang-tools-extra/clangd/support/ThreadSignalHandler.cpp:22
+  ThreadSignalHandlerCallback *Callback = CurrentCallback.get();
+  // TODO: ignore non thread local signals like SIGTERM
+  if (Callback) {

sammccall wrote:
> I think we should do this already, probably just starting with an allowlist 
> of `SIGBUS, SIGFPE, SIGILL, SIGSEGV` (these are signals that are delivered to 
> the thread that triggered them per the linux docs).
> 
> I'm also wondering how portable this assumption/mechanism is, e.g. whether we 
> should enable it for certain platforms only. I guess it's probably true for 
> unixy things, and apparently mostly true for windows too[1]? I'm a little 
> concerned *something* may go wrong on windows, though.
> 
> [1] 
> https://stackoverflow.com/questions/15879342/which-thread-are-signal-handlers-e-g-signalsigint-crtl-c-called-on
I've just looked into adding filtering by signal number and there doesn't seem 
to be a way to do this portably in LLVM. But it looks like it might be safe 
enough to skip the filtering at all:
* From a cursory look at Windows `Signals.inc` it looks like the “signal” 
handling is implemented via 
[SetUnhandledExceptionFilter()](https://docs.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-setunhandledexceptionfilter)
 which is thread-directed, and the `SetConsoleCtrlHandler()` callback [does not 
call](https://reviews.llvm.org/source/llvm-github/browse/main/llvm/lib/Support/Windows/Signals.inc$843-846)
 the registered handlers.
* And on Unix platforms the `AddSignalHandler()` callbacks are called 
[only](https://reviews.llvm.org/source/llvm-github/browse/main/llvm/include/llvm/Support/Signals.h$62-64)
 for 
[KillSigs](https://reviews.llvm.org/source/llvm-github/browse/main/llvm/lib/Support/Unix/Signals.inc$217)
 out of which only `SIGQUIT` seem to be process-directed and would be delivered 
to [any thread](https://man7.org/linux/man-pages/man7/signal.7.html) that is 
not blocking it, but if the thread gets delivered to has a 
`ThreadCrashReporter` installed during the interrupt — it seems to make sense 
to run the handler and let it print the thread-local context information (at 
least there seems to be no harm in doing so).

What do you think?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109506

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


[PATCH] D109531: [CSSPGO] Enable pseudo probe instrumentation in O0 mode.

2021-09-10 Thread Hongtao Yu via Phabricator via cfe-commits
hoy added a comment.

In D109531#2994823 , @wmi wrote:

> In D109531#2993484 , @hoy wrote:
>
>> In D109531#2993394 , @wmi wrote:
>>
>>> In D109531#2992721 , @hoy wrote:
>>>
 In D109531#2992702 , @wenlei 
 wrote:

> The change makes sense given instr PGO also happens for O0. But 
> practically, if a file is being built with O0, do we care about its 
> profile given we're not really optimizing it anyways? Functions from O0 
> modules are not supposed to be inlined into O1 
> + modules either.

 We probably don't care about performance for O0 build. The change is for 
 consistency, also makes the compiler happy which otherwise will complain 
 about "Pseudo-probe-based profile requires SampleProfileProbePass" for O0 
 modules that don't have probes.
>>>
>>> The complain message is emitted in SampleProfileLoader::doInitialization. 
>>> llvm will not run SampleProfileLoader pass for O0 module. Why there is the 
>>> complain?
>>
>> Good question. It could happen in lto postlink which by default optimizes in 
>> -O2 mode. More specifically, with the following command, both `cc1` and 
>> `lld` will run in default mode, which is -O0 for cc1 and -O2 for lld.
>>
>>   clang -flto 1.cpp -v -fuse-ld=lld
>
> I see. It seems a problem only exposed in monolithic lto. Could you add some 
> comment before the change in PassBuilder.cpp?

Sounds good, comment added.  Actually this can also happen in thinlto. Having 
probe inserted in O0 mode allows users to switch between arbitrary setups.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109531

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


[PATCH] D109531: [CSSPGO] Enable pseudo probe instrumentation in O0 mode.

2021-09-10 Thread Hongtao Yu via Phabricator via cfe-commits
hoy updated this revision to Diff 371942.
hoy added a comment.

Updating D109531 : [CSSPGO] Enable pseudo 
probe instrumentation in O0 mode.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109531

Files:
  clang/test/CodeGen/pseudo-probe-emit.c
  llvm/lib/Passes/PassBuilder.cpp


Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -1924,6 +1924,13 @@
 
   ModulePassManager MPM;
 
+  // Perform pseudo probe instrumentation in O0 mode. This is for the
+  // consistency between different build modes. For example, a LTO build can be
+  // mixed with an O0 prelink and an O2 postlink. Loading a sample profile in
+  // the postlink will require pseudo probe instrumentation in the prelink.
+  if (PGOOpt && PGOOpt->PseudoProbeForProfiling)
+MPM.addPass(SampleProfileProbePass(TM));
+
   if (PGOOpt && (PGOOpt->Action == PGOOptions::IRInstr ||
  PGOOpt->Action == PGOOptions::IRUse))
 addPGOInstrPassesForO0(
Index: clang/test/CodeGen/pseudo-probe-emit.c
===
--- clang/test/CodeGen/pseudo-probe-emit.c
+++ clang/test/CodeGen/pseudo-probe-emit.c
@@ -1,3 +1,4 @@
+// RUN: %clang_cc1 -O0 -fno-legacy-pass-manager -fpseudo-probe-for-profiling 
-debug-info-kind=limited -emit-llvm -o - %s | FileCheck %s
 // RUN: %clang_cc1 -O2 -fno-legacy-pass-manager -fpseudo-probe-for-profiling 
-debug-info-kind=limited -emit-llvm -o - %s | FileCheck %s
 
 // Check the generation of pseudoprobe intrinsic call


Index: llvm/lib/Passes/PassBuilder.cpp
===
--- llvm/lib/Passes/PassBuilder.cpp
+++ llvm/lib/Passes/PassBuilder.cpp
@@ -1924,6 +1924,13 @@
 
   ModulePassManager MPM;
 
+  // Perform pseudo probe instrumentation in O0 mode. This is for the
+  // consistency between different build modes. For example, a LTO build can be
+  // mixed with an O0 prelink and an O2 postlink. Loading a sample profile in
+  // the postlink will require pseudo probe instrumentation in the prelink.
+  if (PGOOpt && PGOOpt->PseudoProbeForProfiling)
+MPM.addPass(SampleProfileProbePass(TM));
+
   if (PGOOpt && (PGOOpt->Action == PGOOptions::IRInstr ||
  PGOOpt->Action == PGOOptions::IRUse))
 addPGOInstrPassesForO0(
Index: clang/test/CodeGen/pseudo-probe-emit.c
===
--- clang/test/CodeGen/pseudo-probe-emit.c
+++ clang/test/CodeGen/pseudo-probe-emit.c
@@ -1,3 +1,4 @@
+// RUN: %clang_cc1 -O0 -fno-legacy-pass-manager -fpseudo-probe-for-profiling -debug-info-kind=limited -emit-llvm -o - %s | FileCheck %s
 // RUN: %clang_cc1 -O2 -fno-legacy-pass-manager -fpseudo-probe-for-profiling -debug-info-kind=limited -emit-llvm -o - %s | FileCheck %s
 
 // Check the generation of pseudoprobe intrinsic call
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D109611: Fix CLANG_ENABLE_STATIC_ANALYZER=OFF building all analyzer source

2021-09-10 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson created this revision.
arichardson added reviewers: thakis, hans, tstellar.
Herald added subscribers: manas, steakhal, ASDenysPetrov, martong, dkrupp, 
donat.nagy, Szelethus, a.sidorin, baloghadamsoftware, mgorny.
arichardson requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Since https://reviews.llvm.org/D87118, the StaticAnalyzer directory is
added unconditionally. In theory this should not cause the static analyzer
sources to be built unless they are referenced by another target. However,
the clang-cpp target (defined in clang/tools/clang-shlib) uses the
CLANG_STATIC_LIBS global property to determine which libraries need to
be included. To solve this issue, this patch avoids adding libraries to
that property if EXCLUDE_FROM_ALL is set.

In case something like this comes up again: `cmake --graphviz=targets.dot`
is quite useful to see why a target is included as part of `ninja all`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109611

Files:
  clang/cmake/modules/AddClang.cmake
  clang/lib/StaticAnalyzer/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake


Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -429,10 +429,13 @@
 #  This is used to specify that this is a component library of
 #  LLVM which means that the source resides in llvm/lib/ and it is a
 #  candidate for inclusion into libLLVM.so.
+#   EXCLUDE_FROM_ALL
+#  Do not build this library as part of the default target, only
+#  if explicitly requested or when linked against.
 #   )
 function(llvm_add_library name)
   cmake_parse_arguments(ARG
-
"MODULE;SHARED;STATIC;OBJECT;DISABLE_LLVM_LINK_LLVM_DYLIB;SONAME;NO_INSTALL_RPATH;COMPONENT_LIB"
+
"MODULE;SHARED;STATIC;OBJECT;DISABLE_LLVM_LINK_LLVM_DYLIB;SONAME;NO_INSTALL_RPATH;COMPONENT_LIB;EXCLUDE_FROM_ALL"
 "OUTPUT_NAME;PLUGIN_TOOL;ENTITLEMENTS;BUNDLE_PATH"
 "ADDITIONAL_HEADERS;DEPENDS;LINK_COMPONENTS;LINK_LIBS;OBJLIBS"
 ${ARGN})
@@ -535,6 +538,9 @@
 
 # FIXME: Add name_static to anywhere in TARGET ${name}'s PROPERTY.
 set(ARG_STATIC)
+if(ARG_EXCLUDE_FROM_ALL OR EXCLUDE_FROM_ALL)
+  set_target_properties(${name_static} PROPERTIES EXCLUDE_FROM_ALL ON)
+endif()
   endif()
 
   if(ARG_MODULE)
@@ -546,6 +552,10 @@
 add_library(${name} STATIC ${ALL_FILES})
   endif()
 
+  if(ARG_EXCLUDE_FROM_ALL OR EXCLUDE_FROM_ALL)
+set_target_properties(${name} PROPERTIES EXCLUDE_FROM_ALL ON)
+  endif()
+
   if(ARG_COMPONENT_LIB)
 set_target_properties(${name} PROPERTIES LLVM_COMPONENT TRUE)
 set_property(GLOBAL APPEND PROPERTY LLVM_COMPONENT_LIBS ${name})
Index: clang/lib/StaticAnalyzer/CMakeLists.txt
===
--- clang/lib/StaticAnalyzer/CMakeLists.txt
+++ clang/lib/StaticAnalyzer/CMakeLists.txt
@@ -1,3 +1,10 @@
+# These directories can significantly impact build time, only build
+# them if anything depends on the clangStaticAnalyzer* libraries.
+if(NOT CLANG_ENABLE_STATIC_ANALYZER)
+  set_property(DIRECTORY PROPERTY EXCLUDE_FROM_ALL ON)
+  set(EXCLUDE_FROM_ALL ON)
+endif()
+
 add_subdirectory(Core)
 add_subdirectory(Checkers)
 add_subdirectory(Frontend)
Index: clang/cmake/modules/AddClang.cmake
===
--- clang/cmake/modules/AddClang.cmake
+++ clang/cmake/modules/AddClang.cmake
@@ -100,7 +100,12 @@
   # The Xcode generator doesn't handle object libraries correctly.
   list(APPEND LIBTYPE OBJECT)
 endif()
-set_property(GLOBAL APPEND PROPERTY CLANG_STATIC_LIBS ${name})
+if (NOT EXCLUDE_FROM_ALL)
+  # Only include libraries that don't have EXCLUDE_FROM_ALL set. This
+  # ensure that the clang static analyzer libraries are not compiled
+  # as part of clang-shlib if CLANG_ENABLE_STATIC_ANALYZER=OFF.
+  set_property(GLOBAL APPEND PROPERTY CLANG_STATIC_LIBS ${name})
+endif()
   endif()
   llvm_add_library(${name} ${LIBTYPE} ${ARG_UNPARSED_ARGUMENTS} ${srcs})
 
@@ -110,6 +115,9 @@
   endif()
 
   foreach(lib ${libs})
+if (EXCLUDE_FROM_ALL)
+  continue()
+endif()
 if(TARGET ${lib})
   target_link_libraries(${lib} INTERFACE ${LLVM_COMMON_LIBS})
 


Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -429,10 +429,13 @@
 #  This is used to specify that this is a component library of
 #  LLVM which means that the source resides in llvm/lib/ and it is a
 #  candidate for inclusion into libLLVM.so.
+#   EXCLUDE_FROM_ALL
+#  Do not build this library as part of the default target, only
+#  if explicitly requested or when linked against.
 #   )
 function(llvm_add_library name)
   cmake_par

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

2021-09-10 Thread Saiyedul Islam via Phabricator via cfe-commits
saiislam updated this revision to Diff 371946.
saiislam marked an inline comment as done.
saiislam added a comment.

Added documentation and other fixes suggested by reviewers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105191

Files:
  clang/lib/Driver/ToolChains/AMDGPUOpenMP.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.h
  clang/lib/Driver/ToolChains/Cuda.cpp
  clang/test/Driver/Inputs/hip_dev_lib/libFatArchive.a
  clang/test/Driver/fat_archive.cpp

Index: clang/test/Driver/fat_archive.cpp
===
--- /dev/null
+++ clang/test/Driver/fat_archive.cpp
@@ -0,0 +1,91 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: amdgpu-registered-target
+
+// See the steps to create a fat archive near the end of the file.
+
+// Test succeeds if no linked error i.e. all external symbols in the archive
+// could be resolved correctly.
+// RUN: env LIBRARY_PATH=%T/../../../../../runtimes/runtimes-bins/openmp/libomptarget %clang -O2 -target x86_64-pc-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 %s -L%S/Inputs/hip_dev_lib -lFatArchive -o - | FileCheck %s -check-prefix=LINKERROR
+// LINKERROR-NOT: error: linker command failed with exit code 1
+
+// Given a FatArchive, clang-offload-bundler should be called to create a
+// device specific archive, which should be passed to llvm-link.
+// RUN: env LIBRARY_PATH=%T/../../../../../runtimes/runtimes-bins/openmp/libomptarget %clang -O2 -### -target x86_64-pc-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 %s -L%S/Inputs/hip_dev_lib -lFatArchive 2>&1 | FileCheck %s
+// CHECK: clang{{.*}}"-cc1" "-triple" "x86_64-pc-linux-gnu"{{.*}}"-o" "[[HOSTOBJ:.*.o]]" "-x" "ir"{{.*}}
+// CHECK: clang{{.*}}"-cc1"{{.*}}"-triple" "amdgcn-amd-amdhsa"{{.*}}"-emit-llvm-bc"{{.*}}"-target-cpu" "gfx906"{{.*}}"-o" "[[HOSTBC:.*.bc]]" "-x" "c++"{{.*}}.cpp
+// CHECK: clang-offload-bundler" "-unbundle" "-type=a" "-inputs={{.*}}/Inputs/hip_dev_lib/libFatArchive.a" "-targets=openmp-amdgcn-amd-amdhsa-gfx906" "-outputs=[[DEVICESPECIFICARCHIVE:.*.a]]" "-allow-missing-bundles"
+// CHECK: llvm-link{{.*}}"[[HOSTBC]]" "[[DEVICESPECIFICARCHIVE]]" "-o" "{{.*}}-gfx906-linked-{{.*}}.bc"
+// CHECK: ld.lld"{{.*}}" "-L{{.*}}/Inputs/hip_dev_lib" "{{.*}}"[[HOSTOBJ]]" "-lFatArchive" "{{.*}}" "-lomp{{.*}}-lomptarget"
+// expected-no-diagnostics
+
+// Tests for linker and loader errors in case external symbols are not found in
+// the FatArchive.
+// RUN: env LIBRARY_PATH=%T/../../../../../runtimes/runtimes-bins/openmp/libomptarget not %clang -O2 -target x86_64-pc-linux-gnu -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -Xopenmp-target=amdgcn-amd-amdhsa -march=gfx906 %s -L%S/Inputs/hip_dev_lib -lFatArchive -DMISSING=1 2>&1 | FileCheck %s -check-prefix=MISSINGSYM
+// MISSINGSYM: ld.lld: error: undefined symbol: func_missing
+// MISSINGSYM: error: linker command failed with exit code 1
+
+#ifndef HEADER
+#define HEADER
+
+#define N 10
+
+#pragma omp declare target
+// Functions defined in Fat Archive.
+extern "C" void func_present(float *, float *, unsigned);
+
+#ifdef MISSING
+// Function not defined in the fat archive.
+extern "C" void func_missing(float *, float *, unsigned);
+#endif
+
+#pragma omp end declare target
+
+int main() {
+  float in[N], out[N], sum = 0;
+  unsigned i;
+
+#pragma omp parallel for
+  for (i = 0; i < N; ++i) {
+in[i] = i;
+  }
+
+  func_present(in, out, N); // Returns out[i] = a[i] * 0
+
+#ifdef MISSING
+  func_missing(in, out, N); // Should throw an error here
+#endif
+
+#pragma omp parallel for reduction(+ \
+   : sum)
+  for (i = 0; i < N; ++i)
+sum += out[i];
+
+  if (!sum)
+return 0;
+  return sum;
+}
+
+#endif
+
+/
+   Steps to create Fat Archive (libFatArchive.a) 
+*
+* File: func_1.c 
+void func_present(float* in, float* out, unsigned n){
+  unsigned i;
+  #pragma omp target teams distribute parallel for map(to: in[0:n]) map(from: out[0:n])
+  for(i=0; i(
   JA, *this,
   ResponseFileSupport{ResponseFileSupport::RF_Full, llvm::sys::WEM_UTF8,
@@ -743,6 +746,8 @@
 
 addOpenMPDeviceRTL(getDriver(), DriverArgs, CC1Args, BitcodeSuffix,
getTriple());
+AddStaticDeviceLibs(getDriver(), DriverArgs, CC1Args, "nvptx", GpuArch,
+/* bitcode SDL?*/ true, /* PostClang Link? */ true);
   }
 }
 
Index: clang/lib/Driver/ToolChains/CommonArgs.h
===
--- clang/lib/Driver/ToolChains/CommonArgs.h
+++ clang/lib/Driver/ToolChains/CommonArgs.h
@@ -49,6 +49,37 @@
  

[PATCH] D87118: Add an explicit toggle for the static analyzer in clang-tidy

2021-09-10 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson added inline comments.



Comment at: clang/lib/CMakeLists.txt:24
 add_subdirectory(IndexSerialization)
-if(CLANG_ENABLE_STATIC_ANALYZER)
-  add_subdirectory(StaticAnalyzer)

arichardson wrote:
> thakis wrote:
> > hans wrote:
> > > Why does removing the condition here work?
> > As far as I understand, it just impacts which targets CMake generates. 
> > clang/lib/FrontendTool/CMakeLists.txt only adds the dep on 
> > clangStaticAnalyzerFrontend if CLANG_ENABLE_STATIC_ANALYZER is set, so this 
> > doesn't change what gets built for "clang". If you build all targets, this 
> > will now always build the analyzer sources and I suppose it makes it a bit 
> > easier to accidentally depend on clangStaticAnalyzerFrontend , but I don't 
> > know of another way to be able to link this into clang-tidy when it's not 
> > built at all over here.
> I just noticed that my builds (just a plain `ninja`) are compiling all static 
> analyzer sources. I am explicitly passing 
> `-DCLANG_ENABLE_STATIC_ANALYZER=OFF` to cmake (and not building any 
> clang-tools-extra).
> I feel like this was not happening before so it's possible there was some 
> CMake change more recently that is now causing this behaviour.
> 
> I tried setting EXCLUDE_FROM_ALL 
> (https://cmake.org/cmake/help/latest/prop_tgt/EXCLUDE_FROM_ALL.html) on the 
> directories and targets but that didn't fix the issue for me.
> 
> How about changing the condition to
> `if (CLANG_TIDY_ENABLE_STATIC_ANALYZER OR CLANG_ENABLE_STATIC_ANALYZER)`? Or 
> will that not work since CLANG_TIDY_ENABLE_STATIC_ANALYZER isn't defined yet?
Possible solution: D109611


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

https://reviews.llvm.org/D87118

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


[clang] 45e8e08 - [OpenMP] Encode `omp [...] assume[...]` assumptions with `omp[x]` prefix

2021-09-10 Thread Johannes Doerfert via cfe-commits

Author: Johannes Doerfert
Date: 2021-09-10T12:08:52-05:00
New Revision: 45e8e084921b99ca36131d7f90359c70c4e1a25c

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

LOG: [OpenMP] Encode `omp [...] assume[...]` assumptions with `omp[x]` prefix

Since these assumptions are coming from OpenMP it makes sense to mark
them as such in the generic IR encoding. Standardized assumptions will
be named
  omp_ASSUMPTION_NAME
and extensions will be named
  ompx_ASSUMPTION_NAME
which is the OpenMP 5.2 syntax for "extensions" of any kind.

This also matches what the OpenMP-Opt pass expects.

Summarized,
  #pragma omp [...] assume[s] no_parallelism
now generates the same IR assumption annotation as
  __attribute__((assume("omp_no_parallelism")))

Reviewed By: jhuber6

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

Added: 


Modified: 
clang/include/clang/Sema/Sema.h
clang/lib/Parse/ParseOpenMP.cpp
clang/lib/Sema/SemaOpenMP.cpp
clang/test/OpenMP/assumes_codegen.cpp
clang/test/OpenMP/assumes_include_nvptx.cpp
clang/test/OpenMP/assumes_print.cpp
clang/test/OpenMP/assumes_template_print.cpp

Removed: 




diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 2794b0f2a3e13..710abeb1ea514 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -10462,7 +10462,7 @@ class Sema final {
   /// Called on well-formed '#pragma omp [begin] assume[s]'.
   void ActOnOpenMPAssumesDirective(SourceLocation Loc,
OpenMPDirectiveKind DKind,
-   ArrayRef Assumptions,
+   ArrayRef Assumptions,
bool SkippedClauses);
 
   /// Check if there is an active global `omp begin assumes` directive.

diff  --git a/clang/lib/Parse/ParseOpenMP.cpp b/clang/lib/Parse/ParseOpenMP.cpp
index 5f8f984096676..e953446cd5bac 100644
--- a/clang/lib/Parse/ParseOpenMP.cpp
+++ b/clang/lib/Parse/ParseOpenMP.cpp
@@ -1532,7 +1532,7 @@ bool 
Parser::parseOMPDeclareVariantMatchClause(SourceLocation Loc,
 ///
 void Parser::ParseOpenMPAssumesDirective(OpenMPDirectiveKind DKind,
  SourceLocation Loc) {
-  SmallVector Assumptions;
+  SmallVector Assumptions;
   bool SkippedClauses = false;
 
   auto SkipBraces = [&](llvm::StringRef Spelling, bool IssueNote) {
@@ -1599,9 +1599,11 @@ void 
Parser::ParseOpenMPAssumesDirective(OpenMPDirectiveKind DKind,
 }
 
 assert(II && "Expected an identifier clause!");
-StringRef Assumption = II->getName();
+std::string Assumption = II->getName().str();
 if (ACMI.StartsWith)
-  Assumption = Assumption.substr(ACMI.Identifier.size());
+  Assumption = "ompx_" + Assumption.substr(ACMI.Identifier.size());
+else
+  Assumption = "omp_" + Assumption;
 Assumptions.push_back(Assumption);
   }
 

diff  --git a/clang/lib/Sema/SemaOpenMP.cpp b/clang/lib/Sema/SemaOpenMP.cpp
index 63598f20a4cf7..cbfb0dd63b5b2 100644
--- a/clang/lib/Sema/SemaOpenMP.cpp
+++ b/clang/lib/Sema/SemaOpenMP.cpp
@@ -3213,7 +3213,7 @@ Sema::ActOnOpenMPRequiresDirective(SourceLocation Loc,
 
 void Sema::ActOnOpenMPAssumesDirective(SourceLocation Loc,
OpenMPDirectiveKind DKind,
-   ArrayRef Assumptions,
+   ArrayRef Assumptions,
bool SkippedClauses) {
   if (!SkippedClauses && Assumptions.empty())
 Diag(Loc, diag::err_omp_no_clause_for_directive)

diff  --git a/clang/test/OpenMP/assumes_codegen.cpp 
b/clang/test/OpenMP/assumes_codegen.cpp
index e359a87bfdc15..2217e3ab567e1 100644
--- a/clang/test/OpenMP/assumes_codegen.cpp
+++ b/clang/test/OpenMP/assumes_codegen.cpp
@@ -67,41 +67,41 @@ int lambda_outer() {
 }
 #pragma omp end assumes
 
-// AST:  void foo() 
__attribute__((assume("no_openmp_routines,another_warning,after_invalid_clauses")))
 __attribute__((assume("no_openmp"))) {
+// AST:  void foo() 
__attribute__((assume("omp_no_openmp_routines,ompx_another_warning,ompx_after_invalid_clauses")))
 __attribute__((assume("omp_no_openmp"))) {
 // AST-NEXT: }
 // AST-NEXT: class BAR {
 // AST-NEXT: public:
-// AST-NEXT: BAR() __attribute__((assume("range_bar_only"))) 
__attribute__((assume("range_bar_only_2"))) 
__attribute__((assume("no_openmp_routines,another_warning,after_invalid_clauses")))
 __attribute__((assume("no_openmp"))) {
+// AST-NEXT: BAR() __attribute__((assume("ompx_range_bar_only"))) 
__attribute__((assume("ompx_range_bar_only_2"))) 
__attribute__((assume("omp_no_openmp_routines,ompx_another_warning,ompx_after_invalid_clauses")))
 __attribute__((assume("omp_no_openmp")))

[PATCH] D105937: [OpenMP] Encode `omp [...] assume[...]` assumptions with `omp[x]` prefix

2021-09-10 Thread Johannes Doerfert 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 rG45e8e084921b: [OpenMP] Encode `omp [...] assume[...]` 
assumptions with `omp[x]` prefix (authored by jdoerfert).

Changed prior to commit:
  https://reviews.llvm.org/D105937?vs=358502&id=371950#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105937

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/assumes_codegen.cpp
  clang/test/OpenMP/assumes_include_nvptx.cpp
  clang/test/OpenMP/assumes_print.cpp
  clang/test/OpenMP/assumes_template_print.cpp

Index: clang/test/OpenMP/assumes_template_print.cpp
===
--- clang/test/OpenMP/assumes_template_print.cpp
+++ clang/test/OpenMP/assumes_template_print.cpp
@@ -17,7 +17,7 @@
 struct S {
   int a;
 // CHECK: template  struct S {
-// CHECK: void foo() __attribute__((assume("global_assumption"))) {
+// CHECK: void foo() __attribute__((assume("ompx_global_assumption"))) {
   void foo() {
 #pragma omp parallel
 {}
@@ -25,15 +25,15 @@
 };
 
 // CHECK: template<> struct S {
-// CHECK: void foo() __attribute__((assume("global_assumption"))) {
+// CHECK: void foo() __attribute__((assume("ompx_global_assumption"))) {
 
 #pragma omp begin assumes no_openmp
-// CHECK: void S_with_assumes_no_call() __attribute__((assume("no_openmp"))) __attribute__((assume("global_assumption"))) {
+// CHECK: void S_with_assumes_no_call() __attribute__((assume("omp_no_openmp"))) __attribute__((assume("ompx_global_assumption"))) {
 void S_with_assumes_no_call() {
   S s;
   s.a = 0;
 }
-// CHECK: void S_with_assumes_call() __attribute__((assume("no_openmp"))) __attribute__((assume("global_assumption"))) {
+// CHECK: void S_with_assumes_call() __attribute__((assume("omp_no_openmp"))) __attribute__((assume("ompx_global_assumption"))) {
 void S_with_assumes_call() {
   S s;
   s.a = 0;
@@ -42,7 +42,7 @@
 }
 #pragma omp end assumes
 
-// CHECK: void S_without_assumes() __attribute__((assume("global_assumption"))) {
+// CHECK: void S_without_assumes() __attribute__((assume("ompx_global_assumption"))) {
 void S_without_assumes() {
   S s;
   s.foo();
@@ -54,7 +54,7 @@
 template 
 struct P {
 // CHECK: template  struct P {
-// CHECK: void foo() __attribute__((assume("global_assumption"))) {
+// CHECK: void foo() __attribute__((assume("ompx_global_assumption"))) {
   int a;
   void foo() {
 #pragma omp parallel
@@ -65,21 +65,21 @@
 // TODO: Avoid the duplication here:
 
 // CHECK: template<> struct P {
-// CHECK: void foo() __attribute__((assume("global_assumption"))) __attribute__((assume("global_assumption"))) {
+// CHECK: void foo() __attribute__((assume("ompx_global_assumption"))) __attribute__((assume("ompx_global_assumption"))) {
 
-// CHECK: void P_without_assumes() __attribute__((assume("global_assumption"))) {
+// CHECK: void P_without_assumes() __attribute__((assume("ompx_global_assumption"))) {
 void P_without_assumes() {
   P p;
   p.foo();
 }
 
 #pragma omp begin assumes no_openmp
-// CHECK: void P_with_assumes_no_call() __attribute__((assume("no_openmp"))) __attribute__((assume("global_assumption"))) {
+// CHECK: void P_with_assumes_no_call() __attribute__((assume("omp_no_openmp"))) __attribute__((assume("ompx_global_assumption"))) {
 void P_with_assumes_no_call() {
   P p;
   p.a = 0;
 }
-// CHECK: void P_with_assumes_call() __attribute__((assume("no_openmp"))) __attribute__((assume("global_assumption"))) {
+// CHECK: void P_with_assumes_call() __attribute__((assume("omp_no_openmp"))) __attribute__((assume("ompx_global_assumption"))) {
 void P_with_assumes_call() {
   P p;
   p.a = 0;
Index: clang/test/OpenMP/assumes_print.cpp
===
--- clang/test/OpenMP/assumes_print.cpp
+++ clang/test/OpenMP/assumes_print.cpp
@@ -37,8 +37,8 @@
 }
 #pragma omp end assumes
 
-// CHECK: void foo() __attribute__((assume("no_openmp_routines"))) __attribute__((assume("no_openmp")))
-// CHECK: void bar() __attribute__((assume("range_bar_only"))) __attribute__((assume("range_bar_only_2"))) __attribute__((assume("no_openmp_routines"))) __attribute__((assume("no_openmp")))
-// CHECK: void baz() __attribute__((assume("1234"))) __attribute__((assume("no_openmp_routines"))) __attribute__((assume("no_openmp")))
+// CHECK: void foo() __attribute__((assume("omp_no_openmp_routines"))) __attribute__((assume("omp_no_openmp")))
+// CHECK: void bar() __attribute__((assume("ompx_range_bar_only"))) __attribute__((assume("ompx_range_bar_only_2"))) __attribute__((assume("omp_no_openmp_routines"))) __attribute__((assume("omp_no_openmp")))
+// CHECK: void baz() __attribute__((assume("ompx_1234"))) __attribute__((assume("omp

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

2021-09-10 Thread Mariya Podchishchaeva via Phabricator via cfe-commits
Fznamznon accepted this revision.
Fznamznon added a comment.

LGTM, thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109315

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


[PATCH] D109531: [CSSPGO] Enable pseudo probe instrumentation in O0 mode.

2021-09-10 Thread Wei Mi via Phabricator via cfe-commits
wmi accepted this revision.
wmi added a comment.

LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109531

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


[PATCH] D109599: [PowerPC][MMA] Allow MMA builtin types in pre-P10 compilation units

2021-09-10 Thread Kamau Bridgeman via Phabricator via cfe-commits
kamaub updated this revision to Diff 371954.
kamaub added a comment.

The condition for failing semantic chequing on mma builtins was incorrect,
updating this patch to correctly check the semantics and associated testing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109599

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/AST/ast-dump-ppc-types.c
  clang/test/CodeGen/builtins-ppc-pair-mma.c
  clang/test/CodeGen/ppc-mma-types.c
  clang/test/CodeGenCXX/ppc-mangle-mma-types.cpp
  clang/test/Sema/ppc-mma-builtins.c
  clang/test/Sema/ppc-pair-mma-types.c
  clang/test/Sema/ppc-paired-vector-builtins.c

Index: clang/test/Sema/ppc-paired-vector-builtins.c
===
--- /dev/null
+++ clang/test/Sema/ppc-paired-vector-builtins.c
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu pwr10 \
+// RUN:   -target-feature -paired-vector-memops -fsyntax-only %s -verify
+
+void test1(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __vector_pair res;
+  __builtin_vsx_assemble_pair(&res, vc, vc); // expected-error {{this builtin is only valid on POWER10 or later CPUs}}
+}
+
+void test2(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __builtin_vsx_disassemble_pair(resp, (__vector_pair*)vpp); // expected-error {{this builtin is only valid on POWER10 or later CPUs}}
+}
+
+void test3(const __vector_pair *vpp, signed long long offset, const __vector_pair *vp2) {
+  __vector_pair vp = __builtin_vsx_lxvp(offset, vpp); // expected-error {{this builtin is only valid on POWER10 or later CPUs}}
+  __builtin_vsx_stxvp(vp, offset, vp2); // expected-error {{this builtin is only valid on POWER10 or later CPUs}}
+}
+
+void test4(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __vector_quad vq = *((__vector_quad *)vqp);
+  __vector_pair vp = *((__vector_pair *)vpp);
+  __builtin_mma_xxmtacc(&vq); // expected-error {{this builtin is only valid on POWER10 or later CPUs}}
+  *((__vector_quad *)resp) = vq;
+}
+
+
Index: clang/test/Sema/ppc-pair-mma-types.c
===
--- clang/test/Sema/ppc-pair-mma-types.c
+++ clang/test/Sema/ppc-pair-mma-types.c
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -fsyntax-only \
-// RUN:   -target-cpu future %s -verify
+// RUN:   -target-cpu pwr10 %s -verify
 
 // The use of PPC MMA types is strongly restricted. Non-pointer MMA variables
 // can only be declared in functions and a limited number of operations are
Index: clang/test/Sema/ppc-mma-builtins.c
===
--- /dev/null
+++ clang/test/Sema/ppc-mma-builtins.c
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -target-cpu pwr10 \
+// RUN:   -target-feature -mma -fsyntax-only %s -verify
+
+void test1(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __vector_pair res;
+  __builtin_vsx_assemble_pair(&res, vc, vc);
+}
+
+void test2(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __builtin_vsx_disassemble_pair(resp, (__vector_pair*)vpp);
+}
+
+void test3(const __vector_pair *vpp, signed long long offset, const __vector_pair *vp2) {
+  __vector_pair vp = __builtin_vsx_lxvp(offset, vpp);
+  __builtin_vsx_stxvp(vp, offset, vp2);
+}
+
+void test4(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __vector_quad vq = *((__vector_quad *)vqp);
+  __vector_pair vp = *((__vector_pair *)vpp);
+  __builtin_mma_xxmtacc(&vq); // expected-error {{this builtin is only valid on POWER10 or later CPUs}}
+  *((__vector_quad *)resp) = vq;
+}
+
+void test5(unsigned char *vqp, unsigned char *vpp, vector unsigned char vc, unsigned char *resp) {
+  __vector_quad vq = *((__vector_quad *)vqp);
+  __vector_pair vp = *((__vector_pair *)vpp);
+  __builtin_mma_pmxvf64ger(&vq, vp, vc, 0, 0); // expected-error {{this builtin is only valid on POWER10 or later CPUs}}
+  *((__vector_quad *)resp) = vq;
+}
+
+
Index: clang/test/CodeGenCXX/ppc-mangle-mma-types.cpp
===
--- clang/test/CodeGenCXX/ppc-mangle-mma-types.cpp
+++ clang/test/CodeGenCXX/ppc-mangle-mma-types.cpp
@@ -1,4 +1,8 @@
-// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu future %s \
+// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu pwr10 %s \
+// RUN:   -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu pwr9 %s \
+// RUN:   -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-linux-unknown -target-cpu pwr8 %

[clang] 50d7ecc - [NFC][clang] Improve test coverage for alignment manifestation on aligned allocation functions

2021-09-10 Thread Roman Lebedev via cfe-commits

Author: Roman Lebedev
Date: 2021-09-10T20:49:28+03:00
New Revision: 50d7ecc560b27d258c921abe39211926d46fbcff

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

LOG: [NFC][clang] Improve test coverage for alignment manifestation on aligned 
allocation functions

Added: 


Modified: 
clang/test/CodeGen/alloc-fns-alignment.c

Removed: 




diff  --git a/clang/test/CodeGen/alloc-fns-alignment.c 
b/clang/test/CodeGen/alloc-fns-alignment.c
index d2f9b467196a7..1ce0cfbad97b0 100644
--- a/clang/test/CodeGen/alloc-fns-alignment.c
+++ b/clang/test/CodeGen/alloc-fns-alignment.c
@@ -5,12 +5,14 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-malloc  
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-MALLOC
 // RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-calloc  
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-CALLOC
 // RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-realloc 
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-REALLOC
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fno-builtin-aligned_alloc 
-emit-llvm < %s  | FileCheck %s --check-prefix=NOBUILTIN-ALIGNED_ALLOC
 
 typedef __SIZE_TYPE__ size_t;
 
 void *malloc(size_t);
 void *calloc(size_t, size_t);
 void *realloc(void *, size_t);
+void *aligned_alloc(size_t, size_t);
 
 void *malloc_test(size_t n) {
   return malloc(n);
@@ -20,16 +22,59 @@ void *calloc_test(size_t n) {
   return calloc(1, n);
 }
 
-void *raalloc_test(void *p, size_t n) {
+void *realloc_test(void *p, size_t n) {
   return realloc(p, n);
 }
 
+void *aligned_alloc_variable_test(size_t n, size_t a) {
+  return aligned_alloc(a, n);
+}
+
+void *aligned_alloc_constant_test(size_t n) {
+  return aligned_alloc(8, n);
+}
+
+void *aligned_alloc_large_constant_test(size_t n) {
+  return aligned_alloc(4096, n);
+}
+
+// CHECK-LABEL: @malloc_test
 // ALIGN16: align 16 i8* @malloc
+
+// CHECK-LABEL: @calloc_test
 // ALIGN16: align 16 i8* @calloc
+
+// CHECK-LABEL: @realloc_test
 // ALIGN16: align 16 i8* @realloc
+
+// CHECK-LABEL: @aligned_alloc_variable_test
+// ALIGN16: align 16 i8* @aligned_alloc
+
+// CHECK-LABEL: @aligned_alloc_constant_test
+// ALIGN16: align 16 i8* @aligned_alloc
+
+// CHECK-LABEL: @aligned_alloc_large_constant_test
+// ALIGN16: align 16 i8* @aligned_alloc
+
+// CHECK-LABEL: @malloc_test
 // ALIGN8: align 8 i8* @malloc
+
+// CHECK-LABEL: @calloc_test
 // ALIGN8: align 8 i8* @calloc
+
+// CHECK-LABEL: @realloc_test
 // ALIGN8: align 8 i8* @realloc
+
+// CHECK-LABEL: @aligned_alloc_variable_test
+// ALIGN8: align 8 i8* @aligned_alloc
+
+// CHECK-LABEL: @aligned_alloc_constant_test
+// ALIGN8: align 8 i8* @aligned_alloc
+
+// CHECK-LABEL: @aligned_alloc_large_constant_test
+// ALIGN8: align 8 i8* @aligned_alloc
+
 // NOBUILTIN-MALLOC: declare i8* @malloc
 // NOBUILTIN-CALLOC: declare i8* @calloc
 // NOBUILTIN-REALLOC: declare i8* @realloc
+// NOBUILTIN-ALIGNED_ALLOC: declare i8* @aligned_alloc



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


[clang] 85ba583 - [NFCI][clang] Move allocation alignment manifestation for malloc-like into Sema from Codegen

2021-09-10 Thread Roman Lebedev via cfe-commits

Author: Roman Lebedev
Date: 2021-09-10T20:49:28+03:00
New Revision: 85ba583eba1902c386a55f5565f3c721bd6bcb23

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

LOG: [NFCI][clang] Move allocation alignment manifestation for malloc-like into 
Sema from Codegen

... so that it happens right next to 
`AddKnownFunctionAttributesForReplaceableGlobalAllocationFunction()`,
which is good for consistency.

Added: 


Modified: 
clang/lib/CodeGen/CGCall.cpp
clang/lib/Sema/SemaDecl.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 1ddd4d160b4bd..deb688513fd18 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -2066,24 +2066,6 @@ void CodeGenModule::ConstructAttributeList(StringRef 
Name,
   // allows it to work on indirect virtual function calls.
   if (AttrOnCallSite && TargetDecl->hasAttr())
 FuncAttrs.addAttribute(llvm::Attribute::NoMerge);
-
-  // Add known guaranteed alignment for allocation functions.
-  if (unsigned BuiltinID = Fn->getBuiltinID()) {
-switch (BuiltinID) {
-case Builtin::BIaligned_alloc:
-case Builtin::BIcalloc:
-case Builtin::BImalloc:
-case Builtin::BImemalign:
-case Builtin::BIrealloc:
-case Builtin::BIstrdup:
-case Builtin::BIstrndup:
-  RetAttrs.addAlignmentAttr(Context.getTargetInfo().getNewAlign() /
-Context.getTargetInfo().getCharWidth());
-  break;
-default:
-  break;
-}
-  }
 }
 
 // 'const', 'pure' and 'noalias' attributed functions are also nounwind.

diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 92c1a37fdab96..59726ad67fbb6 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -15146,6 +15146,30 @@ void Sema::AddKnownFunctionAttributes(FunctionDecl 
*FD) {
   else
 FD->addAttr(CUDAHostAttr::CreateImplicit(Context, FD->getLocation()));
 }
+
+// Add known guaranteed alignment for allocation functions.
+switch (BuiltinID) {
+case Builtin::BIaligned_alloc:
+case Builtin::BIcalloc:
+case Builtin::BImalloc:
+case Builtin::BImemalign:
+case Builtin::BIrealloc:
+case Builtin::BIstrdup:
+case Builtin::BIstrndup: {
+  if (!FD->hasAttr()) {
+unsigned NewAlign = Context.getTargetInfo().getNewAlign() /
+Context.getTargetInfo().getCharWidth();
+IntegerLiteral *Alignment = IntegerLiteral::Create(
+Context, Context.MakeIntValue(NewAlign, Context.UnsignedIntTy),
+Context.UnsignedIntTy, FD->getLocation());
+FD->addAttr(AssumeAlignedAttr::CreateImplicit(
+Context, Alignment, /*Offset=*/nullptr, FD->getLocation()));
+  }
+  break;
+}
+default:
+  break;
+}
   }
 
   AddKnownFunctionAttributesForReplaceableGlobalAllocationFunction(FD);



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


[clang] f3c2094 - [clang] `aligned_alloc` allocation function specifies alignment in first arg, manifest that knowledge

2021-09-10 Thread Roman Lebedev via cfe-commits

Author: Roman Lebedev
Date: 2021-09-10T20:49:29+03:00
New Revision: f3c2094d8c112f40923ef45953f66c4b2ecb6d01

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

LOG: [clang] `aligned_alloc` allocation function specifies alignment in first 
arg, manifest that knowledge

Mainly, if a constant value was passed as an alignment,
then we correctly annotate the alignment of the returned value
of @aligned_alloc. And if it wasn't constant,
then we also don't loose that, but emit an assumption.

Added: 


Modified: 
clang/lib/Sema/SemaDecl.cpp
clang/test/CodeGen/alloc-fns-alignment.c

Removed: 




diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 59726ad67fbb..cc3417d4ccba 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -15150,6 +15150,10 @@ void Sema::AddKnownFunctionAttributes(FunctionDecl 
*FD) {
 // Add known guaranteed alignment for allocation functions.
 switch (BuiltinID) {
 case Builtin::BIaligned_alloc:
+  if (!FD->hasAttr())
+FD->addAttr(AllocAlignAttr::CreateImplicit(Context, ParamIdx(1, FD),
+   FD->getLocation()));
+  LLVM_FALLTHROUGH;
 case Builtin::BIcalloc:
 case Builtin::BImalloc:
 case Builtin::BImemalign:

diff  --git a/clang/test/CodeGen/alloc-fns-alignment.c 
b/clang/test/CodeGen/alloc-fns-alignment.c
index 1ce0cfbad97b..b19cf867f74c 100644
--- a/clang/test/CodeGen/alloc-fns-alignment.c
+++ b/clang/test/CodeGen/alloc-fns-alignment.c
@@ -48,13 +48,14 @@ void *aligned_alloc_large_constant_test(size_t n) {
 // ALIGN16: align 16 i8* @realloc
 
 // CHECK-LABEL: @aligned_alloc_variable_test
-// ALIGN16: align 16 i8* @aligned_alloc
+// ALIGN16:  %[[ALLOCATED:.*]] = call align 16 i8* 
@aligned_alloc({{i32|i64}} %[[ALIGN:.*]], {{i32|i64}} %[[NBYTES:.*]])
+// ALIGN16-NEXT: call void @llvm.assume(i1 true) [ "align"(i8* %[[ALLOCATED]], 
{{i32|i64}} %[[ALIGN]]) ]
 
 // CHECK-LABEL: @aligned_alloc_constant_test
 // ALIGN16: align 16 i8* @aligned_alloc
 
 // CHECK-LABEL: @aligned_alloc_large_constant_test
-// ALIGN16: align 16 i8* @aligned_alloc
+// ALIGN16: align 4096 i8* @aligned_alloc
 
 // CHECK-LABEL: @malloc_test
 // ALIGN8: align 8 i8* @malloc
@@ -72,7 +73,7 @@ void *aligned_alloc_large_constant_test(size_t n) {
 // ALIGN8: align 8 i8* @aligned_alloc
 
 // CHECK-LABEL: @aligned_alloc_large_constant_test
-// ALIGN8: align 8 i8* @aligned_alloc
+// ALIGN8: align 4096 i8* @aligned_alloc
 
 // NOBUILTIN-MALLOC: declare i8* @malloc
 // NOBUILTIN-CALLOC: declare i8* @calloc



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


[PATCH] D109158: [clang][deps] Test diagnostic options are being respected

2021-09-10 Thread Mats Larsen via Phabricator via cfe-commits
supergrecko added a comment.

Hi, are these test cases supposed to be under /llvm in the monorepo? Right now 
they are at a new path, /llvm/clang/test/... which doesn't look right.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109158

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


[clang] 23f256f - [clang] Fix typo in test from a723310b4

2021-09-10 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2021-09-10T14:16:45-04:00
New Revision: 23f256f2b19843fa08f83dce43bab362e8ce2235

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

LOG: [clang] Fix typo in test from a723310b4

We want the driver-level flag here, else the test passes for the wrong reasons.
See comments on https://reviews.llvm.org/D99901.

Added: 


Modified: 
clang/test/Driver/nostdincxx.cpp

Removed: 




diff  --git a/clang/test/Driver/nostdincxx.cpp 
b/clang/test/Driver/nostdincxx.cpp
index 774874d80d82..dad40eaeddaf 100644
--- a/clang/test/Driver/nostdincxx.cpp
+++ b/clang/test/Driver/nostdincxx.cpp
@@ -1,7 +1,7 @@
 // RUN: not %clangxx -nostdinc %s 2>&1 | FileCheck %s
 // RUN: not %clangxx -nostdinc++ %s 2>&1 | FileCheck %s
 // RUN: not %clangxx -nostdlibinc %s 2>&1 | FileCheck %s
-// RUN: not %clangxx -triple x86_64-unknown-unknown-gnu -fsyntax-only 
-nostdinc -nostdinc++ %s 2>&1 | FileCheck /dev/null 
--implicit-check-not=-Wunused-command-line-argument
+// RUN: not %clangxx --target=x86_64-unknown-unknown-gnu -fsyntax-only 
-nostdinc -nostdinc++ %s 2>&1 | FileCheck /dev/null 
--implicit-check-not=-Wunused-command-line-argument
 // CHECK: file not found
 #include  
 



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


[PATCH] D99901: [Driver][test] Test intended target only

2021-09-10 Thread Nico Weber via Phabricator via cfe-commits
thakis added inline comments.



Comment at: clang/test/Driver/nostdincxx.cpp:4
 // RUN: not %clangxx -nostdlibinc %s 2>&1 | FileCheck %s
-// RUN: not %clangxx -fsyntax-only -nostdinc -nostdinc++ %s 2>&1 | FileCheck 
/dev/null --implicit-check-not=-Wunused-command-line-argument
+// RUN: not %clangxx -target unknown-unknown-gnu -fsyntax-only -nostdinc 
-nostdinc++ %s 2>&1 | FileCheck /dev/null 
--implicit-check-not=-Wunused-command-line-argument
 // CHECK: file not found

hubert.reinterpretcast wrote:
> jsji wrote:
> > MaskRay wrote:
> > > `error: unknown target triple 'unknown-unknown-hurd-gnu', please use 
> > > -triple or -arch`
> > > 
> > > Perhaps this should UNSUPPORTED aix if aix does not support -nostdinc++.
> > No, AIX does support `-nostdinc++`, we don't want to unsupport this whole 
> > test
> I believe the original fix was meant to be generally applicable but 
> unintentionally applied in only a limited fashion. Ideally, the test would 
> have been left as-is and the various toolchains changed similarly.
> 
> That is:
> ```
> $ clang -nostdinc -nostdinc++ -xc++ /dev/null -fsyntax-only
> clang-13: warning: argument unused during compilation: '-nostdinc++' 
> [-Wunused-command-line-argument]
> ```
> 
> should not happen. I guess a way forward is to first make the change for AIX 
> (and update the test to check on AIX) and then to commit a separate NFCI 
> commit to apply the test broadly to see if anyone finds the test to be 
> failing.
FYI: `%clangxx` is a driver invocation, not a cc1 invocation. The driver flag 
is `--target=`, not `-triple`.

This test, when run manually, produces:

```
bin/clang  -triple x86_64-unknown-unknown-gnu -fsyntax-only -nostdinc 
-nostdinc++ /Users/thakis/src/llvm-project/clang/test/Driver/nostdincxx.cpp
clang: error: unknown argument: '-triple'
clang: error: no such file or directory: 'x86_64-unknown-unknown-gnu'
```

That passes, but probably not for the reasons you want :) I fixed this in 
23f256f2b198.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99901

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


[PATCH] D106674: Runtime for Interop directive

2021-09-10 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added inline comments.



Comment at: openmp/libomptarget/src/interop.cpp:198-201
+  if (interop_type == kmp_interop_type_tasksync) {
+__kmpc_omp_wait_deps(loc_ref, gtid, ndeps, dep_list, ndeps_noalias,
+ noalias_dep_list);
+  }

RaviNarayanaswamy wrote:
> jdoerfert wrote:
> > RaviNarayanaswamy wrote:
> > > Interop object does not wait for any task from libomp.  
> > > Init just initializes the interop object.
> > > The initialization of interop object should  be done by the plugin as 
> > > only the plugin knows what properties are supported
> > > Interop object does not wait for any task from libomp. 
> > 
> > I don't know why you think we would not wait for libomp tasks. If we have 
> > dependences we need to wait for them.
> > 
> > > The initialization of interop object should be done by the plugin as only 
> > > the plugin knows what properties are supported.
> > 
> > It is, below. This is the generic part that then redirects to the plugin.
> Libomp would have not invoked the task which calls this routine if there are 
> dependences.   They must be executed before the task containing  the interop 
> creation is scheduled.
> 
> The interop_type should be passed to plugin and let it initialize the common 
> for all interop-types and then add based on the interop_type 
> Libomp would have not invoked the task which calls this routine if there are 
> dependences. They must be executed before the task containing the interop 
> creation is scheduled.

To me it seems you are assuming that we create a task in which this routine is 
called. We do not, as far as I can tell. See D105876.

> The interop_type should be passed to plugin and let it initialize the common 
> for all interop-types and then add based on the interop_type

So what you are trying to say is that `init_device_info` should take the 
`interop_type` too? That makes sense to me. But as discussed in other reviews 
recently, we should not extend the API for "future use cases" but extend it as 
use cases become relevant. For now it seems we can simply set up the 
`tgt_device_info` part of the `omp_interop_val_t` without knowing the 
`interop_type`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106674

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


[PATCH] D109621: [clang][Driver] Default to loading clang.cfg if config file not specified

2021-09-10 Thread Matthew Smith via Phabricator via cfe-commits
asymptotically created this revision.
asymptotically added reviewers: rsmith, sepavloff.
asymptotically added a project: clang.
asymptotically requested review of this revision.
Herald added a subscriber: cfe-commits.

If a configuration file is not supplied (either via the driver name or through 
the `--config` parameter), default to using `clang.cfg`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109621

Files:
  clang/docs/UsersManual.rst
  clang/lib/Driver/Driver.cpp


Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -908,7 +908,7 @@
 CfgFileName = ClangNameParts.TargetPrefix + '-' + 
ClangNameParts.ModeSuffix;
 
   if (CfgFileName.empty())
-return false;
+CfgFileName = "clang";
 
   // Determine architecture part of the file name, if it is present.
   StringRef CfgFileArch = CfgFileName;
Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -875,7 +875,8 @@
 Another way to specify a configuration file is to encode it in executable name.
 For example, if the Clang executable is named `armv7l-clang` (it may be a
 symbolic link to `clang`), then Clang will search for file `armv7l.cfg` in the
-directory where Clang resides.
+directories mentioned above. If the executable is named `clang`, the Clang will
+attempt to load the configuration file named `clang.cfg`.
 
 If a driver mode is specified in invocation, Clang tries to find a file 
specific
 for the specified mode. For example, if the executable file is named


Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -908,7 +908,7 @@
 CfgFileName = ClangNameParts.TargetPrefix + '-' + ClangNameParts.ModeSuffix;
 
   if (CfgFileName.empty())
-return false;
+CfgFileName = "clang";
 
   // Determine architecture part of the file name, if it is present.
   StringRef CfgFileArch = CfgFileName;
Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -875,7 +875,8 @@
 Another way to specify a configuration file is to encode it in executable name.
 For example, if the Clang executable is named `armv7l-clang` (it may be a
 symbolic link to `clang`), then Clang will search for file `armv7l.cfg` in the
-directory where Clang resides.
+directories mentioned above. If the executable is named `clang`, the Clang will
+attempt to load the configuration file named `clang.cfg`.
 
 If a driver mode is specified in invocation, Clang tries to find a file specific
 for the specified mode. For example, if the executable file is named
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] f28e710 - [OpenMP] Make CUDA math library functions SPMD amenable

2021-09-10 Thread Joseph Huber via cfe-commits

Author: Joseph Huber
Date: 2021-09-10T14:52:45-04:00
New Revision: f28e710db720a913f4b508a9dc43f25e81629e72

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

LOG: [OpenMP] Make CUDA math library functions SPMD amenable

This patch adds the SPMD amenable assumption to the CUDA math library
defintions in Clang. Previously these functions would block SPMD
execution on the device because they're intrinsic calls into the library
and can't be calculated. These functions don't have side-effects so they
are safe to execute in SPMD mode.

Depends on D105937

Reviewed By: jdoerfert

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

Added: 


Modified: 
clang/lib/Headers/__clang_cuda_libdevice_declares.h

Removed: 




diff  --git a/clang/lib/Headers/__clang_cuda_libdevice_declares.h 
b/clang/lib/Headers/__clang_cuda_libdevice_declares.h
index 6173b589e3eff..23f35964ea974 100644
--- a/clang/lib/Headers/__clang_cuda_libdevice_declares.h
+++ b/clang/lib/Headers/__clang_cuda_libdevice_declares.h
@@ -16,6 +16,7 @@ extern "C" {
 
 #if defined(__OPENMP_NVPTX__)
 #define __DEVICE__
+#pragma omp begin assumes ext_spmd_amenable no_openmp
 #elif defined(__CUDA__)
 #define __DEVICE__ __device__
 #endif
@@ -456,6 +457,11 @@ __DEVICE__ double __nv_y1(double __a);
 __DEVICE__ float __nv_y1f(float __a);
 __DEVICE__ float __nv_ynf(int __a, float __b);
 __DEVICE__ double __nv_yn(int __a, double __b);
+
+#if defined(__OPENMP_NVPTX__)
+#pragma omp end assumes ext_spmd_amenable no_openmp
+#endif
+
 #if defined(__cplusplus)
 } // extern "C"
 #endif



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


[PATCH] D108958: [OpenMP] Make CUDA math library functions SPMD amenable

2021-09-10 Thread Joseph Huber 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 rGf28e710db720: [OpenMP] Make CUDA math library functions SPMD 
amenable (authored by jhuber6).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108958

Files:
  clang/lib/Headers/__clang_cuda_libdevice_declares.h


Index: clang/lib/Headers/__clang_cuda_libdevice_declares.h
===
--- clang/lib/Headers/__clang_cuda_libdevice_declares.h
+++ clang/lib/Headers/__clang_cuda_libdevice_declares.h
@@ -16,6 +16,7 @@
 
 #if defined(__OPENMP_NVPTX__)
 #define __DEVICE__
+#pragma omp begin assumes ext_spmd_amenable no_openmp
 #elif defined(__CUDA__)
 #define __DEVICE__ __device__
 #endif
@@ -456,6 +457,11 @@
 __DEVICE__ float __nv_y1f(float __a);
 __DEVICE__ float __nv_ynf(int __a, float __b);
 __DEVICE__ double __nv_yn(int __a, double __b);
+
+#if defined(__OPENMP_NVPTX__)
+#pragma omp end assumes ext_spmd_amenable no_openmp
+#endif
+
 #if defined(__cplusplus)
 } // extern "C"
 #endif


Index: clang/lib/Headers/__clang_cuda_libdevice_declares.h
===
--- clang/lib/Headers/__clang_cuda_libdevice_declares.h
+++ clang/lib/Headers/__clang_cuda_libdevice_declares.h
@@ -16,6 +16,7 @@
 
 #if defined(__OPENMP_NVPTX__)
 #define __DEVICE__
+#pragma omp begin assumes ext_spmd_amenable no_openmp
 #elif defined(__CUDA__)
 #define __DEVICE__ __device__
 #endif
@@ -456,6 +457,11 @@
 __DEVICE__ float __nv_y1f(float __a);
 __DEVICE__ float __nv_ynf(int __a, float __b);
 __DEVICE__ double __nv_yn(int __a, double __b);
+
+#if defined(__OPENMP_NVPTX__)
+#pragma omp end assumes ext_spmd_amenable no_openmp
+#endif
+
 #if defined(__cplusplus)
 } // extern "C"
 #endif
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 285ec53 - [clang][deps] Move tests to the Clang subdirectory

2021-09-10 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2021-09-10T21:36:49+02:00
New Revision: 285ec53730ce6dfecd2a4288388e6ba4f2bd17e4

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

LOG: [clang][deps] Move tests to the Clang subdirectory

Added: 
clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template
clang/test/ClangScanDeps/Inputs/diagnostics/mod.h
clang/test/ClangScanDeps/Inputs/diagnostics/module.modulemap
clang/test/ClangScanDeps/Inputs/diagnostics/tu.c
clang/test/ClangScanDeps/diagnostics.c

Modified: 


Removed: 
llvm/clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template
llvm/clang/test/ClangScanDeps/Inputs/diagnostics/mod.h
llvm/clang/test/ClangScanDeps/Inputs/diagnostics/module.modulemap
llvm/clang/test/ClangScanDeps/Inputs/diagnostics/tu.c
llvm/clang/test/ClangScanDeps/diagnostics.c



diff  --git 
a/llvm/clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template 
b/clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template
similarity index 63%
rename from llvm/clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template
rename to clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template
index a33fabbb958c5..062e202328c86 100644
--- a/llvm/clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template
+++ b/clang/test/ClangScanDeps/Inputs/diagnostics/cdb.json.template
@@ -1,7 +1,7 @@
 [
   {
 "directory": "DIR",
-"command": "clang -c DIR/tu.c -fmodules -target 
i386-apple-ios14.0-simulator -o DIR/tu.o",
+"command": "clang -c DIR/tu.c -fmodules -target 
i386-apple-ios14.0-simulator -Wno-error=invalid-ios-deployment-target -o 
DIR/tu.o",
 "file": "DIR/tu.c"
   }
 ]

diff  --git a/llvm/clang/test/ClangScanDeps/Inputs/diagnostics/mod.h 
b/clang/test/ClangScanDeps/Inputs/diagnostics/mod.h
similarity index 100%
rename from llvm/clang/test/ClangScanDeps/Inputs/diagnostics/mod.h
rename to clang/test/ClangScanDeps/Inputs/diagnostics/mod.h

diff  --git a/llvm/clang/test/ClangScanDeps/Inputs/diagnostics/module.modulemap 
b/clang/test/ClangScanDeps/Inputs/diagnostics/module.modulemap
similarity index 100%
rename from llvm/clang/test/ClangScanDeps/Inputs/diagnostics/module.modulemap
rename to clang/test/ClangScanDeps/Inputs/diagnostics/module.modulemap

diff  --git a/llvm/clang/test/ClangScanDeps/Inputs/diagnostics/tu.c 
b/clang/test/ClangScanDeps/Inputs/diagnostics/tu.c
similarity index 100%
rename from llvm/clang/test/ClangScanDeps/Inputs/diagnostics/tu.c
rename to clang/test/ClangScanDeps/Inputs/diagnostics/tu.c

diff  --git a/llvm/clang/test/ClangScanDeps/diagnostics.c 
b/clang/test/ClangScanDeps/diagnostics.c
similarity index 90%
rename from llvm/clang/test/ClangScanDeps/diagnostics.c
rename to clang/test/ClangScanDeps/diagnostics.c
index e82bdccb88c4b..ce4eff79dc02b 100644
--- a/llvm/clang/test/ClangScanDeps/diagnostics.c
+++ b/clang/test/ClangScanDeps/diagnostics.c
@@ -6,8 +6,9 @@
 // RUN: clang-scan-deps -compilation-database %t/cdb.json -format 
experimental-full 2>&1 >> %t/result.json
 // RUN: cat %t/result.json | sed 's:\?:/:g' | FileCheck %s
 
-// Check that the scanner injects '-Wno-error' option and invalid command-line
-// arguments like '-target i386-apple-ios14.0-simulator' do not result in 
error.
+// Check that the '-Wno-error=invalid-ios-deployment-target' option is being
+// respected and invalid arguments like '-target i386-apple-ios14.0-simulator'
+// do not result in an error.
 
 // CHECK-NOT:  error:
 // CHECK:  -[[PREFIX:.*]]



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


[PATCH] D109158: [clang][deps] Test diagnostic options are being respected

2021-09-10 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 added a comment.

In D109158#2995095 , @supergrecko 
wrote:

> Hi, are these test cases supposed to be under /llvm in the monorepo? Right 
> now they are at a new path, /llvm/clang/test/... which doesn't look right.

You're right, thanks. Fixed in 285ec53730ce6dfecd2a4288388e6ba4f2bd17e4 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109158

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


[PATCH] D109625: [compiler-rt] Ensure LIT_TEST_DEP targets are actually built

2021-09-10 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan created this revision.
leonardchan added a reviewer: phosek.
Herald added subscribers: mgorny, dberris.
leonardchan requested review of this revision.
Herald added a project: Sanitizers.
Herald added a subscriber: Sanitizers.

When building compiler-rt via runtimes, many tests fail because tools like 
FileCheck and count aren't built yet. If it's also through a standalone build, 
then compiler-rt doesn't know of these targets. This copies logic from other 
parts of the monorepo and adds custom commands for building these external 
projects if we are in the case of a runtimes build.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109625

Files:
  compiler-rt/test/CMakeLists.txt


Index: compiler-rt/test/CMakeLists.txt
===
--- compiler-rt/test/CMakeLists.txt
+++ compiler-rt/test/CMakeLists.txt
@@ -1,5 +1,6 @@
 # Needed for lit support in standalone builds.
 include(AddLLVM)
+include(LLVMExternalProjectUtils)
 
 option(COMPILER_RT_TEST_STANDALONE_BUILD_LIBS
   "When set to ON and testing in a standalone build, test the runtime \
@@ -28,14 +29,29 @@
 # When ANDROID, we build tests with the host compiler (i.e. CMAKE_C_COMPILER),
 # and run tests with tools from the host toolchain.
 if(NOT ANDROID)
-  if(NOT COMPILER_RT_STANDALONE_BUILD AND NOT LLVM_RUNTIMES_BUILD)
-# Use LLVM utils and Clang from the same build tree.
-list(APPEND SANITIZER_COMMON_LIT_TEST_DEPS
+  set(LIT_TEST_DEPS
   clang clang-resource-headers FileCheck count not llvm-config llvm-nm 
llvm-objdump
   llvm-readelf llvm-readobj llvm-size llvm-symbolizer compiler-rt-headers 
sancov)
-if (WIN32)
-  list(APPEND SANITIZER_COMMON_LIT_TEST_DEPS KillTheDoctor)
-endif()
+  if (WIN32)
+list(APPEND LIT_TEST_DEPS KillTheDoctor)
+  endif()
+
+  if(NOT COMPILER_RT_STANDALONE_BUILD AND NOT LLVM_RUNTIMES_BUILD)
+# Use LLVM utils and Clang from the same build tree.
+list(APPEND SANITIZER_COMMON_LIT_TEST_DEPS ${LIT_TEST_DEPS})
+  elseif(COMPILER_RT_STANDALONE_BUILD)
+# If we are making a standalone build, we need to ensure some targets used
+# for testing are known and built as deps.
+list(APPEND SANITIZER_COMMON_LIT_TEST_DEPS ${LIT_TEST_DEPS})
+foreach(dep ${LIT_TEST_DEPS})
+  if (NOT TARGET ${dep})
+llvm_ExternalProject_BuildCmd(build_${dep} ${dep} ${BINARY_DIR})
+add_custom_target(${dep}
+  COMMAND ${build_${dep}}
+  WORKING_DIRECTORY ${BINARY_DIR}
+  VERBATIM USES_TERMINAL)
+  endif()
+endforeach()
   endif()
   # Tests use C++ standard library headers.
   if (TARGET cxx-headers OR HAVE_LIBCXX)


Index: compiler-rt/test/CMakeLists.txt
===
--- compiler-rt/test/CMakeLists.txt
+++ compiler-rt/test/CMakeLists.txt
@@ -1,5 +1,6 @@
 # Needed for lit support in standalone builds.
 include(AddLLVM)
+include(LLVMExternalProjectUtils)
 
 option(COMPILER_RT_TEST_STANDALONE_BUILD_LIBS
   "When set to ON and testing in a standalone build, test the runtime \
@@ -28,14 +29,29 @@
 # When ANDROID, we build tests with the host compiler (i.e. CMAKE_C_COMPILER),
 # and run tests with tools from the host toolchain.
 if(NOT ANDROID)
-  if(NOT COMPILER_RT_STANDALONE_BUILD AND NOT LLVM_RUNTIMES_BUILD)
-# Use LLVM utils and Clang from the same build tree.
-list(APPEND SANITIZER_COMMON_LIT_TEST_DEPS
+  set(LIT_TEST_DEPS
   clang clang-resource-headers FileCheck count not llvm-config llvm-nm llvm-objdump
   llvm-readelf llvm-readobj llvm-size llvm-symbolizer compiler-rt-headers sancov)
-if (WIN32)
-  list(APPEND SANITIZER_COMMON_LIT_TEST_DEPS KillTheDoctor)
-endif()
+  if (WIN32)
+list(APPEND LIT_TEST_DEPS KillTheDoctor)
+  endif()
+
+  if(NOT COMPILER_RT_STANDALONE_BUILD AND NOT LLVM_RUNTIMES_BUILD)
+# Use LLVM utils and Clang from the same build tree.
+list(APPEND SANITIZER_COMMON_LIT_TEST_DEPS ${LIT_TEST_DEPS})
+  elseif(COMPILER_RT_STANDALONE_BUILD)
+# If we are making a standalone build, we need to ensure some targets used
+# for testing are known and built as deps.
+list(APPEND SANITIZER_COMMON_LIT_TEST_DEPS ${LIT_TEST_DEPS})
+foreach(dep ${LIT_TEST_DEPS})
+  if (NOT TARGET ${dep})
+llvm_ExternalProject_BuildCmd(build_${dep} ${dep} ${BINARY_DIR})
+add_custom_target(${dep}
+  COMMAND ${build_${dep}}
+  WORKING_DIRECTORY ${BINARY_DIR}
+  VERBATIM USES_TERMINAL)
+  endif()
+endforeach()
   endif()
   # Tests use C++ standard library headers.
   if (TARGET cxx-headers OR HAVE_LIBCXX)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D109118: [AArch64][SVE][InstCombine] Canonicalize aarch64_sve_dup_x intrinsic to IR splat operation

2021-09-10 Thread Usman Nadeem 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 rG98c37247d81d: [AArch64][SVE][InstCombine] Canonicalize 
aarch64_sve_dup_x intrinsic to IR… (authored by mnadeem).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109118

Files:
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_abd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_acge.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_acgt.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_acle.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_aclt.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_add.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_and.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_asr.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_bfdot.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_bfmlalb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_bfmlalt.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_bic.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cmpeq.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cmpge.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cmpgt.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cmple.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cmplt.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cmpne.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_cmpuo.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_div.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_divr.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_dot.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_dup-bfloat.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_dup.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_dupq.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_eor.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_lsl.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_lsr.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mad.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_max.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_maxnm.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_min.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_minnm.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mla.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mls.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_msb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mul.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mulh.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mulx.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_nmad.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_nmla.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_nmls.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_nmsb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_orr.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qadd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qsub.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_scale.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_sub.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_subr.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_sudot.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_usdot.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_aba.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_abalb.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_abalt.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_abdlb.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_abdlt.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_adclb.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_adclt.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_addhnb.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_addhnt.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_addlb.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_addlbt.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_addlt.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_addwb.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_addwt.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_bcax.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_bdep.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_bext.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_bgrp.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_bsl.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_bsl1n.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_bsl2n.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_eor3.c
  clang/test/CodeGen/aarch64-sve2-intrinsics/acle_sve2_eorbt.c
  clang/t

[PATCH] D109609: [C++4OpenCL] Add support for multiple address spaced destructors

2021-09-10 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

> The feature is also C++ for OpenCL specific to let the fast path remain when 
> not utilizing the
> address spaces, as this new implementation will be slower than the bitfields 
> that C++ currently
> uses, but I hope this can also be optimized in the future if it turns out to 
> be very slow.

In general we try to align OpenCL's address spaces with C/C++ general direction 
but we haven't completed support of address space methods qualifiers in C++ 
yet. Therefore supporting dtors with address spaces won't be possible in 
generic C++. However, it would be good to check that we don't entirely misalign 
with the C++ requirements.

I would like to see if @rjmccall  has any suggestions at this point.




Comment at: clang/include/clang/AST/DeclCXX.h:983
+  bool needsImplicitDestructor(LangAS AS = LangAS::Default) const {
+if (getASTContext().getLangOpts().OpenCL) {
+  return getDestructor(AS) == nullptr;

According to the current OpenCL strategy, we only declare implicit members in 
default address space (i.e. `__generic`). It might be that we can declare them 
for all concrete address spaces but we are not there yet to start adding this 
feature. So it would make sense, for now, to simplify this logic and only add 
implicit dtors in the generic address space. 

This implies that objects in concrete address spaces would still be able to use 
such implicit dtors but the compiler would add an implicit conversion to 
`__generic` for the implicit object parameter.



Comment at: clang/include/clang/Sema/Sema.h:4048
+  bool VolatileArg, bool RValueThis, bool ConstThis,
+  bool VolatileThis, LangAS AS = LangAS::Default);
 

it feels to me that this should be named  `ASThis` following the convention? 




Comment at: clang/lib/AST/DeclCXX.cpp:1901
+
+  for (DeclContext::lookup_result::iterator I = R.begin(), E = R.end(); I != E;
+   ++I) {

For ctors and other special members the logic for the selection of the overload 
candidates seems to be implemented at the end of `Sema::LookupSpecialMember`:
https://clang.llvm.org/doxygen/SemaLookup_8cpp_source.html#l03114

There it creates an implicit parameter `this` and performs regular overload 
resolution.

Currently dtors don't hit that point because the implementation fast paths them 
in that function. 

Do you think it makes sense to follow the same logic for dtors (by preventing 
the early exit there), even though perhaps we would then only do it for OpenCL 
to avoid performance regressions for pure C++ implementation? However, I am not 
entirely convinced when and how that code is called for the special members 
since it doesn't have address space handling anywhere but clang's behavior 
seems correct for ctors and assignments at least. Although it is possible that 
it is only used for some corner cases we haven't encountered yet and hence we 
have a general bug for special members with address spaces in some situations.

Alternatively, we could just add similar logic here if it makes implementation 
more efficient. After all the special member implementation doesn't seem to 
reuse fully common member function overload resolution code so perhaps it is 
not unreasonable to add a special case for dtors. I am not saying though we 
need to do it in this path... but it would be good to understand how the 
evolution of your approach would look like towards completion.



Comment at: clang/lib/Sema/SemaLookup.cpp:3082
   ID.AddInteger(VolatileThis);
+  ID.AddInteger((unsigned)AS);
 

Btw ctors and assignments don't seem to need this but they seem to work fine 
though... 


For example here the right assignment overload with `__local` address space is 
selected
https://godbolt.org/z/aYKj4W6rc
or ctor overload with `__global` is selected here correctly:
https://godbolt.org/z/1frheezE5

So it seems like there is some other logic to handle address spaces for special 
members elsewhere? Although it is very strange and rather confusing.



Comment at: clang/lib/Sema/SemaLookup.cpp:3099
+  runWithSufficientStackSpace(RD->getLocation(),
+  [&] { DeclareImplicitDestructor(RD, AS); });
 }

Currently, all other special members added implicitly use default address space 
(i.e. `__generic` for OpenCL) for `this` via 
`Sema::setupImplicitSpecialMemberType` helper so I think we should mirror it 
for `DeclareImplicitDestructor` too... then perhaps we can avoid changes in 
`Sema::setupImplicitSpecialMemberType`?

FYI in the past we have discussed that we might want to change the design and 
put special members in concrete address spaces but we haven't gone that far yet 
and it would make sense to have all special members working coherently... so it 
would be better for dtors to just mirror logic from the other specia

[PATCH] D109506: [RFC] Print current request context along with the stack trance in clangd

2021-09-10 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

Well, thanks for such a well-thought-out patch :-) I have to admit my first 
reaction was terror, but this seems solid to me.




Comment at: clang-tools-extra/clangd/TUScheduler.cpp:1381
+  auto &OS = llvm::errs();
+  OS << "Signalled during AST action:\n";
+  auto &Command = FileInputs.CompileCommand;

0x1eaf wrote:
> sammccall wrote:
> > the name of the action is available as CurrentRequest->Action, which I 
> > think is safe to either pass into this function or read directly here.
> I've noticed the the action name is always hardcoded as “Build AST 
> ({version})” and just logged the version directly below, but I guess it's not 
> forward compatible, so I'm going to log both…
> the action name is always hardcoded as “Build AST ({version})”

This shouldn't *always* be the case, there should be entries like "Hover" etc 
too, corresponding to `WorkScheduler->runWithAST("Hover", ...)` in 
ClangdServer.cpp.

However the "build AST" actions are the ones that run the clang parser, so 
they're the slowest and crashiest for sure!



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:1392
+  OS << "Contents:\n";
+  OS << FileInputs.Contents << "\n";
+}

0x1eaf wrote:
> sammccall wrote:
> > sammccall wrote:
> > > hmm, this is potentially really useful (could gather full reproducers) 
> > > but also is going to dominate the output and make it annoying to see the 
> > > stack traces/other details. I'm worried this may make this feature 
> > > net-negative for a majority of users, who won't find the right parts of 
> > > the output to report...
> > > 
> > > How critical do you think this is for debugging crashes in practice? (I 
> > > suspect fairly important!)
> > > Since we're taking liberties with async-signal-safety anyway, it might be 
> > > possible to get this sent to a tempfile, which might be more useful. In 
> > > any case, we might want full file dumps to be off by default outside of 
> > > environments where anyone is likely to actually try to get the 
> > > reproducers.
> > > 
> > > I'd probably suggest leaving this out of the initial patch entirely so we 
> > > can focus on getting the rest of the mechanism right.
> > another thought along the lines of reproducers (but nothing for this 
> > patch)...
> > 
> > If we're working on a file and have a preamble, then the headers that make 
> > up the preamble are relevant. In practice it's hard to reproduce bug 
> > reports we get because we need all their headers. If we're using a preamble 
> > then just dumping all the filenames it includes would make it possible for 
> > some tool to take the crash report and zip up a reproducer.
> > 
> > (This probably needs the ability to run all of the handlers for the current 
> > thread, not just the top of the stack, since we acquire the relevant 
> > preamble later)
> > How critical do you think this is for debugging crashes in practice?
> 
> For us it would likely be of utmost importance as our VSCode extension routes 
> requests to [Glean](https://glean.software) until local clangd finishes the 
> compilation, so clangd ends up mostly being used for modified files, and the 
> crashes might be unreproducible on the original source…
> 
> > I'd probably suggest leaving this out of the initial patch entirely so we 
> > can focus on getting the rest of the mechanism right.
> 
> Alright, will remove the file contents with the next update.
> 
> > In any case, we might want full file dumps to be off by default outside of 
> > environments where anyone is likely to actually try to get the reproducers.
> 
> What would be the best way to re-add it in a subsequent revision: make it 
> configurable via a command line option, or via an environment variable? And 
> if it's just an env var, maybe we could include it conditionally in this 
> revision?
> 
> > If we're using a preamble then just dumping all the filenames it includes 
> > would make it possible for some tool to take the crash report and zip up a 
> > reproducer.
> 
> We had discussions within the team about potentially implementing a similar 
> tool, but the rough idea was to rely on VCS to collect the changes as the 
> delta would normally be smaller than bundling all the headers that the TU 
> includes. But if the VCS-agnostic approach would be simpler and more portable 
> — I'm all for it :)
> What would be the best way to re-add it in a subsequent revision: make it 
> configurable via a command line option, or via an environment variable? And 
> if it's just an env var, maybe we could include it conditionally in this 
> revision?

Yeah an env var seems tempting to me. I can't put my finger on *why* it feels 
like an appropriate way to configure this vs a flag, but at least not having to 
plumb it around is nice.
I'd be happy with `if (getenv("CLANGD_CRASH_DUMP_SOURCE"))` or something like 
that in this patch.

> the rough idea was to rely on VCS to collect the changes


[PATCH] D109621: [clang][Driver] Default to loading clang.cfg if config file not specified

2021-09-10 Thread Arfrever Frehtes Taifersar Arahesis via Phabricator via cfe-commits
Arfrever added inline comments.



Comment at: clang/docs/UsersManual.rst:877
 For example, if the Clang executable is named `armv7l-clang` (it may be a
 symbolic link to `clang`), then Clang will search for file `armv7l.cfg` in the
+directories mentioned above. If the executable is named `clang`, the Clang will

This says `armv7l.cfg`...



Comment at: clang/lib/Driver/Driver.cpp:906
   // from executable name. For instance, an executable 'armv7l-clang' will
   // search for config file 'armv7l-clang.cfg'.
   if (CfgFileName.empty() && !ClangNameParts.TargetPrefix.empty())

But this says `armv7l-clang.cfg`.
Could you also fix this inconsistency?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109621

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


[PATCH] D106674: Runtime for Interop directive

2021-09-10 Thread Ravi Narayanaswamy via Phabricator via cfe-commits
RaviNarayanaswamy added inline comments.



Comment at: openmp/libomptarget/src/interop.cpp:198-201
+  if (interop_type == kmp_interop_type_tasksync) {
+__kmpc_omp_wait_deps(loc_ref, gtid, ndeps, dep_list, ndeps_noalias,
+ noalias_dep_list);
+  }

jdoerfert wrote:
> RaviNarayanaswamy wrote:
> > jdoerfert wrote:
> > > RaviNarayanaswamy wrote:
> > > > Interop object does not wait for any task from libomp.  
> > > > Init just initializes the interop object.
> > > > The initialization of interop object should  be done by the plugin as 
> > > > only the plugin knows what properties are supported
> > > > Interop object does not wait for any task from libomp. 
> > > 
> > > I don't know why you think we would not wait for libomp tasks. If we have 
> > > dependences we need to wait for them.
> > > 
> > > > The initialization of interop object should be done by the plugin as 
> > > > only the plugin knows what properties are supported.
> > > 
> > > It is, below. This is the generic part that then redirects to the plugin.
> > Libomp would have not invoked the task which calls this routine if there 
> > are dependences.   They must be executed before the task containing  the 
> > interop creation is scheduled.
> > 
> > The interop_type should be passed to plugin and let it initialize the 
> > common for all interop-types and then add based on the interop_type 
> > Libomp would have not invoked the task which calls this routine if there 
> > are dependences. They must be executed before the task containing the 
> > interop creation is scheduled.
> 
> To me it seems you are assuming that we create a task in which this routine 
> is called. We do not, as far as I can tell. See D105876.
> 
> > The interop_type should be passed to plugin and let it initialize the 
> > common for all interop-types and then add based on the interop_type
> 
> So what you are trying to say is that `init_device_info` should take the 
> `interop_type` too? That makes sense to me. But as discussed in other reviews 
> recently, we should not extend the API for "future use cases" but extend it 
> as use cases become relevant. For now it seems we can simply set up the 
> `tgt_device_info` part of the `omp_interop_val_t` without knowing the 
> `interop_type`.
Then need to change this code since the interop_type  can be both target_sync 
and  target which will not be handled correctly.  target_sync and target have 
common initialization + additional  property base don the interop_type requested


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106674

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


[PATCH] D108243: Revert "Avoid needlessly copying a block to the heap when a block literal"

2021-09-10 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak added a comment.

Do you need `arc-blocks-avoid-heapify.m`? It seems like the other tests already 
cover all the cases we care about.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108243

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


[PATCH] D109632: [clang] de-duplicate methods from AST files

2021-09-10 Thread Richard Howell via Phabricator via cfe-commits
rmaz created this revision.
rmaz requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This diff will de-duplicate methods read from AST files before
inserting them in to a global method pool list. When reading
ObjCMethodDecl from AST files we can end up with a significant
amount of duplication when modules contain redeclarations of
system framework methods. For instance a common pattern is to
redeclare `-(instancetype)init` with `NS_UNAVAILABLE`, which
results in the entire ObjCMethodList for `init` being serialized
in each module with this redeclaration.

Measuring this against our codebase for files that use `-fmodules`
shows an overall 19% compile time improvement, and in some cases
as much as 79% for files with a lot of modular dependencies.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D109632

Files:
  clang/lib/Serialization/ASTReader.cpp


Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -8181,8 +8181,18 @@
 /// Add the given set of methods to the method list.
 static void addMethodsToPool(Sema &S, ArrayRef Methods,
  ObjCMethodList &List) {
-  for (unsigned I = 0, N = Methods.size(); I != N; ++I) {
-S.addMethodToGlobalList(&List, Methods[I]);
+  // Methods from visited modules can contain a lot of duplicates
+  // when redeclaring methods from system frameworks, for example
+  // when marking -(instancetype)init as NS_UNAVAILABLE.
+  llvm::DenseSet seen;
+  for (auto *L = &List; L; L = L->getNext()) {
+seen.insert(L->getMethod());
+  }
+
+  for (auto *M : Methods) {
+if (seen.insert(M).second) {
+  S.addMethodToGlobalList(&List, M);
+}
   }
 }
 


Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -8181,8 +8181,18 @@
 /// Add the given set of methods to the method list.
 static void addMethodsToPool(Sema &S, ArrayRef Methods,
  ObjCMethodList &List) {
-  for (unsigned I = 0, N = Methods.size(); I != N; ++I) {
-S.addMethodToGlobalList(&List, Methods[I]);
+  // Methods from visited modules can contain a lot of duplicates
+  // when redeclaring methods from system frameworks, for example
+  // when marking -(instancetype)init as NS_UNAVAILABLE.
+  llvm::DenseSet seen;
+  for (auto *L = &List; L; L = L->getNext()) {
+seen.insert(L->getMethod());
+  }
+
+  for (auto *M : Methods) {
+if (seen.insert(M).second) {
+  S.addMethodToGlobalList(&List, M);
+}
   }
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D106674: Runtime for Interop directive

2021-09-10 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added inline comments.



Comment at: openmp/libomptarget/src/interop.cpp:198-201
+  if (interop_type == kmp_interop_type_tasksync) {
+__kmpc_omp_wait_deps(loc_ref, gtid, ndeps, dep_list, ndeps_noalias,
+ noalias_dep_list);
+  }

RaviNarayanaswamy wrote:
> jdoerfert wrote:
> > RaviNarayanaswamy wrote:
> > > jdoerfert wrote:
> > > > RaviNarayanaswamy wrote:
> > > > > Interop object does not wait for any task from libomp.  
> > > > > Init just initializes the interop object.
> > > > > The initialization of interop object should  be done by the plugin as 
> > > > > only the plugin knows what properties are supported
> > > > > Interop object does not wait for any task from libomp. 
> > > > 
> > > > I don't know why you think we would not wait for libomp tasks. If we 
> > > > have dependences we need to wait for them.
> > > > 
> > > > > The initialization of interop object should be done by the plugin as 
> > > > > only the plugin knows what properties are supported.
> > > > 
> > > > It is, below. This is the generic part that then redirects to the 
> > > > plugin.
> > > Libomp would have not invoked the task which calls this routine if there 
> > > are dependences.   They must be executed before the task containing  the 
> > > interop creation is scheduled.
> > > 
> > > The interop_type should be passed to plugin and let it initialize the 
> > > common for all interop-types and then add based on the interop_type 
> > > Libomp would have not invoked the task which calls this routine if there 
> > > are dependences. They must be executed before the task containing the 
> > > interop creation is scheduled.
> > 
> > To me it seems you are assuming that we create a task in which this routine 
> > is called. We do not, as far as I can tell. See D105876.
> > 
> > > The interop_type should be passed to plugin and let it initialize the 
> > > common for all interop-types and then add based on the interop_type
> > 
> > So what you are trying to say is that `init_device_info` should take the 
> > `interop_type` too? That makes sense to me. But as discussed in other 
> > reviews recently, we should not extend the API for "future use cases" but 
> > extend it as use cases become relevant. For now it seems we can simply set 
> > up the `tgt_device_info` part of the `omp_interop_val_t` without knowing 
> > the `interop_type`.
> Then need to change this code since the interop_type  can be both target_sync 
> and  target which will not be handled correctly.  target_sync and target have 
> common initialization + additional  property base don the interop_type 
> requested
> Then need to change this code since the interop_type can be both target_sync 
> and target which will not be handled correctly. target_sync and target have 
> common initialization + additional property base don the interop_type 
> requested

Could you please elaborate what needs to be changed exactly. What information 
is currently not available in the setup as is? What properties would be 
different?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106674

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


[PATCH] D109544: [OpenMP] Add flag for setting debug in the offloading device

2021-09-10 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D109544

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


[PATCH] D108243: Revert "Avoid needlessly copying a block to the heap when a block literal"

2021-09-10 Thread Walter Lee via Phabricator via cfe-commits
waltl updated this revision to Diff 372017.
waltl added a comment.

Delete redundant tests in arc-blocks-avoid-heapify.m.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108243

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGObjC.cpp
  clang/test/CodeGenObjC/arc-block-copy-escape.m
  clang/test/CodeGenObjC/arc-blocks-avoid-heapify.m
  clang/test/CodeGenObjC/arc-blocks.m
  clang/test/CodeGenObjCXX/arc-blocks.mm
  clang/test/PCH/arc-blocks.mm

Index: clang/test/PCH/arc-blocks.mm
===
--- clang/test/PCH/arc-blocks.mm
+++ clang/test/PCH/arc-blocks.mm
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fobjc-arc -fblocks -std=c++1y -emit-pch %s -o %t
-// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fobjc-arc -fblocks -std=c++1y -include-pch %t -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fobjc-arc -fblocks -std=c++1y -include-pch %t -fobjc-avoid-heapify-local-blocks -emit-llvm -o - %s | FileCheck %s
 
 #ifndef HEADER_INCLUDED
 #define HEADER_INCLUDED
Index: clang/test/CodeGenObjCXX/arc-blocks.mm
===
--- clang/test/CodeGenObjCXX/arc-blocks.mm
+++ clang/test/CodeGenObjCXX/arc-blocks.mm
@@ -1,9 +1,11 @@
 // RUN: %clang_cc1 -std=gnu++98 -triple x86_64-apple-darwin10 -emit-llvm -fobjc-runtime-has-weak -fblocks -fobjc-arc -fexceptions -fobjc-arc-exceptions -o - %s | FileCheck -check-prefix CHECK %s
 // RUN: %clang_cc1 -std=gnu++98 -triple x86_64-apple-darwin10 -emit-llvm -fobjc-runtime-has-weak -fblocks -fobjc-arc -fexceptions -fobjc-arc-exceptions -O1 -o - %s | FileCheck -check-prefix CHECK-O1 %s
 // RUN: %clang_cc1 -std=gnu++98 -triple x86_64-apple-darwin10 -emit-llvm -fobjc-runtime-has-weak -fblocks -fobjc-arc -o - %s | FileCheck -check-prefix CHECK-NOEXCP %s
+// RUN: %clang_cc1 -std=gnu++98 -triple x86_64-apple-darwin10 -emit-llvm -fobjc-runtime-has-weak -fblocks -fobjc-arc -fexceptions -fobjc-arc-exceptions -fobjc-avoid-heapify-local-blocks -o - %s | FileCheck -check-prefix CHECK-NOHEAP %s
 
 // CHECK: [[A:.*]] = type { i64, [10 x i8*] }
 // CHECK: %[[STRUCT_BLOCK_DESCRIPTOR:.*]] = type { i64, i64 }
+// CHECK-NOHEAP: %[[STRUCT_BLOCK_DESCRIPTOR:.*]] = type { i64, i64 }
 // CHECK: %[[STRUCT_TEST1_S0:.*]] = type { i32 }
 // CHECK: %[[STRUCT_TRIVIAL_INTERNAL:.*]] = type { i32 }
 
@@ -209,8 +211,8 @@
 
 namespace test_block_retain {
 
-// CHECK-LABEL: define{{.*}} void @_ZN17test_block_retain14initializationEP11objc_object(
-// CHECK-NOT: @llvm.objc.retainBlock(
+// CHECK-NOHEAP-LABEL: define{{.*}} void @_ZN17test_block_retain14initializationEP11objc_object(
+// CHECK-NOHEAP-NOT: @llvm.objc.retainBlock(
   void initialization(id a) {
 BlockTy b0 = ^{ foo1(a); };
 BlockTy b1 = (^{ foo1(a); });
@@ -218,23 +220,23 @@
 b1();
   }
 
-// CHECK-LABEL: define{{.*}} void @_ZN17test_block_retain20initializationStaticEP11objc_object(
-// CHECK: @llvm.objc.retainBlock(
+// CHECK-NOHEAP-LABEL: define{{.*}} void @_ZN17test_block_retain20initializationStaticEP11objc_object(
+// CHECK-NOHEAP: @llvm.objc.retainBlock(
   void initializationStatic(id a) {
 static BlockTy b0 = ^{ foo1(a); };
 b0();
   }
 
-// CHECK-LABEL: define{{.*}} void @_ZN17test_block_retain15initialization2EP11objc_object
-// CHECK: %[[B0:.*]] = alloca void ()*, align 8
-// CHECK: %[[B1:.*]] = alloca void ()*, align 8
-// CHECK: load void ()*, void ()** %[[B0]], align 8
-// CHECK-NOT: @llvm.objc.retainBlock
-// CHECK: %[[V9:.*]] = load void ()*, void ()** %[[B0]], align 8
-// CHECK: %[[V10:.*]] = bitcast void ()* %[[V9]] to i8*
-// CHECK: %[[V11:.*]] = call i8* @llvm.objc.retainBlock(i8* %[[V10]])
-// CHECK: %[[V12:.*]] = bitcast i8* %[[V11]] to void ()*
-// CHECK: store void ()* %[[V12]], void ()** %[[B1]], align 8
+// CHECK-NOHEAP-LABEL: define{{.*}} void @_ZN17test_block_retain15initialization2EP11objc_object
+// CHECK-NOHEAP: %[[B0:.*]] = alloca void ()*, align 8
+// CHECK-NOHEAP: %[[B1:.*]] = alloca void ()*, align 8
+// CHECK-NOHEAP: load void ()*, void ()** %[[B0]], align 8
+// CHECK-NOHEAP-NOT: @llvm.objc.retainBlock
+// CHECK-NOHEAP: %[[V9:.*]] = load void ()*, void ()** %[[B0]], align 8
+// CHECK-NOHEAP: %[[V10:.*]] = bitcast void ()* %[[V9]] to i8*
+// CHECK-NOHEAP: %[[V11:.*]] = call i8* @llvm.objc.retainBlock(i8* %[[V10]])
+// CHECK-NOHEAP: %[[V12:.*]] = bitcast i8* %[[V11]] to void ()*
+// CHECK-NOHEAP: store void ()* %[[V12]], void ()** %[[B1]], align 8
   void initialization2(id a) {
 BlockTy b0 = ^{ foo1(a); };
 b0();
@@ -242,8 +244,8 @@
 b1();
   }
 
-// CHECK-LABEL: define{{.*}} void @_ZN17test_block_retain10assignmentEP11objc_object(
-// CHECK-NOT: @llvm.objc.retainBlock(
+// CHECK-NOHEAP-LABEL: define{{.*}} void @_ZN17test_block_retain10assignmentEP11objc_object(
+// CHECK-NOHEAP

[PATCH] D108243: Revert "Avoid needlessly copying a block to the heap when a block literal"

2021-09-10 Thread Walter Lee via Phabricator via cfe-commits
waltl added a comment.

In D108243#2995476 , @ahatanak wrote:

> Do you need `arc-blocks-avoid-heapify.m`? It seems like the other tests 
> already cover all the cases we care about.

You're right much of it is redundant, but test10a() and test10b() are still 
meaningful.  I've deleted the redundant tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108243

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


  1   2   >