[PATCH] D103313: [RISCV][Clang] Implement support for zmmul-experimental

[JiahaoChen_Conor via Phabricator via cfe-commits]

JiahaoChenConor added a comment.
Herald added subscribers: pcwang-thead, eopXD, VincentWu, luke957, 
achieveartificialintelligence.
Herald added a project: All.

Hi, do you still continue working on this patch?


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

https://reviews.llvm.org/D103313

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

[PATCH] D119144: [tests][Driver] Pass an empty sysroot for `DEFAULT_SYSROOT` builds

[Carlo Cabrera via Phabricator via cfe-commits]

carlocab added a comment.
Herald added a project: All.

Per suggestion on Discord, here’s my git author line:

Carlo Cabrera 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119144

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

[clang] 4f637c3 - [tests][Driver] Pass an empty sysroot for `DEFAULT_SYSROOT` builds

[Tim Northover via cfe-commits]

Author: Tim Northover
Date: 2022-03-04T09:01:50Z
New Revision: 4f637c30e1cd2d1d85f4f3b2ab042bfd75ae2865

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

LOG: [tests][Driver] Pass an empty sysroot for `DEFAULT_SYSROOT` builds

The baremetal-sysroot test fails when the toolchain is configured with
DEFAULT_SYSROOT. So, to emulate not having passed one at all, let's
pass an empty sysroot instead.

https://reviews.llvm.org/D119144

Patch by Carlo Cabrera 

Added: 


Modified: 
clang/test/Driver/baremetal-sysroot.cpp

Removed: 




diff  --git a/clang/test/Driver/baremetal-sysroot.cpp 
b/clang/test/Driver/baremetal-sysroot.cpp
index ae174e01417e7..fc66020772a77 100644
--- a/clang/test/Driver/baremetal-sysroot.cpp
+++ b/clang/test/Driver/baremetal-sysroot.cpp
@@ -10,7 +10,7 @@
 // RUN: ln -s %clang %T/baremetal_default_sysroot/bin/clang
 
 // RUN: %T/baremetal_default_sysroot/bin/clang -no-canonical-prefixes %s -### 
-o %t.o 2>&1 \
-// RUN: -target armv6m-none-eabi \
+// RUN: -target armv6m-none-eabi --sysroot= \
 // RUN:   | FileCheck --check-prefix=CHECK-V6M-C %s
 // CHECK-V6M-C: "{{.*}}clang{{.*}}" "-cc1" "-triple" 
"thumbv6m-none-unknown-eabi"
 // CHECK-V6M-C-SAME: "-internal-isystem" 
"{{.*}}/baremetal_default_sysroot{{[/\\]+}}bin{{[/\\]+}}..{{[/\\]+}}lib{{[/\\]+}}clang-runtimes{{[/\\]+}}armv6m-none-eabi{{[/\\]+}}include{{[/\\]+}}c++{{[/\\]+}}v1"



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

[PATCH] D120540: [Driver] Enable to use C++20 modules standalone by -fcxx-modules

[Iain Sandoe via Phabricator via cfe-commits]

iains added a comment.

1. I agree 100% that the driver needs to be able to process in "c++20 modules 
mode"; there is some handling of sources that should be changed accordingly.

2. I believe that it is a general objective of the tooling folks (roughly SG15 
participants) that C++20 modules should (eventually) be considered automatic 
for C++20+

3. There is at least one request from tooling folks that there should be an 
option to disable modules (even when in C++20  mode); this is a practical 
measure to avoid the case that it is impossible to build a TU because of some 
potential modules-related bug ...

4. IMO it becomes increasingly important to try and decouple the clang modules 
from C++20 modules as much as possible.

