date:20210521

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

2021-05-21 Thread Balázs Benics via Phabricator via cfe-commits

steakhal updated this revision to Diff 346938.
steakhal added a comment.
Herald added a subscriber: manas.

Nothing changed, I'm just retriggering the pre-merge bots as my parent revision 
landed.


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

https://reviews.llvm.org/D102643

Files:
  clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp


Index: clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
===
--- clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
+++ clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
@@ -19,13 +19,6 @@
 #include "llvm/Config/llvm-config.h"
 #include "gtest/gtest.h"
 
-// FIXME: Use GTEST_SKIP() instead if GTest is updated to version 1.10.0
-#ifdef LLVM_WITH_Z3
-#define SKIP_WITHOUT_Z3
-#else
-#define SKIP_WITHOUT_Z3 return
-#endif
-
 namespace clang {
 namespace ento {
 namespace {
@@ -101,6 +94,15 @@
   });
 }
 
+class FalsePositiveRefutationBRVisitorTestBase : public testing::Test {
+public:
+  void SetUp() override {
+#ifndef LLVM_WITH_Z3
+GTEST_SKIP() << "Requires the LLVM_ENABLE_Z3_SOLVER cmake option.";
+#endif
+  }
+};
+
 // C++20 use constexpr below.
 const std::vector LazyAssumeArgs{
 "-Xclang", "-analyzer-config", "-Xclang", "eagerly-assume=false"};
@@ -108,8 +110,7 @@
 "-Xclang", "-analyzer-config", "-Xclang", "eagerly-assume=false",
 "-Xclang", "-analyzer-config", "-Xclang", "crosscheck-with-z3=true"};
 
-TEST(FalsePositiveRefutationBRVisitor, UnSatInTheMiddleNoReport) {
-  SKIP_WITHOUT_Z3;
+TEST_F(FalsePositiveRefutationBRVisitorTestBase, UnSatInTheMiddleNoReport) {
   constexpr auto Code = R"(
  void reachedWithContradiction();
  void reachedWithNoContradiction();
@@ -139,8 +140,8 @@
 "test.FalsePositiveGenerator:REACHED_WITH_CONTRADICTION\n");
 }
 
-TEST(FalsePositiveRefutationBRVisitor, UnSatAtErrorNodeWithNewSymbolNoReport) {
-  SKIP_WITHOUT_Z3;
+TEST_F(FalsePositiveRefutationBRVisitorTestBase,
+   UnSatAtErrorNodeWithNewSymbolNoReport) {
   constexpr auto Code = R"(
 void reportIfCanBeTrue(bool);
 void reachedWithNoContradiction();
@@ -170,9 +171,8 @@
 "test.FalsePositiveGenerator:CAN_BE_TRUE\n");
 }
 
-TEST(FalsePositiveRefutationBRVisitor,
- UnSatAtErrorNodeDueToRefinedConstraintNoReport) {
-  SKIP_WITHOUT_Z3;
+TEST_F(FalsePositiveRefutationBRVisitorTestBase,
+   UnSatAtErrorNodeDueToRefinedConstraintNoReport) {
   constexpr auto Code = R"(
 void reportIfCanBeTrue(bool);
 void reachedWithNoContradiction();


Index: clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
===
--- clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
+++ clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
@@ -19,13 +19,6 @@
 #include "llvm/Config/llvm-config.h"
 #include "gtest/gtest.h"
 
-// FIXME: Use GTEST_SKIP() instead if GTest is updated to version 1.10.0
-#ifdef LLVM_WITH_Z3
-#define SKIP_WITHOUT_Z3
-#else
-#define SKIP_WITHOUT_Z3 return
-#endif
-
 namespace clang {
 namespace ento {
 namespace {
@@ -101,6 +94,15 @@
   });
 }
 
+class FalsePositiveRefutationBRVisitorTestBase : public testing::Test {
+public:
+  void SetUp() override {
+#ifndef LLVM_WITH_Z3
+GTEST_SKIP() << "Requires the LLVM_ENABLE_Z3_SOLVER cmake option.";
+#endif
+  }
+};
+
 // C++20 use constexpr below.
 const std::vector LazyAssumeArgs{
 "-Xclang", "-analyzer-config", "-Xclang", "eagerly-assume=false"};
@@ -108,8 +110,7 @@
 "-Xclang", "-analyzer-config", "-Xclang", "eagerly-assume=false",
 "-Xclang", "-analyzer-config", "-Xclang", "crosscheck-with-z3=true"};
 
-TEST(FalsePositiveRefutationBRVisitor, UnSatInTheMiddleNoReport) {
-  SKIP_WITHOUT_Z3;
+TEST_F(FalsePositiveRefutationBRVisitorTestBase, UnSatInTheMiddleNoReport) {
   constexpr auto Code = R"(
  void reachedWithContradiction();
  void reachedWithNoContradiction();
@@ -139,8 +140,8 @@
 "test.FalsePositiveGenerator:REACHED_WITH_CONTRADICTION\n");
 }
 
-TEST(FalsePositiveRefutationBRVisitor, UnSatAtErrorNodeWithNewSymbolNoReport) {
-  SKIP_WITHOUT_Z3;
+TEST_F(FalsePositiveRefutationBRVisitorTestBase,
+   UnSatAtErrorNodeWithNewSymbolNoReport) {
   constexpr auto Code = R"(
 void reportIfCanBeTrue(bool);
 void reachedWithNoContradiction();
@@ -170,9 +171,8 @@
 "test.FalsePositiveGenerator:CAN_BE_TRUE\n");
 }
 
-TEST(FalsePositiveRefutationBRVisitor,
- UnSatAtErrorNodeDueToRefinedConstraintNoReport) {
-  SKIP_WITHOUT_Z3;
+TEST_F(FalsePositiveRefutationBRVisitorTestBase,
+   UnSatAtErrorNodeDueToRefinedConstraintNoReport) {
   constexpr auto Code = R"(
 void reportIfCanBeTrue(bool);
 void reachedWithNoContradiction();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:

[PATCH] D91949: [clang-format] Add BeforeStructInitialization option in BraceWrapping configuration

2021-05-21 Thread Anastasiia Lukianenko via Phabricator via cfe-commits

anastasiia_lukianenko updated this revision to Diff 346939.

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

https://reviews.llvm.org/D91949

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

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -5069,6 +5069,106 @@
 format(Input, Style));
 }
 
+TEST_F(FormatTest, BreakBeforeStructInitialization) {
+  FormatStyle Style = getLLVMStyle();
+  Style.ColumnLimit = 80;
+  Style.BreakBeforeBraces = FormatStyle::BS_Custom;
+  Style.BraceWrapping.BeforeStructInitialization = true;
+  Style.AlwaysBreakTemplateDeclarations = FormatStyle::BTDS_No;
+  verifyFormat("struct new_struct struct_name =\n"
+   "{a = 1};",
+   Style);
+  verifyFormat("struct new_struct struct_name =\n"
+   "{a = 1, b = 2};",
+   Style);
+  verifyFormat("struct new_struct struct_name =\n"
+   "{\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("typedef struct Foo =\n"
+   "{\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("static constexpr struct Foo =\n"
+   "{\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("template <> struct Foo =\n"
+   "{\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("struct =\n"
+   "{\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  // BeforeStructInitialization doesn't affect on AfterStruct behavior
+  Style.BraceWrapping.AfterStruct = false;
+  verifyFormat("struct new_struct struct_name {\n"
+   "  a = 1;\n"
+   "  b = 2;\n"
+   "};",
+   Style);
+  Style.BraceWrapping.AfterStruct = true;
+  verifyFormat("struct new_struct struct_name\n"
+   "{\n"
+   "  a = 1;\n"
+   "  b = 2;\n"
+   "};",
+   Style);
+  Style.BraceWrapping.BeforeStructInitialization = false;
+  verifyFormat("struct new_struct struct_name = {a = 1};", Style);
+  verifyFormat("struct new_struct struct_name = {a = 1, b = 2};", Style);
+  verifyFormat("struct new_struct struct_name = {\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("typedef struct Foo = {\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("static constexpr struct Foo = {\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("template <> struct Foo = {\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  verifyFormat("struct = {\n"
+   "a = 1,\n"
+   "b = 2,\n"
+   "};",
+   Style);
+  // BeforeStructInitialization doesn't affect on AfterStruct behavior
+  Style.BraceWrapping.AfterStruct = false;
+  verifyFormat("struct new_struct struct_name {\n"
+   "  a = 1;\n"
+   "  b = 2;\n"
+   "};",
+   Style);
+  Style.BraceWrapping.AfterStruct = true;
+  verifyFormat("struct new_struct struct_name\n"
+   "{\n"
+   "  a = 1;\n"
+   "  b = 2;\n"
+   "};",
+   Style);
+}
+
 TEST_F(FormatTest, BreakConstructorInitializersAfterColon) {
   FormatStyle Style = getLLVMStyle();
   Style.BreakConstructorInitializers = FormatStyle::BCIS_AfterColon;
@@ -16328,6 +16428,7 @@
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, BeforeCatch);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, BeforeElse);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, BeforeLambdaBody);
+  CHECK_PARSE_NESTED_BOOL(BraceWrapping, BeforeStructInitialization);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, BeforeWhile);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, IndentBraces);
   CHECK_PARSE_NESTED_BOOL(BraceWrapping, SplitEmptyFunction);
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2702,7 +2702,11 @@
   nextToken();
 }
   }
-  if (FormatTok->Tok.is(tok::l_brace)) {
+  if (InitialToken.is(tok::kw_struct

[PATCH] D97183: [analyzer] Add NoteTag for smart-ptr get()

2021-05-21 Thread Raphael Isemann via Phabricator via cfe-commits

teemperor added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:243
+  // If b is a get() expression, then we can return a note
+  if (auto Report = bugReportOnGet(Node, BRC, RHS)) {
+return Report;

LLVM-code style mandates no curly braces around single-line ifs.



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:256
+BugReporterContext &BRC, const Stmt *S, const SVal InnerPtrVal) {
+  if (const auto *DS = llvm::dyn_cast(S)) {
+const Decl *D = DS->getSingleDecl();

(I think this was already pointed out, but early-exits are the way to go in 
LLVM.

```
const auto *DS = llvm::dyn_cast(S));
if (!DS)
  return nullptr;
const Decl *D = DS->getSingleDecl();
const auto *VD = llvm::dyn_cast(D);
if (!VD)
  return nullptr;


``



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:179-180
+  // P.get()
+  if (const auto *InnerCastExpr =
+  llvm::dyn_cast(Sub)) {
+Sub = InnerCastExpr->getSubExpr();

RedDocMD wrote:
> vsavchenko wrote:
> > I think it's better to `IgnoreParensAndCasts` instead of manual traversal.
> What is IgnoreParensAndCasts`? I didn't find it in the source code anywhere 
> (ripgrep, that is).
Just a typo, the actual name is `IgnoreParenCasts` (Expr::IgnoreParenCasts)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97183

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

[clang] 49f9532 - [clang-repl] Tell the LLJIT the exact target triple we use.

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


Author: Vassil Vassilev
Date: 2021-05-21T08:16:42Z
New Revision: 49f9532165f0cc0485a7da84662ebf63d155652c

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

LOG: [clang-repl] Tell the LLJIT the exact target triple we use.

Some systems use a different data layout. For instance, s390x the layout of
machines with vector registers is different from the ones without. In such
cases, the JIT will automatically detect the vector registers and go out of
sync.

This patch tells the JIT what is the target triple of the generated code so that
both ends are in sync.

Discussion available in https://reviews.llvm.org/D96033. Thanks to @uweigand for
helping understand the issue.

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

Added: 


Modified: 
clang/lib/Interpreter/IncrementalExecutor.cpp
clang/lib/Interpreter/IncrementalExecutor.h
clang/lib/Interpreter/Interpreter.cpp

Removed: 




diff  --git a/clang/lib/Interpreter/IncrementalExecutor.cpp 
b/clang/lib/Interpreter/IncrementalExecutor.cpp
index f999e5eceaede..9a368d9122bcf 100644
--- a/clang/lib/Interpreter/IncrementalExecutor.cpp
+++ b/clang/lib/Interpreter/IncrementalExecutor.cpp
@@ -26,12 +26,14 @@
 namespace clang {
 
 IncrementalExecutor::IncrementalExecutor(llvm::orc::ThreadSafeContext &TSC,
- llvm::Error &Err)
+ llvm::Error &Err,
+ const llvm::Triple &Triple)
 : TSCtx(TSC) {
   using namespace llvm::orc;
   llvm::ErrorAsOutParameter EAO(&Err);
 
-  if (auto JitOrErr = LLJITBuilder().create())
+  auto JTMB = JITTargetMachineBuilder(Triple);
+  if (auto JitOrErr = LLJITBuilder().setJITTargetMachineBuilder(JTMB).create())
 Jit = std::move(*JitOrErr);
   else {
 Err = JitOrErr.takeError();

diff  --git a/clang/lib/Interpreter/IncrementalExecutor.h 
b/clang/lib/Interpreter/IncrementalExecutor.h
index c4e33a390942f..b4c6ddec10472 100644
--- a/clang/lib/Interpreter/IncrementalExecutor.h
+++ b/clang/lib/Interpreter/IncrementalExecutor.h
@@ -14,6 +14,7 @@
 #define LLVM_CLANG_LIB_INTERPRETER_INCREMENTALEXECUTOR_H
 
 #include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/Triple.h"
 #include "llvm/ExecutionEngine/Orc/ExecutionUtils.h"
 
 #include 
@@ -34,7 +35,8 @@ class IncrementalExecutor {
   llvm::orc::ThreadSafeContext &TSCtx;
 
 public:
-  IncrementalExecutor(llvm::orc::ThreadSafeContext &TSC, llvm::Error &Err);
+  IncrementalExecutor(llvm::orc::ThreadSafeContext &TSC, llvm::Error &Err,
+  const llvm::Triple &Triple);
   ~IncrementalExecutor();
 
   llvm::Error addModule(std::unique_ptr M);

diff  --git a/clang/lib/Interpreter/Interpreter.cpp 
b/clang/lib/Interpreter/Interpreter.cpp
index 79acb5bd68982..711a5e9ff0168 100644
--- a/clang/lib/Interpreter/Interpreter.cpp
+++ b/clang/lib/Interpreter/Interpreter.cpp
@@ -16,6 +16,7 @@
 #include "IncrementalExecutor.h"
 #include "IncrementalParser.h"
 
+#include "clang/AST/ASTContext.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/CodeGen/ModuleBuilder.h"
 #include "clang/CodeGen/ObjectFilePCHContainerOperations.h"
@@ -204,8 +205,11 @@ llvm::Expected 
Interpreter::Parse(llvm::StringRef Code) {
 llvm::Error Interpreter::Execute(Transaction &T) {
   assert(T.TheModule);
   if (!IncrExecutor) {
+const llvm::Triple &Triple =
+getCompilerInstance()->getASTContext().getTargetInfo().getTriple();
 llvm::Error Err = llvm::Error::success();
-IncrExecutor = std::make_unique(*TSCtx, Err);
+IncrExecutor = std::make_unique(*TSCtx, Err, Triple);
+
 if (Err)
   return Err;
   }



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

[clang] 89ea60f - [clang][deps] Explicitly enable C++ modules in a test

2021-05-21 Thread Jan Svoboda via cfe-commits


Author: Jan Svoboda
Date: 2021-05-21T10:25:02+02:00
New Revision: 89ea60f392aa0a98e8d7ed8baa8ccbbec14d4050

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

LOG: [clang][deps] Explicitly enable C++ modules in a test

In Apple Clang, enabling modules for C++ input requires additional flag: 
-fcxx-modules.

Added: 


Modified: 
clang/test/ClangScanDeps/Inputs/modules_inferred_cdb.json

Removed: 




diff  --git a/clang/test/ClangScanDeps/Inputs/modules_inferred_cdb.json 
b/clang/test/ClangScanDeps/Inputs/modules_inferred_cdb.json
index e88dc88fa1b49..23de66f74cfc3 100644
--- a/clang/test/ClangScanDeps/Inputs/modules_inferred_cdb.json
+++ b/clang/test/ClangScanDeps/Inputs/modules_inferred_cdb.json
@@ -1,7 +1,7 @@
 [
 {
   "directory": "DIR",
-  "command": "clang -E DIR/modules_cdb_input.cpp -FFRAMEWORKS -fmodules 
-fmodules-cache-path=DIR/module-cache -fimplicit-modules -fimplicit-module-maps 
-pedantic -Werror",
+  "command": "clang -E DIR/modules_cdb_input.cpp -FFRAMEWORKS -fmodules 
-fcxx-modules -fmodules-cache-path=DIR/module-cache -fimplicit-modules 
-fimplicit-module-maps -pedantic -Werror",
   "file": "DIR/modules_cdb_input.cpp"
 }
 ]



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

[PATCH] D102517: [clang] Add support for the "abstract" contextual keyword of MSVC

2021-05-21 Thread Hans Wennborg via Phabricator via cfe-commits

hans added a comment.

Looking good overall, just a few nits.

Out of curiosity, where would one run into this? Does MS use this in any 
library headers or such?




Comment at: clang/lib/Parse/ParseDeclCXX.cpp:3314
   if (getLangOpts().CPlusPlus && Tok.is(tok::identifier)) {
-VirtSpecifiers::Specifier Specifier = isCXX11VirtSpecifier(Tok);
-assert((Specifier == VirtSpecifiers::VS_Final ||
-Specifier == VirtSpecifiers::VS_GNU_Final ||
-Specifier == VirtSpecifiers::VS_Sealed) &&
+for (VirtSpecifiers::Specifier Specifier = isCXX11VirtSpecifier(Tok);
+ Specifier != VirtSpecifiers::VS_None;

This 'for' construct is hard to follow. I think it might be easier to follow as 
a while loop, maybe

```
while ((Specifier = isCXX11VirtSpecifier(Tok)) != VirtSpecifiers::VS_None) {
```

Also the "is" prefix in isCXX11VirtSpecifier is confusing given that it doesn't 
return a bool.



Comment at: clang/lib/Sema/DeclSpec.cpp:1479
+  case VS_Abstract:
+VS_abstractLoc = Loc;
+break;

nit: the other cases just use one line



Comment at: clang/lib/Sema/DeclSpec.cpp:1493
   case VS_Sealed: return "sealed";
+  case VS_Abstract:
+return "abstract";

nit: skip the newline for consistency here too



Comment at: clang/lib/Sema/SemaDecl.cpp:16449
 
-  if (FinalLoc.isValid())
+  if (IsAbstract) {
+Record->markAbstract();

nit: it would be more common in clang to omit the braces


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102517

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

[PATCH] D102906: [clang-tidy] Remark was added to clang tooling Diagnostic

2021-05-21 Thread Ivan Murashko via Phabricator via cfe-commits

ivanmurashko created this revision.
ivanmurashko added reviewers: aaron.ballman, alexfh, DmitryPolukhin, gribozavr2.
ivanmurashko added projects: clang, clang-tools-extra.
Herald added a subscriber: xazax.hun.
ivanmurashko requested review of this revision.
Herald added a subscriber: cfe-commits.

The diff adds `Remark` to `Diagnostic::Level` for clang tooling. That makes 
`Remark` diagnostic level ready to use in `clang-tidy` checks: the 
**clang-diagnostic-module-import** becomes visible as a part of the change

Test plan:

  ninja check-clang
  ninja check-clang-tools


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102906

Files:
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tools-extra/test/clang-tidy/infrastructure/Inputs/remarks/A.h
  
clang-tools-extra/test/clang-tidy/infrastructure/Inputs/remarks/module.modulemap
  clang-tools-extra/test/clang-tidy/infrastructure/remarks.cpp
  clang/include/clang/Tooling/Core/Diagnostic.h
  clang/include/clang/Tooling/DiagnosticsYaml.h
  clang/unittests/Tooling/DiagnosticsYamlTest.cpp

Index: clang/unittests/Tooling/DiagnosticsYamlTest.cpp
===
--- clang/unittests/Tooling/DiagnosticsYamlTest.cpp
+++ clang/unittests/Tooling/DiagnosticsYamlTest.cpp
@@ -47,10 +47,11 @@
  const std::string &Message, int FileOffset,
  const std::string &FilePath,
  const StringMap &Fix,
- const SmallVector &Ranges) {
+ const SmallVector &Ranges,
+ Diagnostic::Level DiagnosticLevel) {
   return Diagnostic(DiagnosticName,
 makeMessage(Message, FileOffset, FilePath, Fix, Ranges), {},
-Diagnostic::Warning, "path/to/build/directory");
+DiagnosticLevel, "path/to/build/directory");
 }
 
 static const char *YAMLContent =
@@ -102,6 +103,14 @@
 "Replacements:[]\n"
 "Level:   Warning\n"
 "BuildDirectory:  'path/to/build/directory'\n"
+"  - DiagnosticName:  'diagnostic#4'\n"
+"DiagnosticMessage:\n"
+"  Message: 'message #4'\n"
+"  FilePath:'path/to/source3.cpp'\n"
+"  FileOffset:  72\n"
+"  Replacements:[]\n"
+"Level:   Remark\n"
+"BuildDirectory:  'path/to/build/directory'\n"
 "...\n";
 
 TEST(DiagnosticsYamlTest, serializesDiagnostics) {
@@ -112,7 +121,8 @@
   {"path/to/source.cpp",
Replacements({"path/to/source.cpp", 100, 12, "replacement #1"})}};
   TUD.Diagnostics.push_back(makeDiagnostic("diagnostic#1", "message #1", 55,
-   "path/to/source.cpp", Fix1, {}));
+   "path/to/source.cpp", Fix1, {},
+   Diagnostic::Warning));
 
   StringMap Fix2 = {
   {"path/to/header.h",
@@ -120,15 +130,21 @@
   SmallVector Ranges2 =
   {makeByteRange(10, 10, "path/to/source.cpp")};
   TUD.Diagnostics.push_back(makeDiagnostic("diagnostic#2", "message #2", 60,
-   "path/to/header.h", Fix2, Ranges2));
+   "path/to/header.h", Fix2, Ranges2,
+   Diagnostic::Warning));
 
   TUD.Diagnostics.push_back(makeDiagnostic("diagnostic#3", "message #3", 72,
-   "path/to/source2.cpp", {}, {}));
+   "path/to/source2.cpp", {}, {},
+   Diagnostic::Warning));
   TUD.Diagnostics.back().Notes.push_back(
   makeMessage("Note1", 88, "path/to/note1.cpp", {}, {}));
   TUD.Diagnostics.back().Notes.push_back(
   makeMessage("Note2", 99, "path/to/note2.cpp", {}, {}));
 
+  TUD.Diagnostics.push_back(makeDiagnostic("diagnostic#4", "message #4", 72,
+   "path/to/source3.cpp", {}, {},
+   Diagnostic::Remark));
+
   std::string YamlContent;
   raw_string_ostream YamlContentStream(YamlContent);
 
@@ -144,7 +160,7 @@
   YAML >> TUDActual;
 
   ASSERT_FALSE(YAML.error());
-  ASSERT_EQ(3u, TUDActual.Diagnostics.size());
+  ASSERT_EQ(4u, TUDActual.Diagnostics.size());
   EXPECT_EQ("path/to/source.cpp", TUDActual.MainSourceFile);
 
   auto getFixes = [](const StringMap &Fix) {
Index: clang/include/clang/Tooling/DiagnosticsYaml.h
===
--- clang/include/clang/Tooling/DiagnosticsYaml.h
+++ clang/include/clang/Tooling/DiagnosticsYaml.h
@@ -106,6 +106,7 @@
   static void enumeration(IO &IO, clang::tooling::Diagnostic::Level &Value) {
 IO.enumCase(Value, "Warning", clang::tooling::Diagnostic::Warning);
 IO.enumCase(Value, "Error", clang::toolin

[clang] b5b3843 - [clang] Fix for "Bug 27113 - MSVC-compat __identifier implementation incomplete"

2021-05-21 Thread Hans Wennborg via cfe-commits


Author: Melvin Fox
Date: 2021-05-21T11:14:01+02:00
New Revision: b5b3843f8d9327039bbcc08b61ff768081a2220d

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

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

this patch fixes Bug 27113 by adding support for string literals to the
implementation of the MS extension __identifier.

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

Added: 


Modified: 
clang/lib/Lex/PPMacroExpansion.cpp
clang/test/Parser/MicrosoftExtensions.cpp

Removed: 




diff  --git a/clang/lib/Lex/PPMacroExpansion.cpp 
b/clang/lib/Lex/PPMacroExpansion.cpp
index 9528a8f575f0c..74ef9df592dbe 100644
--- a/clang/lib/Lex/PPMacroExpansion.cpp
+++ b/clang/lib/Lex/PPMacroExpansion.cpp
@@ -25,6 +25,7 @@
 #include "clang/Lex/ExternalPreprocessorSource.h"
 #include "clang/Lex/HeaderSearch.h"
 #include "clang/Lex/LexDiagnostic.h"
+#include "clang/Lex/LiteralSupport.h"
 #include "clang/Lex/MacroArgs.h"
 #include "clang/Lex/MacroInfo.h"
 #include "clang/Lex/Preprocessor.h"
@@ -1813,7 +1814,14 @@ void Preprocessor::ExpandBuiltinMacro(Token &Tok) {
 
 if (!Tok.isAnnotation() && Tok.getIdentifierInfo())
   Tok.setKind(tok::identifier);
-else {
+else if (Tok.is(tok::string_literal) && !Tok.hasUDSuffix()) {
+  StringLiteralParser Literal(Tok, *this);
+  if (Literal.hadError)
+return;
+
+  Tok.setIdentifierInfo(getIdentifierInfo(Literal.GetString()));
+  Tok.setKind(tok::identifier);
+} else {
   Diag(Tok.getLocation(), diag::err_pp_identifier_arg_not_identifier)
 << Tok.getKind();
   // Don't walk past anything that's not a real token.

diff  --git a/clang/test/Parser/MicrosoftExtensions.cpp 
b/clang/test/Parser/MicrosoftExtensions.cpp
index 9706eecce2db2..c625bf3d6befc 100644
--- a/clang/test/Parser/MicrosoftExtensions.cpp
+++ b/clang/test/Parser/MicrosoftExtensions.cpp
@@ -263,6 +263,12 @@ int k = identifier_weird(if)); // expected-error {{use of 
undeclared identifier
 
 extern int __identifier(and);
 
+int __identifier("baz") = 0;
+int bar = baz;
+
+void mangled_function();
+extern "C" void __identifier("?mangled_function@@YAXXZ")() {}
+
 void f() {
   __identifier(() // expected-error {{cannot convert '(' token to an 
identifier}}
   __identifier(void) // expected-error {{use of undeclared identifier 'void'}}
@@ -270,8 +276,10 @@ void f() {
   // FIXME: We should pick a friendlier display name for this token kind.
   __identifier(1) // expected-error {{cannot convert  token 
to an identifier}}
   __identifier(+) // expected-error {{cannot convert '+' token to an 
identifier}}
-  __identifier("foo") // expected-error {{cannot convert  
token to an identifier}}
   __identifier(;) // expected-error {{cannot convert ';' token to an 
identifier}}
+  __identifier("1"); // expected-error {{use of undeclared identifier '1'}}
+  __identifier("+"); // expected-error {{use of undeclared identifier '+'}}
+  __identifier(";"); // expected-error {{use of undeclared identifier ';'}}
 }
 
 class inline_definition_pure_spec {



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

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

2021-05-21 Thread Hans Wennborg 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 rGb5b3843f8d93: [clang] Fix for "Bug 27113 - MSVC-compat 
__identifier implementation incomplete" (authored by super_concat, 
committed by hans).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100252

Files:
  clang/lib/Lex/PPMacroExpansion.cpp
  clang/test/Parser/MicrosoftExtensions.cpp


Index: clang/test/Parser/MicrosoftExtensions.cpp
===
--- clang/test/Parser/MicrosoftExtensions.cpp
+++ clang/test/Parser/MicrosoftExtensions.cpp
@@ -263,6 +263,12 @@
 
 extern int __identifier(and);
 
+int __identifier("baz") = 0;
+int bar = baz;
+
+void mangled_function();
+extern "C" void __identifier("?mangled_function@@YAXXZ")() {}
+
 void f() {
   __identifier(() // expected-error {{cannot convert '(' token to an 
identifier}}
   __identifier(void) // expected-error {{use of undeclared identifier 'void'}}
@@ -270,8 +276,10 @@
   // FIXME: We should pick a friendlier display name for this token kind.
   __identifier(1) // expected-error {{cannot convert  token 
to an identifier}}
   __identifier(+) // expected-error {{cannot convert '+' token to an 
identifier}}
-  __identifier("foo") // expected-error {{cannot convert  
token to an identifier}}
   __identifier(;) // expected-error {{cannot convert ';' token to an 
