date:20220428

[PATCH] D124540: [clang][dataflow] Perform structural comparison of indirection values in `join`.

2022-04-28 Thread Stanislav Gatev via Phabricator via cfe-commits

sgatev accepted this revision.
sgatev added inline comments.



Comment at: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp:357-365
+// FIXME: add unit tests that cover this statement.
+if (auto *IndVal1 = dyn_cast(Val)) {
+  auto *IndVal2 = cast(It->second);
+  assert(IndVal1->getKind() == IndVal2->getKind());
+  if (&IndVal1->getPointeeLoc() == &IndVal2->getPointeeLoc()) {
+JoinedEnv.LocToVal.insert({Loc, Val});
+continue;

Let's add merging of distinct indirection values to `mergeDistinctValues` where 
we already have code for merging distinct boolean values.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124540

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

[PATCH] D117112: [AArch64] Support for Ampere1 core

2022-04-28 Thread Dave Green via Phabricator via cfe-commits

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

I don't know the details of the scheduling latencies for the core, but this 
looks perfectly sensible. There are a few comments inline, but other than those 
this patch LGTM.




Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:296
+ (AArch64::AEK_FP16 | AArch64::AEK_MTE | AArch64::AEK_SB |
+ AArch64::AEK_SSBS))
 // Invalid CPU

The formatting is a bit off here.



Comment at: llvm/lib/Target/AArch64/AArch64.td:1082
FeatureFullFP16, FeatureFP16FML, 
FeatureDotProd];
+  list Ampere1 = [HasV8_6aOps, FeatureNEON, FeaturePerfMon];
 

Should this include SSBS and MTE too, if they are included in the target 
parsing?



Comment at: llvm/lib/Target/AArch64/AArch64Subtarget.h:83
+TSV110,
+Ampere1
   };

dmgreen wrote:
> This list can be alphabetical.
This still needs to be alphabetical


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117112

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

[PATCH] D124570: Revert "[analyzer][NFC] Refactor GenericTaintChecker to use CallDescriptionMap"

2022-04-28 Thread Balázs Benics via Phabricator via cfe-commits

steakhal added a comment.

I'm not comfortable with reverting this.
We depend on taint capabilities downstream, thus we would rather help fixing 
the underlying issue.
Do you have a reproducer for the crash in any form? I would take it from there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124570

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

[PATCH] D124589: [clang-format] Fix a bug that misformats Access Specifier after *[]

2022-04-28 Thread Owen Pan via Phabricator via cfe-commits

owenpan updated this revision to Diff 425710.
owenpan added a comment.

Also checks the token before `*` and adds a test case.


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

https://reviews.llvm.org/D124589

Files:
  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
@@ -3336,6 +3336,14 @@
   verifyFormat("if (public == private)\n");
   verifyFormat("void foo(public, private)");
   verifyFormat("public::foo();");
+
+  verifyFormat("class A {\n"
+   "public:\n"
+   "  std::unique_ptr b() { return nullptr; }\n"
+   "\n"
+   "private:\n"
+   "  int c;\n"
+   "};");
 }
 
 TEST_F(FormatTest, SeparatesLogicalBlocks) {
@@ -21487,6 +21495,7 @@
"  bar([]() {} // Did not respect 
SpacesBeforeTrailingComments\n"
"  );\n"
"}");
+  verifyFormat("auto k = *[](int *j) { return j; }(&i)");
 
   // Lambdas created through weird macros.
   verifyFormat("void f() {\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2037,13 +2037,17 @@
 
 bool UnwrappedLineParser::tryToParseLambdaIntroducer() {
   const FormatToken *Previous = FormatTok->Previous;
-  if (Previous &&
-  (Previous->isOneOf(tok::identifier, tok::kw_operator, tok::kw_new,
- tok::kw_delete, tok::l_square) ||
-   FormatTok->isCppStructuredBinding(Style) || Previous->closesScope() ||
-   Previous->isSimpleTypeSpecifier())) {
-nextToken();
-return false;
+  if (Previous) {
+const FormatToken *PrevPrev = Previous->Previous;
+if (Previous->isOneOf(tok::identifier, tok::kw_operator, tok::kw_new,
+  tok::kw_delete, tok::l_square) ||
+FormatTok->isCppStructuredBinding(Style) || Previous->closesScope() ||
+Previous->isSimpleTypeSpecifier() ||
+(Previous->is(tok::star) && PrevPrev &&
+ PrevPrev->isSimpleTypeSpecifier())) {
+  nextToken();
+  return false;
+}
   }
   nextToken();
   if (FormatTok->is(tok::l_square))


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -3336,6 +3336,14 @@
   verifyFormat("if (public == private)\n");
   verifyFormat("void foo(public, private)");
   verifyFormat("public::foo();");
+
+  verifyFormat("class A {\n"
+   "public:\n"
+   "  std::unique_ptr b() { return nullptr; }\n"
+   "\n"
+   "private:\n"
+   "  int c;\n"
+   "};");
 }
 
 TEST_F(FormatTest, SeparatesLogicalBlocks) {
@@ -21487,6 +21495,7 @@
"  bar([]() {} // Did not respect SpacesBeforeTrailingComments\n"
"  );\n"
"}");
+  verifyFormat("auto k = *[](int *j) { return j; }(&i)");
 
   // Lambdas created through weird macros.
   verifyFormat("void f() {\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2037,13 +2037,17 @@
 
 bool UnwrappedLineParser::tryToParseLambdaIntroducer() {
   const FormatToken *Previous = FormatTok->Previous;
-  if (Previous &&
-  (Previous->isOneOf(tok::identifier, tok::kw_operator, tok::kw_new,
- tok::kw_delete, tok::l_square) ||
-   FormatTok->isCppStructuredBinding(Style) || Previous->closesScope() ||
-   Previous->isSimpleTypeSpecifier())) {
-nextToken();
-return false;
+  if (Previous) {
+const FormatToken *PrevPrev = Previous->Previous;
+if (Previous->isOneOf(tok::identifier, tok::kw_operator, tok::kw_new,
+  tok::kw_delete, tok::l_square) ||
+FormatTok->isCppStructuredBinding(Style) || Previous->closesScope() ||
+Previous->isSimpleTypeSpecifier() ||
+(Previous->is(tok::star) && PrevPrev &&
+ PrevPrev->isSimpleTypeSpecifier())) {
+  nextToken();
+  return false;
+}
   }
   nextToken();
   if (FormatTok->is(tok::l_square))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124589: [clang-format] Fix a bug that misformats Access Specifier after *[]

2022-04-28 Thread Owen Pan via Phabricator via cfe-commits

owenpan added a comment.

In D124589#3479241 , @curdeius wrote:

> Looks more or less correct, but I am afraid that this change may misbehave in 
> some rare cases.
> Consider `*[](auto *x) { return x; }();`, so an immediately invoked lambda 
> returning a pointer.
> It seems to be correctly formatted currently, but I don't see any test on it.
> Could you add a test for this please?

Good catch!


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

https://reviews.llvm.org/D124589

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

[PATCH] D123605: [WIP][Sema][SVE] Move/simplify Sema testing for SVE ACLE builtins

2022-04-28 Thread Rosie Sumpter via Phabricator via cfe-commits

RosieSumpter added inline comments.



Comment at: clang/test/Sema/aarch64-sve2-intrinsics/acle_sve2_imm_n.cpp:25
+{
+  // expected-error-re@+1 3 {{argument value {{[0-9]+}} is outside the valid 
range [0, 7]}}
+  EXPAND_XZM_FUNC(SVE_ACLE_FUNC(svqshlu,_n_s8,,), pg, svundef_s8(), -1);

paulwalker-arm wrote:
> I've not seen this before, presumably it's short hand instead of needing to 
> repeat multiple identical `expected-error` check lines?  If so, is it worth 
> using this throughout the test files and essentially only require one 
> `expected-error` per function or does this only work here because the 
> `EXPAND...` macro emits its three function calls on the same line?
Yes it lets you specify how many times you expect the diagnostic to appear, but 
as you said it only works when the diagnostics are emitted on the same line so 
I'm not sure there's a way to reduce the number of `expected-error` lines any 
more than this


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

https://reviews.llvm.org/D123605

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

[PATCH] D124536: [AMDGPU] Add gfx11 subtarget ELF definition

2022-04-28 Thread Jay Foad via Phabricator via cfe-commits

foad accepted this revision.
foad added a reviewer: t-tye.
foad added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124536

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

[PATCH] D123605: [WIP][Sema][SVE] Move/simplify Sema testing for SVE ACLE builtins

2022-04-28 Thread Rosie Sumpter via Phabricator via cfe-commits

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



Comment at: 
clang/test/Sema/aarch64-sve2-intrinsics/acle_sve2_imm_lane.cpp:151-152
+{
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid 
range [0, 1]}}
+  SVE_ACLE_FUNC(svcdot_lane,_s64,,)(svundef_s64(), svundef_s16(), 
svundef_s16(), -1, 0);
+  // expected-error-re@+1 {{argument value {{[0-9]+}} is outside the valid 
range [0, 1]}}

sdesmalen wrote:
> nit: there is also a svcdot_lane,_s32
It's already on line 86! 


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

https://reviews.llvm.org/D123605

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

[PATCH] D124563: Drop '* text=auto' from .gitattributes and normalize

2022-04-28 Thread Nikita Popov via Phabricator via cfe-commits

nikic added a comment.

This change seems to have broken switching to a branch before the commit 
completely. The only way I was able to recover my git checkout is to comment 
out the `* text=auto` line and then run `git reset --hard`, otherwise the 
crlf.cpp files always show up as changed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124563

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

[PATCH] D124532: [AST] Improve traversal of concept requirements

2022-04-28 Thread Ilya Biryukov via Phabricator via cfe-commits

ilya-biryukov updated this revision to Diff 425713.
ilya-biryukov added a comment.

- Mention the `AutoType` traversal does not traverse the constrained concept 
decl anymore and add a test for it


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124532

Files:
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/lib/Index/IndexBody.cpp
  clang/unittests/Tooling/RecursiveASTVisitorTests/Concept.cpp

Index: clang/unittests/Tooling/RecursiveASTVisitorTests/Concept.cpp
===
--- clang/unittests/Tooling/RecursiveASTVisitorTests/Concept.cpp
+++ clang/unittests/Tooling/RecursiveASTVisitorTests/Concept.cpp
@@ -7,7 +7,10 @@
 //===--===//
 
 #include "TestVisitor.h"
+#include "clang/AST/ASTConcept.h"
+#include "clang/AST/DeclTemplate.h"
 #include "clang/AST/ExprConcepts.h"
+#include "clang/AST/Type.h"
 
 using namespace clang;
 
@@ -18,28 +21,96 @@
 ++ConceptSpecializationExprsVisited;
 return true;
   }
-  bool TraverseConceptReference(const ConceptReference &R) {
-++ConceptReferencesTraversed;
-return true;
+  bool TraverseTypeConstraint(const TypeConstraint *C) {
+++TypeConstraintsTraversed;
+return ExpectedLocationVisitor::TraverseTypeConstraint(C);
+  }
+  bool TraverseConceptRequirement(concepts::Requirement *R) {
+++ConceptRequirementsTraversed;
+return ExpectedLocationVisitor::TraverseConceptRequirement(R);
   }
 
+  bool shouldVisitImplicitCode() { return ShouldVisitImplicitCode; }
+
   int ConceptSpecializationExprsVisited = 0;
-  int ConceptReferencesTraversed = 0;
+  int TypeConstraintsTraversed = 0;
+  int ConceptRequirementsTraversed = 0;
+  bool ShouldVisitImplicitCode = false;
 };
 
-TEST(RecursiveASTVisitor, ConstrainedParameter) {
+TEST(RecursiveASTVisitor, Concepts) {
   ConceptVisitor Visitor;
+  Visitor.ShouldVisitImplicitCode = true;
   EXPECT_TRUE(Visitor.runOver("template  concept Fooable = true;\n"
   "template  void bar(T);",
   ConceptVisitor::Lang_CXX2a));
-  // Check that we visit the "Fooable T" template parameter's TypeConstraint's
-  // ImmediatelyDeclaredConstraint, which is a ConceptSpecializationExpr.
+  // Check that we traverse the "Fooable T" template parameter's
+  // TypeConstraint's ImmediatelyDeclaredConstraint, which is a
+  // ConceptSpecializationExpr.
   EXPECT_EQ(1, Visitor.ConceptSpecializationExprsVisited);
-  // There are two ConceptReference objects in the AST: the base subobject
-  // of the ConceptSpecializationExpr, and the base subobject of the
-  // TypeConstraint itself. To avoid traversing the concept and arguments
-  // multiple times, we only traverse one.
-  EXPECT_EQ(1, Visitor.ConceptReferencesTraversed);
+  // Also check we traversed the TypeConstraint that produced the expr.
+  EXPECT_EQ(1, Visitor.TypeConstraintsTraversed);
+
+  Visitor = {}; // Don't visit implicit code now.
+  EXPECT_TRUE(Visitor.runOver("template  concept Fooable = true;\n"
+  "template  void bar(T);",
+  ConceptVisitor::Lang_CXX2a));
+  // Check that we only visit the TypeConstraint, but not the implicitly
+  // generated immediately declared expression.
+  EXPECT_EQ(0, Visitor.ConceptSpecializationExprsVisited);
+  EXPECT_EQ(1, Visitor.TypeConstraintsTraversed);
+
+  Visitor = {};
+  EXPECT_TRUE(Visitor.runOver("template  concept A = true;\n"
+  "template  struct vector {};\n"
+  "template  concept B = requires(T x) {\n"
+  "  typename vector;\n"
+  "  {x} -> A;\n"
+  "  requires true;\n"
+  "};",
+  ConceptVisitor::Lang_CXX2a));
+  EXPECT_EQ(3, Visitor.ConceptRequirementsTraversed);
+}
+
+struct VisitDeclOnlyOnce : ExpectedLocationVisitor {
+  bool VisitConceptDecl(ConceptDecl *D) {
+++ConceptDeclsVisited;
+return true;
+  }
+
+  bool VisitAutoType(AutoType *) {
+++AutoTypeVisited;
+return true;
+  }
+  bool VisitAutoTypeLoc(AutoTypeLoc) {
+++AutoTypeLocVisited;
+return true;
+  }
+
+  bool TraverseVarDecl(VarDecl *V) {
+// The base traversal visits only the `TypeLoc`.
+// However, in the test we also validate the underlying `QualType`.
+TraverseType(V->getType());
+return ExpectedLocationVisitor::TraverseVarDecl(V);
+  }
+
+  bool shouldWalkTypesOfTypeLocs() { return false; }
+
+  int ConceptDeclsVisited = 0;
+  int AutoTypeVisited = 0;
+  int AutoTypeLocVisited = 0;
+};
+
+TEST(RecursiveASTVisitor, ConceptDeclInAutoType) {
+  // Check `AutoType` and `AutoTypeLoc` do not repeatedly traverse the
+  //

[PATCH] D124563: Drop '* text=auto' from .gitattributes and normalize

2022-04-28 Thread Michael Forster via Phabricator via cfe-commits

MForster added a comment.

It also seems weird to me that a file that relies on CRLF line endings is 
checked in explicitly with LF line endings. A better approach IMHO would be to 
check it in as binary.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124563

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

[clang] e8cc749 - Revert "[clang-format] SortIncludes should support "@import" lines in Objective-C"

2022-04-28 Thread Krasimir Georgiev via cfe-commits


Author: Krasimir Georgiev
Date: 2022-04-28T11:00:32+02:00
New Revision: e8cc7490d23477233d21c72923a4f8ea43bfbbc0

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

LOG: Revert "[clang-format] SortIncludes should support "@import" lines in 
Objective-C"

This reverts commit d46fa023caa2db5a9f1e21dd038bcb626261d958.
Regressed include order in some cases with trailing comments, see the
comments on https://reviews.llvm.org/D121370. Will add a regression test
in a follow-up commit.

Added: 


Modified: 
clang/include/clang/Tooling/Inclusions/HeaderIncludes.h
clang/lib/Format/Format.cpp
clang/lib/Tooling/Inclusions/HeaderIncludes.cpp
clang/unittests/Format/SortIncludesTest.cpp

Removed: 




diff  --git a/clang/include/clang/Tooling/Inclusions/HeaderIncludes.h 
b/clang/include/clang/Tooling/Inclusions/HeaderIncludes.h
index a5017bf84c24a..ea8ad896be89f 100644
--- a/clang/include/clang/Tooling/Inclusions/HeaderIncludes.h
+++ b/clang/include/clang/Tooling/Inclusions/HeaderIncludes.h
@@ -129,23 +129,6 @@ class HeaderIncludes {
   llvm::Regex IncludeRegex;
 };
 
-/// \returns a regex that can match various styles of C++ includes.
-/// For example:
-/// \code
-/// #include 
-/// @import bar;
-/// #include "bar.h"
-/// \endcode
-llvm::Regex getCppIncludeRegex();
-
-/// \returns the last match in the list of matches that is not empty.
-llvm::StringRef getIncludeNameFromMatches(
-const llvm::SmallVectorImpl &Matches);
-
-/// \returns the given include name and removes the following symbols from the
-/// beginning and ending of the include name: " > < ;
-llvm::StringRef trimInclude(llvm::StringRef IncludeName);
-
 } // namespace tooling
 } // namespace clang
 

diff  --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index b2c710174ecd9..afa87a8bafe31 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -44,7 +44,6 @@
 #include "llvm/Support/VirtualFileSystem.h"
 #include "llvm/Support/YAMLTraits.h"
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -2725,6 +2724,13 @@ static void sortCppIncludes(const FormatStyle &Style,
   }
 }
 