So .. I was going to suggest that we might introduce -fmodules= {none, clang, 
c++20, ...} 
with defaults picked:

   fmodules => clang (i.e. the current meaning)
  
  !fmodules && C++20+ => c++20 (i.e. the objective of (2) above
  Where there are other flags that imply C++20 that can switch c++20 mode as 
well
  
  otherwise the default would be "none"

.. this provides for (3) ... since -std=c++20 -fmodules=none could be used.

I do not have a patch for this proposal as of this time (my current patches 
assume (2) but do not meet the objective of (3))


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120540

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

[PATCH] D120902: [clang-format] Fix assertion failure/crash with `AllowShortFunctionsOnASingleLine: Inline/InlineOnly`.

[Owen Pan via Phabricator via cfe-commits]

owenpan added inline comments.



Comment at: clang/lib/Format/UnwrappedLineFormatter.cpp:313
   break;
+  if ((*J)->Level == TheLine->Level)
+return false;

curdeius wrote:
> owenpan wrote:
> > To be safe?
> Good idea. Will do.
> Any idea how to provoke this (if at all possible)?
I can't think of a valid C++ example that would trigger this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120902

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

[PATCH] D120540: [Driver] Enable to use C++20 modules standalone by -fcxx-modules

[Iain Sandoe via Phabricator via cfe-commits]

iains added a comment.

of course, this meets your objective too - since you could put -fmodules=cxx20 
(even without -std=c++20) ..


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120540

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

[PATCH] D118869: [clang-format] Non-latin comment prefix whitespace

[Krasimir Georgiev via Phabricator via cfe-commits]

krasimir added a comment.
Herald added a project: All.

It appears that this caused a regression by adding an additional space of 
indentation to line comments in some cases:

  % cat test.cc  # (before)
  // Comment
  int i;
  % clang-format -style=google test.cc
  //  Comment
  int i;

@ksyx could you please take a look?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118869

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

[PATCH] D120540: [Driver] Enable to use C++20 modules standalone by -fcxx-modules

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added a comment.

In D120540#3359394 , @iains wrote:

> 1. I agree 100% that the driver needs to be able to process in "c++20 modules 
> mode";

Yeah, not all the projects could be able to run in c++20 mode. We use 
`-std=c++17` + `-fcoroutines-ts` for C++20 coroutine before.

> there is some handling of sources that should be changed accordingly.

If I don't misunderstand, I guess we don't. Since all the code about C++20 
modules are controlled by `CPlusPlusModules` variable. I think there wouldn't 
be codes controlled by `Cpp20` variables.

> 2. I believe that it is a general objective of the tooling folks (roughly 
> SG15 participants) that C++20 modules should (eventually) be considered 
> automatic for C++20+

If I understand correctly, clang would enable C++20 modules by default if C++20 
is enabled.

> 3. There is at least one request from tooling folks that there should be an 
> option to disable modules (even when in C++20  mode); this is a practical 
> measure to avoid the case that it is impossible to build a TU because of some 
> potential modules-related bug ...

I think `-fno-cxxmodules` could be the option now.

> 4. IMO it becomes increasingly important to try and decouple the clang 
> modules from C++20 modules as much as possible.

100% agree. I think it should be beneficial to decouple them from command line, 
implementation and comments. (Now many comments are not precise. For example, 
when we talk about a `Module`. we are referring a module unit indeed. There are 
other examples.)

> So .. I was going to suggest that we might introduce -fmodules= {none, clang, 
> c++20, ...} 
> with defaults picked:
>
>fmodules => clang (i.e. the current meaning)
>   
>   !fmodules && C++20+ => c++20 (i.e. the objective of (2) above
>   Where there are other flags that imply C++20 that can switch c++20 mode as 
> well
>   
>   otherwise the default would be "none"
>
> .. this provides for (3) ... since -std=c++20 -fmodules=none could be used.
>
> I do not have a patch for this proposal as of this time (my current patches 
> assume (2) but do not meet the objective of (3))

The proposal is good to me though. I sent a patch 
(https://reviews.llvm.org/D113391) before to forbid the mixed use of clang 
modules and c++20 modules since it might be confusing if we use the combination 
`-fmodules -std=c++20`. But the comment shows that the current users of Clang 
Modules (mainly Google and Apple) wish a smooth switch from clang module to 
c++20 module. So I think the proposal which would break the current use cases 
would be not easy to land. 
(This patch wouldn't break any use case I think).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120540

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

[PATCH] D120540: [Driver] Enable to use C++20 modules standalone by -fcxx-modules

[Iain Sandoe via Phabricator via cfe-commits]

iains added a comment.

In D120540#3359446 , @ChuanqiXu wrote:

> In D120540#3359394 , @iains wrote:
>
>> 1. I agree 100% that the driver needs to be able to process in "c++20 
>> modules mode";
>
> Yeah, not all the projects could be able to run in c++20 mode. We use 
> `-std=c++17` + `-fcoroutines-ts` for C++20 coroutine before.
>
>> there is some handling of sources that should be changed accordingly.
>
> If I don't misunderstand, I guess we don't. Since all the code about C++20 
> modules are controlled by `CPlusPlusModules` variable. I think there wouldn't 
> be codes controlled by `Cpp20` variables.

Actually, the comment was intending to refer to the driver specifically - since 
(for example) we have to disambiguate PCH jobs from C++20 Header Unit jobs - in 
the Front End, as of now we have been using CPlusPlus modules as the indicator 
for C++20 modules.  There is still scope for confusion if that is set at the 
same time as alternates...

>> 2. I believe that it is a general objective of the tooling folks (roughly 
>> SG15 participants) that C++20 modules should (eventually) be considered 
>> automatic for C++20+
>
> If I understand correctly, clang would enable C++20 modules by default if 
> C++20 is enabled.

Yes, exactly, as is the case right now.

>> 3. There is at least one request from tooling folks that there should be an 
>> option to disable modules (even when in C++20  mode); this is a practical 
>> measure to avoid the case that it is impossible to build a TU because of 
>> some potential modules-related bug ...
>
> I think `-fno-cxxmodules` could be the option now.

so long as this is decoupled from any clang modules meanings?

>> 4. IMO it becomes increasingly important to try and decouple the clang 
>> modules from C++20 modules as much as possible.
>
> 100% agree. I think it should be beneficial to decouple them from command 
> line, implementation and comments. (Now many comments are not precise. For 
> example, when we talk about a `Module`. we are referring a module unit 
> indeed. There are other examples.)

It would be friendly to the user to reject command line options that are not 
appropriate to the "current modules mode" - since there are ≈ 60+ 
modules-related command line options it is already very easy to be confused.  
To do this, the driver needs to establish the "current modules mode" early 
(even before it builds jobs, since as noted above some jobs build differently 
depending on the assumed mode).

>> So .. I was going to suggest that we might introduce -fmodules= {none, 
>> clang, c++20, ...} 
>> with defaults picked:
>>
>>fmodules => clang (i.e. the current meaning)
>>   
>>   !fmodules && C++20+ => c++20 (i.e. the objective of (2) above
>>   Where there are other flags that imply C++20 that can switch c++20 mode as 
>> well
>>   
>>   otherwise the default would be "none"
>>
>> .. this provides for (3) ... since -std=c++20 -fmodules=none could be used.
>>
>> I do not have a patch for this proposal as of this time (my current patches 
>> assume (2) but do not meet the objective of (3))
>
> The proposal is good to me though. I sent a patch 
> (https://reviews.llvm.org/D113391) before to forbid the mixed use of clang 
> modules and c++20 modules since it might be confusing if we use the 
> combination `-fmodules -std=c++20`. But the comment shows that the current 
> users of Clang Modules (mainly Google and Apple) wish a smooth switch from 
> clang module to c++20 module. So I think the proposal which would break the 
> current use cases would be not easy to land. 
> (This patch wouldn't break any use case I think).

Well, I think neither proposal breaks current use-cases - the selection of 
defaults is designed to make current command lines do exactly the same as they 
do now.

My comments are not intended as a blocker for your patch -  but simply to offer 
a suggestion for a more generic handling of the same objective.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120540

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

[PATCH] D120568: [flang][driver] Add support for -S and implement -c/-emit-obj

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski updated this revision to Diff 412963.
awarzynski added a comment.

Rebase on top of D120897 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120568

Files:
  clang/include/clang/Driver/Options.td
  flang/include/flang/Frontend/FrontendActions.h
  flang/include/flang/Frontend/FrontendOptions.h
  flang/lib/Frontend/CMakeLists.txt
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/lib/Optimizer/Support/FIRContext.cpp
  flang/test/CMakeLists.txt
  flang/test/Driver/code-gen-aarch64.f90
  flang/test/Driver/code-gen-x86.f90
  flang/test/Driver/code-gen.f90
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/emit-asm-aarch64.f90
  flang/test/Driver/emit-asm-x86.f90
  flang/test/Driver/syntax-only.f90
  flang/test/Fir/target-rewrite-triple.fir
  flang/test/lit.cfg.py
  flang/test/lit.site.cfg.py.in
  flang/tools/flang-driver/fc1_main.cpp
  flang/unittests/Frontend/CMakeLists.txt
  flang/unittests/Frontend/FrontendActionTest.cpp

Index: flang/unittests/Frontend/FrontendActionTest.cpp
===
--- flang/unittests/Frontend/FrontendActionTest.cpp
+++ flang/unittests/Frontend/FrontendActionTest.cpp
@@ -11,6 +11,7 @@
 #include "flang/Frontend/FrontendOptions.h"
 #include "flang/FrontendTool/Utils.h"
 #include "llvm/Support/FileSystem.h"
+#include "llvm/Support/TargetSelect.h"
 #include "llvm/Support/raw_ostream.h"
 
 #include "gtest/gtest.h"
@@ -188,4 +189,35 @@
   EXPECT_TRUE(llvm::StringRef(outputFileBuffer.data())
   .contains("define void @_QQmain()"));
 }
+
+TEST_F(FrontendActionTest, EmitAsm) {
+  // Populate the input file with the pre-defined input and flush it.
+  *(inputFileOs_) << "end program";
+  inputFileOs_.reset();
+
+  // Set-up the action kind.
+  compInst_.invocation().frontendOpts().programAction = EmitAssembly;
+  compInst_.invocation().preprocessorOpts().noReformat = true;
+
+  // Initialise LLVM backend
+  llvm::InitializeAllTargets();
+  llvm::InitializeAllTargetMCs();
+  llvm::InitializeAllAsmPrinters();
+
+  // Set-up the output stream. We are using output buffer wrapped as an output
+  // stream, as opposed to an actual file (or a file descriptor).
+  llvm::SmallVector outputFileBuffer;
+  std::unique_ptr outputFileStream(
+  new llvm::raw_svector_ostream(outputFileBuffer));
+  compInst_.set_outputStream(std::move(outputFileStream));
+
+  // Execute the action.
+  bool success = ExecuteCompilerInvocation(&compInst_);
+
+  // Validate the expected output.
+  EXPECT_TRUE(success);
+  EXPECT_TRUE(!outputFileBuffer.empty());
+
+  EXPECT_TRUE(llvm::StringRef(outputFileBuffer.data()).contains("_QQmain"));
+}
 } // namespace
Index: flang/unittests/Frontend/CMakeLists.txt
===
--- flang/unittests/Frontend/CMakeLists.txt
+++ flang/unittests/Frontend/CMakeLists.txt
@@ -1,3 +1,7 @@
+set(LLVM_LINK_COMPONENTS
+  ${LLVM_TARGETS_TO_BUILD}
+)
+
 add_flang_unittest(FlangFrontendTests
   CompilerInstanceTest.cpp
   FrontendActionTest.cpp
Index: flang/tools/flang-driver/fc1_main.cpp
===
--- flang/tools/flang-driver/fc1_main.cpp
+++ flang/tools/flang-driver/fc1_main.cpp
@@ -20,6 +20,7 @@
 #include "llvm/Option/Arg.h"
 #include "llvm/Option/ArgList.h"
 #include "llvm/Option/OptTable.h"
+#include "llvm/Support/TargetSelect.h"
 
 #include 
 
@@ -48,6 +49,11 @@
   bool success =
   CompilerInvocation::CreateFromArgs(flang->invocation(), argv, diags);
 
+  // Initialize targets first, so that --version shows registered targets.
+  llvm::InitializeAllTargets();
+  llvm::InitializeAllTargetMCs();
+  llvm::InitializeAllAsmPrinters();
+
   diagsBuffer->FlushDiagnostics(flang->diagnostics());
 
   if (!success)
Index: flang/test/lit.site.cfg.py.in
===
--- flang/test/lit.site.cfg.py.in
+++ flang/test/lit.site.cfg.py.in
@@ -18,6 +18,7 @@
 config.flang_standalone_build = @FLANG_STANDALONE_BUILD@
 config.has_plugins = @LLVM_ENABLE_PLUGINS@
 config.cc = "@CMAKE_C_COMPILER@"
+config.targets_to_build = "@TARGETS_TO_BUILD@"
 
 # Support substitution of the tools_dir with user parameters. This is
 # used when we can't determine the tool dir at configuration time.
Index: flang/test/lit.cfg.py
===
--- flang/test/lit.cfg.py
+++ flang/test/lit.cfg.py
@@ -39,6 +39,11 @@
 llvm_config.feature_config(
 [('--assertion-mode', {'ON': 'asserts'})])
 
+# Targets
+config.targets = frozenset(config.targets_to_build.split())
+for arch in config.targets_to_build.split():
+config.available_features.add(arch.lower() + '-registered-target')
+

[PATCH] D120984: [clang][dataflow] Extend flow conditions from block terminators

[Stanislav Gatev via Phabricator via cfe-commits]

sgatev created this revision.
sgatev added reviewers: ymandel, xazax.hun, gribozavr2.
Herald added subscribers: tschuett, steakhal, rnkovacs.
Herald added a project: All.
sgatev requested review of this revision.
Herald added a project: clang.

This is part of the implementation of the dataflow analysis framework.
See "[RFC] A dataflow analysis framework for Clang AST" on cfe-dev.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D120984

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
  clang/lib/Analysis/FlowSensitive/Transfer.cpp
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
  clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
@@ -336,7 +336,8 @@
   }
 
   bool compareEquivalent(QualType Type, const Value &Val1,
- const Value &Val2) final {
+ const Environment &Env1, const Value &Val2,
+ const Environment &Env2) final {
 // Nothing to say about a value that does not model an `OptionalInt`.
 if (!Type->isRecordType() ||
 Type->getAsCXXRecordDecl()->getQualifiedNameAsString() != "OptionalInt")
@@ -346,8 +347,9 @@
cast(&Val2)->getProperty("has_value");
   }
 
-  bool merge(QualType Type, const Value &Val1, const Value &Val2,
- Value &MergedVal, Environment &Env) final {
+  bool merge(QualType Type, const Value &Val1, const Environment &Env1,
+ const Value &Val2, const Environment &Env2, Value &MergedVal,
+ Environment &Env) final {
 // Nothing to say about a value that does not model an `OptionalInt`.
 if (!Type->isRecordType() ||
 Type->getAsCXXRecordDecl()->getQualifiedNameAsString() != "OptionalInt")
@@ -559,4 +561,319 @@
   });
 }
 
+class FlowConditionTest : public Test {
+protected:
+  template 
+  void runDataflow(llvm::StringRef Code, Matcher Match) {
+ASSERT_THAT_ERROR(
+test::checkDataflow(
+Code, "target",
+[](ASTContext &Context, Environment &Env) {
+  return NoopAnalysis(Context, true);
+},
+[&Match](
+llvm::ArrayRef<
+std::pair>>
+Results,
+ASTContext &ASTCtx) { Match(Results, ASTCtx); },
+{"-fsyntax-only", "-std=c++17"}),
+llvm::Succeeded());
+  }
+};
+
+TEST_F(FlowConditionTest, IfStmtSingleVar) {
+  std::string Code = R"(
+void target(bool Foo) {
+  if (Foo) {
+(void)0;
+/*[[p1]]*/
+  } else {
+(void)1;
+/*[[p2]]*/
+  }
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+ASSERT_THAT(Results, ElementsAre(Pair("p2", _), Pair("p1", _)));
+
+const Environment &Env1 = Results[1].second.Env;
+auto *FooVal1 =
+cast(Env1.getValue(*FooDecl, SkipPast::None));
+EXPECT_TRUE(Env1.flowConditionImplies(*FooVal1));
+
+const Environment &Env2 = Results[0].second.Env;
+auto *FooVal2 =
+cast(Env2.getValue(*FooDecl, SkipPast::None));
+EXPECT_FALSE(Env2.flowConditionImplies(*FooVal2));
+  });
+}
+
+TEST_F(FlowConditionTest, IfStmtSingleNegatedVar) {
+  std::string Code = R"(
+void target(bool Foo) {
+  if (!Foo) {
+(void)0;
+/*[[p1]]*/
+  } else {
+(void)1;
+/*[[p2]]*/
+  }
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+ASSERT_THAT(Results, ElementsAre(Pair("p2", _), Pair("p1", _)));
+
+const Environment &Env1 = Results[1].second.Env;
+auto *FooVal1 =
+cast(Env1.getValue(*FooDecl, SkipPast::None));
+EXPECT_FALSE(Env1.flowConditionImplies(*FooVal1));
+
+const Environment &Env2 = Results[0].second.Env;
+auto *FooVal2 =
+cast(Env2.getValue(*FooDecl, SkipPast::None));
+EXPECT_TRUE(Env2.flowConditi

[PATCH] D120984: [clang][dataflow] Extend flow conditions from block terminators

[Stanislav Gatev via Phabricator via cfe-commits]

sgatev updated this revision to Diff 412969.
sgatev added a comment.

Minor tweaks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120984

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
  clang/lib/Analysis/FlowSensitive/Transfer.cpp
  clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
  clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
@@ -336,7 +336,8 @@
   }
 
   bool compareEquivalent(QualType Type, const Value &Val1,
- const Value &Val2) final {
+ const Environment &Env1, const Value &Val2,
+ const Environment &Env2) final {
 // Nothing to say about a value that does not model an `OptionalInt`.
 if (!Type->isRecordType() ||
 Type->getAsCXXRecordDecl()->getQualifiedNameAsString() != "OptionalInt")
@@ -346,8 +347,9 @@
cast(&Val2)->getProperty("has_value");
   }
 
-  bool merge(QualType Type, const Value &Val1, const Value &Val2,
- Value &MergedVal, Environment &Env) final {
+  bool merge(QualType Type, const Value &Val1, const Environment &Env1,
+ const Value &Val2, const Environment &Env2, Value &MergedVal,
+ Environment &Env) final {
 // Nothing to say about a value that does not model an `OptionalInt`.
 if (!Type->isRecordType() ||
 Type->getAsCXXRecordDecl()->getQualifiedNameAsString() != "OptionalInt")
@@ -559,4 +561,319 @@
   });
 }
 
+class FlowConditionTest : public Test {
+protected:
+  template 
+  void runDataflow(llvm::StringRef Code, Matcher Match) {
+ASSERT_THAT_ERROR(
+test::checkDataflow(
+Code, "target",
+[](ASTContext &Context, Environment &Env) {
+  return NoopAnalysis(Context, true);
+},
+[&Match](
+llvm::ArrayRef<
+std::pair>>
+Results,
+ASTContext &ASTCtx) { Match(Results, ASTCtx); },
+{"-fsyntax-only", "-std=c++17"}),
+llvm::Succeeded());
+  }
+};
+
+TEST_F(FlowConditionTest, IfStmtSingleVar) {
+  std::string Code = R"(
+void target(bool Foo) {
+  if (Foo) {
+(void)0;
+/*[[p1]]*/
+  } else {
+(void)1;
+/*[[p2]]*/
+  }
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+ASSERT_THAT(Results, ElementsAre(Pair("p2", _), Pair("p1", _)));
+
+const Environment &Env1 = Results[1].second.Env;
+auto *FooVal1 =
+cast(Env1.getValue(*FooDecl, SkipPast::None));
+EXPECT_TRUE(Env1.flowConditionImplies(*FooVal1));
+
+const Environment &Env2 = Results[0].second.Env;
+auto *FooVal2 =
+cast(Env2.getValue(*FooDecl, SkipPast::None));
+EXPECT_FALSE(Env2.flowConditionImplies(*FooVal2));
+  });
+}
+
+TEST_F(FlowConditionTest, IfStmtSingleNegatedVar) {
+  std::string Code = R"(
+void target(bool Foo) {
+  if (!Foo) {
+(void)0;
+/*[[p1]]*/
+  } else {
+(void)1;
+/*[[p2]]*/
+  }
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+ASSERT_THAT(Results, ElementsAre(Pair("p2", _), Pair("p1", _)));
+
+const Environment &Env1 = Results[1].second.Env;
+auto *FooVal1 =
+cast(Env1.getValue(*FooDecl, SkipPast::None));
+EXPECT_FALSE(Env1.flowConditionImplies(*FooVal1));
+
+const Environment &Env2 = Results[0].second.Env;
+auto *FooVal2 =
+cast(Env2.getValue(*FooDecl, SkipPast::None));
+EXPECT_TRUE(Env2.flowConditionImplies(*FooVal2));
+  });
+}
+
+TEST_F(FlowConditionTest, WhileStmt) {
+  std::string Code = R"(
+void target(bool Foo) {
+  while (Foo) {
+(void)0;
+/*[[p]]*/
+  }
+}
+  )";
+  runDataf

[PATCH] D120967: [NFC] Divide tests into smaller files

[Florian Hahn via Phabricator via cfe-commits]

fhahn accepted this revision.
fhahn added a comment.

Thanks for splitting up the tests! Looks like pre-commit CI is happy again!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120967

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

[PATCH] D120875: [Driver] Split up huge aarch64-cpus.c test.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 412971.
fhahn added a comment.

Thanks everyone! I added a TODO for splitting up by category and plan to land 
this soon.
The update also adds a missing GENERIC check line.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120875

Files:
  clang/test/Driver/aarch64-cpus-1.c
  clang/test/Driver/aarch64-cpus-2.c
  clang/test/Driver/aarch64-cpus.c

Index: clang/test/Driver/aarch64-cpus-2.c
===
--- /dev/null
+++ clang/test/Driver/aarch64-cpus-2.c
@@ -0,0 +1,436 @@
+// Check target CPUs are correctly passed. Continuation of aarch64-cpus-1.c.
+// NOTE: The tests are split across multiple files, to avoid excessive test
+// times for large single test files.
+// TODO: The files should be split up by categories, e.g. by architecture versions.
+
+// RUN: %clang -target aarch64 -### -c %s 2>&1 | FileCheck -check-prefix=GENERIC-V8A %s
+// RUN: %clang -target aarch64 -march=armv8-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERIC-V8A %s
+// GENERIC-V8A: "-cc1"{{.*}} "-triple" "aarch64{{(--)?}}"{{.*}} "-target-cpu" "generic" "-target-feature" "+neon" "-target-feature" "+v8a"
+
+// RUN: %clang -target aarch64 -march=armv8-r -### -c %s 2>&1 | FileCheck -check-prefix=GENERIC-V8R %s
+// GENERIC-V8R: "-cc1"{{.*}} "-triple" "aarch64{{(--)?}}"{{.*}} "-target-cpu" "generic" "-target-feature" "+neon" "-target-feature" "+v8r"
+
+// RUN: %clang -target aarch64 -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A %s
+// RUN: %clang -target aarch64 -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A %s
+// RUN: %clang -target aarch64 -mlittle-endian -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A %s
+// RUN: %clang -target aarch64 -mlittle-endian -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A %s
+// RUN: %clang -target aarch64_be -mlittle-endian -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A %s
+// RUN: %clang -target aarch64_be -mlittle-endian -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A %s
+// GENERICV81A: "-cc1"{{.*}} "-triple" "aarch64{{(--)?}}"{{.*}} "-target-cpu" "generic" "-target-feature" "+neon" "-target-feature" "+v8.1a"
+
+// RUN: %clang -target arm64 -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=ARM64-GENERICV81A %s
+// RUN: %clang -target arm64 -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=ARM64-GENERICV81A %s
+// RUN: %clang -target arm64 -mlittle-endian -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=ARM64-GENERICV81A %s
+// RUN: %clang -target arm64 -mlittle-endian -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=ARM64-GENERICV81A %s
+// ARM64-GENERICV81A: "-cc1"{{.*}} "-triple" "arm64{{.*}}" "-target-cpu" "generic" "-target-feature" "+neon" "-target-feature" "+v8.1a"
+
+// RUN: %clang -target aarch64_be -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A-BE %s
+// RUN: %clang -target aarch64_be -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A-BE %s
+// RUN: %clang -target aarch64 -mbig-endian -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A-BE %s
+// RUN: %clang -target aarch64 -mbig-endian -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A-BE %s
+// RUN: %clang -target aarch64_be -mbig-endian -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A-BE %s
+// RUN: %clang -target aarch64_be -mbig-endian -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A-BE %s
+
+// RUN: %clang -target aarch64 -march=armv8.2a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A %s
+// RUN: %clang -target aarch64 -march=armv8.2-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A %s
+// RUN: %clang -target aarch64 -mlittle-endian -march=armv8.2a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A %s
+// RUN: %clang -target aarch64 -mlittle-endian -march=armv8.2-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A %s
+// RUN: %clang -target aarch64_be -mlittle-endian -march=armv8.2a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A %s
+// RUN: %clang -target aarch64_be -mlittle-endian -march=armv8.2-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A %s
+// GENERICV82A: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "generic" "-target-feature" "+neon" "-target-feature" "+v8.2a"
+
+// RUN: %clang -target aarch64_be -march=armv8.2a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A-BE %s
+// RUN: %clang -target aarch64_be -march=armv8.2-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A-BE %s
+// RUN: %clang -target aarch64 -mbig-endian -march=armv8.2a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A-BE %s
+// RUN: %clang -target aarch64 -mbig-endian -march=armv8.2-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A-BE %s
+// RUN: %c

[PATCH] D120875: [Driver] Split up huge aarch64-cpus.c test.

[Florian Hahn 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 rG8f5bdaf481c3: [Driver] Split up huge aarch64-cpus.c test. 
(authored by fhahn).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120875

Files:
  clang/test/Driver/aarch64-cpus-1.c
  clang/test/Driver/aarch64-cpus-2.c
  clang/test/Driver/aarch64-cpus.c

Index: clang/test/Driver/aarch64-cpus-2.c
===
--- /dev/null
+++ clang/test/Driver/aarch64-cpus-2.c
@@ -0,0 +1,436 @@
+// Check target CPUs are correctly passed. Continuation of aarch64-cpus-1.c.
+// NOTE: The tests are split across multiple files, to avoid excessive test
+// times for large single test files.
+// TODO: The files should be split up by categories, e.g. by architecture versions.
+
+// RUN: %clang -target aarch64 -### -c %s 2>&1 | FileCheck -check-prefix=GENERIC-V8A %s
+// RUN: %clang -target aarch64 -march=armv8-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERIC-V8A %s
+// GENERIC-V8A: "-cc1"{{.*}} "-triple" "aarch64{{(--)?}}"{{.*}} "-target-cpu" "generic" "-target-feature" "+neon" "-target-feature" "+v8a"
+
+// RUN: %clang -target aarch64 -march=armv8-r -### -c %s 2>&1 | FileCheck -check-prefix=GENERIC-V8R %s
+// GENERIC-V8R: "-cc1"{{.*}} "-triple" "aarch64{{(--)?}}"{{.*}} "-target-cpu" "generic" "-target-feature" "+neon" "-target-feature" "+v8r"
+
+// RUN: %clang -target aarch64 -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A %s
+// RUN: %clang -target aarch64 -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A %s
+// RUN: %clang -target aarch64 -mlittle-endian -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A %s
+// RUN: %clang -target aarch64 -mlittle-endian -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A %s
+// RUN: %clang -target aarch64_be -mlittle-endian -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A %s
+// RUN: %clang -target aarch64_be -mlittle-endian -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A %s
+// GENERICV81A: "-cc1"{{.*}} "-triple" "aarch64{{(--)?}}"{{.*}} "-target-cpu" "generic" "-target-feature" "+neon" "-target-feature" "+v8.1a"
+
+// RUN: %clang -target arm64 -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=ARM64-GENERICV81A %s
+// RUN: %clang -target arm64 -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=ARM64-GENERICV81A %s
+// RUN: %clang -target arm64 -mlittle-endian -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=ARM64-GENERICV81A %s
+// RUN: %clang -target arm64 -mlittle-endian -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=ARM64-GENERICV81A %s
+// ARM64-GENERICV81A: "-cc1"{{.*}} "-triple" "arm64{{.*}}" "-target-cpu" "generic" "-target-feature" "+neon" "-target-feature" "+v8.1a"
+
+// RUN: %clang -target aarch64_be -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A-BE %s
+// RUN: %clang -target aarch64_be -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A-BE %s
+// RUN: %clang -target aarch64 -mbig-endian -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A-BE %s
+// RUN: %clang -target aarch64 -mbig-endian -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A-BE %s
+// RUN: %clang -target aarch64_be -mbig-endian -march=armv8.1a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A-BE %s
+// RUN: %clang -target aarch64_be -mbig-endian -march=armv8.1-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV81A-BE %s
+
+// RUN: %clang -target aarch64 -march=armv8.2a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A %s
+// RUN: %clang -target aarch64 -march=armv8.2-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A %s
+// RUN: %clang -target aarch64 -mlittle-endian -march=armv8.2a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A %s
+// RUN: %clang -target aarch64 -mlittle-endian -march=armv8.2-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A %s
+// RUN: %clang -target aarch64_be -mlittle-endian -march=armv8.2a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A %s
+// RUN: %clang -target aarch64_be -mlittle-endian -march=armv8.2-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A %s
+// GENERICV82A: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" "generic" "-target-feature" "+neon" "-target-feature" "+v8.2a"
+
+// RUN: %clang -target aarch64_be -march=armv8.2a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A-BE %s
+// RUN: %clang -target aarch64_be -march=armv8.2-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A-BE %s
+// RUN: %clang -target aarch64 -mbig-endian -march=armv8.2a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82A-BE %s
+// RUN: %clang -target aarch64 -mbig-endian -march=armv8.2-a -### -c %s 2>&1 | FileCheck -check-prefix=GENERICV82

[clang] 8f5bdaf - [Driver] Split up huge aarch64-cpus.c test.

[Florian Hahn via cfe-commits]

Author: Florian Hahn
Date: 2022-03-04T11:24:12Z
New Revision: 8f5bdaf481c3f4e6876a5ae0e4d7c6ed2042e6a6

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

LOG: [Driver] Split up huge aarch64-cpus.c test.

This test file has grown to the point where it takes a huge amount of
time to run. At the moment, this test seems to consistently time out
when running in the pre-commit checks in Phabricator with a 10 minute
timeout. For example see
https://reviews.llvm.org/harbormaster/unit/view/2832723/

While splitting up the test file is not ideal, it is even more
undesirable to have huge test files that time out in common settings.

This patch splits up the test file roughly in the middle.

Reviewed By: dmgreen

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

Added: 
clang/test/Driver/aarch64-cpus-1.c
clang/test/Driver/aarch64-cpus-2.c

Modified: 


Removed: 
clang/test/Driver/aarch64-cpus.c



diff  --git a/clang/test/Driver/aarch64-cpus.c 
b/clang/test/Driver/aarch64-cpus-1.c
similarity index 53%
rename from clang/test/Driver/aarch64-cpus.c
rename to clang/test/Driver/aarch64-cpus-1.c
index 235eb4f1c5d1b..675f2b01f9df8 100644
--- a/clang/test/Driver/aarch64-cpus.c
+++ b/clang/test/Driver/aarch64-cpus-1.c
@@ -1,4 +1,7 @@
-// Check target CPUs are correctly passed.
+// Check target CPUs are correctly passed. See aarch64-cpus-2.c for additional 
tests.
+// NOTE: The tests are split across multiple files, to avoid excessive test
+// times for large single test files.
+// TODO: The files should be split up by categories, e.g. by architecture 
versions.
 
 // RUN: %clang -target aarch64 -### -c %s 2>&1 | FileCheck 
-check-prefix=GENERIC %s
 // RUN: %clang -target aarch64 -mcpu=generic -### -c %s 2>&1 | FileCheck 
-check-prefix=GENERIC %s
@@ -512,434 +515,3 @@
 // MCPU-MTUNE-A73: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-cpu" 
"cortex-a73"
 // MCPU-MTUNE-THUNDERX2T99: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" 
"-target-cpu" "thunderx2t99"
 // MCPU-MTUNE-THUNDERX3T110: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" 
"-target-cpu" "thunderx3t110"
-
-// RUN: %clang -target aarch64 -### -c %s 2>&1 | FileCheck 
-check-prefix=GENERIC-V8A %s
-// RUN: %clang -target aarch64 -march=armv8-a -### -c %s 2>&1 | FileCheck 
-check-prefix=GENERIC-V8A %s
-// GENERIC-V8A: "-cc1"{{.*}} "-triple" "aarch64{{(--)?}}"{{.*}} "-target-cpu" 
"generic" "-target-feature" "+neon" "-target-feature" "+v8a"
-
-// RUN: %clang -target aarch64 -march=armv8-r -### -c %s 2>&1 | FileCheck 
-check-prefix=GENERIC-V8R %s
-// GENERIC-V8R: "-cc1"{{.*}} "-triple" "aarch64{{(--)?}}"{{.*}} "-target-cpu" 
"generic" "-target-feature" "+neon" "-target-feature" "+v8r"
-
-// RUN: %clang -target aarch64 -march=armv8.1a -### -c %s 2>&1 | FileCheck 
-check-prefix=GENERICV81A %s
-// RUN: %clang -target aarch64 -march=armv8.1-a -### -c %s 2>&1 | FileCheck 
-check-prefix=GENERICV81A %s
-// RUN: %clang -target aarch64 -mlittle-endian -march=armv8.1a -### -c %s 2>&1 
| FileCheck -check-prefix=GENERICV81A %s
-// RUN: %clang -target aarch64 -mlittle-endian -march=armv8.1-a -### -c %s 
2>&1 | FileCheck -check-prefix=GENERICV81A %s
-// RUN: %clang -target aarch64_be -mlittle-endian -march=armv8.1a -### -c %s 
2>&1 | FileCheck -check-prefix=GENERICV81A %s
-// RUN: %clang -target aarch64_be -mlittle-endian -march=armv8.1-a -### -c %s 
2>&1 | FileCheck -check-prefix=GENERICV81A %s
-// GENERICV81A: "-cc1"{{.*}} "-triple" "aarch64{{(--)?}}"{{.*}} "-target-cpu" 
"generic" "-target-feature" "+neon" "-target-feature" "+v8.1a"
-
-// RUN: %clang -target arm64 -march=armv8.1a -### -c %s 2>&1 | FileCheck 
-check-prefix=ARM64-GENERICV81A %s
-// RUN: %clang -target arm64 -march=armv8.1-a -### -c %s 2>&1 | FileCheck 
-check-prefix=ARM64-GENERICV81A %s
-// RUN: %clang -target arm64 -mlittle-endian -march=armv8.1a -### -c %s 2>&1 | 
FileCheck -check-prefix=ARM64-GENERICV81A %s
-// RUN: %clang -target arm64 -mlittle-endian -march=armv8.1-a -### -c %s 2>&1 
| FileCheck -check-prefix=ARM64-GENERICV81A %s
-// ARM64-GENERICV81A: "-cc1"{{.*}} "-triple" "arm64{{.*}}" "-target-cpu" 
"generic" "-target-feature" "+neon" "-target-feature" "+v8.1a"
-
-// RUN: %clang -target aarch64_be -march=armv8.1a -### -c %s 2>&1 | FileCheck 
-check-prefix=GENERICV81A-BE %s
-// RUN: %clang -target aarch64_be -march=armv8.1-a -### -c %s 2>&1 | FileCheck 
-check-prefix=GENERICV81A-BE %s
-// RUN: %clang -target aarch64 -mbig-endian -march=armv8.1a -### -c %s 2>&1 | 
FileCheck -check-prefix=GENERICV81A-BE %s
-// RUN: %clang -target aarch64 -mbig-endian -march=armv8.1-a -### -c %s 2>&1 | 
FileCheck -check-prefix=GENERICV81A-BE %s
-// RUN: %clang -target aarch64_be -mbig-endian -march=armv8.1a -### -c %s 2>&1 
| FileCheck -check-prefix=GENERICV81A-BE %s
-// RUN: %clang -target aarch64_be -mbig-en

[PATCH] D120876: [Driver] Split up huge arm-cortex-cpus.c test.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 412974.
fhahn added a comment.

Thanks!

I added a TODO to split it up by categories and I'll plan to land the change 
soon.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120876

Files:
  clang/test/Driver/arm-cortex-cpus-1.c
  clang/test/Driver/arm-cortex-cpus-2.c
  clang/test/Driver/arm-cortex-cpus.c

Index: clang/test/Driver/arm-cortex-cpus-2.c
===
--- clang/test/Driver/arm-cortex-cpus-2.c
+++ clang/test/Driver/arm-cortex-cpus-2.c
@@ -1,445 +1,8 @@
-// == Check default CPU on each major architecture
-// RUN: %clang -target arm -mcpu=generic -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-GENERIC %s
-// CHECK-GENERIC: "-cc1"{{.*}} "-triple" "armv4t-{{.*}} "-target-cpu" "generic"
-
-// RUN: %clang -target armeb -mcpu=generic -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-BE-GENERIC %s
-// CHECK-BE-GENERIC: "-cc1"{{.*}} "-triple" "armebv4t-{{.*}} "-target-cpu" "generic"
-
-// RUN: %clang -target arm -mthumb -mcpu=generic -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-GENERIC-THUMB %s
-// CHECK-GENERIC-THUMB: "-cc1"{{.*}} "-triple" "thumbv4t-{{.*}} "-target-cpu" "generic"
-
-// RUN: %clang -target armeb -mthumb -mcpu=generic -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-BE-GENERIC-THUMB %s
-// CHECK-BE-GENERIC-THUMB: "-cc1"{{.*}} "-triple" "thumbebv4t-{{.*}} "-target-cpu" "generic"
-
-// RUN: %clang -target armv4t -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V4T %s
-// RUN: %clang -target arm -march=armv4t -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V4T %s
-// CHECK-V4T: "-cc1"{{.*}} "-triple" "armv4t-{{.*}} "-target-cpu" "arm7tdmi"
-
-// RUN: %clang -target armv4t -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V4T-THUMB %s
-// RUN: %clang -target arm -mthumb -march=armv4t -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V4T-THUMB %s
-// CHECK-V4T-THUMB: "-cc1"{{.*}} "-triple" "thumbv4t-{{.*}} "-target-cpu" "arm7tdmi"
-
-// RUN: %clang -target armv5 -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5 %s
-// RUN: %clang -target arm -march=armv5 -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5 %s
-// RUN: %clang -target armv5t -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5 %s
-// RUN: %clang -target arm -march=armv5t -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5 %s
-// CHECK-V5: "-cc1"{{.*}} "-triple" "armv5-{{.*}} "-target-cpu" "arm10tdmi"
-
-// RUN: %clang -target armv5 -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5-THUMB %s
-// RUN: %clang -target arm -march=armv5 -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5-THUMB %s
-// RUN: %clang -target armv5t -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5-THUMB %s
-// CHECK-V5-THUMB: "-cc1"{{.*}} "-triple" "thumbv5-{{.*}} "-target-cpu" "arm10tdmi"
-
-// RUN: %clang -target armv5e -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5E %s
-// RUN: %clang -target arm -march=armv5e -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5E %s
-// CHECK-V5E: "-cc1"{{.*}} "-triple" "armv5e-{{.*}} "-target-cpu" "arm1022e"
-
-// RUN: %clang -target armv5e -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5E-THUMB %s
-// RUN: %clang -target arm -march=armv5e -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5E-THUMB %s
-// CHECK-V5E-THUMB: "-cc1"{{.*}} "-triple" "thumbv5e-{{.*}} "-target-cpu" "arm1022e"
-
-// FIXME %clang -target armv5tej -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5TEJ %s
-// RUN: %clang -target arm -march=armv5tej -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5TEJ %s
-// CHECK-V5TEJ: "-cc1"{{.*}} "-triple" "armv5e-{{.*}} "-target-cpu" "arm926ej-s"
-
-// FIXME %clang -target armv5tej -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5TEJ-THUMB %s
-// RUN: %clang -target arm -march=armv5tej -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5TEJ-THUMB %s
-// CHECK-V5TEJ-THUMB: "-cc1"{{.*}} "-triple" "thumbv5e-{{.*}} "-target-cpu" "arm926ej-s"
-
-// RUN: %clang -target armv6 -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V6 %s
-// RUN: %clang -target arm -march=armv6 -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V6 %s
-// CHECK-V6: "-cc1"{{.*}} "-triple" "armv6-{{.*}} "-target-cpu" "arm1136jf-s"
-
-// RUN: %clang -target armv6 -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V6-THUMB %s
-// RUN: %clang -target arm -march=armv6 -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V6-THUMB %s
-// CHECK-V6-THUMB: "-cc1"{{.*}} "-triple" "thumbv6-{{.*}} "-target-cpu" "arm1136jf-s"
-
-// FIXME %clang -target armv6j -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V6J %s
-// RUN: %clang -target arm -march=armv6j -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V6J %s
-// CHECK-V6J: "-cc1"{{.*}} "-triple" "armv6-{{.*}} "-target-cpu" "arm1136jf-s"
-
-// FIXME %clang -target armv6j -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V6J-THUMB %s
-// RUN: %clang -tar

[clang] fb42e55 - [Driver] Split up huge arm-cortex-cpus.c test.

[Florian Hahn via cfe-commits]

Author: Florian Hahn
Date: 2022-03-04T11:37:00Z
New Revision: fb42e557d8b4c8430a75391bbb5af309b5472685

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

LOG: [Driver] Split up huge arm-cortex-cpus.c test.

This test file has grown to the point where it takes a huge amount of
time to run. At the moment, this test seems to consistently time out
when running in the pre-commit checks in Phabricator with a 10 minute
timeout. For example see
https://reviews.llvm.org/harbormaster/unit/view/2832724/

While splitting up the test file is not ideal, it is even more
undesirable to have huge test files that time out in common settings.

This patch splits up the test file roughly in the middle.

Reviewed By: dmgreen

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

Added: 
clang/test/Driver/arm-cortex-cpus-1.c
clang/test/Driver/arm-cortex-cpus-2.c

Modified: 


Removed: 
clang/test/Driver/arm-cortex-cpus.c



diff  --git a/clang/test/Driver/arm-cortex-cpus-1.c 
b/clang/test/Driver/arm-cortex-cpus-1.c
new file mode 100644
index 0..7b6c203b53b80
--- /dev/null
+++ b/clang/test/Driver/arm-cortex-cpus-1.c
@@ -0,0 +1,446 @@
+// NOTE: See arm-cortex-cpus-2.c for additional tests The tests are split
+// across multiple files, to avoid excessive test times for large single
+// test files.
+// TODO: The files should be split up by categories, e.g. by architecture 
versions.
+//
+// == Check default CPU on each major architecture
+// RUN: %clang -target arm -mcpu=generic -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-GENERIC %s
+// CHECK-GENERIC: "-cc1"{{.*}} "-triple" "armv4t-{{.*}} "-target-cpu" "generic"
+
+// RUN: %clang -target armeb -mcpu=generic -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-BE-GENERIC %s
+// CHECK-BE-GENERIC: "-cc1"{{.*}} "-triple" "armebv4t-{{.*}} "-target-cpu" 
"generic"
+
+// RUN: %clang -target arm -mthumb -mcpu=generic -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-GENERIC-THUMB %s
+// CHECK-GENERIC-THUMB: "-cc1"{{.*}} "-triple" "thumbv4t-{{.*}} "-target-cpu" 
"generic"
+
+// RUN: %clang -target armeb -mthumb -mcpu=generic -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-BE-GENERIC-THUMB %s
+// CHECK-BE-GENERIC-THUMB: "-cc1"{{.*}} "-triple" "thumbebv4t-{{.*}} 
"-target-cpu" "generic"
+
+// RUN: %clang -target armv4t -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V4T %s
+// RUN: %clang -target arm -march=armv4t -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V4T %s
+// CHECK-V4T: "-cc1"{{.*}} "-triple" "armv4t-{{.*}} "-target-cpu" "arm7tdmi"
+
+// RUN: %clang -target armv4t -mthumb -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V4T-THUMB %s
+// RUN: %clang -target arm -mthumb -march=armv4t -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V4T-THUMB %s
+// CHECK-V4T-THUMB: "-cc1"{{.*}} "-triple" "thumbv4t-{{.*}} "-target-cpu" 
"arm7tdmi"
+
+// RUN: %clang -target armv5 -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V5 %s
+// RUN: %clang -target arm -march=armv5 -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V5 %s
+// RUN: %clang -target armv5t -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V5 %s
+// RUN: %clang -target arm -march=armv5t -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V5 %s
+// CHECK-V5: "-cc1"{{.*}} "-triple" "armv5-{{.*}} "-target-cpu" "arm10tdmi"
+
+// RUN: %clang -target armv5 -mthumb -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V5-THUMB %s
+// RUN: %clang -target arm -march=armv5 -mthumb -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V5-THUMB %s
+// RUN: %clang -target armv5t -mthumb -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V5-THUMB %s
+// CHECK-V5-THUMB: "-cc1"{{.*}} "-triple" "thumbv5-{{.*}} "-target-cpu" 
"arm10tdmi"
+
+// RUN: %clang -target armv5e -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V5E %s
+// RUN: %clang -target arm -march=armv5e -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V5E %s
+// CHECK-V5E: "-cc1"{{.*}} "-triple" "armv5e-{{.*}} "-target-cpu" "arm1022e"
+
+// RUN: %clang -target armv5e -mthumb -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V5E-THUMB %s
+// RUN: %clang -target arm -march=armv5e -mthumb -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V5E-THUMB %s
+// CHECK-V5E-THUMB: "-cc1"{{.*}} "-triple" "thumbv5e-{{.*}} "-target-cpu" 
"arm1022e"
+
+// FIXME %clang -target armv5tej -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V5TEJ %s
+// RUN: %clang -target arm -march=armv5tej -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V5TEJ %s
+// CHECK-V5TEJ: "-cc1"{{.*}} "-triple" "armv5e-{{.*}} "-target-cpu" 
"arm926ej-s"
+
+// FIXME %clang -target armv5tej -mthumb -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V5TEJ-THUMB %s
+// RUN: %clang -target arm -march=armv5tej -mthumb -### -c %s 2>&1 | FileCheck 
-check-prefix=CHECK-V5TEJ-THUMB %s
+// CHECK-V5TEJ

[PATCH] D120876: [Driver] Split up huge arm-cortex-cpus.c test.

[Florian Hahn 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 rGfb42e557d8b4: [Driver] Split up huge arm-cortex-cpus.c test. 
(authored by fhahn).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120876

Files:
  clang/test/Driver/arm-cortex-cpus-1.c
  clang/test/Driver/arm-cortex-cpus-2.c
  clang/test/Driver/arm-cortex-cpus.c

Index: clang/test/Driver/arm-cortex-cpus-2.c
===
--- clang/test/Driver/arm-cortex-cpus-2.c
+++ clang/test/Driver/arm-cortex-cpus-2.c
@@ -1,445 +1,8 @@
-// == Check default CPU on each major architecture
-// RUN: %clang -target arm -mcpu=generic -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-GENERIC %s
-// CHECK-GENERIC: "-cc1"{{.*}} "-triple" "armv4t-{{.*}} "-target-cpu" "generic"
-
-// RUN: %clang -target armeb -mcpu=generic -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-BE-GENERIC %s
-// CHECK-BE-GENERIC: "-cc1"{{.*}} "-triple" "armebv4t-{{.*}} "-target-cpu" "generic"
-
-// RUN: %clang -target arm -mthumb -mcpu=generic -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-GENERIC-THUMB %s
-// CHECK-GENERIC-THUMB: "-cc1"{{.*}} "-triple" "thumbv4t-{{.*}} "-target-cpu" "generic"
-
-// RUN: %clang -target armeb -mthumb -mcpu=generic -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-BE-GENERIC-THUMB %s
-// CHECK-BE-GENERIC-THUMB: "-cc1"{{.*}} "-triple" "thumbebv4t-{{.*}} "-target-cpu" "generic"
-
-// RUN: %clang -target armv4t -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V4T %s
-// RUN: %clang -target arm -march=armv4t -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V4T %s
-// CHECK-V4T: "-cc1"{{.*}} "-triple" "armv4t-{{.*}} "-target-cpu" "arm7tdmi"
-
-// RUN: %clang -target armv4t -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V4T-THUMB %s
-// RUN: %clang -target arm -mthumb -march=armv4t -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V4T-THUMB %s
-// CHECK-V4T-THUMB: "-cc1"{{.*}} "-triple" "thumbv4t-{{.*}} "-target-cpu" "arm7tdmi"
-
-// RUN: %clang -target armv5 -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5 %s
-// RUN: %clang -target arm -march=armv5 -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5 %s
-// RUN: %clang -target armv5t -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5 %s
-// RUN: %clang -target arm -march=armv5t -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5 %s
-// CHECK-V5: "-cc1"{{.*}} "-triple" "armv5-{{.*}} "-target-cpu" "arm10tdmi"
-
-// RUN: %clang -target armv5 -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5-THUMB %s
-// RUN: %clang -target arm -march=armv5 -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5-THUMB %s
-// RUN: %clang -target armv5t -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5-THUMB %s
-// CHECK-V5-THUMB: "-cc1"{{.*}} "-triple" "thumbv5-{{.*}} "-target-cpu" "arm10tdmi"
-
-// RUN: %clang -target armv5e -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5E %s
-// RUN: %clang -target arm -march=armv5e -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5E %s
-// CHECK-V5E: "-cc1"{{.*}} "-triple" "armv5e-{{.*}} "-target-cpu" "arm1022e"
-
-// RUN: %clang -target armv5e -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5E-THUMB %s
-// RUN: %clang -target arm -march=armv5e -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5E-THUMB %s
-// CHECK-V5E-THUMB: "-cc1"{{.*}} "-triple" "thumbv5e-{{.*}} "-target-cpu" "arm1022e"
-
-// FIXME %clang -target armv5tej -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5TEJ %s
-// RUN: %clang -target arm -march=armv5tej -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5TEJ %s
-// CHECK-V5TEJ: "-cc1"{{.*}} "-triple" "armv5e-{{.*}} "-target-cpu" "arm926ej-s"
-
-// FIXME %clang -target armv5tej -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5TEJ-THUMB %s
-// RUN: %clang -target arm -march=armv5tej -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V5TEJ-THUMB %s
-// CHECK-V5TEJ-THUMB: "-cc1"{{.*}} "-triple" "thumbv5e-{{.*}} "-target-cpu" "arm926ej-s"
-
-// RUN: %clang -target armv6 -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V6 %s
-// RUN: %clang -target arm -march=armv6 -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V6 %s
-// CHECK-V6: "-cc1"{{.*}} "-triple" "armv6-{{.*}} "-target-cpu" "arm1136jf-s"
-
-// RUN: %clang -target armv6 -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V6-THUMB %s
-// RUN: %clang -target arm -march=armv6 -mthumb -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V6-THUMB %s
-// CHECK-V6-THUMB: "-cc1"{{.*}} "-triple" "thumbv6-{{.*}} "-target-cpu" "arm1136jf-s"
-
-// FIXME %clang -target armv6j -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V6J %s
-// RUN: %clang -target arm -march=armv6j -### -c %s 2>&1 | FileCheck -check-prefix=CHECK-V6J %s
-// CHECK-V6J: "-cc1"{{.*}} "-triple" "armv6-{{.*}} "-target-cpu" "arm1136jf-s"
-
-// FIXME %clang -target armv6j -mthumb -### -c %s 

[PATCH] D118352: [clang][ABI] New c++20 modules mangling scheme

[Nathan Sidwell via Phabricator via cfe-commits]

urnathan added a comment.

In D118352#3358864 , @ChuanqiXu wrote:

> If I don't misread the codes, it looks like `mangleModuleInitializer` is not 
> called.



> Now we could add test for partitions.

Correct, it is not called as the global initializer pieces are not yet 
implemented.  Let's not hold up this patch for that nor remove piece that will 
become necessary at that point.


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

https://reviews.llvm.org/D118352

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

[PATCH] D103313: [RISCV][Clang] Implement support for zmmul-experimental

[ksyx via Phabricator via cfe-commits]

ksyx added a comment.

In D103313#3359310 , @JiahaoChenConor 
wrote:

> Hi, do you still continue working on this patch?

In fact, not pretty sure what else I need to improve on this.


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

https://reviews.llvm.org/D103313

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

[PATCH] D120949: [clang][AST matchers] adding attributedStmt AST matcher

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a subscriber: sammccall.
aaron.ballman added a comment.

In D120949#3358707 , 
@ajohnson-uoregon wrote:

> Okay this is actually the right commits now, sorry about the spam, Aaron. 🙃 
> Didn't realize I'd put unrelated things in the first commit.

No worries! I usually review AST matcher changes anyway, so there's definitely 
no harm in tagging me. :-)

You also need to add some test coverage for the changes to 
`clang/unittests/ASTMatchers/` and you also need to regenerate the 
documentation by running `clang/docs/tools/dump_ast_matchers.py`.




Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2704-2712
+/// Example: Matches [[likely]] and [[unlikely]]
+/// \code
+///   constexpr double pow(double x, long long n) noexcept {
+/// if (n > 0) [[likely]]
+///  return x * pow(x, n - 1);
+/// else [[unlikely]]
+///  return 1;





Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2713-2714
+/// \endcode
+extern const internal::VariadicDynCastAllOfMatcher
+attributedStmt;
+

Design-wise, I'm on the fence here. AST matchers match the AST nodes that Clang 
produces, and from that perspective, this makes a lot of sense. But 
`AttributedStmt` is a bit of a hack in some ways, and do we want to expose that 
hack to AST matcher users? e.g., is there a reason we shouldn't make 
`returnStmt(hasAttr(attr::Likely))` work directly rather than making the user 
pick their way through the `AttributedStmt`? This is more in line with how you 
check for a declaration with a particular attribute and seems like the more 
natural way to surface this.

For the moment, since this is following the current AST structure in Clang, I 
think this is fine. But I'm curious if @klimek or perhaps @sammccall has an 
opinion here.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2722
+/// \endcode
+/// would only match [[likely]] here:
+/// \code





Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2732-2737
+  for (const auto *Attr : Node.getAttrs()) {
+if (Attr->getKind() == AttrKind) {
+  return true;
+}
+  }
+  return false;

Probably have to reformat this as well.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2746
+/// \endcode
+/// would match return 1; here:
+/// \code





Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2753-2755
+  const Stmt *const Statement = Node.getSubStmt();
+  return (Statement != nullptr &&
+  InnerMatcher.matches(*Statement, Finder, Builder));




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120949

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

[PATCH] D120967: [NFC] Divide tests into smaller files

[Brandon Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG5a148869d336: [NFC] Divide tests into smaller files 
(authored by 4vtomat).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120967

Files:
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vloxseg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vloxseg_mask.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vluxseg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vluxseg_mask.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vloxseg_mask.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vluxseg_mask.c

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

[clang] 6afe035 - Revert "[analyzer] Done some changes to detect Uninitialized read by the char array manipulation functions"

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2022-03-04T07:21:52-05:00
New Revision: 6afe0354048f350442708eff0875101fe6f2bf44

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

LOG: Revert "[analyzer] Done some changes to detect Uninitialized read by the 
char array manipulation functions"

This reverts commit 9c300c18a4eaf79eb7044744bbdb705764579220.

This broke the sphinx bot and seems like an unintentional commit.

Added: 


Modified: 
clang/docs/analyzer/checkers.rst

Removed: 




diff  --git a/clang/docs/analyzer/checkers.rst 
b/clang/docs/analyzer/checkers.rst
index a9ebe063c6c8b..bc42b80d166c7 100644
--- a/clang/docs/analyzer/checkers.rst
+++ b/clang/docs/analyzer/checkers.rst
@@ -2650,6 +2650,7 @@ Limitations:
   
- Due to limitations of the memory modeling in the analyzer, one can likely
  observe a lot of false-positive reports like this:
+
   .. code-block:: c
   
 void false_positive() {



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

Re: [clang] 9c300c1 - [analyzer] Done some changes to detect Uninitialized read by the char array manipulation functions

[Aaron Ballman via cfe-commits]

Can you explain this commit please? I had to revert it in
6afe0354048f350442708eff0875101fe6f2bf44 because it broke the Sphinx
bot, but this looks like an unintentional commit and I wanted to
double-check (I had fixed this exact issue in
d74a3a514cf64731ecd21e1453aa78af79a565f2 and your changes here undid
my fix which is why I thought this might be an unintentional commit).

~Aaron

On Fri, Mar 4, 2022 at 1:48 AM via cfe-commits
 wrote:
>
>
> Author: phyBrackets
> Date: 2022-03-04T12:17:58+05:30
> New Revision: 9c300c18a4eaf79eb7044744bbdb705764579220
>
> URL: 
> https://github.com/llvm/llvm-project/commit/9c300c18a4eaf79eb7044744bbdb705764579220
> DIFF: 
> https://github.com/llvm/llvm-project/commit/9c300c18a4eaf79eb7044744bbdb705764579220.diff
>
> LOG: [analyzer] Done some changes to detect Uninitialized read by the char 
> array manipulation functions
>
> Few weeks back I was experimenting with reading the uninitialized values from 
> src , which is actually a bug but the CSA seems to give up at that point . I 
> was curious about that and I pinged @steakhal on the discord and according to 
> him this seems to be a genuine issue and needs to be fix. So I goes with 
> fixing this bug and thanks to @steakhal who help me creating this patch. This 
> feature seems to break some tests but this was the genuine problem and the 
> broken tests also needs to fix in certain manner. I add a test but yeah we 
> need more tests,I'll try to add more tests.Thanks
>
> Reviewed By: steakhal, NoQ
>
> Differential Revision: https://reviews.llvm.org/D120489
>
> Added:
>
>
> Modified:
> clang/docs/analyzer/checkers.rst
>
> Removed:
>
>
>
> 
> diff  --git a/clang/docs/analyzer/checkers.rst 
> b/clang/docs/analyzer/checkers.rst
> index bc42b80d166c7..a9ebe063c6c8b 100644
> --- a/clang/docs/analyzer/checkers.rst
> +++ b/clang/docs/analyzer/checkers.rst
> @@ -2650,7 +2650,6 @@ Limitations:
>
> - Due to limitations of the memory modeling in the analyzer, one can 
> likely
>   observe a lot of false-positive reports like this:
> -
>.. code-block:: c
>
>  void false_positive() {
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D120989: Support debug info for alias variable

[Kavitha Natarajan via Phabricator via cfe-commits]

kavitha-natarajan created this revision.
kavitha-natarajan added reviewers: kamleshbhalui, umesh.kalappa0, probinson, 
dblaikie.
kavitha-natarajan added a project: debug-info.
Herald added a subscriber: jeroen.dobbelaere.
Herald added a project: All.
kavitha-natarajan requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This is in continuation with the patch posted earlier for bug-50052 
:

https://reviews.llvm.org/D103131

For the below testcase, when compiled with clang compiler, debugger is not able 
to print alias variable type or value. 
$ cat test.c
int oldname = 1;
extern int newname attribute((alias("oldname")));

int main ()
{

  return 0;

}

$ clang -g -O0 test.c

$ gdb a.out
(gdb) ptype oldname
type = int
(gdb) ptype newname
type = 
(gdb) p oldname
$1 = 1
(gdb) p newname
'newname' has unknown type; cast it to its declared type

This is because clang is not emitting dwarf information for alias variable. The 
above mentioned patch supports clang to emit debug info for alias variable as 
imported entity (DW_TAG_imported_declaration). However, gdb cannot handle the 
imported declaration for alias variables. GCC emits debug info for alias 
variables as DW_TAG_variable which gdb can handle. The discussions in the above 
bug report and patch review links talk about why it is appropriate to emit 
alias variable as DW_TAG_imported_declaration rather than DW_TAG_variable. 
Refer section "3.2.3 Imported (or Renamed) Declaration Entries" in DWARF 5 
specification.

In the clang patch, CGDebugInfo.cpp:EmitGlobalAlias() function is rewritten to 
handle nested (recursive) imported declaration and developed a testcase as 
well. A corresponding gdb patch that can handle DW_TAG_imported_declaration as 
alias variables is also developed and will be posted to gdb community for 
review in parallel.

After clang and gdb fixes:

$ gdb a.out
(gdb) ptype oldname
type = int
(gdb) ptype newname
type = int
(gdb) p oldname
$1 = 1
(gdb) p newname
$2 = 1
(gdb)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D120989

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/test/CodeGen/debug-info-alias.c

Index: clang/test/CodeGen/debug-info-alias.c
===
--- /dev/null
+++ clang/test/CodeGen/debug-info-alias.c
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -emit-llvm -debug-info-kind=limited %s -o - | FileCheck %s
+
+// CHECK-DAG: [[ENTITY1:![0-9]+]] = distinct !DIGlobalVariable(name: "aliased_global"
+// CHECK-DAG: [[ENTITY2:![0-9]+]] = distinct !DIGlobalVariable(name: "aliased_global_2"
+// CHECK-DAG: !DIImportedEntity(tag: DW_TAG_imported_declaration, name: "__global_alias", scope: !2, entity: [[ENTITY1]]
+// CHECK-DAG: [[ENTITY3:![0-9]+]] = !DIImportedEntity(tag: DW_TAG_imported_declaration, name: "global_alias_2", scope: !2, entity: [[ENTITY2]]
+// CHECK-DAG: !DIImportedEntity(tag: DW_TAG_imported_declaration, name: "__global_alias_2_alias", scope: !2, entity: [[ENTITY3]]
+
+int aliased_global = 1;
+extern int __attribute__((alias("aliased_global"))) __global_alias;
+
+// Recursive alias:
+int aliased_global_2 = 2;
+extern int __attribute__((alias("aliased_global_2"))) global_alias_2;
+extern int __attribute__((alias("global_alias_2"))) __global_alias_2_alias;
Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -1213,6 +1213,7 @@
 
   StringRef getMangledName(GlobalDecl GD);
   StringRef getBlockMangledName(GlobalDecl GD, const BlockDecl *BD);
+  const GlobalDecl getMangledNameDecl(StringRef);
 
   void EmitTentativeDefinition(const VarDecl *D);
 
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -1495,6 +1495,16 @@
   return Result.first->first();
 }
 
+const GlobalDecl CodeGenModule::getMangledNameDecl(StringRef Name) {
+  auto it = MangledDeclNames.begin();
+  while (it != MangledDeclNames.end()) {
+if (it->second == Name)
+  return it->first;
+it++;
+  }
+  return GlobalDecl();
+}
+
 llvm::GlobalValue *CodeGenModule::GetGlobalValue(StringRef Name) {
   return getModule().getNamedValue(Name);
 }
@@ -5139,6 +5149,13 @@
   setTLSMode(GA, *VD);
 
   SetCommonAttributes(GD, GA);
+
+  // Emit global alias debug information.
+  if (const auto *VD = dyn_cast(D)) {
+if (CGDebugInfo *DI = getModuleDebugInfo()) {
+  DI->EmitGlobalAlias(cast(GA->getAliasee()), GD);
+}
+  }
 }
 
 void CodeGenModule::emitIFuncDefinition(GlobalDecl GD) {
Index: clang/lib/CodeGen/CGDebugInfo.h
===
--- clang/lib/CodeGen

[PATCH] D120952: [clang][AST matchers] adding submatchers under cudaKernelCallExpr to match kernel launch config

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a reviewer: aaron.ballman.
aaron.ballman added a comment.

Typically, we only add AST matchers when there's an obvious need for them (we 
do this because compiling this file takes a *long* time and generates quite a 
few symbols in the executable). I'm not certain that these CUDA matchers rise 
to that level of need -- are you planning to write a number of clang-tidy 
checks that use these new interfaces (or some other in-tree use)?

(Assuming you think we should continue to progress this patch, you should fix 
the clang-format issues, add test coverage, and regenerate documentation.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120952

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

[PATCH] D120959: [clang][AST matchers] new hasExpectedReturnType submatcher for ReturnStmts

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a reviewer: aaron.ballman.
aaron.ballman added a comment.

As mentioned in another review, it's not clear that this rises to the level of 
need to add it to the general AST matching interfaces. Can you explain the 
intended in-tree use cases for this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120959

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

[PATCH] D120258: [clangd] Add inlay hints for auto-typed parameters with one instantiation.

[Trass3r via Phabricator via cfe-commits]

Trass3r added a comment.
Herald added a project: All.

@sammccall pls merge


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120258

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

[PATCH] D120956: [clang][AST matchers] new AST matcher argumentsGivenCountIs(n) that checks the actual number of arguments given in a function call

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

This seems somewhat more generally applicable as an AST matcher, but I'm still 
curious what the in-tree use will be for it. (Same suggestion for test coverage 
and regenerating the documentation as before.)




Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:4452
+/// \endcode
+AST_POLYMORPHIC_MATCHER_P(argumentsGivenCountIs,
+  AST_POLYMORPHIC_SUPPORTED_TYPES(

I have a preference for `argumentCountAsWrittenIs()` -- we often use "as 
written" to distinguish syntax from semantics, and in the case of default 
arguments, the semantics are that the default arguments are treated as if they 
were given at the call site, so I would expect `argumentsGivenCountIs(2)` to 
match both calls to `f()`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120956

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

[PATCH] D118869: [clang-format] Non-latin comment prefix whitespace

[ksyx via Phabricator via cfe-commits]

ksyx added a comment.

In D118869#3359439 , @krasimir wrote:

> It appears that this caused a regression by adding an additional space of 
> indentation to line comments in some cases:
>
>   % cat test.cc  # (before)
>   // Comment
>   int i;
>   % clang-format -style=google test.cc
>   //  Comment
>   int i;
>
> @ksyx could you please take a look?

I did not reproduce it in latest main branch. This problem may in relate to 
this issue which have recently been fixed: 
https://github.com/llvm/llvm-project/issues/53844


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118869

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

[PATCH] D120947: [tooling] Explain how to create a compilation database on Windows [NFC]

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM aside from a formatting nit, thank you -- this is really helpful 
information! I confirmed the instructions work for me on Windows.




Comment at: clang/docs/HowToSetupToolingForLLVM.rst:66-68
+First, you will need to install `Ninja`_.  Once
+installed, the Ninja executable will need to be in your search path for CMake
+to locate it.

Looks like you can re-flow this to the usual 80 col limit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120947

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

[PATCH] D120911: [CUDA][HIP] Fix offloading kind for linking C++ programs

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 412989.
yaxunl added a comment.

add more tests


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

https://reviews.llvm.org/D120911

Files:
  clang/include/clang/Driver/Action.h
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/hip-phases.hip

Index: clang/test/Driver/hip-phases.hip
===
--- clang/test/Driver/hip-phases.hip
+++ clang/test/Driver/hip-phases.hip
@@ -459,17 +459,65 @@
 // Test mixed HIP and C++ compilation. HIP program should have HIP offload kind.
 // C++ program should have no offload kind.
 
+// Test compile empty.hip and empty.cpp.
 // RUN: %clang -target x86_64-unknown-linux-gnu \
 // RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
 // RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED %s
-
 // RUN: %clang -target x86_64-unknown-linux-gnu \
 // RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
 // RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED-NEG %s
 
+// Test compile and link empty.hip and empty.cpp.
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED %s
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED-NEG %s
+
+// Test compile and link empty.hip and empty.cpp with --hip-link -fgpu-rdc.
+// RUN: %clang -target x86_64-unknown-linux-gnu --hip-link -fgpu-rdc \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED %s
+// RUN: %clang -target x86_64-unknown-linux-gnu --hip-link -fgpu-rdc \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED-NEG %s
+
+// Test compile and link -x hip empty.hip and -x c++ empty.cpp.
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -x hip %S/Inputs/empty.hip -x c++ %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED %s
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -x hip %S/Inputs/empty.hip -x c++ %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED-NEG %s
+
+// Test compile and link -x hip empty.hip and empty.cpp.
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -x hip %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED2 %s
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -x hip %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED2-NEG %s
+
+// Test compile and link empty.hip and -x hip empty.cpp.
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: %S/Inputs/empty.hip -x hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED2 %s
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -x hip %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED2-NEG %s
+
 // MIXED-DAG: input, "{{.*}}empty.hip", hip, (host-hip)
 // MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx803)
 // MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx900)
 // MIXED-DAG: input, "{{.*}}empty.cpp", c++
 // MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (host-hip)
 // MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (device-hip
+
+// MIXED2-DAG: input, "{{.*}}empty.hip", hip, (host-hip)
+// MIXED2-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx803)
+// MIXED2-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx900)
+// MIXED2-DAG: input, "{{.*}}empty.cpp", hip, (host-hip)
+// MIXED2-DAG: input, "{{.*}}empty.cpp", hip, (device-hip, gfx803)
+// MIXED2-DAG: input, "{{.*}}empty.cpp", hip, (device-hip, gfx900)
+// MIXED2-NEG-NOT: input, "{{.*}}empty.cpp", c++
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -2465,6 +2465,9 @@
   /// Map between an input argument and the offload kinds used to process it.
   std::map InputArgToOffloadKindMap;
 
+  /// Map between a host action and its originating input argument.
+  std::map HostActionToInputArgMap;
+
   /// Builder interface. It doesn't build anything

[PATCH] D120992: [analyzer] ReverseNull: New checker to warn for pointer value conditions, if the pointer value is unconditionally non-null

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus created this revision.
Szelethus added reviewers: NoQ, steakhal, xazax.hun, balazske, martong.
Szelethus added a project: clang.
Herald added subscribers: manas, ASDenysPetrov, gamesh411, dkrupp, donat.nagy, 
mikhail.ramalho, a.sidorin, rnkovacs, szepet, baloghadamsoftware, mgorny.
Herald added a project: All.
Szelethus requested review of this revision.
Herald added a subscriber: cfe-commits.

Loosely tied to EXP34-C.

Suppose we do a pointer operation, such as dereferencing, or passing it to a 
function whose parameter is attributed with non null (like `_Nonnull` or 
`clang::nonnull`). Then, we write an if branch whose condition is this very 
pointer.

  void tp1(int *p) {
*p = 5;
// expected-note@-1{{Pointer assumed non-null here}}
// expected-note@-2{{Consider moving the condition here}}
if (p)
  // expected-note@-1{{Pointer is unconditionally non-null here}}
  // expected-warning@-2{{Pointer is unconditionally non-null here 
[alpha.core.ReverseNull]}}
  return;
  }

This is a sign of code smell: We either inteded to place the condition before 
the operation that already expects the pointer to be non-null, or there are 
some other high level issues in our code. The patch adds a new checker to find 
and warn for similar cases.

One of the fundamental ideas here is that this is an interprocedural checker. 
We want to ensure that the derefence (or similar operation) unconditionally 
leads to the condition without interleaving assignments. This sounds a lot like 
a dataflow analysis! Indeed, it would be great if we had a dataflow framework 
already in the bag, and although there is a work on it (a lot of patches can be 
seen on @ymandel's profile: https://reviews.llvm.org/people/revisions/17749/), 
its not quite there yet.

Another thought could be, that this checker is (somewhat) redundant with 
DeadCodeChecker, because this checker also finds dead code, but restricted to 
pointers. This wasn't a deterrent in developing this alpha checker, because if 
an 'else' branch is not present, the dead code will not be found (despite the 
sode smell being there), and restricting ourselves to pointer analysis takes a 
lot of weight off from our constraint solvers.

I've ran the checker on a lot of projects, and the results so far look 
promising, and I'm looking forward to publishing them ASAP.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D120992

Files:
  clang/docs/analyzer/checkers.rst
  clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
  clang/lib/StaticAnalyzer/Checkers/AnalysisOrderChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt
  clang/lib/StaticAnalyzer/Checkers/NullPtrInterferenceChecker.cpp
  clang/test/Analysis/NSString.m
  clang/test/Analysis/analyzer-config.c
  clang/test/Analysis/null-pointer-interference.c
  clang/test/Analysis/null-pointer-interference.m

Index: clang/test/Analysis/null-pointer-interference.m
===
--- /dev/null
+++ clang/test/Analysis/null-pointer-interference.m
@@ -0,0 +1,27 @@
+// RUN: %clang_analyze_cc1 -verify %s \
+// RUN:   -triple i386-apple-darwin10 -Wno-objc-root-class -fblocks \
+// RUN:   -analyzer-output=text \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=osx.cocoa.NilArg \
+// RUN:   -analyzer-checker=osx.cocoa.RetainCount \
+// RUN:   -analyzer-checker=alpha.core.ReverseNull
+
+#include "Inputs/system-header-simulator-objc.h"
+
+typedef const struct __CFDictionary * CFDictionaryRef;
+const void *CFDictionaryGetValue(CFDictionaryRef theDict, const void *key);
+
+// From NSString.m:
+NSString* f11(CFDictionaryRef dict, const char* key) {
+  NSString* s = (NSString*) CFDictionaryGetValue(dict, key);
+  // expected-note@-1{{'s' initialized here}}
+  [s retain];
+  // expected-note@-1{{Pointer assumed non-null here}}
+  // expected-note@-2{{Consider moving the condition here}}
+  if (s) {
+// expected-warning@-1{{Pointer is unconditionally non-null here [alpha.core.ReverseNull]}}
+// expected-note@-2{{Pointer is unconditionally non-null here}}
+[s release];
+  }
+  return 0;
+}
Index: clang/test/Analysis/null-pointer-interference.c
===
--- /dev/null
+++ clang/test/Analysis/null-pointer-interference.c
@@ -0,0 +1,92 @@
+// RUN: %clang_analyze_cc1 -verify %s -analyzer-output=text\
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=apiModeling \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -analyzer-checker=alpha.core.ReverseNull \
+// RUN:   -analyzer-config apiModeling.StdCLibraryFunctions:ModelPOSIX=true \
+// RUN:   -analyzer-config apiModeling.StdCLibraryFunctions:DisplayLoadedSummaries=true \
+// RUN:   2>&1 | FileCheck %s
+
+void clang_analyzer_warnIfReached();
+//===--===//
+// True positive test cases.
+//===-

[PATCH] D120888: [clang] Stop dragging a EndLoc around when parsing attributes

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Thank you for working on this! We've (very) slowly been working towards all of 
the attribute parsing functions taking a `ParsedAttributesWithRange` so that we 
don't lose this information in the AST, and this is a good step in the right 
direction towards that.




Comment at: clang/lib/Parse/ParseDecl.cpp:820-821
 T.consumeClose();
-if (End)
-  *End = T.getCloseLocation();
   }

This is a case where we're regressing functionality -- we used to track the 
actual end location here, but because this doesn't take a 
`ParsedAttributesWithRange`, the end location is lost. Can we rework this to 
take a `ParsedAttributesWithRange` instead?



Comment at: clang/lib/Parse/ParseDeclCXX.cpp:4661-4662
   assert(Tok.is(tok::l_square) && "Not a Microsoft attribute list");
+  // FIXME: ParseMicrosoftAttributes() does not support
+  // ParsedAttributesWithRange.
 

Heh, same concern here as above.



Comment at: clang/lib/Parse/ParseStmt.cpp:1122
   ParsedAttributesWithRange attrs(AttrFactory);
-  MaybeParseCXX11Attributes(attrs, nullptr,
+  MaybeParseCXX11Attributes(attrs,
 /*MightBeObjCMessageSend*/ true);

It seems like this could be re-flowed to 80-col?


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

https://reviews.llvm.org/D120888

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

[PATCH] D118869: [clang-format] Non-latin comment prefix whitespace

[Krasimir Georgiev via Phabricator via cfe-commits]

krasimir added a comment.

Thank you!
Turns out the original source wasn't using an ascii space for the comment 
indentation but a unicode [c2 a0] no-break space:

  2f 2f c2 a0 43 6f 6d 6d  65 6e 74 0a 69 6e 74 20  |//..Comment.int |

IMO we shouldn't aim to handle non-ascii spaces for indentation in 
clang-format; the new behavior on this example is fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118869

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

[PATCH] D120992: [analyzer] ReverseNull: New checker to warn for pointer value conditions, if the pointer value is unconditionally non-null

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

In addition to the excellent summary, I'd like to highlight that this is 
intended to catch only the cases where the use of the constrained pointer is in 
the very same stack frame where it was constrained. This leads to a really nice 
property: local reasoning, which greatly reduces the number of false-positives.

This should be emphasized in the doc segment of the checker as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120992

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

[PATCH] D120888: [clang] Stop dragging a EndLoc around when parsing attributes

[Timm Bäder via Phabricator via cfe-commits]

tbaeder marked an inline comment as done.
tbaeder added a comment.

In D120888#3359798 , @aaron.ballman 
wrote:

> Thank you for working on this! We've (very) slowly been working towards all 
> of the attribute parsing functions taking a `ParsedAttributesWithRange` so 
> that we don't lose this information in the AST, and this is a good step in 
> the right direction towards that.

Yes, that's what I'm working on. There is a very peculiar test failure in 
`clang/test/SemaOpenCL/address-spaces.cl` however, so I can't switch everything 
over to `ParsedAttributesWithRange` (and do a rename) at once.




Comment at: clang/lib/Parse/ParseDecl.cpp:820-821
 T.consumeClose();
-if (End)
-  *End = T.getCloseLocation();
   }

aaron.ballman wrote:
> This is a case where we're regressing functionality -- we used to track the 
> actual end location here, but because this doesn't take a 
> `ParsedAttributesWithRange`, the end location is lost. Can we rework this to 
> take a `ParsedAttributesWithRange` instead?
Pretty sure yes. I already have that change locally anyway, I'll add it to this 
patch and run the tests.



Comment at: clang/lib/Parse/ParseDeclCXX.cpp:4661-4662
   assert(Tok.is(tok::l_square) && "Not a Microsoft attribute list");
+  // FIXME: ParseMicrosoftAttributes() does not support
+  // ParsedAttributesWithRange.
 

aaron.ballman wrote:
> Heh, same concern here as above.
Also same as above :)


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

https://reviews.llvm.org/D120888

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

[PATCH] D120888: [clang] Stop dragging a EndLoc around when parsing attributes

[Timm Bäder via Phabricator via cfe-commits]

tbaeder updated this revision to Diff 412994.
tbaeder marked an inline comment as done.

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

https://reviews.llvm.org/D120888

Files:
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/DeclSpec.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Parse/ParseTentative.cpp

Index: clang/lib/Parse/ParseTentative.cpp
===
--- clang/lib/Parse/ParseTentative.cpp
+++ clang/lib/Parse/ParseTentative.cpp
@@ -1913,7 +1913,7 @@
   /*OuterMightBeMessageSend*/true))
   return TPResult::True;
 
-ParsedAttributes attrs(AttrFactory);
+ParsedAttributesWithRange attrs(AttrFactory);
 MaybeParseMicrosoftAttributes(attrs);
 
 // decl-specifier-seq
Index: clang/lib/Parse/ParseStmt.cpp
===
--- clang/lib/Parse/ParseStmt.cpp
+++ clang/lib/Parse/ParseStmt.cpp
@@ -106,7 +106,7 @@
   // at the start of the statement. Thus, we're not using MaybeParseAttributes
   // here because we don't want to allow arbitrary orderings.
   ParsedAttributesWithRange Attrs(AttrFactory);
-  MaybeParseCXX11Attributes(Attrs, nullptr, /*MightBeObjCMessageSend*/ true);
+  MaybeParseCXX11Attributes(Attrs, /*MightBeObjCMessageSend*/ true);
   if (getLangOpts().OpenCL)
 MaybeParseGNUAttributes(Attrs);
 
@@ -1119,7 +1119,7 @@
 ConsumeToken();
 
   ParsedAttributesWithRange attrs(AttrFactory);
-  MaybeParseCXX11Attributes(attrs, nullptr,
+  MaybeParseCXX11Attributes(attrs,
 /*MightBeObjCMessageSend*/ true);
 
   // If this is the start of a declaration, parse it as such.
Index: clang/lib/Parse/ParsePragma.cpp
===
--- clang/lib/Parse/ParsePragma.cpp
+++ clang/lib/Parse/ParsePragma.cpp
@@ -341,7 +341,7 @@
 Token &FirstToken) override;
 
   /// A pool of attributes that were parsed in \#pragma clang attribute.
-  ParsedAttributes AttributesForPragmaAttribute;
+  ParsedAttributesWithRange AttributesForPragmaAttribute;
 };
 
 struct PragmaMaxTokensHereHandler : public PragmaHandler {
@@ -1365,12 +1365,12 @@
 namespace {
 struct PragmaAttributeInfo {
   enum ActionType { Push, Pop, Attribute };
-  ParsedAttributes &Attributes;
+  ParsedAttributesWithRange &Attributes;
   ActionType Action;
   const IdentifierInfo *Namespace = nullptr;
   ArrayRef Tokens;
 
-  PragmaAttributeInfo(ParsedAttributes &Attributes) : Attributes(Attributes) {}
+  PragmaAttributeInfo(ParsedAttributesWithRange &Attributes) : Attributes(Attributes) {}
 };
 
 #include "clang/Parse/AttrSubMatchRulesParserStringSwitches.inc"
@@ -1640,7 +1640,7 @@
   /*IsReinject=*/false);
   ConsumeAnnotationToken();
 
-  ParsedAttributes &Attrs = Info->Attributes;
+  ParsedAttributesWithRange &Attrs = Info->Attributes;
   Attrs.clearListOnly();
 
   auto SkipToEnd = [this]() {
Index: clang/lib/Parse/ParseExprCXX.cpp
===
--- clang/lib/Parse/ParseExprCXX.cpp
+++ clang/lib/Parse/ParseExprCXX.cpp
@@ -1252,7 +1252,7 @@
   TemplateParameterDepthRAII CurTemplateDepthTracker(TemplateParameterDepth);
   Actions.PushLambdaScope();
 
-  ParsedAttributes Attr(AttrFactory);
+  ParsedAttributesWithRange Attr(AttrFactory);
   if (getLangOpts().CUDA) {
 // In CUDA code, GNU attributes are allowed to appear immediately after the
 // "[...]", even if there is no "(...)" before the lambda body.
@@ -1355,7 +1355,8 @@
   DeclEndLoc = ESpecRange.getEnd();
 
 // Parse attribute-specifier[opt].
-MaybeParseCXX11Attributes(Attr, &DeclEndLoc);
+if (MaybeParseCXX11Attributes(Attr))
+  DeclEndLoc = Attr.Range.getEnd();
 
 // Parse OpenCL addr space attribute.
 if (Tok.isOneOf(tok::kw___private, tok::kw___global, tok::kw___local,
Index: clang/lib/Parse/ParseDeclCXX.cpp
===
--- clang/lib/Parse/ParseDeclCXX.cpp
+++ clang/lib/Parse/ParseDeclCXX.cpp
@@ -4513,19 +4513,17 @@
 ///
 /// attribute-specifier-seq:
 ///   attribute-specifier-seq[opt] attribute-specifier
-void Parser::ParseCXX11Attributes(ParsedAttributesWithRange &attrs,
-  SourceLocation *endLoc) {
+void Parser::ParseCXX11Attributes(ParsedAttributesWithRange &attrs) {
   assert(standardAttributesAllowed());
 
-  SourceLocation StartLoc = Tok.getLocation(), Loc;
-  if (!endLoc)
-endLoc = &Loc;
+  SourceLocation StartLoc = Tok.getLocation();
+  SourceLocation EndLoc = StartLoc;
 
   do {
-ParseCXX11AttributeSpecifier(attrs, endLoc);
+ParseCXX11AttributeSpecifier(attrs, &EndLoc);
   } while (isCXX11AttributeSpecifier(

[PATCH] D120992: [analyzer] ReverseNull: New checker to warn for pointer value conditions, if the pointer value is unconditionally non-null

[Balázs Benics via Phabricator via cfe-commits]

steakhal added a comment.

Looks great. I'm loving it!
BTW what is the semantics of `[p retain]` in ObjC? Can `p` be null in that 
context? Or does it count as a dereferences, hence it constraints the pointer?

Why did you touch the `AnalysisOrderChecker`, should we separate those changes?

Additionally, why do you think it needs to be in the `alpha.core` package 
instead of the `core`?
What sort of false-positives have you seen in the wild justifying that 
classification?




Comment at: clang/docs/analyzer/checkers.rst:1703
+alpha.core.ReverseNull (C)
+"
+Checks whether a dereferenced (and as such, assumed to be non-null) pointer is





Comment at: 
clang/lib/StaticAnalyzer/Checkers/NullPtrInterferenceChecker.cpp:196-198
+const MemRegion *MR = Cond->getAsRegion();
+if (!MR)
+  return;

I think additionally to this, you should also check for the type of the 
`Condition` expression. It's gotta be a pointer.



Comment at: 
clang/lib/StaticAnalyzer/Checkers/NullPtrInterferenceChecker.cpp:211-216
+  // We want to be sure that the constraint and the condition are in the
+  // same stackframe. Caller and callee functions' pre/post conditions may
+  // not apply to the caller stackframe. A similar issue is discussed here:
+  // 
https://discourse.llvm.org/t/static-analyzer-query-why-is-suppress-null-return-paths-enabled-by-default/
+  if (NBeforeConstraint->getLocationContext() != Ctx.getLocationContext())
+return;

IMO we should catch these as well:
```lang=C++
void store(int *q, int value) {
  *q = value;
}

void top(int *p) {
  store(p, 5);
  if (!p)
return;
}
```

In this case, the stack-frame in which the pointer gets constrained is not the 
same as where the redundant check resides - rather a child frame of that.



Comment at: clang/test/Analysis/null-pointer-interference.c:18
+  // expected-note@-1{{Pointer assumed non-null here}}
+  // expected-note@-2{{Consider moving the condition here}}
+  if (p)

"before this expression"?
The term `here` is not well defined IMO.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120992

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

[PATCH] D120272: [CUDA] Add driver support for compiling CUDA with the new driver

[Joseph Huber via Phabricator via cfe-commits]

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

Fix


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120272

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/cuda-openmp-driver.cu

Index: clang/test/Driver/cuda-openmp-driver.cu
===
--- /dev/null
+++ clang/test/Driver/cuda-openmp-driver.cu
@@ -0,0 +1,16 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// RUN: %clang -### -target x86_64-linux-gnu -nocudalib -ccc-print-bindings -fgpu-rdc \
+// RUN:-foffload-new-driver --offload-arch=sm_35 --offload-arch=sm_70 %s 2>&1 \
+// RUN: | FileCheck -check-prefix CHECK %s
+
+// CHECK: "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT:.+]]"], output: "[[PTX_SM_35:.+]]"
+// CHECK: "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: ["[[PTX_SM_35]]"], output: "[[CUBIN_SM_35:.+]]"
+// CHECK: "nvptx64-nvidia-cuda" - "NVPTX::Linker", inputs: ["[[CUBIN_SM_35]]", "[[PTX_SM_35]]"], output: "[[FATBIN_SM_35:.+]]"
+// CHECK: "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT]]"], output: "[[PTX_SM_70:.+]]"
+// CHECK: "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: ["[[PTX_SM_70:.+]]"], output: "[[CUBIN_SM_70:.+]]"
+// CHECK: "nvptx64-nvidia-cuda" - "NVPTX::Linker", inputs: ["[[CUBIN_SM_70]]", "[[PTX_SM_70:.+]]"], output: "[[FATBIN_SM_70:.+]]"
+// CHECK: "x86_64-unknown-linux-gnu" - "clang", inputs: ["[[INPUT]]", "[[FATBIN_SM_35]]", "[[FATBIN_SM_70]]"], output: "[[HOST_OBJ:.+]]"
+// CHECK: "x86_64-unknown-linux-gnu" - "Offload::Linker", inputs: ["[[HOST_OBJ]]"], output: "a.out"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4391,6 +4391,7 @@
   // one input.
   bool IsCuda = JA.isOffloading(Action::OFK_Cuda);
   bool IsCudaDevice = JA.isDeviceOffloading(Action::OFK_Cuda);
+  bool IsCudaHost = JA.isHostOffloading(Action::OFK_Cuda);
   bool IsHIP = JA.isOffloading(Action::OFK_HIP);
   bool IsHIPDevice = JA.isDeviceOffloading(Action::OFK_HIP);
   bool IsOpenMPDevice = JA.isDeviceOffloading(Action::OFK_OpenMP);
@@ -4414,6 +4415,7 @@
 
   InputInfoList ModuleHeaderInputs;
   InputInfoList OpenMPHostInputs;
+  InputInfoList CudaHostInputs;
   const InputInfo *CudaDeviceInput = nullptr;
   const InputInfo *OpenMPDeviceInput = nullptr;
   for (const InputInfo &I : Inputs) {
@@ -4428,6 +4430,8 @@
 << types::getTypeName(Expected);
   }
   ModuleHeaderInputs.push_back(I);
+} else if (IsCudaHost && Args.hasArg(options::OPT_fopenmp_new_driver)) {
+  CudaHostInputs.push_back(I);
 } else if ((IsCuda || IsHIP) && !CudaDeviceInput) {
   CudaDeviceInput = &I;
 } else if (IsOpenMPDevice && !OpenMPDeviceInput) {
@@ -6957,6 +6961,7 @@
 auto OpenMPTCs = C.getOffloadToolChains();
 for (auto TI = OpenMPTCs.first, TE = OpenMPTCs.second; TI != TE;
  ++TI, ++InputFile) {
+  assert(InputFile->isFilename() && "Offloading requires a filename");
   const ToolChain *TC = TI->second;
   const ArgList &TCArgs = C.getArgsForToolChain(TC, "", Action::OFK_OpenMP);
   StringRef File =
@@ -6969,6 +6974,21 @@
   TC->getTripleString() + "." +
   TCArgs.getLastArgValue(options::OPT_march_EQ) + "." + InputName));
 }
+  } else if (IsCudaHost && !CudaHostInputs.empty()) {
+const ToolChain *TC = C.getSingleOffloadToolChain();
+for (const auto &InputFile : CudaHostInputs) {
+  assert(InputFile.isFilename() && "Offloading requires a filename");
+  StringRef File =
+  C.getArgs().MakeArgString(TC->getInputFilename(InputFile));
+  StringRef InputName = Clang::getBaseInputStem(Args, Inputs);
+  // The CUDA toolchain should have a bound arch appended to the filename.
+  StringRef Arch = File.split(".").first.rsplit('-').second;
+  CmdArgs.push_back(Args.MakeArgString(
+  "-fembed-offload-object=" + File + "," +
+  Action::GetOffloadKindName(Action::OFK_Cuda) + "." +
+  TC->getTripleString() + "." +
+  Arch + "." + InputName));
+}
   }
 
   if (Triple.isAMDGPU()) {
@@ -8220,14 +8240,17 @@
   ArgStringList CmdArgs;
 
   // Pass the CUDA path to the linker wrapper tool.
-  for (auto &I : llvm::make_range(OpenMPTCRange.first, OpenMPTCRange.second)) {
-const ToolChain *TC = I.second;
-if (TC->getTriple().isNVPTX()) {
-  CudaInstallationDetector CudaInstallation(D, TheTriple, Args);
-  if (CudaInstallation.isValid())
-CmdArgs.push_back(Args.MakeArgString(
-"--cuda-path=" + CudaInstallation.getInstallPath()));
-  break;
+  for (Action::OffloadKind Kind : {A

[PATCH] D120323: [clang][SVE] Add support for arithmetic operators on SVE types

[Bradley Smith via Phabricator via cfe-commits]

bsmith added a comment.
Herald added a project: All.

This all looks reasonable to me, but I'll let @peterwaller-arm have the final 
say.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120323

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

[PATCH] D119184: [clang] [concepts] Check constrained-auto return types for void-returning functions

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone updated this revision to Diff 413006.
Quuxplusone added a comment.
Herald added a project: All.

Rebased, poke CI one last time.
If this is green, imma land it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119184

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/test/SemaTemplate/concepts.cpp

Index: clang/test/SemaTemplate/concepts.cpp
===
--- clang/test/SemaTemplate/concepts.cpp
+++ clang/test/SemaTemplate/concepts.cpp
@@ -169,3 +169,42 @@
   template void f(T, U) = delete;
   void g() { f(0, 0); }
 }
+
+namespace PR49188 {
+  template concept C = false; // expected-note 6 {{because 'false' evaluated to false}}
+
+  C auto f1() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return void();
+  }
+  C auto f2() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return;
+  }
+  C auto f3() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  }
+  C decltype(auto) f4() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return void();
+  }
+  C decltype(auto) f5() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return;
+  }
+  C decltype(auto) f6() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  }
+  C auto& f7() { // expected-error {{cannot form a reference to 'void'}}
+return void();
+  }
+  C auto& f8() {
+return; // expected-error {{cannot deduce return type 'C auto &' from omitted return expression}}
+  }
+  C auto& f9() { // expected-error {{cannot deduce return type 'C auto &' for function with no return statements}}
+  }
+}
+namespace PR53911 {
+  template concept C = false;
+
+  C auto *f1() {
+return (void*)nullptr; // FIXME: should error
+  }
+  C auto *f2() {
+return (int*)nullptr; // FIXME: should error
+  }
+}
Index: clang/lib/Sema/SemaStmt.cpp
===
--- clang/lib/Sema/SemaStmt.cpp
+++ clang/lib/Sema/SemaStmt.cpp
@@ -3762,8 +3762,8 @@
 bool Sema::DeduceFunctionTypeFromReturnExpr(FunctionDecl *FD,
 SourceLocation ReturnLoc,
 Expr *&RetExpr,
-AutoType *AT) {
-  // If this is the conversion function for a lambda, we choose to deduce it
+const AutoType *AT) {
+  // If this is the conversion function for a lambda, we choose to deduce its
   // type from the corresponding call operator, not from the synthesized return
   // statement within it. See Sema::DeduceReturnType.
   if (isLambdaConversionOperator(FD))
@@ -3808,19 +3808,26 @@
 LocalTypedefNameReferencer Referencer(*this);
 Referencer.TraverseType(RetExpr->getType());
   } else {
-//  In the case of a return with no operand, the initializer is considered
-//  to be void().
-//
-// Deduction here can only succeed if the return type is exactly 'cv auto'
-// or 'decltype(auto)', so just check for that case directly.
+// For a function with a deduced result type to return void,
+// the result type as written must be 'auto' or 'decltype(auto)',
+// possibly cv-qualified or constrained, but not ref-qualified.
 if (!OrigResultType.getType()->getAs()) {
   Diag(ReturnLoc, diag::err_auto_fn_return_void_but_not_auto)
 << OrigResultType.getType();
   return true;
 }
-// We always deduce U = void in this case.
-Deduced = SubstAutoType(OrigResultType.getType(), Context.VoidTy);
-if (Deduced.isNull())
+// In the case of a return with no operand, the initializer is considered
+// to be 'void()'.
+Expr *Dummy = new (Context) CXXScalarValueInitExpr(
+Context.VoidTy,
+Context.getTrivialTypeSourceInfo(Context.VoidTy, ReturnLoc), ReturnLoc);
+DeduceAutoResult DAR = DeduceAutoType(OrigResultType, Dummy, Deduced);
+
+if (DAR == DAR_Failed && !FD->isInvalidDecl())
+  Diag(ReturnLoc, diag::err_auto_fn_deduction_failure)
+  << OrigResultType.getType() << Dummy->getType();
+
+if (DAR != DAR_Succeeded)
   return true;
   }
 
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -14674,18 +14674,20 @@
   if (getLangOpts().CPlusPlus14) {
 if (!FD->isInvalidDecl() && Body && !FD->isDependentContext() &&
 FD->getReturnType()->isUndeducedType()) {
-  // If the function has a deduced result type but contains no 'return'
-  // statements, the result type as written must be exactly 'auto', and
-  // the deduced result type is 'void'.
+  // For a function with a deduced result type to return v

[clang-tools-extra] e86324f - [clang-tidy][NFC] Document bugprone-narrowing-conversions check alias

[Balazs Benics via cfe-commits]

Author: Balazs Benics
Date: 2022-03-04T16:47:11+01:00
New Revision: e86324f80031fb5596f9f7437cb8c0b24fcf3143

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

LOG: [clang-tidy][NFC] Document bugprone-narrowing-conversions check alias

Added: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-narrowing-conversions.rst

Modified: 
clang-tools-extra/docs/clang-tidy/checks/list.rst

Removed: 




diff  --git 
a/clang-tools-extra/docs/clang-tidy/checks/bugprone-narrowing-conversions.rst 
b/clang-tools-extra/docs/clang-tidy/checks/bugprone-narrowing-conversions.rst
new file mode 100644
index 0..85867273aaa6a
--- /dev/null
+++ 
b/clang-tools-extra/docs/clang-tidy/checks/bugprone-narrowing-conversions.rst
@@ -0,0 +1,10 @@
+.. title:: clang-tidy - bugprone-narrowing-conversions
+.. meta::
+   :http-equiv=refresh: 5;URL=cppcoreguidelines-narrowing-conversions.html
+
+bugprone-narrowing-conversions
+==
+
+The bugprone-narrowing-conversions check is an alias, please see
+`cppcoreguidelines-narrowing-conversions 
`_
+for more information.

diff  --git a/clang-tools-extra/docs/clang-tidy/checks/list.rst 
b/clang-tools-extra/docs/clang-tidy/checks/list.rst
index a67de1c4788f9..f2b361e2aecbc 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -336,6 +336,7 @@ Clang-Tidy Checks
 .. csv-table:: Aliases..
:header: "Name", "Redirect", "Offers fixes"
 
+   `bugprone-narrowing-conversions `_, 
`cppcoreguidelines-narrowing-conversions 
`_,
`cert-con36-c `_, `bugprone-spuriously-wake-up-functions 
`_,
`cert-con54-cpp `_, 
`bugprone-spuriously-wake-up-functions 
`_,
`cert-dcl03-c `_, `misc-static-assert 
`_, "Yes"



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

[PATCH] D120449: [RISCV][RVV] Add strict vfcvt intrinsics that have side effects for dynamically-set rounding mode

[Zakk Chen via Phabricator via cfe-commits]

khchen added a comment.

Makes sense to me, but I'd appreciate someone else for a final LGTM.




Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:4683
+Ops.push_back(VL);
+Ops.push_back(DAG.getUNDEF(XLenVT)); // Policy
+  }

arcbbb wrote:
> kito-cheng wrote:
> > Is this operand for tail policy? if so why this is `UNDEF`? I guess this 
> > should be `TAIL_AGNOSTIC` rather than `UNDEF`?
> Because unmasked pseudos doesn't have a policy operand,
> TA/TU is distinguished by checking if passthru is undef. I think it is proper 
> to leave undef here.
nit: maybe we could add a comment for that, because it must be `UNDEF` to match 
unmaksed pattern successfully.



Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:4678
+MVT MaskVT = MVT::getVectorVT(MVT::i1, VT.getVectorElementCount());
+SDValue Mask = DAG.getNode(RISCVISD::VMSET_VL, DL, MaskVT, VL);
+Ops.push_back(Mask);

I think `TrueMask` maybe better.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoVVLPatterns.td:619
+  VReg result_reg_class,
+  VReg op2_reg_class
+  > {

--> `VReg op2_reg_class> {`



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoVVLPatterns.td:649
+defvar ivti = GetIntVTypeInfo.Vti;
+
+defm : VPatConvertStrictSDNode_VLhttps://reviews.llvm.org/D120449/new/

https://reviews.llvm.org/D120449

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

[clang] 7ee97c2 - [clang][dataflow] Add a lattice to track source locations.

[Yitzhak Mandelbaum via cfe-commits]

Author: Yitzhak Mandelbaum
Date: 2022-03-04T17:13:24Z
New Revision: 7ee97c24efab4b2617da7f188760b0ad2dcc2125

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

LOG: [clang][dataflow] Add a lattice to track source locations.

This patch adds a simpe lattice used to collect source loctions. An intended 
application is to track errors found in code during an analysis.

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

Added: 
clang/include/clang/Analysis/FlowSensitive/SourceLocationsLattice.h
clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp
clang/unittests/Analysis/FlowSensitive/SourceLocationsLatticeTest.cpp

Modified: 
clang/lib/Analysis/FlowSensitive/CMakeLists.txt
clang/unittests/Analysis/FlowSensitive/CMakeLists.txt

Removed: 




diff  --git 
a/clang/include/clang/Analysis/FlowSensitive/SourceLocationsLattice.h 
b/clang/include/clang/Analysis/FlowSensitive/SourceLocationsLattice.h
new file mode 100644
index 0..d294f9768cdc5
--- /dev/null
+++ b/clang/include/clang/Analysis/FlowSensitive/SourceLocationsLattice.h
@@ -0,0 +1,65 @@
+//===-- SourceLocationsLattice.h *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//  This file defines a lattice that collects source locations of interest.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_SOURCELOCATIONS_LATTICE_H
+#define LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_SOURCELOCATIONS_LATTICE_H
+
+#include "clang/AST/ASTContext.h"
+#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Basic/SourceLocation.h"
+#include "llvm/ADT/DenseSet.h"
+#include 
+#include 
+
+namespace clang {
+namespace dataflow {
+
+/// Lattice for dataflow analysis that keeps track of a set of source 
locations.
+///
+/// Bottom is the empty set, join is set union, and equality is set equality.
+///
+/// FIXME: Generalize into a (templated) PowerSetLattice.
+class SourceLocationsLattice {
+public:
+  SourceLocationsLattice() = default;
+
+  explicit SourceLocationsLattice(llvm::DenseSet Locs)
+  : Locs(std::move(Locs)) {}
+
+  bool operator==(const SourceLocationsLattice &Other) const {
+return Locs == Other.Locs;
+  }
+
+  bool operator!=(const SourceLocationsLattice &Other) const {
+return !(*this == Other);
+  }
+
+  LatticeJoinEffect join(const SourceLocationsLattice &Other);
+
+  llvm::DenseSet &getSourceLocations() { return Locs; }
+
+  const llvm::DenseSet &getSourceLocations() const {
+return Locs;
+  }
+
+private:
+  llvm::DenseSet Locs;
+};
+
+/// Returns a string that represents the source locations of the lattice.
+std::string DebugString(const SourceLocationsLattice &Lattice,
+const ASTContext &Context);
+
+} // namespace dataflow
+} // namespace clang
+
+#endif // LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_SOURCELOCATIONS_LATTICE_H

diff  --git a/clang/lib/Analysis/FlowSensitive/CMakeLists.txt 
b/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
index 933792d569799..cfe3c8e77b4fd 100644
--- a/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
+++ b/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
@@ -2,6 +2,7 @@ add_clang_library(clangAnalysisFlowSensitive
   ControlFlowContext.cpp
   DataflowAnalysisContext.cpp
   DataflowEnvironment.cpp
+  SourceLocationsLattice.cpp
   Transfer.cpp
   TypeErasedDataflowAnalysis.cpp
   WatchedLiteralsSolver.cpp
@@ -9,4 +10,5 @@ add_clang_library(clangAnalysisFlowSensitive
   LINK_LIBS
   clangAnalysis
   clangAST
+  clangBasic
   )

diff  --git a/clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp 
b/clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp
new file mode 100644
index 0..9e280f4e634a1
--- /dev/null
+++ b/clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp
@@ -0,0 +1,51 @@
+//===- SourceLocationsLattice.cpp 
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//  This file implements a lattice that collects source locations of interest.
+//
+//===--===//
+
+#include "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
+#include "clang/AST/ASTContext.h"
+#inclu

[PATCH] D120890: [clang][dataflow] Add a lattice to track source locations.

[Yitzhak Mandelbaum 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 rG7ee97c24efab: [clang][dataflow] Add a lattice to track 
source locations. (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120890

Files:
  clang/include/clang/Analysis/FlowSensitive/SourceLocationsLattice.h
  clang/lib/Analysis/FlowSensitive/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp
  clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/SourceLocationsLatticeTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/SourceLocationsLatticeTest.cpp
===
--- /dev/null
+++ clang/unittests/Analysis/FlowSensitive/SourceLocationsLatticeTest.cpp
@@ -0,0 +1,68 @@
+//===- unittests/Analysis/FlowSensitive/SourceLocationsLatticeTest.cpp ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
+
+#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Basic/SourceLocation.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace dataflow {
+namespace {
+
+TEST(SourceLocationsLatticeTest, Comparison) {
+  const SourceLocationsLattice Bottom;
+  const SourceLocationsLattice NonBottom(
+  {SourceLocation::getFromRawEncoding(0)});
+
+  EXPECT_TRUE(Bottom == Bottom);
+  EXPECT_FALSE(Bottom == NonBottom);
+  EXPECT_FALSE(NonBottom == Bottom);
+  EXPECT_TRUE(NonBottom == NonBottom);
+
+  EXPECT_FALSE(Bottom != Bottom);
+  EXPECT_TRUE(Bottom != NonBottom);
+  EXPECT_TRUE(NonBottom != Bottom);
+  EXPECT_FALSE(NonBottom != NonBottom);
+}
+
+TEST(SourceLocationsLatticeTest, Join) {
+  const SourceLocationsLattice Bottom;
+  const SourceLocationsLattice NonBottom(
+  {SourceLocation::getFromRawEncoding(0)});
+  {
+SourceLocationsLattice LHS = Bottom;
+const SourceLocationsLattice RHS = Bottom;
+EXPECT_EQ(LHS.join(RHS), LatticeJoinEffect::Unchanged);
+EXPECT_EQ(LHS, Bottom);
+  }
+  {
+SourceLocationsLattice LHS = NonBottom;
+const SourceLocationsLattice RHS = Bottom;
+EXPECT_EQ(LHS.join(RHS), LatticeJoinEffect::Unchanged);
+EXPECT_EQ(LHS, NonBottom);
+  }
+  {
+SourceLocationsLattice LHS = Bottom;
+const SourceLocationsLattice RHS = NonBottom;
+EXPECT_EQ(LHS.join(RHS), LatticeJoinEffect::Changed);
+EXPECT_EQ(LHS, NonBottom);
+  }
+  {
+SourceLocationsLattice LHS = NonBottom;
+const SourceLocationsLattice RHS = NonBottom;
+EXPECT_EQ(LHS.join(RHS), LatticeJoinEffect::Unchanged);
+EXPECT_EQ(LHS, NonBottom);
+  }
+}
+
+} // namespace
+} // namespace dataflow
+} // namespace clang
Index: clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
===
--- clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
+++ clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
@@ -9,6 +9,7 @@
   MapLatticeTest.cpp
   MultiVarConstantPropagationTest.cpp
   SingleVarConstantPropagationTest.cpp
+  SourceLocationsLatticeTest.cpp
   TestingSupport.cpp
   TestingSupportTest.cpp
   TransferTest.cpp
Index: clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp
===
--- /dev/null
+++ clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp
@@ -0,0 +1,51 @@
+//===- SourceLocationsLattice.cpp -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//  This file implements a lattice that collects source locations of interest.
+//
+//===--===//
+
+#include "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "llvm/ADT/STLExtras.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+#include 
+#include 
+
+namespace clang {
+namespace dataflow {
+
+LatticeJoinEffect
+SourceLocationsLattice::join(const SourceLocationsLattice &Other) {
+  auto SizeBefore = Locs.size();
+  Locs.insert(Other.Locs.begin(), Other.Locs.end());
+  return SizeBefore == Locs.size() ? LatticeJoinEffect::Unchanged
+   : LatticeJoinEffect::Changed;
+}
+
+std::string

[PATCH] D120967: [NFC] Divide tests into smaller files

[Jessica Clarke via Phabricator via cfe-commits]

jrtc27 added a comment.

With one exception, every RISC-V Clang CodeGen test (and with 9 exceptions, 
every RISC-V LLVM CodeGen test) is kebab-case not snake_case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120967

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

[clang] c88deef - [clang][dataflow] Add `MatchSwitch` utility library.

[Yitzhak Mandelbaum via cfe-commits]

Author: Yitzhak Mandelbaum
Date: 2022-03-04T17:19:51Z
New Revision: c88deef0a7218dd5c30500e7d3f58fc23283d3e5

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

LOG: [clang][dataflow] Add `MatchSwitch` utility library.

Adds `MatchSwitch`, a library for simplifying implementation of transfer
functions. `MatchSwitch` supports constructing a "switch" statement, where each
case of the switch is defined by an AST matcher. The cases are considered in
order, like pattern matching in functional languages.

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

Added: 
clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h
clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp

Modified: 
clang/unittests/Analysis/FlowSensitive/CMakeLists.txt

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h 
b/clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h
new file mode 100644
index 0..b319360627911
--- /dev/null
+++ b/clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h
@@ -0,0 +1,153 @@
+//=== MatchSwitch.h -*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//  This file defines the `MatchSwitch` abstraction for building a "switch"
+//  statement, where each case of the switch is defined by an AST matcher. The
+//  cases are considered in order, like pattern matching in functional
+//  languages.
+//
+//  Currently, the design is catered towards simplifying the implementation of
+//  `DataflowAnalysis` transfer functions. Based on experience here, this
+//  library may be generalized and moved to ASTMatchers.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_MATCHSWITCH_H_
+#define LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_MATCHSWITCH_H_
+
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/Stmt.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
+#include "llvm/ADT/StringRef.h"
+#include 
+#include 
+#include 
+#include 
+
+namespace clang {
+namespace dataflow {
+
+/// A common form of state shared between the cases of a transfer function.
+template  struct TransferState {
+  TransferState(LatticeT &Lattice, Environment &Env)
+  : Lattice(Lattice), Env(Env) {}
+
+  /// Current lattice element.
+  LatticeT &Lattice;
+  Environment &Env;
+};
+
+/// Matches against `Stmt` and, based on its structure, dispatches to an
+/// appropriate handler.
+template 
+using MatchSwitch = std::function;
+
+/// Collects cases of a "match switch": a collection of matchers paired with
+/// callbacks, which together define a switch that can be applied to a
+/// `Stmt`. This structure can simplify the definition of `transfer` functions
+/// that rely on pattern-matching.
+///
+/// For example, consider an analysis that handles particular function calls. 
It
+/// can define the `MatchSwitch` once, in the constructor of the analysis, and
+/// then reuse it each time that `transfer` is called, with a fresh state 
value.
+///
+/// \code
+/// MatchSwitch BuildSwitch() {
+///   return MatchSwitchBuilder>()
+/// .CaseOf(callExpr(callee(functionDecl(hasName("foo", 
TransferFooCall)
+/// .CaseOf(callExpr(argumentCountIs(2),
+///  callee(functionDecl(hasName("bar",
+/// TransferBarCall)
+/// .Build();
+/// }
+/// \endcode
+template  class MatchSwitchBuilder {
+public:
+  // An action is triggered by the match of a pattern against the input
+  // statement. For generality, actions take both the matched statement and the
+  // set of bindings produced by the match.
+  using Action = std::function;
+
+  MatchSwitchBuilder &&CaseOf(ast_matchers::internal::Matcher M,
+  Action A) && {
+Matchers.push_back(std::move(M));
+Actions.push_back(std::move(A));
+return std::move(*this);
+  }
+
+  // Convenience function for the common case, where bound nodes are not
+  // needed. `Node` should be a subclass of `Stmt`.
+  template 
+  MatchSwitchBuilder &&CaseOf(ast_matchers::internal::Matcher M,
+  void (*Action)(const Node *, State &)) && {
+Matchers.push_back(std::move(M));
+Actions.push_back([Action](const Stmt *Stmt,
+   const ast_matchers::MatchFinder::MatchResult &,
+   State &S) { Action(cast(Stmt),

[PATCH] D120900: [clang][dataflow] Add `MatchSwitch` utility library.

[Yitzhak Mandelbaum 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 rGc88deef0a721: [clang][dataflow] Add `MatchSwitch` utility 
library. (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120900

Files:
  clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h
  clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
===
--- /dev/null
+++ clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
@@ -0,0 +1,204 @@
+//===- unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp ---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//  This file defines a simplistic version of Constant Propagation as an example
+//  of a forward, monotonic dataflow analysis. The analysis tracks all
+//  variables in the scope, but lacks escape analysis.
+//
+//===--===//
+
+#include "clang/Analysis/FlowSensitive/MatchSwitch.h"
+#include "TestingSupport.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/Expr.h"
+#include "clang/AST/Stmt.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Analysis/FlowSensitive/DataflowAnalysis.h"
+#include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
+#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Analysis/FlowSensitive/MapLattice.h"
+#include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/None.h"
+#include "llvm/ADT/Optional.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/Twine.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Testing/Support/Annotations.h"
+#include "llvm/Testing/Support/Error.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+using namespace clang;
+using namespace dataflow;
+
+namespace {
+using ::testing::Pair;
+using ::testing::UnorderedElementsAre;
+
+class BooleanLattice {
+public:
+  BooleanLattice() : Value(false) {}
+  explicit BooleanLattice(bool B) : Value(B) {}
+
+  static BooleanLattice bottom() { return BooleanLattice(false); }
+
+  static BooleanLattice top() { return BooleanLattice(true); }
+
+  LatticeJoinEffect join(BooleanLattice Other) {
+auto Prev = Value;
+Value = Value || Other.Value;
+return Prev == Value ? LatticeJoinEffect::Unchanged
+ : LatticeJoinEffect::Changed;
+  }
+
+  friend bool operator==(BooleanLattice LHS, BooleanLattice RHS) {
+return LHS.Value == RHS.Value;
+  }
+
+  friend std::ostream &operator<<(std::ostream &Os, const BooleanLattice &B) {
+Os << B.Value;
+return Os;
+  }
+
+  bool value() const { return Value; }
+
+private:
+  bool Value;
+};
+} // namespace
+
+MATCHER_P(Holds, m,
+  ((negation ? "doesn't hold" : "holds") +
+   llvm::StringRef(" a lattice element that ") +
+   ::testing::DescribeMatcher(m, negation))
+  .str()) {
+  return ExplainMatchResult(m, arg.Lattice, result_listener);
+}
+
+void TransferSetTrue(const DeclRefExpr *,
+ TransferState &State) {
+  State.Lattice = BooleanLattice(true);
+}
+
+void TransferSetFalse(const Stmt *,
+  const ast_matchers::MatchFinder::MatchResult &,
+  TransferState &State) {
+  State.Lattice = BooleanLattice(false);
+}
+
+class TestAnalysis : public DataflowAnalysis {
+  MatchSwitch> TransferSwitch;
+
+public:
+  explicit TestAnalysis(ASTContext &Context)
+  : DataflowAnalysis(Context) {
+using namespace ast_matchers;
+TransferSwitch =
+MatchSwitchBuilder>()
+.CaseOf(declRefExpr(to(varDecl(hasName("X", TransferSetTrue)
+.CaseOf(callExpr(callee(functionDecl(hasName("Foo",
+TransferSetFalse)
+.Build();
+  }
+
+  static BooleanLattice initialElement() { return BooleanLattice::bottom(); }
+
+  void transfer(const Stmt *S, BooleanLattice &L, Environment &Env) {
+TransferState State(L, Env);
+TransferSwitch(*S, getASTContext(), State);
+  }
+};
+
+class MatchSwitchTest : public ::testing::Test {
+protected:
+  template 
+  void RunDataflow(llvm::StringRef Code, Matcher Expectations) {
+ASSERT_THAT_ERROR(
+test::checkDataflow(
+Code, "fun",
+[](ASTContext &C, Environment &) { return TestAnalysis(C); },
+[&Expectations](

[PATCH] D112181: [docs] Remove hard-coded version numbers from sphinx configs

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.
Herald added a project: All.

Can we drop the git from everywhere?

F22325692: image.png 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112181

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

[PATCH] D114231: [clang][docs][dataflow] Added an introduction to dataflow analysis

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.
Herald added a project: All.

Did you add somewhere what dependency we need in order to build the 
documentation now as mine is having problems with "recommonmark"

  /usr/bin/sphinx-build -n ./docs ./html
  Running Sphinx v3.4.3
  
  Configuration error:
  There is a programmable error in your configuration file:
  
  Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/sphinx/config.py", line 326, in 
eval_config_file
  execfile_(filename, namespace)
File "/usr/lib/python3.6/site-packages/sphinx/util/pycompat.py", line 88, 
in execfile_
  exec(code, _globals)
File "/buildareas/llvm3/llvm-project/clang/docs/conf.py", line 41, in 

  import recommonmark
  ModuleNotFoundError: No module named 'recommonmark'


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114231

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

[PATCH] D103313: [RISCV][Clang] Implement support for zmmul-experimental

[Craig Topper via Phabricator via cfe-commits]

craig.topper added a comment.

In D103313#3359628 , @ksyx wrote:

> In D103313#3359310 , 
> @JiahaoChenConor wrote:
>
>> Hi, do you still continue working on this patch?
>
> In fact, not pretty sure what else I need to improve on this.

At minimum it probably needs to rebased because RISCVISAInfo.cpp has been added 
to cut down on some duplication.


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

https://reviews.llvm.org/D103313

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

[clang] adf6703 - [clang] [NFC] Add `const` to a parameter that's not modified.

[Arthur O'Dwyer via cfe-commits]

Author: Arthur O'Dwyer
Date: 2022-03-04T12:43:05-05:00
New Revision: adf6703f75b09564ca887b0eea0c3b37e65237d7

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

LOG: [clang] [NFC] Add `const` to a parameter that's not modified.

Reviewed as part of D119184.

Added: 


Modified: 
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaStmt.cpp

Removed: 




diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 9496d72cadcab..d072cf9223f7d 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -8701,7 +8701,7 @@ class Sema final {
 
   bool DeduceFunctionTypeFromReturnExpr(FunctionDecl *FD,
 SourceLocation ReturnLoc,
-Expr *&RetExpr, AutoType *AT);
+Expr *&RetExpr, const AutoType *AT);
 
   FunctionTemplateDecl *getMoreSpecializedTemplate(
   FunctionTemplateDecl *FT1, FunctionTemplateDecl *FT2, SourceLocation Loc,

diff  --git a/clang/lib/Sema/SemaStmt.cpp b/clang/lib/Sema/SemaStmt.cpp
index 6ccef38c2f61d..d51a71ffc7f41 100644
--- a/clang/lib/Sema/SemaStmt.cpp
+++ b/clang/lib/Sema/SemaStmt.cpp
@@ -3762,8 +3762,8 @@ TypeLoc Sema::getReturnTypeLoc(FunctionDecl *FD) const {
 bool Sema::DeduceFunctionTypeFromReturnExpr(FunctionDecl *FD,
 SourceLocation ReturnLoc,
 Expr *&RetExpr,
-AutoType *AT) {
-  // If this is the conversion function for a lambda, we choose to deduce it
+const AutoType *AT) {
+  // If this is the conversion function for a lambda, we choose to deduce its
   // type from the corresponding call operator, not from the synthesized return
   // statement within it. See Sema::DeduceReturnType.
   if (isLambdaConversionOperator(FD))



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

[clang] f0891cd - [clang] [concepts] Check constrained-auto return types for void-returning functions

[Arthur O'Dwyer via cfe-commits]

Author: Arthur O'Dwyer
Date: 2022-03-04T12:43:06-05:00
New Revision: f0891cd61b2f7cd57d906406ae785722bfd87603

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

LOG: [clang] [concepts] Check constrained-auto return types for void-returning 
functions

Fixes #49188.

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

Added: 


Modified: 
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaStmt.cpp
clang/test/SemaTemplate/concepts.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 7d9d5ec87948e..b88d9f2f847fd 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -14674,18 +14674,20 @@ Decl *Sema::ActOnFinishFunctionBody(Decl *dcl, Stmt 
*Body,
   if (getLangOpts().CPlusPlus14) {
 if (!FD->isInvalidDecl() && Body && !FD->isDependentContext() &&
 FD->getReturnType()->isUndeducedType()) {
-  // If the function has a deduced result type but contains no 'return'
-  // statements, the result type as written must be exactly 'auto', and
-  // the deduced result type is 'void'.
+  // For a function with a deduced result type to return void,
+  // the result type as written must be 'auto' or 'decltype(auto)',
+  // possibly cv-qualified or constrained, but not ref-qualified.
   if (!FD->getReturnType()->getAs()) {
 Diag(dcl->getLocation(), diag::err_auto_fn_no_return_but_not_auto)
 << FD->getReturnType();
 FD->setInvalidDecl();
   } else {
-// Substitute 'void' for the 'auto' in the type.
-TypeLoc ResultType = getReturnTypeLoc(FD);
-Context.adjustDeducedFunctionResultType(
-FD, SubstAutoType(ResultType.getType(), Context.VoidTy));
+// Falling off the end of the function is the same as 'return;'.
+Expr *Dummy = nullptr;
+if (DeduceFunctionTypeFromReturnExpr(
+FD, dcl->getLocation(), Dummy,
+FD->getReturnType()->getAs()))
+  FD->setInvalidDecl();
   }
 }
   } else if (getLangOpts().CPlusPlus11 && isLambdaCallOperator(FD)) {

diff  --git a/clang/lib/Sema/SemaStmt.cpp b/clang/lib/Sema/SemaStmt.cpp
index d51a71ffc7f41..e23fd23019998 100644
--- a/clang/lib/Sema/SemaStmt.cpp
+++ b/clang/lib/Sema/SemaStmt.cpp
@@ -3808,19 +3808,26 @@ bool 
Sema::DeduceFunctionTypeFromReturnExpr(FunctionDecl *FD,
 LocalTypedefNameReferencer Referencer(*this);
 Referencer.TraverseType(RetExpr->getType());
   } else {
-//  In the case of a return with no operand, the initializer is considered
-//  to be void().
-//
-// Deduction here can only succeed if the return type is exactly 'cv auto'
-// or 'decltype(auto)', so just check for that case directly.
+// For a function with a deduced result type to return void,
+// the result type as written must be 'auto' or 'decltype(auto)',
+// possibly cv-qualified or constrained, but not ref-qualified.
 if (!OrigResultType.getType()->getAs()) {
   Diag(ReturnLoc, diag::err_auto_fn_return_void_but_not_auto)
 << OrigResultType.getType();
   return true;
 }
-// We always deduce U = void in this case.
-Deduced = SubstAutoType(OrigResultType.getType(), Context.VoidTy);
-if (Deduced.isNull())
+// In the case of a return with no operand, the initializer is considered
+// to be 'void()'.
+Expr *Dummy = new (Context) CXXScalarValueInitExpr(
+Context.VoidTy,
+Context.getTrivialTypeSourceInfo(Context.VoidTy, ReturnLoc), 
ReturnLoc);
+DeduceAutoResult DAR = DeduceAutoType(OrigResultType, Dummy, Deduced);
+
+if (DAR == DAR_Failed && !FD->isInvalidDecl())
+  Diag(ReturnLoc, diag::err_auto_fn_deduction_failure)
+  << OrigResultType.getType() << Dummy->getType();
+
+if (DAR != DAR_Succeeded)
   return true;
   }
 

diff  --git a/clang/test/SemaTemplate/concepts.cpp 
b/clang/test/SemaTemplate/concepts.cpp
index c297a75dd82e6..20af504883566 100644
--- a/clang/test/SemaTemplate/concepts.cpp
+++ b/clang/test/SemaTemplate/concepts.cpp
@@ -169,3 +169,42 @@ namespace PR50561 {
   template void f(T, U) = delete;
   void g() { f(0, 0); }
 }
+
+namespace PR49188 {
+  template concept C = false; // expected-note 6 {{because 
'false' evaluated to false}}
+
+  C auto f1() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return void();
+  }
+  C auto f2() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return;
+  }
+  C auto f3() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  }
+  C decltype(auto) f4() { // expected-error {{deduced type 'void' does not 

[PATCH] D119184: [clang] [concepts] Check constrained-auto return types for void-returning functions

[Arthur O'Dwyer via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGf0891cd61b2f: [clang] [concepts] Check constrained-auto 
return types for void-returning… (authored by arthur.j.odwyer).

Changed prior to commit:
  https://reviews.llvm.org/D119184?vs=413006&id=413046#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119184

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/test/SemaTemplate/concepts.cpp

Index: clang/test/SemaTemplate/concepts.cpp
===
--- clang/test/SemaTemplate/concepts.cpp
+++ clang/test/SemaTemplate/concepts.cpp
@@ -169,3 +169,42 @@
   template void f(T, U) = delete;
   void g() { f(0, 0); }
 }
+
+namespace PR49188 {
+  template concept C = false; // expected-note 6 {{because 'false' evaluated to false}}
+
+  C auto f1() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return void();
+  }
+  C auto f2() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return;
+  }
+  C auto f3() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  }
+  C decltype(auto) f4() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return void();
+  }
+  C decltype(auto) f5() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return;
+  }
+  C decltype(auto) f6() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  }
+  C auto& f7() { // expected-error {{cannot form a reference to 'void'}}
+return void();
+  }
+  C auto& f8() {
+return; // expected-error {{cannot deduce return type 'C auto &' from omitted return expression}}
+  }
+  C auto& f9() { // expected-error {{cannot deduce return type 'C auto &' for function with no return statements}}
+  }
+}
+namespace PR53911 {
+  template concept C = false;
+
+  C auto *f1() {
+return (void*)nullptr; // FIXME: should error
+  }
+  C auto *f2() {
+return (int*)nullptr; // FIXME: should error
+  }
+}
Index: clang/lib/Sema/SemaStmt.cpp
===
--- clang/lib/Sema/SemaStmt.cpp
+++ clang/lib/Sema/SemaStmt.cpp
@@ -3808,19 +3808,26 @@
 LocalTypedefNameReferencer Referencer(*this);
 Referencer.TraverseType(RetExpr->getType());
   } else {
-//  In the case of a return with no operand, the initializer is considered
-//  to be void().
-//
-// Deduction here can only succeed if the return type is exactly 'cv auto'
-// or 'decltype(auto)', so just check for that case directly.
+// For a function with a deduced result type to return void,
+// the result type as written must be 'auto' or 'decltype(auto)',
+// possibly cv-qualified or constrained, but not ref-qualified.
 if (!OrigResultType.getType()->getAs()) {
   Diag(ReturnLoc, diag::err_auto_fn_return_void_but_not_auto)
 << OrigResultType.getType();
   return true;
 }
-// We always deduce U = void in this case.
-Deduced = SubstAutoType(OrigResultType.getType(), Context.VoidTy);
-if (Deduced.isNull())
+// In the case of a return with no operand, the initializer is considered
+// to be 'void()'.
+Expr *Dummy = new (Context) CXXScalarValueInitExpr(
+Context.VoidTy,
+Context.getTrivialTypeSourceInfo(Context.VoidTy, ReturnLoc), ReturnLoc);
+DeduceAutoResult DAR = DeduceAutoType(OrigResultType, Dummy, Deduced);
+
+if (DAR == DAR_Failed && !FD->isInvalidDecl())
+  Diag(ReturnLoc, diag::err_auto_fn_deduction_failure)
+  << OrigResultType.getType() << Dummy->getType();
+
+if (DAR != DAR_Succeeded)
   return true;
   }
 
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -14674,18 +14674,20 @@
   if (getLangOpts().CPlusPlus14) {
 if (!FD->isInvalidDecl() && Body && !FD->isDependentContext() &&
 FD->getReturnType()->isUndeducedType()) {
-  // If the function has a deduced result type but contains no 'return'
-  // statements, the result type as written must be exactly 'auto', and
-  // the deduced result type is 'void'.
+  // For a function with a deduced result type to return void,
+  // the result type as written must be 'auto' or 'decltype(auto)',
+  // possibly cv-qualified or constrained, but not ref-qualified.
   if (!FD->getReturnType()->getAs()) {
 Diag(dcl->getLocation(), diag::err_auto_fn_no_return_but_not_auto)
 << FD->getReturnType();
 FD->setInvalidDecl();
   } else {
-// Substitute 'void' for the 'auto' in the type.
-TypeLoc ResultType = getReturnTypeLoc(FD);
-Context.adjustDeducedFunctionResultType(
-FD, SubstAutoTyp

[PATCH] D120449: [RISCV][RVV] Add strict vfcvt intrinsics that have side effects for dynamically-set rounding mode

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoVVLPatterns.td:624
+  (mask_type true_mask),
+  VLOpFrag, (XLenVT undef))),
+(!cast(inst#"_"#kind#"_"#vlmul.MX)

I don't like using Undef for a field that should be a constant. Can we use 0?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120449

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

[PATCH] D112774: [RISCV] Support k-ext clang intrinsics

[Craig Topper via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112774

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

[PATCH] D120931: [clang-format] fix namepsace format when the name is macro expansion

[Marek Kurdej via Phabricator via cfe-commits]

curdeius added a comment.

Please update the summary, the name is no longer empty. Also, if you can add 
some info in the summary about how it looked before (copying a part of the 
Chromium bug report seems enough), it would be awesome.
Otherwise, some small comments only.




Comment at: clang/lib/Format/NamespaceEndCommentsFixer.cpp:59
+
+// Use the string after `namespace` until `{` or `::` or `(` as an name
+// candicate. If the name is empty, use the candicate.





Comment at: clang/lib/Format/NamespaceEndCommentsFixer.cpp:60
+// Use the string after `namespace` until `{` or `::` or `(` as an name
+// candicate. If the name is empty, use the candicate.
+std::string FirstNSName;





Comment at: clang/lib/Format/NamespaceEndCommentsFixer.cpp:69
+while (Tok && !Tok->is(tok::l_brace) && !Tok->is(tok::coloncolon) &&
+   !Tok->is(tok::l_paren)) {
+  FirstNSName += FirstNSTok->TokenText;

It should be simpler when written as `!Tok->isOneOf(...)`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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

[PATCH] D120992: [analyzer] ReverseNull: New checker to warn for pointer value conditions, if the pointer value is unconditionally non-null

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/NullPtrInterferenceChecker.cpp:166
+/// child is a sink node.
+static bool unconditionallyLeadsHere(const ExplodedNode *N) {
+  size_t NonSinkNodeCount = llvm::count_if(

Consider the following code snippet:
```
void f(int *p, bool b)
{
  if (b) {
*p = 4;
  }
  if (p) {
   ...
  }
}
```

I suspect that we would get a warning for the code above. I think warning on 
the code above might be reasonable (the values of `b` and `p` might be 
correlated but in some cases the analyzer has no way to know this, probably 
some assertions could make the code clearer in that case).

My problem is with the wording of the error message.
The warning `Pointer is unconditionally non-null here` on the null check is not 
true for the code above.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120992

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

[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added inline comments.



Comment at: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp:112
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"

Is this 2 bugs in one? I notice  you also handling attributes? is this a 
different bug? (if so it should really be separate  (but we can let it slide as 
long as the tests are thorough)

can you test:

```
namespace /* comment  */ [[ xxx ]]  /* comment */  A {
int i;
int j;
}  // namespace  A

namespace /* comment  */ [[ xxx ]]   A {
int i;
int j;
}  //  namespace A

namespace /* comment  */ [[ xxx ]]   /* comment */ M(x) {
int i;
int j;
}  // namespace  M(x)

namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) {
int i;
int j;
}  // namespace  A::M(x)

namespace /* comment  */ [[ xxx ]]   /* comment */ M(x)  /* comment */ {
int i;
int j;
}  // namespace  M(x)  

namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) /* comment */  {
int i;
int j;
}  // namespace  A::M(x)
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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

[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

> Its assignment only happens in MacroExpander which is never used

This is something that @klimek was working on.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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

[PATCH] D120992: [analyzer] ReverseNull: New checker to warn for pointer value conditions, if the pointer value is unconditionally non-null

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/NullPtrInterferenceChecker.cpp:166
+/// child is a sink node.
+static bool unconditionallyLeadsHere(const ExplodedNode *N) {
+  size_t NonSinkNodeCount = llvm::count_if(

xazax.hun wrote:
> Consider the following code snippet:
> ```
> void f(int *p, bool b)
> {
>   if (b) {
> *p = 4;
>   }
>   if (p) {
>...
>   }
> }
> ```
> 
> I suspect that we would get a warning for the code above. I think warning on 
> the code above might be reasonable (the values of `b` and `p` might be 
> correlated but in some cases the analyzer has no way to know this, probably 
> some assertions could make the code clearer in that case).
> 
> My problem is with the wording of the error message.
> The warning `Pointer is unconditionally non-null here` on the null check is 
> not true for the code above.
Also, if the check would warn for the code snippet above, the note "suggest 
moving the condition here" would also be incorrect.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120992

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

[PATCH] D120989: Support debug info for alias variable

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

I think it'd potentially go somewhere in 
`DWARFDebugLine::LineTable::getFileLineInfoForAddress` for instance - which 
could inspect the candidate row in the line table, and if it's line zero, it 
could go back one row in the table. This would avoid probing addresses that are 
defined by the same row and will have the same result. (& could keep going back 
rows until it finds a non-zero row) & document that it's a fuzzy match. Or 
always produce the precise result and a separate non-zero fuzzy result if the 
main result is zero. "Nearest preceeding non-zero" or something.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120989

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

[PATCH] D119910: [clang][debug] port clang-cl /JMC flag to ELF

[Reid Kleckner via Phabricator via cfe-commits]

rnk added inline comments.
Herald added a project: All.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5372
+  // This controls whether or not we perform JustMyCode instrumentation.
+  if (TC.getTriple().isOSBinFormatELF() && Args.hasArg(options::OPT_fjmc)) {
+if (DebugInfoKind >= codegenoptions::DebugInfoConstructor)

Generally all flags have an fno- variant. Normally, this would be 
`hasFlag(OPT_fjmc, OPT_fno_jmc, false)`, which handles the behavior of making 
the last flag win. Any reason not to set that up?



Comment at: llvm/lib/CodeGen/JMCInstrumenter.cpp:177
+DefaultCheckFunc->setName(CheckFunctionName);
+DefaultCheckFunc->setLinkage(GlobalValue::WeakODRLinkage);
+CheckFunction = DefaultCheckFunc;

This is a bit pedantic, but the idea is that this weak function will be 
overridden with a strong function, right? Technically, for that use case, 
`weak` linkage is the correct linkage. Because the JMC pass runs late after 
inlining, it is unlikely that this will ever cause issues in practice, but I 
think it expresses the intention better to use the linkage that matches the use 
case.

ODR linkage is supposed to indicate that all definitions must be functionally 
equivalent. It just turns out that the only real power that grants the 
optimizer is the ability to inline.



Comment at: llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll:1
-; REQUIRES: system-windows
-; RUN: opt -jmc-instrument -mtriple=x86_64-pc-windows-msvc  -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=aarch64-pc-windows-msvc -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=arm-pc-windows-msvc -S < %s | 
FileCheck %s
+; REQUIRES: system-linux
+; RUN: opt -jmc-instrument -mtriple=x86_64-unknown-linux-gnu  -S < %s | 
FileCheck %s

Please remove the REQUIRES line, this test should pass on Windows, and the 
other test should pass on Linux as well. Neither of these tests depend on 
anything from the system.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119910

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

[PATCH] D120272: [CUDA] Add driver support for compiling CUDA with the new driver

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:4107
+ options::OPT_no_offload_arch_EQ)) {
+C.getDriver().Diag(diag::err_opt_not_valid_with_opt) << "--offload-arch"
+ << "--offload";

Nit: It would be nice to report specific option which triggered the diag. 
Reporting `--offload-arch` when it's triggered by `--no-offload-arch` would be 
somewhat confusing.

`Args.hasArgNoClaim(options::OPT_offload_arch_EQ) ? "--offload-arch" : 
--no-offload-arch` ?



Comment at: clang/lib/Driver/Driver.cpp:4132-4134
+  Archs.insert(CudaArchToString(CudaArch::SM_35));
+else if (Kind == Action::OFK_HIP)
+  Archs.insert(CudaArchToString(CudaArch::GFX803));

If we do not have constants for the default CUDA/HIP arch yet, we should 
probably add them and use them here.



Comment at: clang/lib/Driver/Driver.cpp:4171
 
-for (unsigned I = 0; I < ToolChains.size(); ++I)
+if (!Relocatable)
+  Diags.Report(diag::err_drv_non_relocatable);

If we do not allow non-relocatable compilation with the new driver, perhaps we 
should make `-fgpu-rdc` enabled by default with the new driver and error out if 
someone attempts to use `-fno-gpu-rdc`. Otherwise we're virtually guaranteed 
that everyone attempting to use `-foffload-new-driver` will hit this error.




Comment at: clang/lib/Driver/Driver.cpp:4172
+if (!Relocatable)
+  Diags.Report(diag::err_drv_non_relocatable);
+

Do we want to return early here?



Comment at: clang/lib/Driver/Driver.cpp:4221
+auto TCAndArch = TCAndArchs.begin();
 for (Action *A : DeviceActions) {
+  DDeps.add(*A, *TCAndArch->first, TCAndArch->second.data(), Kind);

Nit: We do have `llvm::zip` for iterating over multiple containers. However, 
unpacking loop variable results maybe more trouble than it's worth it in such a 
small loop, Up to you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120272

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

[PATCH] D120888: [clang] Stop dragging a EndLoc around when parsing attributes

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM aside from two formatting nits, thank you for the cleanup!




Comment at: clang/lib/Parse/ParsePragma.cpp:1373
 
-  PragmaAttributeInfo(ParsedAttributes &Attributes) : Attributes(Attributes) {}
+  PragmaAttributeInfo(ParsedAttributesWithRange &Attributes) : 
Attributes(Attributes) {}
 };

Probably worth reformatting this before you land.


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

https://reviews.llvm.org/D120888

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

[PATCH] D120272: [CUDA] Add driver support for compiling CUDA with the new driver

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:4132-4134
+  Archs.insert(CudaArchToString(CudaArch::SM_35));
+else if (Kind == Action::OFK_HIP)
+  Archs.insert(CudaArchToString(CudaArch::GFX803));

tra wrote:
> If we do not have constants for the default CUDA/HIP arch yet, we should 
> probably add them and use them here.
Defaulting hip to gfx803 is unlikely to be helpful. It won't run on other 
architectures, i.e. there's no conservative default that will run on most 
things. I guess that's an existing quirk of the hip toolchain?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120272

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

[PATCH] D120984: [clang][dataflow] Extend flow conditions from block terminators

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun added inline comments.



Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h:99
+   const Environment &Env2, Value &MergedVal,
+   Environment &Env) {
   return false;

`MergedEnv`? Also, the documentation above gives a short description of the 
relationship between `Val1`, `Val2`, and `MergedVal`. But it gives little 
pointers what are we supposed to do with the `Environment`. 



Comment at: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp:123
+  if (Constraints1.empty() || Constraints2.empty()) {
+// Disjunction of empty set and non-empty set is represented as empty set.
+return JoinedConstraints;

Is this actually correct? Or did you mean `Conjunction`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120984

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

[PATCH] D121014: [WebAssembly] Check bulk-memory when adjusting lang opts

[Thomas Lively via Phabricator via cfe-commits]

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

We previously had logic to disable pthreads, set the ThreadModel to Single, and
disable thread-safe statics when the atomics target features is disabled, since
that means that the resulting program will not be used in a threaded context.
Similarly check for the presence of the bulk-memory feature, since that is also
necessary to produce multithreaded programs.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121014

Files:
  clang/lib/Basic/Targets/WebAssembly.cpp
  clang/test/CodeGenCXX/static-init-wasm.cpp


Index: clang/test/CodeGenCXX/static-init-wasm.cpp
===
--- clang/test/CodeGenCXX/static-init-wasm.cpp
+++ clang/test/CodeGenCXX/static-init-wasm.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+atomics -target-feature +bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=WEBASSEMBLY32
-// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+atomics -target-feature +bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=WEBASSEMBLY64
 
 // Test that we don't create common blocks.
@@ -53,9 +53,9 @@
 // WEBASSEMBLY64: define internal void @_GLOBAL__sub_I_static_init_wasm.cpp() 
#3 {
 // WEBASSEMBLY64: call void @__cxx_global_var_init()
 
-// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=NOATOMICS
-// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=NOATOMICS
 
 // NOATOMICS-LABEL: @_Z1gv()
@@ -66,3 +66,17 @@
 // NOATOMICS-NOT:   __cxa_guard_acquire
 // NOATOMICS:   [[END]]:
 // NOATOMICS-NEXT:  ret void
+
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN:   | FileCheck %s -check-prefix=NOBULKMEM
+// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN:   | FileCheck %s -check-prefix=NOBULKMEM
+
+// NOBULKMEM-LABEL: @_Z1gv()
+// NOBULKMEM:   %[[R0:.+]] = load i8, i8* @_ZGVZ1gvE1a, align 1
+// NOBULKMEM-NEXT:  %guard.uninitialized = icmp eq i8 %[[R0]], 0
+// NOBULKMEM-NEXT:  br i1 %guard.uninitialized, label %[[CHECK:.+]], label 
%[[END:.+]],
+// NOBULKMEM:   [[CHECK]]:
+// NOBULKMEM-NOT:   __cxa_guard_acquire
+// NOBULKMEM:   [[END]]:
+// NOBULKMEM-NEXT:  ret void
Index: clang/lib/Basic/Targets/WebAssembly.cpp
===
--- clang/lib/Basic/Targets/WebAssembly.cpp
+++ clang/lib/Basic/Targets/WebAssembly.cpp
@@ -256,9 +256,10 @@
 void WebAssemblyTargetInfo::adjust(DiagnosticsEngine &Diags,
LangOptions &Opts) {
   TargetInfo::adjust(Diags, Opts);
-  // If the Atomics feature isn't available, turn off POSIXThreads and
-  // ThreadModel, so that we don't predefine _REENTRANT or __STDCPP_THREADS__.
-  if (!HasAtomics) {
+  // Turn off POSIXThreads and ThreadModel so that we don't predefine 
_REENTRANT
+  // or __STDCPP_THREADS__ if we will eventually end up stripping atomics
+  // because they are unsupported.
+  if (!HasAtomics || !HasBulkMemory) {
 Opts.POSIXThreads = false;
 Opts.setThreadModel(LangOptions::ThreadModelKind::Single);
 Opts.ThreadsafeStatics = false;


Index: clang/test/CodeGenCXX/static-init-wasm.cpp
===
--- clang/test/CodeGenCXX/static-init-wasm.cpp
+++ clang/test/CodeGenCXX/static-init-wasm.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature +atomics -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature +atomics -target-feature +bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=WEBASSEMBLY32
-// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature +atomics -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature +atomics -target-feature +bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=WEBASSEMBLY64
 
 // Test that we don't create common blocks.
@@ -53,9 +53,9 @@
 // WEBASSEMBLY64: define internal void @_GLOBAL__sub_I_static_init_wasm.cpp() #3 {
 // WEBASSEMBLY64: call void @__cxx

[PATCH] D119918: [CMake] Rename TARGET_TRIPLE to LLVM_TARGET_TRIPLE

[Louis Dionne via Phabricator via cfe-commits]

ldionne added a comment.
Herald added a project: All.

Shall we land this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119918

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

[PATCH] D120272: [CUDA] Add driver support for compiling CUDA with the new driver

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:4132-4134
+  Archs.insert(CudaArchToString(CudaArch::SM_35));
+else if (Kind == Action::OFK_HIP)
+  Archs.insert(CudaArchToString(CudaArch::GFX803));

JonChesterfield wrote:
> tra wrote:
> > If we do not have constants for the default CUDA/HIP arch yet, we should 
> > probably add them and use them here.
> Defaulting hip to gfx803 is unlikely to be helpful. It won't run on other 
> architectures, i.e. there's no conservative default that will run on most 
> things. I guess that's an existing quirk of the hip toolchain?
I agree that there's no "safe" choice of GPU target. It applies to CUDA, as 
well, at least for GPU binaries.
That said, we still want `clang -c foo.cu` to work.

For CUDA we use the oldest variant still supported by the vendor. It produces 
PTX assembly which we embed along with the GPU binary. 
That PTX is valid for newer GPU archtectures and CUDA runtime will be able to 
compile it for the GPU the app happens to run on. It's not ideal, but it works.

While for AMDGPU we do not have such forward compatibility mode as we have with 
CUDA, being able to compile for *something* by default is still useful, IMO.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120272

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

[PATCH] D120934: [OpenMP][NFC] Refactor new driver to be more general

[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/D120934/new/

https://reviews.llvm.org/D120934

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

[PATCH] D119918: [CMake] Rename TARGET_TRIPLE to LLVM_TARGET_TRIPLE

[Amir Ayupov via Phabricator via cfe-commits]

Amir accepted this revision.
Amir added a comment.

LGTM from BOLT side


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119918

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

[PATCH] D120244: [clang][sema] Enable first-class bool support for C2x

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.
Herald added a project: All.

Thanks for working on this! It's worth noting that 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2935.pdf was what was adopted 
by WG14 a few weeks ago, so you should be checking against that one, not the 
initial version of the paper.
 It's also worth noting that your changes are partially covering 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2934.pdf which was adopted at 
the same meeting (setting `Opts.Bool` to true means you get `bool` and `true` 
and `false`); I would note that in the commit message, because I don't think 
it's worth trying to separate out `bool`, `true`, and `false` from one another 
in the implementation. But it is worth adding the deprecation warning to use of 
`_Bool` from that paper and removing the macro for `bool` in C2x mode from 
`` as part of these changes in this patch.

I think you're missing some test coverage for the preprocessor in the patch. 
e.g.,

  #if true != 1
  #error "oops"
  #endif
  
  #if false != 0
  #error "oops"
  #endif

And I don't see the changes to the  header which is now obsolete in 
C2x.

Oh, and the change should be added to the release notes.




Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3247
 
   // OpenCL and C++ both have bool, true, false keywords.
+  Opts.Bool = Opts.OpenCL || Opts.CPlusPlus || Opts.C2x;

Comment is now stale.



Comment at: clang/test/Sema/c2x-bool.c:1
+// RUN: %clang_cc1 -triple x86_64-apple-darwin -std=c2x -x c -fsyntax-only 
-verify %s
+

Is the triple necessary?



Comment at: clang/test/Sema/c2x-bool.c:14
+_Static_assert(false == (bool)+0);
+
+

You should also add a test to verify that the predefined constants are usable 
as an integer constant expression:
```
char c1[true]; // good
_Static_assert(sizeof(c1) == sizeof(char[1]));
char c2[false]; // zero-sized array declaration
```
(This covers the changes in 6.6.)





Comment at: clang/test/Sema/c2x-bool.c:15
+
+
+static void *f = false; // expected-warning {{to null from a constant boolean 
expression}}

Another test case that's needed is for the integer promotion rules:
```
_Static_assert(_Generic(+true, bool : 0, unsigned int : 0, signed int : 1, 
default : 0));

struct S {
  bool b : 1;
} s;
_Static_assert(_Generic(+s.b, bool : 0, unsigned int : 0, signed int : 1, 
default : 0));
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120244

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

[PATCH] D120272: [CUDA] Add driver support for compiling CUDA with the new driver

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 updated this revision to Diff 413087.
jhuber6 added a comment.
Herald added a subscriber: dexonsmith.

Addressing nits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120272

Files:
  clang/include/clang/Basic/Cuda.h
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/cuda-openmp-driver.cu

Index: clang/test/Driver/cuda-openmp-driver.cu
===
--- /dev/null
+++ clang/test/Driver/cuda-openmp-driver.cu
@@ -0,0 +1,16 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// RUN: %clang -### -target x86_64-linux-gnu -nocudalib -ccc-print-bindings -fgpu-rdc \
+// RUN:-foffload-new-driver --offload-arch=sm_35 --offload-arch=sm_70 %s 2>&1 \
+// RUN: | FileCheck -check-prefix CHECK %s
+
+// CHECK: "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT:.+]]"], output: "[[PTX_SM_35:.+]]"
+// CHECK: "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: ["[[PTX_SM_35]]"], output: "[[CUBIN_SM_35:.+]]"
+// CHECK: "nvptx64-nvidia-cuda" - "NVPTX::Linker", inputs: ["[[CUBIN_SM_35]]", "[[PTX_SM_35]]"], output: "[[FATBIN_SM_35:.+]]"
+// CHECK: "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT]]"], output: "[[PTX_SM_70:.+]]"
+// CHECK: "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: ["[[PTX_SM_70:.+]]"], output: "[[CUBIN_SM_70:.+]]"
+// CHECK: "nvptx64-nvidia-cuda" - "NVPTX::Linker", inputs: ["[[CUBIN_SM_70]]", "[[PTX_SM_70:.+]]"], output: "[[FATBIN_SM_70:.+]]"
+// CHECK: "x86_64-unknown-linux-gnu" - "clang", inputs: ["[[INPUT]]", "[[FATBIN_SM_35]]", "[[FATBIN_SM_70]]"], output: "[[HOST_OBJ:.+]]"
+// CHECK: "x86_64-unknown-linux-gnu" - "Offload::Linker", inputs: ["[[HOST_OBJ]]"], output: "a.out"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4391,6 +4391,7 @@
   // one input.
   bool IsCuda = JA.isOffloading(Action::OFK_Cuda);
   bool IsCudaDevice = JA.isDeviceOffloading(Action::OFK_Cuda);
+  bool IsCudaHost = JA.isHostOffloading(Action::OFK_Cuda);
   bool IsHIP = JA.isOffloading(Action::OFK_HIP);
   bool IsHIPDevice = JA.isDeviceOffloading(Action::OFK_HIP);
   bool IsOpenMPDevice = JA.isDeviceOffloading(Action::OFK_OpenMP);
@@ -4414,6 +4415,7 @@
 
   InputInfoList ModuleHeaderInputs;
   InputInfoList OpenMPHostInputs;
+  InputInfoList CudaHostInputs;
   const InputInfo *CudaDeviceInput = nullptr;
   const InputInfo *OpenMPDeviceInput = nullptr;
   for (const InputInfo &I : Inputs) {
@@ -4428,6 +4430,8 @@
 << types::getTypeName(Expected);
   }
   ModuleHeaderInputs.push_back(I);
+} else if (IsCudaHost && Args.hasArg(options::OPT_fopenmp_new_driver)) {
+  CudaHostInputs.push_back(I);
 } else if ((IsCuda || IsHIP) && !CudaDeviceInput) {
   CudaDeviceInput = &I;
 } else if (IsOpenMPDevice && !OpenMPDeviceInput) {
@@ -6957,6 +6961,7 @@
 auto OpenMPTCs = C.getOffloadToolChains();
 for (auto TI = OpenMPTCs.first, TE = OpenMPTCs.second; TI != TE;
  ++TI, ++InputFile) {
+  assert(InputFile->isFilename() && "Offloading requires a filename");
   const ToolChain *TC = TI->second;
   const ArgList &TCArgs = C.getArgsForToolChain(TC, "", Action::OFK_OpenMP);
   StringRef File =
@@ -6969,6 +6974,20 @@
   TC->getTripleString() + "." +
   TCArgs.getLastArgValue(options::OPT_march_EQ) + "." + InputName));
 }
+  } else if (IsCudaHost && !CudaHostInputs.empty()) {
+const ToolChain *TC = C.getSingleOffloadToolChain();
+for (const auto &InputFile : CudaHostInputs) {
+  assert(InputFile.isFilename() && "Offloading requires a filename");
+  StringRef File =
+  C.getArgs().MakeArgString(TC->getInputFilename(InputFile));
+  StringRef InputName = Clang::getBaseInputStem(Args, Inputs);
+  // The CUDA toolchain should have a bound arch appended to the filename.
+  StringRef Arch = File.split(".").first.rsplit('-').second;
+  CmdArgs.push_back(Args.MakeArgString(
+  "-fembed-offload-object=" + File + "," +
+  Action::GetOffloadKindName(Action::OFK_Cuda) + "." +
+  TC->getTripleString() + "." + Arch + "." + InputName));
+}
   }
 
   if (Triple.isAMDGPU()) {
@@ -8220,14 +8239,17 @@
   ArgStringList CmdArgs;
 
   // Pass the CUDA path to the linker wrapper tool.
-  for (auto &I : llvm::make_range(OpenMPTCRange.first, OpenMPTCRange.second)) {
-const ToolChain *TC = I.second;
-if (TC->getTriple().isNVPTX()) {
-  CudaInstallationDetector CudaInstallation(D, TheTriple, Args);
-  if (CudaInstallation.isValid())
-CmdArgs.push_back(Args.MakeArgString(
-"--cuda-path=" + CudaInstalla

[PATCH] D120272: [CUDA] Add driver support for compiling CUDA with the new driver

[Joseph Huber via Phabricator via cfe-commits]

jhuber6 added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:4132-4134
+  Archs.insert(CudaArchToString(CudaArch::SM_35));
+else if (Kind == Action::OFK_HIP)
+  Archs.insert(CudaArchToString(CudaArch::GFX803));

tra wrote:
> JonChesterfield wrote:
> > tra wrote:
> > > If we do not have constants for the default CUDA/HIP arch yet, we should 
> > > probably add them and use them here.
> > Defaulting hip to gfx803 is unlikely to be helpful. It won't run on other 
> > architectures, i.e. there's no conservative default that will run on most 
> > things. I guess that's an existing quirk of the hip toolchain?
> I agree that there's no "safe" choice of GPU target. It applies to CUDA, as 
> well, at least for GPU binaries.
> That said, we still want `clang -c foo.cu` to work.
> 
> For CUDA we use the oldest variant still supported by the vendor. It produces 
> PTX assembly which we embed along with the GPU binary. 
> That PTX is valid for newer GPU archtectures and CUDA runtime will be able to 
> compile it for the GPU the app happens to run on. It's not ideal, but it 
> works.
> 
> While for AMDGPU we do not have such forward compatibility mode as we have 
> with CUDA, being able to compile for *something* by default is still useful, 
> IMO.
> 
> 
I just copied GFX803 because that's what the previous driver used. I agree we 
should just default to something, maybe in the AMD case we can issue a warning 
telling them to use the flag to properly specify it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120272

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

[PATCH] D119778: [clang] Add a note "deducing return type for 'foo'"

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone updated this revision to Diff 413089.
Quuxplusone added a comment.
Herald added a project: All.

Rebased after landing D119184 . I'm no longer 
necessarily trying to land this note (it's not directly relevant to my 
interests anymore), but I'd like to show its CI as green before I abandon it. 
@rsmith would you like me to do something other than abandon this?


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

https://reviews.llvm.org/D119778

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Frontend/FrontendActions.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p2-1z.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p7-cxx14.cpp
  clang/test/CXX/dcl/dcl.spec/dcl.type/dcl.spec.auto/p6.cpp
  clang/test/SemaCUDA/autoret-global.cu
  clang/test/SemaCXX/cxx2b-consteval-if.cpp
  clang/test/SemaCXX/deduced-return-type-cxx14.cpp
  clang/test/SemaCXX/deduced-return-void.cpp
  clang/test/SemaCXX/typo-correction-crash.cpp
  clang/test/SemaTemplate/concepts.cpp

Index: clang/test/SemaTemplate/concepts.cpp
===
--- clang/test/SemaTemplate/concepts.cpp
+++ clang/test/SemaTemplate/concepts.cpp
@@ -114,6 +114,7 @@
   }
   template void g5() {
 ([]() -> C auto{ // expected-error-re {{deduced type {{.*}} does not satisfy}}
+// expected-note@-1 {{deducing return type for 'operator()'}}
  return T();
  }(), ...);
   }
@@ -174,26 +175,34 @@
   template concept C = false; // expected-note 6 {{because 'false' evaluated to false}}
 
   C auto f1() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+// expected-note@-1 {{deducing return type for 'f1'}}
 return void();
   }
   C auto f2() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+// expected-note@-1 {{deducing return type for 'f2'}}
 return;
   }
   C auto f3() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+// expected-note@-1 {{deducing return type for 'f3'}}
   }
   C decltype(auto) f4() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  // expected-note@-1 {{deducing return type for 'f4'}}
 return void();
   }
   C decltype(auto) f5() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  // expected-note@-1 {{deducing return type for 'f5'}}
 return;
   }
   C decltype(auto) f6() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  // expected-note@-1 {{deducing return type for 'f6'}}
   }
   C auto& f7() { // expected-error {{cannot form a reference to 'void'}}
+ // expected-note@-1 {{deducing return type for 'f7'}}
 return void();
   }
   C auto& f8() {
 return; // expected-error {{cannot deduce return type 'C auto &' from omitted return expression}}
+// expected-note@-2 {{deducing return type for 'f8'}}
   }
   C auto& f9() { // expected-error {{cannot deduce return type 'C auto &' for function with no return statements}}
   }
Index: clang/test/SemaCXX/typo-correction-crash.cpp
===
--- clang/test/SemaCXX/typo-correction-crash.cpp
+++ clang/test/SemaCXX/typo-correction-crash.cpp
@@ -9,6 +9,7 @@
   return "s";
   return tes; // expected-error {{use of undeclared identifier 'tes'; did you mean 'test'?}}
   // expected-error@-1 {{deduced as 'int' here but deduced as 'const char *' in earlier}}
+  // expected-note@-4 {{deducing return type for 'check2'}}
 }
 
 template  struct is_same { static constexpr bool value = false; };
Index: clang/test/SemaCXX/deduced-return-void.cpp
===
--- clang/test/SemaCXX/deduced-return-void.cpp
+++ clang/test/SemaCXX/deduced-return-void.cpp
@@ -16,10 +16,12 @@
 auto f4() {
   return i;
   return; // expected-error {{'auto' in return type deduced as 'void' here but deduced as 'int' in earlier return statement}}
+  // expected-note@-3 {{deducing return type for 'f4'}}
 }
 auto f5() {
   return i;
   return void(); // expected-error {{'auto' in return type deduced as 'void' here but deduced as 'int' in earlier return statement}}
+ // expected-note@-3 {{deducing return type for 'f5'}}
 }
 
 auto l1 = []() { };
@@ -44,10 +46,12 @@
 decltype(auto) f4() {
   return i;
   return; // expected-error {{'decltype(auto)' in return type deduced as 'void' here but deduced as 'int' in earlier return statement}}
+  // expected-note@-3 {{deducing return type for 'f4'}}
 }
 decltype(auto) f5() {
   return i;
   return void(); // expected-error {{'decltype(auto)' in return type deduced as 'void' here but d

[PATCH] D120947: [tooling] Explain how to create a compilation database on Windows [NFC]

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood updated this revision to Diff 413093.
LegalizeAdulthood marked an inline comment as done.
LegalizeAdulthood added a comment.

Update from review comments


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

https://reviews.llvm.org/D120947

Files:
  clang/docs/HowToSetupToolingForLLVM.rst


Index: clang/docs/HowToSetupToolingForLLVM.rst
===
--- clang/docs/HowToSetupToolingForLLVM.rst
+++ clang/docs/HowToSetupToolingForLLVM.rst
@@ -53,6 +53,54 @@
 
   $ make check-all
 
+Setup Clang Tooling Using CMake on Windows
+==
+
+For Windows developers, the Visual Studio project generators in CMake do
+not support `CMAKE_EXPORT_COMPILE_COMMANDS
+`_.
+However, the Ninja generator does support this variable and can be used
+on Windows to generate a suitable ``compile_commands.json`` that invokes
+the MSVC compiler.
+
+First, you will need to install `Ninja`_.  Once installed, the Ninja
+executable will need to be in your search path for CMake to locate it.
+
+Next, assuming you already have Visual Studio installed on your machine, you
+need to have the appropriate environment variables configured so that CMake
+will locate the MSVC compiler for the Ninja generator.  The `documentation
+`_
+describes the necessary environment variable settings, but the simplest thing
+is to use a `developer command-prompt window
+`_
+or call a `developer command file
+`_
+to set the environment variables appropriately.
+
+Now you can run CMake with the Ninja generator to export a compilation
+database:
+
+.. code-block:: console
+
+  C:\> mkdir build-ninja
+  C:\> cd build-ninja
+  C:\build-ninja> cmake -G Ninja -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 
path/to/llvm/sources
+
+It is best to keep your Visual Studio IDE build folder separate from the
+Ninja build folder.  This prevents the two build systems from negatively
+interacting with each other.
+
+Once the ``compile_commands.json`` file has been created by Ninja, you can
+use that compilation database with Clang Tooling.  One caveat is that because
+there are indirect settings obtained through the environment variables,
+you may need to run any Clang Tooling executables through a command prompt
+window created for use with Visual Studio as described above.  An
+alternative, e.g. for using the Visual Studio debugger on a Clang Tooling
+executable, is to ensure that the environment variables are also visible
+to the debugger settings.  This can be done locally in Visual Studio's
+debugger configuration locally or globally by launching the Visual Studio
+IDE from a suitable command-prompt window.
+
 Using Clang Tools
 =
 
@@ -143,9 +191,9 @@
 Using Ninja Build System
 ===
 
-Optionally you can use the `Ninja `_
-build system instead of make. It is aimed at making your builds faster.
-Currently this step will require building Ninja from sources.
+Optionally you can use the `Ninja`_ build system instead of make. It is
+aimed at making your builds faster.  Currently this step will require
+building Ninja from sources.
 
 To take advantage of using Clang Tools along with Ninja build you need
 at least CMake 2.8.9.
@@ -197,3 +245,5 @@
   $ ninja check-all
 
 Other target names can be used in the same way as with make.
+
+.. _Ninja: https://ninja-build.org/


Index: clang/docs/HowToSetupToolingForLLVM.rst
===
--- clang/docs/HowToSetupToolingForLLVM.rst
+++ clang/docs/HowToSetupToolingForLLVM.rst
@@ -53,6 +53,54 @@
 
   $ make check-all
 
+Setup Clang Tooling Using CMake on Windows
+==
+
+For Windows developers, the Visual Studio project generators in CMake do
+not support `CMAKE_EXPORT_COMPILE_COMMANDS
+`_.
+However, the Ninja generator does support this variable and can be used
+on Windows to generate a suitable ``compile_commands.json`` that invokes
+the MSVC compiler.
+
+First, you will need to install `Ninja`_.  Once installed, the Ninja
+executable will need to be in your search path for CMake to locate it.
+
+Next, assuming you already have Visual Studio installed on your machine, you
+need to have the appropriate environment variables configured so that CMake
+will locate the MSVC compiler for the Ninja generator.  The `documentation
+

[clang] d5d0313 - [tooling] Explain how to create a compilation database on Windows [NFC]

[via cfe-commits]

Author: Richard
Date: 2022-03-04T13:06:08-07:00
New Revision: d5d03135a7160586e2b09dc47c7021379252fbbd

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

LOG: [tooling] Explain how to create a compilation database on Windows [NFC]

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

Added: 


Modified: 
clang/docs/HowToSetupToolingForLLVM.rst

Removed: 




diff  --git a/clang/docs/HowToSetupToolingForLLVM.rst 
b/clang/docs/HowToSetupToolingForLLVM.rst
index cbe15abaab3b4..62189511aeb2a 100644
--- a/clang/docs/HowToSetupToolingForLLVM.rst
+++ b/clang/docs/HowToSetupToolingForLLVM.rst
@@ -53,6 +53,54 @@ Now you are ready to build and test LLVM using make:
 
   $ make check-all
 
+Setup Clang Tooling Using CMake on Windows
+==
+
+For Windows developers, the Visual Studio project generators in CMake do
+not support `CMAKE_EXPORT_COMPILE_COMMANDS
+`_.
+However, the Ninja generator does support this variable and can be used
+on Windows to generate a suitable ``compile_commands.json`` that invokes
+the MSVC compiler.
+
+First, you will need to install `Ninja`_.  Once installed, the Ninja
+executable will need to be in your search path for CMake to locate it.
+
+Next, assuming you already have Visual Studio installed on your machine, you
+need to have the appropriate environment variables configured so that CMake
+will locate the MSVC compiler for the Ninja generator.  The `documentation
+`_
+describes the necessary environment variable settings, but the simplest thing
+is to use a `developer command-prompt window
+`_
+or call a `developer command file
+`_
+to set the environment variables appropriately.
+
+Now you can run CMake with the Ninja generator to export a compilation
+database:
+
+.. code-block:: console
+
+  C:\> mkdir build-ninja
+  C:\> cd build-ninja
+  C:\build-ninja> cmake -G Ninja -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 
path/to/llvm/sources
+
+It is best to keep your Visual Studio IDE build folder separate from the
+Ninja build folder.  This prevents the two build systems from negatively
+interacting with each other.
+
+Once the ``compile_commands.json`` file has been created by Ninja, you can
+use that compilation database with Clang Tooling.  One caveat is that because
+there are indirect settings obtained through the environment variables,
+you may need to run any Clang Tooling executables through a command prompt
+window created for use with Visual Studio as described above.  An
+alternative, e.g. for using the Visual Studio debugger on a Clang Tooling
+executable, is to ensure that the environment variables are also visible
+to the debugger settings.  This can be done locally in Visual Studio's
+debugger configuration locally or globally by launching the Visual Studio
+IDE from a suitable command-prompt window.
+
 Using Clang Tools
 =
 
@@ -143,9 +191,9 @@ Examples:
 Using Ninja Build System
 ===
 
-Optionally you can use the `Ninja `_
-build system instead of make. It is aimed at making your builds faster.
-Currently this step will require building Ninja from sources.
+Optionally you can use the `Ninja`_ build system instead of make. It is
+aimed at making your builds faster.  Currently this step will require
+building Ninja from sources.
 
 To take advantage of using Clang Tools along with Ninja build you need
 at least CMake 2.8.9.
@@ -197,3 +245,5 @@ Now you are ready to build and test LLVM using Ninja:
   $ ninja check-all
 
 Other target names can be used in the same way as with make.
+
+.. _Ninja: https://ninja-build.org/



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

[PATCH] D120947: [tooling] Explain how to create a compilation database on Windows [NFC]

[Richard 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 rGd5d03135a716: [tooling] Explain how to create a compilation 
database on Windows [NFC] (authored by LegalizeAdulthood).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120947

Files:
  clang/docs/HowToSetupToolingForLLVM.rst


Index: clang/docs/HowToSetupToolingForLLVM.rst
===
--- clang/docs/HowToSetupToolingForLLVM.rst
+++ clang/docs/HowToSetupToolingForLLVM.rst
@@ -53,6 +53,54 @@
 
   $ make check-all
 
+Setup Clang Tooling Using CMake on Windows
+==
+
+For Windows developers, the Visual Studio project generators in CMake do
+not support `CMAKE_EXPORT_COMPILE_COMMANDS
+`_.
+However, the Ninja generator does support this variable and can be used
+on Windows to generate a suitable ``compile_commands.json`` that invokes
+the MSVC compiler.
+
+First, you will need to install `Ninja`_.  Once installed, the Ninja
+executable will need to be in your search path for CMake to locate it.
+
+Next, assuming you already have Visual Studio installed on your machine, you
+need to have the appropriate environment variables configured so that CMake
+will locate the MSVC compiler for the Ninja generator.  The `documentation
+`_
+describes the necessary environment variable settings, but the simplest thing
+is to use a `developer command-prompt window
+`_
+or call a `developer command file
+`_
+to set the environment variables appropriately.
+
+Now you can run CMake with the Ninja generator to export a compilation
+database:
+
+.. code-block:: console
+
+  C:\> mkdir build-ninja
+  C:\> cd build-ninja
+  C:\build-ninja> cmake -G Ninja -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 
path/to/llvm/sources
+
+It is best to keep your Visual Studio IDE build folder separate from the
+Ninja build folder.  This prevents the two build systems from negatively
+interacting with each other.
+
+Once the ``compile_commands.json`` file has been created by Ninja, you can
+use that compilation database with Clang Tooling.  One caveat is that because
+there are indirect settings obtained through the environment variables,
+you may need to run any Clang Tooling executables through a command prompt
+window created for use with Visual Studio as described above.  An
+alternative, e.g. for using the Visual Studio debugger on a Clang Tooling
+executable, is to ensure that the environment variables are also visible
+to the debugger settings.  This can be done locally in Visual Studio's
+debugger configuration locally or globally by launching the Visual Studio
+IDE from a suitable command-prompt window.
+
 Using Clang Tools
 =
 
@@ -143,9 +191,9 @@
 Using Ninja Build System
 ===
 
-Optionally you can use the `Ninja `_
-build system instead of make. It is aimed at making your builds faster.
-Currently this step will require building Ninja from sources.
+Optionally you can use the `Ninja`_ build system instead of make. It is
+aimed at making your builds faster.  Currently this step will require
+building Ninja from sources.
 
 To take advantage of using Clang Tools along with Ninja build you need
 at least CMake 2.8.9.
@@ -197,3 +245,5 @@
   $ ninja check-all
 
 Other target names can be used in the same way as with make.
+
+.. _Ninja: https://ninja-build.org/


Index: clang/docs/HowToSetupToolingForLLVM.rst
===
--- clang/docs/HowToSetupToolingForLLVM.rst
+++ clang/docs/HowToSetupToolingForLLVM.rst
@@ -53,6 +53,54 @@
 
   $ make check-all
 
+Setup Clang Tooling Using CMake on Windows
+==
+
+For Windows developers, the Visual Studio project generators in CMake do
+not support `CMAKE_EXPORT_COMPILE_COMMANDS
+`_.
+However, the Ninja generator does support this variable and can be used
+on Windows to generate a suitable ``compile_commands.json`` that invokes
+the MSVC compiler.
+
+First, you will need to install `Ninja`_.  Once installed, the Ninja
+executable will need to be in your search path for CMake to locate it.
+
+Next, assuming you already have Visual Studio installed on your machine, you
+need to have the appropriate environment variabl

[PATCH] D121019: [clang-tools-extra] Document clang tidy unit tests target

[Richard via Phabricator via cfe-commits]

LegalizeAdulthood created this revision.
LegalizeAdulthood added reviewers: aaron.ballman, njames93, ymandel.
LegalizeAdulthood added a project: clang-tools-extra.
Herald added a project: All.
LegalizeAdulthood requested review of this revision.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121019

Files:
  clang-tools-extra/docs/clang-tidy/Contributing.rst


Index: clang-tools-extra/docs/clang-tidy/Contributing.rst
===
--- clang-tools-extra/docs/clang-tidy/Contributing.rst
+++ clang-tools-extra/docs/clang-tidy/Contributing.rst
@@ -364,6 +364,11 @@
 test.  The ``ASTMatchersTests`` target contains unit tests for the public AST 
matcher
 classes and is a good source of testing idioms for matchers.
 
+You can build the Clang Tidy unit tests by building the ``ClangTidyTests`` 
target.
+Test targets in LLVM and Clang are excluded from the "build all" style action 
of
+IDE based CMake generators, so you need to explicitly build the target for the 
unit
+tests to be built.
+
 Making your check robust
 
 


Index: clang-tools-extra/docs/clang-tidy/Contributing.rst
===
--- clang-tools-extra/docs/clang-tidy/Contributing.rst
+++ clang-tools-extra/docs/clang-tidy/Contributing.rst
@@ -364,6 +364,11 @@
 test.  The ``ASTMatchersTests`` target contains unit tests for the public AST matcher
 classes and is a good source of testing idioms for matchers.
 
+You can build the Clang Tidy unit tests by building the ``ClangTidyTests`` target.
+Test targets in LLVM and Clang are excluded from the "build all" style action of
+IDE based CMake generators, so you need to explicitly build the target for the unit
+tests to be built.
+
 Making your check robust
 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] e22e277 - [RGT] DistroTest: Separate environment-specific test functions

[Paul Robinson via cfe-commits]

Author: Paul Robinson
Date: 2022-03-04T12:28:38-08:00
New Revision: e22e2774d93379d6bad41ae20194b076fdb44915

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

LOG: [RGT] DistroTest: Separate environment-specific test functions

This allows using GTEST_SKIP() to identify un-executed tests.

Found by the Rotten Green Tests project.

Added: 


Modified: 
clang/unittests/Driver/DistroTest.cpp

Removed: 




diff  --git a/clang/unittests/Driver/DistroTest.cpp 
b/clang/unittests/Driver/DistroTest.cpp
index b6e4ca9be8579..ebf75dc7ce3a6 100644
--- a/clang/unittests/Driver/DistroTest.cpp
+++ b/clang/unittests/Driver/DistroTest.cpp
@@ -360,16 +360,17 @@ TEST(DistroTest, DetectWindowsAndCrossCompile) {
 unsigned Count{};
   };
 
+  llvm::Triple Host(llvm::sys::getProcessTriple());
+  if (!Host.isOSWindows())
+GTEST_SKIP();
+
   llvm::IntrusiveRefCntPtr RFS =
   llvm::vfs::getRealFileSystem();
-  llvm::Triple Host(llvm::sys::getProcessTriple());
 
   CountingFileSystem CFileSystem;
   Distro LinuxDistro{CFileSystem, llvm::Triple("unknown-pc-linux")};
-  if (Host.isOSWindows()) {
-ASSERT_EQ(Distro(Distro::UnknownDistro), LinuxDistro);
-ASSERT_GT(CFileSystem.Count, 0U);
-  }
+  ASSERT_EQ(Distro(Distro::UnknownDistro), LinuxDistro);
+  ASSERT_GT(CFileSystem.Count, 0U);
 
   Distro WinDistro{CFileSystem, llvm::Triple("unknown-pc-windows")};
   ASSERT_EQ(Distro(Distro::UnknownDistro), WinDistro);
@@ -377,20 +378,25 @@ TEST(DistroTest, DetectWindowsAndCrossCompile) {
 
   // When running on Windows along with a real file system, ensure that no
   // distro is returned if targeting Linux
-  if (Host.isOSWindows()) {
-Distro LinuxRealDistro{*RFS, llvm::Triple("unknown-pc-linux")};
-ASSERT_EQ(Distro(Distro::UnknownDistro), LinuxRealDistro);
-  }
-  // When running on Linux, check if the distro is the same as the host when
-  // targeting Linux
-  if (Host.isOSLinux()) {
-Distro HostDistro{*RFS, Host};
-Distro LinuxRealDistro{*RFS, llvm::Triple("unknown-pc-linux")};
-ASSERT_EQ(HostDistro, LinuxRealDistro);
-  }
+  Distro LinuxRealDistro{*RFS, llvm::Triple("unknown-pc-linux")};
+  ASSERT_EQ(Distro(Distro::UnknownDistro), LinuxRealDistro);
 
   Distro WinRealDistro{*RFS, llvm::Triple("unknown-pc-windows")};
   ASSERT_EQ(Distro(Distro::UnknownDistro), WinRealDistro);
 }
 
+TEST(DistroTest, DetectLinux) {
+  llvm::Triple Host(llvm::sys::getProcessTriple());
+  if (!Host.isOSLinux())
+GTEST_SKIP();
+
+  // When running on Linux, check if the distro is the same as the host when
+  // targeting Linux
+  llvm::IntrusiveRefCntPtr RFS =
+  llvm::vfs::getRealFileSystem();
+  Distro HostDistro{*RFS, Host};
+  Distro LinuxRealDistro{*RFS, llvm::Triple("unknown-pc-linux")};
+  ASSERT_EQ(HostDistro, LinuxRealDistro);
+}
+
 } // end anonymous namespace



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

[clang] bde13a8 - [HIP] Fix job action offloading kind for mixed HIP/C++ compilation

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2022-03-04T15:34:02-05:00
New Revision: bde13a8102baef4d79723064e6bd27cd39124d91

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

LOG: [HIP] Fix job action offloading kind for mixed HIP/C++ compilation

When both HIP and C++ programs are input files to clang
with -c, clang treats C++ programs as HIP programs,
which is incorrect.

This is due to action builder does not set correct
offloading kind for job actions for C++ programs.

Reviewed by: Artem Belevich

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

Added: 
clang/test/Driver/Inputs/empty.cpp
clang/test/Driver/Inputs/empty.hip

Modified: 
clang/lib/Driver/Driver.cpp
clang/test/Driver/hip-phases.hip

Removed: 




diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 3bfddeefc7b2b..00d8f1b3b374e 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -2692,6 +2692,7 @@ class OffloadingActionBuilder final {
   UA->registerDependentActionInfo(ToolChains[0], Arch,
   AssociatedOffloadKind);
 }
+IsActive = true;
 return ABRT_Success;
   }
 
@@ -3038,6 +3039,9 @@ class OffloadingActionBuilder final {
 getDeviceDependences(OffloadAction::DeviceDependences &DA,
  phases::ID CurPhase, phases::ID FinalPhase,
  PhasesTy &Phases) override {
+  if (!IsActive)
+return ABRT_Inactive;
+
   // amdgcn does not support linking of object files, therefore we skip
   // backend and assemble phases to output LLVM IR. Except for generating
   // non-relocatable device coee, where we generate fat binary for device

diff  --git a/clang/test/Driver/Inputs/empty.cpp 
b/clang/test/Driver/Inputs/empty.cpp
new file mode 100644
index 0..e69de29bb2d1d

diff  --git a/clang/test/Driver/Inputs/empty.hip 
b/clang/test/Driver/Inputs/empty.hip
new file mode 100644
index 0..e69de29bb2d1d

diff  --git a/clang/test/Driver/hip-phases.hip 
b/clang/test/Driver/hip-phases.hip
index 93bf635dab63f..5e4f6fc9373a4 100644
--- a/clang/test/Driver/hip-phases.hip
+++ b/clang/test/Driver/hip-phases.hip
@@ -338,7 +338,7 @@
 // RL2-NB-NOT: linker
 // RL2-NB-NOT: offload
 
-// NL2-DAG: [[P4:[0-9]+]]: linker, {[[P0]], [[P2]]}, image, (host-[[T:hip]])
+// NL2-DAG: [[P4:[0-9]+]]: linker, {[[P0]], [[P2]]}, image
 // RL2-EM-DAG: [[P4:[0-9]+]]: linker, {[[P1]], [[P3]], [[P9]]}, image, 
(host-[[T]])
 // RL2-DEV-NOT: linker
 
@@ -455,3 +455,21 @@
 // PPELLVM2-DAG: [[P9:[0-9]+]]: offload, "device-[[T]] 
(amdgcn-amd-amdhsa:[[ARCH2]])" {[[P8]]}, ir
 // PPELLVM2-DAG: [[P10:[0-9]+]]: clang-offload-bundler, {[[P4]], [[P9]]}, ir, 
(device-hip, )
 // PPELLVM2-NOT: host
+
+// Test mixed HIP and C++ compilation. HIP program should have HIP offload 
kind.
+// C++ program should have no offload kind.
+
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck 
-check-prefixes=MIXED %s
+
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck 
-check-prefixes=MIXED-NEG %s
+
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (host-hip)
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx803)
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx900)
+// MIXED-DAG: input, "{{.*}}empty.cpp", c++
+// MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (host-hip)
+// MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (device-hip



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

[PATCH] D120910: [HIP] Fix job action offloading kind for mixed HIP/C++ compilation

[Yaxun Liu 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 rGbde13a8102ba: [HIP] Fix job action offloading kind for mixed 
HIP/C++ compilation (authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120910

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/Inputs/empty.cpp
  clang/test/Driver/Inputs/empty.hip
  clang/test/Driver/hip-phases.hip


Index: clang/test/Driver/hip-phases.hip
===
--- clang/test/Driver/hip-phases.hip
+++ clang/test/Driver/hip-phases.hip
@@ -338,7 +338,7 @@
 // RL2-NB-NOT: linker
 // RL2-NB-NOT: offload
 
-// NL2-DAG: [[P4:[0-9]+]]: linker, {[[P0]], [[P2]]}, image, (host-[[T:hip]])
+// NL2-DAG: [[P4:[0-9]+]]: linker, {[[P0]], [[P2]]}, image
 // RL2-EM-DAG: [[P4:[0-9]+]]: linker, {[[P1]], [[P3]], [[P9]]}, image, 
(host-[[T]])
 // RL2-DEV-NOT: linker
 
@@ -455,3 +455,21 @@
 // PPELLVM2-DAG: [[P9:[0-9]+]]: offload, "device-[[T]] 
(amdgcn-amd-amdhsa:[[ARCH2]])" {[[P8]]}, ir
 // PPELLVM2-DAG: [[P10:[0-9]+]]: clang-offload-bundler, {[[P4]], [[P9]]}, ir, 
(device-hip, )
 // PPELLVM2-NOT: host
+
+// Test mixed HIP and C++ compilation. HIP program should have HIP offload 
kind.
+// C++ program should have no offload kind.
+
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck 
-check-prefixes=MIXED %s
+
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck 
-check-prefixes=MIXED-NEG %s
+
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (host-hip)
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx803)
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx900)
+// MIXED-DAG: input, "{{.*}}empty.cpp", c++
+// MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (host-hip)
+// MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (device-hip
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -2692,6 +2692,7 @@
   UA->registerDependentActionInfo(ToolChains[0], Arch,
   AssociatedOffloadKind);
 }
+IsActive = true;
 return ABRT_Success;
   }
 
@@ -3038,6 +3039,9 @@
 getDeviceDependences(OffloadAction::DeviceDependences &DA,
  phases::ID CurPhase, phases::ID FinalPhase,
  PhasesTy &Phases) override {
+  if (!IsActive)
+return ABRT_Inactive;
+
   // amdgcn does not support linking of object files, therefore we skip
   // backend and assemble phases to output LLVM IR. Except for generating
   // non-relocatable device coee, where we generate fat binary for device


Index: clang/test/Driver/hip-phases.hip
===
--- clang/test/Driver/hip-phases.hip
+++ clang/test/Driver/hip-phases.hip
@@ -338,7 +338,7 @@
 // RL2-NB-NOT: linker
 // RL2-NB-NOT: offload
 
-// NL2-DAG: [[P4:[0-9]+]]: linker, {[[P0]], [[P2]]}, image, (host-[[T:hip]])
+// NL2-DAG: [[P4:[0-9]+]]: linker, {[[P0]], [[P2]]}, image
 // RL2-EM-DAG: [[P4:[0-9]+]]: linker, {[[P1]], [[P3]], [[P9]]}, image, (host-[[T]])
 // RL2-DEV-NOT: linker
 
@@ -455,3 +455,21 @@
 // PPELLVM2-DAG: [[P9:[0-9]+]]: offload, "device-[[T]] (amdgcn-amd-amdhsa:[[ARCH2]])" {[[P8]]}, ir
 // PPELLVM2-DAG: [[P10:[0-9]+]]: clang-offload-bundler, {[[P4]], [[P9]]}, ir, (device-hip, )
 // PPELLVM2-NOT: host
+
+// Test mixed HIP and C++ compilation. HIP program should have HIP offload kind.
+// C++ program should have no offload kind.
+
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED %s
+
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED-NEG %s
+
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (host-hip)
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx803)
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx900)
+// MIXED-DAG: input, "{{.*}}empty.cpp", c++
+// MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (host-hip)
+// MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (device-hip
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp

[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

[Zequan Wu via Phabricator via cfe-commits]

zequanwu updated this revision to Diff 413109.
zequanwu marked 4 inline comments as done.
zequanwu added a comment.

Address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

Files:
  clang/lib/Format/NamespaceEndCommentsFixer.cpp
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp

Index: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
===
--- clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
+++ clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
@@ -68,6 +68,127 @@
 "int i;\n"
 "int j;\n"
 "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace M(x)",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::M(x)",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace M(x)::A",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A::inline M(x)::B {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::inline M(x)::B",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A::inline M(x)::B {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::inline M(x)::A",
+fixNamespaceEndComments(
+"#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ(
+  "namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ A {\n"
+  "int i;\n"
+  "int j;\n"
+  "}// namespace A",
+  fixNamespaceEndComments(
+  "namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ A {\n"
+  "int i;\n"
+  "int j;\n"
+  "}"));
+  EXPECT_EQ("namespace /* comment */ [[deprecated(\"foo\")]] A {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A",
+fixNamespaceEndComments(
+"namespace /* comment */ [[deprecated(\"foo\")]] A {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ(
+  "#define M(x) x##x\n"
+  "namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ M(x) {\n"
+  "int i;\n"
+  "int j;\n"
+  "}// namespace M(x)",
+  fixNamespaceEndComments("#define M(x) x##x\n"
+  "namespace /* comment */ "
+  "[[deprecated(\"foo\")]] /* comment */ M(x) {\n"
+  "int i;\n"
+  "int j;\n"
+  "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ "
+"A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::M(x)",
+fixNamespaceEndComments(
+"#define M(x) x##x\n"
+"namespace /* comment */ "
+"[[deprecated(\"foo\")]] /* comment */ A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ "
+"M(x) /* comment */ {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace M(x)",
+fixNamespaceEndComments(
+"#define M(x) x##x\n"
+ 

[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

[Zequan Wu via Phabricator via cfe-commits]

zequanwu added inline comments.



Comment at: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp:112
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"

MyDeveloperDay wrote:
> Is this 2 bugs in one? I notice  you also handling attributes? is this a 
> different bug? (if so it should really be separate  (but we can let it slide 
> as long as the tests are thorough)
> 
> can you test:
> 
> ```
> namespace /* comment  */ [[ xxx ]]  /* comment */  A {
> int i;
> int j;
> }  // namespace  A
> 
> namespace /* comment  */ [[ xxx ]]   A {
> int i;
> int j;
> }  //  namespace A
> 
> namespace /* comment  */ [[ xxx ]]   /* comment */ M(x) {
> int i;
> int j;
> }  // namespace  M(x)
> 
> namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) {
> int i;
> int j;
> }  // namespace  A::M(x)
> 
> namespace /* comment  */ [[ xxx ]]   /* comment */ M(x)  /* comment */ {
> int i;
> int j;
> }  // namespace  M(x)  
> 
> namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) /* comment */  {
> int i;
> int j;
> }  // namespace  A::M(x)
> ```
> Is this 2 bugs in one? I notice you also handling attributes? 
No. This tests with attribute is here to test that candidate name doesn't 
include attributes, but that is unnecessary. Added the 6 tests above for 
testing that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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

[PATCH] D119910: [clang][debug] port clang-cl /JMC flag to ELF

[Yuanfang Chen via Phabricator via cfe-commits]

ychen added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5372
+  // This controls whether or not we perform JustMyCode instrumentation.
+  if (TC.getTriple().isOSBinFormatELF() && Args.hasArg(options::OPT_fjmc)) {
+if (DebugInfoKind >= codegenoptions::DebugInfoConstructor)

rnk wrote:
> Generally all flags have an fno- variant. Normally, this would be 
> `hasFlag(OPT_fjmc, OPT_fno_jmc, false)`, which handles the behavior of making 
> the last flag win. Any reason not to set that up?
I missed that. Before this port, `fjmc` is supposed to be used as cc1 option 
only. With this port, it is also a driver option now. I'll add the no-variant.



Comment at: llvm/lib/CodeGen/JMCInstrumenter.cpp:177
+DefaultCheckFunc->setName(CheckFunctionName);
+DefaultCheckFunc->setLinkage(GlobalValue::WeakODRLinkage);
+CheckFunction = DefaultCheckFunc;

rnk wrote:
> This is a bit pedantic, but the idea is that this weak function will be 
> overridden with a strong function, right? Technically, for that use case, 
> `weak` linkage is the correct linkage. Because the JMC pass runs late after 
> inlining, it is unlikely that this will ever cause issues in practice, but I 
> think it expresses the intention better to use the linkage that matches the 
> use case.
> 
> ODR linkage is supposed to indicate that all definitions must be functionally 
> equivalent. It just turns out that the only real power that grants the 
> optimizer is the ability to inline.
Agreed. I'll change it to `weak` linkage.



Comment at: llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll:1
-; REQUIRES: system-windows
-; RUN: opt -jmc-instrument -mtriple=x86_64-pc-windows-msvc  -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=aarch64-pc-windows-msvc -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=arm-pc-windows-msvc -S < %s | 
FileCheck %s
+; REQUIRES: system-linux
+; RUN: opt -jmc-instrument -mtriple=x86_64-unknown-linux-gnu  -S < %s | 
FileCheck %s

rnk wrote:
> Please remove the REQUIRES line, this test should pass on Windows, and the 
> other test should pass on Linux as well. Neither of these tests depend on 
> anything from the system.
Yeah, this is a little tricky. It is about the host rather than the target. The 
flag symbol name is computed using `sys::path` functions. It is different 
between Windows and Linux. For testing purposes, I need to anchor them to a 
specific system to check the result. I could've made this `; REQUIRES: 
system-windows` and check the result, I thought it is more intuitive to test 
the ELF on Linux.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119910

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

[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added inline comments.



Comment at: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp:112
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"

zequanwu wrote:
> MyDeveloperDay wrote:
> > Is this 2 bugs in one? I notice  you also handling attributes? is this a 
> > different bug? (if so it should really be separate  (but we can let it 
> > slide as long as the tests are thorough)
> > 
> > can you test:
> > 
> > ```
> > namespace /* comment  */ [[ xxx ]]  /* comment */  A {
> > int i;
> > int j;
> > }  // namespace  A
> > 
> > namespace /* comment  */ [[ xxx ]]   A {
> > int i;
> > int j;
> > }  //  namespace A
> > 
> > namespace /* comment  */ [[ xxx ]]   /* comment */ M(x) {
> > int i;
> > int j;
> > }  // namespace  M(x)
> > 
> > namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) {
> > int i;
> > int j;
> > }  // namespace  A::M(x)
> > 
> > namespace /* comment  */ [[ xxx ]]   /* comment */ M(x)  /* comment */ {
> > int i;
> > int j;
> > }  // namespace  M(x)  
> > 
> > namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) /* comment */  {
> > int i;
> > int j;
> > }  // namespace  A::M(x)
> > ```
> > Is this 2 bugs in one? I notice you also handling attributes? 
> No. This tests with attribute is here to test that candidate name doesn't 
> include attributes, but that is unnecessary. Added the 6 tests above for 
> testing that.
Where are you checking the addition of this

```
if (Tok && Tok->is(tok::l_square)) {
  int NestLevel = 1;
  while (Tok && NestLevel > 0) {
Tok = Tok->getNextNonComment();
if (Tok) {
  if (Tok->is(tok::l_square))
++NestLevel;
  if (Tok->is(tok::r_square))
--NestLevel;
}
  }
  if (Tok)
Tok = Tok->getNextNonComment();
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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

[PATCH] D119040: Fix LookupTest where it was missing an assertion

[Paul Robinson via Phabricator via cfe-commits]

probinson added a reviewer: hokein.
probinson added a subscriber: hokein.
probinson added a comment.
Herald added a project: All.

+ @hokein  who has done work in the one place where `replaceNestedName` is used.


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

https://reviews.llvm.org/D119040

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

[PATCH] D120911: [CUDA][HIP] Fix offloading kind for linking C++ programs

[Yaxun Liu 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 rGe5eb365069cc: [CUDA][HIP] Fix offloading kind for linking 
C++ programs (authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120911

Files:
  clang/include/clang/Driver/Action.h
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/hip-phases.hip

Index: clang/test/Driver/hip-phases.hip
===
--- clang/test/Driver/hip-phases.hip
+++ clang/test/Driver/hip-phases.hip
@@ -459,17 +459,65 @@
 // Test mixed HIP and C++ compilation. HIP program should have HIP offload kind.
 // C++ program should have no offload kind.
 
+// Test compile empty.hip and empty.cpp.
 // RUN: %clang -target x86_64-unknown-linux-gnu \
 // RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
 // RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED %s
-
 // RUN: %clang -target x86_64-unknown-linux-gnu \
 // RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
 // RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED-NEG %s
 
+// Test compile and link empty.hip and empty.cpp.
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED %s
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED-NEG %s
+
+// Test compile and link empty.hip and empty.cpp with --hip-link -fgpu-rdc.
+// RUN: %clang -target x86_64-unknown-linux-gnu --hip-link -fgpu-rdc \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED %s
+// RUN: %clang -target x86_64-unknown-linux-gnu --hip-link -fgpu-rdc \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED-NEG %s
+
+// Test compile and link -x hip empty.hip and -x c++ empty.cpp.
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -x hip %S/Inputs/empty.hip -x c++ %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED %s
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -x hip %S/Inputs/empty.hip -x c++ %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED-NEG %s
+
+// Test compile and link -x hip empty.hip and empty.cpp.
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -x hip %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED2 %s
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -x hip %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED2-NEG %s
+
+// Test compile and link empty.hip and -x hip empty.cpp.
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: %S/Inputs/empty.hip -x hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED2 %s
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -x hip %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED2-NEG %s
+
 // MIXED-DAG: input, "{{.*}}empty.hip", hip, (host-hip)
 // MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx803)
 // MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx900)
 // MIXED-DAG: input, "{{.*}}empty.cpp", c++
 // MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (host-hip)
 // MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (device-hip
+
+// MIXED2-DAG: input, "{{.*}}empty.hip", hip, (host-hip)
+// MIXED2-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx803)
+// MIXED2-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx900)
+// MIXED2-DAG: input, "{{.*}}empty.cpp", hip, (host-hip)
+// MIXED2-DAG: input, "{{.*}}empty.cpp", hip, (device-hip, gfx803)
+// MIXED2-DAG: input, "{{.*}}empty.cpp", hip, (device-hip, gfx900)
+// MIXED2-NEG-NOT: input, "{{.*}}empty.cpp", c++
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -2465,6 +2465,9 @@
   /// Map between an input argument and the offloa

[clang] e5eb365 - [CUDA][HIP] Fix offloading kind for linking C++ programs

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2022-03-04T15:56:54-05:00
New Revision: e5eb365069cce7bb642421d53a1d3964f8d5bdb7

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

LOG: [CUDA][HIP] Fix offloading kind for linking C++ programs

When both CUDA or HIP programs and C++ programs are passed
to clang driver without -c, C++ programs are treated as CUDA
or HIP program, which is incorrect.

This is because action builder sets the offloading kind of input
job actions to the linking action to be the union of offloading
kind of the input job actions, i.e. if there is one HIP or CUDA
input to the linker, then all the input to the linker is marked
as HIP or CUDA.

To fix this issue, the offload action builder tracks the originating
input argument of each host action, which allows it to determine
the active offload kind of each host action. Then the offload
kind of each input action to the linker can be determined
individually.

Reviewed by: Artem Belevich

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

Added: 


Modified: 
clang/include/clang/Driver/Action.h
clang/lib/Driver/Driver.cpp
clang/test/Driver/hip-phases.hip

Removed: 




diff  --git a/clang/include/clang/Driver/Action.h 
b/clang/include/clang/Driver/Action.h
index 3b6c9e31faa3e..458a10ee11274 100644
--- a/clang/include/clang/Driver/Action.h
+++ b/clang/include/clang/Driver/Action.h
@@ -189,6 +189,11 @@ class Action {
   /// dependences.
   void propagateHostOffloadInfo(unsigned OKinds, const char *OArch);
 
+  void setHostOffloadInfo(unsigned OKinds, const char *OArch) {
+ActiveOffloadKindMask |= OKinds;
+OffloadingArch = OArch;
+  }
+
   /// Set the offload info of this action to be the same as the provided 
action,
   /// and propagate it to its dependences.
   void propagateOffloadInfo(const Action *A);

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 00d8f1b3b374e..488f0164c7336 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -2465,6 +2465,9 @@ class OffloadingActionBuilder final {
   /// Map between an input argument and the offload kinds used to process it.
   std::map InputArgToOffloadKindMap;
 
+  /// Map between a host action and its originating input argument.
+  std::map HostActionToInputArgMap;
+
   /// Builder interface. It doesn't build anything or keep any state.
   class DeviceActionBuilder {
   public:
@@ -3449,6 +3452,17 @@ class OffloadingActionBuilder final {
   delete SB;
   }
 
+  /// Record a host action and its originating input argument.
+  void recordHostAction(Action *HostAction, const Arg *InputArg) {
+assert(HostAction && "Invalid host action");
+assert(InputArg && "Invalid input argument");
+auto Loc = HostActionToInputArgMap.find(HostAction);
+if (Loc == HostActionToInputArgMap.end())
+  HostActionToInputArgMap[HostAction] = InputArg;
+assert(HostActionToInputArgMap[HostAction] == InputArg &&
+   "host action mapped to multiple input arguments");
+  }
+
   /// Generate an action that adds device dependences (if any) to a host 
action.
   /// If no device dependence actions exist, just return the host action \a
   /// HostAction. If an error is found or if no builder requires the host 
action
@@ -3464,6 +3478,7 @@ class OffloadingActionBuilder final {
   return HostAction;
 
 assert(HostAction && "Invalid host action!");
+recordHostAction(HostAction, InputArg);
 
 OffloadAction::DeviceDependences DDeps;
 // Check if all the programming models agree we should not emit the host
@@ -3517,6 +3532,8 @@ class OffloadingActionBuilder final {
 if (!IsValid)
   return true;
 
+recordHostAction(HostAction, InputArg);
+
 // If we are supporting bundling/unbundling and the current action is an
 // input action of non-source file, we replace the host action by the
 // unbundling action. The bundler tool has the logic to detect if an input
@@ -3533,6 +3550,7 @@ class OffloadingActionBuilder final {
   C.getSingleOffloadToolChain(),
   /*BoundArch=*/StringRef(), Action::OFK_Host);
   HostAction = UnbundlingHostAction;
+  recordHostAction(HostAction, InputArg);
 }
 
 assert(HostAction && "Invalid host action!");
@@ -3569,6 +3587,9 @@ class OffloadingActionBuilder final {
   /// programming models allow it.
   bool appendTopLevelActions(ActionList &AL, Action *HostAction,
  const Arg *InputArg) {
+if (HostAction)
+  recordHostAction(HostAction, InputArg);
+
 // Get the device actions to be appended.
 ActionList OffloadAL;
 for (auto *SB : SpecializedBuilders) {
@@ -3590,6 +3611,7 @@ class OffloadingActionBuilder final {
   // before this method was called.
   assert(HostA

[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

[Zequan Wu via Phabricator via cfe-commits]

zequanwu added inline comments.



Comment at: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp:112
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"

MyDeveloperDay wrote:
> zequanwu wrote:
> > MyDeveloperDay wrote:
> > > Is this 2 bugs in one? I notice  you also handling attributes? is this a 
> > > different bug? (if so it should really be separate  (but we can let it 
> > > slide as long as the tests are thorough)
> > > 
> > > can you test:
> > > 
> > > ```
> > > namespace /* comment  */ [[ xxx ]]  /* comment */  A {
> > > int i;
> > > int j;
> > > }  // namespace  A
> > > 
> > > namespace /* comment  */ [[ xxx ]]   A {
> > > int i;
> > > int j;
> > > }  //  namespace A
> > > 
> > > namespace /* comment  */ [[ xxx ]]   /* comment */ M(x) {
> > > int i;
> > > int j;
> > > }  // namespace  M(x)
> > > 
> > > namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) {
> > > int i;
> > > int j;
> > > }  // namespace  A::M(x)
> > > 
> > > namespace /* comment  */ [[ xxx ]]   /* comment */ M(x)  /* comment */ {
> > > int i;
> > > int j;
> > > }  // namespace  M(x)  
> > > 
> > > namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) /* comment */ 
> > >  {
> > > int i;
> > > int j;
> > > }  // namespace  A::M(x)
> > > ```
> > > Is this 2 bugs in one? I notice you also handling attributes? 
> > No. This tests with attribute is here to test that candidate name doesn't 
> > include attributes, but that is unnecessary. Added the 6 tests above for 
> > testing that.
> Where are you checking the addition of this
> 
> ```
> if (Tok && Tok->is(tok::l_square)) {
>   int NestLevel = 1;
>   while (Tok && NestLevel > 0) {
> Tok = Tok->getNextNonComment();
> if (Tok) {
>   if (Tok->is(tok::l_square))
> ++NestLevel;
>   if (Tok->is(tok::r_square))
> --NestLevel;
> }
>   }
>   if (Tok)
> Tok = Tok->getNextNonComment();
> }
> ```
That part of code skips attribute so that `FirstNSName` doesn't add attribute 
string into its name.
In the following test case. it's tested. 
```
namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) {
int i;
int j;
}  // namespace  A::M(x)
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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

[clang] 22b6e81 - Fix test failure in openmp-offload.c

[Yaxun Liu via cfe-commits]

Author: Yaxun (Sam) Liu
Date: 2022-03-04T16:32:30-05:00
New Revision: 22b6e8173cb258fae5a7d332b6f9eb19e9ddf86f

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

LOG: Fix test failure in openmp-offload.c

Update active offload kind of actions for OpenMP programs.

The change is expected as of e5eb365069cce7bb642421d53a1d3964f8d5bdb7.

Added: 


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

Removed: 




diff  --git a/clang/test/Driver/openmp-offload.c 
b/clang/test/Driver/openmp-offload.c
index 424b484df99bd..0bfe5a1195fe1 100644
--- a/clang/test/Driver/openmp-offload.c
+++ b/clang/test/Driver/openmp-offload.c
@@ -234,9 +234,9 @@
 // CHK-PHASES-WITH-CUDA: 19: assembler, {18}, object, (device-openmp)
 // CHK-PHASES-WITH-CUDA: 20: linker, {19}, image, (device-openmp)
 // CHK-PHASES-WITH-CUDA: 21: offload, "device-openmp (nvptx64-nvidia-cuda)" 
{20}, image
-// CHK-PHASES-WITH-CUDA: 22: clang-offload-wrapper, {21}, ir, 
(host-cuda-openmp)
-// CHK-PHASES-WITH-CUDA: 23: backend, {22}, assembler, (host-cuda-openmp)
-// CHK-PHASES-WITH-CUDA: 24: assembler, {23}, object, (host-cuda-openmp)
+// CHK-PHASES-WITH-CUDA: 22: clang-offload-wrapper, {21}, ir, (host-openmp)
+// CHK-PHASES-WITH-CUDA: 23: backend, {22}, assembler, (host-openmp)
+// CHK-PHASES-WITH-CUDA: 24: assembler, {23}, object, (host-openmp)
 // CHK-PHASES-WITH-CUDA: 25: linker, {13, 24}, image, (host-cuda-openmp)
 
 /// ###



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

[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

[Owen Pan via Phabricator via cfe-commits]

owenpan added inline comments.



Comment at: clang/lib/Format/NamespaceEndCommentsFixer.cpp:45-54
+  int NestLevel = 1;
+  while (Tok && NestLevel > 0) {
+Tok = Tok->getNextNonComment();
+if (Tok) {
+  if (Tok->is(tok::l_square))
+++NestLevel;
+  if (Tok->is(tok::r_square))

To make the loop simpler and more efficient.



Comment at: clang/lib/Format/NamespaceEndCommentsFixer.cpp:59-60
+
+// Use the string after `namespace` until `{` or `::` or `(` as a name
+// candidate. If the name is empty, use the candicate.
+std::string FirstNSName;

Move "as a name candidate" to between "`namespace`" and "until".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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

[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

[Owen Pan via Phabricator via cfe-commits]

owenpan added inline comments.



Comment at: clang/lib/Format/NamespaceEndCommentsFixer.cpp:59-60
+
+// Use the string after `namespace` until `{` or `::` or `(` as a name
+// candidate. If the name is empty, use the candicate.
+std::string FirstNSName;

owenpan wrote:
> Move "as a name candidate" to between "`namespace`" and "until".
> Move "as a name candidate" to between "`namespace`" and "until".

Or move it to after "Use", i.e. "Use as a name candidate the string after ...".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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

[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

[Zequan Wu via Phabricator via cfe-commits]

zequanwu updated this revision to Diff 413139.
zequanwu marked 2 inline comments as done.
zequanwu added a comment.

update.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

Files:
  clang/lib/Format/NamespaceEndCommentsFixer.cpp
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp

Index: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
===
--- clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
+++ clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
@@ -68,6 +68,127 @@
 "int i;\n"
 "int j;\n"
 "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace M(x)",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::M(x)",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace M(x)::A",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A::inline M(x)::B {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::inline M(x)::B",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A::inline M(x)::B {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::inline M(x)::A",
+fixNamespaceEndComments(
+"#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ(
+  "namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ A {\n"
+  "int i;\n"
+  "int j;\n"
+  "}// namespace A",
+  fixNamespaceEndComments(
+  "namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ A {\n"
+  "int i;\n"
+  "int j;\n"
+  "}"));
+  EXPECT_EQ("namespace /* comment */ [[deprecated(\"foo\")]] A {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A",
+fixNamespaceEndComments(
+"namespace /* comment */ [[deprecated(\"foo\")]] A {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ(
+  "#define M(x) x##x\n"
+  "namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ M(x) {\n"
+  "int i;\n"
+  "int j;\n"
+  "}// namespace M(x)",
+  fixNamespaceEndComments("#define M(x) x##x\n"
+  "namespace /* comment */ "
+  "[[deprecated(\"foo\")]] /* comment */ M(x) {\n"
+  "int i;\n"
+  "int j;\n"
+  "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ "
+"A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::M(x)",
+fixNamespaceEndComments(
+"#define M(x) x##x\n"
+"namespace /* comment */ "
+"[[deprecated(\"foo\")]] /* comment */ A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ "
+"M(x) /* comment */ {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace M(x)",
+fixNamespaceEndComments(
+"#define M(x) x##x\n"
+   

[PATCH] D119918: [CMake] Rename TARGET_TRIPLE to LLVM_TARGET_TRIPLE

[Petr Hosek via Phabricator via cfe-commits]

phosek updated this revision to Diff 413141.
phosek added a comment.

Rebase


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

https://reviews.llvm.org/D119918

Files:
  bolt/test/Unit/lit.site.cfg.py.in
  bolt/test/lit.site.cfg.py.in
  clang-tools-extra/clangd/test/lit.site.cfg.py.in
  clang-tools-extra/test/Unit/lit.site.cfg.py.in
  clang-tools-extra/test/lit.site.cfg.py.in
  clang/test/Unit/lit.site.cfg.py.in
  clang/test/lit.site.cfg.py.in
  clang/utils/perf-training/lit.site.cfg.in
  clang/utils/perf-training/order-files.lit.site.cfg.in
  compiler-rt/cmake/Modules/AddCompilerRT.cmake
  compiler-rt/cmake/Modules/CompilerRTMockLLVMCMakeConfig.cmake
  compiler-rt/cmake/Modules/CompilerRTUtils.cmake
  compiler-rt/test/fuzzer/lit.site.cfg.py.in
  compiler-rt/unittests/lit.common.unit.configured.in
  cross-project-tests/lit.site.cfg.py.in
  flang/test/NonGtestUnit/lit.site.cfg.py.in
  flang/test/Unit/lit.site.cfg.py.in
  lld/test/Unit/lit.site.cfg.py.in
  lld/test/lit.site.cfg.py.in
  lldb/test/API/lit.site.cfg.py.in
  lldb/test/CMakeLists.txt
  lldb/test/Shell/lit.site.cfg.py.in
  lldb/test/Unit/lit.site.cfg.py.in
  lldb/test/lit.site.cfg.py.in
  llvm/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/cmake/modules/CrossCompile.cmake
  llvm/cmake/modules/LLVMConfig.cmake.in
  llvm/runtimes/CMakeLists.txt
  llvm/test/lit.site.cfg.py.in
  llvm/utils/gn/secondary/clang-tools-extra/clangd/test/BUILD.gn
  llvm/utils/gn/secondary/clang-tools-extra/test/BUILD.gn
  llvm/utils/gn/secondary/clang/test/BUILD.gn
  llvm/utils/gn/secondary/lld/test/BUILD.gn
  llvm/utils/gn/secondary/lldb/test/BUILD.gn
  llvm/utils/gn/secondary/llvm/test/BUILD.gn
  mlir/examples/standalone/test/lit.site.cfg.py.in
  mlir/test/lit.site.cfg.py.in
  polly/test/Unit/lit.site.cfg.in
  polly/test/lit.site.cfg.in

Index: polly/test/lit.site.cfg.in
===
--- polly/test/lit.site.cfg.in
+++ polly/test/lit.site.cfg.in
@@ -6,7 +6,7 @@
 config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
 config.polly_obj_root = "@POLLY_BINARY_DIR@"
 config.polly_lib_dir = "@POLLY_LIB_DIR@"
-config.target_triple = "@TARGET_TRIPLE@"
+config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.enable_gpgpu_codegen = "@GPU_CODEGEN@"
 config.llvm_polly_link_into_tools = "@LLVM_POLLY_LINK_INTO_TOOLS@"
 config.targets_to_build = "@TARGETS_TO_BUILD@"
@@ -15,7 +15,7 @@
 ## Check the current platform with regex
 import re
 EAT_ERR_ON_X86 = ' '
-if (re.match(r'^x86_64*', '@TARGET_TRIPLE@') == None) :
+if (re.match(r'^x86_64*', '@LLVM_TARGET_TRIPLE@') == None) :
   EAT_ERR_ON_X86 = '|| echo \"error is eaten\"'
 
 for arch in config.targets_to_build.split():
Index: polly/test/Unit/lit.site.cfg.in
===
--- polly/test/Unit/lit.site.cfg.in
+++ polly/test/Unit/lit.site.cfg.in
@@ -11,7 +11,7 @@
 config.polly_lib_dir = "@POLLY_LIB_DIR@"
 config.enable_shared = @ENABLE_SHARED@
 config.shlibdir = "@SHLIBDIR@"
-config.target_triple = "@TARGET_TRIPLE@"
+config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.enable_gpgpu_codegen = "@GPU_CODEGEN@"
 config.llvm_polly_link_into_tools = "@LLVM_POLLY_LINK_INTO_TOOLS@"
 config.has_unittests = @POLLY_GTEST_AVAIL@
Index: mlir/test/lit.site.cfg.py.in
===
--- mlir/test/lit.site.cfg.py.in
+++ mlir/test/lit.site.cfg.py.in
@@ -3,7 +3,7 @@
 import sys
 
 config.host_triple = "@LLVM_HOST_TRIPLE@"
-config.target_triple = "@TARGET_TRIPLE@"
+config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
Index: mlir/examples/standalone/test/lit.site.cfg.py.in
===
--- mlir/examples/standalone/test/lit.site.cfg.py.in
+++ mlir/examples/standalone/test/lit.site.cfg.py.in
@@ -3,7 +3,7 @@
 import sys
 
 config.host_triple = "@LLVM_HOST_TRIPLE@"
-config.target_triple = "@TARGET_TRIPLE@"
+config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
Index: llvm/utils/gn/secondary/llvm/test/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/test/BUILD.gn
+++ llvm/utils/gn/secondary/llvm/test/BUILD.gn
@@ -72,7 +72,7 @@
 "LLVM_VERSION_SUFFIX=git",
 "Python3_EXECUTABLE=$python_path",
 "TARGETS_TO_BUILD=$llvm_targets_to_build_string",
-"TARGET_TRIPLE=$llvm_target_triple",
+"LLVM_TARGET_TRIPLE=$llvm_target_triple",
 
 "LLVM_LIBCXX_USED=0",
 
Index: llvm/utils/gn/secondary/lldb/test/BUILD.gn
===
--- llvm/utils/gn/secondary/lldb/test/BUILD.gn
+++ llvm/utils/gn/secondary/lldb/test/BUILD.gn
@@ -24,7 +24,7 @@
   "LLVM_SOURCE_DIR=" + rebase_path("//

[PATCH] D119910: [clang][debug] port clang-cl /JMC flag to ELF

[Yuanfang Chen via Phabricator via cfe-commits]

ychen updated this revision to Diff 413146.
ychen added a comment.
Herald added a subscriber: dang.

- Address Reid's comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119910

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/cl-options.c
  clang/test/Driver/clang_f_opts.c
  llvm/lib/CodeGen/JMCInstrumenter.cpp
  llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll
  llvm/test/Instrumentation/JustMyCode/jmc-instrument-x86.ll
  llvm/test/Instrumentation/JustMyCode/jmc-instrument.ll

Index: llvm/test/Instrumentation/JustMyCode/jmc-instrument-x86.ll
===
--- llvm/test/Instrumentation/JustMyCode/jmc-instrument-x86.ll
+++ llvm/test/Instrumentation/JustMyCode/jmc-instrument-x86.ll
@@ -11,12 +11,12 @@
 ; CHECK:   ret void
 ; CHECK: }
 
-; CHECK: declare x86_fastcallcc void @__CheckForDebuggerJustMyCode(i8* inreg noundef) unnamed_addr
-
 ; CHECK: define void @_JustMyCode_Default(i8* inreg noundef %0) unnamed_addr comdat {
 ; CHECK:   ret void
 ; CHECK: }
 
+; CHECK: declare x86_fastcallcc void @__CheckForDebuggerJustMyCode(i8* inreg noundef) unnamed_addr
+
 ; CHECK: !0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
 ; CHECK: !1 = distinct !DIGlobalVariable(name: "_A8764FDD_x@c", scope: !2, file: !3, type: !5, isLocal: true, isDefinition: true)
 ; CHECK: !2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "clang", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, globals: !4, splitDebugInlining: false, nameTableKind: None)
Index: llvm/test/Instrumentation/JustMyCode/jmc-instrument.ll
===
--- llvm/test/Instrumentation/JustMyCode/jmc-instrument.ll
+++ llvm/test/Instrumentation/JustMyCode/jmc-instrument.ll
@@ -6,8 +6,8 @@
 ; CHECK: $__JustMyCode_Default = comdat any
 
 ; CHECK: @"__E6EA670F_x@c" = internal unnamed_addr global i8 1, section ".msvcjmc", align 1, !dbg !0
-; CHECK: @"__A8764FDD_x@c" = internal unnamed_addr global i8 1, section ".msvcjmc", align 1, !dbg !5
 ; CHECK: @llvm.used = appending global [1 x i8*] [i8* bitcast (void (i8*)* @__JustMyCode_Default to i8*)], section "llvm.metadata"
+; CHECK: @"__A8764FDD_x@c" = internal unnamed_addr global i8 1, section ".msvcjmc", align 1, !dbg !5
 
 ; CHECK: define void @l1() !dbg !13 {
 ; CHECK:   call void @__CheckForDebuggerJustMyCode(i8* noundef @"__E6EA670F_x@c")
@@ -39,12 +39,12 @@
 ; CHECK:   ret void
 ; CHECK: }
 
-; CHECK: declare void @__CheckForDebuggerJustMyCode(i8* noundef) unnamed_addr
-
 ; CHECK: define void @__JustMyCode_Default(i8* noundef %0) unnamed_addr comdat {
 ; CHECK:   ret void
 ; CHECK: }
 
+; CHECK: declare void @__CheckForDebuggerJustMyCode(i8* noundef) unnamed_addr
+
 ; CHECK: !llvm.linker.options = !{!12}
 
 ; CHECK: !0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
Index: llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll
===
--- llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll
+++ llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll
@@ -1,78 +1,72 @@
-; REQUIRES: system-windows
-; RUN: opt -jmc-instrument -mtriple=x86_64-pc-windows-msvc  -S < %s | FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=aarch64-pc-windows-msvc -S < %s | FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=arm-pc-windows-msvc -S < %s | FileCheck %s
+; REQUIRES: system-linux
+; RUN: opt -jmc-instrument -mtriple=x86_64-unknown-linux-gnu  -S < %s | FileCheck %s
 
-; CHECK: $__JustMyCode_Default = comdat any
+; CHECK: @"__7DF23CF5_x@c" = internal unnamed_addr global i8 1, section ".just.my.code", align 1, !dbg !0
+; CHECK: @"__A85D9D03_x@c" = internal unnamed_addr global i8 1, section ".just.my.code", align 1, !dbg !5
 
-; CHECK: @"__E6EA670F_x@c" = internal unnamed_addr global i8 1, section ".msvcjmc", align 1, !dbg !0
-; CHECK: @"__A8764FDD_x@c" = internal unnamed_addr global i8 1, section ".msvcjmc", align 1, !dbg !5
-; CHECK: @llvm.used = appending global [1 x i8*] [i8* bitcast (void (i8*)* @__JustMyCode_Default to i8*)], section "llvm.metadata"
-
-; CHECK: define void @l1() !dbg !13 {
-; CHECK:   call void @__CheckForDebuggerJustMyCode(i8* noundef @"__E6EA670F_x@c")
+; CHECK: define void @l1() !dbg !12 {
+; CHECK:   call void @__CheckForDebuggerJustMyCode(i8* noundef @"__7DF23CF5_x@c")
 ; CHECK:   ret void
 ; CHECK: }
 
-; CHECK: define void @l2() !dbg !17 {
-; CHECK:   call void @__CheckForDebuggerJustMyCode(i8* noundef @"__E6EA670F_x@c")
+; CHECK: define void @l2() !dbg !16 {
+; CHECK:   call void @__CheckForDebuggerJustMyCode(i8* noundef @"__7DF23CF5_x@c")
 ; CHECK:   ret void
 ; CHECK: }
 
-; CHECK: define void @w1() !dbg !19 {
-; CHECK:   call void @__CheckForDebuggerJustMyC

[PATCH] D119910: [clang][debug] port clang-cl /JMC flag to ELF

[Yuanfang Chen via Phabricator via cfe-commits]

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

@rnk, thanks for taking a look. Patch updated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119910

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