identifier}}
+  __identifier("1"); // expected-error {{use of undeclared identifier '1'}}
+  __identifier("+"); // expected-error {{use of undeclared identifier '+'}}
+  __identifier(";"); // expected-error {{use of undeclared identifier ';'}}
 }
 
 class inline_definition_pure_spec {
Index: clang/lib/Lex/PPMacroExpansion.cpp
===
--- clang/lib/Lex/PPMacroExpansion.cpp
+++ clang/lib/Lex/PPMacroExpansion.cpp
@@ -25,6 +25,7 @@
 #include "clang/Lex/ExternalPreprocessorSource.h"
 #include "clang/Lex/HeaderSearch.h"
 #include "clang/Lex/LexDiagnostic.h"
+#include "clang/Lex/LiteralSupport.h"
 #include "clang/Lex/MacroArgs.h"
 #include "clang/Lex/MacroInfo.h"
 #include "clang/Lex/Preprocessor.h"
@@ -1813,7 +1814,14 @@
 
 if (!Tok.isAnnotation() && Tok.getIdentifierInfo())
   Tok.setKind(tok::identifier);
-else {
+else if (Tok.is(tok::string_literal) && !Tok.hasUDSuffix()) {
+  StringLiteralParser Literal(Tok, *this);
+  if (Literal.hadError)
+return;
+
+  Tok.setIdentifierInfo(getIdentifierInfo(Literal.GetString()));
+  Tok.setKind(tok::identifier);
+} else {
   Diag(Tok.getLocation(), diag::err_pp_identifier_arg_not_identifier)
 << Tok.getKind();
   // Don't walk past anything that's not a real token.


Index: clang/test/Parser/MicrosoftExtensions.cpp
===
--- clang/test/Parser/MicrosoftExtensions.cpp
+++ clang/test/Parser/MicrosoftExtensions.cpp
@@ -263,6 +263,12 @@
 
 extern int __identifier(and);
 
+int __identifier("baz") = 0;
+int bar = baz;
+
+void mangled_function();
+extern "C" void __identifier("?mangled_function@@YAXXZ")() {}
+
 void f() {
   __identifier(() // expected-error {{cannot convert '(' token to an identifier}}
   __identifier(void) // expected-error {{use of undeclared identifier 'void'}}
@@ -270,8 +276,10 @@
   // FIXME: We should pick a friendlier display name for this token kind.
   __identifier(1) // expected-error {{cannot convert  token to an identifier}}
   __identifier(+) // expected-error {{cannot convert '+' token to an identifier}}
-  __identifier("foo") // expected-error {{cannot convert  token to an identifier}}
   __identifier(;) // expected-error {{cannot convert ';' token to an identifier}}
+  __identifier("1"); // expected-error {{use of undeclared identifier '1'}}
+  __identifier("+"); // expected-error {{use of undeclared identifier '+'}}
+  __identifier(";"); // expected-error {{use of undeclared identifier ';'}}
 }
 
 class inline_definition_pure_spec {
Index: clang/lib/Lex/PPMacroExpansion.cpp
===
--- clang/lib/Lex/PPMacroExpansion.cpp
+++ clang/lib/Lex/PPMacroExpansion.cpp
@@ -25,6 +25,7 @@
 #include "clang/Lex/ExternalPreprocessorSource.h"
 #include "clang/Lex/HeaderSearch.h"
 #include "clang/Lex/LexDiagnostic.h"
+#include "clang/Lex/LiteralSupport.h"
 #include "clang/Lex/MacroArgs.h"
 #include "clang/Lex/MacroInfo.h"
 #include "clang/Lex/Preprocessor.h"
@@ -1813,7 +1814,14 @@
 
 if (!Tok.isAnnotation() && Tok.getIdentifierInfo())
   Tok.setKind(tok::identifier);
-else {
+else if (Tok.is(tok::string_literal) && !Tok.hasUDSuffix()) {
+  StringLiteralParser Literal(Tok, *this);
+  if (Literal.hadError)
+return;
+
+  Tok.setIdentifierInfo(getIdentifierInfo(Literal.GetString()));
+  Tok.setKind(

[clang] ebd25fd - [clang] Fix Wnested-anon-types in ABIArgInfo

2021-05-21 Thread Raphael Isemann via cfe-commits


Author: Raphael Isemann
Date: 2021-05-21T11:18:43+02:00
New Revision: ebd25fde5e04fa954f3fbad3fa0ee89f511a907a

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

LOG: [clang] Fix Wnested-anon-types in ABIArgInfo

D98794 added the DirectAttr/IndirectAttr struct fields to that union, but
declaring anonymous structs in an anonymous union triggers `-Wnested-anon-types`
warnings. We can't just give them a name as they are in an anonymous union, so
this just declares the type outside.

```
clang/include/clang/CodeGen/CGFunctionInfo.h:97:5: warning: anonymous types 
declared in an anonymous union are an extension [-Wnested-anon-types]
struct {
^
clang/include/clang/CodeGen/CGFunctionInfo.h:101:5: warning: anonymous types 
declared in an anonymous union are an extension [-Wnested-anon-types]
struct {
^
```

Reviewed By: chill

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

Added: 


Modified: 
clang/include/clang/CodeGen/CGFunctionInfo.h

Removed: 




diff  --git a/clang/include/clang/CodeGen/CGFunctionInfo.h 
b/clang/include/clang/CodeGen/CGFunctionInfo.h
index 91d867e7f64a5..4899c9deda6a3 100644
--- a/clang/include/clang/CodeGen/CGFunctionInfo.h
+++ b/clang/include/clang/CodeGen/CGFunctionInfo.h
@@ -93,15 +93,17 @@ class ABIArgInfo {
 llvm::Type *PaddingType; // canHavePaddingType()
 llvm::Type *UnpaddedCoerceAndExpandType; // isCoerceAndExpand()
   };
+  struct DirectAttrInfo {
+unsigned Offset;
+unsigned Align;
+  };
+  struct IndirectAttrInfo {
+unsigned Align;
+unsigned AddrSpace;
+  };
   union {
-struct {
-  unsigned Offset;
-  unsigned Align;
-} DirectAttr;  // isDirect() || isExtend()
-struct {
-  unsigned Align;
-  unsigned AddrSpace;
-} IndirectAttr;// isIndirect()
+DirectAttrInfo DirectAttr; // isDirect() || isExtend()
+IndirectAttrInfo IndirectAttr; // isIndirect()
 unsigned AllocaFieldIndex; // isInAlloca()
   };
   Kind TheKind;



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

[PATCH] D102903: [clang] Fix Wnested-anon-types in ABIArgInfo

2021-05-21 Thread Raphael Isemann 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 rGebd25fde5e04: [clang] Fix Wnested-anon-types in ABIArgInfo 
(authored by teemperor).
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D102903?vs=346942&id=346960#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102903

Files:
  clang/include/clang/CodeGen/CGFunctionInfo.h


Index: clang/include/clang/CodeGen/CGFunctionInfo.h
===
--- clang/include/clang/CodeGen/CGFunctionInfo.h
+++ clang/include/clang/CodeGen/CGFunctionInfo.h
@@ -93,15 +93,17 @@
 llvm::Type *PaddingType; // canHavePaddingType()
 llvm::Type *UnpaddedCoerceAndExpandType; // isCoerceAndExpand()
   };
+  struct DirectAttrInfo {
+unsigned Offset;
+unsigned Align;
+  };
+  struct IndirectAttrInfo {
+unsigned Align;
+unsigned AddrSpace;
+  };
   union {
-struct {
-  unsigned Offset;
-  unsigned Align;
-} DirectAttr;  // isDirect() || isExtend()
-struct {
-  unsigned Align;
-  unsigned AddrSpace;
-} IndirectAttr;// isIndirect()
+DirectAttrInfo DirectAttr; // isDirect() || isExtend()
+IndirectAttrInfo IndirectAttr; // isIndirect()
 unsigned AllocaFieldIndex; // isInAlloca()
   };
   Kind TheKind;


Index: clang/include/clang/CodeGen/CGFunctionInfo.h
===
--- clang/include/clang/CodeGen/CGFunctionInfo.h
+++ clang/include/clang/CodeGen/CGFunctionInfo.h
@@ -93,15 +93,17 @@
 llvm::Type *PaddingType; // canHavePaddingType()
 llvm::Type *UnpaddedCoerceAndExpandType; // isCoerceAndExpand()
   };
+  struct DirectAttrInfo {
+unsigned Offset;
+unsigned Align;
+  };
+  struct IndirectAttrInfo {
+unsigned Align;
+unsigned AddrSpace;
+  };
   union {
-struct {
-  unsigned Offset;
-  unsigned Align;
-} DirectAttr;  // isDirect() || isExtend()
-struct {
-  unsigned Align;
-  unsigned AddrSpace;
-} IndirectAttr;// isIndirect()
+DirectAttrInfo DirectAttr; // isDirect() || isExtend()
+IndirectAttrInfo IndirectAttr; // isIndirect()
 unsigned AllocaFieldIndex; // isInAlloca()
   };
   Kind TheKind;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102812: [clang] Don't pass multiple backend options if mixing -mimplicit-it and -Wa,-mimplicit-it

2021-05-21 Thread David Spickett via Phabricator via cfe-commits

DavidSpickett added a comment.

> Updated to allow mismatches and just picking the value that is set last on 
> the command line - what do you think of this version?

My initial reaction was that I'd prefer to take the last one that matches the 
input type, to be consistent with `-march` and `-mcpu`. `march` and `mcpu` 
effect both so it makes sense to switch on the input type.
However this is an option that only effects asm/inline asm (even when passed as 
a compiler option) so you could think of `-mimplicit-it` as an alias to 
`-Wa,-mimplicit-it`. So taking the last value we find sounds good to me.

Ideally we would warn about conflicting values but that's an enhancement that 
can be done another time if we see situations where it could have been useful.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102812

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

[clang] 3febf0b - [analyzer][Z3][NFC] Use GTEST_SKIP instead of hacks

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


Author: Balazs Benics
Date: 2021-05-21T11:35:24+02:00
New Revision: 3febf0b507e6257414d92744fd646840aa38e5d2

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

LOG: [analyzer][Z3][NFC] Use GTEST_SKIP instead of hacks

Since @bkramer bumped gtest to 1.10.0 I think it's a good time to clean
up some of my hacks.

Reviewed By: Szelethus

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

Added: 


Modified: 
clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp

Removed: 




diff  --git 
a/clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp 
b/clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
index e67dcacca0a9b..32bd3950d526c 100644
--- a/clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
+++ b/clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
@@ -19,13 +19,6 @@
 #include "llvm/Config/llvm-config.h"
 #include "gtest/gtest.h"
 
-// FIXME: Use GTEST_SKIP() instead if GTest is updated to version 1.10.0
-#ifdef LLVM_WITH_Z3
-#define SKIP_WITHOUT_Z3
-#else
-#define SKIP_WITHOUT_Z3 return
-#endif
-
 namespace clang {
 namespace ento {
 namespace {
@@ -101,6 +94,15 @@ void addFalsePositiveGenerator(AnalysisASTConsumer 
&AnalysisConsumer,
   });
 }
 
+class FalsePositiveRefutationBRVisitorTestBase : public testing::Test {
+public:
+  void SetUp() override {
+#ifndef LLVM_WITH_Z3
+GTEST_SKIP() << "Requires the LLVM_ENABLE_Z3_SOLVER cmake option.";
+#endif
+  }
+};
+
 // C++20 use constexpr below.
 const std::vector LazyAssumeArgs{
 "-Xclang", "-analyzer-config", "-Xclang", "eagerly-assume=false"};
@@ -108,8 +110,7 @@ const std::vector LazyAssumeAndCrossCheckArgs{
 "-Xclang", "-analyzer-config", "-Xclang", "eagerly-assume=false",
 "-Xclang", "-analyzer-config", "-Xclang", "crosscheck-with-z3=true"};
 
-TEST(FalsePositiveRefutationBRVisitor, UnSatInTheMiddleNoReport) {
-  SKIP_WITHOUT_Z3;
+TEST_F(FalsePositiveRefutationBRVisitorTestBase, UnSatInTheMiddleNoReport) {
   constexpr auto Code = R"(
  void reachedWithContradiction();
  void reachedWithNoContradiction();
@@ -139,8 +140,8 @@ TEST(FalsePositiveRefutationBRVisitor, 
UnSatInTheMiddleNoReport) {
 "test.FalsePositiveGenerator:REACHED_WITH_CONTRADICTION\n");
 }
 
-TEST(FalsePositiveRefutationBRVisitor, UnSatAtErrorNodeWithNewSymbolNoReport) {
-  SKIP_WITHOUT_Z3;
+TEST_F(FalsePositiveRefutationBRVisitorTestBase,
+   UnSatAtErrorNodeWithNewSymbolNoReport) {
   constexpr auto Code = R"(
 void reportIfCanBeTrue(bool);
 void reachedWithNoContradiction();
@@ -170,9 +171,8 @@ TEST(FalsePositiveRefutationBRVisitor, 
UnSatAtErrorNodeWithNewSymbolNoReport) {
 "test.FalsePositiveGenerator:CAN_BE_TRUE\n");
 }
 
-TEST(FalsePositiveRefutationBRVisitor,
- UnSatAtErrorNodeDueToRefinedConstraintNoReport) {
-  SKIP_WITHOUT_Z3;
+TEST_F(FalsePositiveRefutationBRVisitorTestBase,
+   UnSatAtErrorNodeDueToRefinedConstraintNoReport) {
   constexpr auto Code = R"(
 void reportIfCanBeTrue(bool);
 void reachedWithNoContradiction();



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

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

2021-05-21 Thread Balázs Benics via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG3febf0b507e6: [analyzer][Z3][NFC] Use GTEST_SKIP instead of 
hacks (authored by steakhal).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102643

Files:
  clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp


Index: clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
===
--- clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
+++ clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
@@ -19,13 +19,6 @@
 #include "llvm/Config/llvm-config.h"
 #include "gtest/gtest.h"
 
-// FIXME: Use GTEST_SKIP() instead if GTest is updated to version 1.10.0
-#ifdef LLVM_WITH_Z3
-#define SKIP_WITHOUT_Z3
-#else
-#define SKIP_WITHOUT_Z3 return
-#endif
-
 namespace clang {
 namespace ento {
 namespace {
@@ -101,6 +94,15 @@
   });
 }
 
+class FalsePositiveRefutationBRVisitorTestBase : public testing::Test {
+public:
+  void SetUp() override {
+#ifndef LLVM_WITH_Z3
+GTEST_SKIP() << "Requires the LLVM_ENABLE_Z3_SOLVER cmake option.";
+#endif
+  }
+};
+
 // C++20 use constexpr below.
 const std::vector LazyAssumeArgs{
 "-Xclang", "-analyzer-config", "-Xclang", "eagerly-assume=false"};
@@ -108,8 +110,7 @@
 "-Xclang", "-analyzer-config", "-Xclang", "eagerly-assume=false",
 "-Xclang", "-analyzer-config", "-Xclang", "crosscheck-with-z3=true"};
 
-TEST(FalsePositiveRefutationBRVisitor, UnSatInTheMiddleNoReport) {
-  SKIP_WITHOUT_Z3;
+TEST_F(FalsePositiveRefutationBRVisitorTestBase, UnSatInTheMiddleNoReport) {
   constexpr auto Code = R"(
  void reachedWithContradiction();
  void reachedWithNoContradiction();
@@ -139,8 +140,8 @@
 "test.FalsePositiveGenerator:REACHED_WITH_CONTRADICTION\n");
 }
 
-TEST(FalsePositiveRefutationBRVisitor, UnSatAtErrorNodeWithNewSymbolNoReport) {
-  SKIP_WITHOUT_Z3;
+TEST_F(FalsePositiveRefutationBRVisitorTestBase,
+   UnSatAtErrorNodeWithNewSymbolNoReport) {
   constexpr auto Code = R"(
 void reportIfCanBeTrue(bool);
 void reachedWithNoContradiction();
@@ -170,9 +171,8 @@
 "test.FalsePositiveGenerator:CAN_BE_TRUE\n");
 }
 
-TEST(FalsePositiveRefutationBRVisitor,
- UnSatAtErrorNodeDueToRefinedConstraintNoReport) {
-  SKIP_WITHOUT_Z3;
+TEST_F(FalsePositiveRefutationBRVisitorTestBase,
+   UnSatAtErrorNodeDueToRefinedConstraintNoReport) {
   constexpr auto Code = R"(
 void reportIfCanBeTrue(bool);
 void reachedWithNoContradiction();


Index: clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
===
--- clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
+++ clang/unittests/StaticAnalyzer/FalsePositiveRefutationBRVisitorTest.cpp
@@ -19,13 +19,6 @@
 #include "llvm/Config/llvm-config.h"
 #include "gtest/gtest.h"
 
-// FIXME: Use GTEST_SKIP() instead if GTest is updated to version 1.10.0
-#ifdef LLVM_WITH_Z3
-#define SKIP_WITHOUT_Z3
-#else
-#define SKIP_WITHOUT_Z3 return
-#endif
-
 namespace clang {
 namespace ento {
 namespace {
@@ -101,6 +94,15 @@
   });
 }
 
+class FalsePositiveRefutationBRVisitorTestBase : public testing::Test {
+public:
+  void SetUp() override {
+#ifndef LLVM_WITH_Z3
+GTEST_SKIP() << "Requires the LLVM_ENABLE_Z3_SOLVER cmake option.";
+#endif
+  }
+};
+
 // C++20 use constexpr below.
 const std::vector LazyAssumeArgs{
 "-Xclang", "-analyzer-config", "-Xclang", "eagerly-assume=false"};
@@ -108,8 +110,7 @@
 "-Xclang", "-analyzer-config", "-Xclang", "eagerly-assume=false",
 "-Xclang", "-analyzer-config", "-Xclang", "crosscheck-with-z3=true"};
 
-TEST(FalsePositiveRefutationBRVisitor, UnSatInTheMiddleNoReport) {
-  SKIP_WITHOUT_Z3;
+TEST_F(FalsePositiveRefutationBRVisitorTestBase, UnSatInTheMiddleNoReport) {
   constexpr auto Code = R"(
  void reachedWithContradiction();
  void reachedWithNoContradiction();
@@ -139,8 +140,8 @@
 "test.FalsePositiveGenerator:REACHED_WITH_CONTRADICTION\n");
 }
 
-TEST(FalsePositiveRefutationBRVisitor, UnSatAtErrorNodeWithNewSymbolNoReport) {
-  SKIP_WITHOUT_Z3;
+TEST_F(FalsePositiveRefutationBRVisitorTestBase,
+   UnSatAtErrorNodeWithNewSymbolNoReport) {
   constexpr auto Code = R"(
 void reportIfCanBeTrue(bool);
 void reachedWithNoContradiction();
@@ -170,9 +171,8 @@
 "test.FalsePositiveGenerator:CAN_BE_TRUE\n");
 }
 
-TEST(FalsePositiveRefutationBRVisitor,
- UnSatAtErrorNodeDueToRefinedConstraintNoReport) {
-  SKIP_WITHOUT_Z3;
+TEST_F(FalsePositiveRefutationBRVisitorTestBase,
+   UnSatAtErrorNodeDueToRefinedConstraintNoReport) {
   constexpr auto Code = R"(
 void reportIfCanBeTrue(bool);
 void reachedWithNoContradiction();
___
cfe-commits mailing list
cfe-comm

[PATCH] D102812: [clang] Don't pass multiple backend options if mixing -mimplicit-it and -Wa,-mimplicit-it

2021-05-21 Thread Martin Storsjö via Phabricator via cfe-commits

mstorsjo added a comment.

In D102812#2773132 , @DavidSpickett 
wrote:

>> Updated to allow mismatches and just picking the value that is set last on 
>> the command line - what do you think of this version?
>
> My initial reaction was that I'd prefer to take the last one that matches the 
> input type, to be consistent with `-march` and `-mcpu`. `march` and `mcpu` 
> effect both so it makes sense to switch on the input type.
> However this is an option that only effects asm/inline asm (even when passed 
> as a compiler option) so you could think of `-mimplicit-it` as an alias to 
> `-Wa,-mimplicit-it`. So taking the last value we find sounds good to me.
>
> Ideally we would warn about conflicting values but that's an enhancement that 
> can be done another time if we see situations where it could have been useful.

Thanks for your input!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102812

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

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

2021-05-21 Thread Gabor Marton via Phabricator via cfe-commits

martong updated this revision to Diff 346966.
martong added a comment.

- Add test case for commutativity
- Add test case for Valeriy's case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102696

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

Index: clang/test/Analysis/find-binop-constraints.cpp
===
--- /dev/null
+++ clang/test/Analysis/find-binop-constraints.cpp
@@ -0,0 +1,117 @@
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false \
+// RUN:   -verify
+
+void clang_analyzer_eval(bool);
+
+int test_legacy_behavior(int x, int y) {
+  if (y != 0)
+return 0;
+  if (x + y != 0)
+return 0;
+  clang_analyzer_eval(x + y == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(y == 0); // expected-warning{{TRUE}}
+  return y / (x + y);  // expected-warning{{Division by zero}}
+}
+
+int test_rhs_further_constrained(int x, int y) {
+  if (x + y != 0)
+return 0;
+  if (y != 0)
+return 0;
+  clang_analyzer_eval(x + y == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(y == 0); // expected-warning{{TRUE}}
+  return 0;
+}
+
+int test_lhs_further_constrained(int x, int y) {
+  if (x + y != 0)
+return 0;
+  if (x != 0)
+return 0;
+  clang_analyzer_eval(x + y == 0); // expected-warning{{TRUE}}
+  clang_analyzer_eval(x == 0); // expected-warning{{TRUE}}
+  return 0;
+}
+
+int test_lhs_and_rhs_further_constrained(int x, int y) {
+  if (x % y != 1)
+return 0;
+  if (x != 1)
+return 0;
+  if (y != 1)
+return 0;
+  clang_analyzer_eval(x % y == 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval(y == 1); // expected-warning{{TRUE}}
+  return 0;
+}
+
+// Docement that we fail in this case: "y + x" should be zero if "x + y" is
+// constrainted.
+int test_commutativity(int x, int y) {
+  if (x + y != 0)
+return 0;
+  if (y != 0)
+return 0;
+  clang_analyzer_eval(y + x == 0); // expected-warning{{UNKNOWN}} FIXME!
+  clang_analyzer_eval(y == 0); // expected-warning{{TRUE}}
+  return 0;
+}
+
+int test_binop_when_height_is_2_r(int a, int x, int y, int z) {
+  switch (a) {
+  case 1: {
+if (x + y + z != 0)
+  return 0;
+if (z != 0)
+  return 0;
+clang_analyzer_eval(x + y + z == 0); // expected-warning{{TRUE}}
+clang_analyzer_eval(z == 0); // expected-warning{{TRUE}}
+break;
+  }
+  case 2: {
+if (x + y + z != 0)
+  return 0;
+if (y != 0)
+  return 0;
+clang_analyzer_eval(x + y + z == 0); // expected-warning{{TRUE}}
+clang_analyzer_eval(y == 0); // expected-warning{{TRUE}}
+break;
+  }
+  case 3: {
+if (x + y + z != 0)
+  return 0;
+if (x != 0)
+  return 0;
+clang_analyzer_eval(x + y + z == 0); // expected-warning{{TRUE}}
+clang_analyzer_eval(x == 0); // expected-warning{{TRUE}}
+break;
+  }
+  case 4: {
+if (x + y + z != 0)
+  return 0;
+if (x + y != 0)
+  return 0;
+clang_analyzer_eval(x + y + z == 0); // expected-warning{{TRUE}}
+clang_analyzer_eval(x + y == 0); // expected-warning{{TRUE}}
+break;
+  }
+  case 5: {
+if (z != 0)
+  return 0;
+if (x + y + z != 0)
+  return 0;
+clang_analyzer_eval(x + y + z == 0); // expected-warning{{TRUE}}
+if (y != 0)
+  return 0;
+clang_analyzer_eval(y == 0); // expected-warning{{TRUE}}
+clang_analyzer_eval(z == 0); // expected-warning{{TRUE}}
+clang_analyzer_eval(x + y + z == 0); // expected-warning{{TRUE}}
+break;
+  }
+
+  }
+  return 0;
+}
Index: clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
@@ -10,8 +10,9 @@
 //
 //===--===//
 
-#include "clang/AST/ExprCXX.h"
 #include "clang/AST/DeclCXX.h"
+#include "clang/AST/ExprCXX.h"
+#include "clang/AST/StmtVisitor.h"
 #include "clang/StaticAnalyzer/Core/CheckerManager.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h"
 
@@ -37,10 +38,47 @@
   return Symbol;
 }
 
+// This class is responsible to build such an SVal for a BinOp expression where
+// all constituent SVals are representing an LValue expression. We use it to
+// query constraints that are attached directly to the BinOp.
+class LValueSValBuilder : public ConstStmtVisitor {
+  QualType T;
+  const LocationContext *LCtx;
+  ProgramStateRef State;
+  SValBuilder &SvalBuilder;
+
+public:
+  LValueSValBuilder(QualType T, const LocationContext *LCtx,
+ProgramStateRef State, SValBuilder &SvalBuilder)
+  : T(T), LCtx(LCtx), State(S

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

2021-05-21 Thread Gabor Marton via Phabricator via cfe-commits

martong added a comment.

In D102696#2768857 , @vsavchenko 
wrote:

> My take on this: for whatever approach, we definitely will be able to 
> construct a more nested/complex example so that it doesn't work.
> For this patch, I'm wondering about something like this:
>
>   int foo() {
> if (z != 0)
>   return 0;
> if (x + y + z != 0)
>   return 0;
> clang_analyzer_eval(x + y + z == 0); // expected-warning{{TRUE}} OK.
> if (y != 0)
>   return 0;
> clang_analyzer_eval(y == 0); // expected-warning{{TRUE}} OK.
> clang_analyzer_eval(z == 0); // expected-warning{{TRUE}} OK.
> clang_analyzer_eval(x + y + z == 0); // expected-warning{{TRUE}} ?
>   }

I've added a test case for this, and it passes with the patch.

Also, I added another test case for checking that "y + x" should be zero if "x 
+ y" is constrained. This fails. To support that we should be synthesizing all 
combination of the commutative expressions, which would not scale of course. 
(Perhaps we could do this only for the upper level expression and this way, the 
most common case could be supported)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102696

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

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

2021-05-21 Thread Gabor Marton via Phabricator via cfe-commits

martong added a comment.

In D102696#2769465 , @NoQ wrote:

> In D102696#2767894 , @martong wrote:
>
>>> This happens for the same reason that your patch is needed in the first 
>>> place: we're eagerly substituting a constant.
>>
>> Absolutely, that's the point. On the other hand, it is very important to 
>> emphasize that we cannot solve this problem with a stronger solver, see my 
>> example with 3 variables and two equations above.
>
> Well, in that other example, we should be asking about `$x + $y + 0 == 0` at 
> some point. And then the solver should be able to deduce it from `$x + $y + 
> $z == 0` and `$z == 0`. If we're not asking this question, that's obviously 
> the first problem to get out of our way.

Yeah, you are right and my analysis was not precise enough. I confirm that 
currently - at main - we do query `$x + $y + 0 == 0`. And the solver is 
incapable of solving it from the given constraints. So, yes, this patch is a 
"workaround" to ask the solver what does it know from the value of the verbatim 
expression. And this has it's limitation (see the test case for commutativity), 
still I think it could make the analyzer more precise.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102696

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

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

2021-05-21 Thread Gabor Marton via Phabricator via cfe-commits

martong added a comment.

> As for the solver, it is something that tormented me for a long time. Is 
> there a way to avoid a full-blown brute force check of all existing 
> constraints and get some knowledge about symbolic expressions by constraints 
> these symbolic expressions are actually part of (right now we can reason 
> about expressions if we know some information about its own parts aka 
> operands)?

Well, it is a hard question.
I've been thinking about building a "parent" map for the sub-expressions, like 
we do in the AST (see clang::ParentMap). We could use this parent map to inject 
new constraints during the "constant folding" mechanism.
So, let's say we have `$x + $y = 0` and then when we process `$y = 0` then we'd 
add a new constraint: `$x = 0`. We could add this new constraint by knowing 
that we have to visit `$x + $y` because `$y` is connected to that in the parent 
map.
What do you think, could it work?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102696

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

[PATCH] D102879: Disable retain-count tracking for references to OSMetaClass

2021-05-21 Thread Georgeta Igna via Phabricator via cfe-commits

georgi_igna abandoned this revision.
georgi_igna added a comment.

There is an existing revision that I can use for this change


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102879

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

[PATCH] D102906: [clang-tidy] Remark was added to clang tooling Diagnostic

2021-05-21 Thread Dmitry Polukhin via Phabricator via cfe-commits

DmitryPolukhin added inline comments.



Comment at: clang/include/clang/Tooling/Core/Diagnostic.h:72
+Error = DiagnosticsEngine::Error,
+Remark = DiagnosticsEngine::Remark
   };

nit, I would move remark first to have list by increasing severity. It looks 
like this enum values is not used outside of the sources so I hope it is safe.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102906

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

[PATCH] D102577: NFC: TreeTransform.h: make the function TransformNestedNameSpecifierLoc more beautiful

2021-05-21 Thread Pengfei Wang via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe6ec7ab5820f: NFC: TreeTransform.h: make the function 
TransformNestedNameSpecifierLoc more… (authored by zhouyizhou, committed by 
pengfei).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102577

Files:
  clang/lib/Sema/TreeTransform.h


Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -4031,12 +4031,10 @@
   return Sema::ConditionResult();
 }
 
-template
-NestedNameSpecifierLoc
-TreeTransform::TransformNestedNameSpecifierLoc(
-NestedNameSpecifierLoc NNS,
- QualType ObjectType,
- NamedDecl *FirstQualifierInScope) 
{
+template 
+NestedNameSpecifierLoc TreeTransform::TransformNestedNameSpecifierLoc(
+NestedNameSpecifierLoc NNS, QualType ObjectType,
+NamedDecl *FirstQualifierInScope) {
   SmallVector Qualifiers;
   for (NestedNameSpecifierLoc Qualifier = NNS; Qualifier;
Qualifier = Qualifier.getPrefix())
@@ -4050,28 +4048,26 @@
 switch (QNNS->getKind()) {
 case NestedNameSpecifier::Identifier: {
   Sema::NestedNameSpecInfo IdInfo(QNNS->getAsIdentifier(),
-  Q.getLocalBeginLoc(), Q.getLocalEndLoc(), 
ObjectType);
+  Q.getLocalBeginLoc(), Q.getLocalEndLoc(),
+  ObjectType);
   if (SemaRef.BuildCXXNestedNameSpecifier(/*Scope=*/nullptr, IdInfo, false,
   SS, FirstQualifierInScope, 
false))
 return NestedNameSpecifierLoc();
-}
   break;
+}
 
 case NestedNameSpecifier::Namespace: {
-  NamespaceDecl *NS
-= cast_or_null(
-getDerived().TransformDecl(
-  Q.getLocalBeginLoc(),
-   
QNNS->getAsNamespace()));
+  NamespaceDecl *NS =
+  cast_or_null(getDerived().TransformDecl(
+  Q.getLocalBeginLoc(), QNNS->getAsNamespace()));
   SS.Extend(SemaRef.Context, NS, Q.getLocalBeginLoc(), Q.getLocalEndLoc());
   break;
 }
 
 case NestedNameSpecifier::NamespaceAlias: {
-  NamespaceAliasDecl *Alias
-= cast_or_null(
-  getDerived().TransformDecl(Q.getLocalBeginLoc(),
- QNNS->getAsNamespaceAlias()));
+  NamespaceAliasDecl *Alias =
+  cast_or_null(getDerived().TransformDecl(
+  Q.getLocalBeginLoc(), QNNS->getAsNamespaceAlias()));
   SS.Extend(SemaRef.Context, Alias, Q.getLocalBeginLoc(),
 Q.getLocalEndLoc());
   break;
@@ -4107,7 +4103,7 @@
 if (TL.getType()->isEnumeralType())
   SemaRef.Diag(TL.getBeginLoc(),
diag::warn_cxx98_compat_enum_nested_name_spec);
-SS.Extend(SemaRef.Context, /*FIXME:*/SourceLocation(), TL,
+SS.Extend(SemaRef.Context, /*FIXME:*/ SourceLocation(), TL,
   Q.getLocalEndLoc());
 break;
   }
@@ -4116,7 +4112,7 @@
   TypedefTypeLoc TTL = TL.getAs();
   if (!TTL || !TTL.getTypedefNameDecl()->isInvalidDecl()) {
 SemaRef.Diag(TL.getBeginLoc(), diag::err_nested_name_spec_non_tag)
-  << TL.getType() << SS.getRange();
+<< TL.getType() << SS.getRange();
   }
   return NestedNameSpecifierLoc();
 }


Index: clang/lib/Sema/TreeTransform.h
===
--- clang/lib/Sema/TreeTransform.h
+++ clang/lib/Sema/TreeTransform.h
@@ -4031,12 +4031,10 @@
   return Sema::ConditionResult();
 }
 
-template
-NestedNameSpecifierLoc
-TreeTransform::TransformNestedNameSpecifierLoc(
-NestedNameSpecifierLoc NNS,
- QualType ObjectType,
- NamedDecl *FirstQualifierInScope) {
+template 
+NestedNameSpecifierLoc TreeTransform::TransformNestedNameSpecifierLoc(
+NestedNameSpecifierLoc NNS, QualType ObjectType,
+NamedDecl *FirstQualifierInScope) {
   SmallVector Qualifiers;
   for (NestedNameSpecifierLoc Qualifier = NNS; Qualifier;
Qualifier = Qualifier.getPrefix())
@@ -4050,28 +4048,26 @@
 switch (QNNS->getKind()) {
 case NestedNameSpecifier::Identifier: {
   Sema::NestedNameSpecInfo IdInfo(QNNS->getAsIdentifier(),
-  Q.getLocalBeginLoc(), Q.getLocalEndLoc(), ObjectType);
+  Q.getLocalBeginLoc(), Q.getLocalEndLoc(),
+  ObjectType);
   if (S

[clang] e6ec7ab - NFC: TreeTransform.h: make the function TransformNestedNameSpecifierLoc more beautiful

2021-05-21 Thread via cfe-commits


Author: Zhouyi Zhou
Date: 2021-05-21T18:27:23+08:00
New Revision: e6ec7ab5820f85016ece401bd49db12837d0715d

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

LOG: NFC: TreeTransform.h: make the function TransformNestedNameSpecifierLoc 
more beautiful

Hi,
I am new to LLVM, and I really want to get involved in LLVM community.

I guess if the following switch case of function
TransformNestedNameSpecifierLoc could possibly made more beautiful with
'break' stmt moved inside of the right brace.

I think move of 'break' stmt will not change the invoking destructor of
IdInfo.

Thanks for your effort.

I have done make check-all on x86_64-linux
Signed-off-by: Zhouyi Zhou 

Reviewed By: pengfei

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

Added: 


Modified: 
clang/lib/Sema/TreeTransform.h

Removed: 




diff  --git a/clang/lib/Sema/TreeTransform.h b/clang/lib/Sema/TreeTransform.h
index 18864e731f17f..e4bbc1cf4df63 100644
--- a/clang/lib/Sema/TreeTransform.h
+++ b/clang/lib/Sema/TreeTransform.h
@@ -4031,12 +4031,10 @@ Sema::ConditionResult 
TreeTransform::TransformCondition(
   return Sema::ConditionResult();
 }
 
-template
-NestedNameSpecifierLoc
-TreeTransform::TransformNestedNameSpecifierLoc(
-NestedNameSpecifierLoc NNS,
- QualType ObjectType,
- NamedDecl *FirstQualifierInScope) 
{
+template 
+NestedNameSpecifierLoc TreeTransform::TransformNestedNameSpecifierLoc(
+NestedNameSpecifierLoc NNS, QualType ObjectType,
+NamedDecl *FirstQualifierInScope) {
   SmallVector Qualifiers;
   for (NestedNameSpecifierLoc Qualifier = NNS; Qualifier;
Qualifier = Qualifier.getPrefix())
@@ -4050,28 +4048,26 @@ TreeTransform::TransformNestedNameSpecifierLoc(
 switch (QNNS->getKind()) {
 case NestedNameSpecifier::Identifier: {
   Sema::NestedNameSpecInfo IdInfo(QNNS->getAsIdentifier(),
-  Q.getLocalBeginLoc(), Q.getLocalEndLoc(), 
ObjectType);
+  Q.getLocalBeginLoc(), Q.getLocalEndLoc(),
+  ObjectType);
   if (SemaRef.BuildCXXNestedNameSpecifier(/*Scope=*/nullptr, IdInfo, false,
   SS, FirstQualifierInScope, 
false))
 return NestedNameSpecifierLoc();
-}
   break;
+}
 
 case NestedNameSpecifier::Namespace: {
-  NamespaceDecl *NS
-= cast_or_null(
-getDerived().TransformDecl(
-  Q.getLocalBeginLoc(),
-   
QNNS->getAsNamespace()));
+  NamespaceDecl *NS =
+  cast_or_null(getDerived().TransformDecl(
+  Q.getLocalBeginLoc(), QNNS->getAsNamespace()));
   SS.Extend(SemaRef.Context, NS, Q.getLocalBeginLoc(), Q.getLocalEndLoc());
   break;
 }
 
 case NestedNameSpecifier::NamespaceAlias: {
-  NamespaceAliasDecl *Alias
-= cast_or_null(
-  getDerived().TransformDecl(Q.getLocalBeginLoc(),
- QNNS->getAsNamespaceAlias()));
+  NamespaceAliasDecl *Alias =
+  cast_or_null(getDerived().TransformDecl(
+  Q.getLocalBeginLoc(), QNNS->getAsNamespaceAlias()));
   SS.Extend(SemaRef.Context, Alias, Q.getLocalBeginLoc(),
 Q.getLocalEndLoc());
   break;
@@ -4107,7 +4103,7 @@ TreeTransform::TransformNestedNameSpecifierLoc(
 if (TL.getType()->isEnumeralType())
   SemaRef.Diag(TL.getBeginLoc(),
diag::warn_cxx98_compat_enum_nested_name_spec);
-SS.Extend(SemaRef.Context, /*FIXME:*/SourceLocation(), TL,
+SS.Extend(SemaRef.Context, /*FIXME:*/ SourceLocation(), TL,
   Q.getLocalEndLoc());
 break;
   }
@@ -4116,7 +4112,7 @@ TreeTransform::TransformNestedNameSpecifierLoc(
   TypedefTypeLoc TTL = TL.getAs();
   if (!TTL || !TTL.getTypedefNameDecl()->isInvalidDecl()) {
 SemaRef.Diag(TL.getBeginLoc(), diag::err_nested_name_spec_non_tag)
-  << TL.getType() << SS.getRange();
+<< TL.getType() << SS.getRange();
   }
   return NestedNameSpecifierLoc();
 }



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

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

2021-05-21 Thread Valeriy Savchenko via Phabricator via cfe-commits

vsavchenko added a comment.

In D102696#2773304 , @martong wrote:

>> As for the solver, it is something that tormented me for a long time. Is 
>> there a way to avoid a full-blown brute force check of all existing 
>> constraints and get some knowledge about symbolic expressions by constraints 
>> these symbolic expressions are actually part of (right now we can reason 
>> about expressions if we know some information about its own parts aka 
>> operands)?
>
> Well, it is a hard question.
> I've been thinking about building a "parent" map for the sub-expressions, 
> like we do in the AST (see clang::ParentMap). We could use this parent map to 
> inject new constraints during the "constant folding" mechanism.
> So, let's say we have `$x + $y = 0` and then when we process `$y = 0` then 
> we'd add a new constraint: `$x = 0`. We could add this new constraint by 
> knowing that we have to visit `$x + $y` because `$y` is connected to that in 
> the parent map.
> What do you think, could it work?

Yes, this was exactly my line of thinking.  Instead of trying to use hard logic 
every time we are asked a question, we can try to simplify existing constraints 
based on the new bit of information.
The main problem with this is the tree nature of symbolic expressions.  If we 
have something trivial like `$x + $y` - sure.  But something with lot more 
nested subexpressions can get tricky really fast.  That can be solved if we 
have a canonical form for the trees (this will resolve the problem with `$x + 
$y` versus `$y + $x` as well).  Right now, we have bits of this all around our 
codebase, but those are more like workarounds as opposed to one general 
approach.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102696

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

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

2021-05-21 Thread Nathan Sidwell via Phabricator via cfe-commits

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



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:11632
+  // As with enum-decls, we ignore attributes for now.
+
+  auto *Enum = cast(DS.getRepAsDecl());

bruno wrote:
> Remove this empty line.
You guys sure hate white space :)  FWIW, here's the using decl' source:
  assert(IdentLoc.isValid() && "Invalid TargetName location.");

  // FIXME: We ignore attributes for now.

  // For an inheriting constructor declaration, the name of the using


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

https://reviews.llvm.org/D102241

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

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

2021-05-21 Thread Nathan Sidwell via Phabricator via cfe-commits

urnathan updated this revision to Diff 346985.
urnathan added a comment.

Fix nits


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

https://reviews.llvm.org/D102241

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

Index: clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersNodeTest.cpp
@@ -1428,6 +1428,22 @@
   usingDecl(hasAnyUsingShadowDecl(hasName("a");
 }
 
+TEST_P(ASTMatchersTest, UsingEnumDecl_MatchesUsingEnumDeclarations) {
+  if (!GetParam().isCXX20OrLater()) {
+return;
+  }
+  EXPECT_TRUE(
+  matches("namespace X { enum x {}; } using enum X::x;", usingEnumDecl()));
+}
+
+TEST_P(ASTMatchersTest, UsingEnumDecl_MatchesShadowUsingDeclarations) {
+  if (!GetParam().isCXX20OrLater()) {
+return;
+  }
+  EXPECT_TRUE(matches("namespace f { enum a {b}; } using enum f::a;",
+  usingEnumDecl(hasAnyUsingShadowDecl(hasName("b");
+}
+
 TEST_P(ASTMatchersTest, UsingDirectiveDecl_MatchesUsingNamespace) {
   if (!GetParam().isCXX()) {
 return;
Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -844,7 +844,15 @@
   testImport("namespace foo { int bar; }"
  "void declToImport() { using foo::bar; }",
  Lang_CXX03, "", Lang_CXX03, Verifier,
- functionDecl(hasDescendant(usingDecl(;
+ functionDecl(hasDescendant(usingDecl(hasName("bar");
+}
+
+TEST_P(ImportDecl, ImportUsingEnumDecl) {
+  MatchVerifier Verifier;
+  testImport("namespace foo { enum bar { baz, toto, quux }; }"
+ "void declToImport() { using enum foo::bar; }",
+ Lang_CXX20, "", Lang_CXX20, Verifier,
+ functionDecl(hasDescendant(usingEnumDecl(hasName("bar");
 }
 
 /// \brief Matches shadow declarations introduced into a scope by a
@@ -862,10 +870,16 @@
 
 TEST_P(ImportDecl, ImportUsingShadowDecl) {
   MatchVerifier Verifier;
+  // from using-decl
   testImport("namespace foo { int bar; }"
  "namespace declToImport { using foo::bar; }",
  Lang_CXX03, "", Lang_CXX03, Verifier,
- namespaceDecl(has(usingShadowDecl(;
+ namespaceDecl(has(usingShadowDecl(hasName("bar");
+  // from using-enum-decl
+  testImport("namespace foo { enum bar {baz, toto, quux }; }"
+ "namespace declToImport { using enum foo::bar; }",
+ Lang_CXX20, "", Lang_CXX20, Verifier,
+ namespaceDecl(has(usingShadowDecl(hasName("baz");
 }
 
 TEST_P(ImportExpr, ImportUnresolvedLookupExpr) {
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -6540,6 +6540,7 @@
   }
 
   case Decl::Using:
+  case Decl::UsingEnum:
 return MakeCursorOverloadedDeclRef(cast(D), D->getLocation(),
TU);
 
Index: clang/test/SemaCXX/cxx20-using-enum.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx20-using-enum.cpp
@@ -0,0 +1,233

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

2021-05-21 Thread Andy Wingo via Phabricator via cfe-commits

wingo updated this revision to Diff 346986.
wingo added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101140

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

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

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

2021-05-21 Thread Andy Wingo via Phabricator via cfe-commits

wingo updated this revision to Diff 346990.
wingo marked 4 inline comments as done.
wingo added a comment.

Address feedback


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101140

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

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

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

2021-05-21 Thread Anton Zabaznov 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 rG826905787ae4: [OpenCL] Add support of OpenCL C 3.0 
__opencl_c_fp64 (authored by azabaznov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96524

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

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

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

2021-05-21 Thread Andy Wingo via Phabricator via cfe-commits

wingo added inline comments.



Comment at: llvm/include/llvm/CodeGen/MIRYamlMapping.h:351
 IO.enumCase(ID, "scalable-vector", TargetStackID::ScalableVector);
+IO.enumCase(ID, "object", TargetStackID::Object);
 IO.enumCase(ID, "noalloc", TargetStackID::NoAlloc);

tlively wrote:
> Is there a good test to demonstrate this change in?
Done in ir-locals-stackid.ll



Comment at: llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.cpp:34-36
+// runs between then and DAG building time, though, so instead we hoist stack
+// objects lazily when they are first used, and comprehensively after the DAG 
is
+// built via the PreprocessISelDAG hook, called by the

tlively wrote:
> Why do this in two places instead of just once comprehensively in the hook? 
> It would be good to explain that in the comment, too.
👍 



Comment at: llvm/lib/Target/WebAssembly/Utils/WebAssemblyUtilities.cpp:63-64
+  MFI.setObjectOffset(FrameIndex, Local);
+  // Allocate WebAssembly locals for each non-aggregate component of the
+  // allocation.
+  for (EVT ValueVT : ValueVTs)

tlively wrote:
> Can there be aggregate components? What do we do with them?
Hoo, it is a good question.  I think the high-level answer is that in the same 
way as you can allocate an i32 to a local, or an externref to a local, you 
could allocate a struct { i32, externref }.  The leaves of that aggregate would 
be numbered from 0 to N, assigned to consecutive locals of the appropriate 
primitive types, and accesses would compiled down to direct access to the 
members.  Probably the first person who tries this is going to run into some 
interesting cases and I think specifically the local.get index mapping isn't 
quite yet ready.  But that would be the idea.  WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101140

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

[clang] 8269057 - [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64

2021-05-21 Thread Anton Zabaznov via cfe-commits


Author: Anton Zabaznov
Date: 2021-05-21T15:01:19+03:00
New Revision: 826905787ae4c8540bb8a2384fac59c606c7eaff

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

LOG: [OpenCL] Add support of OpenCL C 3.0 __opencl_c_fp64

There already exists cl_khr_fp64 extension. So OpenCL C 3.0
and higher should use the feature, earlier versions still
use the extension. OpenCL C 3.0 API spec states that extension
will be not described in the option string if corresponding
optional functionality is not supported (see 4.2. Querying Devices).
Due to that fact the usage of features for OpenCL C 3.0 must
be as follows:

```
$ clang -Xclang -cl-ext=+cl_khr_fp64,+__opencl_c_fp64 ...

$ clang -Xclang -cl-ext=-cl_khr_fp64,-__opencl_c_fp64 ...
```

e.g. the feature and the equivalent extension (if exists)
must be set to the same values

Reviewed By: Anastasia

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

Added: 
clang/test/Misc/opencl-c-3.0.incorrect_options.cl
clang/test/SemaOpenCL/fp64-fp16-options.cl

Modified: 
clang/docs/OpenCLSupport.rst
clang/include/clang/Basic/DiagnosticCommonKinds.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Basic/Targets.cpp
clang/lib/Basic/Targets/AMDGPU.h
clang/lib/Basic/Targets/NVPTX.h
clang/lib/Frontend/CompilerInstance.cpp
clang/lib/Sema/SemaExpr.cpp
clang/lib/Sema/SemaType.cpp
clang/test/CodeGenOpenCL/printf.cl

Removed: 
clang/test/SemaOpenCL/extensions.cl



diff  --git a/clang/docs/OpenCLSupport.rst b/clang/docs/OpenCLSupport.rst
index fa719c8bdf9f5..dbfb67f90ae14 100644
--- a/clang/docs/OpenCLSupport.rst
+++ b/clang/docs/OpenCLSupport.rst
@@ -339,7 +339,24 @@ Missing features or with limited support
 
 .. _opencl_300:
 
-OpenCL 3.0 Implementation Status
+OpenCL C 3.0 Usage
+
+
+OpenCL C 3.0 language standard makes most OpenCL C 2.0 features optional. 
Optional
+functionality in OpenCL C 3.0 is indicated with the presence of feature-test 
macros
+(list of feature-test macros is `here 
`_).
+Command-line flag :ref:`-cl-ext ` can be used to override 
features supported by a target.
+
+For cases when there is an associated extension for a specific feature (fp64 
and 3d image writes)
+user should specify both (extension and feature) in command-line flag:
+
+   .. code-block:: console
+
+ $ clang -cc1 -cl-std=CL3.0 -cl-ext=+cl_khr_fp64,+__opencl_c_fp64 ...
+ $ clang -cc1 -cl-std=CL3.0 -cl-ext=-cl_khr_fp64,-__opencl_c_fp64 ...
+
+
+OpenCL C 3.0 Implementation Status
 
 
 The following table provides an overview of features in OpenCL C 3.0 and their

diff  --git a/clang/include/clang/Basic/DiagnosticCommonKinds.td 
b/clang/include/clang/Basic/DiagnosticCommonKinds.td
index 06c2647149dfa..4dab3a3b39ac3 100644
--- a/clang/include/clang/Basic/DiagnosticCommonKinds.td
+++ b/clang/include/clang/Basic/DiagnosticCommonKinds.td
@@ -364,4 +364,7 @@ def warn_poison_system_directories : Warning <
 def warn_opencl_unsupported_core_feature : Warning<
   "%0 is a core feature in %select{OpenCL C|C++ for OpenCL}1 version %2 but 
not supported on this target">,
   InGroup, DefaultIgnore;
+
+def err_opencl_extension_and_feature_
diff ers : Error<
+  "options %0 and %1 are set to 
diff erent values">;
 }

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index fff6b62f3b7fb..5d0f5dcbfc359 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -118,7 +118,8 @@ def warn_float_underflow : Warning<
   "magnitude of floating-point constant too small for type %0; minimum is %1">,
   InGroup;
 def warn_double_const_requires_fp64 : Warning<
-  "double precision constant requires cl_khr_fp64, casting to single 
precision">;
+  "double precision constant requires %select{cl_khr_fp64|cl_khr_fp64 and 
__opencl_c_fp64}0, "
+  "casting to single precision">;
 def err_half_const_requires_fp16 : Error<
   "half precision constant requires cl_khr_fp16">;
 
@@ -10027,6 +10028,8 @@ def err_opencl_requires_extension : Error<
 def ext_opencl_double_without_pragma : Extension<
   "Clang permits use of type 'double' regardless pragma if 'cl_khr_fp64' is"
   " supported">;
+def err_opencl_double_requires_extension :  Error<
+"use of type 'double' requires %select{cl_khr_fp64|cl_khr_fp64 and 
__opencl_c_fp64}0 support">;
 def warn_opencl_generic_address_space_arg : Warning<
   "passing non-generic address space pointer to %0"
   " may cause dynamic conversion affecting performance">,

diff  --git a/clang/lib/Basic/Targets.cpp b/clang/lib/Basic/Targets.cpp
index 8

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

2021-05-21 Thread Denys Petrov via Phabricator via cfe-commits

ASDenysPetrov updated this revision to Diff 346741.
ASDenysPetrov added a comment.
Herald added a subscriber: manas.

Reworked the solution. Returned to Implemented two versions of the same 
algorithm. Most optimized (but more verbose) and generalized one (but less 
optimized).
Added a bit more tests. @vsavchenko , please, look.


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

https://reviews.llvm.org/D99797

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

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

[PATCH] D102914: [analyzer] Make checker silencing work for non-pathsensitive bug reports

2021-05-21 Thread Kristóf Umann via Phabricator via cfe-commits

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

D66572  separated `BugReport` and 
`BugReporter` into basic and path sensitive versions. As a result, checker 
silencing, which worked deep in the path sensitive report generation facilities 
became specific to it. This patch moves the corresponding code before the call 
to the virtual function `generateDiagnosticForConsumerMap` (which is overriden 
by the specific kinds of bug reporters). Although we see bug reporting as 
relatively lightweight compared to the analysis, this will get rid of several 
steps we used to throw away.

Quoting from D65379 :

> At a very high level, this consists of 3 steps:
>
> 1. For all `BugReport`s in the same `BugReportEquivClass`, collect all their 
> error nodes in a set. With that set, create a new, trimmed `ExplodedGraph` 
> whose leafs are all error nodes.
> 2. Until a valid report is found, construct a bug path, which is yet another 
> `ExplodedGraph`, that is linear from a given error node to the root of the 
> graph.
> 3. Run all visitors on the constructed bug path. If in this process the 
> report got invalidated, start over from step 2.

Checker silencing used to kick in after all of these. Now it does before any of 
them :^)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102914

Files:
  clang/lib/StaticAnalyzer/Core/BugReporter.cpp
  clang/test/Analysis/silence-checkers-malloc.cpp
  clang/test/Analysis/silence-checkers.cpp


Index: clang/test/Analysis/silence-checkers.cpp
===
--- clang/test/Analysis/silence-checkers.cpp
+++ clang/test/Analysis/silence-checkers.cpp
@@ -11,6 +11,12 @@
 // RUN:   -analyzer-checker=cplusplus.NewDelete\
 // RUN:   -analyzer-config silence-checkers="unix"
 
+// RUN: %clang_analyze_cc1 -verify %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=apiModeling \
+// RUN:   -analyzer-checker=deadcode \
+// RUN:   -analyzer-config silence-checkers="deadcode.DeadStores"
+
 #include "Inputs/system-header-simulator-cxx.h"
 
 typedef __typeof(sizeof(int)) size_t;
@@ -38,3 +44,15 @@
   delete Ptr; // no-silence-warning{{Argument to 'delete' is a constant 
address (16), which is not memory allocated by 'new' [cplusplus.NewDelete]}}
   // unix-silenced-warning@-1{{Argument to 'delete' is a constant 
address (16), which is not memory allocated by 'new' [cplusplus.NewDelete]}}
 }
+
+int foo() {
+  int x = 42;
+  return x;
+}
+
+void g() {
+  int y;
+  y = 7;
+  int x = foo();
+  y = 10;
+}
Index: clang/lib/StaticAnalyzer/Core/BugReporter.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugReporter.cpp
+++ clang/lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -1989,13 +1989,6 @@
   const SourceManager &SM = getSourceManager();
   const AnalyzerOptions &Opts = getAnalyzerOptions();
 
-  // See whether we need to silence the checker/package.
-  // FIXME: This will not work if the report was emitted with an incorrect tag.
-  for (const std::string &CheckerOrPackage : Opts.SilencedCheckersAndPackages) 
{
-if (R->getBugType().getCheckerName().startswith(CheckerOrPackage))
-  return nullptr;
-  }
-
   if (!PDC->shouldGenerateDiagnostics())
 return generateEmptyDiagnosticForReport(R, getSourceManager());
 
@@ -3040,6 +3033,14 @@
   if (!report)
 return;
 
+  // See whether we need to silence the checker/package.
+  for (const std::string &CheckerOrPackage :
+   getAnalyzerOptions().SilencedCheckersAndPackages) {
+if (report->getBugType().getCheckerName().startswith(
+CheckerOrPackage))
+  return;
+  }
+
   ArrayRef Consumers = getPathDiagnosticConsumers();
   std::unique_ptr Diagnostics =
   generateDiagnosticForConsumerMap(report, Consumers, bugReports);


Index: clang/test/Analysis/silence-checkers.cpp
===
--- clang/test/Analysis/silence-checkers.cpp
+++ clang/test/Analysis/silence-checkers.cpp
@@ -11,6 +11,12 @@
 // RUN:   -analyzer-checker=cplusplus.NewDelete\
 // RUN:   -analyzer-config silence-checkers="unix"
 
+// RUN: %clang_analyze_cc1 -verify %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=apiModeling \
+// RUN:   -analyzer-checker=deadcode \
+// RUN:   -analyzer-config silence-checkers="deadcode.DeadStores"
+
 #include "Inputs/system-header-simulator-cxx.h"
 
 typedef __typeof(sizeof(int)) size_t;
@@ -38,3 +44,15 @@
   delete Ptr; // no-silence-warning{{Argument to 'delete' is a constant address (16), wh

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

2021-05-21 Thread Alexandre Ganea via Phabricator via cfe-commits

aganea added inline comments.



Comment at: clang/include/clang/Frontend/CompilerInstance.h:170
 std::string TempFilename;
+Optional TempFile;
 

Can we always use `TempFile`? And remove `TempFilename` in that case?



Comment at: clang/lib/Frontend/CompilerInstance.cpp:728
+
+std::string ErrorMsg;
+if (OF.TempFile) {

I think the idea overall in LLVM is to defer the error rendering as late as 
possible. You could probably only keep an `Error` variable here, and render it 
below in the diagnostic with `toString(E)`.



Comment at: clang/lib/Frontend/CompilerInstance.cpp:733
+} else {
+  if (std::error_code EC =
+  llvm::sys::fs::rename(OF.TempFilename, NewOutFile))

Here you can probably use `ECError` or `errorCodeToError()` with what is said 
slightly above.



Comment at: clang/lib/Frontend/CompilerInstance.cpp:840
 int fd;
-std::error_code EC = llvm::sys::fs::createUniqueFile(
-TempPath, fd, TempPath,
-Binary ? llvm::sys::fs::OF_None : llvm::sys::fs::OF_Text);
+#if _WIN32
+// On Windows, use llvm::sys::fs::TempFile to write the output file so

Usually it is better to avoid platform-specific logic. Could we use `TempFile` 
all the time on all platforms?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102736

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

[PATCH] D102663: Bug 49633 - Added warning for static inline global and namespaced declarations for c++17+

2021-05-21 Thread Erich Keane via Phabricator via cfe-commits

erichkeane added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:7127
 << FixItHint::CreateRemoval(D.getDeclSpec().getInlineSpecLoc());
+} else if (SC == SC_Static && DC->isFileContext() &&
+   getLangOpts().CPlusPlus17) {

First, what about this is C++17 specific?  The inline and static relationship 
is older than C++17, right?

Also, are you sure that the warning/stuff in the 'else' isn't still valuable?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102663

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

[PATCH] D102914: [analyzer] Make checker silencing work for non-pathsensitive bug reports

2021-05-21 Thread Kristóf Umann via Phabricator via cfe-commits

Szelethus updated this revision to Diff 347003.
Szelethus added a comment.

Fix the test file.


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

https://reviews.llvm.org/D102914

Files:
  clang/lib/StaticAnalyzer/Core/BugReporter.cpp
  clang/test/Analysis/silence-checkers-malloc.cpp
  clang/test/Analysis/silence-checkers.cpp


Index: clang/test/Analysis/silence-checkers.cpp
===
--- clang/test/Analysis/silence-checkers.cpp
+++ clang/test/Analysis/silence-checkers.cpp
@@ -11,6 +11,12 @@
 // RUN:   -analyzer-checker=cplusplus.NewDelete\
 // RUN:   -analyzer-config silence-checkers="unix"
 
+// RUN: %clang_analyze_cc1 -verify="deadstore-silenced" %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=apiModeling \
+// RUN:   -analyzer-checker=deadcode \
+// RUN:   -analyzer-config silence-checkers="deadcode.DeadStores"
+
 #include "Inputs/system-header-simulator-cxx.h"
 
 typedef __typeof(sizeof(int)) size_t;
@@ -38,3 +44,17 @@
   delete Ptr; // no-silence-warning{{Argument to 'delete' is a constant 
address (16), which is not memory allocated by 'new' [cplusplus.NewDelete]}}
   // unix-silenced-warning@-1{{Argument to 'delete' is a constant 
address (16), which is not memory allocated by 'new' [cplusplus.NewDelete]}}
 }
+
+// deadstore-silenced-no-diagnostics
+
+int foo() {
+  int x = 42;
+  return x;
+}
+
+void g() {
+  int y;
+  y = 7;
+  int x = foo();
+  y = 10;
+}
Index: clang/lib/StaticAnalyzer/Core/BugReporter.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugReporter.cpp
+++ clang/lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -1989,13 +1989,6 @@
   const SourceManager &SM = getSourceManager();
   const AnalyzerOptions &Opts = getAnalyzerOptions();
 
-  // See whether we need to silence the checker/package.
-  // FIXME: This will not work if the report was emitted with an incorrect tag.
-  for (const std::string &CheckerOrPackage : Opts.SilencedCheckersAndPackages) 
{
-if (R->getBugType().getCheckerName().startswith(CheckerOrPackage))
-  return nullptr;
-  }
-
   if (!PDC->shouldGenerateDiagnostics())
 return generateEmptyDiagnosticForReport(R, getSourceManager());
 
@@ -3040,6 +3033,14 @@
   if (!report)
 return;
 
+  // See whether we need to silence the checker/package.
+  for (const std::string &CheckerOrPackage :
+   getAnalyzerOptions().SilencedCheckersAndPackages) {
+if (report->getBugType().getCheckerName().startswith(
+CheckerOrPackage))
+  return;
+  }
+
   ArrayRef Consumers = getPathDiagnosticConsumers();
   std::unique_ptr Diagnostics =
   generateDiagnosticForConsumerMap(report, Consumers, bugReports);


Index: clang/test/Analysis/silence-checkers.cpp
===
--- clang/test/Analysis/silence-checkers.cpp
+++ clang/test/Analysis/silence-checkers.cpp
@@ -11,6 +11,12 @@
 // RUN:   -analyzer-checker=cplusplus.NewDelete\
 // RUN:   -analyzer-config silence-checkers="unix"
 
+// RUN: %clang_analyze_cc1 -verify="deadstore-silenced" %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=apiModeling \
+// RUN:   -analyzer-checker=deadcode \
+// RUN:   -analyzer-config silence-checkers="deadcode.DeadStores"
+
 #include "Inputs/system-header-simulator-cxx.h"
 
 typedef __typeof(sizeof(int)) size_t;
@@ -38,3 +44,17 @@
   delete Ptr; // no-silence-warning{{Argument to 'delete' is a constant address (16), which is not memory allocated by 'new' [cplusplus.NewDelete]}}
   // unix-silenced-warning@-1{{Argument to 'delete' is a constant address (16), which is not memory allocated by 'new' [cplusplus.NewDelete]}}
 }
+
+// deadstore-silenced-no-diagnostics
+
+int foo() {
+  int x = 42;
+  return x;
+}
+
+void g() {
+  int y;
+  y = 7;
+  int x = foo();
+  y = 10;
+}
Index: clang/lib/StaticAnalyzer/Core/BugReporter.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugReporter.cpp
+++ clang/lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -1989,13 +1989,6 @@
   const SourceManager &SM = getSourceManager();
   const AnalyzerOptions &Opts = getAnalyzerOptions();
 
-  // See whether we need to silence the checker/package.
-  // FIXME: This will not work if the report was emitted with an incorrect tag.
-  for (const std::string &CheckerOrPackage : Opts.SilencedCheckersAndPackages) {
-if (R->getBugType().getCheckerName().startswith(CheckerOrPackage))
-  return nullptr;
-  }
-
   if (!PDC->shouldGenerateDiagnostics())
 return generateEmptyDiagnosticForReport(R, getSourceManager());
 
@@ -3040,6 +3033,14 @@
   if (!report)
 return;
 
+  // See whether we need to silence the checker/package.
+  for (const std::string &CheckerOrPackage :
+   getAnalyzerOptions().SilencedCheckersAndPackages) {
+if (report->getBugType().getCheckerName().startswith(
+

[PATCH] D102633: [clang-scan-deps] Improvements to thread usage

2021-05-21 Thread Alexandre Ganea via Phabricator via cfe-commits

aganea added a subscriber: mehdi_amini.
aganea added a comment.

In D102633#2769762 , @arphaman wrote:

> It might be good for @aganea to take a look as well.

Thanks! I actually work with @saudi, I already took a look at the patch before 
uploading. However I'm stil torn about running one of the workers on the main 
thread. I fear that we could have random errors because of the stack size of 
the "main" thread that could be different from the stack size of the 
"satellite" threads. There's 99.99% chance that this won't happen, but I'd 
prefer that behavior to be explicit.

We could have:

  -j0 : use all hardware threads
  -j1: don't use multi-threading, run all the tasks on the main thread
  -jN: use the specified number of threads

The rationale is that we're using clang-scan-deps as-a-DLL in Fastbuild, to 
extract the dependencies. Since Fastbuild already has its own thread pool 
management, we call into clang-scan-deps with -j1 from different Fastbuild 
threads (but keeping the `DependencyScanningService` alive between calls). It 
would great if each call to clang-scan-deps wouldn't create a extra new thread.

Perhaps any of you would like to comment? +@mehdi_amini


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102633

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

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

2021-05-21 Thread David Blaikie via Phabricator via cfe-commits

dblaikie added a comment.

I'd still like to hear from some of the other folks mentioned previously.

(though there is precedent for debug info modes being frontend, like -gmlt, etc 
- so it's not totally novel/to be avoided, but I'd like the discussion first)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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

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

2021-05-21 Thread Fangrui Song via Phabricator via cfe-commits

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

LGTM. This looks like an improvement because it avoids a temporary 
`MCObjectFileInfo MOFI;` (which appeared to be initialized in two subsequent 
calls) in numerous places.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101921

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

[PATCH] D100581: [Clang] -Wunused-but-set-parameter and -Wunused-but-set-variable

2021-05-21 Thread Michael Benfield via Phabricator via cfe-commits

mbenfield updated this revision to Diff 346904.
mbenfield added a comment.
Herald added subscribers: llvm-commits, lldb-commits, kbarton, hiraditya, 
nemanjai.
Herald added projects: LLDB, LLVM.

Don't warn for reference or dependent types (fixing false positives).

Also fix a few places where this warning is correctly triggered. In a couple
places I did that by adding __attribute__((unused)) rather than removing the
unused variable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100581

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/p12.cpp
  clang/test/CodeGen/2007-10-30-Volatile.c
  clang/test/CodeGen/X86/x86_32-xsave.c
  clang/test/CodeGen/X86/x86_64-xsave.c
  clang/test/CodeGen/builtins-arm.c
  clang/test/CodeGen/builtins-riscv.c
  clang/test/FixIt/fixit.cpp
  clang/test/Misc/warning-wall.c
  clang/test/Sema/shift.c
  clang/test/Sema/vector-gcc-compat.c
  clang/test/Sema/vector-gcc-compat.cpp
  clang/test/Sema/warn-unused-but-set-parameters.c
  clang/test/Sema/warn-unused-but-set-variables.c
  clang/test/SemaCXX/goto.cpp
  clang/test/SemaCXX/shift.cpp
  clang/test/SemaCXX/sizeless-1.cpp
  clang/test/SemaCXX/warn-unused-but-set-parameters-cpp.cpp
  clang/test/SemaCXX/warn-unused-but-set-variables-cpp.cpp
  clang/test/SemaObjC/foreach.m
  lldb/source/Interpreter/CommandInterpreter.cpp
  lldb/source/Plugins/ABI/PowerPC/ABISysV_ppc.cpp
  
lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.cpp
  llvm/lib/Target/AArch64/GISel/AArch64PostSelectOptimize.cpp
  llvm/lib/Target/ARM/ARMISelLowering.cpp
  llvm/lib/Target/ARM/ARMLowOverheadLoops.cpp
  llvm/lib/Target/PowerPC/PPCBranchSelector.cpp
  llvm/lib/Target/X86/X86FloatingPoint.cpp
  llvm/utils/benchmark/src/complexity.cc

Index: llvm/utils/benchmark/src/complexity.cc
===
--- llvm/utils/benchmark/src/complexity.cc
+++ llvm/utils/benchmark/src/complexity.cc
@@ -76,7 +76,6 @@
 LeastSq MinimalLeastSq(const std::vector& n,
const std::vector& time,
BigOFunc* fitting_curve) {
-  double sigma_gn = 0.0;
   double sigma_gn_squared = 0.0;
   double sigma_time = 0.0;
   double sigma_time_gn = 0.0;
@@ -84,7 +83,6 @@
   // Calculate least square fitting parameter
   for (size_t i = 0; i < n.size(); ++i) {
 double gn_i = fitting_curve(n[i]);
-sigma_gn += gn_i;
 sigma_gn_squared += gn_i * gn_i;
 sigma_time += time[i];
 sigma_time_gn += time[i] * gn_i;
Index: llvm/lib/Target/X86/X86FloatingPoint.cpp
===
--- llvm/lib/Target/X86/X86FloatingPoint.cpp
+++ llvm/lib/Target/X86/X86FloatingPoint.cpp
@@ -1526,7 +1526,7 @@
 
 // Scan the assembly for ST registers used, defined and clobbered. We can
 // only tell clobbers from defs by looking at the asm descriptor.
-unsigned STUses = 0, STDefs = 0, STClobbers = 0, STDeadDefs = 0;
+unsigned STUses = 0, STDefs = 0, STClobbers = 0;
 unsigned NumOps = 0;
 SmallSet FRegIdx;
 unsigned RCID;
@@ -1559,8 +1559,6 @@
   case InlineAsm::Kind_RegDef:
   case InlineAsm::Kind_RegDefEarlyClobber:
 STDefs |= (1u << STReg);
-if (MO.isDead())
-  STDeadDefs |= (1u << STReg);
 break;
   case InlineAsm::Kind_Clobber:
 STClobbers |= (1u << STReg);
Index: llvm/lib/Target/PowerPC/PPCBranchSelector.cpp
===
--- llvm/lib/Target/PowerPC/PPCBranchSelector.cpp
+++ llvm/lib/Target/PowerPC/PPCBranchSelector.cpp
@@ -415,5 +415,5 @@
   }
 
   BlockSizes.clear();
-  return true;
+  return EverMadeChange;
 }
Index: llvm/lib/Target/ARM/ARMLowOverheadLoops.cpp
===
--- llvm/lib/Target/ARM/ARMLowOverheadLoops.cpp
+++ llvm/lib/Target/ARM/ARMLowOverheadLoops.cpp
@@ -1247,7 +1247,7 @@
   if (LoLoop.Preheader)
 LoLoop.Start = SearchForStart(LoLoop.Preheader);
   else
-return false;
+return Changed;
 
   // Find the low-overhead loop components and decide whether or not to fall
   // back to a normal loop. Also look for a vctp instructions and decide
@@ -1281,7 +1281,7 @@
   LLVM_DEBUG(LoLoop.dump());
   if (!LoLoop.FoundAllComponents()) {
 LLVM_DEBUG(dbgs() << "ARM Loops: Didn't find loop start, update, end\n");
-return false;
+return Changed;
   }
 
   assert(LoLoop.Start->getOpcode() != ARM::t2WhileLoopStart &&
Index: llvm/lib/Target/ARM/ARMISelLowering.cpp
===
--- llvm/lib/Target/ARM/ARMISelLowering.cpp
+++ llvm/lib/Target/ARM/ARMISelLowering.cpp
@@ -6

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

2021-05-21 Thread ChenZheng via Phabricator via cfe-commits

shchenz requested review of this revision.
shchenz added a comment.

OK, thanks David @dblaikie .

Ping for your comments, we need some discussion here to decide we should fix 
this in FE or BE. See more in https://reviews.llvm.org/D100630#2762354

@aprantl @probinson and other reviewers ^- ^


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100630

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

[PATCH] D100581: [Clang] -Wunused-but-set-parameter and -Wunused-but-set-variable

2021-05-21 Thread Dávid Bolvanský via Phabricator via cfe-commits

xbolva00 added a comment.

>> Also fix a few places where this warning is correctly triggered.

Create new patch please - dont mix fixes with new warning within one patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100581

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

[PATCH] D102904: [LoopNest][LoopFlatten] Change LoopFlattenPass to LoopNest pass

2021-05-21 Thread Yueh-Ting Chen via Phabricator via cfe-commits

eopXD updated this revision to Diff 346965.
eopXD added a comment.
Herald added subscribers: cfe-commits, libcxx-commits, openmp-commits, 
lldb-commits, Sanitizers, shabalin, jsmolens, eric-k256, dcaballe, cota, 
mravishankar, teijeong, frasercrmck, dexonsmith, rdzhabarov, tatianashp, 
wenlei, lxfind, dang, okura, bbn, jdoerfert, msifontes, sstefan1, jurahul, 
kuter, Kayjukh, grosul1, Joonsoo, stephenneuendorffer, kerbowa, liufengdb, 
aartbik, lucyrfox, mgester, arpith-jacob, csigg, nicolasvasilache, antiagainst, 
shauheen, rriddle, mehdi_amini, luismarques, apazos, sameer.abuasal, pengfei, 
s.egerton, dmgreen, Jim, mstorsjo, jocewei, rupprecht, PkmX, jfb, the_o, 
brucehoult, MartinMosbeck, rogfer01, steven_wu, atanasyan, edward-jones, 
zzheng, MaskRay, jrtc27, gbedwell, martong, delcypher, niosHD, cryptoad, 
sabuasal, simoncook, johnrusso, rbar, asb, fedor.sergeev, kbarton, aheejin, 
jgravelle-google, arichardson, sbc100, mgorny, nhaehnle, jvesely, nemanjai, 
sdardis, emaste, jyknight, dschuff, arsenm.
Herald added a reviewer: andreadb.
Herald added a reviewer: alexshap.
Herald added a reviewer: shafik.
Herald added a reviewer: rupprecht.
Herald added a reviewer: jdoerfert.
Herald added a reviewer: jhenderson.
Herald added a reviewer: jdoerfert.
Herald added a reviewer: sstefan1.
Herald added a reviewer: nicolasvasilache.
Herald added a reviewer: herhut.
Herald added a reviewer: rriddle.
Herald added a reviewer: aartbik.
Herald added a reviewer: sscalpone.
Herald added a reviewer: ftynse.
Herald added a reviewer: aaron.ballman.
Herald added a reviewer: baziotis.
Herald added a reviewer: aartbik.
Herald added a reviewer: aartbik.
Herald added a reviewer: int3.
Herald added a reviewer: sjarus.
Herald added a reviewer: gkm.
Herald added projects: clang, Sanitizers, LLDB, libc++, OpenMP, libc++abi, 
MLIR, lld-macho, clang-tools-extra.
Herald added a reviewer: libc++.
Herald added a reviewer: libc++abi.
Herald added a reviewer: lld-macho.

Apply clang-tidy.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102904

Files:
  SECURITY.md
  clang-tools-extra/clang-tidy/modernize/RawStringLiteralCheck.cpp
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/arm_mve.td
  clang/include/clang/Driver/Options.td
  clang/include/clang/Sema/ExternalSemaSource.h
  clang/include/clang/Sema/MultiplexExternalSemaSource.h
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTReader.h
  clang/include/clang/Serialization/ASTWriter.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/DeclCXX.cpp
  clang/lib/Basic/Targets/M68k.cpp
  clang/lib/Basic/Targets/M68k.h
  clang/lib/CodeGen/CGDeclCXX.cpp
  clang/lib/CodeGen/CGException.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenPGO.cpp
  clang/lib/CodeGen/CodeGenPGO.h
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Arch/AArch64.cpp
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/lib/Driver/ToolChains/Arch/M68k.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Interpreter/IncrementalExecutor.cpp
  clang/lib/Interpreter/IncrementalExecutor.h
  clang/lib/Interpreter/Interpreter.cpp
  clang/lib/Parse/Parser.cpp
  clang/lib/Sema/MultiplexExternalSemaSource.cpp
  clang/lib/Sema/SemaAccess.cpp
  clang/lib/Sema/SemaCUDA.cpp
  clang/lib/Sema/SemaConcept.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
  clang/test/AST/ast-dump-constant-var.cu
  clang/test/ClangScanDeps/Inputs/modules_inferred_cdb.json
  clang/test/ClangScanDeps/modules-inferred-explicit-build.m
  clang/test/CodeGen/SystemZ/builtins-systemz-zvector-constrained.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_rdffr.c
  clang/test/CodeGen/asan-globals-alias.cpp
  clang/test/CodeGen/asan-globals-odr.cpp
  clang/test/CodeGen/asan-globals.cpp
  clang/test/CodeGen/asan-static-odr.cpp
  clang/test/CodeGen/attr-weakref2.c
  clang/test/CodeGen/pre-ra-sched.c
  clang/test/CodeGen/semantic-interposition.c
  clang/test/CodeGenCUDA/device-stub.cu
  clang/test/CodeGenCUDA/device-var-linkage.cu
  clang/test/CodeGenCUDA/host-used-device-var.cu
  clang/test/CodeGenCUDA/managed-var.cu
  clang/test/CodeGenCUDA/static-device-var-rdc.cu
  clang/test/CodeGenCXX/debug-info-byval.cpp
  clang/test/CodeGenCXX/wasm-eh.cpp
  clang/test/CodeGenOpenCLCXX/addrspace-constructors.clcpp
  clang/test/Driver/arm-implicit-it.s
  clang/test/Driver/arm-target-as-mimplicit-it.s
  clang/test/Driver/as-options.s
  clang/test/Driver/clang-offload-bundler.c
  clang/test/Driver/lto.c
  clang/test/Driver/m68k-fixed-register.c

[PATCH] D102216: [Clang][docs]JSONLinkDatabase

2021-05-21 Thread Sam McCall via Phabricator via cfe-commits

sammccall added a comment.

Hi, thanks for writing this up! This is an interesting idea and whole-program 
information is something our tooling libraries don't cover.

A few high-level thoughts:

- this has wider scope and probably have wider discussion than a code review, 
an RFC on the cfe-dev mailing list is the usual starting point
- it's unusual for LLVM to define file-formats without tools for working with 
them. compile_commands.json was developed in tandem with a library to use it 
for clang-based analysis. Do you have plans to develop such tools in the LLVM 
tree?
- whether in or out of the LLVM tree, what are the most important use cases for 
such a format? Why was this design picked over others to satisfy them?
- is command/flags the right abstraction for information about how source code 
is ultimately linked? It follows the compile_commands.json precedent, but the 
underlying reasons seem much weaker. (With parsing commands there are a huge 
diversity of options, it's critical we preserve them ~all exactly, and there's 
a clear impl strategy for doing so)
- if the database can contain arbitrarily mixed linker/object file 
manipulation/non-linker commands and the tool is responsible for 
guessing/interpreting them seems to mean this format will be hard to consume 
robustly.
- one motivating case is in the readme (resolving one of multiple definitions 
in the code base). IIUC the suggested implementation is to index the codebase 
using compile_commands.json, and then use link info to choose between multiple 
definitions. This seems quite narrow (only helps when there are multiple 
defintions, but not if they're each linked to the caller in different 
binaries), doesn't yield a particularly *efficient* implementation, and seems 
to admit less invasive solutions (e.g. a subset compile_commands.json that only 
covers sources for one binary).

(Sorry about the delay, I've been off work for a few weeks)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102216

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

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

2021-05-21 Thread Sven van Haastregt via Phabricator via cfe-commits

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

LGTM!


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

https://reviews.llvm.org/D101843

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

[PATCH] D102517: [clang] Add support for the "abstract" contextual keyword of MSVC

2021-05-21 Thread Abbas Sabra via Phabricator via cfe-commits

AbbasSabra updated this revision to Diff 347018.
AbbasSabra marked 3 inline comments as done.
AbbasSabra added a comment.

Updating D102517 : [clang]Apply code review


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102517

Files:
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Sema/DeclSpec.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaCXX/MicrosoftExtensions.cpp

Index: clang/test/SemaCXX/MicrosoftExtensions.cpp
===
--- clang/test/SemaCXX/MicrosoftExtensions.cpp
+++ clang/test/SemaCXX/MicrosoftExtensions.cpp
@@ -462,6 +462,77 @@
 virtual ~SealedDestructor() sealed; // expected-warning {{class with destructor marked 'sealed' cannot be inherited from}}
 };
 
+// expected-warning@+1 {{'abstract' keyword is a Microsoft extension}}
+class AbstractClass abstract {
+  int i;
+};
+
+// expected-error@+1 {{variable type 'AbstractClass' is an abstract class}}
+AbstractClass abstractInstance;
+
+// expected-warning@+4 {{abstract class is marked 'sealed'}}
+// expected-note@+3 {{'AbstractAndSealedClass' declared here}}
+// expected-warning@+2 {{'abstract' keyword is a Microsoft extension}}
+// expected-warning@+1 {{'sealed' keyword is a Microsoft extension}}
+class AbstractAndSealedClass abstract sealed {}; // Does no really make sense, but allowed
+
+// expected-error@+1 {{variable type 'AbstractAndSealedClass' is an abstract class}}
+AbstractAndSealedClass abstractAndSealedInstance;
+// expected-error@+1 {{base 'AbstractAndSealedClass' is marked 'sealed'}}
+class InheritFromAbstractAndSealed : AbstractAndSealedClass {};
+
+#if __cplusplus <= 199711L
+// expected-warning@+4 {{'final' keyword is a C++11 extension}}
+// expected-warning@+3 {{'final' keyword is a C++11 extension}}
+#endif
+// expected-error@+1 {{class already marked 'final'}}
+class TooManyVirtSpecifiers1 final final {};
+#if __cplusplus <= 199711L
+// expected-warning@+4 {{'final' keyword is a C++11 extension}}
+#endif
+// expected-warning@+2 {{'sealed' keyword is a Microsoft extension}}
+// expected-error@+1 {{class already marked 'sealed'}}
+class TooManyVirtSpecifiers2 final sealed {};
+#if __cplusplus <= 199711L
+// expected-warning@+6 {{'final' keyword is a C++11 extension}}
+// expected-warning@+5 {{'final' keyword is a C++11 extension}}
+#endif
+// expected-warning@+3 {{abstract class is marked 'final'}}
+// expected-warning@+2 {{'abstract' keyword is a Microsoft extension}}
+// expected-error@+1 {{class already marked 'final'}}
+class TooManyVirtSpecifiers3 final abstract final {};
+#if __cplusplus <= 199711L
+// expected-warning@+6 {{'final' keyword is a C++11 extension}}
+#endif
+// expected-warning@+4 {{abstract class is marked 'final'}}
+// expected-warning@+3 {{'abstract' keyword is a Microsoft extension}}
+// expected-warning@+2 {{'abstract' keyword is a Microsoft extension}}
+// expected-error@+1 {{class already marked 'abstract'}}
+class TooManyVirtSpecifiers4 abstract final abstract {};
+
+class Base {
+  virtual void i();
+};
+class AbstractFunctionInClass : public Base {
+  // expected-note@+2 {{unimplemented pure virtual method 'f' in 'AbstractFunctionInClass'}}
+  // expected-warning@+1 {{'abstract' keyword is a Microsoft extension}}
+  virtual void f() abstract;
+  // expected-warning@+1 {{'abstract' keyword is a Microsoft extension}}
+  void g() abstract; // expected-error {{'g' is not virtual and cannot be declared pure}}
+  // expected-note@+2 {{unimplemented pure virtual method 'h' in 'AbstractFunctionInClass'}}
+  // expected-warning@+1 {{'abstract' keyword is a Microsoft extension}}
+  virtual void h() abstract = 0; // expected-error {{class member already marked 'abstract'}}
+#if __cplusplus <= 199711L
+  // expected-warning@+4 {{'override' keyword is a C++11 extension}}
+#endif
+  // expected-note@+2 {{unimplemented pure virtual method 'i' in 'AbstractFunctionInClass'}}
+  // expected-warning@+1 {{'abstract' keyword is a Microsoft extension}}
+  virtual void i() abstract override;
+};
+
+// expected-error@+1 {{variable type 'AbstractFunctionInClass' is an abstract class}}
+AbstractFunctionInClass abstractFunctionInClassInstance;
+
 void AfterClassBody() {
   // expected-warning@+1 {{attribute 'deprecated' is ignored, place it after "struct" to apply attribute to type declaration}}
   struct D {} __declspec(deprecated);
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -16436,6 +16436,7 @@
 void Sema::ActOnStartCXXMemberDeclarations(Scope *S, Decl *TagD,

[PATCH] D102517: [clang] Add support for the "abstract" contextual keyword of MSVC

2021-05-21 Thread Abbas Sabra via Phabricator via cfe-commits

AbbasSabra added a comment.

> Does MS use this in any library headers or such

I didn't check if they do. But if any codebase does use "abstract" and they are 
trying to use clang-cl they would face a parsing error.
My use case was running static analysis on code that uses this feature. Such an 
error had a great impact on the quality of the analysis.




Comment at: clang/lib/Parse/ParseDeclCXX.cpp:3314
   if (getLangOpts().CPlusPlus && Tok.is(tok::identifier)) {
-VirtSpecifiers::Specifier Specifier = isCXX11VirtSpecifier(Tok);
-assert((Specifier == VirtSpecifiers::VS_Final ||
-Specifier == VirtSpecifiers::VS_GNU_Final ||
-Specifier == VirtSpecifiers::VS_Sealed) &&
+for (VirtSpecifiers::Specifier Specifier = isCXX11VirtSpecifier(Tok);
+ Specifier != VirtSpecifiers::VS_None;

hans wrote:
> This 'for' construct is hard to follow. I think it might be easier to follow 
> as a while loop, maybe
> 
> ```
> while ((Specifier = isCXX11VirtSpecifier(Tok)) != VirtSpecifiers::VS_None) {
> ```
> 
> Also the "is" prefix in isCXX11VirtSpecifier is confusing given that it 
> doesn't return a bool.
For "for" vs "while" if you use while you will have to declare the variable 
before the loop giving it the wrong scope which makes it less readable in my 
opinion. 
For  !!isCXX11VirtSpecifier!! I agree but I wouldn't separate the rename from 
this patch(I'm not sure what is the guidelines here)




Comment at: clang/lib/Sema/DeclSpec.cpp:1479
+  case VS_Abstract:
+VS_abstractLoc = Loc;
+break;

hans wrote:
> nit: the other cases just use one line
clang-format doesn't like it. Should I ignore it?



Comment at: clang/lib/Sema/DeclSpec.cpp:1493
   case VS_Sealed: return "sealed";
+  case VS_Abstract:
+return "abstract";

hans wrote:
> nit: skip the newline for consistency here too
same clang-format splits the line


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102517

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

[PATCH] D102772: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute

2021-05-21 Thread Marco Elver via Phabricator via cfe-commits

melver added inline comments.



Comment at: clang/test/CodeGen/sanitize-coverage.c:23-87
+static inline __attribute__((__always_inline__)) void always_inlined_fn(int n) 
{
+  if (n)
+x[n] = 42;
+}
+// CHECK-LABEL: define dso_local void @test_always_inline(
+void test_always_inline(int n) {
+  // CHECK-DAG: call void @__sanitizer_cov_trace_pc

vitalybuka wrote:
> you are adding tests for unrelated code.
> Could you please land is as a separate NFC patch first?
Which bits in particular? Just the 


```
static inline __attribute__((__always_inline__)) void always_inlined_fn(int n) {
  if (n)
x[n] = 42;
}
// CHECK-LABEL: define dso_local void @test_always_inline(
void test_always_inline(int n) {
  // CHECK-DAG: call void @__sanitizer_cov_trace_pc
  // CHECK-DAG: call void @__sanitizer_cov_trace_const_cmp
  always_inlined_fn(n);
}
```

part?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102772

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

[PATCH] D99439: Update @llvm.powi to handle different int sizes for the exponent

2021-05-21 Thread Bjorn Pettersson via Phabricator via cfe-commits

bjope marked 3 inline comments as done.
bjope added inline comments.



Comment at: llvm/test/Transforms/InstCombine/pow_fp_int16.ll:3
 
-; PR42190
+; Test case was copied from pow_fp_int.ll but adjusted for 16-bit int.
+; Assuming that we can't generate test checks for the same reason (PR42740).

xbolva00 wrote:
> Precommit? And we dont need full copy of existings tests - 2-3 tests for 
> 16bit int are anough.
I've pre-commited the tests now. Remove some of the tests (mainly the ones 
related to i64. But I think most of the others are relevant as regression test 
to see that we get what is expected for the different scenarios also with 
16-bit int.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99439

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

[PATCH] D93565: scan-view: Remove Reporter.py and associated AppleScript files

2021-05-21 Thread Tom Stellard via Phabricator via cfe-commits

tstellar added a comment.

Are you still seeing failures in the main branch?  I thought I had fixed this 
with Revision: https://reviews.llvm.org/D96367.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93565

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

[PATCH] D93565: scan-view: Remove Reporter.py and associated AppleScript files

2021-05-21 Thread Ben Jackson via Phabricator via cfe-commits

puremourning added a comment.

Erm, doh. I thought I was on main, but I was using clang 12.0.0 (tag 
llvmorg-10.0.0 from llvm-project). We tend to only use release tagged versions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93565

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

[PATCH] D102443: [PowerPC] Added multiple PowerPC builtins

2021-05-21 Thread Quinn Pham via Phabricator via cfe-commits

quinnp updated this revision to Diff 347029.
quinnp added a comment.

Adding a comment in BuiltinsPPC.def for motivation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102443

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/test/CodeGen/builtins-ppc-xlcompat-sync.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-msync.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-sync.ll
  llvm/test/CodeGen/PowerPC/eieio.ll

Index: llvm/test/CodeGen/PowerPC/eieio.ll
===
--- llvm/test/CodeGen/PowerPC/eieio.ll
+++ llvm/test/CodeGen/PowerPC/eieio.ll
@@ -4,7 +4,9 @@
 
 define void @eieio_test() {
 ; CHECK-LABEL: @eieio_test
-; CHECK: eieio
+; CHECK: ori r2, r2, 0
+; CHECK-NEXT: ori r2, r2, 0
+; CHECK-NEXT: eieio
 ; CHECK-NEXT: blr
 
 entry:
Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-sync.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-sync.ll
@@ -0,0 +1,74 @@
+; RUN: llc -verify-machineinstrs -mtriple=powerpcle-unknown-linux-gnu \
+; RUN: -mcpu=pwr8 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-linux-gnu \
+; RUN: -mcpu=pwr8 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN: -mcpu=pwr8 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN: -mcpu=pwr8 < %s | FileCheck %s
+
+define dso_local void @test_builtin_ppc_eieio() #0 {
+; CHECK-LABEL: test_builtin_ppc_eieio
+
+entry:
+  call void @llvm.ppc.eieio()
+; CHECK: ori 2, 2, 0
+; CHECK-NEXT: ori 2, 2, 0
+; CHECK-NEXT: eieio
+ 
+  ret void
+}
+
+declare void @llvm.ppc.eieio() #2
+
+define dso_local void @test_builtin_ppc_iospace_eieio() #0 {
+; CHECK-LABEL: test_builtin_ppc_iospace_eieio
+
+entry:
+  call void @llvm.ppc.iospace.eieio()
+; CHECK: ori 2, 2, 0
+; CHECK-NEXT: ori 2, 2, 0
+; CHECK-NEXT: eieio
+ 
+  ret void
+}
+
+declare void @llvm.ppc.iospace.eieio() #2
+
+define dso_local void @test_builtin_ppc_iospace_lwsync() #0 {
+; CHECK-LABEL: test_builtin_ppc_iospace_lwsync
+
+entry:
+  call void @llvm.ppc.iospace.lwsync()
+; CHECK: lwsync
+
+  ret void
+}
+
+declare void @llvm.ppc.iospace.lwsync() #2
+
+define dso_local void @test_builtin_ppc_iospace_sync() #0 {
+; CHECK-LABEL: test_builtin_ppc_iospace_sync
+
+entry:
+  call void @llvm.ppc.iospace.sync()
+; CHECK: sync
+
+  ret void
+}
+
+declare void @llvm.ppc.iospace.sync() #2
+
+define dso_local void @test_builtin_ppc_icbt() #0 {
+; CHECK-LABEL: test_builtin_ppc_icbt
+
+entry:
+  %a = alloca i8*, align 8
+  %0 = load i8*, i8** %a, align 8
+  call void @llvm.ppc.icbt(i8* %0)
+; CHECK: icbt 0, 0, 3
+
+  ret void
+}
+
+declare void @llvm.ppc.icbt(i8*) #2
Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-msync.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-msync.ll
@@ -0,0 +1,33 @@
+; RUN: llc -verify-machineinstrs -mtriple=powerpcle-unknown-linux-gnu \
+; RUN:-mattr=+msync -mcpu=pwr8 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-linux-gnu \
+; RUN:-mattr=+msync -mcpu=pwr8 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:-mattr=+msync -mcpu=pwr8 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:-mattr=+msync -mcpu=pwr8 < %s | FileCheck %s
+
+define dso_local void @test_builtin_ppc_iospace_lwsync() #0 {
+; CHECK-LABEL: test_builtin_ppc_iospace_lwsync
+
+entry:
+  call void @llvm.ppc.iospace.lwsync()
+; CHECK: msync
+
+  ret void
+}
+
+declare void @llvm.ppc.iospace.lwsync() #2
+
+define dso_local void @test_builtin_ppc_iospace_sync() #0 {
+; CHECK-LABEL: test_builtin_ppc_iospace_sync
+
+entry:
+  call void @llvm.ppc.iospace.sync()
+; CHECK: msync
+
+  ret void
+}
+
+declare void @llvm.ppc.iospace.sync() #2
+
Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
===
--- llvm/lib/Target/PowerPC/PPCInstrInfo.td
+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td
@@ -2044,6 +2044,8 @@
   (DCBTST 0, xoaddr:$dst)>;
 def : Pat<(int_ppc_dcbf xoaddr:$dst),
   (DCBF 0, xoaddr:$dst)>;
+def : Pat<(int_ppc_icbt xoaddr:$dst),
+  (ICBT 0, xoaddr:$dst)>;
 
 def : Pat<(prefetch xoaddr:$dst, (i32 0), imm, (i32 1)),
   (DCBT 0, xoaddr:$dst)>;   // data prefetch for loads
@@ -2565,11 +2567,21 @@
 def EnforceIEIO : XForm_24_eieio<31, 854, (outs), (ins),
  "eieio", IIC_LdStLoad, []>;
 
+def PseudoEIEIO : PPCEmitTimePseudo<(outs), (ins), "#PPCEIEIO",
+  [(in

[PATCH] D93565: scan-view: Remove Reporter.py and associated AppleScript files

2021-05-21 Thread Tom Stellard via Phabricator via cfe-commits

tstellar added a comment.

In D93565#2773761 , @puremourning 
wrote:

> Erm, doh. I thought I was on main, but I was using clang 12.0.0 (tag 
> llvmorg-12.0.0 from llvm-project). We tend to only use release tagged 
> versions.

OK, I've cherry-picked this fix to the release/12.x branch, so it should be 
working in the 12.0.1 release, and in 12.0.1-rc1 when it comes out if you want 
to verify the fix there.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93565

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

[PATCH] D102835: [analyzer] Correctly propagate ConstructionContextLayer thru ParenExpr

2021-05-21 Thread Tomasz Kamiński via Phabricator via cfe-commits

tomasz-kaminski-sonarsource added a comment.

I do not have commit rights. If there are no additional changes needed, would 
it be possible to you to commit the changes on my behalf?


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

https://reviews.llvm.org/D102835

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

[PATCH] D102850: [C++4OpenCL] Fix overloading resolution of addrspace constructors

2021-05-21 Thread Anastasia Stulova via Phabricator via cfe-commits

Anastasia added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:9870
 
+  if (S.getLangOpts().OpenCL) {
+if (const auto *CD1 = 
dyn_cast_or_null(Cand1.Function)) {

I think we should remove the OpenCL check since it is not OpenCL specific rule 
and you are using common helpers indeed!

I also wonder if this should be applied to all member functions not only ctors 
since `isBetterOverloadCandidate` should be used for everything?

However it seems that other members are already handled somehow 
https://godbolt.org/z/MrWKPKed7. Do you know where this handling comes from?



Comment at: clang/test/CodeGenOpenCLCXX/addrspace-constructors.clcpp:14
   // Local variables are handled in local_addrspace_init.clcpp
-  // FIXME: __private and __generic constructors clash for __private variable
-  // X() /*__generic*/ = default;
+  X() /*__generic*/ = default;
   X() __private : x(0) {}

Let's add a `CHECK` to make sure that the overload with the specific address 
space is used.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102850

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

[PATCH] D99683: [HIP] Support ThinLTO

2021-05-21 Thread Teresa Johnson via Phabricator via cfe-commits

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

lgtm


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

https://reviews.llvm.org/D99683

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

[PATCH] D102488: [clang][deps] Prune unused header search paths

2021-05-21 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 updated this revision to Diff 347042.
jansvoboda11 added a comment.

Split out extra patch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102488

Files:
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/Serialization/ASTReader.h
  clang/include/clang/Serialization/ModuleFile.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningService.h
  clang/include/clang/Tooling/DependencyScanning/DependencyScanningWorker.h
  clang/include/clang/Tooling/DependencyScanning/ModuleDepCollector.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningService.cpp
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
  clang/test/ClangScanDeps/Inputs/header-search-pruning/a/a.h
  clang/test/ClangScanDeps/Inputs/header-search-pruning/b/b.h
  clang/test/ClangScanDeps/Inputs/header-search-pruning/begin/begin.h
  clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json
  clang/test/ClangScanDeps/Inputs/header-search-pruning/end/end.h
  clang/test/ClangScanDeps/Inputs/header-search-pruning/mod.h
  clang/test/ClangScanDeps/Inputs/header-search-pruning/module.modulemap
  clang/test/ClangScanDeps/header-search-pruning.cpp
  clang/tools/clang-scan-deps/ClangScanDeps.cpp

Index: clang/tools/clang-scan-deps/ClangScanDeps.cpp
===
--- clang/tools/clang-scan-deps/ClangScanDeps.cpp
+++ clang/tools/clang-scan-deps/ClangScanDeps.cpp
@@ -163,6 +163,11 @@
 "'-fmodule-file=', '-o', '-fmodule-map-file='."),
 llvm::cl::init(false), llvm::cl::cat(DependencyScannerCategory));
 
+static llvm::cl::opt OptimizeArgs(
+"optimize-args",
+llvm::cl::desc("Whether to optimize command-line arguments of modules."),
+llvm::cl::init(false), llvm::cl::cat(DependencyScannerCategory));
+
 llvm::cl::opt
 NumThreads("j", llvm::cl::Optional,
llvm::cl::desc("Number of worker threads to use (default: use "
@@ -357,7 +362,26 @@
 
 private:
   StringRef lookupPCMPath(ModuleID MID) {
-return Modules[IndexedModuleID{MID, 0}].ImplicitModulePCMPath;
+auto PCMPath = PCMPaths.insert({IndexedModuleID{MID, 0}, ""});
+if (PCMPath.second)
+  PCMPath.first->second = constructPCMPath(lookupModuleDeps(MID));
+return PCMPath.first->second;
+  }
+
+  /// Construct a path where to put the explicitly built PCM - essentially the
+  /// path to implicitly built PCM with the context hash replaced by the final
+  /// (potentially modified) context hash.
+  std::string constructPCMPath(const ModuleDeps &MD) const {
+const std::string &ImplicitPCMPath = MD.ImplicitModulePCMPath;
+StringRef Filename = llvm::sys::path::filename(ImplicitPCMPath);
+StringRef ImplicitContextHashPath =
+llvm::sys::path::parent_path(ImplicitPCMPath);
+StringRef ModuleCachePath =
+llvm::sys::path::parent_path(ImplicitContextHashPath);
+
+SmallString<64> ExplicitPCMPath = ModuleCachePath;
+llvm::sys::path::append(ExplicitPCMPath, MD.ID.ContextHash, Filename);
+return std::string(ExplicitPCMPath);
   }
 
   const ModuleDeps &lookupModuleDeps(ModuleID MID) {
@@ -395,6 +419,8 @@
   std::mutex Lock;
   std::unordered_map
   Modules;
+  std::unordered_map
+  PCMPaths;
   std::vector Inputs;
 };
 
@@ -554,7 +580,7 @@
   SharedStream DependencyOS(llvm::outs());
 
   DependencyScanningService Service(ScanMode, Format, ReuseFileManager,
-SkipExcludedPPRanges);
+SkipExcludedPPRanges, OptimizeArgs);
   llvm::ThreadPool Pool(llvm::hardware_concurrency(NumThreads));
   std::vector> WorkerTools;
   for (unsigned I = 0; I < Pool.getThreadCount(); ++I)
Index: clang/test/ClangScanDeps/header-search-pruning.cpp
===
--- /dev/null
+++ clang/test/ClangScanDeps/header-search-pruning.cpp
@@ -0,0 +1,85 @@
+// RUN: rm -rf %t && mkdir -p %t
+// RUN: cp -r %S/Inputs/header-search-pruning/* %t
+// RUN: cp %S/header-search-pruning.cpp %t/header-search-pruning.cpp
+// RUN: sed -e "s|DIR|%/t|g" -e "s|DEFINES|-DINCLUDE_A|g" %S/Inputs/header-search-pruning/cdb.json > %t/cdb_a.json
+// RUN: sed -e "s|DIR|%/t|g" -e "s|DEFINES|-DINCLUDE_B|g" %S/Inputs/header-search-pruning/cdb.json > %t/cdb_b.json
+// RUN: sed -e "s|DIR|%/t|g" -e "s|DEFINES|-DINCLUDE_A -DINCLUDE_B|g" %S/Inputs/header-search-pruning/cdb.json > %t/cdb_ab.json
+//
+// RUN: clang-scan-deps -compilation-database %t/cdb_a.json -format experimental-full -optimize-args >> %t/result_a.json
+// RUN: cat %t/result_a.json | sed 's/\\/\//g' | FileCheck --check-prefixes=CHECK_A %s
+//
+// RUN: clang-scan-deps -compilation-database %t/cdb_b.json -format experimental-full -

[PATCH] D102853: [OpenCL] Align definition of __IMAGE_SUPPORT feature macro with OpenCL version and opencl_c_images feature macro definition

2021-05-21 Thread Anastasia Stulova via Phabricator via cfe-commits

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

LGTM! Although I think it would be better if we set `__IMAGE_SUPPORT__` 
conditionally also for earlier OpenCL versions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102853

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

[PATCH] D102488: [clang][deps] Prune unused header search paths

2021-05-21 Thread Jan Svoboda via Phabricator via cfe-commits

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

This is now ready for review.




Comment at: clang/test/ClangScanDeps/Inputs/header-search-pruning/cdb.json:4
+"directory": "DIR",
+"command": "clang -E DIR/header-search-pruning.cpp -Ibegin -I1 -Ia -I3 -I4 
-I5 -I6 -Ib -I8 -Iend DEFINES -fmodules -fcxx-modules 
-fmodules-cache-path=DIR/module-cache -fimplicit-modules 
-fmodule-map-file=DIR/module.modulemap",
+"file": "DIR/header-search-pruning.cpp"

The extra numerical include directories here force `AST{Writer,Reader}` to work 
with multi-byte blob, providing extra test coverage.



Comment at: clang/test/ClangScanDeps/header-search-pruning.cpp:27
+// CHECK_A:"-I",
+// CHECK_A-NEXT:   "begin",
+// CHECK_A-NEXT:   "-I",

The `being` and `end` include directories here are sentinels that make it 
easier to make positive/negative occurrence checks with `-NEXT`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102488

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

[PATCH] D102923: [clang][lex] Remark for used header search paths

2021-05-21 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 created this revision.
jansvoboda11 added reviewers: Bigcheese, dexonsmith.
jansvoboda11 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

For dependency scanning, it would be useful to collect header search paths 
(provided on command-line via `-I` and friends) that were actually used during 
preprocessing. This patch adds that feature to `HeaderSearch` along with a new 
remark that reports such paths as they get used.

Previous version of this patch tried to use the existing `LookupFileCache` to 
report used paths via `HitIdx`. That doesn't work for `ComputeUserEntryUsage` 
(which is intended to be called *after* preprocessing), because it indexes used 
search paths by the file name. This means the values get overwritten when the 
code contains `#include_next`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102923

Files:
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Lex/HeaderSearch.h
  clang/lib/Frontend/InitHeaderSearch.cpp
  clang/lib/Lex/HeaderSearch.cpp
  clang/test/Preprocessor/Inputs/header-search-user-entries/a/a.h
  clang/test/Preprocessor/Inputs/header-search-user-entries/a_next/a.h
  clang/test/Preprocessor/Inputs/header-search-user-entries/b/b.h
  clang/test/Preprocessor/Inputs/header-search-user-entries/d/d.h
  clang/test/Preprocessor/header-search-user-entries.c

Index: clang/test/Preprocessor/header-search-user-entries.c
===
--- /dev/null
+++ clang/test/Preprocessor/header-search-user-entries.c
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -fsyntax-only %s -Rinclude-header-search-usage \
+// RUN:   -I%S/Inputs/header-search-user-entries/a -I%S/Inputs/header-search-user-entries/a_next \
+// RUN:   -I%S/Inputs/header-search-user-entries/b -I%S/Inputs/header-search-user-entries/c \
+// RUN:   -I%S/Inputs/header-search-user-entries/d 2>&1 | FileCheck %s
+
+#include "a.h"
+#include "d.h"
+
+// CHECK: remark: user-provided search path used '{{.*}}/header-search-user-entries/a'
+// CHECK: remark: user-provided search path used '{{.*}}/header-search-user-entries/a_next'
+// CHECK: remark: user-provided search path used '{{.*}}/header-search-user-entries/d'
Index: clang/test/Preprocessor/Inputs/header-search-user-entries/a/a.h
===
--- /dev/null
+++ clang/test/Preprocessor/Inputs/header-search-user-entries/a/a.h
@@ -0,0 +1 @@
+#include_next "a.h"
Index: clang/lib/Lex/HeaderSearch.cpp
===
--- clang/lib/Lex/HeaderSearch.cpp
+++ clang/lib/Lex/HeaderSearch.cpp
@@ -108,6 +108,18 @@
<< NumSubFrameworkLookups << " subframework lookups.\n";
 }
 
+std::vector HeaderSearch::ComputeUserEntryUsage() const {
+  std::vector UserEntryUsage(HSOpts->UserEntries.size());
+  for (unsigned i = 0, e = SearchDirsUsage.size(); i < e; ++i) {
+if (SearchDirsUsage[i]) {
+  auto UserEntryIdxIt = SearchDirToHSEntry.find(i);
+  if (UserEntryIdxIt != SearchDirToHSEntry.end())
+UserEntryUsage[UserEntryIdxIt->second] = true;
+}
+  }
+  return UserEntryUsage;
+}
+
 /// CreateHeaderMap - This method returns a HeaderMap for the specified
 /// FileEntry, uniquing them through the 'HeaderMaps' datastructure.
 const HeaderMap *HeaderSearch::CreateHeaderMap(const FileEntry *FE) {
@@ -649,6 +661,17 @@
   return None;
 }
 
+void HeaderSearch::CacheLookupSuccess(LookupFileCacheInfo &CacheLookup,
+  unsigned HitIdx) {
+  CacheLookup.HitIdx = HitIdx;
+  SearchDirsUsage[HitIdx] = true;
+
+  auto UserEntryIdxIt = SearchDirToHSEntry.find(HitIdx);
+  if (UserEntryIdxIt != SearchDirToHSEntry.end())
+Diags.Report(diag::remark_pp_include_header_search_usage)
+<< HSOpts->UserEntries[UserEntryIdxIt->second].Path;
+}
+
 void HeaderSearch::setTarget(const TargetInfo &Target) {
   ModMap.setTarget(Target);
 }
@@ -987,7 +1010,7 @@
   &File->getFileEntry(), isAngled, FoundByHeaderMap);
 
 // Remember this location for the next lookup we do.
-CacheLookup.HitIdx = i;
+CacheLookupSuccess(CacheLookup, i);
 return File;
   }
 
@@ -1017,8 +1040,8 @@
 return MSFE;
   }
 
-  LookupFileCacheInfo &CacheLookup = LookupFileCache[Filename];
-  CacheLookup.HitIdx = LookupFileCache[ScratchFilename].HitIdx;
+  CacheLookupSuccess(LookupFileCache[Filename],
+ LookupFileCache[ScratchFilename].HitIdx);
   // FIXME: SuggestedModule.
   return File;
 }
Index: clang/lib/Frontend/InitHeaderSearch.cpp
===
--- clang/lib/Frontend/InitHeaderSearch.cpp
+++ clang/lib/Frontend/InitHeaderSearch.cpp
@@ -36,9 +36,11 @@
 struct IncludePathInfo {
   IncludeDirGroup Group;
   DirectoryLookup Path;
+  Optional UserEntryIdx;
 
-  IncludePathInfo(IncludeDirGroup Group,

[PATCH] D102924: [clang] NFC: Replace std::pair by a struct in InitHeaderSearch

2021-05-21 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 created this revision.
jansvoboda11 added reviewers: Bigcheese, dexonsmith.
jansvoboda11 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch replaces a `std::pair` by a proper struct in `InitHeaderSearch`. 
This will be useful in a follow-up: D102923 .


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102924

Files:
  clang/lib/Frontend/InitHeaderSearch.cpp


Index: clang/lib/Frontend/InitHeaderSearch.cpp
===
--- clang/lib/Frontend/InitHeaderSearch.cpp
+++ clang/lib/Frontend/InitHeaderSearch.cpp
@@ -32,14 +32,20 @@
 using namespace clang::frontend;
 
 namespace {
+/// Holds information about a single include path.
+struct IncludePathInfo {
+  IncludeDirGroup Group;
+  DirectoryLookup Path;
+
+  IncludePathInfo(IncludeDirGroup Group, DirectoryLookup Path)
+  : Group(Group), Path(Path) {}
+};
 
 /// InitHeaderSearch - This class makes it easier to set the search paths of
 ///  a HeaderSearch object. InitHeaderSearch stores several search path lists
 ///  internally, which can be sent to a HeaderSearch object in one swoop.
 class InitHeaderSearch {
-  std::vector > IncludePath;
-  typedef std::vector >::const_iterator path_iterator;
+  std::vector IncludePath;
   std::vector > SystemHeaderPrefixes;
   HeaderSearch &Headers;
   bool Verbose;
@@ -154,8 +160,7 @@
 
   // If the directory exists, add it.
   if (auto DE = FM.getOptionalDirectoryRef(MappedPathStr)) {
-IncludePath.push_back(
-  std::make_pair(Group, DirectoryLookup(*DE, Type, isFramework)));
+IncludePath.emplace_back(Group, DirectoryLookup(*DE, Type, isFramework));
 return true;
   }
 
@@ -165,9 +170,8 @@
 if (auto FE = FM.getFile(MappedPathStr)) {
   if (const HeaderMap *HM = Headers.CreateHeaderMap(*FE)) {
 // It is a headermap, add it to the search path.
-IncludePath.push_back(
-  std::make_pair(Group,
- DirectoryLookup(HM, Type, Group == IndexHeaderMap)));
+IncludePath.emplace_back(
+Group, DirectoryLookup(HM, Type, Group == IndexHeaderMap));
 return true;
   }
 }
@@ -558,32 +562,32 @@
 
   // Quoted arguments go first.
   for (auto &Include : IncludePath)
-if (Include.first == Quoted)
-  SearchList.push_back(Include.second);
+if (Include.Group == Quoted)
+  SearchList.push_back(Include.Path);
 
   // Deduplicate and remember index.
   RemoveDuplicates(SearchList, 0, Verbose);
   unsigned NumQuoted = SearchList.size();
 
   for (auto &Include : IncludePath)
-if (Include.first == Angled || Include.first == IndexHeaderMap)
-  SearchList.push_back(Include.second);
+if (Include.Group == Angled || Include.Group == IndexHeaderMap)
+  SearchList.push_back(Include.Path);
 
   RemoveDuplicates(SearchList, NumQuoted, Verbose);
   unsigned NumAngled = SearchList.size();
 
   for (auto &Include : IncludePath)
-if (Include.first == System || Include.first == ExternCSystem ||
-(!Lang.ObjC && !Lang.CPlusPlus && Include.first == CSystem) ||
+if (Include.Group == System || Include.Group == ExternCSystem ||
+(!Lang.ObjC && !Lang.CPlusPlus && Include.Group == CSystem) ||
 (/*FIXME !Lang.ObjC && */ Lang.CPlusPlus &&
- Include.first == CXXSystem) ||
-(Lang.ObjC && !Lang.CPlusPlus && Include.first == ObjCSystem) ||
-(Lang.ObjC && Lang.CPlusPlus && Include.first == ObjCXXSystem))
-  SearchList.push_back(Include.second);
+ Include.Group == CXXSystem) ||
+(Lang.ObjC && !Lang.CPlusPlus && Include.Group == ObjCSystem) ||
+(Lang.ObjC && Lang.CPlusPlus && Include.Group == ObjCXXSystem))
+  SearchList.push_back(Include.Path);
 
   for (auto &Include : IncludePath)
-if (Include.first == After)
-  SearchList.push_back(Include.second);
+if (Include.Group == After)
+  SearchList.push_back(Include.Path);
 
   // Remove duplicates across both the Angled and System directories.  GCC does
   // this and failing to remove duplicates across these two groups breaks


Index: clang/lib/Frontend/InitHeaderSearch.cpp
===
--- clang/lib/Frontend/InitHeaderSearch.cpp
+++ clang/lib/Frontend/InitHeaderSearch.cpp
@@ -32,14 +32,20 @@
 using namespace clang::frontend;
 
 namespace {
+/// Holds information about a single include path.
+struct IncludePathInfo {
+  IncludeDirGroup Group;
+  DirectoryLookup Path;
+
+  IncludePathInfo(IncludeDirGroup Group, DirectoryLookup Path)
+  : Group(Group), Path(Path) {}
+};
 
 /// InitHeaderSearch - This class makes it easier to set the search paths of
 ///  a HeaderSearch object. InitHeaderSearch stores several search path lists
 ///  internally, which can be sent to a HeaderSearch object in one swoop.
 class InitHeaderSearch {
-  std::vector > IncludePath;
-

[PATCH] D100733: [clang] NFC: change uses of `Expr->getValueKind` into `is?Value`

2021-05-21 Thread Aaron Puchert via Phabricator via cfe-commits

aaronpuchert added a comment.

In D100733#2760890 , @mizvekov wrote:

> - I still think a new value category is simpler than the two phase overload 
> resolution it replaces :D

Not sure if it's simpler, but it'll produce less confusing results.

> - This new value category would (so far as this is only an experiment I am 
> running), only apply to standards older than c++23, where from then on it's 
> just the current categories and the rules as in P2266 
> .
> - Even in the old standards it replaces, it does not introduce any drastic 
> changes. This new category is the same as XValues as far as overload 
> resolution is concerned (with the small addition that it binds less 
> preferentially to non-const l-value references), and as far as type deduction 
> goes, it behaves exactly as LValues.

A new value category feels like a global change for a local problem. We can 
explain the behavior that we want without introducing a new value category: 
either as a “combined” overload resolution for xvalue and lvalue, where all 
candidates for the xvalue are strictly better than any candidate for the 
lvalue, or as a two-phase resolution that falls back only if there are no 
candidates. These explanations are equivalent.

In D100733#2761031 , @rsmith wrote:

> What do we think about renaming `isRValue()` to `isPRValue()` and renaming 
> `VK_RValue` to `VK_PRValue`, adding a "real" `isRValue()`, and then 
> performing this cleanup?

One problem might be that C and C++ have different terminology, right? I like 
the idea of going with prvalue instead of rvalue, then it's the right thing for 
C++ and if you're coming from the C world it's at least not confusing. But 
perhaps I would not introduce for now an `isRValue` function. (Although C 
doesn't have xvalues, so maybe it doesn't matter?)

In D100733#2761052 , @mizvekov wrote:

> Is there any special reason we ended up in this state of affairs with the 
> swapped out names?

My impression is that some people didn't like the changes that came with C++11 
and that it made the terminology of C and C++ somewhat inconsistent. (Though I 
think you can work with the C++ terminology in C, there are just no xvalues, 
but you can't work the other way around.)

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100733

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

[PATCH] D102742: [IR] make stack-protector-guard-* flags into module attrs

2021-05-21 Thread Teresa Johnson via Phabricator via cfe-commits

tejohnson added a comment.

In D102742#2767569 , @nickdesaulniers 
wrote:

> Obviously needs work/cleanup, changes to x86, and tests, but posting for 
> early feedback about module level attributes vs function level attributes, or 
> possibly something else.  I tested this quickly with thin LTO of the Linux 
> kernel and it worked.

I haven't looked through in too much detail, but I see you have the module flag 
type set as Warning on conflict. I guess the answer to module level vs function 
level depends on whether it is valid to link together files compiled with 
different values of these flags and if so what the expected behavior should be. 
How does this work on non-LTO? If it works just fine, i.e. the functions from 
the modules with one value are compiled ok with that value and linked with 
functions compiled effectively with another value, then that would point to a 
function attribute so you can mimic the mix-and-match behavior. If it is 
unexpected, then perhaps better to keep as a module flag but Error? With 
Warning, the value from the first module being linked is used - would that be 
surprising?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102742

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

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

2021-05-21 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:252
+- Option ``IfMacros`` has been added. This lets you define macros that get
+  formatted like conditionals much like ``ForEachMacros`` get stiled like
+  foreach loops.

stiled? did you mean styled?



Comment at: clang/lib/Format/FormatTokenLexer.cpp:1019
   FormatTok->setType(it->second);
+  if (it->second == TT_IfMacro) {
+FormatTok->Tok.setKind(tok::kw_if);

Is there any chance you could leave a comment here as to why this is needed, I 
can't work it out?



Comment at: clang/lib/Format/TokenAnnotator.cpp:3025
   return false;
+if (Left.is(TT_IfMacro)) {
+  return false;

I'll let you decide if you think we need another SBPO_XXX style?



Comment at: clang/unittests/Format/FormatTest.cpp:19699
   verifyFormat("if constexpr ( a )\n  return;", Spaces);
+  verifyFormat("MYIF( a )\n  return;", Spaces);
+  verifyFormat("MYIF( a )\n  return;\nelse MYIF( b )\n  return;", Spaces);

this should support ```MYIF(```  by processing 
SpacesInConditionalStatement  as we do with FOREACH


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

https://reviews.llvm.org/D102730

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

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

2021-05-21 Thread Hubert Tong via Phabricator via cfe-commits

hubert.reinterpretcast added inline comments.



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

TaoPan wrote:
> hubert.reinterpretcast wrote:
> > hubert.reinterpretcast wrote:
> > > The test as was committed is bogus. It checks the output binary(!) stream 
> > > for an error message when stderr was not even redirected. Please fix.
> > Fix committed: 
> > https://github.com/llvm/llvm-project/commit/603818b97c795114f66a6fc13e8a5f0e54b49a13
> Thanks for your review comment and fixing!
> I tried to check stderr as you guided and meet empty stdin problem, thanks 
> for your quick fixing and I got FileCheck option --allow-empty can resolve 
> this kind of problem. 
No problem. Thanks for looking into it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101601

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

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

2021-05-21 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

Is ```Signature``` effectively as is?


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

https://reviews.llvm.org/D102706

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

[PATCH] D100794: [HIP] Support overloaded math functions for hipRTC

2021-05-21 Thread Aaron Enye Shi via Phabricator via cfe-commits

ashi1 added inline comments.



Comment at: clang/lib/Headers/__clang_hip_cmath.h:20
 #include 
 #include 
 #include 

we may not need to `#include` limits and/or type_traits if we replaced them 
with `__hip::is_integral` and `__hip::is_arithmetic`.



Comment at: clang/lib/Headers/__clang_hip_cmath.h:587
 #endif
-#endif
+#endif // !defined(__HIPCC_RTC__)
 

I don't think this `#endif` is for `!defined(__HIPCC_RTC__)`. It should be for 
`_LIBCPP_BEGIN_NAMESPACE_STD`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100794

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

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

2021-05-21 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

Could you clang-format the tests please so I can more easily read them.




Comment at: clang/docs/ClangFormatStyleOptions.rst:2790
 
+**LambdaBodyIndentation** (``LambdaBodyIndentationKind``)
+  What is the lambda body indented relative to (default is ``Signature``).

Did you generate this by hand or using the clang/doc/tools/dump_style.py?


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

https://reviews.llvm.org/D102706

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

[PATCH] D102927: [NFC][CodeGenOptions] Refactor checking SanitizeCoverage options

2021-05-21 Thread Marco Elver via Phabricator via cfe-commits

melver created this revision.
melver added a reviewer: vitalybuka.
Herald added a subscriber: dexonsmith.
melver requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Refactor checking SanitizeCoverage options into
CodeGenOptions::hasSanitizeCoverage().


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102927

Files:
  clang/include/clang/Basic/CodeGenOptions.h
  clang/lib/CodeGen/BackendUtil.cpp


Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -736,9 +736,7 @@
addBoundsCheckingPass);
   }
 
-  if (CodeGenOpts.SanitizeCoverageType ||
-  CodeGenOpts.SanitizeCoverageIndirectCalls ||
-  CodeGenOpts.SanitizeCoverageTraceCmp) {
+  if (CodeGenOpts.hasSanitizeCoverage()) {
 PMBuilder.addExtension(PassManagerBuilder::EP_OptimizerLast,
addSanitizerCoveragePass);
 PMBuilder.addExtension(PassManagerBuilder::EP_EnabledOnOptLevel0,
@@ -1108,9 +1106,7 @@
   const LangOptions &LangOpts, PassBuilder &PB) {
   PB.registerOptimizerLastEPCallback([&](ModulePassManager &MPM,
  PassBuilder::OptimizationLevel Level) 
{
-if (CodeGenOpts.SanitizeCoverageType ||
-CodeGenOpts.SanitizeCoverageIndirectCalls ||
-CodeGenOpts.SanitizeCoverageTraceCmp) {
+if (CodeGenOpts.hasSanitizeCoverage()) {
   auto SancovOpts = getSancovOptsFromCGOpts(CodeGenOpts);
   MPM.addPass(ModuleSanitizerCoveragePass(
   SancovOpts, CodeGenOpts.SanitizeCoverageAllowlistFiles,
Index: clang/include/clang/Basic/CodeGenOptions.h
===
--- clang/include/clang/Basic/CodeGenOptions.h
+++ clang/include/clang/Basic/CodeGenOptions.h
@@ -452,6 +452,12 @@
   bool hasMaybeUnusedDebugInfo() const {
 return getDebugInfo() >= codegenoptions::UnusedTypeInfo;
   }
+
+  // Check if any one of SanitizeCoverage* is enabled.
+  bool hasSanitizeCoverage() const {
+return SanitizeCoverageType || SanitizeCoverageIndirectCalls ||
+   SanitizeCoverageTraceCmp;
+  }
 };
 
 }  // end namespace clang


Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -736,9 +736,7 @@
addBoundsCheckingPass);
   }
 
-  if (CodeGenOpts.SanitizeCoverageType ||
-  CodeGenOpts.SanitizeCoverageIndirectCalls ||
-  CodeGenOpts.SanitizeCoverageTraceCmp) {
+  if (CodeGenOpts.hasSanitizeCoverage()) {
 PMBuilder.addExtension(PassManagerBuilder::EP_OptimizerLast,
addSanitizerCoveragePass);
 PMBuilder.addExtension(PassManagerBuilder::EP_EnabledOnOptLevel0,
@@ -1108,9 +1106,7 @@
   const LangOptions &LangOpts, PassBuilder &PB) {
   PB.registerOptimizerLastEPCallback([&](ModulePassManager &MPM,
  PassBuilder::OptimizationLevel Level) {
-if (CodeGenOpts.SanitizeCoverageType ||
-CodeGenOpts.SanitizeCoverageIndirectCalls ||
-CodeGenOpts.SanitizeCoverageTraceCmp) {
+if (CodeGenOpts.hasSanitizeCoverage()) {
   auto SancovOpts = getSancovOptsFromCGOpts(CodeGenOpts);
   MPM.addPass(ModuleSanitizerCoveragePass(
   SancovOpts, CodeGenOpts.SanitizeCoverageAllowlistFiles,
Index: clang/include/clang/Basic/CodeGenOptions.h
===
--- clang/include/clang/Basic/CodeGenOptions.h
+++ clang/include/clang/Basic/CodeGenOptions.h
@@ -452,6 +452,12 @@
   bool hasMaybeUnusedDebugInfo() const {
 return getDebugInfo() >= codegenoptions::UnusedTypeInfo;
   }
+
+  // Check if any one of SanitizeCoverage* is enabled.
+  bool hasSanitizeCoverage() const {
+return SanitizeCoverageType || SanitizeCoverageIndirectCalls ||
+   SanitizeCoverageTraceCmp;
+  }
 };
 
 }  // end namespace clang
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102929: [NFC][SanitizeCoverage] Test always_inline functions work

2021-05-21 Thread Marco Elver via Phabricator via cfe-commits

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

Test that always_inline functions are instrumented as expected.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102929

Files:
  clang/test/CodeGen/sanitize-coverage.c


Index: clang/test/CodeGen/sanitize-coverage.c
===
--- clang/test/CodeGen/sanitize-coverage.c
+++ clang/test/CodeGen/sanitize-coverage.c
@@ -19,4 +19,16 @@
   if (n)
 x[n] = 42;
 }
+
+static inline __attribute__((__always_inline__)) void always_inlined_fn(int n) 
{
+  if (n)
+x[n] = 42;
+}
+// CHECK-LABEL: define dso_local void @test_always_inline(
+void test_always_inline(int n) {
+  // CHECK-DAG: call void @__sanitizer_cov_trace_pc
+  // CHECK-DAG: call void @__sanitizer_cov_trace_const_cmp
+  always_inlined_fn(n);
+}
+
 // CHECK-LABEL: declare void


Index: clang/test/CodeGen/sanitize-coverage.c
===
--- clang/test/CodeGen/sanitize-coverage.c
+++ clang/test/CodeGen/sanitize-coverage.c
@@ -19,4 +19,16 @@
   if (n)
 x[n] = 42;
 }
+
+static inline __attribute__((__always_inline__)) void always_inlined_fn(int n) {
+  if (n)
+x[n] = 42;
+}
+// CHECK-LABEL: define dso_local void @test_always_inline(
+void test_always_inline(int n) {
+  // CHECK-DAG: call void @__sanitizer_cov_trace_pc
+  // CHECK-DAG: call void @__sanitizer_cov_trace_const_cmp
+  always_inlined_fn(n);
+}
+
 // CHECK-LABEL: declare void
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102772: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute

2021-05-21 Thread Marco Elver via Phabricator via cfe-commits

melver updated this revision to Diff 347062.
melver marked 3 inline comments as done.
melver added a comment.

- Refactor test and SanitizeCoverage* checking.
- s/no_sanitize_coverage/nosanitize_coverage/

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102772

Files:
  clang/docs/SanitizerCoverage.rst
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/sanitize-coverage.c
  llvm/bindings/go/llvm/ir_test.go
  llvm/docs/BitCodeFormat.rst
  llvm/docs/LangRef.rst
  llvm/include/llvm/AsmParser/LLToken.h
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/IPO/ForceFunctionAttrs.cpp
  llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/test/Bitcode/attributes.ll
  llvm/test/Bitcode/compatibility.ll
  llvm/utils/emacs/llvm-mode.el
  llvm/utils/llvm.grm
  llvm/utils/vim/syntax/llvm.vim
  llvm/utils/vscode/llvm/syntaxes/ll.tmLanguage.yaml

Index: llvm/utils/vscode/llvm/syntaxes/ll.tmLanguage.yaml
===
--- llvm/utils/vscode/llvm/syntaxes/ll.tmLanguage.yaml
+++ llvm/utils/vscode/llvm/syntaxes/ll.tmLanguage.yaml
@@ -237,6 +237,7 @@
 \\bnosync\\b|\
 \\bnoundef\\b|\
 \\bnounwind\\b|\
+\\bnosanitize_coverage\\b|\
 \\bnull_pointer_is_valid\\b|\
 \\boptforfuzzing\\b|\
 \\boptnone\\b|\
Index: llvm/utils/vim/syntax/llvm.vim
===
--- llvm/utils/vim/syntax/llvm.vim
+++ llvm/utils/vim/syntax/llvm.vim
@@ -138,6 +138,7 @@
   \ nosync
   \ noundef
   \ nounwind
+  \ nosanitize_coverage
   \ null_pointer_is_valid
   \ optforfuzzing
   \ optnone
Index: llvm/utils/llvm.grm
===
--- llvm/utils/llvm.grm
+++ llvm/utils/llvm.grm
@@ -176,6 +176,7 @@
  | sanitize_thread
  | sanitize_memory
  | mustprogress
+ | nosanitize_coverage
  ;
 
 OptFuncAttrs  ::= + _ | OptFuncAttrs FuncAttr ;
Index: llvm/utils/emacs/llvm-mode.el
===
--- llvm/utils/emacs/llvm-mode.el
+++ llvm/utils/emacs/llvm-mode.el
@@ -25,7 +25,7 @@
'("alwaysinline" "argmemonly" "allocsize" "builtin" "cold" "convergent" "dereferenceable" "dereferenceable_or_null" "hot" "inaccessiblememonly"
  "inaccessiblemem_or_argmemonly" "inalloca" "inlinehint" "jumptable" "minsize" "mustprogress" "naked" "nobuiltin" "nonnull"
  "nocallback" "nocf_check" "noduplicate" "nofree" "noimplicitfloat" "noinline" "nomerge" "nonlazybind" "noprofile" "noredzone" "noreturn"
- "norecurse" "nosync" "noundef" "nounwind" "null_pointer_is_valid" "optforfuzzing" "optnone" "optsize" "preallocated" "readnone" "readonly" "returned" "returns_twice"
+ "norecurse" "nosync" "noundef" "nounwind" "nosanitize_coverage" "null_pointer_is_valid" "optforfuzzing" "optnone" "optsize" "preallocated" "readnone" "readonly" "returned" "returns_twice"
  "shadowcallstack" "speculatable" "speculative_load_hardening" "ssp" "sspreq" "sspstrong" "safestack" "sanitize_address" "sanitize_hwaddress" "sanitize_memtag"
  "sanitize_thread" "sanitize_memory" "strictfp" "swifterror" "uwtable" "vscale_range" "willreturn" "writeonly" "immarg") 'symbols) . font-lock-constant-face)
;; Variables
Index: llvm/test/Bitcode/compatibility.ll
===
--- llvm/test/Bitcode/compatibility.ll
+++ llvm/test/Bitcode/compatibility.ll
@@ -1510,7 +1510,7 @@
   ; CHECK: select <2 x i1> , <2 x i8> , <2 x i8> 
 
   call void @f.nobuiltin() builtin
-  ; CHECK: call void @f.nobuiltin() #44
+  ; CHECK: call void @f.nobuiltin() #45
 
   call fastcc noalias i32* @f.noalias() noinline
   ; CHECK: call fastcc noalias i32* @f.noalias() #12
@@ -1904,6 +1904,9 @@
   ret void
 }
 
+declare void @f.nosanitize_coverage() nosanitize_coverage
+; CHECK: declare void @f.nosanitize_coverage() #44
+
 ; immarg attribute
 declare void @llvm.test.immarg.intrinsic(i32 immarg)
 ; CHECK: declare void @llvm.test.immarg.intrinsic(i32 immarg)
@@ -1961,7 +1964,8 @@
 ; CHECK: attributes #41 = { writeonly }
 ; CHECK: attributes #42 = { speculatable }
 ; CHECK: attributes #43 = { strictfp }
-; CHECK: attributes #44 = { builtin }
+; CHECK: attributes #44 = { nosanitize_coverage }
+; CHECK: attributes #45 = { builtin }
 
 ;; Metadata
 
Index: llvm/test/Bitcode/attributes.ll

[PATCH] D102772: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute

2021-05-21 Thread Marco Elver via Phabricator via cfe-commits

melver added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:757-760
+bool HaveSanitizeCoverage =
+CGM.getCodeGenOpts().SanitizeCoverageType ||
+CGM.getCodeGenOpts().SanitizeCoverageIndirectCalls ||
+CGM.getCodeGenOpts().SanitizeCoverageTraceCmp;

vitalybuka wrote:
> consider adding method into CodeGenOptions and replace here and and the rest 
> ideally in a separate patch
> 
https://reviews.llvm.org/D102927



Comment at: clang/test/CodeGen/sanitize-coverage.c:23-87
+static inline __attribute__((__always_inline__)) void always_inlined_fn(int n) 
{
+  if (n)
+x[n] = 42;
+}
+// CHECK-LABEL: define dso_local void @test_always_inline(
+void test_always_inline(int n) {
+  // CHECK-DAG: call void @__sanitizer_cov_trace_pc

melver wrote:
> vitalybuka wrote:
> > you are adding tests for unrelated code.
> > Could you please land is as a separate NFC patch first?
> Which bits in particular? Just the 
> 
> 
> ```
> static inline __attribute__((__always_inline__)) void always_inlined_fn(int 
> n) {
>   if (n)
> x[n] = 42;
> }
> // CHECK-LABEL: define dso_local void @test_always_inline(
> void test_always_inline(int n) {
>   // CHECK-DAG: call void @__sanitizer_cov_trace_pc
>   // CHECK-DAG: call void @__sanitizer_cov_trace_const_cmp
>   always_inlined_fn(n);
> }
> ```
> 
> part?
https://reviews.llvm.org/D102929



Comment at: llvm/lib/AsmParser/LLLexer.cpp:674
   KEYWORD(nounwind);
+  KEYWORD(no_sanitize_coverage);
   KEYWORD(null_pointer_is_valid);

vitalybuka wrote:
> looking at the rest, seems "nosanitize_coverage" follows pattern better :)
I wasn't sure myself, it's a bit inconsistent with "no_sanitize", but I've 
changed it. ;-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102772

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

[PATCH] D102772: [SanitizeCoverage] Add support for NoSanitizeCoverage function attribute

2021-05-21 Thread Marco Elver via Phabricator via cfe-commits

melver added a comment.

Please have a look at the other 2 patches which are now a dependency for this. 
Once you're happy with all 3 I'll push them all together.
Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102772

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

[PATCH] D102835: [analyzer] Correctly propagate ConstructionContextLayer thru ParenExpr

2021-05-21 Thread Balázs Benics via Phabricator via cfe-commits

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

In D102835#2773818 , 
@tomasz-kaminski-sonarsource wrote:

> I do not have commit rights. If there are no additional changes needed, would 
> it be possible to you to commit the changes on my behalf?

I wanted to wait for a couple of days to see if anyone else has something to 
say.
I'm gonna commit your change on your behalf on Monday if it's good for you.

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

https://reviews.llvm.org/D102835

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

[PATCH] D102494: [Clang, Driver] Default to Darwin_libsystem_m veclib on iOS based targets.

2021-05-21 Thread Florian Hahn via Phabricator via cfe-commits

fhahn planned changes to this revision.
fhahn added a comment.

We are still evaluating whether it is safe to use this as default. I'll mark it 
as 'changes planned' for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102494

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

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

2021-05-21 Thread Adrian McCarthy via Phabricator via cfe-commits

amccarth added a comment.

Cool!  This is getting much simpler.  My remaining comments are mostly musings 
and you can tell me to buzz off.

But I'd like to see @aganea's questions addressed.  It does seem redundant to 
have to keep the file name when we already have an object that represents the 
file.




Comment at: llvm/lib/Support/Path.cpp:1237
   RenameEC = copy_file(TmpName, Name);
   setDeleteDisposition(H, true);
 }

I'm curious if this path has ever been exercised.

I see that rename_handle is implemented with MoveFileExW on Windows.  
MoveFileExW docs say it will fail if you're trying to move a _directory_ to 
another device, but that it can do copy+delete to move a _file_ to another 
device.  (That might require adding MOVEFILE_COPY_ALLOWED to the flags passed 
in the MoveFileExW in lib\Support\Windows\Path.inc near line 485.)

Anyway, it just seems like we're re-implementing functionality the OS calls can 
already do for us.

https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-movefileexw



Comment at: llvm/lib/Support/Path.cpp:1243
   if (RenameEC)
 setDeleteDisposition(H, true);
 #else

If I understand correctly, we're using the delete disposition flag to get the 
OS to clean up the file in case we crash.  But does that prevent us from just 
deleting it outright once we know it's safe to do so?

In other words if we could just delete the file here, then the divergence 
between Win32 and others could possibly be reduced.



Comment at: llvm/lib/Support/Path.cpp:1253
   }
   sys::DontRemoveFileOnSignal(TmpName);
 #endif

Possibly stupid idea:  What if RemoveFileOnSignal and DontRemoveFileOnSignal 
did the Win32-specific delete disposition flag twiddling?  With that 
encapsulated, and assuming we can still explicitly delete a Windows file that's 
already marked for deletion, it seems like all of the special handling here 
could go away.

Then again, the ...OnSignal things are in sys rather than sys::fs, so maybe 
it's not such a good idea.

I'm not trying to make more work for Amy.  The immediate goal probably isn't 
well served by this level of overthinking.  But it would be nice to see all 
this get simpler in the long term.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102736

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

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

2021-05-21 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

This looks like a good start..

All your tests are 3x3 have you considered mixing it up a bit.  i.e. 2x3, what 
is the impact on 1x5 and 5x1 ?

Also how about nested structs, I'm interested to see what happens

  {56, 23, { "ABC", 35 }}
  {57, 24, { "DEF", 36 }}


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101868

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

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

2021-05-21 Thread Gabor Marton via Phabricator via cfe-commits

martong added a comment.

In D102696#2773340 , @vsavchenko 
wrote:

> In D102696#2773304 , @martong wrote:
>
>>> As for the solver, it is something that tormented me for a long time. Is 
>>> there a way to avoid a full-blown brute force check of all existing 
>>> constraints and get some knowledge about symbolic expressions by 
>>> constraints these symbolic expressions are actually part of (right now we 
>>> can reason about expressions if we know some information about its own 
>>> parts aka operands)?
>>
>> Well, it is a hard question.
>> I've been thinking about building a "parent" map for the sub-expressions, 
>> like we do in the AST (see clang::ParentMap). We could use this parent map 
>> to inject new constraints during the "constant folding" mechanism.
>> So, let's say we have `$x + $y = 0` and then when we process `$y = 0` then 
>> we'd add a new constraint: `$x = 0`. We could add this new constraint by 
>> knowing that we have to visit `$x + $y` because `$y` is connected to that in 
>> the parent map.
>> What do you think, could it work?
>
> Yes, this was exactly my line of thinking.  Instead of trying to use hard 
> logic every time we are asked a question, we can try to simplify existing 
> constraints based on the new bit of information.
> The main problem with this is the tree nature of symbolic expressions.  If we 
> have something trivial like `$x + $y` - sure.  But something with lot more 
> nested subexpressions can get tricky really fast.  That can be solved if we 
> have a canonical form for the trees (this will resolve the problem with `$x + 
> $y` versus `$y + $x` as well).  Right now, we have bits of this all around 
> our codebase, but those are more like workarounds as opposed to one general 
> approach.

OK, I have started  working on a constraint manager based prototype 
implementation with a parent map and a hook in `setConstraint`. The test file 
in this patch (even the commutativity test) passes with that, so, it looks 
promising. I hope I can share that next week. Also, I'd like do some 
performance measurements as well, both on this patch and for the new solver 
based one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102696

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

[PATCH] D102742: [IR] make stack-protector-guard-* flags into module attrs

2021-05-21 Thread Nick Desaulniers via Phabricator via cfe-commits

nickdesaulniers updated this revision to Diff 347068.
nickdesaulniers added a comment.

- upgrade module merge strategy to Error


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102742

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/stack-protector-guard.c
  llvm/include/llvm/CodeGen/CommandFlags.h
  llvm/include/llvm/IR/Module.h
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/CommandFlags.cpp
  llvm/lib/CodeGen/StackProtector.cpp
  llvm/lib/IR/Module.cpp
  llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/test/CodeGen/AArch64/stack-guard-sysreg.ll
  llvm/test/CodeGen/X86/stack-protector-3.ll

Index: llvm/test/CodeGen/X86/stack-protector-3.ll
===
--- llvm/test/CodeGen/X86/stack-protector-3.ll
+++ llvm/test/CodeGen/X86/stack-protector-3.ll
@@ -1,10 +1,18 @@
-; RUN: llc -mtriple=x86_64-pc-linux-gnu -o - < %s | FileCheck --check-prefix=CHECK-TLS-FS-40 %s
-; RUN: llc -mtriple=x86_64-pc-linux-gnu -stack-protector-guard=tls -o - < %s | FileCheck --check-prefix=CHECK-TLS-FS-40 %s
-; RUN: llc -mtriple=x86_64-pc-linux-gnu -stack-protector-guard=global -o - < %s | FileCheck --check-prefix=CHECK-GLOBAL %s
-; RUN: llc -mtriple=x86_64-pc-linux-gnu -stack-protector-guard-reg=fs -o - < %s | FileCheck --check-prefix=CHECK-TLS-FS-40 %s
-; RUN: llc -mtriple=x86_64-pc-linux-gnu -stack-protector-guard-reg=gs -o - < %s | FileCheck --check-prefix=CHECK-GS %s
-; RUN: llc -mtriple=x86_64-pc-linux-gnu -stack-protector-guard-offset=20 -o - < %s | FileCheck --check-prefix=CHECK-OFFSET %s
-; RUN: llc -mtriple=x86_64-pc-linux-gnu -stack-protector-guard-offset=-20 -o - < %s | FileCheck --check-prefix=CHECK-NEGATIVE-OFFSET %s
+; RUN: split-file %s %t
+; RUN: cat %t/main.ll %t/a.ll > %t/a2.ll
+; RUN: cat %t/main.ll %t/b.ll > %t/b2.ll
+; RUN: cat %t/main.ll %t/c.ll > %t/c2.ll
+; RUN: cat %t/main.ll %t/d.ll > %t/d2.ll
+; RUN: cat %t/main.ll %t/e.ll > %t/e2.ll
+; RUN: cat %t/main.ll %t/f.ll > %t/f2.ll
+; RUN: cat %t/main.ll %t/g.ll > %t/g2.ll
+; RUN: llc -mtriple=x86_64-pc-linux-gnu -o - < %t/a2.ll | FileCheck --check-prefix=CHECK-TLS-FS-40 %s
+; RUN: llc -mtriple=x86_64-pc-linux-gnu -o - < %t/b2.ll | FileCheck --check-prefix=CHECK-TLS-FS-40 %s
+; RUN: llc -mtriple=x86_64-pc-linux-gnu -o - < %t/c2.ll | FileCheck --check-prefix=CHECK-GLOBAL %s
+; RUN: llc -mtriple=x86_64-pc-linux-gnu -o - < %t/d2.ll | FileCheck --check-prefix=CHECK-TLS-FS-40 %s
+; RUN: llc -mtriple=x86_64-pc-linux-gnu -o - < %t/e2.ll | FileCheck --check-prefix=CHECK-GS %s
+; RUN: llc -mtriple=x86_64-pc-linux-gnu -o - < %t/f2.ll | FileCheck --check-prefix=CHECK-OFFSET %s
+; RUN: llc -mtriple=x86_64-pc-linux-gnu -o - < %t/g2.ll | FileCheck --check-prefix=CHECK-NEGATIVE-OFFSET %s
 
 ; CHECK-TLS-FS-40:   movq%fs:40, %rax
 ; CHECK-TLS-FS-40:   movq%fs:40, %rax
@@ -47,6 +55,8 @@
 ; CHECK-GLOBAL-NEXT:  .cfi_def_cfa_offset 32
 ; CHECK-GLOBAL-NEXT:  callq   __stack_chk_fail
 
+;--- main.ll
+
 ; ModuleID = 't.c'
 @.str = private unnamed_addr constant [14 x i8] c"stackoverflow\00", align 1
 @a = dso_local local_unnamed_addr global i8* null, align 8
@@ -75,3 +85,23 @@
 attributes #0 = { nounwind sspreq uwtable writeonly "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "frame-pointer"="none" "less-precise-fpmad"="false" "min-legal-vector-width"="0" "no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" "unsafe-fp-math"="false" "use-soft-float"="false" }
 attributes #1 = { argmemonly nounwind willreturn }
 attributes #2 = { nounwind }
+
+;--- a.ll
+;--- b.ll
+!llvm.module.flags = !{!1}
+!1 = !{i32 2, !"stack-protector-guard", !"tls"}
+;--- c.ll
+!llvm.module.flags = !{!1}
+!1 = !{i32 2, !"stack-protector-guard", !"global"}
+;--- d.ll
+!llvm.module.flags = !{!1}
+!1 = !{i32 2, !"stack-protector-guard-reg", !"fs"}
+;--- e.ll
+!llvm.module.flags = !{!1}
+!1 = !{i32 2, !"stack-protector-guard-reg", !"gs"}
+;--- f.ll
+!llvm.module.flags = !{!1}
+!1 = !{i32 2, !"stack-protector-guard-offset", i32 20}
+;--- g.ll
+!llvm.module.flags = !{!1}
+!1 = !{i32 2, !"stack-protector-guard-offset", i32 -20}
Index: llvm/test/CodeGen/AArch64/stack-guard-sysreg.ll
===
--- llvm/test/CodeGen/AArch64/stack-guard-sysreg.ll
+++ llvm/test/CodeGen/AArch64/stack-guard-sysreg.ll
@@ -1,46 +1,39 @@
-; RUN: llc %s --stack-protector-guard=sysreg \
-; RUN:   --stack-protector-guard-reg=sp_el0 \
-; RUN:   --stack-protector-guard-offset=0 -verify-machineinstrs -o - | \
+; RUN: split-file %s %t
+; RUN: cat %t/main.ll

[PATCH] D102742: [IR] make stack-protector-guard-* flags into module attrs

2021-05-21 Thread Nick Desaulniers via Phabricator via cfe-commits

nickdesaulniers added a comment.

In D102742#2773954 , @tejohnson wrote:

> In D102742#2767569 , 
> @nickdesaulniers wrote:
>
>> Obviously needs work/cleanup, changes to x86, and tests, but posting for 
>> early feedback about module level attributes vs function level attributes, 
>> or possibly something else.  I tested this quickly with thin LTO of the 
>> Linux kernel and it worked.
>
> I haven't looked through in too much detail, but I see you have the module 
> flag type set as Warning on conflict. I guess the answer to module level vs 
> function level depends on whether it is valid to link together files compiled 
> with different values of these flags and if so what the expected behavior 
> should be. How does this work on non-LTO? If it works just fine, i.e. the 
> functions from the modules with one value are compiled ok with that value and 
> linked with functions compiled effectively with another value, then that 
> would point to a function attribute so you can mimic the mix-and-match 
> behavior. If it is unexpected, then perhaps better to keep as a module flag 
> but Error? With Warning, the value from the first module being linked is used 
> - would that be surprising?

Good point; it won't work as intended on mismatch. Let me upgrade that to Error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102742

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

[PATCH] D91630: [Parse] Add parsing support for C++ attributes on using-declarations

2021-05-21 Thread Louis Dionne via Phabricator via cfe-commits

ldionne updated this revision to Diff 347069.
ldionne marked an inline comment as done.
ldionne added a comment.
Herald added a project: clang.

Rebase onto main and apply Aaron's comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91630

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Parse/Parser.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/Parser/cxx0x-attributes.cpp
  clang/test/SemaCXX/cxx11-attributes-on-using-declaration.cpp

Index: clang/test/SemaCXX/cxx11-attributes-on-using-declaration.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/cxx11-attributes-on-using-declaration.cpp
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -pedantic -triple x86_64-apple-macos11 -std=c++20 -fsyntax-only -verify %s
+
+static_assert(__has_extension(cxx_attributes_on_using_declarations), "");
+
+namespace NS { typedef int x; }
+
+[[clang::annotate("foo")]] using NS::x; // expected-warning{{ISO C++ does not allow an attribute list to appear here}}
+
+
+[[deprecated]] using NS::x; // expected-warning {{'deprecated' currently has no effect on using-declarations}} expected-warning{{ISO C++ does not allow}}
+using NS::x [[deprecated]]; // expected-warning {{'deprecated' currently has no effect on using-declarations}} expected-warning{{ISO C++ does not allow}}
+using NS::x __attribute__((deprecated)); // expected-warning {{'deprecated' currently has no effect on using-declarations}}
+using NS::x __attribute__((availability(macos,introduced=1))); // expected-warning {{'availability' currently has no effect on using-declarations}}
+
+[[clang::availability(macos,introduced=1)]] using NS::x; // expected-warning {{'availability' currently has no effect on using-declarations}} expected-warning{{ISO C++ does not allow}}
+
+// expected-warning@+1 3 {{ISO C++ does not allow an attribute list to appear here}}
+[[clang::annotate("A")]] using NS::x [[clang::annotate("Y")]], NS::x [[clang::annotate("Z")]];
+
+template 
+struct S : T {
+  [[deprecated]] using typename T::x; // expected-warning{{ISO C++ does not allow}} expected-warning {{'deprecated' currently has no effect on using-declarations}}
+  [[deprecated]] using T::y; // expected-warning{{ISO C++ does not allow}} expected-warning {{'deprecated' currently has no effect on using-declarations}}
+
+  using typename T::z [[deprecated]]; // expected-warning{{ISO C++ does not allow}} expected-warning {{'deprecated' currently has no effect on using-declarations}}
+  using T::a [[deprecated]]; // expected-warning{{ISO C++ does not allow}} expected-warning {{'deprecated' currently has no effect on using-declarations}}
+};
+
+struct Base {};
+
+template 
+struct DepBase1 : B {
+  using B::B [[]];
+
+};
+template 
+struct DepBase2 : B {
+  using B::B __attribute__(());
+};
+
+DepBase1 db1;
+DepBase2 db2;
Index: clang/test/Parser/cxx0x-attributes.cpp
===
--- clang/test/Parser/cxx0x-attributes.cpp
+++ clang/test/Parser/cxx0x-attributes.cpp
@@ -131,12 +131,12 @@
 [[]] static_assert(true, ""); //expected-error {{an attribute list cannot appear here}}
 [[]] asm(""); // expected-error {{an attribute list cannot appear here}}
 
-[[]] using ns::i; // expected-error {{an attribute list cannot appear here}}
+[[]] using ns::i;
 [[unknown]] using namespace ns; // expected-warning {{unknown attribute 'unknown' ignored}}
 [[noreturn]] using namespace ns; // expected-error {{'noreturn' attribute only applies to functions}}
 namespace [[]] ns2 {} // expected-warning {{attributes on a namespace declaration are a C++17 extension}}
 
-using [[]] alignas(4) [[]] ns::i; // expected-error {{an attribute list cannot appear here}}
+using [[]] alignas(4) [[]] ns::i; // expected-error {{an attribute list cannot appear here}} expected-error {{'alignas' attribute only applies to variables, data members and tag types}} expected-warning {{ISO C++}}
 using [[]] alignas(4) [[]] foobar = int; // expected-error {{an attribute list cannot appear here}} expected-error {{'alignas' attribute only applies to}}
 
 void bad_attributes_in_do_while() {
@@ -157,7 +157,16 @@
 [[]] using T = int; // expected-error {{an attribute list cannot appear here}}
 using T [[]] = int; // ok
 template using U [[]] = T;
-using ns::i [[]]; // expected-error {{an attribute list cannot appear here}}
+using ns::i [[]];
+using ns::i [[]], ns::i [[]]; // expected-warning {{use of multiple declarators in a single using declaration is a C++17 extension}}
+struct using_in_struct_base {
+  typedef int i, j, k, l;
+};
+struct using_in_struct : using_in_struct_base {
+

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

2021-05-21 Thread Wei Wang via Phabricator via cfe-commits

weiwang added a comment.

In D101793#2772717 , @yaxunl wrote:

> In D101793#2772461 , @weiwang wrote:
>
>> Thanks for the approval!
>>
>> Just want to understand the list of "decls to check for deferred 
>> diagnostics" better, where are these decls coming from? And why do they need 
>> to be checked for warnings? I see decls from libc are in the list, but I 
>> have no idea why are they selected.
>
> For offloading languages e.g. OpenMP/CUDA/HIP, there are apparent errors in 
> functions shared between host and device. However, unless these functions are 
> sure to be emitted on device or host, these errors should not be emitted. 
> These errors are so called deferred error messages. The function decls which 
> need to be checked are recorded. After AST is finalized, the AST of these 
> functions are iterated. If a function is found sure to be emitted, the 
> deferred error message in it are emitted.

Thanks! So the `DeclsToCheckForDeferredDiags` contains the candidate decls to 
be checked. The decls are selected because they would generate diags in the 
context of offloading languages, but whether or not an diag will be emitted is 
deferred till traversal of the AST is performed. I still don't quite understand 
why would libc functions be in the candidate list? They look simple enough (and 
I think they've been there forever).  For example `__uint16_identity` 
(https://code.woboq.org/userspace/glibc/bits/uintn-identity.h.html#32),

  static inline __uint16_t __uint16_identity(__uint16_t __x) {
  return __x;
  }

I don't see how this function would generate diag either on host or device.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101793

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

[PATCH] D102863: [analyzer] RetainCountChecker: Disable tracking for references to OSMetaClass.

2021-05-21 Thread Georgeta Igna via Phabricator via cfe-commits

georgi_igna updated this revision to Diff 347070.

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

https://reviews.llvm.org/D102863

Files:
  clang/lib/Analysis/RetainSummaryManager.cpp
  clang/test/Analysis/os_object_base.h
  clang/test/Analysis/osobject-retain-release.cpp


Index: clang/test/Analysis/osobject-retain-release.cpp
===
--- clang/test/Analysis/osobject-retain-release.cpp
+++ clang/test/Analysis/osobject-retain-release.cpp
@@ -721,6 +721,16 @@
obj->release();
  }
  
++void test_osmetaclass_release(){
++  const char *name = "no_name";
++  const OSMetaClass *meta = OSMetaClass::copyMetaClassWithName(name);
++  if (!meta) {
++return;
++  } else {
++meta->releaseMetaClass();
++  }
++}
++
  class SampleClass {
  public:
OSObjectPtr field;
Index: clang/test/Analysis/os_object_base.h
===
--- clang/test/Analysis/os_object_base.h
+++ clang/test/Analysis/os_object_base.h
@@ -68,6 +68,8 @@
  struct OSMetaClass : public OSMetaClassBase {
virtual OSObject * alloc() const;
static OSObject * allocClassWithName(const char * name);
++  static const OSMetaClass * copyMetaClassWithName(const char * name);
++  void releaseMetaClass() const;
virtual ~OSMetaClass(){}
  };
  
Index: clang/lib/Analysis/RetainSummaryManager.cpp
===
--- clang/lib/Analysis/RetainSummaryManager.cpp
+++ clang/lib/Analysis/RetainSummaryManager.cpp
@@ -146,8 +146,15 @@
return !(match(SubclassM, *D, D->getASTContext()).empty());
  }
  
++static bool isExactClass(const Decl *D, StringRef ClassName) {
++  using namespace ast_matchers;
++  DeclarationMatcher sameClassM =
++  cxxRecordDecl(hasName(std::string(ClassName)));
++  return !(match(sameClassM, *D, D->getASTContext()).empty());
++}
++
  static bool isOSObjectSubclass(const Decl *D) {
--  return D && isSubclass(D, "OSMetaClassBase");
++  return D && isSubclass(D, "OSMetaClassBase") && !isExactClass(D, 
"OSMetaClass");
  }
  
  static bool isOSObjectDynamicCast(StringRef S) {


Index: clang/test/Analysis/osobject-retain-release.cpp
===
--- clang/test/Analysis/osobject-retain-release.cpp
+++ clang/test/Analysis/osobject-retain-release.cpp
@@ -721,6 +721,16 @@
obj->release();
  }
  
++void test_osmetaclass_release(){
++  const char *name = "no_name";
++  const OSMetaClass *meta = OSMetaClass::copyMetaClassWithName(name);
++  if (!meta) {
++return;
++  } else {
++meta->releaseMetaClass();
++  }
++}
++
  class SampleClass {
  public:
OSObjectPtr field;
Index: clang/test/Analysis/os_object_base.h
===
--- clang/test/Analysis/os_object_base.h
+++ clang/test/Analysis/os_object_base.h
@@ -68,6 +68,8 @@
  struct OSMetaClass : public OSMetaClassBase {
virtual OSObject * alloc() const;
static OSObject * allocClassWithName(const char * name);
++  static const OSMetaClass * copyMetaClassWithName(const char * name);
++  void releaseMetaClass() const;
virtual ~OSMetaClass(){}
  };
  
Index: clang/lib/Analysis/RetainSummaryManager.cpp
===
--- clang/lib/Analysis/RetainSummaryManager.cpp
+++ clang/lib/Analysis/RetainSummaryManager.cpp
@@ -146,8 +146,15 @@
return !(match(SubclassM, *D, D->getASTContext()).empty());
  }
  
++static bool isExactClass(const Decl *D, StringRef ClassName) {
++  using namespace ast_matchers;
++  DeclarationMatcher sameClassM =
++  cxxRecordDecl(hasName(std::string(ClassName)));
++  return !(match(sameClassM, *D, D->getASTContext()).empty());
++}
++
  static bool isOSObjectSubclass(const Decl *D) {
--  return D && isSubclass(D, "OSMetaClassBase");
++  return D && isSubclass(D, "OSMetaClassBase") && !isExactClass(D, "OSMetaClass");
  }
  
  static bool isOSObjectDynamicCast(StringRef S) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102782: Add support for Warning Flag "-Wstack-usage="

2021-05-21 Thread Ryan Santhirarajan via Phabricator via cfe-commits

rsanthir.quic added a comment.

Thanks for reviewing @bruno doesn't look like the failure is related to my 
change:
https://buildkite.com/llvm-project/premerge-checks/builds/39905#5f70c261-ae54-451b-b771-7012bcee7387
"No space left on device"

Unless I am looking at the wrong thing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102782

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

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

2021-05-21 Thread Balázs Benics via Phabricator via cfe-commits

steakhal added a comment.

I think It would be also beneficial to document the semantics. Whenever we say 
`$x + $y` it's not entirely clear whether we talk about the addition operation 
in a mathematical sense or we follow C/C++ language semantics. Right now it's 
mostly mixed within the analyzer. It would be really nice to see for example 
how and when wrapping is considered.
What if the types of the operands don't match in bitwidth or signess. This is 
sort of the reason why `ArrayBoundV2` has false positives in some scenarios.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102696

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

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

2021-05-21 Thread Fred Grim via Phabricator via cfe-commits

feg208 added a comment.

In D101868#2774152 , @MyDeveloperDay 
wrote:

> This looks like a good start..

Thanks. I am reworking it so I handle line breaking in a sane fashion and 
dropping the LineFormatter override since that really can't handle reformatting 
without reimplementing most of it

> All your tests are 3x3 have you considered mixing it up a bit.  i.e. 2x3, 
> what is the impact on 1x5 and 5x1 ?

I am also adding a bunch more tests. I'll roll this in.

> Also how about nested structs, I'm interested to see what happens
>
>   {56, 23, { "ABC", 35 }}
>   {57, 24, { "DEF", 36 }}

Will do. I added the braced initializer int constructor test to exercise the 
same code path. But it can't hurt to get this in there

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101868

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

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

2021-05-21 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added a comment.

This is a valiant effort, and I definitely don't want to discourage..especially 
as you shown a good understand of clang-format. Its been a long asked for 
feature.. but we should really ensure this covers the bulk of the complaints if 
possible..

For me I use this.. a search for `clang-format off` in github projects

https://github.com/search?q=clang-format+off

  Status AbsGrad(const AttrSlice& attrs, FunctionDef* g) {
// clang-format off
return GradForUnaryCwise(g, {
{{"sign"}, "Sign", {"x"}, {}, {"dy"}},
{{"dx"}, "Mul", {"dy", "sign"}},
});
// clang-format on
  }

https://github.com/lulzsec2012/tensorflow/blob/d68d869e397515655e9f41570f4db463df770563/tensorflow/core/ops/math_grad.cc

it would be my ideal if we could irradiate the need for these, as they heavily 
dominate.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101868

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

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

2021-05-21 Thread MyDeveloperDay via Phabricator via cfe-commits

MyDeveloperDay added inline comments.



Comment at: clang/unittests/Format/FormatTest.cpp:16389
+  for (const auto &Style : Styles) {
+verifyFormat("struct test demo[] = {\n"
+ "{56, 23,\"hello\" },\n"

may be worth testing a case with comments at the end of each line

```
verifyFormat("struct test demo[3] = {\n"
 "{56, 23,\"hello\" }, // first line\n"
 "{-1, 93463, \"world\" }, /* second line */\n"
 "{7,  5, \"!!\"} // at the end\n"
 "};\n",
 Style);
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101868

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

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

2021-05-21 Thread Valeriy Savchenko via Phabricator via cfe-commits

vsavchenko added a comment.

In D102696#2774169 , @martong wrote:

> In D102696#2773340 , @vsavchenko 
> wrote:
>
>> In D102696#2773304 , @martong 
>> wrote:
>>
 As for the solver, it is something that tormented me for a long time. Is 
 there a way to avoid a full-blown brute force check of all existing 
 constraints and get some knowledge about symbolic expressions by 
 constraints these symbolic expressions are actually part of (right now we 
 can reason about expressions if we know some information about its own 
 parts aka operands)?
>>>
>>> Well, it is a hard question.
>>> I've been thinking about building a "parent" map for the sub-expressions, 
>>> like we do in the AST (see clang::ParentMap). We could use this parent map 
>>> to inject new constraints during the "constant folding" mechanism.
>>> So, let's say we have `$x + $y = 0` and then when we process `$y = 0` then 
>>> we'd add a new constraint: `$x = 0`. We could add this new constraint by 
>>> knowing that we have to visit `$x + $y` because `$y` is connected to that 
>>> in the parent map.
>>> What do you think, could it work?
>>
>> Yes, this was exactly my line of thinking.  Instead of trying to use hard 
>> logic every time we are asked a question, we can try to simplify existing 
>> constraints based on the new bit of information.
>> The main problem with this is the tree nature of symbolic expressions.  If 
>> we have something trivial like `$x + $y` - sure.  But something with lot 
>> more nested subexpressions can get tricky really fast.  That can be solved 
>> if we have a canonical form for the trees (this will resolve the problem 
>> with `$x + $y` versus `$y + $x` as well).  Right now, we have bits of this 
>> all around our codebase, but those are more like workarounds as opposed to 
>> one general approach.
>
> OK, I have started  working on a constraint manager based prototype 
> implementation with a parent map and a hook in `setConstraint`. The test file 
> in this patch (even the commutativity test) passes with that, so, it looks 
> promising. I hope I can share that next week. Also, I'd like do some 
> performance measurements as well, both on this patch and for the new solver 
> based one.

Parent map is more or less trivial for situations like `$x + $y`, where we 
simply relate `$x` and `$y`. But what should we do for a more general case when 
`$x` and `$y` are expressions themselves. One simple example here is `$a +$b 
+$c` as originally constrained and `$a + $c` that got constrained later on.  
Should we include `$a`, `$b`, $c`, `$a + $b`, `$a + $c`, and `$b + $c` to the 
parent map to make it work?

And again even with parent map, we still need canonicalization.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102696

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

[PATCH] D102936: [CUDA] Work around compatibility issue with libstdc++ 11.1.0

2021-05-21 Thread Artem Belevich via Phabricator via cfe-commits

tra created this revision.
tra added reviewers: jlebar, jwakely.
Herald added subscribers: bixia, yaxunl.
tra requested review of this revision.
Herald added a project: clang.

libstdc++ 11.1.0 redeclares __failed_assertion multiple times and that results 
in the
function declared with conflicting set of attributes when we include 
with __host__ __device__ attributes force-applied to all functions.

In order to work around the issue, we rename __failed_assertion within the
region with forced attributes.

See https://bugs.llvm.org/show_bug.cgi?id=50383 for the details.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102936

Files:
  clang/lib/Headers/cuda_wrappers/complex


Index: clang/lib/Headers/cuda_wrappers/complex
===
--- clang/lib/Headers/cuda_wrappers/complex
+++ clang/lib/Headers/cuda_wrappers/complex
@@ -72,8 +72,16 @@
 #define _GLIBCXX_USE_C99_COMPLEX 0
 #define _GLIBCXX_USE_C99_COMPLEX_TR1 0
 
+// Work around a compatibility issue with libstdc++ 11.1.0
+// https://bugs.llvm.org/show_bug.cgi?id=50383
+#pragma push_macro("__failed_assert")
+#if _GLIBCXX_RELEASE == 11 && __GLIBCXX__ == 20210427
+#define __failed_assertion __cuda_failed_assertion
+#endif
+
 #include_next 
 
+#pragma pop_macro("__failed_assert")
 #pragma pop_macro("_GLIBCXX_USE_C99_COMPLEX_TR1")
 #pragma pop_macro("_GLIBCXX_USE_C99_COMPLEX")
 


Index: clang/lib/Headers/cuda_wrappers/complex
===
--- clang/lib/Headers/cuda_wrappers/complex
+++ clang/lib/Headers/cuda_wrappers/complex
@@ -72,8 +72,16 @@
 #define _GLIBCXX_USE_C99_COMPLEX 0
 #define _GLIBCXX_USE_C99_COMPLEX_TR1 0
 
+// Work around a compatibility issue with libstdc++ 11.1.0
+// https://bugs.llvm.org/show_bug.cgi?id=50383
+#pragma push_macro("__failed_assert")
+#if _GLIBCXX_RELEASE == 11 && __GLIBCXX__ == 20210427
+#define __failed_assertion __cuda_failed_assertion
+#endif
+
 #include_next 
 
+#pragma pop_macro("__failed_assert")
 #pragma pop_macro("_GLIBCXX_USE_C99_COMPLEX_TR1")
 #pragma pop_macro("_GLIBCXX_USE_C99_COMPLEX")
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102936: [CUDA] Work around compatibility issue with libstdc++ 11.1.0

2021-05-21 Thread Joachim Meyer via Phabricator via cfe-commits

fodinabor added a comment.

Sadly don't have stdibc++11 available locally as well.. so can't verify, but 
looks good to me except for the push and pop macros.




Comment at: clang/lib/Headers/cuda_wrappers/complex:77
+// https://bugs.llvm.org/show_bug.cgi?id=50383
+#pragma push_macro("__failed_assert")
+#if _GLIBCXX_RELEASE == 11 && __GLIBCXX__ == 20210427

Not sure I understand what the push of `__failed_assert` is for..? can't find 
any reference to `__failed_assert` anywhere... did you mean to write 
`__failed_assertion`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102936

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

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

2021-05-21 Thread Amy Huang via Phabricator via cfe-commits

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

In D102736#2767432 , @aganea wrote:

> Do you think the existing crash tests can be modified to validate that .tmp 
> files are deleted indeed?

Looks like the existing crash tests use `#pragma clang __debug crash` but in 
the case where clang crashes it's actually fine. I guess the only cases where 
this patch actually applies is when the program is killed -- don't know if 
there's a good way to do that in the test suite?




Comment at: clang/lib/Frontend/CompilerInstance.cpp:733
+} else {
+  if (std::error_code EC =
+  llvm::sys::fs::rename(OF.TempFilename, NewOutFile))

aganea wrote:
> Here you can probably use `ECError` or `errorCodeToError()` with what is said 
> slightly above.
I think this path goes away if we always use TempFile



Comment at: clang/lib/Frontend/CompilerInstance.cpp:840
 int fd;
-std::error_code EC = llvm::sys::fs::createUniqueFile(
-TempPath, fd, TempPath,
-Binary ? llvm::sys::fs::OF_None : llvm::sys::fs::OF_Text);
+#if _WIN32
+// On Windows, use llvm::sys::fs::TempFile to write the output file so

aganea wrote:
> Usually it is better to avoid platform-specific logic. Could we use 
> `TempFile` all the time on all platforms?
Hm, probably, that would make things simpler. 



Comment at: llvm/lib/Support/Path.cpp:1253
   }
   sys::DontRemoveFileOnSignal(TmpName);
 #endif

amccarth wrote:
> Possibly stupid idea:  What if RemoveFileOnSignal and DontRemoveFileOnSignal 
> did the Win32-specific delete disposition flag twiddling?  With that 
> encapsulated, and assuming we can still explicitly delete a Windows file 
> that's already marked for deletion, it seems like all of the special handling 
> here could go away.
> 
> Then again, the ...OnSignal things are in sys rather than sys::fs, so maybe 
> it's not such a good idea.
> 
> I'm not trying to make more work for Amy.  The immediate goal probably isn't 
> well served by this level of overthinking.  But it would be nice to see all 
> this get simpler in the long term.
@rnk suggested that too - I think it would definitely make things nicer, but 
yeah, the fact that it's in sys and not sys::fs is inconvenient.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102736

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

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

2021-05-21 Thread Amy Huang via Phabricator via cfe-commits

akhuang updated this revision to Diff 347090.
akhuang marked an inline comment as done.
akhuang added a comment.

Use TempFile on both linux and windows


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102736

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

Index: llvm/lib/Support/Windows/Path.inc
===
--- llvm/lib/Support/Windows/Path.inc
+++ llvm/lib/Support/Windows/Path.inc
@@ -560,11 +560,6 @@
   return errc::permission_denied;
 }
 
-static std::error_code rename_fd(int FromFD, const Twine &To) {
-  HANDLE FromHandle = reinterpret_cast(_get_osfhandle(FromFD));
-  return rename_handle(FromHandle, To);
-}
-
 std::error_code rename(const Twine &From, const Twine &To) {
   // Convert to utf-16.
   SmallVector WideFrom;
Index: llvm/lib/Support/Path.cpp
===
--- llvm/lib/Support/Path.cpp
+++ llvm/lib/Support/Path.cpp
@@ -1229,7 +1229,7 @@
   auto H = reinterpret_cast(_get_osfhandle(FD));
   std::error_code RenameEC = setDeleteDisposition(H, false);
   if (!RenameEC) {
-RenameEC = rename_fd(FD, Name);
+RenameEC = rename_handle(H, Name);
 // If rename failed because it's cross-device, copy instead
 if (RenameEC ==
   std::error_code(ERROR_NOT_SAME_DEVICE, std::system_category())) {
@@ -1261,7 +1261,6 @@
 return errorCodeToError(EC);
   }
   FD = -1;
-
   return errorCodeToError(RenameEC);
 }
 
Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -704,29 +704,38 @@
 void CompilerInstance::clearOutputFiles(bool EraseFiles) {
   for (OutputFile &OF : OutputFiles) {
 if (EraseFiles) {
-  if (!OF.TempFilename.empty()) {
-llvm::sys::fs::remove(OF.TempFilename);
-continue;
+  if (OF.TempFile) {
+if (llvm::Error E = OF.TempFile->discard())
+  consumeError(std::move(E));
   }
   if (!OF.Filename.empty())
 llvm::sys::fs::remove(OF.Filename);
   continue;
 }
 
-if (OF.TempFilename.empty())
+if (!OF.TempFile)
+  continue;
+
+if (OF.TempFile->TmpName.empty()) {
+  if (llvm::Error E = OF.TempFile->discard())
+consumeError(std::move(E));
   continue;
+}
 
 // If '-working-directory' was passed, the output filename should be
 // relative to that.
 SmallString<128> NewOutFile(OF.Filename);
 FileMgr->FixupRelativePath(NewOutFile);
-std::error_code EC = llvm::sys::fs::rename(OF.TempFilename, NewOutFile);
-if (!EC)
+
+std::string ErrorMsg;
+llvm::Error E = OF.TempFile->keep(NewOutFile);
+if (!E)
   continue;
+
 getDiagnostics().Report(diag::err_unable_to_rename_temp)
-<< OF.TempFilename << OF.Filename << EC.message();
+<< OF.TempFile->TmpName << OF.Filename << toString(std::move(E));
 
-llvm::sys::fs::remove(OF.TempFilename);
+llvm::sys::fs::remove(OF.TempFile->TmpName);
   }
   OutputFiles.clear();
   if (DeleteBuiltModules) {
@@ -808,7 +817,7 @@
 }
   }
 
-  std::string TempFile;
+  Optional Temp;
   if (UseTemporary) {
 // Create a temporary file.
 // Insert - before the extension (if any), and because some tools
@@ -820,25 +829,36 @@
 TempPath += "-";
 TempPath += OutputExtension;
 TempPath += ".tmp";
-int fd;
-std::error_code EC = llvm::sys::fs::createUniqueFile(
-TempPath, fd, TempPath,
-Binary ? llvm::sys::fs::OF_None : llvm::sys::fs::OF_Text);
-
-if (CreateMissingDirectories &&
-EC == llvm::errc::no_such_file_or_directory) {
-  StringRef Parent = llvm::sys::path::parent_path(OutputPath);
-  EC = llvm::sys::fs::create_directories(Parent);
-  if (!EC) {
-EC = llvm::sys::fs::createUniqueFile(TempPath, fd, TempPath,
- Binary ? llvm::sys::fs::OF_None
-: llvm::sys::fs::OF_Text);
-  }
-}
+Expected ExpectedFile =
+llvm::sys::fs::TempFile::create(TempPath);
+
+llvm::Error E = handleErrors(
+ExpectedFile.takeError(), [&](const llvm::ECError &E) -> llvm::Error {
+  std::error_code EC = E.convertToErrorCode();
+  if (CreateMissingDirectories &&
+  EC == llvm::errc::no_such_file_or_directory) {
+StringRef Parent = llvm::sys::path::parent_path(OutputPath);
+EC = llvm::sys::fs::create_directories(Parent);
+if (!EC) {
+  ExpectedFile = llvm::sys::fs::TempFile::create(TempPath);
+  if (!ExpectedFile)
+return llvm::errorCodeToError(
+l

[PATCH] D97183: [analyzer] Add NoteTag for smart-ptr get()

2021-05-21 Thread Deep Majumder via Phabricator via cfe-commits

RedDocMD added a comment.

Right, @teemperor, I will do the refactors once we figure out how to utilize 
`trackExpressionValue()` here (because that will eliminate quite a bit of code 
from `GetNoteVisitor`, so no point in refactoring those bits).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97183

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

[PATCH] D102936: [CUDA] Work around compatibility issue with libstdc++ 11.1.0

2021-05-21 Thread Artem Belevich via Phabricator via cfe-commits

tra added inline comments.



Comment at: clang/lib/Headers/cuda_wrappers/complex:77
+// https://bugs.llvm.org/show_bug.cgi?id=50383
+#pragma push_macro("__failed_assert")
+#if _GLIBCXX_RELEASE == 11 && __GLIBCXX__ == 20210427

fodinabor wrote:
> Not sure I understand what the push of `__failed_assert` is for..? can't find 
> any reference to `__failed_assert` anywhere... did you mean to write 
> `__failed_assertion`?
It's a precaution -- we have no control over what may or may not be defined 
outside of this header.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102936

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

[PATCH] D102936: [CUDA] Work around compatibility issue with libstdc++ 11.1.0

2021-05-21 Thread Artem Belevich via Phabricator via cfe-commits

tra updated this revision to Diff 347092.
tra edited the summary of this revision.
tra added a comment.

Fixed typo in push/pop macro name.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102936

Files:
  clang/lib/Headers/cuda_wrappers/complex


Index: clang/lib/Headers/cuda_wrappers/complex
===
--- clang/lib/Headers/cuda_wrappers/complex
+++ clang/lib/Headers/cuda_wrappers/complex
@@ -72,8 +72,16 @@
 #define _GLIBCXX_USE_C99_COMPLEX 0
 #define _GLIBCXX_USE_C99_COMPLEX_TR1 0
 
+// Work around a compatibility issue with libstdc++ 11.1.0
+// https://bugs.llvm.org/show_bug.cgi?id=50383
+#pragma push_macro("__failed_assertion")
+#if _GLIBCXX_RELEASE == 11 && __GLIBCXX__ == 20210427
+#define __failed_assertion __cuda_failed_assertion
+#endif
+
 #include_next 
 
+#pragma pop_macro("__failed_assertion")
 #pragma pop_macro("_GLIBCXX_USE_C99_COMPLEX_TR1")
 #pragma pop_macro("_GLIBCXX_USE_C99_COMPLEX")
 


Index: clang/lib/Headers/cuda_wrappers/complex
===
--- clang/lib/Headers/cuda_wrappers/complex
+++ clang/lib/Headers/cuda_wrappers/complex
@@ -72,8 +72,16 @@
 #define _GLIBCXX_USE_C99_COMPLEX 0
 #define _GLIBCXX_USE_C99_COMPLEX_TR1 0
 
+// Work around a compatibility issue with libstdc++ 11.1.0
+// https://bugs.llvm.org/show_bug.cgi?id=50383
+#pragma push_macro("__failed_assertion")
+#if _GLIBCXX_RELEASE == 11 && __GLIBCXX__ == 20210427
+#define __failed_assertion __cuda_failed_assertion
+#endif
+
 #include_next 
 
+#pragma pop_macro("__failed_assertion")
 #pragma pop_macro("_GLIBCXX_USE_C99_COMPLEX_TR1")
 #pragma pop_macro("_GLIBCXX_USE_C99_COMPLEX")
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102936: [CUDA] Work around compatibility issue with libstdc++ 11.1.0

2021-05-21 Thread Artem Belevich via Phabricator via cfe-commits

tra added inline comments.



Comment at: clang/lib/Headers/cuda_wrappers/complex:77
+// https://bugs.llvm.org/show_bug.cgi?id=50383
+#pragma push_macro("__failed_assert")
+#if _GLIBCXX_RELEASE == 11 && __GLIBCXX__ == 20210427

tra wrote:
> fodinabor wrote:
> > Not sure I understand what the push of `__failed_assert` is for..? can't 
> > find any reference to `__failed_assert` anywhere... did you mean to write 
> > `__failed_assertion`?
> It's a precaution -- we have no control over what may or may not be defined 
> outside of this header.
> 
That, and I've made a typo. Fixed now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102936

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

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

2021-05-21 Thread Joseph Huber via Phabricator via cfe-commits

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

Fixing nits and splitting command line removal to a new patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97680

Files:
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.h
  clang/test/OpenMP/assumes_include_nvptx.cpp
  clang/test/OpenMP/declare_target_codegen_globalization.cpp
  clang/test/OpenMP/nvptx_data_sharing.cpp
  clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/nvptx_multi_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_nested_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_for_codegen.cpp
  clang/test/OpenMP/nvptx_target_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_proc_bind_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen_tbaa_PR46146.cpp
  clang/test/OpenMP/nvptx_target_teams_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/nvptx_teams_codegen.cpp
  clang/test/OpenMP/nvptx_teams_reduction_codegen.cpp
  clang/test/OpenMP/target_parallel_debug_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
  llvm/lib/Transforms/IPO/OpenMPOpt.cpp
  llvm/test/Transforms/OpenMP/globalization_remarks.ll
  llvm/test/Transforms/PhaseOrdering/openmp-opt-module.ll

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

[PATCH] D102940: [OpenMP] Remove OpenMP CUDA Target Parallel compiler flag

2021-05-21 Thread Joseph Huber via Phabricator via cfe-commits

jhuber6 created this revision.
jhuber6 added reviewers: jdoerfert, tianshilei1992.
jhuber6 added a project: clang.
Herald added subscribers: dexonsmith, dang, guansong, yaxunl.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.

The changes introduced in D97680  turns this 
command line option into a no-op so
it can be removed entirely.

Depends on D97680 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D102940

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3475,9 +3475,6 @@
   if (Opts.OpenMPCUDAMode)
 GenerateArg(Args, OPT_fopenmp_cuda_mode, SA);
 
-  if (Opts.OpenMPCUDATargetParallel)
-GenerateArg(Args, OPT_fopenmp_cuda_parallel_target_regions, SA);
-
   if (Opts.OpenMPCUDAForceFullRuntime)
 GenerateArg(Args, OPT_fopenmp_cuda_force_full_runtime, SA);
 
@@ -3905,12 +3902,6 @@
   Opts.OpenMPCUDAMode = Opts.OpenMPIsDevice && (T.isNVPTX() || T.isAMDGCN()) &&
 Args.hasArg(options::OPT_fopenmp_cuda_mode);
 
-  // Set CUDA support for parallel execution of target regions for OpenMP 
target
-  // NVPTX/AMDGCN if specified in options.
-  Opts.OpenMPCUDATargetParallel =
-  Opts.OpenMPIsDevice && (T.isNVPTX() || T.isAMDGCN()) &&
-  Args.hasArg(options::OPT_fopenmp_cuda_parallel_target_regions);
-
   // Set CUDA mode for OpenMP target NVPTX/AMDGCN if specified in options
   Opts.OpenMPCUDAForceFullRuntime =
   Opts.OpenMPIsDevice && (T.isNVPTX() || T.isAMDGCN()) &&
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5673,13 +5673,6 @@
options::OPT_fno_openmp_cuda_mode, /*Default=*/false))
 CmdArgs.push_back("-fopenmp-cuda-mode");
 
-  // When in OpenMP offloading mode with NVPTX target, forward
-  // cuda-parallel-target-regions flag
-  if (Args.hasFlag(options::OPT_fopenmp_cuda_parallel_target_regions,
-   options::OPT_fno_openmp_cuda_parallel_target_regions,
-   /*Default=*/true))
-CmdArgs.push_back("-fopenmp-cuda-parallel-target-regions");
-
   // When in OpenMP offloading mode with NVPTX target, check if full 
runtime
   // is required.
   if (Args.hasFlag(options::OPT_fopenmp_cuda_force_full_runtime,
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2340,12 +2340,6 @@
 defm openmp_optimistic_collapse : BoolFOption<"openmp-optimistic-collapse",
   LangOpts<"OpenMPOptimisticCollapse">, DefaultFalse,
   PosFlag, NegFlag, 
BothFlags<[NoArgumentUnused, HelpHidden]>>;
-def fopenmp_cuda_parallel_target_regions : Flag<["-"], 
"fopenmp-cuda-parallel-target-regions">, Group,
-  Flags<[CC1Option, NoArgumentUnused, HelpHidden]>,
-  HelpText<"Support parallel execution of target regions on Cuda-based 
devices.">;
-def fno_openmp_cuda_parallel_target_regions : Flag<["-"], 
"fno-openmp-cuda-parallel-target-regions">, Group,
-  Flags<[NoArgumentUnused, HelpHidden]>,
-  HelpText<"Support only serial execution of target regions on Cuda-based 
devices.">;
 def static_openmp: Flag<["-"], "static-openmp">,
   HelpText<"Use the static host OpenMP runtime while linking.">;
 def fno_optimize_sibling_calls : Flag<["-"], "fno-optimize-sibling-calls">, 
Group;
Index: clang/include/clang/Basic/LangOptions.def
===
--- clang/include/clang/Basic/LangOptions.def
+++ clang/include/clang/Basic/LangOptions.def
@@ -237,7 +237,6 @@
 LANGOPT(OpenMPCUDABlocksPerSM  , 32, 0, "Number of blocks per SM for CUDA 
devices.")
 LANGOPT(OpenMPCUDAReductionBufNum , 32, 1024, "Number of the reduction records 
in the intermediate reduction buffer used for the teams reductions.")
 LANGOPT(OpenMPOptimisticCollapse  , 1, 0, "Use at most 32 bits to represent 
the collapsed loop nest counter.")
-LANGOPT(OpenMPCUDATargetParallel, 1, 0, "Support parallel execution of target 
region on Cuda-based devices.")
 LANGOPT(RenderScript  , 1, 0, "RenderScript")
 
 LANGOPT(CUDAIsDevice  , 1, 0, "compiling for CUDA device")


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3475,9 +3475,6 @@
   if (Opts.OpenMPCUDAMode)
 GenerateArg(Args, O

[PATCH] D102936: [CUDA] Work around compatibility issue with libstdc++ 11.1.0

2021-05-21 Thread Joachim Meyer via Phabricator via cfe-commits

fodinabor accepted this revision.
fodinabor added a comment.

LGTM :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102936

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

1 2 >

1 - 100 of 146 matches

Mail list logo