+namespace {
+
+const char CppIncludeRegexPattern[] =
+R"(^[\t\ ]*#[\t\ ]*(import|include)[^"<]*(["<][^">]*[">]))";
+
+} // anonymous namespace
+
 tooling::Replacements sortCppIncludes(const FormatStyle &Style, StringRef Code,
   ArrayRef Ranges,
   StringRef FileName,
@@ -2734,7 +2740,7 @@ tooling::Replacements sortCppIncludes(const FormatStyle 
&Style, StringRef Code,
   .StartsWith("\xEF\xBB\xBF", 3) // UTF-8 BOM
   .Default(0);
   unsigned SearchFrom = 0;
-  llvm::Regex IncludeRegex(tooling::getCppIncludeRegex());
+  llvm::Regex IncludeRegex(CppIncludeRegexPattern);
   SmallVector Matches;
   SmallVector IncludesInBlock;
 
@@ -2790,14 +2796,7 @@ tooling::Replacements sortCppIncludes(const FormatStyle 
&Style, StringRef Code,
 bool MergeWithNextLine = Trimmed.endswith("\\");
 if (!FormattingOff && !MergeWithNextLine) {
   if (IncludeRegex.match(Line, &Matches)) {
-StringRef IncludeName = tooling::getIncludeNameFromMatches(Matches);
-// This addresses https://github.com/llvm/llvm-project/issues/38995
-bool WithSemicolon = false;
-if (!IncludeName.startswith("\"") && !IncludeName.startswith("<") &&
-IncludeName.endswith(";")) {
-  WithSemicolon = true;
-}
-
+StringRef IncludeName = Matches[2];
 if (Line.contains("/*") && !Line.contains("*/")) {
   // #include with a start of a block comment, but without the end.
   // Need to keep all the lines until the end of the comment together.
@@ -2810,10 +2809,8 @@ tooling::Replacements sortCppIncludes(const FormatStyle 
&Style, StringRef Code,
 int Category = Categories.getIncludePriority(
 IncludeName,
 /*CheckMainHeader=*/!MainIncludeFound && FirstIncludeBlock);
-int Priority = WithSemicolon ? std::numeric_limits::max()
- : Categories.getSortIncludePriority(
-   IncludeName, !MainIncludeFound &&
-FirstIncludeBlock);
+int Priority = Categories.getSortIncludePriority(
+IncludeName, !MainIncludeFound && FirstIncludeBlock);
 if (Category == 0)
   MainIncludeFound = true;
 IncludesInBlock.push_back(
@@ -3073,7 +3070,8 @@ namespace {
 
 inline bool isHeaderInsertion(const tooling::Replacement &Replace) {
   return Replace.getOffset() == UINT_MAX && Replace.getLength() == 0 &&
- tooling::getCppIncludeRegex().match(Replace.getRe

[clang] be656df - [clang-format] add a regression test for include sorting

2022-04-28 Thread Krasimir Georgiev via cfe-commits


Author: Krasimir Georgiev
Date: 2022-04-28T11:02:14+02:00
New Revision: be656df18721dc55a1de2eea64a3f73b6afa29a2

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

LOG: [clang-format] add a regression test for include sorting

This adds a regression test from the comments
on https://reviews.llvm.org/D121370.

Reviewed By: MyDeveloperDay, curdeius

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

Added: 


Modified: 
clang/unittests/Format/SortIncludesTest.cpp

Removed: 




diff  --git a/clang/unittests/Format/SortIncludesTest.cpp 
b/clang/unittests/Format/SortIncludesTest.cpp
index 7becb906d5d5..97a494a0a467 100644
--- a/clang/unittests/Format/SortIncludesTest.cpp
+++ b/clang/unittests/Format/SortIncludesTest.cpp
@@ -458,6 +458,20 @@ TEST_F(SortIncludesTest, HandlesMultilineIncludes) {
  "#include \"b.h\"\n"));
 }
 
+TEST_F(SortIncludesTest, HandlesTrailingCommentsWithAngleBrackets) {
+  // Regression test from the discussion at https://reviews.llvm.org/D121370.
+  EXPECT_EQ("#include \n"
+"\n"
+"#include \"util/bar.h\"\n"
+"#include \"util/foo/foo.h\" // foo\n",
+sort("#include \n"
+ "\n"
+ "#include \"util/bar.h\"\n"
+ "#include \"util/foo/foo.h\" // foo\n",
+ /*FileName=*/"input.cc",
+ /*ExpectedNumRanges=*/0));
+}
+
 TEST_F(SortIncludesTest, LeavesMainHeaderFirst) {
   Style.IncludeIsMainRegex = "([-_](test|unittest))?$";
   EXPECT_EQ("#include \"llvm/a.h\"\n"



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

[PATCH] D124513: [clang-format] add a regression test for include sorting

2022-04-28 Thread Krasimir Georgiev 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 rGbe656df18721: [clang-format] add a regression test for 
include sorting (authored by krasimir).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124513

Files:
  clang/unittests/Format/SortIncludesTest.cpp


Index: clang/unittests/Format/SortIncludesTest.cpp
===
--- clang/unittests/Format/SortIncludesTest.cpp
+++ clang/unittests/Format/SortIncludesTest.cpp
@@ -458,6 +458,20 @@
  "#include \"b.h\"\n"));
 }
 
+TEST_F(SortIncludesTest, HandlesTrailingCommentsWithAngleBrackets) {
+  // Regression test from the discussion at https://reviews.llvm.org/D121370.
+  EXPECT_EQ("#include \n"
+"\n"
+"#include \"util/bar.h\"\n"
+"#include \"util/foo/foo.h\" // foo\n",
+sort("#include \n"
+ "\n"
+ "#include \"util/bar.h\"\n"
+ "#include \"util/foo/foo.h\" // foo\n",
+ /*FileName=*/"input.cc",
+ /*ExpectedNumRanges=*/0));
+}
+
 TEST_F(SortIncludesTest, LeavesMainHeaderFirst) {
   Style.IncludeIsMainRegex = "([-_](test|unittest))?$";
   EXPECT_EQ("#include \"llvm/a.h\"\n"


Index: clang/unittests/Format/SortIncludesTest.cpp
===
--- clang/unittests/Format/SortIncludesTest.cpp
+++ clang/unittests/Format/SortIncludesTest.cpp
@@ -458,6 +458,20 @@
  "#include \"b.h\"\n"));
 }
 
+TEST_F(SortIncludesTest, HandlesTrailingCommentsWithAngleBrackets) {
+  // Regression test from the discussion at https://reviews.llvm.org/D121370.
+  EXPECT_EQ("#include \n"
+"\n"
+"#include \"util/bar.h\"\n"
+"#include \"util/foo/foo.h\" // foo\n",
+sort("#include \n"
+ "\n"
+ "#include \"util/bar.h\"\n"
+ "#include \"util/foo/foo.h\" // foo\n",
+ /*FileName=*/"input.cc",
+ /*ExpectedNumRanges=*/0));
+}
+
 TEST_F(SortIncludesTest, LeavesMainHeaderFirst) {
   Style.IncludeIsMainRegex = "([-_](test|unittest))?$";
   EXPECT_EQ("#include \"llvm/a.h\"\n"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124285: [clang][NFC] In parts of Objective-C Sema use Obj-C-specific types instead of `Decl`.

2022-04-28 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 added inline comments.



Comment at: clang/include/clang/Sema/Sema.h:3300
 
-  Decl *ActOnObjCContainerStartDefinition(Decl *IDecl);
+  void ActOnObjCContainerStartDefinition(ObjCContainerDecl *IDecl);
 

vsapsai wrote:
> jansvoboda11 wrote:
> > Why the change in return type?
> Initially I've changed the type to catch various `return 
> ActOnObjCContainerStartDefinition..` Now it's not really required.
> 
> What type do you think it should be? We can do both `Decl *` and 
> `ObjCContainerDecl *` though none of those is particularly useful. I've 
> decided to keep `void` because we don't use the returned value anyway.
> 
> I was also considering
> ```lang=c++
> template 
> ObjCDeclTy *ActOnObjCContainerStartDefinition(ObjCDeclTy *IDecl);
> ```
> 
> but I feel like the introduced complexity isn't worth it.
I see. I'm fine with having `void` here, what caught my attention was changing 
`return ActOnObjCContainerStartDefinition(X);` into 
`ActOnObjCContainerStartDefinition(X); return X;` that's perfectly fine though.



Comment at: clang/lib/Sema/SemaDecl.cpp:17067
+void Sema::ActOnObjCTemporaryExitContainerContext(ObjCContainerDecl *ObjCCtx) {
+  auto DC = cast(ObjCCtx);
   assert(DC == CurContext && "Mismatch of container contexts");

vsapsai wrote:
> jansvoboda11 wrote:
> > Why the cast? We should be able to compare/assign `ObjCContainerDecl *` to 
> > `DeclContext *`.
> I believe you are right and the cast is not required. Though we cannot 
> compare `ObjCCtx` and `CurContext`, we need to compare `DeclContext *DC`.
> 
> Also dropped a similar cast in `ActOnObjCContainerStartDefinition`.
Interesting, I would expect that `ObjCCtx == CurContext` would have implicit 
upcast of `ObjCCtx` to `DeclContext *`. Same for the assignment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124285

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

[PATCH] D124287: [modules][ODRHash] Compare ODR hashes to detect mismatches in duplicate ObjCInterfaceDecl.

2022-04-28 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 added inline comments.



Comment at: clang/lib/AST/ODRHash.cpp:528
+
+  //FIXME: Hash other interface-specific elements like protocols, etc.
+

Is this important to implement now, or are you fine leaving this be for the 
time being?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124287

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

[PATCH] D124287: [modules][ODRHash] Compare ODR hashes to detect mismatches in duplicate ObjCInterfaceDecl.

2022-04-28 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 added a comment.

In D124287#3476040 , @vsapsai wrote:

> In D124287#3474369 , @jansvoboda11 
> wrote:
>
>> This sounds reasonable to me. What use-cases does `ASTStructuralEquivalence` 
>> fit better than ODR hashes?
>
> I think the biggest advantage of `ASTStructuralEquivalence` is that it 
> doesn't affect memory consumption by Decls. But it makes repeated comparisons 
> more expensive.
>
> Another `ASTStructuralEquivalence` advantage is that it's easier to add new 
> checks. For example, comparing ivars is pretty trivial with 
> `ASTStructuralEquivalence` but with ODR hash we need to handle that ivar 
> types can be structs/unions, including anonymous and nested structs.
>
> Cannot say that for sure but I think `ASTStructuralEquivalence` is easier to 
> extend and to adopt for different purposes, while ODR hash seems to be more 
> invasive. But this argument is more hand-wavy.
>
> Most likely `ASTStructuralEquivalence` has other positive qualities but 
> that's what I was able to come up off the top of my head. And you can see 
> that in my decision-making `ASTStructuralEquivalence` doesn't look like a 
> compelling option.

Makes sense. If most `Decl` classes had the member variables that enable ODR 
hashing, would it make sense to keep structural equivalence logic around? That 
sounds a bit redundant to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124287

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

[PATCH] D124287: [modules][ODRHash] Compare ODR hashes to detect mismatches in duplicate ObjCInterfaceDecl.

2022-04-28 Thread Iain Sandoe via Phabricator via cfe-commits

iains added a comment.

In D124287#3479484 , @jansvoboda11 
wrote:

> In D124287#3476040 , @vsapsai wrote:
>
>> In D124287#3474369 , @jansvoboda11 
>> wrote:
>>
>>> This sounds reasonable to me. What use-cases does 
>>> `ASTStructuralEquivalence` fit better than ODR hashes?
>>
>> I think the biggest advantage of `ASTStructuralEquivalence` is that it 
>> doesn't affect memory consumption by Decls. But it makes repeated 
>> comparisons more expensive.
>>
>> Another `ASTStructuralEquivalence` advantage is that it's easier to add new 
>> checks. For example, comparing ivars is pretty trivial with 
>> `ASTStructuralEquivalence` but with ODR hash we need to handle that ivar 
>> types can be structs/unions, including anonymous and nested structs.



>> Cannot say that for sure but I think `ASTStructuralEquivalence` is easier to 
>> extend and to adopt for different purposes, while ODR hash seems to be more 
>> invasive. But this argument is more hand-wavy.
>>
>> Most likely `ASTStructuralEquivalence` has other positive qualities but 
>> that's what I was able to come up off the top of my head. And you can see 
>> that in my decision-making `ASTStructuralEquivalence` doesn't look like a 
>> compelling option.
>
> Makes sense. If most `Decl` classes had the member variables that enable ODR 
> hashing, would it make sense to keep structural equivalence logic around? 
> That sounds a bit redundant to me.

Presumably `ASTStructuralEquivalence` can also be used as a tie-breaker in the 
case of a hash collision?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124287

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

[PATCH] D124589: [clang-format] Fix a bug that misformats Access Specifier after *[]

2022-04-28 Thread Marek Kurdej via Phabricator via cfe-commits

curdeius added inline comments.



Comment at: clang/unittests/Format/FormatTest.cpp:3342
+   "public:\n"
+   "  std::unique_ptr b() { return nullptr; }\n"
+   "\n"

How about `int const *`, `const int*`? Is `const` & co. a simple type specifier?


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

https://reviews.llvm.org/D124589

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

[PATCH] D116527: [clang-format] Fix indentation for array variables with alignment of consecutive assignments and declarations.

2022-04-28 Thread Hans Wennborg via Phabricator via cfe-commits

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

This seems to have caused a strange indentation problem, see 
https://github.com/llvm/llvm-project/issues/55161


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116527

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

[PATCH] D124589: [clang-format] Fix a bug that misformats Access Specifier after *[]

2022-04-28 Thread Björn Schäpers via Phabricator via cfe-commits

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

I currently don't know exactly how `isSimpleTypeSpecifier` works, but what is 
with
`auto x = Foo * []{return 5;}();`
`auto x = Foo * *[]{static y = 5; return &y;}();`


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

https://reviews.llvm.org/D124589

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

[PATCH] D124558: [Tooling/DependencyScanning] Make skipping excluded PP ranges during dependency scanning the default

2022-04-28 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 added a comment.

LGTM in general, with some suggestions in-line. Besides those, I think we 
should be able to remove `PPSkipMappings` from the condition in 
`MinimizedVFSFile::create` (`DependencyScanningFilesystem.cpp`).




Comment at: 
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp:207
   // skipping in the preprocessor.
   if (PPSkipMappings)
 ScanInstance.getPreprocessorOpts()

I think we can remove this check as well now.



Comment at: 
clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp:291
 
-  if (Service.canSkipExcludedPPRanges())
-PPSkipMappings =
-std::make_unique();
+  PPSkipMappings = 
std::make_unique();
   if (Service.getMode() == ScanningMode::MinimizedSourcePreprocessing)

Do we need to keep this on the heap?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124558

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

[PATCH] D116527: [clang-format] Fix indentation for array variables with alignment of consecutive assignments and declarations.

2022-04-28 Thread Marek Kurdej via Phabricator via cfe-commits

curdeius added a comment.

Feel free to revert and add a regression test please. I'll take a look.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116527

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

[PATCH] D124287: [modules][ODRHash] Compare ODR hashes to detect mismatches in duplicate ObjCInterfaceDecl.

2022-04-28 Thread Jan Svoboda via Phabricator via cfe-commits

jansvoboda11 added a comment.

In D124287#3479493 , @iains wrote:

> Presumably `ASTStructuralEquivalence` can also be used as a tie-breaker in 
> the case of a hash collision?

Ah, that's a good point.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124287

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

[PATCH] D117112: [AArch64] Support for Ampere1 core

2022-04-28 Thread Philipp Tomsich via Phabricator via cfe-commits

philipp.tomsich updated this revision to Diff 425726.
philipp.tomsich added a comment.

- additional tab -> space conversion (hopefully, I have emacs configured 
correctly now)
- added SBSS and MTE to the SubtargetFeatures
- inserted AMpere1 in the subtarget enum in alphabetical order


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117112

Files:
  clang/test/Misc/target-invalid-cpu-note.c
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64SchedAmpere1.td
  llvm/lib/Target/AArch64/AArch64SchedPredAmpere.td
  llvm/lib/Target/AArch64/AArch64SchedPredicates.td
  llvm/lib/Target/AArch64/AArch64Subtarget.cpp
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/test/CodeGen/AArch64/cpus.ll
  llvm/test/CodeGen/AArch64/neon-dot-product.ll
  llvm/test/CodeGen/AArch64/remat.ll
  llvm/test/MC/AArch64/armv8.2a-dotprod.s
  llvm/test/MC/AArch64/armv8.3a-rcpc.s
  llvm/test/MC/Disassembler/AArch64/armv8.3a-rcpc.txt
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -1192,6 +1192,16 @@
  AArch64::AEK_SVE2 | AArch64::AEK_SVE2BITPERM |
  AArch64::AEK_BF16 | AArch64::AEK_I8MM,
  "8.5-A"),
+ARMCPUTestParams("ampere1", "armv8.6-a", "crypto-neon-fp-armv8",
+ AArch64::AEK_CRC | AArch64::AEK_CRYPTO |
+ AArch64::AEK_FP | AArch64::AEK_SIMD |
+ AArch64::AEK_FP16 | AArch64::AEK_RAS |
+ AArch64::AEK_LSE |
+ AArch64::AEK_DOTPROD | AArch64::AEK_RCPC |
+ AArch64::AEK_RDM | AArch64::AEK_MTE |
+ AArch64::AEK_SSBS | AArch64::AEK_SB |
+ AArch64::AEK_BF16 | AArch64::AEK_I8MM,
+ "8.6-A"),
 ARMCPUTestParams(
 "neoverse-512tvb", "armv8.4-a", "crypto-neon-fp-armv8",
 AArch64::AEK_RAS | AArch64::AEK_SVE | AArch64::AEK_SSBS |
Index: llvm/test/MC/Disassembler/AArch64/armv8.3a-rcpc.txt
===
--- llvm/test/MC/Disassembler/AArch64/armv8.3a-rcpc.txt
+++ llvm/test/MC/Disassembler/AArch64/armv8.3a-rcpc.txt
@@ -12,6 +12,7 @@
 # RUN: llvm-mc -triple aarch64-none-linux-gnu -mcpu=neoverse-e1 --disassemble < %s | FileCheck %s
 # RUN: llvm-mc -triple aarch64-none-linux-gnu -mcpu=neoverse-n1 --disassemble < %s | FileCheck %s
 # RUN: llvm-mc -triple aarch64-none-linux-gnu -mcpu=neoverse-n2 --disassemble < %s | FileCheck %s
+# RUN: llvm-mc -triple aarch64-none-linux-gnu -mcpu=ampere1 --disassemble < %s | FileCheck %s
 
 # CHECK: ldaprb w0, [x0]
 # CHECK: ldaprh w0, [x0]
Index: llvm/test/MC/AArch64/armv8.3a-rcpc.s
===
--- llvm/test/MC/AArch64/armv8.3a-rcpc.s
+++ llvm/test/MC/AArch64/armv8.3a-rcpc.s
@@ -6,6 +6,7 @@
 // RUN: llvm-mc -triple aarch64-none-linux-gnu -show-encoding -mcpu=neoverse-e1 < %s 2>&1 | FileCheck %s
 // RUN: llvm-mc -triple aarch64-none-linux-gnu -show-encoding -mcpu=neoverse-n1 < %s 2>&1 | FileCheck %s
 // RUN: llvm-mc -triple aarch64-none-linux-gnu -show-encoding -mcpu=neoverse-n2 < %s 2>&1 | FileCheck %s
+// RUN: llvm-mc -triple aarch64-none-linux-gnu -show-encoding -mcpu=ampere1 < %s 2>&1 | FileCheck %s
 // RUN: llvm-mc -triple aarch64-none-linux-gnu -show-encoding -mattr=+v8.2a -mattr=+rcpc < %s 2>&1 | FileCheck %s
 // RUN: not llvm-mc -triple aarch64-none-linux-gnu -mattr=+v8.2a < %s 2> %t
 // RUN: FileCheck --check-prefix=CHECK-REQ %s < %t
Index: llvm/test/MC/AArch64/armv8.2a-dotprod.s
===
--- llvm/test/MC/AArch64/armv8.2a-dotprod.s
+++ llvm/test/MC/AArch64/armv8.2a-dotprod.s
@@ -13,6 +13,7 @@
 // RUN: llvm-mc -triple aarch64 -mcpu=tsv110 -show-encoding < %s | FileCheck %s --check-prefix=CHECK-DOTPROD
 // RUN: llvm-mc -triple aarch64 -mcpu=cortex-r82 -show-encoding < %s | FileCheck %s --check-prefix=CHECK-DOTPROD
 // RUN: llvm-mc -triple aarch64 -mattr=+v8r -show-encoding < %s | FileCheck %s --check-prefix=CHECK-DOTPROD
+// RUN: llvm-mc -triple aarch64 -mcpu=ampere1 -show-encoding < %s | FileCheck %s --check-prefix=CHECK-DOTPROD
 
 // RUN: not llvm-mc -triple aarch64 -mattr=+v8.2a -show-encoding < %s 2> %t
 // RUN: FileCheck --check-prefix=CHECK-NO-DOTPROD < %t %s
@@ -36,6 +37,8 @@
 // RUN: FileCheck --check-prefix=CHECK-NO-DOTPROD < %t %s
 // RUN: not llvm-mc -triple aarch64 -mcpu=neoverse-n2 -mattr=-dotprod -show-encoding < %s 2> %t
 // RUN: FileCheck --check-prefix=CHECK-NO-DOTPROD < %t %s
+// RUN: not llvm-mc -triple aarch64 -mcpu

[PATCH] D69740: [profile] Support counter relocation at runtime

2022-04-28 Thread Florian Hahn via Phabricator via cfe-commits

fhahn added inline comments.
Herald added subscribers: abrachet, MaskRay.
Herald added a project: All.



Comment at: llvm/lib/Transforms/Instrumentation/InstrProfiling.cpp:673
+auto *Add = Builder.CreateAdd(Builder.CreatePtrToInt(Addr, Int64Ty), LI);
+Addr = Builder.CreateIntToPtr(Add, Int64PtrTy);
+  }

It looks like this may be creating invalid IR in some cases: 
https://github.com/llvm/llvm-project/issues/55125


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69740

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

[PATCH] D124532: [AST] Improve traversal of concept requirements

2022-04-28 Thread Ilya Biryukov via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG2b833d4086ab: [AST] Improve traversal of concepts and 
concept requirements (authored by ilya-biryukov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124532

Files:
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/lib/Index/IndexBody.cpp
  clang/unittests/Tooling/RecursiveASTVisitorTests/Concept.cpp

Index: clang/unittests/Tooling/RecursiveASTVisitorTests/Concept.cpp
===
--- clang/unittests/Tooling/RecursiveASTVisitorTests/Concept.cpp
+++ clang/unittests/Tooling/RecursiveASTVisitorTests/Concept.cpp
@@ -7,7 +7,10 @@
 //===--===//
 
 #include "TestVisitor.h"
+#include "clang/AST/ASTConcept.h"
+#include "clang/AST/DeclTemplate.h"
 #include "clang/AST/ExprConcepts.h"
+#include "clang/AST/Type.h"
 
 using namespace clang;
 
@@ -18,28 +21,96 @@
 ++ConceptSpecializationExprsVisited;
 return true;
   }
-  bool TraverseConceptReference(const ConceptReference &R) {
-++ConceptReferencesTraversed;
-return true;
+  bool TraverseTypeConstraint(const TypeConstraint *C) {
+++TypeConstraintsTraversed;
+return ExpectedLocationVisitor::TraverseTypeConstraint(C);
+  }
+  bool TraverseConceptRequirement(concepts::Requirement *R) {
+++ConceptRequirementsTraversed;
+return ExpectedLocationVisitor::TraverseConceptRequirement(R);
   }
 
+  bool shouldVisitImplicitCode() { return ShouldVisitImplicitCode; }
+
   int ConceptSpecializationExprsVisited = 0;
-  int ConceptReferencesTraversed = 0;
+  int TypeConstraintsTraversed = 0;
+  int ConceptRequirementsTraversed = 0;
+  bool ShouldVisitImplicitCode = false;
 };
 
-TEST(RecursiveASTVisitor, ConstrainedParameter) {
+TEST(RecursiveASTVisitor, Concepts) {
   ConceptVisitor Visitor;
+  Visitor.ShouldVisitImplicitCode = true;
   EXPECT_TRUE(Visitor.runOver("template  concept Fooable = true;\n"
   "template  void bar(T);",
   ConceptVisitor::Lang_CXX2a));
-  // Check that we visit the "Fooable T" template parameter's TypeConstraint's
-  // ImmediatelyDeclaredConstraint, which is a ConceptSpecializationExpr.
+  // Check that we traverse the "Fooable T" template parameter's
+  // TypeConstraint's ImmediatelyDeclaredConstraint, which is a
+  // ConceptSpecializationExpr.
   EXPECT_EQ(1, Visitor.ConceptSpecializationExprsVisited);
-  // There are two ConceptReference objects in the AST: the base subobject
-  // of the ConceptSpecializationExpr, and the base subobject of the
-  // TypeConstraint itself. To avoid traversing the concept and arguments
-  // multiple times, we only traverse one.
-  EXPECT_EQ(1, Visitor.ConceptReferencesTraversed);
+  // Also check we traversed the TypeConstraint that produced the expr.
+  EXPECT_EQ(1, Visitor.TypeConstraintsTraversed);
+
+  Visitor = {}; // Don't visit implicit code now.
+  EXPECT_TRUE(Visitor.runOver("template  concept Fooable = true;\n"
+  "template  void bar(T);",
+  ConceptVisitor::Lang_CXX2a));
+  // Check that we only visit the TypeConstraint, but not the implicitly
+  // generated immediately declared expression.
+  EXPECT_EQ(0, Visitor.ConceptSpecializationExprsVisited);
+  EXPECT_EQ(1, Visitor.TypeConstraintsTraversed);
+
+  Visitor = {};
+  EXPECT_TRUE(Visitor.runOver("template  concept A = true;\n"
+  "template  struct vector {};\n"
+  "template  concept B = requires(T x) {\n"
+  "  typename vector;\n"
+  "  {x} -> A;\n"
+  "  requires true;\n"
+  "};",
+  ConceptVisitor::Lang_CXX2a));
+  EXPECT_EQ(3, Visitor.ConceptRequirementsTraversed);
+}
+
+struct VisitDeclOnlyOnce : ExpectedLocationVisitor {
+  bool VisitConceptDecl(ConceptDecl *D) {
+++ConceptDeclsVisited;
+return true;
+  }
+
+  bool VisitAutoType(AutoType *) {
+++AutoTypeVisited;
+return true;
+  }
+  bool VisitAutoTypeLoc(AutoTypeLoc) {
+++AutoTypeLocVisited;
+return true;
+  }
+
+  bool TraverseVarDecl(VarDecl *V) {
+// The base traversal visits only the `TypeLoc`.
+// However, in the test we also validate the underlying `QualType`.
+TraverseType(V->getType());
+return ExpectedLocationVisitor::TraverseVarDecl(V);
+  }
+
+  bool shouldWalkTypesOfTypeLocs() { return false; }
+
+  int ConceptDeclsVisited = 0;
+  int AutoTypeVisited = 0;
+  int AutoTypeLocVisited = 0;
+};
+
+TEST(RecursiveASTVisitor, ConceptDeclInAutoType) {
+  // Check `AutoType` and `AutoTypeLoc` do not repeatedly traverse the
+  //

[clang-tools-extra] 2b833d4 - [AST] Improve traversal of concepts and concept requirements

2022-04-28 Thread Ilya Biryukov via cfe-commits


Author: Ilya Biryukov
Date: 2022-04-28T09:33:26Z
New Revision: 2b833d4086aba3c0fca480549309af54bfdd8e2e

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

LOG: [AST] Improve traversal of concepts and concept requirements

- Do not traverse concept decl inside `AutoType`. We only traverse
  declaration and definitions, not references to a declaration.
- Do not visit implicit AST node the relevant traversal mode.
- Add traversal extension points for concept requirements.
- Renamed `TraverseConceptReference` to mark as helper to share
  the code. Having an extension point there seems confusing given that
  there are many concept refences in the AST that do not call the
  helper. Those are `AutoType`, `AutoTypeLoc` and constraint requirements.

Only clangd code requires an update.

There are no use-cases for concept requirement traversals yet, but
I added them in the earlier version of the patch and decided to keep
them for completeness.

Reviewed By: sammccall

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

Added: 


Modified: 
clang-tools-extra/clangd/Selection.cpp
clang-tools-extra/clangd/unittests/XRefsTests.cpp
clang/include/clang/AST/RecursiveASTVisitor.h
clang/lib/Index/IndexBody.cpp
clang/unittests/Tooling/RecursiveASTVisitorTests/Concept.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/Selection.cpp 
b/clang-tools-extra/clangd/Selection.cpp
index fa3e6ff22a00a..e11b43047ec1c 100644
--- a/clang-tools-extra/clangd/Selection.cpp
+++ b/clang-tools-extra/clangd/Selection.cpp
@@ -10,6 +10,7 @@
 #include "AST.h"
 #include "support/Logger.h"
 #include "support/Trace.h"
+#include "clang/AST/ASTConcept.h"
 #include "clang/AST/ASTTypeTraits.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclCXX.h"
@@ -709,6 +710,15 @@ class SelectionVisitor : public 
RecursiveASTVisitor {
   bool TraversePseudoObjectExpr(PseudoObjectExpr *E) {
 return traverseNode(E, [&] { return TraverseStmt(E->getSyntacticForm()); 
});
   }
+  bool TraverseTypeConstraint(const TypeConstraint *C) {
+if (auto *E = C->getImmediatelyDeclaredConstraint()) {
+  // Technically this expression is 'implicit' and not traversed by the 
RAV.
+  // However, the range is correct, so we visit expression to avoid adding
+  // an extra kind to 'DynTypeNode' that hold 'TypeConstraint'.
+  return TraverseStmt(E);
+}
+return Base::TraverseTypeConstraint(C);
+  }
 
 private:
   using Base = RecursiveASTVisitor;

diff  --git a/clang-tools-extra/clangd/unittests/XRefsTests.cpp 
b/clang-tools-extra/clangd/unittests/XRefsTests.cpp
index 98693a5d6e4fc..9721f306bda4e 100644
--- a/clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ b/clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -2085,6 +2085,19 @@ TEST(FindReferences, ConceptsWithinAST) {
   checkFindRefs(Code);
 }
 
+TEST(FindReferences, ConceptReq) {
+  constexpr llvm::StringLiteral Code = R"cpp(
+template 
+concept $def[[IsSmal^l]] = sizeof(T) <= 8;
+
+template 
+concept IsSmallPtr = requires(T x) {
+  { *x } -> [[IsSmal^l]];
+};
+  )cpp";
+  checkFindRefs(Code);
+}
+
 TEST(FindReferences, RequiresExprParameters) {
   constexpr llvm::StringLiteral Code = R"cpp(
 template 

diff  --git a/clang/include/clang/AST/RecursiveASTVisitor.h 
b/clang/include/clang/AST/RecursiveASTVisitor.h
index f143df5c3c17f..79e5294a3ca17 100644
--- a/clang/include/clang/AST/RecursiveASTVisitor.h
+++ b/clang/include/clang/AST/RecursiveASTVisitor.h
@@ -13,18 +13,19 @@
 #ifndef LLVM_CLANG_AST_RECURSIVEASTVISITOR_H
 #define LLVM_CLANG_AST_RECURSIVEASTVISITOR_H
 
+#include "clang/AST/ASTConcept.h"
 #include "clang/AST/Attr.h"
 #include "clang/AST/Decl.h"
-#include "clang/AST/DeclarationName.h"
 #include "clang/AST/DeclBase.h"
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclFriend.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/AST/DeclOpenMP.h"
 #include "clang/AST/DeclTemplate.h"
+#include "clang/AST/DeclarationName.h"
 #include "clang/AST/Expr.h"
-#include "clang/AST/ExprConcepts.h"
 #include "clang/AST/ExprCXX.h"
+#include "clang/AST/ExprConcepts.h"
 #include "clang/AST/ExprObjC.h"
 #include "clang/AST/ExprOpenMP.h"
 #include "clang/AST/LambdaCapture.h"
@@ -319,11 +320,6 @@ template  class RecursiveASTVisitor {
   bool TraverseSynOrSemInitListExpr(InitListExpr *S,
 DataRecursionQueue *Queue = nullptr);
 
-  /// Recursively visit a reference to a concept with potential arguments.
-  ///
-  /// \returns false if the visitation was terminated early, true otherwise.
-  bool TraverseConceptReference(const ConceptReference &C);
-
   /// Recursively visit an Objective-C protocol reference with location
   /// information.
   ///
@@ -475,11 +471,21 @@ template  clas

[PATCH] D116527: [clang-format] Fix indentation for array variables with alignment of consecutive assignments and declarations.

2022-04-28 Thread Hans Wennborg via Phabricator via cfe-commits

hans added a comment.

In D116527#3479509 , @curdeius wrote:

> Feel free to revert and add a regression test please. I'll take a look.

Since this patch landed a couple of months back, I don't think we need to rush 
to revert it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116527

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

[clang] bf0bcb5 - [Analyzer] Remove undefined function

2022-04-28 Thread Marco Antognini via cfe-commits


Author: Marco Antognini
Date: 2022-04-28T11:54:40+02:00
New Revision: bf0bcb5e539b1177cb2023691a13635e8cab5d2f

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

LOG: [Analyzer] Remove undefined function

This getLValue function was declared in 98db1f990fc2 ([Analyzer] [NFC]
Parameter Regions, 2020-05-11) but was never implemented.

Reviewed By: NoQ

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

Added: 


Modified: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h

Removed: 




diff  --git 
a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h 
b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
index 3204ac460ed0..cf285c1e1d55 100644
--- a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
+++ b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
@@ -306,10 +306,6 @@ class ProgramState : public llvm::FoldingSetNode {
   Loc getLValue(const CXXRecordDecl *BaseClass, const SubRegion *Super,
 bool IsVirtual) const;
 
-  /// Get the lvalue for a parameter.
-  Loc getLValue(const Expr *Call, unsigned Index,
-const LocationContext *LC) const;
-
   /// Get the lvalue for a variable reference.
   Loc getLValue(const VarDecl *D, const LocationContext *LC) const;
 



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

[PATCH] D124461: [Analyzer] Remove undefined function

2022-04-28 Thread Marco Antognini via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGbf0bcb5e539b: [Analyzer] Remove undefined function (authored 
by mantognini).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124461

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h


Index: clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
===
--- clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
+++ clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
@@ -306,10 +306,6 @@
   Loc getLValue(const CXXRecordDecl *BaseClass, const SubRegion *Super,
 bool IsVirtual) const;
 
-  /// Get the lvalue for a parameter.
-  Loc getLValue(const Expr *Call, unsigned Index,
-const LocationContext *LC) const;
-
   /// Get the lvalue for a variable reference.
   Loc getLValue(const VarDecl *D, const LocationContext *LC) const;
 


Index: clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
===
--- clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
+++ clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
@@ -306,10 +306,6 @@
   Loc getLValue(const CXXRecordDecl *BaseClass, const SubRegion *Super,
 bool IsVirtual) const;
 
-  /// Get the lvalue for a parameter.
-  Loc getLValue(const Expr *Call, unsigned Index,
-const LocationContext *LC) const;
-
   /// Get the lvalue for a variable reference.
   Loc getLValue(const VarDecl *D, const LocationContext *LC) const;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124525: [OpenMP][ClangLinkerWrapper] Extending linker wrapper to embed metadata for multi-arch fat binaries

2022-04-28 Thread Saiyedul Islam via Phabricator via cfe-commits

saiislam added a comment.

In D124525#3478469 , @yaxunl wrote:

> need a test for the generated registration code

Yes, I will add tests.




Comment at: clang/tools/clang-linker-wrapper/ClangLinkerWrapper.cpp:1161
 
-LinkedImages.push_back(*ImageOrErr);
+LinkedImages.emplace_back(TheArch, *ImageOrErr);
   }

jhuber6 wrote:
> I'm doing something similar in D123810, I just used the existing `DeviceFile` 
> because I needed the `Arch` and `Kind` fields to dispatch the appropriate 
> wrapping job for CUDA / HIP.
Seems simpler. I will pull that change here.



Comment at: clang/tools/clang-linker-wrapper/OffloadWrapper.cpp:98-104
+  // struct __tgt_image_info {
+  //   int32_t version;
+  //   int32_t image_number;
+  //   int32_t number_images;
+  //   char* offload_arch;
+  //   char* target_compile_opts;
+  // };

yaxunl wrote:
> I am wondering whether we should add a few more fields to make it more 
> generic for all offloading languages and platforms:
> 
> 
> ```
> char* target_triple;
> char* offloading_kind; // openmp, hip, etc
> char* file_type; // elf, spirv, bitcode, etc
> ```
Good idea. Though I am not sure whether file_type info is being propagated in 
by the linker-wrapper or not. I will check.



Comment at: clang/tools/clang-linker-wrapper/OffloadWrapper.cpp:246
   IRBuilder<> Builder(BasicBlock::Create(C, "entry", Func));
+  // Create calls to __tgt_register_image_info for each image
+  auto *NullPtr = llvm::ConstantPointerNull::get(Builder.getInt8PtrTy());

jhuber6 wrote:
> I'm wondering if it would be better to create a new `__tgt_bin_desc` and call 
> a new `__tgt_register_lib` with it here so we don't need multiple calls here. 
> Inside that new runtime function we could just widen or shrink the existing 
> structs as needed. That way each device image would have this metadata 
> associated with it and the target plugin can handle it as-needed.
Last time multiple vendors objected to changing `__tgt_bin_desc` and 
`__tgt_device_image` structs. The reason was backward compatibility of multiple 
downstream runtimes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124525

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

[PATCH] D124348: [1/2][RISCV]Add Intrinsics for B extension in Clang

2022-04-28 Thread Chang Hu via Phabricator via cfe-commits

joker881 added a comment.

In D124348#3470612 , @craig.topper 
wrote:

> The "B extension" terminology no longer exists.

And I decide to ctz_32 and ctz_64 like clz.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124348

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

[PATCH] D123605: [WIP][Sema][SVE] Move/simplify Sema testing for SVE ACLE builtins

2022-04-28 Thread Paul Walker via Phabricator via cfe-commits

paulwalker-arm added inline comments.



Comment at: clang/test/Sema/aarch64-sve2-intrinsics/acle_sve2_imm_n.cpp:25
+{
+  // expected-error-re@+1 3 {{argument value {{[0-9]+}} is outside the valid 
range [0, 7]}}
+  EXPAND_XZM_FUNC(SVE_ACLE_FUNC(svqshlu,_n_s8,,), pg, svundef_s8(), -1);

RosieSumpter wrote:
> paulwalker-arm wrote:
> > I've not seen this before, presumably it's short hand instead of needing to 
> > repeat multiple identical `expected-error` check lines?  If so, is it worth 
> > using this throughout the test files and essentially only require one 
> > `expected-error` per function or does this only work here because the 
> > `EXPAND...` macro emits its three function calls on the same line?
> Yes it lets you specify how many times you expect the diagnostic to appear, 
> but as you said it only works when the diagnostics are emitted on the same 
> line so I'm not sure there's a way to reduce the number of `expected-error` 
> lines any more than this
OK, thanks for checking.  To be honest I'm not sure why we need the 
`EXPAND_XZM_FUNC` macro given `SVE_ACLE_FUNC` worked fine before.  To my eye it 
kind of ruins the flow, but hey-ho I'll not worry about it.

Assuming I've not screwed up I think you're missing tests for 
`SVE_ACLE_FUNC(svrshrnb,_n_s16,,)` and `SVE_ACLE_FUNC(svrshrnt,_n_s16,,)`.



Comment at: 
clang/test/Sema/aarch64-sve2-intrinsics/acle_sve2_imm_rotation.cpp:17-40
+  // expected-error@+1 {{argument should be the value 90 or 270}}
+  SVE_ACLE_FUNC(svcadd,_s8,,)(svundef_s8(), svundef_s8(), 0);
+  // expected-error@+1 {{argument should be the value 90 or 270}}
+  SVE_ACLE_FUNC(svcadd,_u8,,)(svundef_u8(), svundef_u8(), 0);
+  // expected-error@+1 {{argument should be the value 90 or 270}}
+  SVE_ACLE_FUNC(svcadd,_s16,,)(svundef_s16(), svundef_s16(), 0);
+  // expected-error@+1 {{argument should be the value 90 or 270}}

I know we cannot test every number but `180` seems like a reasonable mistake 
for people to make given the other complex number instructions so perhaps 
alternate between `0` and `180` to give a little more coverage without 
increasing the number of lines.


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

https://reviews.llvm.org/D123605

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

[PATCH] D124606: Use `binary` git attribute instead of `text eol=...'

2022-04-28 Thread Michael Forster via Phabricator via cfe-commits

MForster created this revision.
MForster added a reviewer: labath.
Herald added a subscriber: jdoerfert.
Herald added a project: All.
MForster requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

These automatic conversions lead to issues in various workflows, and all
we want here are files that retain their line endings under all
circumstances. `binary` captures that perfectly well and leads to fewer
issues.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124606

Files:
  clang-tools-extra/test/.gitattributes


Index: clang-tools-extra/test/.gitattributes
===
--- clang-tools-extra/test/.gitattributes
+++ clang-tools-extra/test/.gitattributes
@@ -4,12 +4,12 @@
 
 # These test input files rely on one-byte Unix (LF) line-endings, as they use
 # fixed -offset, FileOffset:, or Offset: numbers in their tests.
-clang-apply-replacements/ClangRenameClassReplacements.cpp text eol=lf
-clang-apply-replacements/Inputs/basic/basic.h text eol=lf
-clang-apply-replacements/Inputs/format/no.cpp text eol=lf
-clang-apply-replacements/Inputs/format/yes.cpp text eol=lf
-clang-tidy/infrastructure/export-diagnostics.cpp text eol=lf
+clang-apply-replacements/ClangRenameClassReplacements.cpp binary
+clang-apply-replacements/Inputs/basic/basic.h binary
+clang-apply-replacements/Inputs/format/no.cpp binary
+clang-apply-replacements/Inputs/format/yes.cpp binary
+clang-tidy/infrastructure/export-diagnostics.cpp binary
 
 # These test input files rely on two-byte Windows (CRLF) line endings.
-clang-apply-replacements/Inputs/crlf/crlf.cpp text eol=crlf
-clang-apply-replacements/Inputs/crlf/crlf.cpp.expected text eol=crlf
+clang-apply-replacements/Inputs/crlf/crlf.cpp binary
+clang-apply-replacements/Inputs/crlf/crlf.cpp.expected binary


Index: clang-tools-extra/test/.gitattributes
===
--- clang-tools-extra/test/.gitattributes
+++ clang-tools-extra/test/.gitattributes
@@ -4,12 +4,12 @@
 
 # These test input files rely on one-byte Unix (LF) line-endings, as they use
 # fixed -offset, FileOffset:, or Offset: numbers in their tests.
-clang-apply-replacements/ClangRenameClassReplacements.cpp text eol=lf
-clang-apply-replacements/Inputs/basic/basic.h text eol=lf
-clang-apply-replacements/Inputs/format/no.cpp text eol=lf
-clang-apply-replacements/Inputs/format/yes.cpp text eol=lf
-clang-tidy/infrastructure/export-diagnostics.cpp text eol=lf
+clang-apply-replacements/ClangRenameClassReplacements.cpp binary
+clang-apply-replacements/Inputs/basic/basic.h binary
+clang-apply-replacements/Inputs/format/no.cpp binary
+clang-apply-replacements/Inputs/format/yes.cpp binary
+clang-tidy/infrastructure/export-diagnostics.cpp binary
 
 # These test input files rely on two-byte Windows (CRLF) line endings.
-clang-apply-replacements/Inputs/crlf/crlf.cpp text eol=crlf
-clang-apply-replacements/Inputs/crlf/crlf.cpp.expected text eol=crlf
+clang-apply-replacements/Inputs/crlf/crlf.cpp binary
+clang-apply-replacements/Inputs/crlf/crlf.cpp.expected binary
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D118996: [clang-tidy] Support C++14 in bugprone-signal-handler.

2022-04-28 Thread Balázs Kéri via Phabricator via cfe-commits

balazske added inline comments.



Comment at: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp:328
 const LangOptions &LangOpts) const {
-  // FIXME: Make the checker useful on C++ code.
-  if (LangOpts.CPlusPlus)
-return false;
-
-  return true;
+  return LangOpts.CPlusPlus17 == 0;
 }

whisperity wrote:
> Aren't these `bool`s?
This is a 1-bit bit field member.



Comment at: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp:472
+StringRef Name = FoundS->getStmtClassName();
+if (Name.startswith("CXX")) {
+  SourceRange R = getSourceRangeOfStmt(FoundS, Ctx);

njames93 wrote:
> This just feels very hacky and it's non exhaustive, would lambda for a start 
> as that isn't prefixed internally with CXX.
This is somewhat "hacky" but is more future-proof if new `Stmt` classes are 
added. I extend the list with `isa` checks for classes in **ExprCXX.h** and 
**StmtCXX.h**. But it is likely that when a new C++-only node is added this 
list is not updated (maybe no problem because new things are for later than 
C++17).



Comment at: clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp:126
 const LangOptions &LangOpts) const {
-  // FIXME: Make the checker useful on C++ code.
-  if (LangOpts.CPlusPlus)
+  if (LangOpts.CPlusPlus17)
 return false;

LegalizeAdulthood wrote:
> njames93 wrote:
> > Is this check valid on Objective-C code?
> `return LangOpts.CPlusPlus17 == 0;`
I do not know if the check is applicable to Objective-C, it may depend on if 
the C standard (or POSIX) is applicable to Objective-C.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118996

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

[PATCH] D124606: Use `binary` git attribute instead of `text eol=...'

2022-04-28 Thread Michael Forster via Phabricator via cfe-commits

MForster updated this revision to Diff 425742.
MForster added a comment.

Force-add crlf.cpp(.expected) with CRLF line endings.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124606

Files:
  clang-tools-extra/test/.gitattributes
  clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
  clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected


Index: clang-tools-extra/test/.gitattributes
===
--- clang-tools-extra/test/.gitattributes
+++ clang-tools-extra/test/.gitattributes
@@ -4,12 +4,12 @@
 
 # These test input files rely on one-byte Unix (LF) line-endings, as they use
 # fixed -offset, FileOffset:, or Offset: numbers in their tests.
-clang-apply-replacements/ClangRenameClassReplacements.cpp text eol=lf
-clang-apply-replacements/Inputs/basic/basic.h text eol=lf
-clang-apply-replacements/Inputs/format/no.cpp text eol=lf
-clang-apply-replacements/Inputs/format/yes.cpp text eol=lf
-clang-tidy/infrastructure/export-diagnostics.cpp text eol=lf
+clang-apply-replacements/ClangRenameClassReplacements.cpp binary
+clang-apply-replacements/Inputs/basic/basic.h binary
+clang-apply-replacements/Inputs/format/no.cpp binary
+clang-apply-replacements/Inputs/format/yes.cpp binary
+clang-tidy/infrastructure/export-diagnostics.cpp binary
 
 # These test input files rely on two-byte Windows (CRLF) line endings.
-clang-apply-replacements/Inputs/crlf/crlf.cpp text eol=crlf
-clang-apply-replacements/Inputs/crlf/crlf.cpp.expected text eol=crlf
+clang-apply-replacements/Inputs/crlf/crlf.cpp binary
+clang-apply-replacements/Inputs/crlf/crlf.cpp.expected binary


Index: clang-tools-extra/test/.gitattributes
===
--- clang-tools-extra/test/.gitattributes
+++ clang-tools-extra/test/.gitattributes
@@ -4,12 +4,12 @@
 
 # These test input files rely on one-byte Unix (LF) line-endings, as they use
 # fixed -offset, FileOffset:, or Offset: numbers in their tests.
-clang-apply-replacements/ClangRenameClassReplacements.cpp text eol=lf
-clang-apply-replacements/Inputs/basic/basic.h text eol=lf
-clang-apply-replacements/Inputs/format/no.cpp text eol=lf
-clang-apply-replacements/Inputs/format/yes.cpp text eol=lf
-clang-tidy/infrastructure/export-diagnostics.cpp text eol=lf
+clang-apply-replacements/ClangRenameClassReplacements.cpp binary
+clang-apply-replacements/Inputs/basic/basic.h binary
+clang-apply-replacements/Inputs/format/no.cpp binary
+clang-apply-replacements/Inputs/format/yes.cpp binary
+clang-tidy/infrastructure/export-diagnostics.cpp binary
 
 # These test input files rely on two-byte Windows (CRLF) line endings.
-clang-apply-replacements/Inputs/crlf/crlf.cpp text eol=crlf
-clang-apply-replacements/Inputs/crlf/crlf.cpp.expected text eol=crlf
+clang-apply-replacements/Inputs/crlf/crlf.cpp binary
+clang-apply-replacements/Inputs/crlf/crlf.cpp.expected binary
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124563: Drop '* text=auto' from .gitattributes and normalize

2022-04-28 Thread Michael Forster via Phabricator via cfe-commits

MForster added a comment.

I'm proposing this: D124606 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124563

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

[PATCH] D124258: [C89/C2x] Change the behavior of implicit int diagnostics

2022-04-28 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

Ping for the other reviewers in case they have thoughts.


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

https://reviews.llvm.org/D124258

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

[PATCH] D123831: [clang][extract-api] Use relative includes

2022-04-28 Thread Daniel Grumberg via Phabricator via cfe-commits

dang added inline comments.



Comment at: clang/lib/ExtractAPI/ExtractAPIConsumer.cpp:134
+if (!SpelledFilename.empty())
+  return SpelledFilename.str();
+

zixuw wrote:
> zixuw wrote:
> > zixuw wrote:
> > > One problem I can see in this right now is that there might be multiple 
> > > headermaps that together construct a chain of mapping, for example
> > > ```
> > > // A.hmap
> > > Header.h -> Product/Header.h
> > > 
> > > // B.hmap
> > > Product/Header.h -> /Absolute/path/to/Header.h
> > > ```
> > > Then this iteration would conclude on using `Product/Header.h` and missed 
> > > the first mapping (if the command line goes `clang -extract-api -I A.hmap 
> > > -I B.hmap ...`).
> > > 
> > > It's also possible that a headermap and a search path together resolve 
> > > the header. For example:
> > > ```
> > > //A.hmap
> > > Header.h -> Product/Header.h
> > > 
> > > // Invocation:
> > > clang -extract-api /Some/Path/to/Product/Header.h -I A.hmap -I 
> > > /Some/path/to/
> > > ```
> > > 
> > > I think we need to keep records and iterate backwards on the search paths 
> > > again to get the full reverse lookup
> > Or, iterate once in reverse and find the last match? 🤔 
> Another thing just came to me: with multiple headermaps chaining remaps, 
> which is the "correct" way to include a header?
> ```
> // A.hmap
> Header.h -> Product/Header.h
> 
> // B.hmap
> Product/Header.h -> /Absolute/path/to/Header.h
> ```
> In the context of Darwin frameworks, we'd use `` so we 
> don't want to follow the chain all the way backwards.
> But without any context or build system rationales of why multiple headermaps 
> with remap chains are generated in the first place, I'm feeling that we don't 
> nearly have enough information for this if we're only talking about headermap 
> as it is and refraining from adopting heuristics.
Two things:
- If we want an exhaustive search, then it would make sense to do what would 
actually happen in a compilation. Iterate forward and find all matches, then 
iterate forwards again with each of the matches from the previous step until we 
find all terminal matches and then heuristically pick the "best one" probably 
the shortest one.
- The "correct" way of including a header would certainly be `#include 
` for a Darwin framework. Nonetheless if the search paths and 
headermaps setup means that `#include "Header.h"` or `#include ` is a 
possible way of getting to the same file I see no harm in doing that. As long 
as shortening a given file results in deterministic results it should work 
fine. I think it would be a user error if shortening a file path to say 
`` meant that including it would lead to a completely different file 
(that is with different declarations/definitions).



Comment at: clang/lib/ExtractAPI/ExtractAPIConsumer.cpp:908
+if (auto RelativeName = getRelativeIncludeName(CI, FilePath)) {
+  HeaderContents += " <";
+  HeaderContents += *RelativeName;

I think `getRelativeIncludeName` is slightly wrong. It doesn't seem like it 
accounts for matches specifically made with `-iquote` arguments. My 
understanding is that we should record that information at that point and 
include the file using the appropriate form `#include "RelativeName"` or 
`#include `. It would probably be best if 
`getRelativeIncludeName` included the quote type in the string directly.



Comment at: clang/test/ExtractAPI/known_files_only_hmap.c:1
+// XFAIL: *
 // RUN: rm -rf %t

I think you can safely delete this test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123831

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

[PATCH] D123605: [Sema][SVE2] Move/simplify Sema testing for SVE2 ACLE builtins

2022-04-28 Thread Rosie Sumpter via Phabricator via cfe-commits

RosieSumpter added inline comments.



Comment at: clang/test/Sema/aarch64-sve2-intrinsics/acle_sve2_imm_n.cpp:25
+{
+  // expected-error-re@+1 3 {{argument value {{[0-9]+}} is outside the valid 
range [0, 7]}}
+  EXPAND_XZM_FUNC(SVE_ACLE_FUNC(svqshlu,_n_s8,,), pg, svundef_s8(), -1);

paulwalker-arm wrote:
> RosieSumpter wrote:
> > paulwalker-arm wrote:
> > > I've not seen this before, presumably it's short hand instead of needing 
> > > to repeat multiple identical `expected-error` check lines?  If so, is it 
> > > worth using this throughout the test files and essentially only require 
> > > one `expected-error` per function or does this only work here because the 
> > > `EXPAND...` macro emits its three function calls on the same line?
> > Yes it lets you specify how many times you expect the diagnostic to appear, 
> > but as you said it only works when the diagnostics are emitted on the same 
> > line so I'm not sure there's a way to reduce the number of `expected-error` 
> > lines any more than this
> OK, thanks for checking.  To be honest I'm not sure why we need the 
> `EXPAND_XZM_FUNC` macro given `SVE_ACLE_FUNC` worked fine before.  To my eye 
> it kind of ruins the flow, but hey-ho I'll not worry about it.
> 
> Assuming I've not screwed up I think you're missing tests for 
> `SVE_ACLE_FUNC(svrshrnb,_n_s16,,)` and `SVE_ACLE_FUNC(svrshrnt,_n_s16,,)`.
I've removed the macro - agree that it ruins the flow


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

https://reviews.llvm.org/D123605

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

[PATCH] D124606: Use `binary` git attribute instead of `text eol=...'

2022-04-28 Thread Pavel Labath via Phabricator via cfe-commits

labath added a comment.

I believe (based on some similar issues I was solving in lldb) that `-text` 
instead of `binary` is sufficient to prevent git from fidlling with the 
contents, while maintaining the ability to diff the files.

Other than that, I am in favour of this approach, but I'd recommend getting 
this reviewed by someone on the clang-tools team.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124606

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

[PATCH] D124606: Use `binary` git attribute instead of `text eol=...'

2022-04-28 Thread Michael Forster via Phabricator via cfe-commits

MForster updated this revision to Diff 425745.
MForster added a comment.

Use `-text` instead of `binary`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124606

Files:
  clang-tools-extra/test/.gitattributes
  clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
  clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected


Index: 
clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected
===
--- 
clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected
+++ 
clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected
@@ -1,6 +1,6 @@
-
-// This file intentionally uses a CRLF newlines!
-
-void foo() {
-  int *x = nullptr;
-}
+
+// This file intentionally uses a CRLF newlines!
+
+void foo() {
+  int *x = nullptr;
+}
Index: clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
===
--- clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
+++ clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
@@ -1,6 +1,6 @@
-
-// This file intentionally uses a CRLF newlines!
-
-void foo() {
-  int *x = 0;
-}
+
+// This file intentionally uses a CRLF newlines!
+
+void foo() {
+  int *x = 0;
+}
Index: clang-tools-extra/test/.gitattributes
===
--- clang-tools-extra/test/.gitattributes
+++ clang-tools-extra/test/.gitattributes
@@ -4,12 +4,12 @@
 
 # These test input files rely on one-byte Unix (LF) line-endings, as they use
 # fixed -offset, FileOffset:, or Offset: numbers in their tests.
-clang-apply-replacements/ClangRenameClassReplacements.cpp text eol=lf
-clang-apply-replacements/Inputs/basic/basic.h text eol=lf
-clang-apply-replacements/Inputs/format/no.cpp text eol=lf
-clang-apply-replacements/Inputs/format/yes.cpp text eol=lf
-clang-tidy/infrastructure/export-diagnostics.cpp text eol=lf
+clang-apply-replacements/ClangRenameClassReplacements.cpp -text
+clang-apply-replacements/Inputs/basic/basic.h -text
+clang-apply-replacements/Inputs/format/no.cpp -text
+clang-apply-replacements/Inputs/format/yes.cpp -text
+clang-tidy/infrastructure/export-diagnostics.cpp -text
 
 # These test input files rely on two-byte Windows (CRLF) line endings.
-clang-apply-replacements/Inputs/crlf/crlf.cpp text eol=crlf
-clang-apply-replacements/Inputs/crlf/crlf.cpp.expected text eol=crlf
+clang-apply-replacements/Inputs/crlf/crlf.cpp -text
+clang-apply-replacements/Inputs/crlf/crlf.cpp.expected -text


Index: clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected
===
--- clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected
+++ clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected
@@ -1,6 +1,6 @@
-
-// This file intentionally uses a CRLF newlines!
-
-void foo() {
-  int *x = nullptr;
-}
+
+// This file intentionally uses a CRLF newlines!
+
+void foo() {
+  int *x = nullptr;
+}
Index: clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
===
--- clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
+++ clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
@@ -1,6 +1,6 @@
-
-// This file intentionally uses a CRLF newlines!
-
-void foo() {
-  int *x = 0;
-}
+
+// This file intentionally uses a CRLF newlines!
+
+void foo() {
+  int *x = 0;
+}
Index: clang-tools-extra/test/.gitattributes
===
--- clang-tools-extra/test/.gitattributes
+++ clang-tools-extra/test/.gitattributes
@@ -4,12 +4,12 @@
 
 # These test input files rely on one-byte Unix (LF) line-endings, as they use
 # fixed -offset, FileOffset:, or Offset: numbers in their tests.
-clang-apply-replacements/ClangRenameClassReplacements.cpp text eol=lf
-clang-apply-replacements/Inputs/basic/basic.h text eol=lf
-clang-apply-replacements/Inputs/format/no.cpp text eol=lf
-clang-apply-replacements/Inputs/format/yes.cpp text eol=lf
-clang-tidy/infrastructure/export-diagnostics.cpp text eol=lf
+clang-apply-replacements/ClangRenameClassReplacements.cpp -text
+clang-apply-replacements/Inputs/basic/basic.h -text
+clang-apply-replacements/Inputs/format/no.cpp -text
+clang-apply-replacements/Inputs/format/yes.cpp -text
+clang-tidy/infrastructure/export-diagnostics.cpp -text
 
 # These test input files rely on two-byte Windows (CRLF) line endings.
-clang-apply-replacements/Inputs/crlf/crlf.cpp text eol=crlf
-clang-apply-replacements/Inputs/crlf/crlf.cpp.expected text eol=crlf
+clang-apply-replacements/Inputs/crlf/crlf.cpp -text
+clang-apply-replacements/Inputs/crlf/crlf.cpp.expected -text
___

[PATCH] D124525: [OpenMP][ClangLinkerWrapper] Extending linker wrapper to embed metadata for multi-arch fat binaries

2022-04-28 Thread Joseph Huber via Phabricator via cfe-commits

jhuber6 added inline comments.



Comment at: clang/tools/clang-linker-wrapper/OffloadWrapper.cpp:246
   IRBuilder<> Builder(BasicBlock::Create(C, "entry", Func));
+  // Create calls to __tgt_register_image_info for each image
+  auto *NullPtr = llvm::ConstantPointerNull::get(Builder.getInt8PtrTy());

saiislam wrote:
> jhuber6 wrote:
> > I'm wondering if it would be better to create a new `__tgt_bin_desc` and 
> > call a new `__tgt_register_lib` with it here so we don't need multiple 
> > calls here. Inside that new runtime function we could just widen or shrink 
> > the existing structs as needed. That way each device image would have this 
> > metadata associated with it and the target plugin can handle it as-needed.
> Last time multiple vendors objected to changing `__tgt_bin_desc` and 
> `__tgt_device_image` structs. The reason was backward compatibility of 
> multiple downstream runtimes.
If you keep the old `__tgt_register_lib` function, old applications will use 
that. Then inside libomptarget you can change `__tgt_register_lib` function to 
create a new `__tgt_device_image` from the old format. It would have some time 
penalty as we'd need to allocate some new structs, but it might be easier to 
deal with if each image contained its own metadata for the plugin to use. I was 
imagining it would look something like
```
struct __tgt_device_image_v2 {
  void* ImageStart;
  void* ImageEnd;
  __tgt_offload_entry*  EntriesBegin;
  __tgt_offload_entry*  EntriesEnd;
  __tgt_image_into *  ImageInfo;
};
```

Not sure if this is the best approach, but it should let us keep backwards 
compatibility and change the structs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124525

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

[clang-tools-extra] b1f1688 - [clang-tidy] support --load in clang-tidy-diff.py/run-clang-tidy.py

2022-04-28 Thread via cfe-commits


Author: Bernhard Manfred Gruber
Date: 2022-04-28T13:49:18+02:00
New Revision: b1f1688e90b22dedc829f5abc9a912f18c034fbc

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

LOG: [clang-tidy] support --load in clang-tidy-diff.py/run-clang-tidy.py

Support for loading shared objects as plugins into clang-tidy was added
in http://reviews.llvm.org/D00. Unfortunately, the utility scripts
`clang-tidy-diff.py` and `run-clang-tidy.py` did not receive
corresponding arguments to forward such plugins to clang-tidy.
This diff adds a `-load=plugin` option to both scripts.

Differential Revision: http://reviews.llvm.org/D12306

Reviewed By: aaron.ballman

Added: 


Modified: 
clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
clang-tools-extra/clang-tidy/tool/run-clang-tidy.py

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/tool/clang-tidy-
diff .py b/clang-tools-extra/clang-tidy/tool/clang-tidy-
diff .py
index 6bd05531333ba..a26d2144b7f97 100755
--- a/clang-tools-extra/clang-tidy/tool/clang-tidy-
diff .py
+++ b/clang-tools-extra/clang-tidy/tool/clang-tidy-
diff .py
@@ -160,6 +160,10 @@ def main():
   'command line.')
   parser.add_argument('-quiet', action='store_true', default=False,
   help='Run clang-tidy in quiet mode')
+  parser.add_argument('-load', dest='plugins',
+  action='append', default=[],
+  help='Load the specified plugin in clang-tidy.')
+
   clang_tidy_args = []
   argv = sys.argv[1:]
   if '--' in argv:
@@ -233,6 +237,8 @@ def main():
 common_clang_tidy_args.append('-extra-arg=%s' % arg)
   for arg in args.extra_arg_before:
 common_clang_tidy_args.append('-extra-arg-before=%s' % arg)
+  for plugin in args.plugins:
+common_clang_tidy_args.append('-load=%s' % plugin)
 
   for name in lines_by_file:
 line_filter_json = json.dumps(

diff  --git a/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py 
b/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
index 9497e0b9f52d3..fdfe5a07bc551 100755
--- a/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
+++ b/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
@@ -92,7 +92,7 @@ def make_absolute(f, directory):
 def get_tidy_invocation(f, clang_tidy_binary, checks, tmpdir, build_path,
 header_filter, allow_enabling_alpha_checkers,
 extra_arg, extra_arg_before, quiet, config_file_path,
-config, line_filter, use_color):
+config, line_filter, use_color, plugins):
   """Gets a command line for clang-tidy."""
   start = [clang_tidy_binary]
   if allow_enabling_alpha_checkers:
@@ -126,6 +126,8 @@ def get_tidy_invocation(f, clang_tidy_binary, checks, 
tmpdir, build_path,
   start.append('--config-file=' + config_file_path)
   elif config:
   start.append('-config=' + config)
+  for plugin in plugins:
+  start.append('-load=' + plugin)
   start.append(f)
   return start
 
@@ -196,7 +198,8 @@ def run_tidy(args, clang_tidy_binary, tmpdir, build_path, 
queue, lock,
  args.allow_enabling_alpha_checkers,
  args.extra_arg, args.extra_arg_before,
  args.quiet, args.config_file, args.config,
- args.line_filter, args.use_color)
+ args.line_filter, args.use_color,
+ args.plugins)
 
 proc = subprocess.Popen(invocation, stdout=subprocess.PIPE, 
stderr=subprocess.PIPE)
 output, err = proc.communicate()
@@ -280,6 +283,9 @@ def main():
   'command line.')
   parser.add_argument('-quiet', action='store_true',
   help='Run clang-tidy in quiet mode')
+  parser.add_argument('-load', dest='plugins',
+  action='append', default=[],
+  help='Load the specified plugin in clang-tidy.')
   args = parser.parse_args()
 
   db_path = 'compile_commands.json'
@@ -306,7 +312,8 @@ def main():
  args.allow_enabling_alpha_checkers,
  args.extra_arg, args.extra_arg_before,
  args.quiet, args.config_file, args.config,
- args.line_filter, args.use_color)
+ args.line_filter, args.use_color,
+ args.plugins)
 invocation.append('-list-checks')
 invocation.append('-')
 if args.quiet:



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

[PATCH] D123065: [clang-tidy] support --load in clang-tidy-diff.py/run-clang-tidy.py

2022-04-28 Thread Whisperity via Phabricator via cfe-commits

whisperity added a comment.

D'oh! I made a mistake when copying the URL and accidentally associated the 
commit with D12306  instead of D123065 
... Anyhow, this was committed in 
rGb1f1688e90b22dedc829f5abc9a912f18c034fbc 
.


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

https://reviews.llvm.org/D123065

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

[PATCH] D124551: [Driver] Add f16 support to -mrecip parsing.

2022-04-28 Thread Sanjay Patel via Phabricator via cfe-commits

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

LGTM.

AFAIK, these FP reciprocal options have never been officially documented. Would 
that go under here:
https://clang.llvm.org/docs/UsersManual.html#controlling-code-generation ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124551

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

[PATCH] D124382: [Clang] Recognize target address space in superset calculation

2022-04-28 Thread Jakub Chlanda via Phabricator via cfe-commits

jchlanda added a comment.

In D124382#3472888 , @Anastasia wrote:

> 

> Can you provide an example of where it could be useful? Note that I feel that
> such functionality could be implemented on top of full implementation of
> target specific address space proposed in https://reviews.llvm.org/D62574.

The use case we had was when calling target builtin (that specifies address
space) from within OpenCL C. Currently this errors out, similarly, the explicit
type cast to address space yields an error
(`(__attribute__((address_space(3))) int *)&l_woof` in the example below). This
is important for libclc, which is implemented in OpenCL C and deals directly
with target builtins.

  __kernel void woof() {
__local int l_woof;
__nvvm_cp_async_mbarrier_arrive_shared(&l_woof);
  }

I wasn't aware of that patch, sorry, I've not had a close look yet, but it
seems worryingly dated.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124382

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

[PATCH] D124563: Drop '* text=auto' from .gitattributes and normalize

2022-04-28 Thread Aaron Puchert via Phabricator via cfe-commits

aaronpuchert added a comment.

In D124563#3479373 , @nikic wrote:

> This change seems to have broken switching to a branch before the commit 
> completely. The only way I was able to recover my git checkout is to comment 
> out the `* text=auto` line and then run `git reset --hard`, otherwise the 
> crlf.cpp files always show up as changed.

We discussed this previously, there is no way to fix that now. We should have 
normalized in the same change that added the `.gitattributes`. Any checkout 
between those two changes will now show bogus modified files. Sometimes it 
happens to work out because Git apparently looks at file time stamps before 
checking the contents, so it doesn't see an issue with those files. But if you 
`touch` them they will again show up as modified.

In D124563#3479405 , @MForster wrote:

> It also seems weird to me that a file that relies on CRLF line endings is 
> checked in explicitly with LF line endings. A better approach IMHO would be 
> to check it in as binary.

These are all text files though, not binaries. Checking it in as binary will 
not show any diffs.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124563

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

[PATCH] D111548: [Clang] Add the `annotate_type` attribute

2022-04-28 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added inline comments.



Comment at: clang/lib/Parse/ParseDecl.cpp:3184
+continue;
+  // We reject AT_LifetimeBound and AT_AnyX86NoCfCheck, even though 
they
+  // are type attributes, because we historically haven't allowed these

mboehme wrote:
> aaron.ballman wrote:
> > I think this is a FIXME situation -- our policy is to diagnose attributes 
> > that are being ignored, and it seems pretty important to (someday, not part 
> > of this patch) diagnose these. Especially the lifetime bound attribute 
> > given that it's intended to help harden code.
> Maybe I should clarify what's happening here: We _do_ produce diagnostics 
> (errors) for AT_LifetimeBound and AT_AnyX86NoCfCheck, both before and after 
> this patch. (For these attributes, the code falls through to the 
> `Diag(PA.getLoc(), diag::err_attribute_not_type_attr)` call below.)
> 
> Before this patch, we would reject (produce errors for) _all_ C++11 
> attributes here. Now, we only reject non-type attributes, and in addition, we 
> also reject AT_LifetimeBound and AT_AnyX86NoCfCheck (even though they are 
> type attributes) because we historically haven't allowed them to be used in 
> this way. There are tests for this behavior, so it seemed important to 
> preserve it.
Oh derp, that's my mistake, I read the `!=` logic wrong. Thank you for the 
clarification!



Comment at: clang/test/SemaCXX/annotate-type.cpp:2
+// RUN: %clang_cc1 %s -std=c++17 -fsyntax-only -verify
+
+struct S1 {

mboehme wrote:
> aaron.ballman wrote:
> > mboehme wrote:
> > > aaron.ballman wrote:
> > > > Can you also add some test coverage for applying the attribute to a 
> > > > declaration instead of a type or not giving it any arguments? Also, 
> > > > should test arguments which are not a constant expression.
> > > I've added tests as you suggested, though I put most of them in 
> > > Sema/annotate-type.c, as they're not specific to C++.
> > > 
> > > Thanks for prompting me to do this -- the tests caused me to notice and 
> > > fix a number of bugs.
> > > 
> > > I haven't managed to diagnose the case when the attribute appears at the 
> > > beginning of the declaration. It seems to me that, at the point where 
> > > I've added the check, this case is indistinguishable from an attribute 
> > > that appears on the type. In both cases, the `TAL` is `TAL_DeclSpec`, and 
> > > the attribute is contained in `DeclSpec::getAttributes()`. This is 
> > > because `Parser::ParseSimpleDeclaration` forwards the declaration 
> > > attributes to the `DeclSpec`:
> > > 
> > > https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/ParseDecl.cpp#L1851
> > > 
> > > I believe if I wanted to prohibit this case, I would need to add a check 
> > > to `Parser::ParseStatementOrDeclaration` and prohibit any occurrences of 
> > > `annotate_type` there. However, this seems the wrong place to do this 
> > > because it doesn't contain any specific processing for other attributes.
> > > 
> > > I've noticed that Clang also doesn't prohibit other type attributes (even 
> > > ones with C++ 11 syntax) from being applied to declarations. For example: 
> > > https://godbolt.org/z/Yj1zWY7nn
> > > 
> > > How do you think I should proceed here? I think the underlying issue is 
> > > that Clang doesn't always distinguish cleanly between declaration 
> > > attributes and type attributes, and fixing this might be nontrivial.
> > > How do you think I should proceed here? I think the underlying issue is 
> > > that Clang doesn't always distinguish cleanly between declaration 
> > > attributes and type attributes, and fixing this might be nontrivial.
> > 
> > This is a general issue with attribute processing. I would imagine that 
> > SemaDeclAttr.cpp should be able to diagnose that case when the attribute 
> > only applies to types and not declarations, but it'd take some 
> > investigation for me to be sure.
> > 
> > Because this issue isn't new to your situation, I'd recommend filing an 
> > issue about the general problem and then we can solve that later.
> I've done some more investigation myself, and I think I've come up with a 
> solution; actually, two potential solutions. I have draft patches for both of 
> these; I wanted to run these by you here first, so I haven't opened a bug yet.
> 
> I'd appreciate your input on how you'd prefer me to proceed with this. I do 
> think it makes sense to do this work now because otherwise, people will start 
> putting `annotate_type` in places where it doesn't belong, and then we'll 
> have to keep supporting that in the future.
> 
> **My preferred solution**
> 
> https://reviews.llvm.org/D124081
> 
> This adds a function `DiagnoseCXX11NonDeclAttrs()` and calls it in all places 
> where we should reject attributes that can't be put on declarations. (As part 
> of this work, I noticed that `gsl::suppress` should be a `DeclOrStmtAttr`, 
> not just a `StmtAttr`.)
>

[PATCH] D124606: Use `binary` git attribute instead of `text eol=...'

2022-04-28 Thread Ilya Biryukov via Phabricator via cfe-commits

ilya-biryukov added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124606

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

[PATCH] D124606: Use `binary` git attribute instead of `text eol=...'

2022-04-28 Thread Ilya Biryukov via Phabricator via cfe-commits

ilya-biryukov added a comment.

NIT: change the commit message to say `-text` instead of `binary`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124606

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

[PATCH] D124563: Drop '* text=auto' from .gitattributes and normalize

2022-04-28 Thread Aaron Puchert via Phabricator via cfe-commits

aaronpuchert added a comment.

As a temporary workaround for switching between branches, just add a local file 
`clang-tools-extra/test/clang-apply-replacements/.gitattributes` with contents:

  Inputs/crlf/crlf.cpp binary
  Inputs/crlf/crlf.cpp.expected binary

This will remove all kinds of filtering for the moment. When you remove that 
file, just make sure to force checkout both files again to make sure the filter 
applies.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124563

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

[clang-tools-extra] 4aba5fa - Use `-text` git attribute instead of `text eol=...`

2022-04-28 Thread Michael Forster via cfe-commits


Author: Michael Forster
Date: 2022-04-28T14:27:29+02:00
New Revision: 4aba5fa774821279c2e2e26dd6ed6e1c6a151044

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

LOG: Use `-text` git attribute instead of `text eol=...`

These automatic conversions lead to issues in various workflows, and all
we want here are files that retain their line endings under all
circumstances. `-text` captures that perfectly well and leads to fewer
issues.

It is preferable to `binary`, because with `-text` we still get textual
diffs.

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

Added: 


Modified: 
clang-tools-extra/test/.gitattributes
clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp

clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected

Removed: 




diff  --git a/clang-tools-extra/test/.gitattributes 
b/clang-tools-extra/test/.gitattributes
index 42567e3196d61..3d4df1e9976bc 100644
--- a/clang-tools-extra/test/.gitattributes
+++ b/clang-tools-extra/test/.gitattributes
@@ -4,12 +4,12 @@
 
 # These test input files rely on one-byte Unix (LF) line-endings, as they use
 # fixed -offset, FileOffset:, or Offset: numbers in their tests.
-clang-apply-replacements/ClangRenameClassReplacements.cpp text eol=lf
-clang-apply-replacements/Inputs/basic/basic.h text eol=lf
-clang-apply-replacements/Inputs/format/no.cpp text eol=lf
-clang-apply-replacements/Inputs/format/yes.cpp text eol=lf
-clang-tidy/infrastructure/export-diagnostics.cpp text eol=lf
+clang-apply-replacements/ClangRenameClassReplacements.cpp -text
+clang-apply-replacements/Inputs/basic/basic.h -text
+clang-apply-replacements/Inputs/format/no.cpp -text
+clang-apply-replacements/Inputs/format/yes.cpp -text
+clang-tidy/infrastructure/export-diagnostics.cpp -text
 
 # These test input files rely on two-byte Windows (CRLF) line endings.
-clang-apply-replacements/Inputs/crlf/crlf.cpp text eol=crlf
-clang-apply-replacements/Inputs/crlf/crlf.cpp.expected text eol=crlf
+clang-apply-replacements/Inputs/crlf/crlf.cpp -text
+clang-apply-replacements/Inputs/crlf/crlf.cpp.expected -text

diff  --git 
a/clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp 
b/clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
index 09e50c292cc91..26f79968f556d 100644
--- a/clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
+++ b/clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
@@ -1,6 +1,6 @@
-
-// This file intentionally uses a CRLF newlines!
-
-void foo() {
-  int *x = 0;
-}
+
+// This file intentionally uses a CRLF newlines!
+
+void foo() {
+  int *x = 0;
+}

diff  --git 
a/clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected 
b/clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected
index 7a5e11354748d..ad8e907856283 100644
--- 
a/clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected
+++ 
b/clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected
@@ -1,6 +1,6 @@
-
-// This file intentionally uses a CRLF newlines!
-
-void foo() {
-  int *x = nullptr;
-}
+
+// This file intentionally uses a CRLF newlines!
+
+void foo() {
+  int *x = nullptr;
+}



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

[PATCH] D124606: Use `binary` git attribute instead of `text eol=...'

2022-04-28 Thread Michael Forster via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rG4aba5fa77482: Use `-text` git attribute instead of `text 
eol=...` (authored by MForster).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124606

Files:
  clang-tools-extra/test/.gitattributes
  clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
  clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected


Index: 
clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected
===
--- 
clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected
+++ 
clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected
@@ -1,6 +1,6 @@
-
-// This file intentionally uses a CRLF newlines!
-
-void foo() {
-  int *x = nullptr;
-}
+
+// This file intentionally uses a CRLF newlines!
+
+void foo() {
+  int *x = nullptr;
+}
Index: clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
===
--- clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
+++ clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
@@ -1,6 +1,6 @@
-
-// This file intentionally uses a CRLF newlines!
-
-void foo() {
-  int *x = 0;
-}
+
+// This file intentionally uses a CRLF newlines!
+
+void foo() {
+  int *x = 0;
+}
Index: clang-tools-extra/test/.gitattributes
===
--- clang-tools-extra/test/.gitattributes
+++ clang-tools-extra/test/.gitattributes
@@ -4,12 +4,12 @@
 
 # These test input files rely on one-byte Unix (LF) line-endings, as they use
 # fixed -offset, FileOffset:, or Offset: numbers in their tests.
-clang-apply-replacements/ClangRenameClassReplacements.cpp text eol=lf
-clang-apply-replacements/Inputs/basic/basic.h text eol=lf
-clang-apply-replacements/Inputs/format/no.cpp text eol=lf
-clang-apply-replacements/Inputs/format/yes.cpp text eol=lf
-clang-tidy/infrastructure/export-diagnostics.cpp text eol=lf
+clang-apply-replacements/ClangRenameClassReplacements.cpp -text
+clang-apply-replacements/Inputs/basic/basic.h -text
+clang-apply-replacements/Inputs/format/no.cpp -text
+clang-apply-replacements/Inputs/format/yes.cpp -text
+clang-tidy/infrastructure/export-diagnostics.cpp -text
 
 # These test input files rely on two-byte Windows (CRLF) line endings.
-clang-apply-replacements/Inputs/crlf/crlf.cpp text eol=crlf
-clang-apply-replacements/Inputs/crlf/crlf.cpp.expected text eol=crlf
+clang-apply-replacements/Inputs/crlf/crlf.cpp -text
+clang-apply-replacements/Inputs/crlf/crlf.cpp.expected -text


Index: clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected
===
--- clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected
+++ clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp.expected
@@ -1,6 +1,6 @@
-
-// This file intentionally uses a CRLF newlines!
-
-void foo() {
-  int *x = nullptr;
-}
+
+// This file intentionally uses a CRLF newlines!
+
+void foo() {
+  int *x = nullptr;
+}
Index: clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
===
--- clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
+++ clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp
@@ -1,6 +1,6 @@
-
-// This file intentionally uses a CRLF newlines!
-
-void foo() {
-  int *x = 0;
-}
+
+// This file intentionally uses a CRLF newlines!
+
+void foo() {
+  int *x = 0;
+}
Index: clang-tools-extra/test/.gitattributes
===
--- clang-tools-extra/test/.gitattributes
+++ clang-tools-extra/test/.gitattributes
@@ -4,12 +4,12 @@
 
 # These test input files rely on one-byte Unix (LF) line-endings, as they use
 # fixed -offset, FileOffset:, or Offset: numbers in their tests.
-clang-apply-replacements/ClangRenameClassReplacements.cpp text eol=lf
-clang-apply-replacements/Inputs/basic/basic.h text eol=lf
-clang-apply-replacements/Inputs/format/no.cpp text eol=lf
-clang-apply-replacements/Inputs/format/yes.cpp text eol=lf
-clang-tidy/infrastructure/export-diagnostics.cpp text eol=lf
+clang-apply-replacements/ClangRenameClassReplacements.cpp -text
+clang-apply-replacements/Inputs/basic/basic.h -text
+clang-apply-replacements/Inputs/format/no.cpp -text
+clang-apply-replacements/Inputs/format/yes.cpp -text
+clang-tidy/infrastructure/export-diagnostics.cpp -text
 
 # These test input files rely on two-byte Windows (CRLF) line endings.
-clang-apply-replacements/Inputs/crlf/crlf.cpp text eol=crlf
-clang-apply-replacements/Inputs/crlf/crlf.cpp.expected text eol=crlf
+clang-apply-replacements/Inputs/crlf/crlf.cpp

[PATCH] D124606: Use `binary` git attribute instead of `text eol=...'

2022-04-28 Thread Michael Forster via Phabricator via cfe-commits

MForster added a comment.

In D124606#3479798 , @ilya-biryukov 
wrote:

> NIT: change the commit message to say `-text` instead of `binary`

Ah, sorry, saw this too late...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124606

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

[PATCH] D124606: Use `-text` git attribute instead of `text eol=...'

2022-04-28 Thread Michael Forster via Phabricator via cfe-commits

MForster added a comment.

In D124606#3479805 , @MForster wrote:

> In D124606#3479798 , @ilya-biryukov 
> wrote:
>
>> NIT: change the commit message to say `-text` instead of `binary`
>
> Ah, sorry, saw this too late...

Turns out I had already renamed the commit :-). I also updated the code review 
title...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124606

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

[clang-tools-extra] 5e4a77f - [clangd] Record latency for ASTSignal derivation

2022-04-28 Thread Kadir Cetinkaya via cfe-commits


Author: Kadir Cetinkaya
Date: 2022-04-28T14:34:39+02:00
New Revision: 5e4a77f0c4e7e8122e8ee3a15fff0971f5db2244

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

LOG: [clangd] Record latency for ASTSignal derivation

Added: 


Modified: 
clang-tools-extra/clangd/ASTSignals.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/ASTSignals.cpp 
b/clang-tools-extra/clangd/ASTSignals.cpp
index 58c57e147d41..8476641391b9 100644
--- a/clang-tools-extra/clangd/ASTSignals.cpp
+++ b/clang-tools-extra/clangd/ASTSignals.cpp
@@ -9,10 +9,12 @@
 #include "ASTSignals.h"
 #include "AST.h"
 #include "FindTarget.h"
+#include "support/Trace.h"
 
 namespace clang {
 namespace clangd {
 ASTSignals ASTSignals::derive(const ParsedAST &AST) {
+  trace::Span Span("ASTSignals::derive");
   ASTSignals Signals;
   const SourceManager &SM = AST.getSourceManager();
   findExplicitReferences(



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

[PATCH] D124563: Drop '* text=auto' from .gitattributes and normalize

2022-04-28 Thread Michael Forster via Phabricator via cfe-commits

MForster added a comment.

> In D124563#3479405 , @MForster 
> wrote:
>
>> It also seems weird to me that a file that relies on CRLF line endings is 
>> checked in explicitly with LF line endings. A better approach IMHO would be 
>> to check it in as binary.
>
> These are all text files though, not binaries. Checking it in as binary will 
> not show any diffs.

See D124606 . `-text` seems to be the right 
compromise.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124563

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

[PATCH] D124434: [Clang][Test] Run tests in C++14 mode explicitly.

2022-04-28 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

In D124434#3479051 , @junaire wrote:

>> In general, my concern with the this patch is that it loses test coverage by 
>> specifying an explicit language mode. We typically prefer to fix the tests 
>> so that they can work in any language mode (and perhaps add additional RUN 
>> lines in the process to do so).
>
> OK, I'll do this. But I guess it is not sort of trivial work and will take 
> plenty of time.

Oh, please do not feel obligated to do that work yourself! Not only is it 
nontrivial and likely to take a fair amount of effort, I'm not even certain if 
other people think it's a good idea or not. I see this more as a start of a 
discussion as to how we want to handle this. I think when C and C++ were on 10+ 
year release cycles, this model was a bit more palatable, but now that the 
releases are shorter (every 3 yrs for C++ at the least) and there's more 
interplay between them (extensions ported to older language modes, etc) we 
might want something different.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124434

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

[PATCH] D118996: [clang-tidy] Support C++14 in bugprone-signal-handler.

2022-04-28 Thread Balázs Kéri via Phabricator via cfe-commits

balazske updated this revision to Diff 425753.
balazske added a comment.

Applied the review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118996

Files:
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-signal-handler.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-msc54-cpp.rst
  clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/signal.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/bugprone-signal-handler/stdcpp.h
  clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c
  clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.cpp
@@ -0,0 +1,228 @@
+// RUN: %check_clang_tidy -std=c++14 %s bugprone-signal-handler %t -- -- -isystem %S/Inputs/Headers -isystem %S/Inputs/bugprone-signal-handler
+
+#include "stdcpp.h"
+#include "stdio.h"
+
+// Functions called "signal" that are different from the system version.
+typedef void (*callback_t)(int);
+void signal(int, callback_t, int);
+namespace ns {
+void signal(int, callback_t);
+}
+
+extern "C" void handler_unsafe(int) {
+  printf("xxx");
+}
+
+extern "C" void handler_unsafe_1(int) {
+  printf("xxx");
+}
+
+namespace test_invalid_handler {
+
+void handler_non_extern_c(int) {
+  printf("xxx");
+}
+
+struct A {
+  static void handler_member(int) {
+printf("xxx");
+  }
+};
+
+void test() {
+  std::signal(SIGINT, handler_unsafe_1);
+  // CHECK-MESSAGES: :[[@LINE-17]]:3: warning: standard function 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-MESSAGES: :[[@LINE-2]]:23: note: function 'handler_unsafe_1' registered here as signal handler
+
+  std::signal(SIGINT, handler_non_extern_c);
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: functions without C linkage are not allowed as signal handler (until C++17) [bugprone-signal-handler]
+  std::signal(SIGINT, A::handler_member);
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: functions without C linkage are not allowed as signal handler (until C++17) [bugprone-signal-handler]
+  std::signal(SIGINT, [](int) { printf("xxx"); });
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: lambda function is not allowed as signal handler (until C++17) [bugprone-signal-handler]
+
+  // This case is (deliberately) not found by the checker.
+  std::signal(SIGINT, [](int) -> callback_t { return &handler_unsafe; }(1));
+}
+
+} // namespace test_invalid_handler
+
+namespace test_non_standard_signal_call {
+
+struct Signal {
+  static void signal(int, callback_t);
+};
+
+void test() {
+  // No diagnostics here. All these signal calls differ from the standard system one.
+  signal(SIGINT, handler_unsafe, 1);
+  ns::signal(SIGINT, handler_unsafe);
+  Signal::signal(SIGINT, handler_unsafe);
+  system_other::signal(SIGINT, handler_unsafe);
+}
+
+} // namespace test_non_standard_signal_call
+
+namespace test_cpp_construct_in_handler {
+
+struct Struct {
+  virtual ~Struct() {}
+  void f1();
+  int *begin();
+  int *end();
+  static void f2();
+};
+struct Derived : public Struct {
+};
+
+struct X {
+  X(int, float);
+};
+
+Struct *S_Global;
+const Struct *S_GlobalConst;
+
+void f_non_extern_c() {
+}
+
+void f_default_arg(int P1 = 0) {
+}
+
+extern "C" void handler_cpp(int) {
+  using namespace ::test_cpp_construct_in_handler;
+
+  // These calls are not found as problems.
+  // (Called functions are not analyzed if the current function has already
+  // other problems.)
+  f_non_extern_c();
+  Struct::f2();
+  // 'auto' is not disallowed
+  auto Auto = 28u;
+
+  Struct S;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: C++-only construct is not allowed in signal handler (until C++17) [bugprone-signal-handler]
+  // CHECK-MESSAGES: :[[@LINE-2]]:10: remark: internally, the statement is parsed as a 'CXXConstructExpr'
+  // CHECK-MESSAGES: :198:23: note: function 'handler_cpp' registered here as signal handler
+  S_Global->f1();
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: C++-only construct is not allowed in signal handler (until C++17) [bugprone-signal-handler]
+  // CHECK-MESSAGES: :[[@LINE-2]]:3: remark: internally, the statement is parsed as a 'CXXMemberCallExpr'
+  // CHECK-MESSAGES: :198:23: note: function 'handler_cpp' registered here as signal handler
+  const Struct &SRef = Struct();
+  // CHECK-MESSAGES: :[[@LINE-1]]:24: warning: C++-only construct is not allowed in signal handler (until C++17) [bugprone-signal-handler]
+  // CHECK-MESSAGES: :[[@LINE-2]]:24: remark: in

[PATCH] D124556: [NFC] Prevent shadowing a variable declared in `if`

2022-04-28 Thread Ken Matsui via Phabricator via cfe-commits

ken-matsui added a comment.

@hubert.reinterpretcast,

Sorry to have missed providing a summary.

In most cases, shadowing a declaration of a local variable should be avoided to 
prevent making others confused and mistakes because we need to figure out the 
boundaries of the declaration. In this case, the variable declared by `const 
char *S` in `if` can be accessed by every branch. That means that declarations 
in `else if` had shadowed the declaration in `if`, so I changed them to use the 
same declaration used in `if`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124556

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

[PATCH] D124487: [HLSL] Adjust access specifier behavior

2022-04-28 Thread Aaron Ballman via Phabricator via cfe-commits

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

LGTM aside from whitespace changes.




Comment at: 
clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp:1
-
-// This file intentionally uses a CRLF newlines!
-
-void foo() {
-  int *x = 0;
-}
+
+// This file intentionally uses a CRLF newlines!

It looks like these are unintentional whitespace changes? (Same below)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124487

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

[clang] f2b31f0 - re-roll-forward "[clang] Mark `trivial_abi` types as "trivially relocatable"".""

2022-04-28 Thread Dmitri Gribenko via cfe-commits


Author: Devin Jeanpierre
Date: 2022-04-28T14:53:59+02:00
New Revision: f2b31f06b79a6cfb7eb3146dfc1d514da52142e9

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

LOG: re-roll-forward "[clang] Mark `trivial_abi` types as "trivially 
relocatable"".""

This reverts commit b0bc93da926a943cdc2d8b04f8dcbe23a774520c.

Changes: `s/_WIN32/_WIN64/g` in clang/test/SemaCXX/attr-trivial-abi.cpp.

The calling convention is specific to 64-bit windows. It's even in the name: 
`CCK_MicrosoftWin64`.

After this, the test passes with both `-triple i686-pc-win32` and `-triple 
x86_64-pc-win32`. Phew!

Reviewed By: gribozavr2

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

Added: 


Modified: 
clang/docs/LanguageExtensions.rst
clang/include/clang/AST/Type.h
clang/include/clang/Basic/AttrDocs.td
clang/include/clang/Basic/TokenKinds.def
clang/lib/AST/Type.cpp
clang/lib/Sema/SemaExprCXX.cpp
clang/test/SemaCXX/attr-trivial-abi.cpp
clang/test/SemaCXX/type-traits.cpp
clang/test/SemaObjCXX/arc-type-traits.mm
clang/test/SemaObjCXX/objc-weak-type-traits.mm

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index 0391102fb222c..fbc881a724bb2 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -1434,6 +1434,11 @@ The following type trait primitives are supported by 
Clang. Those traits marked
 * ``__is_trivially_constructible`` (C++, GNU, Microsoft)
 * ``__is_trivially_copyable`` (C++, GNU, Microsoft)
 * ``__is_trivially_destructible`` (C++, MSVC 2013)
+* ``__is_trivially_relocatable`` (Clang): Returns true if moving an object
+  of the given type, and then destroying the source object, is known to be
+  functionally equivalent to copying the underlying bytes and then dropping the
+  source object on the floor. This is true of trivial types and types which
+  were made trivially relocatable via the ``clang::trivial_abi`` attribute.
 * ``__is_union`` (C++, GNU, Microsoft, Embarcadero)
 * ``__is_unsigned`` (C++, Embarcadero):
   Returns false for enumeration types. Note, before Clang 13, returned true for

diff  --git a/clang/include/clang/AST/Type.h b/clang/include/clang/AST/Type.h
index 1a8549bedb4f9..45b75fe7960c3 100644
--- a/clang/include/clang/AST/Type.h
+++ b/clang/include/clang/AST/Type.h
@@ -830,6 +830,8 @@ class QualType {
   /// Return true if this is a trivially copyable type (C++0x [basic.types]p9)
   bool isTriviallyCopyableType(const ASTContext &Context) const;
 
+  /// Return true if this is a trivially relocatable type.
+  bool isTriviallyRelocatableType(const ASTContext &Context) const;
 
   /// Returns true if it is a class and it might be dynamic.
   bool mayBeDynamicClass() const;

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 00d6b035ff3cf..02b6031fd5aa5 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -,6 +,9 @@ If a type is trivial for the purposes of calls, has a 
non-trivial destructor,
 and is passed as an argument by value, the convention is that the callee will
 destroy the object before returning.
 
+If a type is trivial for the purpose of calls, it is assumed to be trivially
+relocatable for the purpose of ``__is_trivially_relocatable``.
+
 Attribute ``trivial_abi`` has no effect in the following cases:
 
 - The class directly declares a virtual base or virtual methods.

diff  --git a/clang/include/clang/Basic/TokenKinds.def 
b/clang/include/clang/Basic/TokenKinds.def
index 5092780d8f60f..093389615c263 100644
--- a/clang/include/clang/Basic/TokenKinds.def
+++ b/clang/include/clang/Basic/TokenKinds.def
@@ -511,6 +511,7 @@ TYPE_TRAIT_1(__has_unique_object_representations,
 KEYWORD(__underlying_type   , KEYCXX)
 
 // Clang-only C++ Type Traits
+TYPE_TRAIT_1(__is_trivially_relocatable, IsTriviallyRelocatable, KEYCXX)
 TYPE_TRAIT_2(__reference_binds_to_temporary, ReferenceBindsToTemporary, KEYCXX)
 
 // Embarcadero Expression Traits

diff  --git a/clang/lib/AST/Type.cpp b/clang/lib/AST/Type.cpp
index bb9900ea6eea4..92450e8f5f2f5 100644
--- a/clang/lib/AST/Type.cpp
+++ b/clang/lib/AST/Type.cpp
@@ -2505,6 +2505,25 @@ bool QualType::isTriviallyCopyableType(const ASTContext 
&Context) const {
   return false;
 }
 
+bool QualType::isTriviallyRelocatableType(const ASTContext &Context) const {
+  QualType BaseElementType = Context.getBaseElementType(*this);
+
+  if (BaseElementType->isIncompleteType()) {
+return false;
+  } else if (const auto *RD = BaseElementType->getAsRecordDecl()) {
+return RD->canPassInRegisters();
+  } else {
+switch (isNonTrivialToPrimitiveDestructiveMove()) {
+case PCK_Trivial:
+  return !isDestructedT

[PATCH] D123059: re-roll-forward "[clang] Mark `trivial_abi` types as "trivially relocatable"".""

2022-04-28 Thread Dmitri Gribenko via Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rGf2b31f06b79a: re-roll-forward "[clang] Mark 
`trivial_abi` types as "trivially relocatable""."" 
(authored by devin.jeanpierre, committed by gribozavr).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123059

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/TokenKinds.def
  clang/lib/AST/Type.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/test/SemaCXX/attr-trivial-abi.cpp
  clang/test/SemaCXX/type-traits.cpp
  clang/test/SemaObjCXX/arc-type-traits.mm
  clang/test/SemaObjCXX/objc-weak-type-traits.mm

Index: clang/test/SemaObjCXX/objc-weak-type-traits.mm
===
--- clang/test/SemaObjCXX/objc-weak-type-traits.mm
+++ clang/test/SemaObjCXX/objc-weak-type-traits.mm
@@ -8,7 +8,7 @@
 #define TRAIT_IS_FALSE(Trait, Type) static_assert(!Trait(Type), "")
 #define TRAIT_IS_TRUE_2(Trait, Type1, Type2) static_assert(Trait(Type1, Type2), "")
 #define TRAIT_IS_FALSE_2(Trait, Type1, Type2) static_assert(!Trait(Type1, Type2), "")
-  
+
 struct HasStrong { id obj; };
 struct HasWeak { __weak id obj; };
 struct HasUnsafeUnretained { __unsafe_unretained id obj; };
@@ -208,3 +208,12 @@
 TRAIT_IS_FALSE_2(__is_trivially_constructible, HasWeak, HasWeak&&);
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained);
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained&&);
+
+// __is_trivially_relocatable
+TRAIT_IS_TRUE(__is_trivially_relocatable, __strong id);
+TRAIT_IS_FALSE(__is_trivially_relocatable, __weak id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __autoreleasing id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __unsafe_unretained id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasStrong);
+TRAIT_IS_FALSE(__is_trivially_relocatable, HasWeak);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasUnsafeUnretained);
Index: clang/test/SemaObjCXX/arc-type-traits.mm
===
--- clang/test/SemaObjCXX/arc-type-traits.mm
+++ clang/test/SemaObjCXX/arc-type-traits.mm
@@ -12,7 +12,7 @@
 #define TRAIT_IS_FALSE(Trait, Type) char JOIN2(Trait,__LINE__)[Trait(Type)? -1 : 1]
 #define TRAIT_IS_TRUE_2(Trait, Type1, Type2) char JOIN2(Trait,__LINE__)[Trait(Type1, Type2)? 1 : -1]
 #define TRAIT_IS_FALSE_2(Trait, Type1, Type2) char JOIN2(Trait,__LINE__)[Trait(Type1, Type2)? -1 : 1]
-  
+
 struct HasStrong { id obj; };
 struct HasWeak { __weak id obj; };
 struct HasUnsafeUnretained { __unsafe_unretained id obj; };
@@ -213,3 +213,11 @@
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained);
 TRAIT_IS_TRUE_2(__is_trivially_constructible, HasUnsafeUnretained, HasUnsafeUnretained&&);
 
+// __is_trivially_relocatable
+TRAIT_IS_TRUE(__is_trivially_relocatable, __strong id);
+TRAIT_IS_FALSE(__is_trivially_relocatable, __weak id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __autoreleasing id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, __unsafe_unretained id);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasStrong);
+TRAIT_IS_FALSE(__is_trivially_relocatable, HasWeak);
+TRAIT_IS_TRUE(__is_trivially_relocatable, HasUnsafeUnretained);
Index: clang/test/SemaCXX/type-traits.cpp
===
--- clang/test/SemaCXX/type-traits.cpp
+++ clang/test/SemaCXX/type-traits.cpp
@@ -2854,3 +2854,64 @@
 #undef T16384
 #undef T32768
 } // namespace type_trait_expr_numargs_overflow
+
+namespace is_trivially_relocatable {
+
+static_assert(!__is_trivially_relocatable(void), "");
+static_assert(__is_trivially_relocatable(int), "");
+static_assert(__is_trivially_relocatable(int[]), "");
+
+enum Enum {};
+static_assert(__is_trivially_relocatable(Enum), "");
+static_assert(__is_trivially_relocatable(Enum[]), "");
+
+union Union {int x;};
+static_assert(__is_trivially_relocatable(Union), "");
+static_assert(__is_trivially_relocatable(Union[]), "");
+
+struct Trivial {};
+static_assert(__is_trivially_relocatable(Trivial), "");
+static_assert(__is_trivially_relocatable(Trivial[]), "");
+
+struct Incomplete; // expected-note {{forward declaration of 'is_trivially_relocatable::Incomplete'}}
+bool unused = __is_trivially_relocatable(Incomplete); // expected-error {{incomplete type}}
+
+struct NontrivialDtor {
+  ~NontrivialDtor() {}
+};
+static_assert(!__is_trivially_relocatable(NontrivialDtor), "");
+static_assert(!__is_trivially_relocatable(NontrivialDtor[]), "");
+
+struct NontrivialCopyCtor {
+  NontrivialCopyCtor(const NontrivialCopyCtor&) {}
+};
+static_assert(!__is_trivially_relocatable(NontrivialCopyCtor), "");
+static_assert(!__is_trivially_relocatable(NontrivialCopyCtor[]), "");
+
+struct NontrivialMoveCtor {
+  NontrivialMoveCtor(NontrivialMoveCtor&

[PATCH] D122920: [Clang][CodeGen]Fix __builtin_dump_struct missing record type field name

2022-04-28 Thread Erich Keane via Phabricator via cfe-commits

erichkeane added a comment.

In D122920#3479192 , @yihanaa wrote:

>> While we'd usually be happy to take the fix-in-hand and apply it, part of 
>> the discussion on the other thread is whether to remove 
>> `__builtin_dump_struct` entirely. Because of that, I don't think we should 
>> make substantial changes in this area until it's clear we're keeping the 
>> builtin.
>
> Thanks for take a look, I agree to wait for the outcome of the discussion

I think I disagree with Aaron.  While, YES, we are likely to delete this in the 
near future, it doesn't mean we should leave it in a broken state in the 
meantime.  WHILE all of this is likely to be deleted, it has value until we 
delete it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122920

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

[PATCH] D123605: [Sema][SVE2] Move/simplify Sema testing for SVE2 ACLE builtins

2022-04-28 Thread Rosie Sumpter via Phabricator via cfe-commits

RosieSumpter closed this revision.
RosieSumpter added a comment.

Commit: f7068c82a2560d97bf9826db1e917f931e887017 



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

https://reviews.llvm.org/D123605

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

[PATCH] D123958: [randstruct] Randomize all elements of a record

2022-04-28 Thread Aaron Ballman via Phabricator via cfe-commits

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

LGTM!




Comment at: clang/unittests/AST/RandstructTest.cpp:368
+int h;
+char name[0];
+} __attribute__((randomize_layout));

void wrote:
> aaron.ballman wrote:
> > Can you add a test where the last field is `char name[1];` and another one 
> > for `char name[];` so that we have full coverage there?
> The `name[]` is above this test. The `name[1]` is due to a copy-paste error 
> (oops). Fixed.
Ah, good call on `name[]`, I missed that one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123958

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

[PATCH] D122920: [Clang][CodeGen]Fix __builtin_dump_struct missing record type field name

2022-04-28 Thread Aaron Ballman via Phabricator via cfe-commits

aaron.ballman added a comment.

In D122920#3479884 , @erichkeane 
wrote:

> In D122920#3479192 , @yihanaa wrote:
>
>>> While we'd usually be happy to take the fix-in-hand and apply it, part of 
>>> the discussion on the other thread is whether to remove 
>>> `__builtin_dump_struct` entirely. Because of that, I don't think we should 
>>> make substantial changes in this area until it's clear we're keeping the 
>>> builtin.
>>
>> Thanks for take a look, I agree to wait for the outcome of the discussion
>
> I think I disagree with Aaron.  While, YES, we are likely to delete this in 
> the near future, it doesn't mean we should leave it in a broken state in the 
> meantime.  WHILE all of this is likely to be deleted, it has value until we 
> delete it.

I'm not opposed to moving forward with this check, I just didn't want @yihanaa 
(and reviewers) to spend time working on this if it's going to be removed in 
this release of Clang anyway.




Comment at: clang/test/CodeGen/dump-struct-builtin.c:809
+}
\ No newline at end of file


You should add the newline back to the end of the test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122920

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

[PATCH] D122920: [Clang][CodeGen]Fix __builtin_dump_struct missing record type field name

2022-04-28 Thread Erich Keane via Phabricator via cfe-commits

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

CGBuiltin.cpp changes look good enough to me, but please add the newline aaron 
requested.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122920

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

[PATCH] D124611: [RISCV][Clang] add more tests for clang driver. (NFC)

2022-04-28 Thread Zakk Chen via Phabricator via cfe-commits

khchen created this revision.
khchen added reviewers: craig.topper, asb, luismarques.
Herald added subscribers: sunshaoce, VincentWu, luke957, StephenFan, vkmr, 
frasercrmck, evandro, apazos, sameer.abuasal, s.egerton, Jim, benna, psnobl, 
jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, 
zzheng, jrtc27, kito-cheng, niosHD, sabuasal, simoncook, johnrusso, rbar, 
arichardson.
Herald added a project: All.
khchen requested review of this revision.
Herald added subscribers: cfe-commits, pcwang-thead, eopXD.
Herald added a project: clang.

Test experimental arch, Zfh, Zfmin and Zve arch.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124611

Files:
  clang/test/Driver/riscv-arch.c


Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -412,6 +412,26 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZFHMIN %s
 // RV32-ZFHMIN: "-target-feature" "+zfhmin"
 
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izbt -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-NOFLAG 
%s
+// RV32-EXPERIMENTAL-NOFLAG: error: invalid arch name 'rv32izbt'
+// RV32-EXPERIMENTAL-NOFLAG: requires '-menable-experimental-extensions'
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izbt 
-menable-experimental-extensions -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-NOVERS 
%s
+// RV32-EXPERIMENTAL-NOVERS: error: invalid arch name 'rv32izbt'
+// RV32-EXPERIMENTAL-NOVERS: experimental extension requires explicit version 
number
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izbt0p1 
-menable-experimental-extensions -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-BADVERS 
%s
+// RV32-EXPERIMENTAL-BADVERS: error: invalid arch name 'rv32izbt0p1'
+// RV32-EXPERIMENTAL-BADVERS: unsupported version number 0.1 for experimental 
extension
+// RV32-EXPERIMENTAL-BADVERS: 'zbt'(this compiler supports 0.93)
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izbt0p93 
-menable-experimental-extensions -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck 
-check-prefix=RV32-EXPERIMENTAL-GOODVERS %s
+// RV32-EXPERIMENTAL-GOODVERS: "-target-feature" "+experimental-zbt"
+
 // RUN: %clang --target=riscv32-unknown-elf -march=rv32izbb1p0 -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZBB %s
 // RUN: %clang --target=riscv32-unknown-elf -march=rv32izbb -### %s \
@@ -494,3 +514,28 @@
 // RUN: %clang --target=riscv32-unknown-elf -march=rv32izk1p0 -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZK %s
 // RV32-ZK: "-target-feature" "+zk"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfh1p0 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=CHECK-RV32-ZFH %s
+// CHECK-RV32-ZFH: "-target-feature" "+zfh"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izfhmin1p0 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=CHECK-RV32-ZFHMIN %s
+// CHECK-RV32-ZFHMIN: "-target-feature" "+zfhmin"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izve32x0p1 -### %s -c 
2>&1 | \
+// RUN:   FileCheck -check-prefix=RV32-ZVE-BADVERS %s
+// RV32-ZVE-BADVERS: error: invalid arch name 'rv32izve32x0p1'
+// RV32-ZVE-BADVERS: unsupported version number 0.1 for extension 'zve32x'
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izve32x -### %s -c 2>&1 
| \
+// RUN:   FileCheck -check-prefix=RV32-ZVE-GOODVERS %s
+// RV32-ZVE-GOODVERS: "-target-feature" "+zve32x"
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izve32f -### %s -c 2>&1 
| \
+// RUN:   FileCheck -check-prefix=RV32-ZVE32F-REQUIRE-F %s
+// RV32-ZVE32F-REQUIRE-F: error: invalid arch name 'rv32izve32f', zve32f 
requires f or zfinx extension to also be specified
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32ifzve32f -### %s -c 
2>&1 | \
+// RUN:   FileCheck -check-prefix=RV32-ZVE32F-GOOD %s
+// RV32-ZVE32F-GOOD: "-target-feature" "+zve32f"


Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -412,6 +412,26 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-ZFHMIN %s
 // RV32-ZFHMIN: "-target-feature" "+zfhmin"
 
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izbt -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-NOFLAG %s
+// RV32-EXPERIMENTAL-NOFLAG: error: invalid arch name 'rv32izbt'
+// RV32-EXPERIMENTAL-NOFLAG: requires '-menable-experimental-extensions'
+
+// RUN: %clang --target=riscv32-unknown-elf -march=rv32izbt -menable-experimental-extensions -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-EXPERIMENTAL-NOVERS %s
+// RV32-EXPERIMENTAL-NOVERS: error: invalid arch name 'rv32izbt'
+// RV32-EXPERIMEN

[PATCH] D124563: Drop '* text=auto' from .gitattributes and normalize

2022-04-28 Thread Aaron Puchert via Phabricator via cfe-commits

aaronpuchert added a comment.

In D124563#3479819 , @MForster wrote:

> See D124606 . `-text` seems to be the right 
> compromise.

To quote an earlier comment from this thread:

In D124563#3478625 , @smeenai wrote:

> I *think* this would mean that if you're on Windows and have `core.autocrlf` 
> set to `input`, when you commit changes to this files, Git will convert them 
> back to LF line endings. Not 100% sure of that though.

Which convinced me that D97625  was right: we 
do want the line endings to remain CRLF, and not have them accidentally 
destroyed. With `-text` we say that we don't care, which is not true.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124563

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

[PATCH] D124613: In MSVC compatibility mode, friend function declarations behave as function declarations

2022-04-28 Thread Fred Tingaud via Phabricator via cfe-commits

frederic-tingaud-sonarsource created this revision.
frederic-tingaud-sonarsource added a reviewer: rnk.
Herald added a reviewer: shafik.
Herald added a project: All.
frederic-tingaud-sonarsource requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Before C++20, MSVC treated any friend function declaration as a function 
declaration, so the following code would compile despite funGlob being declared 
after its first call:

  class Glob {
  public:
friend void funGlob();
  
void test() {
  funGlob();
}
  };
  
  void funGlob() {}

This proposed patch mimics the MSVC behavior when in MSVC compatibility mode


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124613

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaCXX/ms-friend-function-decl.cpp
  clang/unittests/AST/ASTImporterTest.cpp

Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -2658,7 +2658,10 @@
   getTuDecl("struct X { friend void f(); };", Lang_CXX03, "input0.cc");
   auto *FromD = FirstDeclMatcher().match(FromTU, FunctionPattern);
   ASSERT_TRUE(FromD->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
-  ASSERT_FALSE(FromD->isInIdentifierNamespace(Decl::IDNS_Ordinary));
+  // Before CXX20, MSVC treats friend function declarations as function
+  // declarations
+  ASSERT_EQ(FromTU->getLangOpts().MSVCCompat,
+FromD->isInIdentifierNamespace(Decl::IDNS_Ordinary));
   {
 auto FromName = FromD->getDeclName();
 auto *Class = FirstDeclMatcher().match(FromTU, ClassPattern);
@@ -2702,7 +2705,10 @@
   auto *FromNormal =
   LastDeclMatcher().match(FromTU, FunctionPattern);
   ASSERT_TRUE(FromFriend->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
-  ASSERT_FALSE(FromFriend->isInIdentifierNamespace(Decl::IDNS_Ordinary));
+  // Before CXX20, MSVC treats friend function declarations as function
+  // declarations
+  ASSERT_EQ(FromTU->getLangOpts().MSVCCompat,
+FromFriend->isInIdentifierNamespace(Decl::IDNS_Ordinary));
   ASSERT_FALSE(FromNormal->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
   ASSERT_TRUE(FromNormal->isInIdentifierNamespace(Decl::IDNS_Ordinary));
 
@@ -2793,7 +2799,10 @@
 
   ASSERT_TRUE(FromNormalF->isInIdentifierNamespace(Decl::IDNS_Ordinary));
   ASSERT_FALSE(FromNormalF->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
-  ASSERT_FALSE(FromFriendF->isInIdentifierNamespace(Decl::IDNS_Ordinary));
+  // Before CXX20, MSVC treats friend function declarations as function
+  // declarations
+  ASSERT_EQ(FromFriendTU->getLangOpts().MSVCCompat,
+FromFriendF->isInIdentifierNamespace(Decl::IDNS_Ordinary));
   ASSERT_TRUE(FromFriendF->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
   auto LookupRes = FromNormalTU->noload_lookup(FromNormalName);
   ASSERT_TRUE(LookupRes.isSingleResult());
Index: clang/test/SemaCXX/ms-friend-function-decl.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/ms-friend-function-decl.cpp
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 -std=c++03 -fms-compatibility -fsyntax-only -verify %s
+// RUN: %clang_cc1 -std=c++17 -fms-compatibility -fsyntax-only -verify %s
+// RUN: %clang_cc1 -std=c++20 -fms-compatibility -fsyntax-only -verify=modern %s
+#if __cplusplus < 202002L
+// expected-no-diagnostics
+#endif
+
+namespace ns {
+
+class C {
+public:
+  template 
+  friend void funtemp();
+
+  friend void fun();
+
+  void test() {
+::ns::fun(); // modern-error {{no member named 'fun' in namespace 'ns'}}
+
+// modern-error@+3 {{no member named 'funtemp' in namespace 'ns'}}
+// modern-error@+2 {{expected '(' for function-style cast or type construction}}
+// modern-error@+1 {{expected expression}}
+::ns::funtemp();
+  }
+};
+
+void fun() {
+}
+
+template 
+void funtemp() {}
+
+} // namespace ns
+
+class Glob {
+public:
+  friend void funGlob();
+
+  void test() {
+funGlob(); // modern-error {{use of undeclared identifier 'funGlob'}}
+  }
+};
+
+void funGlob() {
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -9631,11 +9631,15 @@
 }
 
 if (isFriend) {
+  // In MSVC mode for older versions of the standard, friend function
+  // declarations behave as declarations
+  bool PerformFriendInjection =
+  getLangOpts().MSVCCompat && !getLangOpts().CPlusPlus20;
   if (FunctionTemplate) {
-FunctionTemplate->setObjectOfFriendDecl();
+FunctionTemplate->setObjectOfFriendDecl(PerformFriendInjection);
 FunctionTemplate->setAccess(AS_public);
   }
-  NewFD->setObjectOfFriendDecl();
+  NewFD->setObjectOfFriendDecl(PerformFriendInjection);
   NewFD->setAccess(AS_public);

[PATCH] D124606: Use `-text` git attribute instead of `text eol=...'

2022-04-28 Thread Aaron Puchert via Phabricator via cfe-commits

aaronpuchert added subscribers: smeenai, aaronpuchert.
aaronpuchert added a comment.

I think this change broke again what D97625  
was trying to fix. These are text files and we want them to keep the specified 
line endings regardless of the local git configuration. See also @smeenai's 
comment D124563#3478625 .




Comment at: clang-tools-extra/test/.gitattributes:7-15
+clang-apply-replacements/ClangRenameClassReplacements.cpp -text
+clang-apply-replacements/Inputs/basic/basic.h -text
+clang-apply-replacements/Inputs/format/no.cpp -text
+clang-apply-replacements/Inputs/format/yes.cpp -text
+clang-tidy/infrastructure/export-diagnostics.cpp -text
 
 # These test input files rely on two-byte Windows (CRLF) line endings.

My understanding is that `-text` removes an attribute, but what attribute is 
there to remove? There is no global `.gitattributes` that would set it in the 
first place. This change just reverts to the status quo before D97625, or 
rather before that file was moved.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124606

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

[PATCH] D124462: [Analyzer] Fix clang::ento::taint::dumpTaint definition

2022-04-28 Thread Marco Antognini via Phabricator via cfe-commits

mantognini added a comment.

In D124462#3477115 , @steakhal wrote:

> Although gcc (and probably clang too) allows specifying 
> `__attribute__((noinline))` at any declaration (by merging //compatible// 
> attributes), I would prefer not to repeat ourselves.
> The attribute must be present at the header to force all usages not to inline 
> it, hence I would rather drop such attributes from the definition files.

On further inspection, I agree with you and will update the patch (+ 
description).

A few things misled me. First, attributes are complex, with standard and 
compiler-specific ones having different requirements. Then, Clang's doc 
 about `used` talks 
about definitions, not declarations. GCC is clearer and always talks about 
declarations. Fortunately, https://godbolt.org/z/PnW7x9Ezz shows Clang 
inherits, as expected, the attributes of interest here.

But I was mainly misled because, specifically for `LLVM_DUMP_METHOD`, the trend 
in LLVM seems to apply it to definitions:

  $ git grep -Ee '::dump\(\) const \{.*' | grep -ve LLVM_DUMP_METHOD | wc -l
  92
  $ git grep -Ee '::dump\(\) const \{.*' | grep -e LLVM_DUMP_METHOD | wc -l
  184

Anyway, thanks for your feedback -- this fairly trivial patch turned out to 
reveal something interesting to me!

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124462

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

[PATCH] D124258: [C89/C2x] Change the behavior of implicit int diagnostics

2022-04-28 Thread Tom Honermann via Phabricator via cfe-commits

tahonermann added a comment.

> Ping for the other reviewers in case they have thoughts.

I took a gander and it all looks good to me. I added one comment regarding a 
test change.




Comment at: clang/unittests/AST/SourceLocationTest.cpp:135-145
 TEST(ParmVarDecl, KNRLocation) {
   LocationVerifier Verifier;
-  Verifier.expectLocation(1, 8);
-  EXPECT_TRUE(Verifier.match("void f(i) {}", varDecl(), Lang_C99));
+  Verifier.expectLocation(1, 15);
+  EXPECT_TRUE(Verifier.match("void f(i) int i; {}", varDecl(), Lang_C99));
 }
 
 TEST(ParmVarDecl, KNRRange) {

Perhaps preserve the prior tests (switched to `Lang_C89`) and then add these 
tests? That would ensure locations stay correct for both declaration forms.


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

https://reviews.llvm.org/D124258

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

[PATCH] D124614: [Analyzer] Fix clang::ento::taint::dumpTaint definition

2022-04-28 Thread Marco Antognini via Phabricator via cfe-commits

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

Ensure the definition is in the "taint" namespace, like its declaration.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124614

Files:
  clang/lib/StaticAnalyzer/Checkers/Taint.cpp


Index: clang/lib/StaticAnalyzer/Checkers/Taint.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/Taint.cpp
+++ clang/lib/StaticAnalyzer/Checkers/Taint.cpp
@@ -37,7 +37,9 @@
 Out << I.first << " : " << I.second << NL;
 }
 
-void dumpTaint(ProgramStateRef State) { printTaint(State, llvm::errs()); }
+void taint::dumpTaint(ProgramStateRef State) {
+  printTaint(State, llvm::errs());
+}
 
 ProgramStateRef taint::addTaint(ProgramStateRef State, const Stmt *S,
 const LocationContext *LCtx,


Index: clang/lib/StaticAnalyzer/Checkers/Taint.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/Taint.cpp
+++ clang/lib/StaticAnalyzer/Checkers/Taint.cpp
@@ -37,7 +37,9 @@
 Out << I.first << " : " << I.second << NL;
 }
 
-void dumpTaint(ProgramStateRef State) { printTaint(State, llvm::errs()); }
+void taint::dumpTaint(ProgramStateRef State) {
+  printTaint(State, llvm::errs());
+}
 
 ProgramStateRef taint::addTaint(ProgramStateRef State, const Stmt *S,
 const LocationContext *LCtx,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124614: [Analyzer] Fix clang::ento::taint::dumpTaint definition

2022-04-28 Thread Marco Antognini via Phabricator via cfe-commits

mantognini abandoned this revision.
mantognini added a comment.

Ran wrong `arc` command...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124614

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

[PATCH] D124606: Use `-text` git attribute instead of `text eol=...'

2022-04-28 Thread Pavel Labath via Phabricator via cfe-commits

labath added inline comments.

Comment at: clang-tools-extra/test/.gitattributes:7-15
+clang-apply-replacements/ClangRenameClassReplacements.cpp -text
+clang-apply-replacements/Inputs/basic/basic.h -text
+clang-apply-replacements/Inputs/format/no.cpp -text
+clang-apply-replacements/Inputs/format/yes.cpp -text
+clang-tidy/infrastructure/export-diagnostics.cpp -text

 # These test input files rely on two-byte Windows (CRLF) line endings.

aaronpuchert wrote:
> My understanding is that `-text` removes an attribute, but what attribute is 
> there to remove? There is no global `.gitattributes` that would set it in the 
> first place. This change just reverts to the status quo before D97625, or 
> rather before that file was moved.
Are you sure about that? Git seems to distinguish between "unset" and 
"unspecified" values of an attribute:
```
   Each attribute can be in one of these states for a given path:

   Set
   The path has the attribute with special value "true"; this is 
specified by listing only the
   name of the attribute in the attribute list.

   Unset
   The path has the attribute with special value "false"; this is 
specified by listing the
   name of the attribute prefixed with a dash - in the attribute list.

   Set to a value
   The path has the attribute with specified string value; this is 
specified by listing the
   name of the attribute followed by an equal sign = and its value in 
the attribute list.

   Unspecified
   No pattern matches the path, and nothing says if the path has or 
does not have the
   attribute, the attribute for the path is said to be Unspecified.

```

And then it says this about the `text` attribute in particular:
```
   Set
   Setting the text attribute on a path enables end-of-line 
normalization and marks the
   path as a text file. End-of-line conversion takes place without 
guessing the content
   type.

   Unset
   Unsetting the text attribute on a path tells Git not to attempt 
any end-of-line
   conversion upon checkin or checkout.

   Set to string value "auto"
   When text is set to "auto", the path is marked for automatic 
end-of-line conversion. If
   Git decides that the content is text, its line endings are 
converted to LF on checkin.
   When the file has been committed with CRLF, no conversion is 
done.

   Unspecified
   If the text attribute is unspecified, Git uses the core.autocrlf 
configuration variable
   to determine if the file should be converted.

```

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124606

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

[clang] 8854d12 - [PS5] Disable exceptions by default

2022-04-28 Thread Paul Robinson via cfe-commits


Author: Paul Robinson
Date: 2022-04-28T07:16:16-07:00
New Revision: 8854d1244c905b20dd62db3a7430043477e1ad3b

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

LOG: [PS5] Disable exceptions by default

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/clang-exception-flags.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 01380f9e1985..1f083de405f0 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -459,9 +459,9 @@ static bool addExceptionArgs(const ArgList &Args, types::ID 
InputType,
   }
 
   if (types::isCXX(InputType)) {
-// Disable C++ EH by default on XCore and PS4.
+// Disable C++ EH by default on XCore and PS4/PS5.
 bool CXXExceptionsEnabled =
-Triple.getArch() != llvm::Triple::xcore && !Triple.isPS4();
+Triple.getArch() != llvm::Triple::xcore && !Triple.isPS();
 Arg *ExceptionArg = Args.getLastArg(
 options::OPT_fcxx_exceptions, options::OPT_fno_cxx_exceptions,
 options::OPT_fexceptions, options::OPT_fno_exceptions);

diff  --git a/clang/test/Driver/clang-exception-flags.cpp 
b/clang/test/Driver/clang-exception-flags.cpp
index a5faed228e05..af63a0ab03be 100644
--- a/clang/test/Driver/clang-exception-flags.cpp
+++ b/clang/test/Driver/clang-exception-flags.cpp
@@ -24,5 +24,6 @@
 // RUN: %clang -### -fexceptions -fno-cxx-exceptions %s 2>&1 | FileCheck %s 
-check-prefix=OFF4
 // OFF4-NOT: "-cc1" {{.*}} "-fcxx-exceptions"
 //
-// RUN: %clang -### -target x86_64-scei-ps4 %s 2>&1 | FileCheck %s 
-check-prefix=PS4-OFF
-// PS4-OFF-NOT: "-cc1" {{.*}} "-f{{(cxx-)?}}exceptions"
+// RUN: %clang -### -target x86_64-scei-ps4 %s 2>&1 | FileCheck %s 
-check-prefix=PS-OFF
+// RUN: %clang -### -target x86_64-sie-ps5 %s 2>&1 | FileCheck %s 
-check-prefix=PS-OFF
+// PS-OFF-NOT: "-cc1" {{.*}} "-f{{(cxx-)?}}exceptions"



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

[PATCH] D124462: [Analyzer] Fix clang::ento::taint::dumpTaint definition

2022-04-28 Thread Marco Antognini via Phabricator via cfe-commits

mantognini updated this revision to Diff 425772.
mantognini added a comment.

Remove LLVM_DUMP_METHOD from definition


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124462

Files:
  clang/lib/StaticAnalyzer/Checkers/Taint.cpp


Index: clang/lib/StaticAnalyzer/Checkers/Taint.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/Taint.cpp
+++ clang/lib/StaticAnalyzer/Checkers/Taint.cpp
@@ -37,7 +37,9 @@
 Out << I.first << " : " << I.second << NL;
 }
 
-void dumpTaint(ProgramStateRef State) { printTaint(State, llvm::errs()); }
+void taint::dumpTaint(ProgramStateRef State) {
+  printTaint(State, llvm::errs());
+}
 
 ProgramStateRef taint::addTaint(ProgramStateRef State, const Stmt *S,
 const LocationContext *LCtx,


Index: clang/lib/StaticAnalyzer/Checkers/Taint.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/Taint.cpp
+++ clang/lib/StaticAnalyzer/Checkers/Taint.cpp
@@ -37,7 +37,9 @@
 Out << I.first << " : " << I.second << NL;
 }
 
-void dumpTaint(ProgramStateRef State) { printTaint(State, llvm::errs()); }
+void taint::dumpTaint(ProgramStateRef State) {
+  printTaint(State, llvm::errs());
+}
 
 ProgramStateRef taint::addTaint(ProgramStateRef State, const Stmt *S,
 const LocationContext *LCtx,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124606: Use `-text` git attribute instead of `text eol=...'

2022-04-28 Thread Ilya Biryukov via Phabricator via cfe-commits

ilya-biryukov added a comment.

In D124606#3480012 , @aaronpuchert 
wrote:

> I think this change broke again what D97625  
> was trying to fix. These are text files and we want them to keep the 
> specified line endings regardless of the local git configuration. See also 
> @smeenai's comment D124563#3478625 .

This change should be doing exactly that.
The behaviour in the mentioned comment should apply when the text attribute is 
unspecified, not when it's explicitly unset.
From git docs :

  Unset
  Unsetting the text attribute on a path tells Git not to attempt any 
end-of-line conversion upon checkin or checkout.
  
  Unspecified
  If the text attribute is unspecified, Git uses the core.autocrlf 
configuration variable to determine if the file should be converted.




Comment at: clang-tools-extra/test/.gitattributes:7-15
+clang-apply-replacements/ClangRenameClassReplacements.cpp -text
+clang-apply-replacements/Inputs/basic/basic.h -text
+clang-apply-replacements/Inputs/format/no.cpp -text
+clang-apply-replacements/Inputs/format/yes.cpp -text
+clang-tidy/infrastructure/export-diagnostics.cpp -text
 
 # These test input files rely on two-byte Windows (CRLF) line endings.

labath wrote:
> aaronpuchert wrote:
> > My understanding is that `-text` removes an attribute, but what attribute 
> > is there to remove? There is no global `.gitattributes` that would set it 
> > in the first place. This change just reverts to the status quo before 
> > D97625, or rather before that file was moved.
> Are you sure about that? Git seems to distinguish between "unset" and 
> "unspecified" values of an attribute:
> ```
>Each attribute can be in one of these states for a given path:
> 
>Set
>The path has the attribute with special value "true"; this is 
> specified by listing only the
>name of the attribute in the attribute list.
> 
>Unset
>The path has the attribute with special value "false"; this is 
> specified by listing the
>name of the attribute prefixed with a dash - in the attribute list.
> 
>Set to a value
>The path has the attribute with specified string value; this is 
> specified by listing the
>name of the attribute followed by an equal sign = and its value in 
> the attribute list.
> 
>Unspecified
>No pattern matches the path, and nothing says if the path has or 
> does not have the
>attribute, the attribute for the path is said to be Unspecified.
> 
> ```
> 
> And then it says this about the `text` attribute in particular:
> ```
>Set
>Setting the text attribute on a path enables end-of-line 
> normalization and marks the
>path as a text file. End-of-line conversion takes place 
> without guessing the content
>type.
> 
>Unset
>Unsetting the text attribute on a path tells Git not to 
> attempt any end-of-line
>conversion upon checkin or checkout.
> 
>Set to string value "auto"
>When text is set to "auto", the path is marked for automatic 
> end-of-line conversion. If
>Git decides that the content is text, its line endings are 
> converted to LF on checkin.
>When the file has been committed with CRLF, no conversion is 
> done.
> 
>Unspecified
>If the text attribute is unspecified, Git uses the 
> core.autocrlf configuration variable
>to determine if the file should be converted.
> 
> ```
The [[ https://git-scm.com/docs/gitattributes | git docs ]] seem to be pretty 
clear that unsetting the attribute should do the right thing:
```
Unset
Unsetting the text attribute on a path tells Git not to attempt any end-of-line 
conversion upon checkin or checkout.
```

It seems git is supposed to do the right thing for us here, unless I 
misunderstand something.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124606

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

[PATCH] D124606: Use `-text` git attribute instead of `text eol=...'

2022-04-28 Thread Ilya Biryukov via Phabricator via cfe-commits

ilya-biryukov added a comment.

@labath, ah, sorry, you beat me to it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124606

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

[PATCH] D123924: [clang-apply-replacements] Added an option to ignore insert conflict.

2022-04-28 Thread gehry via Phabricator via cfe-commits

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

Friendly ping.


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

https://reviews.llvm.org/D123924

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

[PATCH] D124556: [NFC] Prevent shadowing a variable declared in `if`

2022-04-28 Thread Hubert Tong via Phabricator via cfe-commits

hubert.reinterpretcast added a comment.

In D124556#3479833 , @ken-matsui 
wrote:

> @hubert.reinterpretcast,
>
> Sorry to have missed providing a summary.

You can still provide one by using the "Edit Revision" link.

I suggest something like:
Prevents confusion over which `S` is referenced in the final `else` branch if 
such a use is added.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124556

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

[PATCH] D124606: Use `-text` git attribute instead of `text eol=...'

2022-04-28 Thread Michael Forster via Phabricator via cfe-commits

MForster added a comment.

Well, I tested this on Windows. :-)

  forster@Desktop MINGW64 ~/src/llvm-project/clang-tools-extra/test (main)
  $ git reset --hard 4aba5fa774821279c2e2e26dd6ed6e1c6a151044 && grep 'crlf.cpp 
' .gitattributes && file clang-apply-replacements/Inputs/crlf/crlf.cpp
  HEAD is now at 4aba5fa77482 Use `-text` git attribute instead of `text 
eol=...`
  clang-apply-replacements/Inputs/crlf/crlf.cpp -text
  clang-apply-replacements/Inputs/crlf/crlf.cpp: ASCII text, with CRLF line 
terminators
  
  forster@Desktop MINGW64 ~/src/llvm-project/clang-tools-extra/test (main)
  $ git reset --hard c9a16e8c3d99173c7525e576d78eed57110d2b08 && grep 'crlf.cpp 
' .gitattributes && file clang-apply-replacements/Inputs/crlf/crlf.cpp
  HEAD is now at c9a16e8c3d99 Drop '* text=auto' from .gitattributes and 
normalize
  clang-apply-replacements/Inputs/crlf/crlf.cpp text eol=crlf
  clang-apply-replacements/Inputs/crlf/crlf.cpp: ASCII text, with CRLF line 
terminators
  
  forster@Desktop MINGW64 ~/src/llvm-project/clang-tools-extra/test (main)
  $ git reset --hard ac5f7be6a8688955a282becf00eebc542238a86b && grep 'crlf.cpp 
' .gitattributes && file clang-apply-replacements/Inputs/crlf/crlf.cpp
  HEAD is now at ac5f7be6a868 Move test/.gitattributes to clang-tools-extra/test
  clang-apply-replacements/Inputs/crlf/crlf.cpp text eol=crlf
  clang-apply-replacements/Inputs/crlf/crlf.cpp: ASCII text, with CRLF line 
terminators


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124606

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

[clang] 451c557 - [PS5] Set default cpu to znver2, with no tuning

2022-04-28 Thread Paul Robinson via cfe-commits


Author: Paul Robinson
Date: 2022-04-28T07:50:37-07:00
New Revision: 451c5578b834fe3aca4e495aaf6a2f32639e86a6

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

LOG: [PS5] Set default cpu to znver2, with no tuning

Added: 


Modified: 
clang/lib/Driver/ToolChains/Arch/X86.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Driver/ps4-cpu-defaults.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Arch/X86.cpp 
b/clang/lib/Driver/ToolChains/Arch/X86.cpp
index 73df835585239..de0725b8d6de6 100644
--- a/clang/lib/Driver/ToolChains/Arch/X86.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/X86.cpp
@@ -88,9 +88,11 @@ std::string x86::getX86TargetCPU(const Driver &D, const 
ArgList &Args,
 return Is64Bit ? "core2" : "yonah";
   }
 
-  // Set up default CPU name for PS4 compilers.
+  // Set up default CPU name for PS4/PS5 compilers.
   if (Triple.isPS4())
 return "btver2";
+  if (Triple.isPS5())
+return "znver2";
 
   // On Android use targets compatible with gcc
   if (Triple.isAndroid())

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 1f083de405f0a..52dbe07ab3551 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2296,10 +2296,10 @@ void Clang::AddX86TargetArgs(const ArgList &Args,
 
   // Handle -mtune.
 
-  // Default to "generic" unless -march is present or targetting the PS4.
+  // Default to "generic" unless -march is present or targetting the PS4/PS5.
   std::string TuneCPU;
   if (!Args.hasArg(clang::driver::options::OPT_march_EQ) &&
-  !getToolChain().getTriple().isPS4())
+  !getToolChain().getTriple().isPS())
 TuneCPU = "generic";
 
   // Override based on -mtune.

diff  --git a/clang/test/Driver/ps4-cpu-defaults.cpp 
b/clang/test/Driver/ps4-cpu-defaults.cpp
index 46fa8897e6fae..8102c4b144a35 100644
--- a/clang/test/Driver/ps4-cpu-defaults.cpp
+++ b/clang/test/Driver/ps4-cpu-defaults.cpp
@@ -1,7 +1,10 @@
 // Check that on the PS4 we default to:
-// -target-cpu btver2, no exceptions and not -tune-cpu generic
+// -target-cpu btver2, not -tune-cpu generic
+// And on the PS5 we default to:
+// -target-cpu znver2, not -tune-cpu generic
 
-// RUN: %clang -target x86_64-scei-ps4 -c %s -### 2>&1 | FileCheck %s
-// CHECK: "-target-cpu" "btver2"
-// CHECK-NOT: exceptions
-// CHECK-NOT: "-tune-cpu"
+// RUN: %clang -target x86_64-scei-ps4 -c %s -### 2>&1 | FileCheck 
--check-prefixes=PS4,BOTH %s
+// RUN: %clang -target x86_64-sie-ps5 -c %s -### 2>&1 | FileCheck 
--check-prefixes=PS5,BOTH %s
+// PS4: "-target-cpu" "btver2"
+// PS5: "-target-cpu" "znver2"
+// BOTH-NOT: "-tune-cpu"



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

[PATCH] D124525: [OpenMP][ClangLinkerWrapper] Extending linker wrapper to embed metadata for multi-arch fat binaries

2022-04-28 Thread Yaxun Liu via Phabricator via cfe-commits

yaxunl added inline comments.



Comment at: clang/tools/clang-linker-wrapper/OffloadWrapper.cpp:98-104
+  // struct __tgt_image_info {
+  //   int32_t version;
+  //   int32_t image_number;
+  //   int32_t number_images;
+  //   char* offload_arch;
+  //   char* target_compile_opts;
+  // };

saiislam wrote:
> yaxunl wrote:
> > I am wondering whether we should add a few more fields to make it more 
> > generic for all offloading languages and platforms:
> > 
> > 
> > ```
> > char* target_triple;
> > char* offloading_kind; // openmp, hip, etc
> > char* file_type; // elf, spirv, bitcode, etc
> > ```
> Good idea. Though I am not sure whether file_type info is being propagated in 
> by the linker-wrapper or not. I will check.
the file_type is for the file embedded by OffloadWrapper, therefore 
OffloadWrapper knows it.

Currently it is fatbin or cubin for CUDA and code object (elf) for HIP.

In the future, it may be spirv or bitcode to allow JIT compilation of spirv or 
bitcode in runtime so that one binary for all GPU's. OffloadWrapper will decide 
what is the final file type to embed based on type of embedded binaries in 
input files, target triple, and compile arguments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124525

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

[PATCH] D124563: Drop '* text=auto' from .gitattributes and normalize

2022-04-28 Thread Michael Forster via Phabricator via cfe-commits

MForster added a comment.

In D124563#3479990 , @aaronpuchert 
wrote:

> In D124563#3478625 , @smeenai wrote:
>
>> I *think* this would mean that if you're on Windows and have `core.autocrlf` 
>> set to `input`, when you commit changes to this files, Git will convert them 
>> back to LF line endings. Not 100% sure of that though.
>
> Which convinced me that D97625  was right: 
> we do want the line endings to remain CRLF, and not have them accidentally 
> destroyed. With `-text` we say that we don't care, which is not true.

I verified manually on Windows that the behavior is still what we want. D124606 
 explains that `-text` means that 
`core.autocrlf` is ignored.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124563

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

[PATCH] D123498: [clang] Adding Platform/Architecture Specific Resource Header Installation Targets

2022-04-28 Thread Qiongsi Wu via Phabricator via cfe-commits

qiongsiwu1 updated this revision to Diff 425780.
qiongsiwu1 added reviewers: ye-luo, rastogishubham.
qiongsiwu1 added a comment.
Herald added a subscriber: sstefan1.

This patch is updated to address

- https://github.com/llvm/llvm-project/issues/55002 @ye-luo
- configuration issue with xcode @rastogishubham
- regrouping of header targets so the comments apply. @Anastasia

  @ye-luo @rastogishubham if you get a chance, could you try the patch and see 
if it works? Thanks!

Thanks for the comments and the issue reports!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123498

Files:
  clang/lib/Headers/CMakeLists.txt

Index: clang/lib/Headers/CMakeLists.txt
===
--- clang/lib/Headers/CMakeLists.txt
+++ clang/lib/Headers/CMakeLists.txt
@@ -1,19 +1,107 @@
-set(files
-  adxintrin.h
-  altivec.h
-  ammintrin.h
-  amxintrin.h
+# core_files list contains the headers shared by all platforms.
+# Please consider adding new platform specific headers
+# to platform specific lists below.
+set(core_files
+  builtins.h
+  float.h
+  inttypes.h
+  iso646.h
+  limits.h
+  module.modulemap
+  stdalign.h
+  stdarg.h
+  stdatomic.h
+  stdbool.h
+  stddef.h
+  __stddef_max_align_t.h
+  stdint.h
+  stdnoreturn.h
+  tgmath.h
+  unwind.h
+  varargs.h
+  )
+
+set(arm_common_files
+  # Headers shared by Arm and AArch64
   arm_acle.h
+  )
+
+set(arm_only_files
   arm_cmse.h
   armintr.h
+  )
+
+set(aarch64_only_files
   arm64intr.h
+  )
+
+set(cuda_files
+  __clang_cuda_builtin_vars.h
+  __clang_cuda_math.h
+  __clang_cuda_cmath.h
+  __clang_cuda_complex_builtins.h
+  __clang_cuda_device_functions.h
+  __clang_cuda_intrinsics.h
+  __clang_cuda_texture_intrinsics.h
+  __clang_cuda_libdevice_declares.h
+  __clang_cuda_math_forward_declares.h
+  __clang_cuda_runtime_wrapper.h
+  )
+
+set(hexagon_files
+  hexagon_circ_brev_intrinsics.h
+  hexagon_protos.h
+  hexagon_types.h
+  hvx_hexagon_protos.h
+  )
+
+set(hip_files
+  __clang_hip_libdevice_declares.h
+  __clang_hip_cmath.h
+  __clang_hip_math.h
+  __clang_hip_runtime_wrapper.h
+  )
+
+set(mips_msa_files
+  msa.h
+  )
+
+set(opencl_files
+  opencl-c.h
+  opencl-c-base.h
+  )
+
+set(ppc_files
+  altivec.h
+  htmintrin.h
+  htmxlintrin.h
+  )
+
+set(systemz_files
+  s390intrin.h
+  vecintrin.h
+  )
+
+set(ve_files
+  velintrin.h
+  velintrin_gen.h
+  velintrin_approx.h
+  )
+
+set(webassembly_files
+  wasm_simd128.h
+  )
+
+set(x86_files
+# Intrinsics
+  adxintrin.h
+  ammintrin.h
+  amxintrin.h
   avx2intrin.h
   avx512bf16intrin.h
-  avx512bwintrin.h
   avx512bitalgintrin.h
-  avx512vlbitalgintrin.h
+  avx512bwintrin.h
   avx512cdintrin.h
-  avx512vpopcntdqintrin.h
   avx512dqintrin.h
   avx512erintrin.h
   avx512fintrin.h
@@ -21,86 +109,55 @@
   avx512ifmaintrin.h
   avx512ifmavlintrin.h
   avx512pfintrin.h
+  avx512vbmi2intrin.h
   avx512vbmiintrin.h
   avx512vbmivlintrin.h
-  avx512vbmi2intrin.h
-  avx512vlvbmi2intrin.h
   avx512vlbf16intrin.h
+  avx512vlbitalgintrin.h
   avx512vlbwintrin.h
   avx512vlcdintrin.h
   avx512vldqintrin.h
   avx512vlfp16intrin.h
   avx512vlintrin.h
-  avx512vp2intersectintrin.h
+  avx512vlvbmi2intrin.h
+  avx512vlvnniintrin.h
   avx512vlvp2intersectintrin.h
-  avx512vpopcntdqvlintrin.h
   avx512vnniintrin.h
-  avx512vlvnniintrin.h
+  avx512vp2intersectintrin.h
+  avx512vpopcntdqintrin.h
+  avx512vpopcntdqvlintrin.h
   avxintrin.h
   avxvnniintrin.h
   bmi2intrin.h
   bmiintrin.h
-  builtins.h
-  __clang_cuda_builtin_vars.h
-  __clang_cuda_math.h
-  __clang_cuda_cmath.h
-  __clang_cuda_complex_builtins.h
-  __clang_cuda_device_functions.h
-  __clang_cuda_intrinsics.h
-  __clang_cuda_texture_intrinsics.h
-  __clang_cuda_libdevice_declares.h
-  __clang_cuda_math_forward_declares.h
-  __clang_cuda_runtime_wrapper.h
-  __clang_hip_libdevice_declares.h
-  __clang_hip_cmath.h
-  __clang_hip_math.h
-  __clang_hip_runtime_wrapper.h
   cetintrin.h
-  cet.h
   cldemoteintrin.h
-  clzerointrin.h
-  crc32intrin.h
-  cpuid.h
   clflushoptintrin.h
   clwbintrin.h
+  clzerointrin.h
+  crc32intrin.h
   emmintrin.h
   enqcmdintrin.h
   f16cintrin.h
-  float.h
   fma4intrin.h
   fmaintrin.h
   fxsrintrin.h
   gfniintrin.h
-  hexagon_circ_brev_intrinsics.h
-  hexagon_protos.h
-  hexagon_types.h
-  hvx_hexagon_protos.h
   hresetintrin.h
-  htmintrin.h
-  htmxlintrin.h
   ia32intrin.h
   immintrin.h
-  intrin.h
-  inttypes.h
   invpcidintrin.h
-  iso646.h
   keylockerintrin.h
-  limits.h
   lwpintrin.h
   lzcntintrin.h
   mm3dnow.h
   mmintrin.h
-  mm_malloc.h
-  module.modulemap
   movdirintrin.h
-  msa.h
   mwaitxintrin.h
   nmmintrin.h
-  opencl-c.h
-  opencl-c-base.h
+  pconfigintrin.h
   pkuintrin.h
   pmmintrin.h
-  pconfigintrin.h
   popcntintrin.h
   prfchwintrin.h
   ptwriteintrin.h
@@ -108,33 +165,18 @@
   rtmintrin.h
   serializeintrin.h
   sgxintrin.h
-  s390intrin.h
   shaintrin.h
   smmintrin.h
-  stdalign.h
-  std

[PATCH] D123773: [clang][analyzer][ctu] Make CTU a two phase analysis

2022-04-28 Thread Gabor Marton via Phabricator via cfe-commits

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

- Add an option to config the inlining mode during the first phase
- Change the `ctu-main.c[pp]` tests to have a RUN line with this new config 
option that mimics the old ctu implementation's behavor.
- Change the on-demand-parsing tests back as they were in the baseline. Those 
files are sheer copies of the `ctu-main` files, actually, the on demand testing 
should be done in the `ctu-main` test files as well (added a fixme for that).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123773

Files:
  clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.def
  clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  clang/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
  clang/test/Analysis/Inputs/ctu-onego-small-other.cpp
  
clang/test/Analysis/Inputs/ctu-onego-small-other.cpp.externalDefMap.ast-dump.txt
  clang/test/Analysis/analyzer-config.c
  clang/test/Analysis/ctu-main.c
  clang/test/Analysis/ctu-main.cpp
  clang/test/Analysis/ctu-on-demand-parsing.c
  clang/test/Analysis/ctu-on-demand-parsing.cpp
  clang/test/Analysis/ctu-onego-indirect.cpp
  clang/test/Analysis/ctu-onego-small.cpp
  clang/test/Analysis/ctu-onego-toplevel.cpp

Index: clang/test/Analysis/ctu-onego-toplevel.cpp
===
--- clang/test/Analysis/ctu-onego-toplevel.cpp
+++ clang/test/Analysis/ctu-onego-toplevel.cpp
@@ -9,6 +9,7 @@
 // RUN:   -analyzer-config eagerly-assume=false \
 // RUN:   -analyzer-config experimental-enable-naive-ctu-analysis=true \
 // RUN:   -analyzer-config ctu-dir=%t/ctudir \
+// RUN:   -analyzer-config ctu-phase1-inlining=none \
 // RUN:   -verify=ctu %s
 
 // RUN: %clang_analyze_cc1 -std=c++14 -triple x86_64-pc-linux-gnu \
@@ -16,6 +17,7 @@
 // RUN:   -analyzer-config eagerly-assume=false \
 // RUN:   -analyzer-config experimental-enable-naive-ctu-analysis=true \
 // RUN:   -analyzer-config ctu-dir=%t/ctudir \
+// RUN:   -analyzer-config ctu-phase1-inlining=none \
 // RUN:   -analyzer-config display-ctu-progress=true \
 // RUN:   -analyzer-display-progress \
 // RUN:   -verify=ctu %s 2>&1 | FileCheck %s
Index: clang/test/Analysis/ctu-onego-small.cpp
===
--- /dev/null
+++ clang/test/Analysis/ctu-onego-small.cpp
@@ -0,0 +1,51 @@
+// RUN: rm -rf %t && mkdir %t
+// RUN: mkdir -p %t/ctudir
+// RUN: %clang_cc1 -std=c++14 -triple x86_64-pc-linux-gnu \
+// RUN:   -emit-pch -o %t/ctudir/ctu-onego-small-other.cpp.ast %S/Inputs/ctu-onego-small-other.cpp
+// RUN: cp %S/Inputs/ctu-onego-small-other.cpp.externalDefMap.ast-dump.txt %t/ctudir/externalDefMap.txt
+
+// Small function defined in another TU.
+int bar();
+
+// Here we limit the ctu analysis to the first phase only (via the
+// ctu-max-nodes config options). And we check whether the small foreign
+// function `bar` is inlined.
+
+// RUN: %clang_analyze_cc1 -std=c++14 -triple x86_64-pc-linux-gnu \
+// RUN:   -analyzer-checker=core,debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false \
+// RUN:   -analyzer-config experimental-enable-naive-ctu-analysis=true \
+// RUN:   -analyzer-config ctu-dir=%t/ctudir \
+// RUN:   -analyzer-config display-ctu-progress=true \
+// RUN:   -analyzer-display-progress \
+// RUN:   -analyzer-config ctu-max-nodes-mul=0 \
+// RUN:   -analyzer-config ctu-max-nodes-min=0 2>&1 %s | FileCheck %s
+// CHECK: ANALYZE (Path,  Inline_Regular): {{.*}} baruser(int){{.*}}CTU loaded AST file
+
+// RUN: %clang_analyze_cc1 -std=c++14 -triple x86_64-pc-linux-gnu \
+// RUN:   -analyzer-checker=core,debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false \
+// RUN:   -analyzer-config experimental-enable-naive-ctu-analysis=true \
+// RUN:   -analyzer-config ctu-dir=%t/ctudir \
+// RUN:   -analyzer-config ctu-max-nodes-mul=0 \
+// RUN:   -analyzer-config ctu-phase1-inlining=none \
+// RUN:   -analyzer-config ctu-max-nodes-min=0 -verify=inline-none %s
+
+// RUN: %clang_analyze_cc1 -std=c++14 -triple x86_64-pc-linux-gnu \
+// RUN:   -analyzer-checker=core,debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false \
+// RUN:   -analyzer-config experimental-enable-naive-ctu-analysis=true \
+// RUN:   -analyzer-config ctu-dir=%t/ctudir \
+// RUN:   -analyzer-config ctu-max-nodes-mul=0 \
+// RUN:   -analyzer-config ctu-phase1-inlining=small \
+// RUN:   -analyzer-config ctu-max-nodes-min=0 -verify=inline-small %s
+
+
+void clang_analyzer_eval(int);
+
+void baruser(int x) {
+  int y = bar();
+  // inline-none-warning@+2{{UNKNOWN}}
+  // inline-small-warning@+1{{TRUE}}
+  clang_analyzer_eval(y == 0);
+}
Index: clang/test/Analysis/ctu-onego-indirect.cpp
===
--- clang/test/Analysis/ctu-onego-indirect.cpp
+++ clang/test/Analysis/

[PATCH] D123773: [clang][analyzer][ctu] Make CTU a two phase analysis

2022-04-28 Thread Gabor Marton via Phabricator via cfe-commits

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

- Chosing the correct baseline this time


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123773

Files:
  clang/include/clang/CrossTU/CrossTranslationUnit.h
  clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.def
  clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/CoreEngine.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  clang/lib/CrossTU/CrossTranslationUnit.cpp
  clang/lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
  clang/lib/StaticAnalyzer/Core/CallEvent.cpp
  clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
  clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
  clang/test/Analysis/Inputs/ctu-onego-existingdef-other.cpp
  
clang/test/Analysis/Inputs/ctu-onego-existingdef-other.cpp.externalDefMap.ast-dump.txt
  clang/test/Analysis/Inputs/ctu-onego-indirect-other.cpp
  
clang/test/Analysis/Inputs/ctu-onego-indirect-other.cpp.externalDefMap.ast-dump.txt
  clang/test/Analysis/Inputs/ctu-onego-small-other.cpp
  
clang/test/Analysis/Inputs/ctu-onego-small-other.cpp.externalDefMap.ast-dump.txt
  clang/test/Analysis/Inputs/ctu-onego-toplevel-other.cpp
  
clang/test/Analysis/Inputs/ctu-onego-toplevel-other.cpp.externalDefMap.ast-dump.txt
  clang/test/Analysis/analyzer-config.c
  clang/test/Analysis/ctu-implicit.c
  clang/test/Analysis/ctu-main.c
  clang/test/Analysis/ctu-main.cpp
  clang/test/Analysis/ctu-on-demand-parsing.c
  clang/test/Analysis/ctu-on-demand-parsing.cpp
  clang/test/Analysis/ctu-onego-existingdef.cpp
  clang/test/Analysis/ctu-onego-indirect.cpp
  clang/test/Analysis/ctu-onego-small.cpp
  clang/test/Analysis/ctu-onego-toplevel.cpp

Index: clang/test/Analysis/ctu-onego-toplevel.cpp
===
--- /dev/null
+++ clang/test/Analysis/ctu-onego-toplevel.cpp
@@ -0,0 +1,54 @@
+// RUN: rm -rf %t && mkdir %t
+// RUN: mkdir -p %t/ctudir
+// RUN: %clang_cc1 -std=c++14 -triple x86_64-pc-linux-gnu \
+// RUN:   -emit-pch -o %t/ctudir/ctu-onego-toplevel-other.cpp.ast %S/Inputs/ctu-onego-toplevel-other.cpp
+// RUN: cp %S/Inputs/ctu-onego-toplevel-other.cpp.externalDefMap.ast-dump.txt %t/ctudir/externalDefMap.txt
+
+// RUN: %clang_analyze_cc1 -std=c++14 -triple x86_64-pc-linux-gnu \
+// RUN:   -analyzer-checker=core,debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false \
+// RUN:   -analyzer-config experimental-enable-naive-ctu-analysis=true \
+// RUN:   -analyzer-config ctu-dir=%t/ctudir \
+// RUN:   -analyzer-config ctu-phase1-inlining=none \
+// RUN:   -verify=ctu %s
+
+// RUN: %clang_analyze_cc1 -std=c++14 -triple x86_64-pc-linux-gnu \
+// RUN:   -analyzer-checker=core,debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false \
+// RUN:   -analyzer-config experimental-enable-naive-ctu-analysis=true \
+// RUN:   -analyzer-config ctu-dir=%t/ctudir \
+// RUN:   -analyzer-config ctu-phase1-inlining=none \
+// RUN:   -analyzer-config display-ctu-progress=true \
+// RUN:   -analyzer-display-progress \
+// RUN:   -verify=ctu %s 2>&1 | FileCheck %s
+//
+// CallGraph: c->b
+// topological sort: c, b
+// Note that `other` calls into `b` but that is not visible in the CallGraph
+// b/c that happens in another TU.
+
+// During the onego CTU analysis, we start with c() as top level function.
+// Then we visit b() as non-toplevel during the processing of the FWList, thus
+// that would not be visited as toplevel without special care.
+
+// `c` is analyzed as toplevel and during that the other TU is loaded:
+// CHECK: ANALYZE (Path,  Inline_Regular): {{.*}} c(int){{.*}}CTU loaded AST file
+// next, `b` is analyzed as toplevel:
+// CHECK: ANALYZE (Path,  Inline_Regular): {{.*}} b(int)
+
+void b(int x);
+void other(int y);
+void c(int y) {
+  other(y);
+  return;
+  // The below call is here to form the proper CallGraph, but will not be
+  // analyzed.
+  b(1);
+}
+
+void b(int x) {
+  if (x == 0)
+(void)(1 / x);
+// ctu-warning@-1{{Division by zero}}
+// We receive the above warning only if `b` is analyzed as top-level.
+}
Index: clang/test/Analysis/ctu-onego-small.cpp
===
--- /dev/null
+++ clang/test/Analysis/ctu-onego-small.cpp
@@ -0,0 +1,51 @@
+// RUN: rm -rf %t && mkdir %t
+// RUN: mkdir -p %t/ctudir
+// RUN: %clang_cc1 -std=c++14 -triple x86_64-pc-linux-gnu \
+// RUN:   -emit-pch -o %t/ctudir/ctu-onego-small-other.cpp.ast %S/Inputs/ctu-onego-small-other.cpp
+// RUN: cp %S/Inputs/ctu-onego-small-other.cpp.externalDefMap.ast-dump.txt %t/ctudir/externalDefMap.txt
+
+// Small function defined in another TU.
+int bar();
+
+// Here we limit the ctu analysis to the first phase only (via the

[PATCH] D124606: Use `-text` git attribute instead of `text eol=...'

2022-04-28 Thread Aaron Puchert via Phabricator via cfe-commits

aaronpuchert added a comment.

Fair enough, but don't we want to enforce LF or CRLF, respectively? An editor 
could inadvertently change the line endings, and someone might not notice 
before commiting. Explicitly specifying the right line endings gives us the 
proper line endings even if some editors mess things up.

That was what @smeenai actually referred to, sorry for misrepresenting that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124606

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

[clang] 501cc4a - [PS5] Rename a test to reflect its new purpose

2022-04-28 Thread Paul Robinson via cfe-commits


Author: Paul Robinson
Date: 2022-04-28T08:07:50-07:00
New Revision: 501cc4ae304f29e392a2b7e21c316e3abf954daa

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

LOG: [PS5] Rename a test to reflect its new purpose

Added: 
clang/test/Driver/ps4-ps5-cpu-defaults.cpp

Modified: 


Removed: 
clang/test/Driver/ps4-cpu-defaults.cpp



diff  --git a/clang/test/Driver/ps4-cpu-defaults.cpp 
b/clang/test/Driver/ps4-ps5-cpu-defaults.cpp
similarity index 100%
rename from clang/test/Driver/ps4-cpu-defaults.cpp
rename to clang/test/Driver/ps4-ps5-cpu-defaults.cpp



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

[PATCH] D123325: [Clang] Make enabling the new driver more generic

2022-04-28 Thread Joseph Huber via Phabricator via cfe-commits

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

Ping and update.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123325

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp


Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4381,8 +4381,11 @@
   bool IsDeviceOffloadAction = !(JA.isDeviceOffloading(Action::OFK_None) ||
  JA.isDeviceOffloading(Action::OFK_Host));
   bool IsHostOffloadingAction =
-  JA.isHostOffloading(Action::OFK_OpenMP) &&
-  !Args.hasArg(options::OPT_fno_openmp_new_driver);
+  (JA.isHostOffloading(Action::OFK_OpenMP) &&
+   Args.hasFlag(options::OPT_fopenmp_new_driver,
+ options::OPT_fno_offload_new_driver, true)) ||
+  Args.hasFlag(options::OPT_foffload_new_driver,
+  options::OPT_fno_offload_new_driver, false);
   bool IsUsingLTO = D.isUsingLTO(IsDeviceOffloadAction);
   auto LTOMode = D.getLTOMode(IsDeviceOffloadAction);
 
@@ -4678,7 +4681,9 @@
   // Only AMDGPU supports device-side LTO.
   if (IsDeviceOffloadAction &&
   !Args.hasFlag(options::OPT_fopenmp_new_driver,
-options::OPT_fno_openmp_new_driver, true) &&
+options::OPT_fno_offload_new_driver, true) &&
+  !Args.hasFlag(options::OPT_foffload_new_driver,
+options::OPT_fno_offload_new_driver, false) &&
   !Triple.isAMDGPU()) {
 D.Diag(diag::err_drv_unsupported_opt_for_target)
 << Args.getLastArg(options::OPT_foffload_lto,
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -3976,17 +3976,19 @@
   // Builder to be used to build offloading actions.
   OffloadingActionBuilder OffloadBuilder(C, Args, Inputs);
 
+  bool UseNewOffloadingDriver =
+  (C.isOffloadingHostKind(Action::OFK_OpenMP) &&
+  Args.hasFlag(options::OPT_fopenmp_new_driver,
+   options::OPT_fno_offload_new_driver, true)) ||
+  Args.hasFlag(options::OPT_foffload_new_driver,
+  options::OPT_fno_offload_new_driver, false);
+
   // Construct the actions to perform.
   HeaderModulePrecompileJobAction *HeaderModuleAction = nullptr;
   ExtractAPIJobAction *ExtractAPIAction = nullptr;
   ActionList LinkerInputs;
   ActionList MergerInputs;
 
-  bool UseNewOffloadingDriver =
-  C.isOffloadingHostKind(Action::OFK_OpenMP) &&
-  Args.hasFlag(options::OPT_fopenmp_new_driver,
-   options::OPT_fno_openmp_new_driver, true);
-
   for (auto &I : Inputs) {
 types::ID InputType = I.first;
 const Arg *InputArg = I.second;
@@ -4114,8 +4116,7 @@
 // Check if this Linker Job should emit a static library.
 if (ShouldEmitStaticLibrary(Args)) {
   LA = C.MakeAction(LinkerInputs, types::TY_Image);
-} else if (UseNewOffloadingDriver &&
-   C.getActiveOffloadKinds() != Action::OFK_None) {
+} else if (UseNewOffloadingDriver) {
   LA = C.MakeAction(LinkerInputs, types::TY_Image);
   LA->propagateHostOffloadInfo(C.getActiveOffloadKinds(),
/*BoundArch=*/nullptr);
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2532,10 +2532,14 @@
   PosFlag, NegFlag, 
BothFlags<[NoArgumentUnused, HelpHidden]>>;
 def static_openmp: Flag<["-"], "static-openmp">,
   HelpText<"Use the static host OpenMP runtime while linking.">;
+def foffload_new_driver : Flag<["-"], "foffload-new-driver">, 
Flags<[CC1Option]>, Group,
+  HelpText<"Use the new driver for offloading compilation.">;
+def fno_offload_new_driver : Flag<["-"], "fno-offload-new-driver">, 
Flags<[CC1Option]>, Group,
+  HelpText<"Don't Use the new driver for offloading compilation.">;
 def fopenmp_new_driver : Flag<["-"], "fopenmp-new-driver">, 
Flags<[CC1Option]>, Group,
   HelpText<"Use the new driver for OpenMP offloading.">;
 def fno_openmp_new_driver : Flag<["-"], "fno-openmp-new-driver">, 
Flags<[CC1Option]>, Group,
-  HelpText<"Don't use the new driver for OpenMP offloading.">;
+  Alias, HelpText<"Don't use the new driver for OpenMP 
offloading.">;
 def fno_optimize_sibling_calls : Flag<["-"], "fno-optimize-sibling-calls">, 
Group, Flags<[CC1Option]>,
   HelpText<"Disable tail call optimization, keeping the call stack accurate">,
   MarshallingInfoFlag>;


Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4

[PATCH] D124487: [HLSL] Adjust access specifier behavior

2022-04-28 Thread Chris Bieneman via Phabricator via cfe-commits

beanz added inline comments.



Comment at: 
clang-tools-extra/test/clang-apply-replacements/Inputs/crlf/crlf.cpp:1
-
-// This file intentionally uses a CRLF newlines!
-
-void foo() {
-  int *x = 0;
-}
+
+// This file intentionally uses a CRLF newlines!

aaron.ballman wrote:
> It looks like these are unintentional whitespace changes? (Same below)
Ha! I didn't notice this came along for the ride. This is from me trying to get 
the git file attributes setup correctly. This file should be crlf in the index 
(hence the title and comment) but is lf.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124487

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

[PATCH] D123773: [clang][analyzer][ctu] Make CTU a two phase analysis

2022-04-28 Thread Gabor Marton via Phabricator via cfe-commits

martong added inline comments.



Comment at: clang/test/Analysis/ctu-on-demand-parsing.c:23
+// FIXME On-demand ctu should be tested in the very same file that we have for
+// the PCH version, but with a different a different verify prefix (e.g.
+// -verfiy=on-demanc-ctu)




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123773

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

[PATCH] D124556: [NFC] Prevent shadowing a variable declared in `if`

2022-04-28 Thread Ken Matsui via Phabricator via cfe-commits

ken-matsui added a comment.

@hubert.reinterpretcast,

Thank you for your suggestion! I’ve updated the summary.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124556

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

[PATCH] D124606: Use `-text` git attribute instead of `text eol=...'

2022-04-28 Thread Aaron Puchert via Phabricator via cfe-commits

aaronpuchert added a comment.

Also I still don't understand what specifically this is fixing. What exactly 
was wrong about the previous configuration?

The commit message talks about "various workflows" but which workflows are 
that? Does that mean no one can use `.gitattributes` with something else than 
`-text` in LLVM?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124606

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

[clang] 062317f - [HIP] Add HIP runtime library arguments for linker

2022-04-28 Thread Yaxun Liu via cfe-commits


Author: Yaxun (Sam) Liu
Date: 2022-04-28T11:12:23-04:00
New Revision: 062317f72ebfc19b0f3733b4181bb09344707653

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

LOG: [HIP] Add HIP runtime library arguments for linker

Add -L -l options for linker.

Reviewed by: Artem Belevich

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

Added: 
clang/test/Driver/hip-runtime-libs-linux.hip
clang/test/Driver/hip-runtime-libs-msvc.hip

Modified: 
clang/include/clang/Driver/Options.td
clang/include/clang/Driver/ToolChain.h
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/lib/Driver/ToolChains/CommonArgs.h
clang/lib/Driver/ToolChains/Gnu.cpp
clang/lib/Driver/ToolChains/Linux.cpp
clang/lib/Driver/ToolChains/Linux.h
clang/lib/Driver/ToolChains/MSVC.cpp
clang/lib/Driver/ToolChains/MSVC.h

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 780e814bef396..d2097427ed711 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -927,6 +927,8 @@ def cuda_gpu_arch_EQ : Joined<["--"], "cuda-gpu-arch=">, 
Flags<[NoXarchOption]>,
   Alias;
 def hip_link : Flag<["--"], "hip-link">,
   HelpText<"Link clang-offload-bundler bundles for HIP">;
+def no_hip_rt: Flag<["-"], "no-hip-rt">,
+  HelpText<"Do not link against HIP runtime libraries">;
 def no_offload_arch_EQ : Joined<["--"], "no-offload-arch=">, 
Flags<[NoXarchOption]>,
   HelpText<"Remove CUDA/HIP offloading device architecture (e.g. sm_35, 
gfx906) from the list of devices to compile for. "
"'all' resets the list to its default value.">;

diff  --git a/clang/include/clang/Driver/ToolChain.h 
b/clang/include/clang/Driver/ToolChain.h
index a3da1db2f15ef..5d95a644fde1a 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -696,6 +696,11 @@ class ToolChain {
   virtual llvm::SmallVector
   getHIPDeviceLibs(const llvm::opt::ArgList &Args) const;
 
+  /// Add the system specific linker arguments to use
+  /// for the given HIP runtime library type.
+  virtual void AddHIPRuntimeLibArgs(const llvm::opt::ArgList &Args,
+llvm::opt::ArgStringList &CmdArgs) const {}
+
   /// Return sanitizers which are available in this toolchain.
   virtual SanitizerMask getSupportedSanitizers() const;
 

diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index 96a54228626f6..03a887a7527b7 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -2089,3 +2089,17 @@ void tools::addOpenMPDeviceRTL(const Driver &D,
   << LibOmpTargetName << ArchPrefix;
   }
 }
+void tools::addHIPRuntimeLibArgs(const ToolChain &TC,
+ const llvm::opt::ArgList &Args,
+ llvm::opt::ArgStringList &CmdArgs) {
+  if (Args.hasArg(options::OPT_hip_link) &&
+  !Args.hasArg(options::OPT_nostdlib) &&
+  !Args.hasArg(options::OPT_no_hip_rt)) {
+TC.AddHIPRuntimeLibArgs(Args, CmdArgs);
+  } else {
+// Claim "no HIP libraries" arguments if any
+for (auto Arg : Args.filtered(options::OPT_no_hip_rt)) {
+  Arg->claim();
+}
+  }
+}

diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.h 
b/clang/lib/Driver/ToolChains/CommonArgs.h
index 2bba1ee285e62..1c43cd329b85c 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.h
+++ b/clang/lib/Driver/ToolChains/CommonArgs.h
@@ -120,6 +120,9 @@ bool addOpenMPRuntime(llvm::opt::ArgStringList &CmdArgs, 
const ToolChain &TC,
   bool ForceStaticHostRuntime = false,
   bool IsOffloadingHost = false, bool GompNeedsRT = false);
 
+void addHIPRuntimeLibArgs(const ToolChain &TC, const llvm::opt::ArgList &Args,
+  llvm::opt::ArgStringList &CmdArgs);
+
 const char *getAsNeededOption(const ToolChain &TC, bool as_needed);
 
 llvm::opt::Arg *getLastProfileUseArg(const llvm::opt::ArgList &Args);

diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index e0fcabc3e250a..183828dcaa734 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -580,6 +580,9 @@ void tools::gnutools::Linker::ConstructJob(Compilation &C, 
const JobAction &JA,
   bool NeedsXRayDeps = addXRayRuntime(ToolChain, Args, CmdArgs);
   addLinkerCompressDebugSectionsOption(ToolChain, Args, CmdArgs);
   AddLinkerInputs(ToolChain, Inputs, Args, CmdArgs, JA);
+
+  addHIPRuntimeLibArgs(ToolChain, Args, CmdArgs);
+
   // The profile runtime also needs access to system libraries.
   getToolChain().addProfileRTLibs(Args, CmdArgs);
 

diff  --git a/clang/lib/Driver/Tool

1 2 3 >

1 - 100 of 234 matches

Mail list logo