[PATCH] D105692: [analyzer][solver][NFC] Introduce ConstraintAssignor

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

Hi,

When compiling with gcc I see the following new warnings with this patch:

  [4/22] Building CXX object 
tools/clang/lib/StaticAnalyzer/Core/CMakeFiles/obj.clangStaticAnalyzerCore.dir/RangeConstraintManager.cpp.o
  
/repo/uabelho/master-github/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2395:17:
 warning: 'clang::ento::ProgramStateRef 
{anonymous}::RangeConstraintManager::setRange(clang::ento::ProgramStateRef, 
{anonymous}::EquivalenceClass, clang::ento::RangeSet)' defined but not used 
[-Wunused-function]
   2395 | ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef 
State,
| ^~
  
/repo/uabelho/master-github/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2384:10:
 warning: 'clang::ento::RangeSet 
{anonymous}::RangeConstraintManager::getRange(clang::ento::ProgramStateRef, 
{anonymous}::EquivalenceClass)' defined but not used [-Wunused-function]
   2384 | RangeSet RangeConstraintManager::getRange(ProgramStateRef State,
|  ^~

Will those methods be used or can they be removed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105692

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

[PATCH] D103096: [analyzer] Implement cast for ranges of symbolic integers.

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added a comment.

In D103096#2877818 , @ASDenysPetrov 
wrote:

> Made `ignoreCast` non-virtual.
> P.S.  IMO, this change is not something that can be taken as a pattern, 
> though.

It is already a pattern in other type hierarchies.
Virtual functions are only good, when they can have multiple implementations.  
`ignoreCasts` by its name can have only one implementation and couldn't be 
virtual.  That's it!  It is more useable now, and less confusing for its users. 
 The fact that its definition lives in some other cpp file doesn't change it.




Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h:293-296
+SymbolRef Sym = Operand;
+while (isa(Sym))
+  Sym = cast(Sym)->Operand;
+return Sym;

ASDenysPetrov wrote:
> vsavchenko wrote:
> > ASDenysPetrov wrote:
> > > vsavchenko wrote:
> > > > ASDenysPetrov wrote:
> > > > > vsavchenko wrote:
> > > > > > ASDenysPetrov wrote:
> > > > > > > vsavchenko wrote:
> > > > > > > > 
> > > > > > > Do you think the recursive call is better than the loop? But, I 
> > > > > > > guess, I see your point. You option could be safer if we had 
> > > > > > > another implementation of the virtual method. Or you think such 
> > > > > > > alike cast symbol is possible in the future? Well, for now 
> > > > > > > `ignoreCasts` doesn't make sense to any other `Expr` successors.
> > > > > > Oh, wait, why is it even virtual?  I don't think that it should be 
> > > > > > virtual.
> > > > > > Are similar functions in `Expr` virtual?
> > > > > > And I think that this implementation should live in `SymExpr` 
> > > > > > directly.  Then it would look like:
> > > > > > ```
> > > > > > if (const SymbolCast *ThisAsCast = dyn_cast(this)) {
> > > > > >   return ThisAsCast->ignoreCasts();
> > > > > > }
> > > > > > return this;
> > > > > > ```
> > > > > Yes, `SymExpr` is an abstract class. And because of limitations and 
> > > > > dependency of inheritance we are not able to know the implementaion 
> > > > > of `SymbolCast`. Unfortunately, this is not a CRTP.
> > > > Re-read my comment, please.
> > > > Oh, wait, why is it even virtual?
> > > `ignoreCasts` is a virtual function because I haven't found any other way 
> > > to implement it better.
> > > > I don't think that it should be virtual.
> > > Unfortunately, this is not a CRTP to avoid dynamic linking.
> > > > Are similar functions in Expr virtual?
> > > `SymExpr` is an abstract class. I'm not sure about similarity but 
> > > `SymExpr` has such virtual methods:
> > >   - computeComplexity
> > >   - getType 
> > >   - getOriginRegion
> > > > And I think that this implementation should live in SymExpr directly.
> > > It's impossible due to `SymExpr` implementation design. `SymExpr` knows 
> > > nothing about implementation details of `SymbolCast` to invoke 
> > > `ignoreCasts()`.
> > > 
> > a) `Expr` is also an abstract class
> > b) I put the implementation right there in the comment above.  I don't see 
> > any reasons not to use it.
> > c) I don't buy it about "impossible" and "implementation design" because 
> > you can always declare function in one place and define it in the other.
> I think I achieved of what you've been concerned.
This function should be removed then.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:3002-3004
+  std::tie(St, Sym, New) = modifySymbolAndConstraints(St, Sym, New);
+  if (!St)
+return nullptr;

No, please, remove duplication by putting it inside of the constraint assignor. 
 It is designed specifically so we don't duplicate code around `assumeSymXX` 
functions.


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

https://reviews.llvm.org/D103096

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

[clang] b0d38ad - [clang][Analyzer] Add symbol uninterestingness to bug report.

[Balázs Kéri via cfe-commits]

Author: Balázs Kéri
Date: 2021-07-15T10:02:18+02:00
New Revision: b0d38ad0bc254b887123cd063a5f0db30a80f938

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

LOG: [clang][Analyzer] Add symbol uninterestingness to bug report.

`PathSensitiveBughReport` has a function to mark a symbol as interesting but
it was not possible to clear this flag. This can be useful in some cases,
so the functionality is added.

Reviewed By: NoQ

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

Added: 
clang/unittests/StaticAnalyzer/BugReportInterestingnessTest.cpp

Modified: 
clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
clang/lib/StaticAnalyzer/Core/BugReporter.cpp
clang/unittests/StaticAnalyzer/CMakeLists.txt
clang/unittests/StaticAnalyzer/Reusables.h

Removed: 




diff  --git a/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h 
b/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
index 99cd24a52f2df..3c93ebeccde8d 100644
--- a/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
+++ b/clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
@@ -432,6 +432,8 @@ class PathSensitiveBugReport : public BugReport {
   void markInteresting(SymbolRef sym, bugreporter::TrackingKind TKind =
   bugreporter::TrackingKind::Thorough);
 
+  void markNotInteresting(SymbolRef sym);
+
   /// Marks a region as interesting. Different kinds of interestingness will
   /// be processed 
diff erently by visitors (e.g. if the tracking kind is
   /// condition, will append "will be used as a condition" to the message).
@@ -439,6 +441,8 @@ class PathSensitiveBugReport : public BugReport {
   const MemRegion *R,
   bugreporter::TrackingKind TKind = bugreporter::TrackingKind::Thorough);
 
+  void markNotInteresting(const MemRegion *R);
+
   /// Marks a symbolic value as interesting. Different kinds of interestingness
   /// will be processed 
diff erently by visitors (e.g. if the tracking kind is
   /// condition, will append "will be used as a condition" to the message).

diff  --git a/clang/lib/StaticAnalyzer/Core/BugReporter.cpp 
b/clang/lib/StaticAnalyzer/Core/BugReporter.cpp
index 6ace986b4e0df..cf4581e8f67b9 100644
--- a/clang/lib/StaticAnalyzer/Core/BugReporter.cpp
+++ b/clang/lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -2249,10 +2249,22 @@ void PathSensitiveBugReport::markInteresting(SymbolRef 
sym,
 
   insertToInterestingnessMap(InterestingSymbols, sym, TKind);
 
+  // FIXME: No tests exist for this code and it is questionable:
+  // How to handle multiple metadata for the same region?
   if (const auto *meta = dyn_cast(sym))
 markInteresting(meta->getRegion(), TKind);
 }
 
+void PathSensitiveBugReport::markNotInteresting(SymbolRef sym) {
+  if (!sym)
+return;
+  InterestingSymbols.erase(sym);
+
+  // The metadata part of markInteresting is not reversed here.
+  // Just making the same region not interesting is incorrect
+  // in specific cases.
+}
+
 void PathSensitiveBugReport::markInteresting(const MemRegion *R,
  bugreporter::TrackingKind TKind) {
   if (!R)
@@ -2265,6 +2277,17 @@ void PathSensitiveBugReport::markInteresting(const 
MemRegion *R,
 markInteresting(SR->getSymbol(), TKind);
 }
 
+void PathSensitiveBugReport::markNotInteresting(const MemRegion *R) {
+  if (!R)
+return;
+
+  R = R->getBaseRegion();
+  InterestingRegions.erase(R);
+
+  if (const auto *SR = dyn_cast(R))
+markNotInteresting(SR->getSymbol());
+}
+
 void PathSensitiveBugReport::markInteresting(SVal V,
  bugreporter::TrackingKind TKind) {
   markInteresting(V.getAsRegion(), TKind);

diff  --git a/clang/unittests/StaticAnalyzer/BugReportInterestingnessTest.cpp 
b/clang/unittests/StaticAnalyzer/BugReportInterestingnessTest.cpp
new file mode 100644
index 0..bc1b8edf05356
--- /dev/null
+++ b/clang/unittests/StaticAnalyzer/BugReportInterestingnessTest.cpp
@@ -0,0 +1,162 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "Reusables.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
+#include "clang/StaticAnalyzer/Core/Checker.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
+#include "clang/StaticAnalyzer/Core/Pat

[PATCH] D105637: [clang][Analyzer] Add symbol uninterestingness to bug report.

[Balázs Kéri 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 rGb0d38ad0bc25: [clang][Analyzer] Add symbol uninterestingness 
to bug report. (authored by balazske).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105637

Files:
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
  clang/lib/StaticAnalyzer/Core/BugReporter.cpp
  clang/unittests/StaticAnalyzer/BugReportInterestingnessTest.cpp
  clang/unittests/StaticAnalyzer/CMakeLists.txt
  clang/unittests/StaticAnalyzer/Reusables.h

Index: clang/unittests/StaticAnalyzer/Reusables.h
===
--- clang/unittests/StaticAnalyzer/Reusables.h
+++ clang/unittests/StaticAnalyzer/Reusables.h
@@ -10,9 +10,10 @@
 #define LLVM_CLANG_UNITTESTS_STATICANALYZER_REUSABLES_H
 
 #include "clang/ASTMatchers/ASTMatchFinder.h"
-#include "clang/Frontend/CompilerInstance.h"
 #include "clang/CrossTU/CrossTranslationUnit.h"
+#include "clang/Frontend/CompilerInstance.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h"
+#include "gtest/gtest.h"
 
 namespace clang {
 namespace ento {
@@ -66,6 +67,88 @@
 Eng(CTU, AMgr, &VisitedCallees, &FS, ExprEngine::Inline_Regular) {}
 };
 
+struct ExpectedLocationTy {
+  unsigned Line;
+  unsigned Column;
+
+  void testEquality(SourceLocation L, SourceManager &SM) const {
+EXPECT_EQ(SM.getSpellingLineNumber(L), Line);
+EXPECT_EQ(SM.getSpellingColumnNumber(L), Column);
+  }
+};
+
+struct ExpectedRangeTy {
+  ExpectedLocationTy Begin;
+  ExpectedLocationTy End;
+
+  void testEquality(SourceRange R, SourceManager &SM) const {
+Begin.testEquality(R.getBegin(), SM);
+End.testEquality(R.getEnd(), SM);
+  }
+};
+
+struct ExpectedPieceTy {
+  ExpectedLocationTy Loc;
+  std::string Text;
+  std::vector Ranges;
+
+  void testEquality(const PathDiagnosticPiece &Piece, SourceManager &SM) {
+Loc.testEquality(Piece.getLocation().asLocation(), SM);
+EXPECT_EQ(Piece.getString(), Text);
+EXPECT_EQ(Ranges.size(), Piece.getRanges().size());
+for (const auto &RangeItem : llvm::enumerate(Piece.getRanges()))
+  Ranges[RangeItem.index()].testEquality(RangeItem.value(), SM);
+  }
+};
+
+struct ExpectedDiagTy {
+  ExpectedLocationTy Loc;
+  std::string VerboseDescription;
+  std::string ShortDescription;
+  std::string CheckerName;
+  std::string BugType;
+  std::string Category;
+  std::vector Path;
+
+  void testEquality(const PathDiagnostic &Diag, SourceManager &SM) {
+Loc.testEquality(Diag.getLocation().asLocation(), SM);
+EXPECT_EQ(Diag.getVerboseDescription(), VerboseDescription);
+EXPECT_EQ(Diag.getShortDescription(), ShortDescription);
+EXPECT_EQ(Diag.getCheckerName(), CheckerName);
+EXPECT_EQ(Diag.getBugType(), BugType);
+EXPECT_EQ(Diag.getCategory(), Category);
+
+EXPECT_EQ(Path.size(), Diag.path.size());
+for (const auto &PieceItem : llvm::enumerate(Diag.path)) {
+  if (PieceItem.index() < Path.size())
+Path[PieceItem.index()].testEquality(*PieceItem.value(), SM);
+}
+  }
+};
+
+using ExpectedDiagsTy = std::vector;
+
+// A consumer to verify the generated diagnostics.
+class VerifyPathDiagnosticConsumer : public PathDiagnosticConsumer {
+  ExpectedDiagsTy ExpectedDiags;
+  SourceManager &SM;
+
+public:
+  VerifyPathDiagnosticConsumer(ExpectedDiagsTy &&ExpectedDiags,
+   SourceManager &SM)
+  : ExpectedDiags(ExpectedDiags), SM(SM) {}
+
+  StringRef getName() const override { return "verify test diagnostics"; }
+
+  void FlushDiagnosticsImpl(std::vector &Diags,
+FilesMade *filesMade) override {
+EXPECT_EQ(Diags.size(), ExpectedDiags.size());
+for (const auto &Item : llvm::enumerate(Diags))
+  if (Item.index() < ExpectedDiags.size())
+ExpectedDiags[Item.index()].testEquality(*Item.value(), SM);
+  }
+};
+
 } // namespace ento
 } // namespace clang
 
Index: clang/unittests/StaticAnalyzer/CMakeLists.txt
===
--- clang/unittests/StaticAnalyzer/CMakeLists.txt
+++ clang/unittests/StaticAnalyzer/CMakeLists.txt
@@ -5,6 +5,7 @@
 
 add_clang_unittest(StaticAnalysisTests
   AnalyzerOptionsTest.cpp
+  BugReportInterestingnessTest.cpp
   CallDescriptionTest.cpp
   CallEventTest.cpp
   FalsePositiveRefutationBRVisitorTest.cpp
Index: clang/unittests/StaticAnalyzer/BugReportInterestingnessTest.cpp
===
--- /dev/null
+++ clang/unittests/StaticAnalyzer/BugReportInterestingnessTest.cpp
@@ -0,0 +1,162 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// S

[PATCH] D103096: [analyzer] Implement cast for ranges of symbolic integers.

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

@vsavchenko

> It is already a pattern in other type hierarchies.

I just rarely met them. And it was hard to me reading the code searching for 
implementation all over the places.




Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h:293-296
+SymbolRef Sym = Operand;
+while (isa(Sym))
+  Sym = cast(Sym)->Operand;
+return Sym;

vsavchenko wrote:
> ASDenysPetrov wrote:
> > vsavchenko wrote:
> > > ASDenysPetrov wrote:
> > > > vsavchenko wrote:
> > > > > ASDenysPetrov wrote:
> > > > > > vsavchenko wrote:
> > > > > > > ASDenysPetrov wrote:
> > > > > > > > vsavchenko wrote:
> > > > > > > > > 
> > > > > > > > Do you think the recursive call is better than the loop? But, I 
> > > > > > > > guess, I see your point. You option could be safer if we had 
> > > > > > > > another implementation of the virtual method. Or you think such 
> > > > > > > > alike cast symbol is possible in the future? Well, for now 
> > > > > > > > `ignoreCasts` doesn't make sense to any other `Expr` successors.
> > > > > > > Oh, wait, why is it even virtual?  I don't think that it should 
> > > > > > > be virtual.
> > > > > > > Are similar functions in `Expr` virtual?
> > > > > > > And I think that this implementation should live in `SymExpr` 
> > > > > > > directly.  Then it would look like:
> > > > > > > ```
> > > > > > > if (const SymbolCast *ThisAsCast = dyn_cast(this)) {
> > > > > > >   return ThisAsCast->ignoreCasts();
> > > > > > > }
> > > > > > > return this;
> > > > > > > ```
> > > > > > Yes, `SymExpr` is an abstract class. And because of limitations and 
> > > > > > dependency of inheritance we are not able to know the implementaion 
> > > > > > of `SymbolCast`. Unfortunately, this is not a CRTP.
> > > > > Re-read my comment, please.
> > > > > Oh, wait, why is it even virtual?
> > > > `ignoreCasts` is a virtual function because I haven't found any other 
> > > > way to implement it better.
> > > > > I don't think that it should be virtual.
> > > > Unfortunately, this is not a CRTP to avoid dynamic linking.
> > > > > Are similar functions in Expr virtual?
> > > > `SymExpr` is an abstract class. I'm not sure about similarity but 
> > > > `SymExpr` has such virtual methods:
> > > >   - computeComplexity
> > > >   - getType 
> > > >   - getOriginRegion
> > > > > And I think that this implementation should live in SymExpr directly.
> > > > It's impossible due to `SymExpr` implementation design. `SymExpr` knows 
> > > > nothing about implementation details of `SymbolCast` to invoke 
> > > > `ignoreCasts()`.
> > > > 
> > > a) `Expr` is also an abstract class
> > > b) I put the implementation right there in the comment above.  I don't 
> > > see any reasons not to use it.
> > > c) I don't buy it about "impossible" and "implementation design" because 
> > > you can always declare function in one place and define it in the other.
> > I think I achieved of what you've been concerned.
> This function should be removed then.
NP.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:3002-3004
+  std::tie(St, Sym, New) = modifySymbolAndConstraints(St, Sym, New);
+  if (!St)
+return nullptr;

vsavchenko wrote:
> No, please, remove duplication by putting it inside of the constraint 
> assignor.  It is designed specifically so we don't duplicate code around 
> `assumeSymXX` functions.
+1. That's what I've recently thought about. :)


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

https://reviews.llvm.org/D103096

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

[PATCH] D104925: [Analyzer] Improve report of file read at end-of-file condition.

[Balázs Kéri via Phabricator via cfe-commits]

balazske marked 4 inline comments as done.
balazske added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:419-421
+  const CheckerNameRef CheckerName;
+  SymbolRef StreamSym;
+  const ExplodedNode *NotePosition;

balazske wrote:
> NoQ wrote:
> > I guess it's a matter of preference but I really don't understand the need 
> > to define a structure when a lambda is sufficient. Lambda is the intended 
> > syntax sugar for exactly what you have written.
> The reason is that the `NoteTag` is added at more than one place. And I do 
> not want a function that returns a lambda.
Problem solved: see `constructSetEofNoteTag`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104925

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

[PATCH] D105384: [NVPTX, CUDA] Add .and.popc variant of the b1 MMA instruction.

[Steffen Larsen via Phabricator via cfe-commits]

steffenlarsen accepted this revision.
steffenlarsen added a comment.

LGTM! Are the test failures related to this, you reckon?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105384

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

[PATCH] D106044: [RISCV] Update to vcpop.m, vlm.v and vsm.v according to v1.0-rc1.

[Roger Ferrer Ibanez via Phabricator via cfe-commits]

rogfer01 added a comment.

I'm confused because the PDF at 
https://github.com/riscv/riscv-v-spec/releases/tag/v1.0-rc1  doesn't seem to 
describe  `vcpop.m`.

I can see this has changed in the ToT 
https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#changes-from-v1-0-rc1

Perhaps this will be part of a future 1.0-rc2?




Comment at: llvm/test/CodeGen/RISCV/rvv/vse1-rv64.ll:12
+; CHECK-NEXT:sd ra, 8(sp) # 8-byte Folded Spill
+; CHECK-NEXT:call llvm.riscv.vse1.nxv1i1@plt
+; CHECK-NEXT:ld ra, 8(sp) # 8-byte Folded Reload

Is this expected?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106044

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

[PATCH] D103849: Fix undeduced type when instanciating template member

[serge via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG4b219051a331: Fix undeduced type assert (authored by 
serge-sans-paille).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103849

Files:
  clang/lib/AST/Expr.cpp
  clang/test/CodeGenCXX/auto-variable-template.cpp


Index: clang/test/CodeGenCXX/auto-variable-template.cpp
===
--- clang/test/CodeGenCXX/auto-variable-template.cpp
+++ clang/test/CodeGenCXX/auto-variable-template.cpp
@@ -12,3 +12,21 @@
 
 // CHECK: define{{.*}} i32 @main()
 // CHECK: call void @_ZNK1fclEv(%struct.f* {{[^,]*}} @_Z9vtemplateIiE)
+
+template 
+struct pack {
+  template 
+  constexpr static auto some_boolean_cx_value = true;
+};
+
+auto usage() {
+  return pack::some_boolean_cx_value;
+}
+
+// CHECK: define{{.*}} i1 @_Z5usagev()
+
+auto otherusage() {
+  return pack{}.some_boolean_cx_value;
+}
+
+// CHECK: define{{.*}} i1 @_Z10otherusagev()
Index: clang/lib/AST/Expr.cpp
===
--- clang/lib/AST/Expr.cpp
+++ clang/lib/AST/Expr.cpp
@@ -490,6 +490,8 @@
 
 void DeclRefExpr::setDecl(ValueDecl *NewD) {
   D = NewD;
+  if (getType()->isUndeducedType())
+setType(NewD->getType());
   setDependence(computeDependence(this, NewD->getASTContext()));
 }
 
@@ -1722,8 +1724,10 @@
   return new (Mem) MemberExpr(EmptyShell());
 }
 
-void MemberExpr::setMemberDecl(ValueDecl *D) {
-  MemberDecl = D;
+void MemberExpr::setMemberDecl(ValueDecl *NewD) {
+  MemberDecl = NewD;
+  if (getType()->isUndeducedType())
+setType(NewD->getType());
   setDependence(computeDependence(this));
 }
 


Index: clang/test/CodeGenCXX/auto-variable-template.cpp
===
--- clang/test/CodeGenCXX/auto-variable-template.cpp
+++ clang/test/CodeGenCXX/auto-variable-template.cpp
@@ -12,3 +12,21 @@
 
 // CHECK: define{{.*}} i32 @main()
 // CHECK: call void @_ZNK1fclEv(%struct.f* {{[^,]*}} @_Z9vtemplateIiE)
+
+template 
+struct pack {
+  template 
+  constexpr static auto some_boolean_cx_value = true;
+};
+
+auto usage() {
+  return pack::some_boolean_cx_value;
+}
+
+// CHECK: define{{.*}} i1 @_Z5usagev()
+
+auto otherusage() {
+  return pack{}.some_boolean_cx_value;
+}
+
+// CHECK: define{{.*}} i1 @_Z10otherusagev()
Index: clang/lib/AST/Expr.cpp
===
--- clang/lib/AST/Expr.cpp
+++ clang/lib/AST/Expr.cpp
@@ -490,6 +490,8 @@
 
 void DeclRefExpr::setDecl(ValueDecl *NewD) {
   D = NewD;
+  if (getType()->isUndeducedType())
+setType(NewD->getType());
   setDependence(computeDependence(this, NewD->getASTContext()));
 }
 
@@ -1722,8 +1724,10 @@
   return new (Mem) MemberExpr(EmptyShell());
 }
 
-void MemberExpr::setMemberDecl(ValueDecl *D) {
-  MemberDecl = D;
+void MemberExpr::setMemberDecl(ValueDecl *NewD) {
+  MemberDecl = NewD;
+  if (getType()->isUndeducedType())
+setType(NewD->getType());
   setDependence(computeDependence(this));
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 4b21905 - Fix undeduced type assert

[via cfe-commits]

Author: serge-sans-paille
Date: 2021-07-15T10:52:25+02:00
New Revision: 4b219051a331d49c391fe452548bc220bcfe8ea3

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

LOG: Fix undeduced type assert

If the instantiation of a member variable makes it possible to
compute a previously undeduced type, we should use that piece of
information.

Fix bug#50590

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

Added: 


Modified: 
clang/lib/AST/Expr.cpp
clang/test/CodeGenCXX/auto-variable-template.cpp

Removed: 




diff  --git a/clang/lib/AST/Expr.cpp b/clang/lib/AST/Expr.cpp
index 842b9c0a8a0e2..ebf87618e1277 100644
--- a/clang/lib/AST/Expr.cpp
+++ b/clang/lib/AST/Expr.cpp
@@ -490,6 +490,8 @@ DeclRefExpr *DeclRefExpr::CreateEmpty(const ASTContext 
&Context,
 
 void DeclRefExpr::setDecl(ValueDecl *NewD) {
   D = NewD;
+  if (getType()->isUndeducedType())
+setType(NewD->getType());
   setDependence(computeDependence(this, NewD->getASTContext()));
 }
 
@@ -1722,8 +1724,10 @@ MemberExpr *MemberExpr::CreateEmpty(const ASTContext 
&Context,
   return new (Mem) MemberExpr(EmptyShell());
 }
 
-void MemberExpr::setMemberDecl(ValueDecl *D) {
-  MemberDecl = D;
+void MemberExpr::setMemberDecl(ValueDecl *NewD) {
+  MemberDecl = NewD;
+  if (getType()->isUndeducedType())
+setType(NewD->getType());
   setDependence(computeDependence(this));
 }
 

diff  --git a/clang/test/CodeGenCXX/auto-variable-template.cpp 
b/clang/test/CodeGenCXX/auto-variable-template.cpp
index 79a145a73cf31..ae7154f3cb142 100644
--- a/clang/test/CodeGenCXX/auto-variable-template.cpp
+++ b/clang/test/CodeGenCXX/auto-variable-template.cpp
@@ -12,3 +12,21 @@ int main() { vtemplate(); }
 
 // CHECK: define{{.*}} i32 @main()
 // CHECK: call void @_ZNK1fclEv(%struct.f* {{[^,]*}} @_Z9vtemplateIiE)
+
+template 
+struct pack {
+  template 
+  constexpr static auto some_boolean_cx_value = true;
+};
+
+auto usage() {
+  return pack::some_boolean_cx_value;
+}
+
+// CHECK: define{{.*}} i1 @_Z5usagev()
+
+auto otherusage() {
+  return pack{}.some_boolean_cx_value;
+}
+
+// CHECK: define{{.*}} i1 @_Z10otherusagev()



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

[PATCH] D105974: [analyzer] Do not assume that all pointers have the same bitwidth as void*

[Vince Bridgers via Phabricator via cfe-commits]

vabridgers updated this revision to Diff 358869.
vabridgers added a comment.

update test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105974

Files:
  clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
  clang/test/Analysis/solver-sym-simplification-ptr-bool.cl


Index: clang/test/Analysis/solver-sym-simplification-ptr-bool.cl
===
--- /dev/null
+++ clang/test/Analysis/solver-sym-simplification-ptr-bool.cl
@@ -0,0 +1,23 @@
+// RUN: %clang_analyze_cc1 -triple amdgcn-unknown-unknown -analyze 
-analyzer-checker=core %s
+
+// expected-no-diagnostics
+
+// This test case covers an issue found in the static analyzer
+// solver where pointer sizes were assumed. Pointer sizes may vary on other
+// architectures. This issue was originally discovered on a downstream,
+// custom target, this assert occurs on the custom target and this one
+// without the fix, and is fixed with this change.
+//
+// The assertion appears to be happening as a result of evaluating the
+// SymIntExpr (reg_$0) != 0U in VisitSymIntExpr located in
+// SimpleSValBuilder.cpp. The LHS is evaluated to 32b and the RHS is
+// evaluated to 16b. This eventually leads to the assertion in APInt.h.
+//
+// APInt.h:1151: bool llvm::APInt::operator==(const llvm::APInt &) const: 
Assertion `BitWidth == RHS.BitWidth && "Comparison requires equal bit widths"'
+// 
+void test(__attribute__((address_space(256))) int * p) {
+  __attribute__((address_space(256))) int * q = p-1;
+  if (q) {}
+  if (q) {}
+  (void)q;
+} 
Index: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -712,9 +712,23 @@
   // symbols to use, only content metadata.
   return nonloc::SymbolVal(SymMgr.getExtentSymbol(FTR));
 
-if (const SymbolicRegion *SymR = R->getSymbolicBase())
-  return makeNonLoc(SymR->getSymbol(), BO_NE,
-BasicVals.getZeroWithPtrWidth(), CastTy);
+if (const SymbolicRegion *SymR = R->getSymbolicBase()) {
+  SymbolRef Sym = SymR->getSymbol();
+  QualType Ty = Sym->getType();
+  // This change is needed for architectures with varying
+  // pointer widths. See the amdgcn opencl reproducer with
+  // this change as an example: solver-sym-simplification-ptr-bool.cl
+  // FIXME: We could encounter a reference here,
+  //try returning a concrete 'true' since it might
+  //be easier on the solver.
+  // FIXME: Cleanup remainder of `getZeroWithPtrWidth ()`
+  //and `getIntWithPtrWidth()` functions to prevent future
+  //confusion
+  const llvm::APSInt &Zero = Ty->isReferenceType()
+ ? BasicVals.getZeroWithPtrWidth()
+ : BasicVals.getZeroWithTypeSize(Ty);
+  return makeNonLoc(Sym, BO_NE, Zero, CastTy);
+}
 // Non-symbolic memory regions are always true.
 return makeTruthVal(true, CastTy);
   }


Index: clang/test/Analysis/solver-sym-simplification-ptr-bool.cl
===
--- /dev/null
+++ clang/test/Analysis/solver-sym-simplification-ptr-bool.cl
@@ -0,0 +1,23 @@
+// RUN: %clang_analyze_cc1 -triple amdgcn-unknown-unknown -analyze -analyzer-checker=core %s
+
+// expected-no-diagnostics
+
+// This test case covers an issue found in the static analyzer
+// solver where pointer sizes were assumed. Pointer sizes may vary on other
+// architectures. This issue was originally discovered on a downstream,
+// custom target, this assert occurs on the custom target and this one
+// without the fix, and is fixed with this change.
+//
+// The assertion appears to be happening as a result of evaluating the
+// SymIntExpr (reg_$0) != 0U in VisitSymIntExpr located in
+// SimpleSValBuilder.cpp. The LHS is evaluated to 32b and the RHS is
+// evaluated to 16b. This eventually leads to the assertion in APInt.h.
+//
+// APInt.h:1151: bool llvm::APInt::operator==(const llvm::APInt &) const: Assertion `BitWidth == RHS.BitWidth && "Comparison requires equal bit widths"'
+// 
+void test(__attribute__((address_space(256))) int * p) {
+  __attribute__((address_space(256))) int * q = p-1;
+  if (q) {}
+  if (q) {}
+  (void)q;
+} 
Index: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -712,9 +712,23 @@
   // symbols to use, only content metadata.
   return nonloc::SymbolVal(SymMgr.getExtentSymbol(FTR));
 
-if (const SymbolicRegion *SymR = R->getSymbolicBase())
-  return makeNonLoc(SymR->getSymbol(), BO_NE,
-Basi

[PATCH] D106044: [RISCV] Update to vcpop.m, vlm.v and vsm.v according to v1.0-rc1.

[Hsiangkai Wang via Phabricator via cfe-commits]

HsiangKai added a comment.

In D106044#2879361 , @rogfer01 wrote:

> I'm confused because the PDF at 
> https://github.com/riscv/riscv-v-spec/releases/tag/v1.0-rc1  doesn't seem to 
> describe  `vcpop.m`.
>
> I can see this has changed in the ToT 
> https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#changes-from-v1-0-rc1
>
> Perhaps this will be part of a future 1.0-rc2?

You are right. I will revert it. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106044

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

[PATCH] D106049: [RISCV] Update to vfredusum.vs and vfwredusum.vs according to v1.0-rc1.

[Fraser Cormack via Phabricator via cfe-commits]

frasercrmck added a comment.

Duplicate of D105690 ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106049

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

[PATCH] D105564: Fix for DWARF parsing to better handle auto return type for member functions

[Raphael Isemann via Phabricator via cfe-commits]

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

I'm really sorry, I don't understand what kind of review is expected here given 
the state of this patch.

- The patch **still** doesn't include the tests that I asked for in my previous 
comment: https://reviews.llvm.org/D105564#2871703
- I applied the patch locally and **again** LLDB just crashes on the first 
corner case that I test.
- I genuinely can't comprehend why my crash reproducer got copied one-to-one 
into this patch as a real test case. It's just meant to make it straightforward 
to reproduce the crash I ran into, but the 'test' itself does completely bogus 
things like checking for the *wrong* return value, declaring dead code, all the 
identifiers are just 'bla', etc...

I think it's part of a good review to actually compile and poke around at the 
code that I'm requested to review. It's also fine if I run into some weird 
corner cases while doing some manual testing (one could argue that's the whole 
point of the review. I'm always happy when someone invests the time to do that 
for my patches). But this patch feels like every reviewer either has to just 
hope this just works or IKEA-style assemble their own tests at home. This is 
fine for an RFC/WIP patch, but this is clearly aiming to be accepted at the 
moment.

Given how long everyone's review queue is, it seems frankly unfair to other 
people to postpone reviewing their patches and instead spend time repeatedly 
reviewing this patch by manually compiling and testing it. I'll send this patch 
back and I'm happy to review it once it's actually ready, but at the moment 
it's sadly not.

Some notes on what I expect to happen to this patch before this goes back in 
anyone's review queue:

- Get enough (documented) tests that a reasonable person can look at this patch 
and believe it could work in production.
- Obviously fix any bugs uncovered by the tests.
- I don't think the current approach will always correctly resolve the return 
type (which is perfectly fine), but if that happens we shouldn't crash. IIRC 
the reason why my original patch set the C++14 flag in the expr evaluator is 
because it makes using these raw 'auto' types an error diagnostic instead of a 
crash. In any case, this should be tested then. Just to be clear: I think 
getting this to work in every case is out of scope for this patch so I think 
it's fine if those cases are at just documented/tested.




Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:402-403
 case DW_AT_type:
-  type = form_value;
+  if (!type.IsValid())
+type = form_value;
   break;

shafik wrote:
> JDevlieghere wrote:
> > What's the purpose of this? Do we expect to see the type attribute more 
> > than once? 
> Good question, the first iteration was done by @teemperor and then I modified 
> it heavily but I did not dig  into this change to deeply but I was pretty 
> sure when we first talked about there was a good reason for it.
`ParsedDWARFTypeAttributes` iterates not just over the attributes in the 
current DIE, but also follows `DW_AT_specification` and then iterates the 
attributes there. But the `DW_AT_specification` of the definition points to the 
declaration with the `auto` type, so without this change we would first assign 
`type` to the real type from the definition and then when we iterate over the 
attributes of the declaration we would overwrite the real type with the `auto` 
type.

In short: without this change `ParsedDWARFTypeAttributes(definition_die).type` 
would be `auto` instead of the real type.


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

https://reviews.llvm.org/D105564

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

[PATCH] D105904: [clangd] Support `#pragma mark` in the outline

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

In D105904#2877281 , @dgoldman wrote:

> Yep, I can you send you some searches internally with how prevalent they are.

Thanks!

> I don't think this an Xcode limitation really - more of an LSP spec 
> limitation. If we create a group inside of another symbol, we are effectively 
> contained in it and cannot escape without violating the spec, right? To be 
> clear, Xcode rules are a bit different - see the link above - the `#pragma 
> mark -` just creates a divider which we can't mirror.

Sorry I don't follow what you mean here. I was talking about inability to have 
something like:

  #pragma mark -Foo
#pragma mark -Bar
#pragma mark SPECIAL_BAR_END
  #pragma mark SPECIAL_FOO_END

By making sure groups are terminated **explicitly** we gain the ability to nest 
them, whereas otherwise `-Bar` above will always terminate the previous group 
implicitly.

> This assumes (like this code today) that the nodes are sorted properly and 
> the ranges of the parent are accurate.

Well it is not as strong as that. We'll mostly rely on the fact that symbols 
are nested properly. Since we just need to figure out the mark container for a 
symbol, we don't care about the ordering (or am I missing something here?).
OTOH, range of the parent being accurate is indeed required. I think today it 
is only broken for macro parents, but hopefully it shouldn't cause as any 
troubles as in all the practical cases these are still contained inside an AST 
node (I think), e.g:

  #define FOO(X) class X
  FOO(Bar) {
  #pragma mark -Test
  void bar();
  }

`-Test` mark is contained in `class X` so it can be nested properly. I don't 
think it is ever possible to have it nest directly under a macro name since you 
can't have other PP directives expanded from macros (even though it is probably 
possible via weird tricks like `__pragma`/`_Pragma`).
Now ranges for the pragma-mark containers will also be broken, but again it is 
not a problem as we are never going to attach any pragma-mark symbols directly 
into another pragma-mark (they'll either be siblings or there'll be a regular 
AST node in between, as explained previously).

> I was thinking of adding a proper sort in a post-processing phase but maybe 
> we could do it + range fix up during insertion. Seems complicated to move 
> everything over to insertion, but if you think that's reasonable, I can try 
> that out.

As explained above, I think we can just keep adjusting the ranges after 
building the tree as we do today. Let me know if I am missing something though.

> I think it's a bit more complicated since the leaf nodes terminate the 
> groups. As long as we do that it should be fine, assuming editors don't 
> require it to be sorted.

Well actually handling the leafs that terminate the group they are contained in 
is easy (since we'll make use of the closest mark-pragma to the declaration), 
but the other way around is hard, e.g:

  #pragma mark -Foo
  class X {
#pragma mark -Bar
  };
  void foo();

`foo` above needs to be nested under `Foo`, even though the closest mark-pragma 
is `Bar`. I think these can be handled more naturally by making sure we throw 
away mark-pragmas contained inside a symbol after processing the containing 
symbol (e.g. `Bar` will be dropped from our container after `X` has been 
inserted into the tree).

> We could - I considered it, but with the existing behavior and potential 
> subtle ordering issues I thought it would be simpler, but less efficient to 
> do it after.

Does my new set of comments help clarify things a little more? I don't think we 
need any ordering guarantees, we mostly rely on the fact that mark-pragmas will 
be sorted properly and symbols are nested correctly.

> I took a look at the Macro Expansion code and didn't understand it + 
> potential edge cases well enough to add it there.

I don't think this should directly go into the macro parent logic, but rather 
be orthogonal. Then we can just chain them, by first looking for a macro 
container and then looking for a mark-pragma one above that container (since we 
know the other-way around is not possible, i.e. a mark-pragma cannot nest 
directly under a macro).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105904

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

[PATCH] D105553: [analyzer][NFC] Split the main logic of NoStoreFuncVisitor to an abstract NoStateChangeVisitor class

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

Szelethus updated this revision to Diff 358876.
Szelethus marked 3 inline comments as done.
Szelethus added a comment.

- Change parameter names to highlight that the node at the end of the function 
call is a `CallExitBegin`.
- Change individual parameter callbacks to the entire call -- if a client knows 
that they don't want to emit diagnostics for some function, they can early 
return, instead of early returning for each parameter.
- Fix according to reviewer comments!


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

https://reviews.llvm.org/D105553

Files:
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h
  clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp

Index: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
+++ clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
@@ -343,46 +343,140 @@
   return P;
 }
 
+//===--===//
+// Implementation of NoStateChangeFuncVisitor.
+//===--===//
+
+bool NoStateChangeFuncVisitor::isModifiedInFrame(const ExplodedNode *N) {
+  const LocationContext *Ctx = N->getLocationContext();
+  const StackFrameContext *SCtx = Ctx->getStackFrame();
+  if (!FramesModifyingCalculated.count(SCtx))
+findModifyingFrames(N);
+  return FramesModifying.count(SCtx);
+}
+
+void NoStateChangeFuncVisitor::findModifyingFrames(
+const ExplodedNode *const CallExitBeginN) {
+
+  assert(CallExitBeginN->getLocationAs());
+  const ExplodedNode *LastReturnN = CallExitBeginN;
+  const StackFrameContext *const OriginalSCtx =
+  CallExitBeginN->getLocationContext()->getStackFrame();
+
+  const ExplodedNode *CurrN = CallExitBeginN;
+
+  do {
+ProgramStateRef State = CurrN->getState();
+auto CallExitLoc = CurrN->getLocationAs();
+if (CallExitLoc) {
+  LastReturnN = CurrN;
+}
+
+FramesModifyingCalculated.insert(
+CurrN->getLocationContext()->getStackFrame());
+
+if (wasModifiedBeforeCallExit(CurrN, LastReturnN)) {
+  const StackFrameContext *SCtx = CurrN->getStackFrame();
+  while (!SCtx->inTopFrame()) {
+auto p = FramesModifying.insert(SCtx);
+if (!p.second)
+  break; // Frame and all its parents already inserted.
+SCtx = SCtx->getParent()->getStackFrame();
+  }
+}
+
+// Stop calculation at the call to the current function.
+if (auto CE = CurrN->getLocationAs())
+  if (CE->getCalleeContext() == OriginalSCtx)
+break;
+
+CurrN = CurrN->getFirstPred();
+  } while (CurrN);
+}
+
+PathDiagnosticPieceRef NoStateChangeFuncVisitor::VisitNode(
+const ExplodedNode *N, BugReporterContext &BR, PathSensitiveBugReport &R) {
+
+  const LocationContext *Ctx = N->getLocationContext();
+  const StackFrameContext *SCtx = Ctx->getStackFrame();
+  ProgramStateRef State = N->getState();
+  auto CallExitLoc = N->getLocationAs();
+
+  // No diagnostic if region was modified inside the frame.
+  if (!CallExitLoc || isModifiedInFrame(N))
+return nullptr;
+
+  CallEventRef<> Call =
+  BR.getStateManager().getCallEventManager().getCaller(SCtx, State);
+
+  // Optimistically suppress uninitialized value bugs that result
+  // from system headers having a chance to initialize the value
+  // but failing to do so. It's too unlikely a system header's fault.
+  // It's much more likely a situation in which the function has a failure
+  // mode that the user decided not to check. If we want to hunt such
+  // omitted checks, we should provide an explicit function-specific note
+  // describing the precondition under which the function isn't supposed to
+  // initialize its out-parameter, and additionally check that such
+  // precondition can actually be fulfilled on the current path.
+  if (Call->isInSystemHeader()) {
+// We make an exception for system header functions that have no branches.
+// Such functions unconditionally fail to initialize the variable.
+// If they call other functions that have more paths within them,
+// this suppression would still apply when we visit these inner functions.
+// One common example of a standard function that doesn't ever initialize
+// its out parameter is operator placement new; it's up to the follow-up
+// constructor (if any) to initialize the memory.
+if (!N->getStackFrame()->getCFG()->isLinear()) {
+  static int i = 0;
+  R.markInvalid(&i, nullptr);
+}
+return nullptr;
+  }
+
+  if (const auto *MC = dyn_cast(Call)) {
+// If we failed to construct a piece for self, we still want to check
+// whether the entity of interest is in a parameter.
+if (PathDiagnosticPieceRef Piece = maybeEmitNoteForObjCSelf(R, *MC, N))
+  return Piece;
+  }
+
+  if (const auto *CCall = dyn_cast(Call)) {
+// D

[PATCH] D105553: [analyzer][NFC] Split the main logic of NoStoreFuncVisitor to an abstract NoStateChangeVisitor class

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

Szelethus added a comment.

In D105553#2867881 , @NoQ wrote:

> In the mailing list I seem to have made a mistake about how this works: we 
> don't explicitly scan the AST for potential statements that could cause a 
> state change (eg., assignment operators in case of `NoStore`) but we only 
> check if the region was explicitly made accessible. This makes things a lot 
> easier (we don't have to build an auxiliary AST-based analysis) and I'm not 
> sure if this other heuristic that I thought we have would actually make 
> things significantly better. I guess it makes sense to keep in mind that we 
> might want to ultimately plug it in but I don't immediately see what'd stop 
> us.

For `NoStoreFuncVisitor`, this seems to be fine I suppose, though I'm not sure 
how things pan out for memory leaks. As you put it,

> We probably shouldn't emit a note every time the function simply accepts the 
> value of interest by pointer, because this doesn't necessarily prove the 
> intent to delete the pointer;

it might be rather difficult to tell this intent. For now, I'm leaning on the 
side of slightly too much than too little, but I need real world data on my 
hand to have a good feel for it.




Comment at: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:399
+/// to get the correct parameter name.
+static ArrayRef getCallParameters(const CallEvent &Call) {
+  // Use runtime definition, if available.

NoQ wrote:
> While we're at it, can you take a look if the recently introduced 
> `CallEvent::parameters()` is good enough for this?
I suppose yeah, at least the lit tests all passed, though its worth mentioning 
that this function explicitly calls `CallEvent::parameters()`...


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

https://reviews.llvm.org/D105553

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

[PATCH] D105819: [analyzer] MallocChecker: Add a visitor to leave a note on functions that could have, but did not change ownership on leaked memory

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

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

- Fixes according to reviewer comments!
- Rebase on D105553 .
- Primitively check whether the allocated memory was actually passed into the 
function.


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

https://reviews.llvm.org/D105819

Files:
  clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
  clang/test/Analysis/NewDeleteLeaks.cpp
  clang/test/Analysis/self-assign.cpp

Index: clang/test/Analysis/self-assign.cpp
===
--- clang/test/Analysis/self-assign.cpp
+++ clang/test/Analysis/self-assign.cpp
@@ -1,4 +1,9 @@
-// RUN: %clang_analyze_cc1 -std=c++11 -analyzer-checker=core,cplusplus,unix.Malloc,debug.ExprInspection -analyzer-config eagerly-assume=false %s -verify -analyzer-output=text
+// RUN: %clang_analyze_cc1 -std=c++11 %s -verify -analyzer-output=text \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=cplusplus \
+// RUN:   -analyzer-checker=unix.Malloc \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false
 
 extern "C" char *strdup(const char* s);
 extern "C" void free(void* ptr);
@@ -28,18 +33,31 @@
   free(str);
 }
 
-StringUsed& StringUsed::operator=(const StringUsed &rhs) { // expected-note{{Assuming rhs == *this}} expected-note{{Assuming rhs == *this}} expected-note{{Assuming rhs != *this}}
-  clang_analyzer_eval(*this == rhs); // expected-warning{{TRUE}} expected-warning{{UNKNOWN}} expected-note{{TRUE}} expected-note{{UNKNOWN}}
+StringUsed &StringUsed::operator=(const StringUsed &rhs) {
+  // expected-note@-1{{Assuming rhs == *this}}
+  // expected-note@-2{{Assuming rhs == *this}}
+  // expected-note@-3{{Assuming rhs != *this}}
+  clang_analyzer_eval(*this == rhs); // expected-warning{{TRUE}}
+ // expected-warning@-1{{UNKNOWN}}
+ // expected-note@-2{{TRUE}}
+ // expected-note@-3{{UNKNOWN}}
   free(str); // expected-note{{Memory is released}}
-  str = strdup(rhs.str); // expected-warning{{Use of memory after it is freed}}  expected-note{{Use of memory after it is freed}}
-// expected-note@-1{{Memory is allocated}}
+  str = strdup(rhs.str); // expected-warning{{Use of memory after it is freed}}
+ // expected-note@-1{{Use of memory after it is freed}}
+ // expected-note@-2{{Memory is allocated}}
   return *this;
 }
 
-StringUsed& StringUsed::operator=(StringUsed &&rhs) { // expected-note{{Assuming rhs == *this}} expected-note{{Assuming rhs != *this}}
-  clang_analyzer_eval(*this == rhs); // expected-warning{{TRUE}} expected-warning{{UNKNOWN}} expected-note{{TRUE}} expected-note{{UNKNOWN}}
+StringUsed &StringUsed::operator=(StringUsed &&rhs) {
+  // expected-note@-1{{Assuming rhs == *this}}
+  // expected-note@-2{{Assuming rhs != *this}}
+  clang_analyzer_eval(*this == rhs); // expected-warning{{TRUE}}
+ // expected-warning@-1{{UNKNOWN}}
+ // expected-note@-2{{TRUE}}
+ // expected-note@-3{{UNKNOWN}}
   str = rhs.str;
-  rhs.str = nullptr; // expected-warning{{Potential memory leak}} expected-note{{Potential memory leak}}
+  rhs.str = nullptr; // expected-warning{{Potential memory leak}}
+ // expected-note@-1{{Potential memory leak}}
   return *this;
 }
 
@@ -63,15 +81,27 @@
   free(str);
 }
 
-StringUnused& StringUnused::operator=(const StringUnused &rhs) { // expected-note{{Assuming rhs == *this}} expected-note{{Assuming rhs == *this}} expected-note{{Assuming rhs != *this}}
-  clang_analyzer_eval(*this == rhs); // expected-warning{{TRUE}} expected-warning{{UNKNOWN}} expected-note{{TRUE}} expected-note{{UNKNOWN}}
+StringUnused &StringUnused::operator=(const StringUnused &rhs) {
+  // expected-note@-1{{Assuming rhs == *this}}
+  // expected-note@-2{{Assuming rhs == *this}}
+  // expected-note@-3{{Assuming rhs != *this}}
+  clang_analyzer_eval(*this == rhs); // expected-warning{{TRUE}}
+ // expected-warning@-1{{UNKNOWN}}
+ // expected-note@-2{{TRUE}}
+ // expected-note@-3{{UNKNOWN}}
   free(str); // expected-note{{Memory is released}}
-  str = strdup(rhs.str); // expected-warning{{Use of memory after it is freed}}  expected-note{{Use of memory after it is freed}}
+  str = strdup(rhs.str); // expected-warning{{Use of memory after it is freed}}
+ // expected-note@-1{{Use of memory after it is freed}}
   return *this;
 }
 
-StringUnused& StringUnused::operator=(StringUnused &&rhs) { // expected-note{{Assuming rhs == *this}} expected-note{{Assuming rhs != *this}}
-  clang_analyzer_eval(*this == rhs); // expected-warning{{TRUE}} expected-warnin

[PATCH] D105703: [hwasan] Use stack safety analysis.

[Florian Mayer via Phabricator via cfe-commits]

fmayer updated this revision to Diff 358884.
fmayer marked 7 inline comments as done.
fmayer added a comment.

address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105703

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h
  llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
  llvm/test/CodeGen/hwasan-stack-safety-analysis-asm.c
  llvm/test/CodeGen/hwasan-stack-safety-analysis.c

Index: llvm/test/CodeGen/hwasan-stack-safety-analysis.c
===
--- /dev/null
+++ llvm/test/CodeGen/hwasan-stack-safety-analysis.c
@@ -0,0 +1,15 @@
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm -mllvm -hwasan-use-stack-safety=true -mllvm -hwasan-generate-tags-with-calls -O2 %s -o - | FileCheck %s --check-prefix=SAFETY
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm -mllvm -hwasan-use-stack-safety=false -mllvm -hwasan-generate-tags-with-calls -O2 %s -o - | FileCheck %s --check-prefix=NOSAFETY
+
+// Default when optimizing, but not with O0.
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm -mllvm -hwasan-generate-tags-with-calls -O2 %s -o - | FileCheck %s --check-prefix=SAFETY
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm -mllvm -hwasan-generate-tags-with-calls -O0 %s -o - | FileCheck %s --check-prefix=NOSAFETY
+
+int main(int argc, char **argv) {
+  char buf[10];
+  volatile char *x = buf;
+  *x = 0;
+  return buf[0];
+  // NOSAFETY: __hwasan_generate_tag
+  // SAFETY-NOT: __hwasan_generate_tag
+}
Index: llvm/test/CodeGen/hwasan-stack-safety-analysis-asm.c
===
--- /dev/null
+++ llvm/test/CodeGen/hwasan-stack-safety-analysis-asm.c
@@ -0,0 +1,15 @@
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -mllvm -hwasan-use-stack-safety=true -mllvm -hwasan-generate-tags-with-calls -O2 %s -o - | FileCheck %s --check-prefix=SAFETY
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -mllvm -hwasan-use-stack-safety=false -mllvm -hwasan-generate-tags-with-calls -O2 %s -o - | FileCheck %s --check-prefix=NOSAFETY
+
+// Default when optimizing, but not with O0.
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -mllvm -hwasan-generate-tags-with-calls -O2 %s -o - | FileCheck %s --check-prefix=SAFETY
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -mllvm -hwasan-generate-tags-with-calls -O0 %s -o - | FileCheck %s --check-prefix=NOSAFETY
+
+int main(int argc, char **argv) {
+  char buf[10];
+  volatile char *x = buf;
+  *x = 0;
+  return buf[0];
+  // NOSAFETY: __hwasan_generate_tag
+  // SAFETY-NOT: __hwasan_generate_tag
+}
Index: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
@@ -17,6 +17,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Triple.h"
+#include "llvm/Analysis/StackSafetyAnalysis.h"
 #include "llvm/BinaryFormat/ELF.h"
 #include "llvm/IR/Attributes.h"
 #include "llvm/IR/BasicBlock.h"
@@ -109,6 +110,11 @@
cl::desc("instrument stack (allocas)"),
cl::Hidden, cl::init(true));
 
+static cl::opt
+ClUseStackSafety("hwasan-use-stack-safety", cl::Hidden, cl::init(true),
+ cl::Hidden, cl::desc("Use Stack Safety analysis results"),
+ cl::Optional);
+
 static cl::opt ClUARRetagToZero(
 "hwasan-uar-retag-to-zero",
 cl::desc("Clear alloca tags before returning from the function to allow "
@@ -210,13 +216,23 @@
 #pragma GCC poison ClInstrumentWithCalls
 }
 
+bool shouldUseStackSafetyAnalysis(const Triple &TargetTriple,
+  bool DisableOptimization) {
+  auto StackSafety = ClUseStackSafety.getNumOccurrences()
+ ? ClUseStackSafety
+ : !DisableOptimization;
+  return shouldInstrumentStack(TargetTriple) && StackSafety;
+// No one should use the option directly.
+#pragma GCC poison ClUseStackSafety
+}
 /// An instrumentation pass implementing detection of addressability bugs
 /// using tagged pointers.
 class HWAddressSanitizer {
 public:
   explicit HWAddressSanitizer(Module &M, bool CompileKernel = false,
-  bool Recover = false)
-  : M(M) {
+  bool Recover = false,
+  const StackSafetyGlobalInfo *SSI = nullptr)
+  : M(M), SSI(SSI) {
 this->Recover = ClRecover.getNumOccurrences() > 0 ? ClRecover : Recover;
 this->CompileKernel = ClEnableKhwasan.

[PATCH] D105819: [analyzer] MallocChecker: Add a visitor to leave a note on functions that could have, but did not change ownership on leaked memory

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

Szelethus marked 2 inline comments as done.
Szelethus added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp:801
+// must be a superset of, but not necessarily equal to ExitOwners.
+return !llvm::set_is_subset(ExitOwners, CurrOwners);
+  }

NoQ wrote:
> Can you also comment on what's, generally, the default scenario / motivating 
> example where this is necessary? What makes you hunt down store bindings that 
> didn't cause an escape to happen (given that an escape would have been a 
> state change)? IIUC this is for the situation when the callee stores the 
> pointer in a caller-local variable and in this case you don't want to claim 
> that ownership didn't change?
The comment above is meant to explain it. 
// [...] Any pointers
// inside the call that pointed to the allocated memory are of little
// consequence if their lifetime ends before within the function



Comment at: clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp:832-833
+  ArrayRef Parameters, unsigned ParamIdx) override {
+// TODO: Check whether the allocated memory was actually passed into the
+// function.
+return emitNote(N);

NoQ wrote:
> How difficult would it be to re-use this part as well?
Ugh, I gave this a shot, and its worse then expected. I think the original 
patch that George made was intended to be used by `NoStoreFuncVisitor`, and 
nothing else. As a consequence, its practically impossible to factor out 
without rewriting the whole thing.

At this point, I'm more in favor of just biting the bullet, and reuse how 
pointees and casts are printed from D50506, and maybe some of the dereferencing 
technology as well. It might be sliightly slower, but the majority of the 
price is only paid when `FieldChainInfo` is printed, not when its constructed.

For the time being, I made a rather primitive implementation here, which should 
lean on the conservative side (we under approximate the set of function calls 
where the allocated memory was actually passed into).



Comment at: clang/test/Analysis/NewDeleteLeaks.cpp:104-106
+// TODO: We don't want a note here. sink() doesn't seem like a function that
+// even attempts to take care of any memory ownership problems.
+namespace memory_passed_into_fn_that_doesnt_intend_to_free {

NoQ wrote:
> How do you think this is different from the very first test, 
> `memory_allocated_in_fn_call()`? Is this just because of how the pointer is 
> put into a variable first? This function is kinda still the only place that 
> could free memory.
That was my idea, yes, but you have a point there... 


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

https://reviews.llvm.org/D105819

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

[PATCH] D105703: [hwasan] Use stack safety analysis.

[Florian Mayer via Phabricator via cfe-commits]

fmayer added a comment.

Thanks!




Comment at: clang/test/CodeGen/hwasan-stack-safety-analysis-asm.c:4
+
+int main(int argc, char **argv) {
+  char buf[10];

vitalybuka wrote:
> fmayer wrote:
> > vitalybuka wrote:
> > > this patch mostly change code under llvm/ so tests should be also there, 
> > > as IR tests
> > > 
> > > 
> > I don't have strong feelings, but clang/test/CodeGen/lifetime-sanitizer.c 
> > is a very similar test, so I think we should either move all of these to 
> > llvm/ or add the new ones here to clang/. What do you think?
> That lifetime tests how clang inserts lifetime markers. So it must be in 
> clang/ this is from https://reviews.llvm.org/D20759 which is clang only patch.
> Here the only change for clang is forwarded BuilderWrapper.getTargetTriple().
> I don't mind if you keep your tests here, but we also need something which 
> tests llvm without clang as you change llvm tranformation.
> Usually if contributor changes code in llvm/, expectation is that check-llvm 
> should discover regression. It's not always possible, but that's the goal and 
> easy to do with this patch.
Thanks for the explanation. Moved to llvm/.



Comment at: llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h:32
+  Triple TargetTriple = {});
   PreservedAnalyses run(Module &M, ModuleAnalysisManager &MAM);
   static bool isRequired() { return true; }

vitalybuka wrote:
> fmayer wrote:
> > vitalybuka wrote:
> > > Why not from M.getTargetTriple() ?
> > Mostly for consistency with the legacy pass. Either way is fine for me 
> > though, what do you prefer?
> I don't know if will cause any issues, but usually most passes get triple 
> from the module.
> I prefer we stay consistent with the rest of the code if possible.
> 
I'll leave it as is, for consistency within this file, as we need to do it this 
way for the new pass manager.



Comment at: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp:444
+  const StackSafetyGlobalInfo *SSI = nullptr;
+  if (shouldUseStackSafetyAnalysis(TargetTriple, IsOptNull)) {
+SSI = &MAM.getResult(M);

vitalybuka wrote:
> we usually don't use {} for single line 
> also maybe good candidate for ?: operator
I think this would make a bit of a long tenary expression.



Comment at: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp:390
+  void getAnalysisUsage(AnalysisUsage &AU) const override {
+if (shouldUseStackSafetyAnalysis(TargetTriple)) {
+  AU.addRequired();

vitalybuka wrote:
> fmayer wrote:
> > vitalybuka wrote:
> > > why we need to check TargetTriple for that?
> > Because we only need the stack safety analysis if we instrument the stack, 
> > which we do not do on x86_64 (see shouldInstrumentStack).
> I see, I forgot about this limitation.
> LGTM, but unconditional is fine as well, assuming we are going to have stack 
> instrumentation at some point?
I am not sure we will ever add it for non-LAM x86_64.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105703

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

[PATCH] D105703: [hwasan] Use stack safety analysis.

[Florian Mayer via Phabricator via cfe-commits]

fmayer updated this revision to Diff 358885.
fmayer added a comment.

fixup


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105703

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h
  llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
  llvm/test/CodeGen/hwasan-stack-safety-analysis-asm.c
  llvm/test/CodeGen/hwasan-stack-safety-analysis.c

Index: llvm/test/CodeGen/hwasan-stack-safety-analysis.c
===
--- /dev/null
+++ llvm/test/CodeGen/hwasan-stack-safety-analysis.c
@@ -0,0 +1,15 @@
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm -mllvm -hwasan-use-stack-safety=true -mllvm -hwasan-generate-tags-with-calls -O2 %s -o - | FileCheck %s --check-prefix=SAFETY
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm -mllvm -hwasan-use-stack-safety=false -mllvm -hwasan-generate-tags-with-calls -O2 %s -o - | FileCheck %s --check-prefix=NOSAFETY
+
+// Default when optimizing, but not with O0.
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm -mllvm -hwasan-generate-tags-with-calls -O2 %s -o - | FileCheck %s --check-prefix=SAFETY
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm -mllvm -hwasan-generate-tags-with-calls -O0 %s -o - | FileCheck %s --check-prefix=NOSAFETY
+
+int main(int argc, char **argv) {
+  char buf[10];
+  volatile char *x = buf;
+  *x = 0;
+  return buf[0];
+  // NOSAFETY: __hwasan_generate_tag
+  // SAFETY-NOT: __hwasan_generate_tag
+}
Index: llvm/test/CodeGen/hwasan-stack-safety-analysis-asm.c
===
--- /dev/null
+++ llvm/test/CodeGen/hwasan-stack-safety-analysis-asm.c
@@ -0,0 +1,15 @@
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -mllvm -hwasan-use-stack-safety=true -mllvm -hwasan-generate-tags-with-calls -O2 %s -o - | FileCheck %s --check-prefix=SAFETY
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -mllvm -hwasan-use-stack-safety=false -mllvm -hwasan-generate-tags-with-calls -O2 %s -o - | FileCheck %s --check-prefix=NOSAFETY
+
+// Default when optimizing, but not with O0.
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -mllvm -hwasan-generate-tags-with-calls -O2 %s -o - | FileCheck %s --check-prefix=SAFETY
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -mllvm -hwasan-generate-tags-with-calls -O0 %s -o - | FileCheck %s --check-prefix=NOSAFETY
+
+int main(int argc, char **argv) {
+  char buf[10];
+  volatile char *x = buf;
+  *x = 0;
+  return buf[0];
+  // NOSAFETY: __hwasan_generate_tag
+  // SAFETY-NOT: __hwasan_generate_tag
+}
Index: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
@@ -17,6 +17,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Triple.h"
+#include "llvm/Analysis/StackSafetyAnalysis.h"
 #include "llvm/BinaryFormat/ELF.h"
 #include "llvm/IR/Attributes.h"
 #include "llvm/IR/BasicBlock.h"
@@ -109,6 +110,11 @@
cl::desc("instrument stack (allocas)"),
cl::Hidden, cl::init(true));
 
+static cl::opt
+ClUseStackSafety("hwasan-use-stack-safety", cl::Hidden, cl::init(true),
+ cl::Hidden, cl::desc("Use Stack Safety analysis results"),
+ cl::Optional);
+
 static cl::opt ClUARRetagToZero(
 "hwasan-uar-retag-to-zero",
 cl::desc("Clear alloca tags before returning from the function to allow "
@@ -210,13 +216,23 @@
 #pragma GCC poison ClInstrumentWithCalls
 }
 
+bool shouldUseStackSafetyAnalysis(const Triple &TargetTriple,
+  bool DisableOptimization) {
+  auto StackSafety = ClUseStackSafety.getNumOccurrences()
+ ? ClUseStackSafety
+ : !DisableOptimization;
+  return shouldInstrumentStack(TargetTriple) && StackSafety;
+// No one should use the option directly.
+#pragma GCC poison ClUseStackSafety
+}
 /// An instrumentation pass implementing detection of addressability bugs
 /// using tagged pointers.
 class HWAddressSanitizer {
 public:
   explicit HWAddressSanitizer(Module &M, bool CompileKernel = false,
-  bool Recover = false)
-  : M(M) {
+  bool Recover = false,
+  const StackSafetyGlobalInfo *SSI = nullptr)
+  : M(M), SSI(SSI) {
 this->Recover = ClRecover.getNumOccurrences() > 0 ? ClRecover : Recover;
 this->CompileKernel = ClEnableKhwasan.getNumOccurrences() > 0

[PATCH] D105629: [TSan] Add SystemZ support

[Ilya Leoshkevich 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 rGacf0a6428681: [sanitizer] Fix __sanitizer_kernel_sigset_t 
endianness issue (authored by iii).

Changed prior to commit:
  https://reviews.llvm.org/D105629?vs=358431&id=358890#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105629

Files:
  compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
  compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.h


Index: compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.h
===
--- compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.h
+++ compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -650,14 +650,14 @@
 #endif // !SANITIZER_ANDROID
 
 #if defined(__mips__)
-struct __sanitizer_kernel_sigset_t {
-  uptr sig[2];
-};
+#define __SANITIZER_KERNEL_NSIG 128
 #else
+#define __SANITIZER_KERNEL_NSIG 64
+#endif
+
 struct __sanitizer_kernel_sigset_t {
-  u8 sig[8];
+  uptr sig[__SANITIZER_KERNEL_NSIG / (sizeof(uptr) * 8)];
 };
-#endif
 
 // Linux system headers define the 'sa_handler' and 'sa_sigaction' macros.
 #if SANITIZER_MIPS
Index: compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
===
--- compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
+++ compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
@@ -878,7 +878,7 @@
   __sanitizer_kernel_sigset_t *k_set = (__sanitizer_kernel_sigset_t *)set;
   const uptr idx = signum / (sizeof(k_set->sig[0]) * 8);
   const uptr bit = signum % (sizeof(k_set->sig[0]) * 8);
-  k_set->sig[idx] &= ~(1 << bit);
+  k_set->sig[idx] &= ~((uptr)1 << bit);
 }
 
 bool internal_sigismember(__sanitizer_sigset_t *set, int signum) {
@@ -888,7 +888,7 @@
   __sanitizer_kernel_sigset_t *k_set = (__sanitizer_kernel_sigset_t *)set;
   const uptr idx = signum / (sizeof(k_set->sig[0]) * 8);
   const uptr bit = signum % (sizeof(k_set->sig[0]) * 8);
-  return k_set->sig[idx] & (1 << bit);
+  return k_set->sig[idx] & ((uptr)1 << bit);
 }
 #elif SANITIZER_FREEBSD
 void internal_sigdelset(__sanitizer_sigset_t *set, int signum) {


Index: compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.h
===
--- compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.h
+++ compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -650,14 +650,14 @@
 #endif // !SANITIZER_ANDROID
 
 #if defined(__mips__)
-struct __sanitizer_kernel_sigset_t {
-  uptr sig[2];
-};
+#define __SANITIZER_KERNEL_NSIG 128
 #else
+#define __SANITIZER_KERNEL_NSIG 64
+#endif
+
 struct __sanitizer_kernel_sigset_t {
-  u8 sig[8];
+  uptr sig[__SANITIZER_KERNEL_NSIG / (sizeof(uptr) * 8)];
 };
-#endif
 
 // Linux system headers define the 'sa_handler' and 'sa_sigaction' macros.
 #if SANITIZER_MIPS
Index: compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
===
--- compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
+++ compiler-rt/lib/sanitizer_common/sanitizer_linux.cpp
@@ -878,7 +878,7 @@
   __sanitizer_kernel_sigset_t *k_set = (__sanitizer_kernel_sigset_t *)set;
   const uptr idx = signum / (sizeof(k_set->sig[0]) * 8);
   const uptr bit = signum % (sizeof(k_set->sig[0]) * 8);
-  k_set->sig[idx] &= ~(1 << bit);
+  k_set->sig[idx] &= ~((uptr)1 << bit);
 }
 
 bool internal_sigismember(__sanitizer_sigset_t *set, int signum) {
@@ -888,7 +888,7 @@
   __sanitizer_kernel_sigset_t *k_set = (__sanitizer_kernel_sigset_t *)set;
   const uptr idx = signum / (sizeof(k_set->sig[0]) * 8);
   const uptr bit = signum % (sizeof(k_set->sig[0]) * 8);
-  return k_set->sig[idx] & (1 << bit);
+  return k_set->sig[idx] & ((uptr)1 << bit);
 }
 #elif SANITIZER_FREEBSD
 void internal_sigdelset(__sanitizer_sigset_t *set, int signum) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] e34078f - [TSan] Enable SystemZ support

[Ilya Leoshkevich via cfe-commits]

Author: Ilya Leoshkevich
Date: 2021-07-15T12:18:48+02:00
New Revision: e34078f121a58b503d225cf715d1494117e7948b

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

LOG: [TSan] Enable SystemZ support

Enable building the runtime and enable -fsanitize=thread in clang.

Reviewed By: dvyukov

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Linux.cpp
compiler-rt/cmake/config-ix.cmake

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Linux.cpp 
b/clang/lib/Driver/ToolChains/Linux.cpp
index 886e0b35ece8..c9360fc67165 100644
--- a/clang/lib/Driver/ToolChains/Linux.cpp
+++ b/clang/lib/Driver/ToolChains/Linux.cpp
@@ -709,7 +709,7 @@ SanitizerMask Linux::getSupportedSanitizers() const {
   if (IsX86_64 || IsMIPS64 || IsAArch64 || IsX86 || IsArmArch || IsPowerPC64 ||
   IsRISCV64 || IsSystemZ)
 Res |= SanitizerKind::Leak;
-  if (IsX86_64 || IsMIPS64 || IsAArch64 || IsPowerPC64)
+  if (IsX86_64 || IsMIPS64 || IsAArch64 || IsPowerPC64 || IsSystemZ)
 Res |= SanitizerKind::Thread;
   if (IsX86_64)
 Res |= SanitizerKind::KernelMemory;

diff  --git a/compiler-rt/cmake/config-ix.cmake 
b/compiler-rt/cmake/config-ix.cmake
index 9b27631f4af9..6f13acfa2757 100644
--- a/compiler-rt/cmake/config-ix.cmake
+++ b/compiler-rt/cmake/config-ix.cmake
@@ -329,7 +329,7 @@ set(ALL_HWASAN_SUPPORTED_ARCH ${X86_64} ${ARM64})
 set(ALL_MEMPROF_SUPPORTED_ARCH ${X86_64})
 set(ALL_PROFILE_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${PPC32} 
${PPC64}
 ${MIPS32} ${MIPS64} ${S390X} ${SPARC} ${SPARCV9})
-set(ALL_TSAN_SUPPORTED_ARCH ${X86_64} ${MIPS64} ${ARM64} ${PPC64})
+set(ALL_TSAN_SUPPORTED_ARCH ${X86_64} ${MIPS64} ${ARM64} ${PPC64} ${S390X})
 set(ALL_UBSAN_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM32} ${ARM64} ${RISCV64}
 ${MIPS32} ${MIPS64} ${PPC64} ${S390X} ${SPARC} ${SPARCV9})
 set(ALL_SAFESTACK_SUPPORTED_ARCH ${X86} ${X86_64} ${ARM64} ${MIPS32} ${MIPS64})



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

[PATCH] D105988: [OpenCL] NULL introduced prior to v2.0

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added inline comments.



Comment at: clang/lib/Headers/opencl-c-base.h:167
 
-#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_2_0)
+#if defined(__OPENCL_CPP_VERSION__) || defined(__OPENCL_C_VERSION__)
 #define NULL ((void*)0)

I think we should drop `#if` here since the condition now includes both OpenCL 
kernel languages that clang supports.



Comment at: clang/test/SemaOpenCL/null_literal.cl:7
 
 #define NULL ((void*)0)
 

Anastasia wrote:
> I think we should remove this `NULL` definition but instead add 
> `-finclude-default-header -fdeclare-opencl-builtins` to test the definition 
> you are adding in the header.
Ok, is this a full diff? 
https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface


Because the file appears to be incompletely displayed or something...


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

https://reviews.llvm.org/D105988

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

[PATCH] D105987: [C++4OpenCL] NULL redefined as nullptr

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added inline comments.



Comment at: clang/test/SemaOpenCL/null_literal.cl:2
+// RUN: %clang_cc1 -fdeclare-opencl-builtins -finclude-default-header -verify 
%s
+// RUN: %clang_cc1 -cl-std=CL1.0 -fdeclare-opencl-builtins 
-finclude-default-header -verify %s
+// RUN: %clang_cc1 -cl-std=CL1.1 -fdeclare-opencl-builtins 
-finclude-default-header -verify %s

I think these lines here are from another patch.



Comment at: clang/test/SemaOpenCL/null_literal.cl:13
+#if defined(__OPENCL_CPP_VERSION__)
+// expected-error@+2{{cannot initialize a variable of type '__global int 
*__private' with an rvalue of type '__global void *'}}
+#endif

hmm, you should not get those errors though https://godbolt.org/z/qvr7x11TM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105987

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

[PATCH] D103191: [OpenCL] Add support of __opencl_c_program_scope_global_variables feature macro

[Anton Zabaznov via Phabricator via cfe-commits]

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

Restructured test a little


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103191

Files:
  clang/include/clang/Basic/OpenCLOptions.h
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CodeGenOpenCL/addr-space-struct-arg.cl
  clang/test/SemaOpenCL/storageclass.cl

Index: clang/test/SemaOpenCL/storageclass.cl
===
--- clang/test/SemaOpenCL/storageclass.cl
+++ clang/test/SemaOpenCL/storageclass.cl
@@ -1,28 +1,118 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL1.2
-
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=-__opencl_c_program_scope_global_variables,-__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=+__opencl_c_program_scope_global_variables,-__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=-__opencl_c_program_scope_global_variables,+__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=+__opencl_c_program_scope_global_variables,+__opencl_c_generic_address_space
 static constant int G1 = 0;
 constant int G2 = 0;
-int G3 = 0;// expected-error{{program scope variable must reside in constant address space}}
-global int G4 = 0; // expected-error{{program scope variable must reside in constant address space}}
 
-static float g_implicit_static_var = 0; // expected-error {{program scope variable must reside in constant address space}}
+int G3 = 0;
+#ifndef __opencl_c_program_scope_global_variables
+// expected-error@-2 {{program scope variable must reside in constant address space}}
+#endif
+
+global int G4 = 0;
+#ifndef __opencl_c_program_scope_global_variables
+// expected-error@-2 {{program scope variable must reside in constant address space}}
+#endif
+
+static float g_implicit_static_var = 0;
+#ifndef __opencl_c_program_scope_global_variables
+// expected-error@-2 {{program scope variable must reside in constant address space}}
+#endif
+
 static constant float g_constant_static_var = 0;
-static global float g_global_static_var = 0;   // expected-error {{program scope variable must reside in constant address space}}
-static local float g_local_static_var = 0; // expected-error {{program scope variable must reside in constant address space}}
-static private float g_private_static_var = 0; // expected-error {{program scope variable must reside in constant address space}}
-static generic float g_generic_static_var = 0; // expected-error{{OpenCL C version 1.2 does not support the 'generic' type qualifier}} // expected-error {{program scope variable must reside in constant address space}}
 
-extern float g_implicit_extern_var; // expected-error {{extern variable must reside in constant address space}}
+static global float g_global_static_var = 0;
+#ifndef __opencl_c_program_scope_global_variables
+// expected-error@-2 {{program scope variable must reside in constant address space}}
+#endif
+
+static local float g_local_static_var = 0;
+#ifndef __opencl_c_program_scope_global_variables
+// expected-error@-2 {{program scope variable must reside in constant address space}}
+#else
+// expected-error@-4 {{program scope variable must reside in global or constant address space}}
+#endif
+
+static private float g_private_static_var = 0;
+#ifndef __opencl_c_program_scope_global_variables
+// expected-error@-2 {{program scope variable must reside in constant address space}}
+#else
+// expected-error@-4 {{program scope variable must reside in global or constant address space}}
+#endif
+
+static generic float g_generic_static_var = 0;
+#if (__OPENCL_C_VERSION__ < 300)
+// expected-error@-2 {{OpenCL C version 1.2 does not support the 'generic' type qualifier}}
+// expected-error@-3 {{program scope variable must reside in constant address space}}
+#elif (__OPENCL_C_VERSION__ == 300)
+ #if !defined(__opencl_c_generic_address_space)
+// expected-error@-6 {{OpenCL C version 3.0 does not support the 'generic' type qualifier}}
+ #endif
+ #if !defined(__opencl_c_program_scope_global_variables)
+// expected-error@-9 {{program scope variable must reside in constant address space}}
+ #endif
+ #if defined(__opencl_c_generic_address_space) && defined(__opencl_c_program_scope_global_variables)
+// expected-error@-12 {{program scope variable must reside in global or constant address space}}
+ #endif
+#endif
+
+extern float g_implicit_extern_var;
+#ifndef __opencl_c_program_scope_global_variables
+// expected-error@-2 {{extern variable must reside in constant address space}}
+#endif
+
 extern constant float g_constant_extern_var;
-extern global float g_global_extern_var;   // expected-error {{extern variable must reside in constant address space}}
-extern local float g_local_extern_var; 

[PATCH] D105973: [ASTMatchers] NFC: Fix the annotation.

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM, thank you for the fix! Do you need me to commit it on your behalf? If so, 
what name and email address would you like me to use for patch attribution?


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

https://reviews.llvm.org/D105973

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

[PATCH] D105988: [OpenCL] NULL introduced prior to v2.0

[Justas Janickas via Phabricator via cfe-commits]

Topotuna updated this revision to Diff 358911.
Topotuna added a comment.

Full diff now added. Redundant condition `#if` removed


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

https://reviews.llvm.org/D105988

Files:
  clang/lib/Headers/opencl-c-base.h
  clang/test/SemaOpenCL/null_literal.cl


Index: clang/test/SemaOpenCL/null_literal.cl
===
--- clang/test/SemaOpenCL/null_literal.cl
+++ clang/test/SemaOpenCL/null_literal.cl
@@ -1,7 +1,8 @@
-// RUN: %clang_cc1 -verify %s
-// RUN: %clang_cc1 -cl-std=CL2.0 -DCL20 -verify %s
-
-#define NULL ((void*)0)
+// RUN: %clang_cc1 -fdeclare-opencl-builtins -finclude-default-header -verify 
%s
+// RUN: %clang_cc1 -cl-std=CL1.0 -fdeclare-opencl-builtins 
-finclude-default-header -verify %s
+// RUN: %clang_cc1 -cl-std=CL1.1 -fdeclare-opencl-builtins 
-finclude-default-header -verify %s
+// RUN: %clang_cc1 -cl-std=CL1.2 -fdeclare-opencl-builtins 
-finclude-default-header -verify %s
+// RUN: %clang_cc1 -cl-std=CL2.0 -DCL20 -fdeclare-opencl-builtins 
-finclude-default-header -verify %s
 
 void foo(){
 
Index: clang/lib/Headers/opencl-c-base.h
===
--- clang/lib/Headers/opencl-c-base.h
+++ clang/lib/Headers/opencl-c-base.h
@@ -164,9 +164,7 @@
 typedef double double16 __attribute__((ext_vector_type(16)));
 #endif
 
-#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_2_0)
 #define NULL ((void*)0)
-#endif
 
 /**
  * Value of maximum non-infinite single-precision floating-point


Index: clang/test/SemaOpenCL/null_literal.cl
===
--- clang/test/SemaOpenCL/null_literal.cl
+++ clang/test/SemaOpenCL/null_literal.cl
@@ -1,7 +1,8 @@
-// RUN: %clang_cc1 -verify %s
-// RUN: %clang_cc1 -cl-std=CL2.0 -DCL20 -verify %s
-
-#define NULL ((void*)0)
+// RUN: %clang_cc1 -fdeclare-opencl-builtins -finclude-default-header -verify %s
+// RUN: %clang_cc1 -cl-std=CL1.0 -fdeclare-opencl-builtins -finclude-default-header -verify %s
+// RUN: %clang_cc1 -cl-std=CL1.1 -fdeclare-opencl-builtins -finclude-default-header -verify %s
+// RUN: %clang_cc1 -cl-std=CL1.2 -fdeclare-opencl-builtins -finclude-default-header -verify %s
+// RUN: %clang_cc1 -cl-std=CL2.0 -DCL20 -fdeclare-opencl-builtins -finclude-default-header -verify %s
 
 void foo(){
 
Index: clang/lib/Headers/opencl-c-base.h
===
--- clang/lib/Headers/opencl-c-base.h
+++ clang/lib/Headers/opencl-c-base.h
@@ -164,9 +164,7 @@
 typedef double double16 __attribute__((ext_vector_type(16)));
 #endif
 
-#if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_2_0)
 #define NULL ((void*)0)
-#endif
 
 /**
  * Value of maximum non-infinite single-precision floating-point
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105988: [OpenCL] NULL introduced prior to v2.0

[Justas Janickas via Phabricator via cfe-commits]

Topotuna marked 2 inline comments as done.
Topotuna added inline comments.



Comment at: clang/test/SemaOpenCL/null_literal.cl:7
 
 #define NULL ((void*)0)
 

Anastasia wrote:
> Anastasia wrote:
> > I think we should remove this `NULL` definition but instead add 
> > `-finclude-default-header -fdeclare-opencl-builtins` to test the definition 
> > you are adding in the header.
> Ok, is this a full diff? 
> https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface
> 
> 
> Because the file appears to be incompletely displayed or something...
Apologies. That was not a full diff. Should be fixed now.


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

https://reviews.llvm.org/D105988

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

[PATCH] D105660: [PowerPC][AIX] Add warning when alignment is incompatible with XL

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:3255-3256
+def warn_not_xl_compatible
+: Warning<"requested alignment of arguments 16 bytes or greater is not"
+  " compatible with previous versions of the AIX XL compiler">,
+  InGroup>;

ZarkoCA wrote:
> aaron.ballman wrote:
> > ZarkoCA wrote:
> > > aaron.ballman wrote:
> > > > Should we be talking about the AIX XL compiler in a Clang diagnostic?
> > > I see your point. Sorry if this isn't what is supposed to be done or if 
> > > it doesn't a good precedent.
> > > 
> > > The reasons for adding this warning is that our back end implementation 
> > > isn't totally compatible with XL now and, while buggy, users on AIX may 
> > > expect clang and xlclang to be compatible since AIX is the reference 
> > > compiler.  The xlclang name implies it's clang based and it's possible 
> > > for users to expect some sort of binary compatibility.
> > > 
> > > I see your point. Sorry if this isn't what is supposed to be done or if 
> > > it doesn't a good precedent.
> > 
> > No worries, it's a good discussion to have! We have some MSVC and GCC 
> > compatibility warnings, so there's precedent for naming other compilers. 
> > Now that you've moved the diagnostic into an AIX compatibility diagnostic 
> > group, I am more comfortable with it. Thanks!
> Thanks, glad it's better now. 
I missed this last time, sorry, but is "arguments" actually necessary for the 
diagnostic or can that be dropped?



Comment at: clang/test/Sema/aix-attr-align.c:18-21
+};
+  int a[8] __attribute__((aligned(8)));  // no-warning
+  int b[4] __attribute__((aligned(16))); // no-warning 
+  int c[2] __attribute__((aligned(32))); // no-warning

Minor formatting nit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105660

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

[PATCH] D105257: [clang][darwin] add support for remapping macOS availability to Mac Catalyst availability

[Aaron Ballman via Phabricator via cfe-commits]

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

LGTM!




Comment at: clang/lib/Sema/Sema.cpp:63
+  StringRef Platform) {
+  if (!CachedDarwinSDKInfo) {
+auto SDKInfo = parseDarwinSDKInfo(

dexonsmith wrote:
> Nit: I think I'd find this function easier to read if it used an early return 
> here, duplicating the `CachedDarwinSDKInfo->get()` call. But I'm fine if you 
> prefer it this way.
I don't have strong feelings either, but I think an early return would be 
reasonable.


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

https://reviews.llvm.org/D105257

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

[PATCH] D104386: [PowerPC][Builtins] Added a number of builtins for compatibility with XL.

[Stefan Pintilie via Phabricator via cfe-commits]

stefanp updated this revision to Diff 358915.
stefanp added a comment.

Sorry for letting this patch sit for so long.

I have updated the tests to simplify them so that we only include the
intrinsics (As per a comment). This reduces quite a bit of clutter.

Added Sema Checking for the builtins that were created.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104386

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-abs.c
  clang/test/CodeGen/builtins-ppc-xlcompat-alloca.c
  clang/test/CodeGen/builtins-ppc-xlcompat-bpermd.c
  clang/test/CodeGen/builtins-ppc-xlcompat-cipher.c
  clang/test/CodeGen/builtins-ppc-xlcompat-cmplx.c
  clang/test/CodeGen/builtins-ppc-xlcompat-darn.c
  clang/test/CodeGen/builtins-ppc-xlcompat-div.c
  clang/test/CodeGen/builtins-ppc-xlcompat-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-expect.c
  clang/test/CodeGen/builtins-ppc-xlcompat-fma.c
  clang/test/CodeGen/builtins-ppc-xlcompat-memory.c
  clang/test/CodeGen/builtins-ppc-xlcompat-mode.c
  clang/test/CodeGen/builtins-ppc-xlcompat-popcnt.c
  clang/test/CodeGen/builtins-ppc-xlcompat-rotate.c

Index: clang/test/CodeGen/builtins-ppc-xlcompat-rotate.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-rotate.c
@@ -0,0 +1,39 @@
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc-unknown-unknown \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpcle-unknown-unknown \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc-unknown-aix \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr7 | FileCheck %s
+
+// CHECK-LABEL: @testrotatel4(
+// CHECK: [[TMP:%.*]] = call i32 @llvm.fshl.i32(i32 {{%.*}}, i32 {{%.*}}, i32 {{%.*}})
+// CHECK-NEXT:ret i32 [[TMP]]
+//
+unsigned int testrotatel4(unsigned int rs, unsigned int shift) {
+  return __rotatel4(rs, shift);
+}
+
+// CHECK-LABEL: @testrotatel8(
+// CHECK: [[TMP:%.*]] = call i64 @llvm.fshl.i64(i64 {{%.*}}, i64 {{%.*}}, i64 {{%.*}})
+// CHECK-NEXT:ret i64 [[TMP]]
+//
+unsigned long long testrotatel8(unsigned long long rs, unsigned long long shift) {
+  return __rotatel8(rs, shift);
+}
+
+// CHECK-LABEL: @testrdlam(
+// CHECK: [[TMP0:%.*]] = call i64 @llvm.fshl.i64(i64 {{%.*}}, i64 {{%.*}}, i64 {{%.*}})
+// CHECK-NEXT:[[TMP1:%.*]] = and i64 [[TMP0]], 7
+// CHECK-NEXT:ret i64 [[TMP1]]
+//
+unsigned long long testrdlam(unsigned long long rs, unsigned int shift) {
+  // The third parameter is a mask that must be a constant that represents a
+  // contiguous bit field.
+  return __rdlam(rs, shift, 7);
+}
Index: clang/test/CodeGen/builtins-ppc-xlcompat-popcnt.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-popcnt.c
@@ -0,0 +1,63 @@
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc-unknown-unknown \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpcle-unknown-unknown \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+
+// CHECK-LABEL: @testcntlz4(
+// CHECK: [[TMP:%.*]] = call i32 @llvm.ctlz.i32(i32 {{%.*}}, i1 false)
+// CHECK-NEXT:ret i32 [[TMP]]
+//
+unsigned int testcntlz4(unsigned int value) {
+  return __cntlz4(value);
+}
+
+// CHECK-LABEL: @testcntlz8(
+// CHECK: [[TMP:%.*]] = call i64 @llvm.ctlz.i64(i64 {{%.*}}, i1 false)
+// CHECK-NEXT:[[CAST:%.*]] = trunc i64 [[TMP]] to i32
+// CHECK-NEXT:ret i32 [[CAST]]
+//
+unsigned int testcntlz8(unsigned long long value) {
+  return __cntlz8(value);
+}
+
+// CHECK-LABEL: @testcnttz4(
+// CHECK: [[TMP:%.*]] = call i32 @llvm.cttz.i32(i32 {{%.*}}, i1 false)
+// CHECK-NEXT:ret i32 [[TMP]]
+//
+unsigned int testcnttz4(unsigned int value) {
+  return __cnttz4(value);
+}
+
+// CHECK-LABEL: @

[PATCH] D106049: [RISCV] Update to vfredusum.vs and vfwredusum.vs according to v1.0-rc1.

[Hsiangkai Wang via Phabricator via cfe-commits]

HsiangKai abandoned this revision.
HsiangKai added a comment.

In D106049#2879422 , @frasercrmck 
wrote:

> Duplicate of D105690 ?

I didn't aware of it. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106049

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

[PATCH] D105973: [ASTMatchers] NFC: Fix the annotation.

[gehry via Phabricator via cfe-commits]

Sockke added a comment.

I would appreciate it if you could submit it on my behalf. Thanks a lot!

Name: liuke
Email: liuke.ge...@bytedance.com


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

https://reviews.llvm.org/D105973

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

[PATCH] D105904: [clangd] Support `#pragma mark` in the outline

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D105904#2877184 , @kadircet wrote:

> So first of all, it is not clear to me if this is a useful enough improvement 
> to justify all the new code, but looking at your investment I'll assume this 
> is really common in ObjC land and gonna be useful for developers working with 
> ObjC. That's enough of a justification for me, but I'd be more than happy to 
> see some real data if you have any.

+1. I think the key for this kind of feature is isolating the complexity so it 
doesn't need to be part of the core mental model of how the feature works.
For macros I basically failed to do this, but I think we can do better here.

> Can you verify that I understood the intent correctly and make it more 
> explicit in the comments as well?

Yes, I think the comments should explain how these marks are used without 
assuming any prior knowledge.
Simplest reason for this is that the impl language for clangd is not objc, and 
the technique seems basically unknown elsewhere.

> Before diving into the details of the implementation it looks like we are 
> doing some post-processing to incorporate mark pragmas into the tree, why 
> can't we just insert them while building the tree as we do with macros?

OK, this is why I'm jumping in here...
I think the fact that we do macros as-we-go is bad but unavoidable. It forces 
the core algorithm to think about symbol nesting and macro expansion at the 
same time, and makes the code much harder to reason about than if they were 
completely separate.

I didn't manage to separate them because macros are so complicated - we need 
the detailed SourceLocation info, to account for cases where they don't nest 
concentrically, etc. But this failure isn't something we should be consistent 
about - the more features that are part of the central algorithm, the 
exponentially more interactions there are to worry about.

However those difficulties don't apply here - I believe you can take the 
current final representation (`vector`) + the list of marks and 
produce a markified `vector` via a fairly natural tree walk. 
And this does a *really* good job of isolating this feature - we literally run 
the rest of the algorithm without it.
(This is slightly different to what's done in the patch, I would actually take 
it out of the `DocumentOutline` class entirely).
I don't think this hurts efficiency much (I think/hope this ends up being a 
move rather than a copy for most nodes). And I think it actually makes the 
markifying code easier to reason about in this case, as it just deals with line 
numbers/positions, without having the distraction of SourceLocation.

@kadircet WDYT of this argument, before we make David go back and forth?




Comment at: clang-tools-extra/clangd/ParsedAST.cpp:418
   collectIncludeStructureCallback(Clang->getSourceManager(), &Includes));
   // Copy over the macros in the preamble region of the main file, and combine
   // with non-preamble macros below.

You'll need to do this with marks as well (collect + merge), or you'll miss 
marks from the preamble region.
Make sure there's a test for this (it's not necessary to actually have any 
includes, I think)



Comment at: clang-tools-extra/clangd/Protocol.h:198
+
+  /// Expand this range to also contain `Rng`.
+  void mergeWith(Range Rng) {

This doesn't belong in Protocol.h, rather in SourceCode.h or so - these aren't 
domain objects and adding logic to them can end up causing layering issues in 
general.
(There are some exceptions for good and bad reasons, but not many. I'm not sure 
why Range::contains is here)

Maybe union() to be a little less ambiguous?



Comment at: clang-tools-extra/clangd/TextMarks.h:22
+/// Represents a programmer specified mark/note, typically used to easily 
locate
+/// or differentiate code. e.g. a `pragma mark`, a `TODO`.
+///

This seems like premature abstraction - you don't handle TODOs here, nor are 
they appropriate for the single use case we have. Moreover they don't satisfy 
the definition here: `int foo; // TODO: turn into a float` the TODO doesn't 
occupy the whole line.

If we need it, the appropriate generalization seems just as likely to be 
"pragmas" or "directives" as "textual marks".

Similarly, it's not clear that the logic around interpreting the strings e.g. 
as groups needs to be shared across features, nor is it terribly complicated.
So the interface here seems like it could be much simpler:
```
struct PragmaMark {
  unsigned Line;
  string Text;
}
unique_ptr collectPragmaMarksCallback(const SourceManager&, 
vector &Out);
```

I'd suggest putting this in CollectMacros.h (which would be misnamed but not 
terribly, or we could always rename) rather than adding a new header.



Comment at: clang-tools-extra/clangd/TextMarks.h:45
+  : SM(SM), Out(Out) {}
+  void PragmaMark(SourceLocation 

[PATCH] D105819: [analyzer] MallocChecker: Add a visitor to leave a note on functions that could have, but did not change ownership on leaked memory

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

Szelethus updated this revision to Diff 358927.
Szelethus marked an inline comment as done.
Szelethus added a comment.

- Fix testfiles.
- Fix a typo in the comments.


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

https://reviews.llvm.org/D105819

Files:
  clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
  clang/test/Analysis/NewDeleteLeaks.cpp
  clang/test/Analysis/self-assign.cpp

Index: clang/test/Analysis/self-assign.cpp
===
--- clang/test/Analysis/self-assign.cpp
+++ clang/test/Analysis/self-assign.cpp
@@ -1,4 +1,9 @@
-// RUN: %clang_analyze_cc1 -std=c++11 -analyzer-checker=core,cplusplus,unix.Malloc,debug.ExprInspection -analyzer-config eagerly-assume=false %s -verify -analyzer-output=text
+// RUN: %clang_analyze_cc1 -std=c++11 %s -verify -analyzer-output=text \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=cplusplus \
+// RUN:   -analyzer-checker=unix.Malloc \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false
 
 extern "C" char *strdup(const char* s);
 extern "C" void free(void* ptr);
@@ -28,18 +33,31 @@
   free(str);
 }
 
-StringUsed& StringUsed::operator=(const StringUsed &rhs) { // expected-note{{Assuming rhs == *this}} expected-note{{Assuming rhs == *this}} expected-note{{Assuming rhs != *this}}
-  clang_analyzer_eval(*this == rhs); // expected-warning{{TRUE}} expected-warning{{UNKNOWN}} expected-note{{TRUE}} expected-note{{UNKNOWN}}
+StringUsed &StringUsed::operator=(const StringUsed &rhs) {
+  // expected-note@-1{{Assuming rhs == *this}}
+  // expected-note@-2{{Assuming rhs == *this}}
+  // expected-note@-3{{Assuming rhs != *this}}
+  clang_analyzer_eval(*this == rhs); // expected-warning{{TRUE}}
+ // expected-warning@-1{{UNKNOWN}}
+ // expected-note@-2{{TRUE}}
+ // expected-note@-3{{UNKNOWN}}
   free(str); // expected-note{{Memory is released}}
-  str = strdup(rhs.str); // expected-warning{{Use of memory after it is freed}}  expected-note{{Use of memory after it is freed}}
-// expected-note@-1{{Memory is allocated}}
+  str = strdup(rhs.str); // expected-warning{{Use of memory after it is freed}}
+ // expected-note@-1{{Use of memory after it is freed}}
+ // expected-note@-2{{Memory is allocated}}
   return *this;
 }
 
-StringUsed& StringUsed::operator=(StringUsed &&rhs) { // expected-note{{Assuming rhs == *this}} expected-note{{Assuming rhs != *this}}
-  clang_analyzer_eval(*this == rhs); // expected-warning{{TRUE}} expected-warning{{UNKNOWN}} expected-note{{TRUE}} expected-note{{UNKNOWN}}
+StringUsed &StringUsed::operator=(StringUsed &&rhs) {
+  // expected-note@-1{{Assuming rhs == *this}}
+  // expected-note@-2{{Assuming rhs != *this}}
+  clang_analyzer_eval(*this == rhs); // expected-warning{{TRUE}}
+ // expected-warning@-1{{UNKNOWN}}
+ // expected-note@-2{{TRUE}}
+ // expected-note@-3{{UNKNOWN}}
   str = rhs.str;
-  rhs.str = nullptr; // expected-warning{{Potential memory leak}} expected-note{{Potential memory leak}}
+  rhs.str = nullptr; // expected-warning{{Potential memory leak}}
+ // expected-note@-1{{Potential memory leak}}
   return *this;
 }
 
@@ -63,15 +81,27 @@
   free(str);
 }
 
-StringUnused& StringUnused::operator=(const StringUnused &rhs) { // expected-note{{Assuming rhs == *this}} expected-note{{Assuming rhs == *this}} expected-note{{Assuming rhs != *this}}
-  clang_analyzer_eval(*this == rhs); // expected-warning{{TRUE}} expected-warning{{UNKNOWN}} expected-note{{TRUE}} expected-note{{UNKNOWN}}
+StringUnused &StringUnused::operator=(const StringUnused &rhs) {
+  // expected-note@-1{{Assuming rhs == *this}}
+  // expected-note@-2{{Assuming rhs == *this}}
+  // expected-note@-3{{Assuming rhs != *this}}
+  clang_analyzer_eval(*this == rhs); // expected-warning{{TRUE}}
+ // expected-warning@-1{{UNKNOWN}}
+ // expected-note@-2{{TRUE}}
+ // expected-note@-3{{UNKNOWN}}
   free(str); // expected-note{{Memory is released}}
-  str = strdup(rhs.str); // expected-warning{{Use of memory after it is freed}}  expected-note{{Use of memory after it is freed}}
+  str = strdup(rhs.str); // expected-warning{{Use of memory after it is freed}}
+ // expected-note@-1{{Use of memory after it is freed}}
   return *this;
 }
 
-StringUnused& StringUnused::operator=(StringUnused &&rhs) { // expected-note{{Assuming rhs == *this}} expected-note{{Assuming rhs != *this}}
-  clang_analyzer_eval(*this == rhs); // expected-warning{{TRUE}} expected-warning{{UNKNOWN}} expected-note{{TRUE}} expected-note{{UNKNOWN}}
+StringUnused &StringUnused::opera

[PATCH] D105819: [analyzer] MallocChecker: Add a visitor to leave a note on functions that could have, but did not change ownership on leaked memory

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

Szelethus added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp:801
+// must be a superset of, but not necessarily equal to ExitOwners.
+return !llvm::set_is_subset(ExitOwners, CurrOwners);
+  }

Szelethus wrote:
> NoQ wrote:
> > Can you also comment on what's, generally, the default scenario / 
> > motivating example where this is necessary? What makes you hunt down store 
> > bindings that didn't cause an escape to happen (given that an escape would 
> > have been a state change)? IIUC this is for the situation when the callee 
> > stores the pointer in a caller-local variable and in this case you don't 
> > want to claim that ownership didn't change?
> The comment above is meant to explain it. 
> // [...] Any pointers
> // inside the call that pointed to the allocated memory are of little
> // consequence if their lifetime ends before within the function
Oh, speaking of which, that is a gramarr eror.


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

https://reviews.llvm.org/D105819

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

[PATCH] D105660: [PowerPC][AIX] Add warning when alignment is incompatible with XL

[Zarko Todorovski via Phabricator via cfe-commits]

ZarkoCA updated this revision to Diff 358934.
ZarkoCA added a comment.

- Fix formatting in test case
- Reword warning message


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105660

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Sema/aix-attr-align.c


Index: clang/test/Sema/aix-attr-align.c
===
--- /dev/null
+++ clang/test/Sema/aix-attr-align.c
@@ -0,0 +1,22 @@
+// off-no-diagnostics
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -verify -fsyntax-only %s
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -verify -fsyntax-only %s
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -verify=off -Wno-aix-compat 
-fsyntax-only %s
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -verify=off -Wno-aix-compat 
-fsyntax-only %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-linux -verify=off -fsyntax-only 
%s
+
+struct S {
+  int a[8] __attribute__((aligned(8))); // no-warning
+};
+
+struct T {
+  int a[4] __attribute__((aligned(16))); // expected-warning {{requesting an 
alignment of 16 bytes or greater for struct members is not binary compatible 
with AIX XL 16.1 and older}}
+};
+
+struct U {
+  int a[2] __attribute__((aligned(32))); // expected-warning {{requesting an 
alignment of 16 bytes or greater for struct members is not binary compatible 
with AIX XL 16.1 and older}}
+};
+
+int a[8] __attribute__((aligned(8)));  // no-warning
+int b[4] __attribute__((aligned(16))); // no-warning
+int c[2] __attribute__((aligned(32))); // no-warning
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -3953,6 +3953,12 @@
 return;
 
   uint64_t AlignVal = Alignment.getZExtValue();
+  // 16 byte ByVal alignment not due to a vector member is not honoured by XL
+  // on AIX. Emit a warning here that users are generating binary incompatible
+  // code to be safe.
+  if (AlignVal >= 16 && isa(D) &&
+  Context.getTargetInfo().getTriple().isOSAIX())
+Diag(AttrLoc, diag::warn_not_xl_compatible) << E->getSourceRange();
 
   // C++11 [dcl.align]p2:
   //   -- if the constant expression evaluates to zero, the alignment
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -3254,6 +3254,10 @@
 : Warning<"requested alignment must be %0 bytes or smaller; maximum "
   "alignment assumed">,
   InGroup>;
+def warn_not_xl_compatible
+: Warning<"requesting an alignment of 16 bytes or greater for struct"
+  " members is not binary compatible with AIX XL 16.1 and older">,
+  InGroup;
 def warn_redeclaration_without_attribute_prev_attribute_ignored : Warning<
   "%q0 redeclared without %1 attribute: previous %1 ignored">,
   InGroup;
Index: clang/include/clang/Basic/DiagnosticGroups.td
===
--- clang/include/clang/Basic/DiagnosticGroups.td
+++ clang/include/clang/Basic/DiagnosticGroups.td
@@ -1083,6 +1083,9 @@
 // A warning group for warnings about code that clang accepts but gcc doesn't.
 def GccCompat : DiagGroup<"gcc-compat">;
 
+// A warning group for warnings about code that may be incompatible on AIX.
+def AIXCompat : DiagGroup<"aix-compat">;
+
 // Warnings for Microsoft extensions.
 def MicrosoftCharize : DiagGroup<"microsoft-charize">;
 def MicrosoftDrectveSection : DiagGroup<"microsoft-drectve-section">;


Index: clang/test/Sema/aix-attr-align.c
===
--- /dev/null
+++ clang/test/Sema/aix-attr-align.c
@@ -0,0 +1,22 @@
+// off-no-diagnostics
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -verify -fsyntax-only %s
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -verify -fsyntax-only %s
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix-xcoff -verify=off -Wno-aix-compat -fsyntax-only %s
+// RUN: %clang_cc1 -triple powerpc-ibm-aix-xcoff -verify=off -Wno-aix-compat -fsyntax-only %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-linux -verify=off -fsyntax-only %s
+
+struct S {
+  int a[8] __attribute__((aligned(8))); // no-warning
+};
+
+struct T {
+  int a[4] __attribute__((aligned(16))); // expected-warning {{requesting an alignment of 16 bytes or greater for struct members is not binary compatible with AIX XL 16.1 and older}}
+};
+
+struct U {
+  int a[2] __attribute__((aligned(32))); // expected-warning {{requesting an alignment of 16 bytes or greater for struct members is not binary compatible with AIX XL 16.1 and older}}
+};
+
+int a[8] __attribute__((aligned(8)));  // no-warning
+int b[4] __attribute

[PATCH] D105660: [PowerPC][AIX] Add warning when alignment is incompatible with XL

[Zarko Todorovski via Phabricator via cfe-commits]

ZarkoCA marked 2 inline comments as done.
ZarkoCA added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:3255-3256
+def warn_not_xl_compatible
+: Warning<"requested alignment of arguments 16 bytes or greater is not"
+  " compatible with previous versions of the AIX XL compiler">,
+  InGroup>;

aaron.ballman wrote:
> ZarkoCA wrote:
> > aaron.ballman wrote:
> > > ZarkoCA wrote:
> > > > aaron.ballman wrote:
> > > > > Should we be talking about the AIX XL compiler in a Clang diagnostic?
> > > > I see your point. Sorry if this isn't what is supposed to be done or if 
> > > > it doesn't a good precedent.
> > > > 
> > > > The reasons for adding this warning is that our back end implementation 
> > > > isn't totally compatible with XL now and, while buggy, users on AIX may 
> > > > expect clang and xlclang to be compatible since AIX is the reference 
> > > > compiler.  The xlclang name implies it's clang based and it's possible 
> > > > for users to expect some sort of binary compatibility.
> > > > 
> > > > I see your point. Sorry if this isn't what is supposed to be done or if 
> > > > it doesn't a good precedent.
> > > 
> > > No worries, it's a good discussion to have! We have some MSVC and GCC 
> > > compatibility warnings, so there's precedent for naming other compilers. 
> > > Now that you've moved the diagnostic into an AIX compatibility diagnostic 
> > > group, I am more comfortable with it. Thanks!
> > Thanks, glad it's better now. 
> I missed this last time, sorry, but is "arguments" actually necessary for the 
> diagnostic or can that be dropped?
It actually isn't correct, the warning should apply only to members of structs. 
 Thanks for bringing it to my attention again, I also missed this the last 
time. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105660

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

[PATCH] D105904: [clangd] Support `#pragma mark` in the outline

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

> However those difficulties don't apply here - I believe you can take the 
> current final representation (vector) + the list of marks and 
> produce a markified vector via a fairly natural tree walk. 
> And this does a *really* good job of isolating this feature - we literally 
> run the rest of the algorithm without it.
> (This is slightly different to what's done in the patch, I would actually 
> take it out of the DocumentOutline class entirely).
> I don't think this hurts efficiency much (I think/hope this ends up being a 
> move rather than a copy for most nodes). And I think it actually makes the 
> markifying code easier to reason about in this case, as it just deals with 
> line numbers/positions, without having the distraction of SourceLocation.
> @kadircet WDYT of this argument, before we make David go back and forth?

As discussed offline, I am sold. In the end both this approach and inserting 
marks as we build the tree share a lot in common. In both cases when inserting 
a node into the tree we need to figure out whether it should go under the 
current parent or there's a mark that should contain that node, which is 
possibly not present in the tree yet. Instead of looking at ast nodes, it is 
definitely more reasonable to look at the document symbol nodes. Also as you 
mentioned doing this afterwards definitely does a better job at isolating this 
from the rest + enables us to fix up ranges/ordering of the tree produced from 
ast.

Sorry for the hassle here David :/


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105904

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

[PATCH] D104797: [WebAssembly] Implementation of global.get/set for reftypes in LLVM IR

[Paulo Matos via Phabricator via cfe-commits]

pmatos added a comment.

@tlively once D105423  lands, is it enough to 
test and reland it under this revision or shall i open a new one?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104797

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

[PATCH] D105946: [PowerPC] Store, load, move from and to registers related builtins

[Lei Huang via Phabricator via cfe-commits]

lei added inline comments.



Comment at: llvm/include/llvm/IR/IntrinsicsPowerPC.td:1569
+  def int_ppc_sthcx : Intrinsic<[llvm_i32_ty], [llvm_ptr_ty, llvm_i32_ty], 
[IntrWriteMem]>;
+  def int_ppc_lharx : GCCBuiltin<"__builtin_ppc_lharx">,
+  Intrinsic<[llvm_i32_ty], [llvm_ptr_ty], [IntrNoMem]>;

do these loads not need `IntrReadMem`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105946

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

[PATCH] D105946: [PowerPC] Store, load, move from and to registers related builtins

[Lei Huang via Phabricator via cfe-commits]

lei added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:3371
+return SemaFeatureCheck(*this, TheCall, "extdiv",
+diag::err_ppc_builtin_only_on_arch, "8");
 #define CUSTOM_BUILTIN(Name, Intr, Types, Acc) \

need tests for these.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105946

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

[clang] 034b94b - Fix documentation; NFC

[Aaron Ballman via cfe-commits]

Author: liuke
Date: 2021-07-15T09:38:05-04:00
New Revision: 034b94bb7161c64234e4ec35bf49428c3a1f8f0a

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

LOG: Fix documentation; NFC

The documentation about ignoringImpCasts is wrong, which can cause
misunderstandings. This patch fixes it.

Added: 


Modified: 
clang/docs/LibASTMatchersReference.html
clang/include/clang/ASTMatchers/ASTMatchers.h

Removed: 




diff  --git a/clang/docs/LibASTMatchersReference.html 
b/clang/docs/LibASTMatchersReference.html
index 73309fb081f96..565f7f261 100644
--- a/clang/docs/LibASTMatchersReference.html
+++ b/clang/docs/LibASTMatchersReference.html
@@ -7701,7 +7701,7 @@ AST Traversal Matchers
 While
varDecl(hasInitializer(integerLiteral()))
varDecl(hasInitializer(declRefExpr()))
-only match the declarations for b, c, and d.
+only match the declarations for a.
 
 
 

diff  --git a/clang/include/clang/ASTMatchers/ASTMatchers.h 
b/clang/include/clang/ASTMatchers/ASTMatchers.h
index a13827df4405a..8e3ee6cb9e7e7 100644
--- a/clang/include/clang/ASTMatchers/ASTMatchers.h
+++ b/clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -913,7 +913,7 @@ AST_MATCHER_P(Expr, ignoringImplicit, 
internal::Matcher,
 ///varDecl(hasInitializer(integerLiteral()))
 ///varDecl(hasInitializer(declRefExpr()))
 /// \endcode
-/// only match the declarations for b, c, and d.
+/// only match the declarations for a.
 AST_MATCHER_P(Expr, ignoringImpCasts,
   internal::Matcher, InnerMatcher) {
   return InnerMatcher.matches(*Node.IgnoreImpCasts(), Finder, Builder);



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

[PATCH] D105973: [ASTMatchers] NFC: Fix the annotation.

[Aaron Ballman via Phabricator via cfe-commits]

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

Thank you for the patch! I've commit on your behalf in 
034b94bb7161c64234e4ec35bf49428c3a1f8f0a 
.


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

https://reviews.llvm.org/D105973

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

[PATCH] D106063: [Analyzer][solver] Remove unused functions

[Gabor Marton via Phabricator via cfe-commits]

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

../../git/llvm-project/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2395:17:
 warning: 'clang::ento::ProgramStateRef 
{anonymous}::RangeConstraintManager::setRange(clang::ento::ProgramStateRef, 
{anonymous}::EquivalenceClass, clang::ento::RangeSet)' defined but not used 
[-Wunused-function]
../../git/llvm-project/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2384:10:
 warning: 'clang::ento::RangeSet 
{anonymous}::RangeConstraintManager::getRange(clang::ento::ProgramStateRef, 
{anonymous}::EquivalenceClass)' defined but not used [-Wunused-function]


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106063

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp


Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -2381,23 +2381,12 @@
   return SymbolicRangeInferrer::inferRange(F, State, Sym);
 }
 
-RangeSet RangeConstraintManager::getRange(ProgramStateRef State,
-  EquivalenceClass Class) {
-  return SymbolicRangeInferrer::inferRange(F, State, Class);
-}
-
 ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef State,
  SymbolRef Sym,
  RangeSet Range) {
   return ConstraintAssignor::assign(State, getSValBuilder(), F, Sym, Range);
 }
 
-ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef State,
- EquivalenceClass Class,
- RangeSet Range) {
-  return ConstraintAssignor::assign(State, getSValBuilder(), F, Class, Range);
-}
-
 
//======
 // assumeSymX methods: protected interface for RangeConstraintManager.
 
//======/


Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -2381,23 +2381,12 @@
   return SymbolicRangeInferrer::inferRange(F, State, Sym);
 }
 
-RangeSet RangeConstraintManager::getRange(ProgramStateRef State,
-  EquivalenceClass Class) {
-  return SymbolicRangeInferrer::inferRange(F, State, Class);
-}
-
 ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef State,
  SymbolRef Sym,
  RangeSet Range) {
   return ConstraintAssignor::assign(State, getSValBuilder(), F, Sym, Range);
 }
 
-ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef State,
- EquivalenceClass Class,
- RangeSet Range) {
-  return ConstraintAssignor::assign(State, getSValBuilder(), F, Class, Range);
-}
-
 //======
 // assumeSymX methods: protected interface for RangeConstraintManager.
 //======/
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105692: [analyzer][solver][NFC] Introduce ConstraintAssignor

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

In D105692#2879186 , @uabelho wrote:

> Hi,
>
> When compiling with gcc I see the following new warnings with this patch:
>
>   [4/22] Building CXX object 
> tools/clang/lib/StaticAnalyzer/Core/CMakeFiles/obj.clangStaticAnalyzerCore.dir/RangeConstraintManager.cpp.o
>   
> /repo/uabelho/master-github/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2395:17:
>  warning: 'clang::ento::ProgramStateRef 
> {anonymous}::RangeConstraintManager::setRange(clang::ento::ProgramStateRef, 
> {anonymous}::EquivalenceClass, clang::ento::RangeSet)' defined but not used 
> [-Wunused-function]
>2395 | ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef 
> State,
> | ^~
>   
> /repo/uabelho/master-github/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2384:10:
>  warning: 'clang::ento::RangeSet 
> {anonymous}::RangeConstraintManager::getRange(clang::ento::ProgramStateRef, 
> {anonymous}::EquivalenceClass)' defined but not used [-Wunused-function]
>2384 | RangeSet RangeConstraintManager::getRange(ProgramStateRef State,
> |  ^~
>
> Will those methods be used or can they be removed?

I think they can be removed, waiting for Valeriy's approval.
https://reviews.llvm.org/D106063


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105692

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

[PATCH] D104744: [PowerPC] Add PowerPC rotate related builtins and emit target independent code for XL compatibility

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

LGTM other than a couple of nits.




Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15064
   }
+  case PPC::BI__builtin_ppc_rldimi:
+  case PPC::BI__builtin_ppc_rlwimi: {

Please add a comment describing the emitted code. Something like:
```
// Rotate and insert under mask operation.
// __rlwimi(rs, is, shift, mask)
// rotl(rs, shift) & mask) | (is & ~mask)
```



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15070
+  Ops[2] = Builder.CreateZExt(Ops[2], Int64Ty);
+Value *shift = Builder.CreateCall(F, {Ops[0], Ops[0], Ops[2]});
+Value *X = Builder.CreateAnd(shift, Ops[3]);

Nit: `s/shift/Shift` to conform to variable naming conventions. Here and 
elsewhere.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104744

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

[PATCH] D106064: [clang][deps] Normalize paths in minimizing file system

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 created this revision.
jansvoboda11 added reviewers: Bigcheese, dexonsmith, arphaman.
jansvoboda11 added a project: clang.
jansvoboda11 requested review of this revision.

This patch normalizes paths in `DependencyScanningWorkerFilesystem` so that 
lookup of ignored files and cached file entries works correctly on Windows 
(where `/` and `\` are equivalent).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106064

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


Index: clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -128,11 +128,11 @@
   // Add any filenames that were explicity passed in the build settings and
   // that might be opened, as we want to ensure we don't run source
   // minimization on them.
-  DepFS->IgnoredFiles.clear();
+  DepFS->clearIgnoredFiles();
   for (const auto &Entry : CI.getHeaderSearchOpts().UserEntries)
-DepFS->IgnoredFiles.insert(Entry.Path);
+DepFS->ignoreFile(Entry.Path);
   for (const auto &Entry : CI.getHeaderSearchOpts().VFSOverlayFiles)
-DepFS->IgnoredFiles.insert(Entry);
+DepFS->ignoreFile(Entry);
 
   // Support for virtual file system overlays on top of the caching
   // filesystem.
Index: clang/lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
@@ -149,9 +149,18 @@
   return shouldMinimize(Filename); // Only cache stat failures on source files.
 }
 
+void DependencyScanningWorkerFilesystem::ignoreFile(StringRef RawFilename) {
+  llvm::SmallString<256> Filename;
+  llvm::sys::path::native(RawFilename, Filename);
+  IgnoredFiles.insert(Filename);
+}
+
 llvm::ErrorOr
 DependencyScanningWorkerFilesystem::getOrCreateFileSystemEntry(
-const StringRef Filename) {
+const StringRef RawFilename) {
+  llvm::SmallString<256> Filename;
+  llvm::sys::path::native(RawFilename, Filename);
+
   if (const CachedFileSystemEntry *Entry = getCachedEntry(Filename)) {
 return Entry;
   }
Index: 
clang/include/clang/Tooling/DependencyScanning/DependencyScanningFilesystem.h
===
--- 
clang/include/clang/Tooling/DependencyScanning/DependencyScanningFilesystem.h
+++ 
clang/include/clang/Tooling/DependencyScanning/DependencyScanningFilesystem.h
@@ -153,8 +153,8 @@
   llvm::ErrorOr>
   openFileForRead(const Twine &Path) override;
 
-  /// The set of files that should not be minimized.
-  llvm::StringSet<> IgnoredFiles;
+  void clearIgnoredFiles() { IgnoredFiles.clear(); }
+  void ignoreFile(StringRef Filename);
 
 private:
   void setCachedEntry(StringRef Filename, const CachedFileSystemEntry *Entry) {
@@ -179,6 +179,8 @@
   /// excluded conditional directive skip mappings that are used by the
   /// currently active preprocessor.
   ExcludedPreprocessorDirectiveSkipMapping *PPSkipMappings;
+  /// The set of files that should not be minimized.
+  llvm::StringSet<> IgnoredFiles;
 };
 
 } // end namespace dependencies


Index: clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -128,11 +128,11 @@
   // Add any filenames that were explicity passed in the build settings and
   // that might be opened, as we want to ensure we don't run source
   // minimization on them.
-  DepFS->IgnoredFiles.clear();
+  DepFS->clearIgnoredFiles();
   for (const auto &Entry : CI.getHeaderSearchOpts().UserEntries)
-DepFS->IgnoredFiles.insert(Entry.Path);
+DepFS->ignoreFile(Entry.Path);
   for (const auto &Entry : CI.getHeaderSearchOpts().VFSOverlayFiles)
-DepFS->IgnoredFiles.insert(Entry);
+DepFS->ignoreFile(Entry);
 
   // Support for virtual file system overlays on top of the caching
   // filesystem.
Index: clang/lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningFilesystem.cpp
@@ -149,9 +149,18 @@
   return shouldMinimize(Filename); // Only cache stat failures on source files.
 }
 
+void DependencyScanningWorkerFilesyste

[PATCH] D104536: WIP: [clang][deps] Avoid minimizing PCH input files

[Jan Svoboda via Phabricator via cfe-commits]

jansvoboda11 updated this revision to Diff 358951.
jansvoboda11 edited the summary of this revision.
jansvoboda11 set the repository for this revision to rG LLVM Github Monorepo.
jansvoboda11 added a comment.

Rebase on top of D106064 , solving Windows CI 
failure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104536

Files:
  clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
  clang/test/ClangScanDeps/modules-pch.c

Index: clang/test/ClangScanDeps/modules-pch.c
===
--- clang/test/ClangScanDeps/modules-pch.c
+++ clang/test/ClangScanDeps/modules-pch.c
@@ -6,7 +6,7 @@
 // RUN: sed "s|DIR|%/t|g" %S/Inputs/modules-pch/cdb_pch.json > %t/cdb.json
 // RUN: echo -%t > %t/result_pch.json
 // RUN: clang-scan-deps -compilation-database %t/cdb.json -format experimental-full \
-// RUN:   -generate-modules-path-args -module-files-dir %t/build -mode preprocess >> %t/result_pch.json
+// RUN:   -generate-modules-path-args -module-files-dir %t/build >> %t/result_pch.json
 // RUN: cat %t/result_pch.json | sed 's:\?:/:g' | FileCheck %s -check-prefix=CHECK-PCH
 //
 // Check we didn't build the PCH during dependency scanning.
@@ -127,9 +127,8 @@
 //
 // RUN: sed "s|DIR|%/t|g" %S/Inputs/modules-pch/cdb_tu.json > %t/cdb.json
 // RUN: echo -%t > %t/result_tu.json
-// FIXME: Make this work with '-mode preprocess-minimized-sources'.
 // RUN: clang-scan-deps -compilation-database %t/cdb.json -format experimental-full \
-// RUN:   -generate-modules-path-args -module-files-dir %t/build -mode preprocess >> %t/result_tu.json
+// RUN:   -generate-modules-path-args -module-files-dir %t/build >> %t/result_tu.json
 // RUN: cat %t/result_tu.json | sed 's:\?:/:g' | FileCheck %s -check-prefix=CHECK-TU
 //
 // CHECK-TU:  -[[PREFIX:.*]]
@@ -193,7 +192,7 @@
 // RUN: sed "s|DIR|%/t|g" %S/Inputs/modules-pch/cdb_tu_with_common.json > %t/cdb.json
 // RUN: echo -%t > %t/result_tu_with_common.json
 // RUN: clang-scan-deps -compilation-database %t/cdb.json -format experimental-full \
-// RUN:   -generate-modules-path-args -module-files-dir %t/build -mode preprocess >> %t/result_tu_with_common.json
+// RUN:   -generate-modules-path-args -module-files-dir %t/build >> %t/result_tu_with_common.json
 // RUN: cat %t/result_tu_with_common.json | sed 's:\?:/:g' | FileCheck %s -check-prefix=CHECK-TU-WITH-COMMON
 //
 // CHECK-TU-WITH-COMMON:  -[[PREFIX:.*]]
Index: clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
===
--- clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
+++ clang/lib/Tooling/DependencyScanning/DependencyScanningWorker.cpp
@@ -46,25 +46,73 @@
   DependencyConsumer &C;
 };
 
-/// A listener that collects the names and paths to imported modules.
-class ImportCollectingListener : public ASTReaderListener {
-  using PrebuiltModuleFilesT =
-  decltype(HeaderSearchOptions::PrebuiltModuleFiles);
-
+/// A listener that collects the imported modules and optionally the input
+/// files.
+class PrebuiltModuleListener : public ASTReaderListener {
 public:
-  ImportCollectingListener(PrebuiltModuleFilesT &PrebuiltModuleFiles)
-  : PrebuiltModuleFiles(PrebuiltModuleFiles) {}
+  PrebuiltModuleListener(llvm::StringMap &PrebuiltModuleFiles,
+ llvm::StringSet<> &InputFiles, bool VisitInputFiles)
+  : PrebuiltModuleFiles(PrebuiltModuleFiles), InputFiles(InputFiles),
+VisitInputFiles(VisitInputFiles) {}
 
   bool needsImportVisitation() const override { return true; }
+  bool needsInputFileVisitation() override { return VisitInputFiles; }
+  bool needsSystemInputFileVisitation() override { return VisitInputFiles; }
 
   void visitImport(StringRef ModuleName, StringRef Filename) override {
-PrebuiltModuleFiles[std::string(ModuleName)] = std::string(Filename);
+PrebuiltModuleFiles.insert({ModuleName, Filename.str()});
+  }
+
+  bool visitInputFile(StringRef Filename, bool isSystem, bool isOverridden,
+  bool isExplicitModule) override {
+InputFiles.insert(Filename);
+return true;
   }
 
 private:
-  PrebuiltModuleFilesT &PrebuiltModuleFiles;
+  llvm::StringMap &PrebuiltModuleFiles;
+  llvm::StringSet<> &InputFiles;
+  bool VisitInputFiles;
 };
 
+using PrebuiltModuleFilesT = decltype(HeaderSearchOptions::PrebuiltModuleFiles);
+
+/// Visit the given prebuilt module and collect all of the modules it
+/// transitively imports and contributing input files.
+static void visitPrebuiltModule(StringRef PrebuiltModuleFilename,
+CompilerInstance &CI,
+PrebuiltModuleFilesT &ModuleFiles,
+llvm::StringSet<> &InputFiles,
+bool VisitInputFiles) {
+  // Maps the names o

[PATCH] D106063: [Analyzer][solver] Remove unused functions

[Valeriy Savchenko via Phabricator via cfe-commits]

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

Yes, let's do this!  Thanks for addressing it!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106063

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

[PATCH] D105692: [analyzer][solver][NFC] Introduce ConstraintAssignor

[Mikael Holmén via Phabricator via cfe-commits]

uabelho added a comment.

In D105692#2879983 , @martong wrote:

> In D105692#2879186 , @uabelho wrote:
>
>> Hi,
>>
>> When compiling with gcc I see the following new warnings with this patch:
>>
>>   [4/22] Building CXX object 
>> tools/clang/lib/StaticAnalyzer/Core/CMakeFiles/obj.clangStaticAnalyzerCore.dir/RangeConstraintManager.cpp.o
>>   
>> /repo/uabelho/master-github/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2395:17:
>>  warning: 'clang::ento::ProgramStateRef 
>> {anonymous}::RangeConstraintManager::setRange(clang::ento::ProgramStateRef, 
>> {anonymous}::EquivalenceClass, clang::ento::RangeSet)' defined but not used 
>> [-Wunused-function]
>>2395 | ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef 
>> State,
>> | ^~
>>   
>> /repo/uabelho/master-github/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2384:10:
>>  warning: 'clang::ento::RangeSet 
>> {anonymous}::RangeConstraintManager::getRange(clang::ento::ProgramStateRef, 
>> {anonymous}::EquivalenceClass)' defined but not used [-Wunused-function]
>>2384 | RangeSet RangeConstraintManager::getRange(ProgramStateRef State,
>> |  ^~
>>
>> Will those methods be used or can they be removed?
>
> I think they can be removed, waiting for Valeriy's approval.
> https://reviews.llvm.org/D106063

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105692

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

[PATCH] D105660: [PowerPC][AIX] Add warning when alignment is incompatible with XL

[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, thank you!




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:3255-3256
+def warn_not_xl_compatible
+: Warning<"requested alignment of arguments 16 bytes or greater is not"
+  " compatible with previous versions of the AIX XL compiler">,
+  InGroup>;

ZarkoCA wrote:
> aaron.ballman wrote:
> > ZarkoCA wrote:
> > > aaron.ballman wrote:
> > > > ZarkoCA wrote:
> > > > > aaron.ballman wrote:
> > > > > > Should we be talking about the AIX XL compiler in a Clang 
> > > > > > diagnostic?
> > > > > I see your point. Sorry if this isn't what is supposed to be done or 
> > > > > if it doesn't a good precedent.
> > > > > 
> > > > > The reasons for adding this warning is that our back end 
> > > > > implementation isn't totally compatible with XL now and, while buggy, 
> > > > > users on AIX may expect clang and xlclang to be compatible since AIX 
> > > > > is the reference compiler.  The xlclang name implies it's clang based 
> > > > > and it's possible for users to expect some sort of binary 
> > > > > compatibility.
> > > > > 
> > > > > I see your point. Sorry if this isn't what is supposed to be done or 
> > > > > if it doesn't a good precedent.
> > > > 
> > > > No worries, it's a good discussion to have! We have some MSVC and GCC 
> > > > compatibility warnings, so there's precedent for naming other 
> > > > compilers. Now that you've moved the diagnostic into an AIX 
> > > > compatibility diagnostic group, I am more comfortable with it. Thanks!
> > > Thanks, glad it's better now. 
> > I missed this last time, sorry, but is "arguments" actually necessary for 
> > the diagnostic or can that be dropped?
> It actually isn't correct, the warning should apply only to members of 
> structs.  Thanks for bringing it to my attention again, I also missed this 
> the last time. 
Huttah for code review working as intended! :-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105660

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

[clang] f24335c - MachO: fix Clang test broken by dropping private labels in LLVM.

[Tim Northover via cfe-commits]

Author: Tim Northover
Date: 2021-07-15T15:05:08+01:00
New Revision: f24335c69ea363082d922797363e98f1dcb3b14f

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

LOG: MachO: fix Clang test broken by dropping private labels in LLVM.

LLVM changed to not emit L... labels for things marked "do_not_dead_strip"
because the linker can sometimes drop the flag if there's no proper symbol.
This Clang test checked for the old behaviour, but doesn't actually care about
that bit.

Added: 


Modified: 
clang/test/CodeGenObjC/protocol-in-extended-class.m

Removed: 




diff  --git a/clang/test/CodeGenObjC/protocol-in-extended-class.m 
b/clang/test/CodeGenObjC/protocol-in-extended-class.m
index 26c858e53e803..74f1be9e53b5a 100644
--- a/clang/test/CodeGenObjC/protocol-in-extended-class.m
+++ b/clang/test/CodeGenObjC/protocol-in-extended-class.m
@@ -26,4 +26,4 @@ -(void) Meth {
 
 // CHECK-LP64: __OBJC_PROTOCOL_$_ExtendedProtocol:
 
-// CHECK-LP32: L_OBJC_PROTOCOL_ExtendedProtocol:
+// CHECK-LP32: _OBJC_PROTOCOL_ExtendedProtocol:



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

[PATCH] D105083: [clangd] Ensure Ref::Container refers to an indexed symbol

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

thanks, lgtm!
sorry for the late reply :( adding a couple nits.




Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:170
+  while (Enclosing) {
+const NamedDecl *ND = dyn_cast_or_null(Enclosing);
+if (ND && SymbolCollector::shouldCollectSymbol(*ND, ND->getASTContext(),

not need for `_or_null` as loop condition ensures `Enclosing != nullptr`

nit: `const auto *ND`



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:173
+   Opts, true)) {
+  return ND;
+}

nit: I'd just break here and `return Enclosing` outside.



Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:489
 DeclRefs[ND].push_back(
-SymbolRef{SM.getFileLoc(Loc), Roles, ASTNode.Parent});
+SymbolRef{SM.getFileLoc(Loc), Roles, getRefContainer(ASTNode.Parent)});
   // Don't continue indexing if this is a mere reference.

nridge wrote:
> kadircet wrote:
> > nridge wrote:
> > > kadircet wrote:
> > > > as mentioned above I think we should start the traversal from 
> > > > `ASTNode.ParentDC`. any downsides to doing that ? I don't see a case 
> > > > where this container we return is **not** a `DeclContext`.
> > > I assume you mean `ASTNode.ContainerDC`.
> > > 
> > > I tried this suggestion, but it looks like `ContainerDC` does not contain 
> > > what we want in many cases.
> > > 
> > > For all of the following cases in `SymbolCollectorTest.RefContainers`:
> > > 
> > >  * ref2 (variable initializer)
> > >  * ref3 (function parameter default value)
> > >  * ref5 (template parameter default value)
> > >  * ref6 (type of variable)
> > >  * ref7a (return type of function)
> > >  * ref7b (parameter type of function)
> > > 
> > > `ASTNode.ContainerDC` is the `TranslationUnitDecl` (i.e. the 
> > > `DeclContext` in which the function or variable is declared) rather than 
> > > the function or variable itself.
> > > 
> > > In addition, for ref4 (member initializer), `ContainerDC` is the 
> > > `RecordDecl` rather than the `FieldDecl`.
> > > 
> > > So, I don't think this suggestion will work without making the 
> > > `Ref::Container` field significantly less specific (and thereby the call 
> > > hierarchy feature less useful in some cases).
> > > 
> > > I assume you mean ASTNode.ContainerDC.
> > 
> > yes, sorry for the mess.
> > 
> > > So, I don't think this suggestion will work without making the 
> > > Ref::Container field significantly less specific (and thereby the call 
> > > hierarchy feature less useful in some cases).
> > 
> > I can't seem to remember why we went with it in the first place. But now:
> > ```
> > int foo();
> > int x = foo();
> > void bar() {
> >   int y = foo();
> > }
> > ```
> > 
> > calling call hierarchy on `foo` will yield `x` and `bar`, creating some 
> > sort of discrepancy. I am not really sure if telling first call to `foo` is 
> > contained in `x` is really useful compared to saying it was contained in 
> > `filename.cpp` (but ofc we can't do that today as container needs to be a 
> > symbol in the index, hence the ref will be lost instead). do you also think 
> > that would be more useful (i am not really a user of this feature so I 
> > would like to hear which is better from some users)?
> > 
> > also I can't say that I find the discrepancy between an initializer in 
> > parmvardecl/nontypetemplateparm vs vardecl useful (i know it already exists 
> > today, but not really sure why).
> > they are actually attached to the first declcontext containing them, not 
> > the first decl (which you say is more useful, let's leave the fact that 
> > they are not indexed out for a while).
> > moreover it is a behavior we rely on through libindex, as it just marks 
> > `ASTNode.Parent` with declcontext rather than making use of the vardecl. 
> > which makes me believe it is not really important to have the top-level 
> > symbol as the container. But it is the only way we can retain some 
> > container information. 
> > if that's the case, I believe we should make this more explicit, i.e. start 
> > a traversal from the node itself, remember the last indexed decl we've seen 
> > as a parent and return that if we failed to find any indexed declcontext's 
> > containing the decl (with a fixme saying that we could have some file 
> > symbols in the index for translationunitdecls).
> > That way we can say that the container is the first `DeclContext` 
> > containing the reference (with the exception of fixme mentioned).
> > I am not really sure if telling first call to foo is contained in x is 
> > really useful compared to saying it was contained in filename.cpp [...] do 
> > you also think that would be more useful (i am not really a user of this 
> > feature so I would like to hear which is better from some users)?
> 
> 

[clang] 05eb59e - [OpenCL] Add support of __opencl_c_program_scope_global_variables feature macro

[Anton Zabaznov via cfe-commits]

Author: Anton Zabaznov
Date: 2021-07-15T17:21:19+03:00
New Revision: 05eb59e1d0ea7505539434a32ccc5c3dc2097597

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

LOG: [OpenCL] Add support of __opencl_c_program_scope_global_variables feature 
macro

Reviewed By: Anastasia

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

Added: 


Modified: 
clang/include/clang/Basic/OpenCLOptions.h
clang/lib/Sema/SemaDecl.cpp
clang/test/CodeGenOpenCL/addr-space-struct-arg.cl
clang/test/SemaOpenCL/storageclass.cl

Removed: 




diff  --git a/clang/include/clang/Basic/OpenCLOptions.h 
b/clang/include/clang/Basic/OpenCLOptions.h
index 41db6b712a631..1a035626fade4 100644
--- a/clang/include/clang/Basic/OpenCLOptions.h
+++ b/clang/include/clang/Basic/OpenCLOptions.h
@@ -67,7 +67,23 @@ static inline bool isOpenCLVersionContainedInMask(const 
LangOptions &LO,
 
 /// OpenCL supported extensions and optional core features
 class OpenCLOptions {
+
 public:
+  // OpenCL C v1.2 s6.5 - All program scope variables must be declared in the
+  // __constant address space.
+  // OpenCL C v2.0 s6.5.1 - Variables defined at program scope and static
+  // variables inside a function can also be declared in the global
+  // address space.
+  // OpenCL C v3.0 s6.7.1 - Variables at program scope or static or extern
+  // variables inside functions can be declared in global address space if
+  // the __opencl_c_program_scope_global_variables feature is supported
+  // C++ for OpenCL inherits rule from OpenCL C v2.0.
+  bool areProgramScopeVariablesSupported(const LangOptions &Opts) const {
+return Opts.OpenCLCPlusPlus || Opts.OpenCLVersion == 200 ||
+   (Opts.OpenCLVersion == 300 &&
+isSupported("__opencl_c_program_scope_global_variables", Opts));
+  }
+
   struct OpenCLOptionInfo {
 // Does this option have pragma.
 bool WithPragma = false;

diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index c2dcdf0b8d1f6..b25c3650b1607 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -6424,7 +6424,11 @@ void Sema::deduceOpenCLAddressSpace(ValueDecl *Decl) {
 if (Type->isSamplerT() || Type->isVoidType())
   return;
 LangAS ImplAS = LangAS::opencl_private;
-if ((getLangOpts().OpenCLCPlusPlus || getLangOpts().OpenCLVersion >= 200) 
&&
+// OpenCL C v3.0 s6.7.8 - For OpenCL C 2.0 or with the
+// __opencl_c_program_scope_global_variables feature, the address space
+// for a variable at program scope or a static or extern variable inside
+// a function are inferred to be __global.
+if (getOpenCLOptions().areProgramScopeVariablesSupported(getLangOpts()) &&
 Var->hasGlobalStorage())
   ImplAS = LangAS::opencl_global;
 // If the original type from a decayed type is an array type and that array
@@ -8018,23 +8022,16 @@ void Sema::CheckVariableDeclarationType(VarDecl *NewVD) 
{
   }
 }
 
-// OpenCL C v1.2 s6.5 - All program scope variables must be declared in the
-// __constant address space.
-// OpenCL C v2.0 s6.5.1 - Variables defined at program scope and static
-// variables inside a function can also be declared in the global
-// address space.
-// C++ for OpenCL inherits rule from OpenCL C v2.0.
 // FIXME: Adding local AS in C++ for OpenCL might make sense.
 if (NewVD->isFileVarDecl() || NewVD->isStaticLocal() ||
 NewVD->hasExternalStorage()) {
-  if (!T->isSamplerT() &&
-  !T->isDependentType() &&
+  if (!T->isSamplerT() && !T->isDependentType() &&
   !(T.getAddressSpace() == LangAS::opencl_constant ||
 (T.getAddressSpace() == LangAS::opencl_global &&
- (getLangOpts().OpenCLVersion == 200 ||
-  getLangOpts().OpenCLCPlusPlus {
+ getOpenCLOptions().areProgramScopeVariablesSupported(
+ getLangOpts() {
 int Scope = NewVD->isStaticLocal() | NewVD->hasExternalStorage() << 1;
-if (getLangOpts().OpenCLVersion == 200 || 
getLangOpts().OpenCLCPlusPlus)
+if 
(getOpenCLOptions().areProgramScopeVariablesSupported(getLangOpts()))
   Diag(NewVD->getLocation(), 
diag::err_opencl_global_invalid_addr_space)
   << Scope << "global or constant";
 else

diff  --git a/clang/test/CodeGenOpenCL/addr-space-struct-arg.cl 
b/clang/test/CodeGenOpenCL/addr-space-struct-arg.cl
index 21e0f2b057475..d24c9c5f85a4b 100644
--- a/clang/test/CodeGenOpenCL/addr-space-struct-arg.cl
+++ b/clang/test/CodeGenOpenCL/addr-space-struct-arg.cl
@@ -2,6 +2,8 @@
 // RUN: %clang_cc1 %s -emit-llvm -o - -O0 -triple amdgcn | FileCheck 
-enable-var-scope -check-prefixes=ALL,AMDGCN %s
 // RUN: %clang_cc1 %s -emit-llvm -o - -cl-std=CL2.0 -O0 -tripl

[PATCH] D103191: [OpenCL] Add support of __opencl_c_program_scope_global_variables feature macro

[Anton Zabaznov via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG05eb59e1d0ea: [OpenCL] Add support of 
__opencl_c_program_scope_global_variables feature macro (authored by azabaznov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103191

Files:
  clang/include/clang/Basic/OpenCLOptions.h
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CodeGenOpenCL/addr-space-struct-arg.cl
  clang/test/SemaOpenCL/storageclass.cl

Index: clang/test/SemaOpenCL/storageclass.cl
===
--- clang/test/SemaOpenCL/storageclass.cl
+++ clang/test/SemaOpenCL/storageclass.cl
@@ -1,28 +1,118 @@
 // RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL1.2
-
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=-__opencl_c_program_scope_global_variables,-__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=+__opencl_c_program_scope_global_variables,-__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=-__opencl_c_program_scope_global_variables,+__opencl_c_generic_address_space
+// RUN: %clang_cc1 %s -verify -pedantic -fsyntax-only -cl-std=CL3.0 -cl-ext=+__opencl_c_program_scope_global_variables,+__opencl_c_generic_address_space
 static constant int G1 = 0;
 constant int G2 = 0;
-int G3 = 0;// expected-error{{program scope variable must reside in constant address space}}
-global int G4 = 0; // expected-error{{program scope variable must reside in constant address space}}
 
-static float g_implicit_static_var = 0; // expected-error {{program scope variable must reside in constant address space}}
+int G3 = 0;
+#ifndef __opencl_c_program_scope_global_variables
+// expected-error@-2 {{program scope variable must reside in constant address space}}
+#endif
+
+global int G4 = 0;
+#ifndef __opencl_c_program_scope_global_variables
+// expected-error@-2 {{program scope variable must reside in constant address space}}
+#endif
+
+static float g_implicit_static_var = 0;
+#ifndef __opencl_c_program_scope_global_variables
+// expected-error@-2 {{program scope variable must reside in constant address space}}
+#endif
+
 static constant float g_constant_static_var = 0;
-static global float g_global_static_var = 0;   // expected-error {{program scope variable must reside in constant address space}}
-static local float g_local_static_var = 0; // expected-error {{program scope variable must reside in constant address space}}
-static private float g_private_static_var = 0; // expected-error {{program scope variable must reside in constant address space}}
-static generic float g_generic_static_var = 0; // expected-error{{OpenCL C version 1.2 does not support the 'generic' type qualifier}} // expected-error {{program scope variable must reside in constant address space}}
 
-extern float g_implicit_extern_var; // expected-error {{extern variable must reside in constant address space}}
+static global float g_global_static_var = 0;
+#ifndef __opencl_c_program_scope_global_variables
+// expected-error@-2 {{program scope variable must reside in constant address space}}
+#endif
+
+static local float g_local_static_var = 0;
+#ifndef __opencl_c_program_scope_global_variables
+// expected-error@-2 {{program scope variable must reside in constant address space}}
+#else
+// expected-error@-4 {{program scope variable must reside in global or constant address space}}
+#endif
+
+static private float g_private_static_var = 0;
+#ifndef __opencl_c_program_scope_global_variables
+// expected-error@-2 {{program scope variable must reside in constant address space}}
+#else
+// expected-error@-4 {{program scope variable must reside in global or constant address space}}
+#endif
+
+static generic float g_generic_static_var = 0;
+#if (__OPENCL_C_VERSION__ < 300)
+// expected-error@-2 {{OpenCL C version 1.2 does not support the 'generic' type qualifier}}
+// expected-error@-3 {{program scope variable must reside in constant address space}}
+#elif (__OPENCL_C_VERSION__ == 300)
+ #if !defined(__opencl_c_generic_address_space)
+// expected-error@-6 {{OpenCL C version 3.0 does not support the 'generic' type qualifier}}
+ #endif
+ #if !defined(__opencl_c_program_scope_global_variables)
+// expected-error@-9 {{program scope variable must reside in constant address space}}
+ #endif
+ #if defined(__opencl_c_generic_address_space) && defined(__opencl_c_program_scope_global_variables)
+// expected-error@-12 {{program scope variable must reside in global or constant address space}}
+ #endif
+#endif
+
+extern float g_implicit_extern_var;
+#ifndef __opencl_c_program_scope_global_variables
+// expected-error@-2 {{extern variable must reside in constant address space}}
+#endif
+
 extern constant float g_constant_extern_var;

[clang] d0d37fc - [Analyzer][solver] Remove unused functions

[Gabor Marton via cfe-commits]

Author: Gabor Marton
Date: 2021-07-15T16:36:01+02:00
New Revision: d0d37fcc4e2965c4ccd3401f8bdf22935815136a

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

LOG: [Analyzer][solver] Remove unused functions

../../git/llvm-project/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2395:17:
 warning: 'clang::ento::ProgramStateRef 
{anonymous}::RangeConstraintManager::setRange(clang::ento::ProgramStateRef, 
{anonymous}::EquivalenceClass, clang::ento::RangeSet)' defined but not used 
[-Wunused-function]
../../git/llvm-project/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:2384:10:
 warning: 'clang::ento::RangeSet 
{anonymous}::RangeConstraintManager::getRange(clang::ento::ProgramStateRef, 
{anonymous}::EquivalenceClass)' defined but not used [-Wunused-function]

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

Added: 


Modified: 
clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp 
b/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
index aba97e48756aa..f550aca808e56 100644
--- a/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ b/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -2381,23 +2381,12 @@ RangeSet 
RangeConstraintManager::getRange(ProgramStateRef State,
   return SymbolicRangeInferrer::inferRange(F, State, Sym);
 }
 
-RangeSet RangeConstraintManager::getRange(ProgramStateRef State,
-  EquivalenceClass Class) {
-  return SymbolicRangeInferrer::inferRange(F, State, Class);
-}
-
 ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef State,
  SymbolRef Sym,
  RangeSet Range) {
   return ConstraintAssignor::assign(State, getSValBuilder(), F, Sym, Range);
 }
 
-ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef State,
- EquivalenceClass Class,
- RangeSet Range) {
-  return ConstraintAssignor::assign(State, getSValBuilder(), F, Class, Range);
-}
-
 
//======
 // assumeSymX methods: protected interface for RangeConstraintManager.
 
//======/



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

[PATCH] D106063: [Analyzer][solver] Remove unused functions

[Gabor Marton 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 rGd0d37fcc4e29: [Analyzer][solver] Remove unused functions 
(authored by martong).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106063

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp


Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -2381,23 +2381,12 @@
   return SymbolicRangeInferrer::inferRange(F, State, Sym);
 }
 
-RangeSet RangeConstraintManager::getRange(ProgramStateRef State,
-  EquivalenceClass Class) {
-  return SymbolicRangeInferrer::inferRange(F, State, Class);
-}
-
 ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef State,
  SymbolRef Sym,
  RangeSet Range) {
   return ConstraintAssignor::assign(State, getSValBuilder(), F, Sym, Range);
 }
 
-ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef State,
- EquivalenceClass Class,
- RangeSet Range) {
-  return ConstraintAssignor::assign(State, getSValBuilder(), F, Class, Range);
-}
-
 
//======
 // assumeSymX methods: protected interface for RangeConstraintManager.
 
//======/


Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -2381,23 +2381,12 @@
   return SymbolicRangeInferrer::inferRange(F, State, Sym);
 }
 
-RangeSet RangeConstraintManager::getRange(ProgramStateRef State,
-  EquivalenceClass Class) {
-  return SymbolicRangeInferrer::inferRange(F, State, Class);
-}
-
 ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef State,
  SymbolRef Sym,
  RangeSet Range) {
   return ConstraintAssignor::assign(State, getSValBuilder(), F, Sym, Range);
 }
 
-ProgramStateRef RangeConstraintManager::setRange(ProgramStateRef State,
- EquivalenceClass Class,
- RangeSet Range) {
-  return ConstraintAssignor::assign(State, getSValBuilder(), F, Class, Range);
-}
-
 //======
 // assumeSymX methods: protected interface for RangeConstraintManager.
 //======/
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D106065: [Clang] Add an empty builtins.h file.

[Stefan Pintilie via Phabricator via cfe-commits]

stefanp created this revision.
stefanp added reviewers: nemanjai, lei.
Herald added a subscriber: mgorny.
stefanp requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

On Power PC some legacy compilers included a number of builtins in a
builtins.h header file. While this header file is not required to hold
builtins for clang some legacy code does try to include this file and so
this patch provides an empty version of that file.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106065

Files:
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/builtins.h
  clang/test/Headers/builtins-header.c


Index: clang/test/Headers/builtins-header.c
===
--- /dev/null
+++ clang/test/Headers/builtins-header.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown -ffreestanding -emit-llvm 
-o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -ffreestanding 
-emit-llvm -o - %s | FileCheck %s
+
+#include 
+
+// Verify that we can include 
+
+// CHECK: target triple = "powerpc64
Index: clang/lib/Headers/builtins.h
===
--- /dev/null
+++ clang/lib/Headers/builtins.h
@@ -0,0 +1,12 @@
+/*=== builtins.h - Standard header for extra builtins 
-===*\
+ *
+ * Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+ * See https://llvm.org/LICENSE.txt for license information.
+ * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+ *
+\*===--===*/
+
+#ifndef __BUILTINS_H
+#define __BUILTINS_H
+
+#endif /* __BUILTINS_H */
Index: clang/lib/Headers/CMakeLists.txt
===
--- clang/lib/Headers/CMakeLists.txt
+++ clang/lib/Headers/CMakeLists.txt
@@ -38,6 +38,7 @@
   avxvnniintrin.h
   bmi2intrin.h
   bmiintrin.h
+  builtins.h
   __clang_cuda_builtin_vars.h
   __clang_cuda_math.h
   __clang_cuda_cmath.h


Index: clang/test/Headers/builtins-header.c
===
--- /dev/null
+++ clang/test/Headers/builtins-header.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown -ffreestanding -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -ffreestanding -emit-llvm -o - %s | FileCheck %s
+
+#include 
+
+// Verify that we can include 
+
+// CHECK: target triple = "powerpc64
Index: clang/lib/Headers/builtins.h
===
--- /dev/null
+++ clang/lib/Headers/builtins.h
@@ -0,0 +1,12 @@
+/*=== builtins.h - Standard header for extra builtins -===*\
+ *
+ * Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+ * See https://llvm.org/LICENSE.txt for license information.
+ * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+ *
+\*===--===*/
+
+#ifndef __BUILTINS_H
+#define __BUILTINS_H
+
+#endif /* __BUILTINS_H */
Index: clang/lib/Headers/CMakeLists.txt
===
--- clang/lib/Headers/CMakeLists.txt
+++ clang/lib/Headers/CMakeLists.txt
@@ -38,6 +38,7 @@
   avxvnniintrin.h
   bmi2intrin.h
   bmiintrin.h
+  builtins.h
   __clang_cuda_builtin_vars.h
   __clang_cuda_math.h
   __clang_cuda_cmath.h
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D103938: Diagnose -Wunused-value in constant evaluation context

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Sema/Sema.h:5077
 
+  /// Conditionally issue a diagnostic based on the statements reachability
+  /// analysis evaluation context.





Comment at: clang/test/Sema/i-c-e.c:77-78
+  // expected-warning {{expression result unused}}
+int comma3[(1, 2)];   // expected-warning {{variable length array folded to 
constant array as an extension}} \
+  // expected-warning {{expression result unused}}
 

I think this diagnostic is kind of unfortunate because it increases my 
confusion -- the expression result is most assuredly *not* unused in these 
cases because it's used in the definition of the type.



Comment at: clang/test/SemaCXX/warn-unused-value.cpp:145
+namespace test5 {
+int v[(5, 6)]; // expected-warning {{expression result unused}}
+void foo() {

This is another one that tripped me up due to the diagnostic wording.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103938

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

[PATCH] D106069: [HIP] Add test with_fopenmp.hip

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added reviewers: tra, ashi1.
Herald added subscribers: guansong, mgorny.
yaxunl requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added a subscriber: sstefan1.

Add a test to test-suite for testing std::isnan in host and device functions
when compiled with -fopenmp.


Repository:
  rT test-suite

https://reviews.llvm.org/D106069

Files:
  External/HIP/CMakeLists.txt
  External/HIP/with-fopenmp.hip
  External/HIP/with-fopenmp.reference_output


Index: External/HIP/with-fopenmp.reference_output
===
--- /dev/null
+++ External/HIP/with-fopenmp.reference_output
@@ -0,0 +1,2 @@
+PASSED!
+exit 0
Index: External/HIP/with-fopenmp.hip
===
--- /dev/null
+++ External/HIP/with-fopenmp.hip
@@ -0,0 +1,33 @@
+#include 
+#include 
+
+// Test use of std::isnan in device and host code.
+
+namespace TestIsNan {
+__device__ bool DevPass = false;
+
+__global__ void kernel() {
+  double X = 1.0;
+  DevPass = !std::isnan(X);
+}
+
+bool test() {
+  double X = 1.0;
+  kernel<<<1, 1>>>();
+  bool Pass;
+  hipMemcpyFromSymbol(&Pass, DevPass, sizeof(DevPass));
+  return Pass & !std::isnan(X);
+}
+}
+
+int main() {
+  bool Pass = TestIsNan::test();
+
+  if (!Pass) {
+printf("FAILED!\n");
+return 1;
+  }
+
+  printf("PASSED!\n");
+  return 0;
+}
Index: External/HIP/CMakeLists.txt
===
--- External/HIP/CMakeLists.txt
+++ External/HIP/CMakeLists.txt
@@ -5,8 +5,12 @@
 # Create targets for HIP tests that are part of the test suite.
 macro(create_local_hip_tests VariantSuffix)
   set(VariantOffload "hip")
+  # Set per-source compilation/link options
+  set_source_files_properties(with_fopenmp.hip PROPERTIES
+COMPILE_FLAGS -fopenmp)
   # Add HIP tests to be added to hip-tests-simple
   list(APPEND HIP_LOCAL_TESTS empty)
+  list(APPEND HIP_LOCAL_TESTS with_fopenmp)
   list(APPEND HIP_LOCAL_TESTS saxpy)
   foreach(_hip_test IN LISTS HIP_LOCAL_TESTS)
 create_one_local_test(${_hip_test} ${_hip_test}.hip


Index: External/HIP/with-fopenmp.reference_output
===
--- /dev/null
+++ External/HIP/with-fopenmp.reference_output
@@ -0,0 +1,2 @@
+PASSED!
+exit 0
Index: External/HIP/with-fopenmp.hip
===
--- /dev/null
+++ External/HIP/with-fopenmp.hip
@@ -0,0 +1,33 @@
+#include 
+#include 
+
+// Test use of std::isnan in device and host code.
+
+namespace TestIsNan {
+__device__ bool DevPass = false;
+
+__global__ void kernel() {
+  double X = 1.0;
+  DevPass = !std::isnan(X);
+}
+
+bool test() {
+  double X = 1.0;
+  kernel<<<1, 1>>>();
+  bool Pass;
+  hipMemcpyFromSymbol(&Pass, DevPass, sizeof(DevPass));
+  return Pass & !std::isnan(X);
+}
+}
+
+int main() {
+  bool Pass = TestIsNan::test();
+
+  if (!Pass) {
+printf("FAILED!\n");
+return 1;
+  }
+
+  printf("PASSED!\n");
+  return 0;
+}
Index: External/HIP/CMakeLists.txt
===
--- External/HIP/CMakeLists.txt
+++ External/HIP/CMakeLists.txt
@@ -5,8 +5,12 @@
 # Create targets for HIP tests that are part of the test suite.
 macro(create_local_hip_tests VariantSuffix)
   set(VariantOffload "hip")
+  # Set per-source compilation/link options
+  set_source_files_properties(with_fopenmp.hip PROPERTIES
+COMPILE_FLAGS -fopenmp)
   # Add HIP tests to be added to hip-tests-simple
   list(APPEND HIP_LOCAL_TESTS empty)
+  list(APPEND HIP_LOCAL_TESTS with_fopenmp)
   list(APPEND HIP_LOCAL_TESTS saxpy)
   foreach(_hip_test IN LISTS HIP_LOCAL_TESTS)
 create_one_local_test(${_hip_test} ${_hip_test}.hip
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D106070: [HIP] Remove workaround in __clang_hip_runtime_wrapper.h

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added reviewers: tra, JonChesterfield, ronl, ashi1.
yaxunl requested review of this revision.
Herald added a reviewer: jdoerfert.
Herald added a subscriber: sstefan1.

Remove the workaround for -fopenmp in __clang_hip_runtime_wrapper.h
since it causes device functions in HIP wrapper headers disabled when
compiling HIP program with -fopenmp.


https://reviews.llvm.org/D106070

Files:
  clang/lib/Headers/__clang_hip_runtime_wrapper.h


Index: clang/lib/Headers/__clang_hip_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_hip_runtime_wrapper.h
+++ clang/lib/Headers/__clang_hip_runtime_wrapper.h
@@ -101,7 +101,6 @@
 #include <__clang_hip_libdevice_declares.h>
 #include <__clang_hip_math.h>
 
-#if !_OPENMP || __HIP_ENABLE_CUDA_WRAPPER_FOR_OPENMP__
 #if defined(__HIPCC_RTC__)
 #include <__clang_hip_cmath.h>
 #else
@@ -112,7 +111,6 @@
 #include 
 #include 
 #endif // __HIPCC_RTC__
-#endif // !_OPENMP || __HIP_ENABLE_CUDA_WRAPPER_FOR_OPENMP__
 
 #define __CLANG_HIP_RUNTIME_WRAPPER_INCLUDED__ 1
 #if defined(__HIPCC_RTC__)


Index: clang/lib/Headers/__clang_hip_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_hip_runtime_wrapper.h
+++ clang/lib/Headers/__clang_hip_runtime_wrapper.h
@@ -101,7 +101,6 @@
 #include <__clang_hip_libdevice_declares.h>
 #include <__clang_hip_math.h>
 
-#if !_OPENMP || __HIP_ENABLE_CUDA_WRAPPER_FOR_OPENMP__
 #if defined(__HIPCC_RTC__)
 #include <__clang_hip_cmath.h>
 #else
@@ -112,7 +111,6 @@
 #include 
 #include 
 #endif // __HIPCC_RTC__
-#endif // !_OPENMP || __HIP_ENABLE_CUDA_WRAPPER_FOR_OPENMP__
 
 #define __CLANG_HIP_RUNTIME_WRAPPER_INCLUDED__ 1
 #if defined(__HIPCC_RTC__)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D104420: thread_local support for AIX

[Jamie Schmeiser via Phabricator via cfe-commits]

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

Respond to review comments, formatting: fix comments, add assertion, fix
linkage, expand test to include body of generated function.


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

https://reviews.llvm.org/D104420

Files:
  clang/lib/CodeGen/CGDeclCXX.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/test/CodeGenCXX/cxx11-thread-local-reference.cpp
  clang/test/CodeGenCXX/cxx11-thread-local-visibility.cpp
  clang/test/CodeGenCXX/cxx11-thread-local.cpp

Index: clang/test/CodeGenCXX/cxx11-thread-local.cpp
===
--- clang/test/CodeGenCXX/cxx11-thread-local.cpp
+++ clang/test/CodeGenCXX/cxx11-thread-local.cpp
@@ -1,19 +1,20 @@
-// RUN: %clang_cc1 -std=c++11 -emit-llvm %s -o - -triple x86_64-linux-gnu | FileCheck --check-prefix=CHECK --check-prefix=LINUX %s
-// RUN: %clang_cc1 -std=c++11 -emit-llvm %s -O2 -disable-llvm-passes -o - -triple x86_64-linux-gnu | FileCheck --check-prefix=CHECK --check-prefix=LINUX --check-prefix=CHECK-OPT %s
+// RUN: %clang_cc1 -std=c++11 -emit-llvm %s -o - -triple x86_64-linux-gnu | FileCheck --check-prefixes=CHECK,LINUX,LINUX_AIX %s
+// RUN: %clang_cc1 -std=c++11 -emit-llvm %s -O2 -disable-llvm-passes -o - -triple x86_64-linux-gnu | FileCheck --check-prefixes=CHECK,LINUX,LINUX_AIX,CHECK-OPT %s
 // RUN: %clang_cc1 -std=c++11 -femulated-tls -emit-llvm %s -o - \
-// RUN: -triple x86_64-linux-gnu 2>&1 | FileCheck --check-prefix=CHECK --check-prefix=LINUX %s
+// RUN: -triple x86_64-linux-gnu 2>&1 | FileCheck --check-prefixes=CHECK,LINUX,LINUX_AIX %s
 // RUN: %clang_cc1 -std=c++11 -emit-llvm %s -o - -triple x86_64-apple-darwin12 | FileCheck --check-prefix=CHECK --check-prefix=DARWIN %s
+// RUN: %clang_cc1 -std=c++11 -emit-llvm %s -o - -triple powerpc64-unknown-aix-xcoff | FileCheck --check-prefixes=CHECK,AIX,LINUX_AIX %s
 
-// RUN: %clang_cc1 -std=c++11 -fno-use-cxa-atexit -emit-llvm %s -o - -triple x86_64-linux-gnu | FileCheck --check-prefix=CHECK --check-prefix=LINUX %s
-// RUN: %clang_cc1 -std=c++11 -fno-use-cxa-atexit -emit-llvm %s -O2 -disable-llvm-passes -o - -triple x86_64-linux-gnu | FileCheck --check-prefix=CHECK --check-prefix=LINUX --check-prefix=CHECK-OPT %s
+// RUN: %clang_cc1 -std=c++11 -fno-use-cxa-atexit -emit-llvm %s -o - -triple x86_64-linux-gnu | FileCheck --check-prefixes=CHECK,LINUX,LINUX_AIX %s
+// RUN: %clang_cc1 -std=c++11 -fno-use-cxa-atexit -emit-llvm %s -O2 -disable-llvm-passes -o - -triple x86_64-linux-gnu | FileCheck --check-prefixes=CHECK,LINUX,LINUX_AIX,CHECK-OPT %s
 // RUN: %clang_cc1 -std=c++11 -fno-use-cxa-atexit -femulated-tls -emit-llvm %s -o - \
-// RUN: -triple x86_64-linux-gnu 2>&1 | FileCheck --check-prefix=CHECK --check-prefix=LINUX %s
+// RUN: -triple x86_64-linux-gnu 2>&1 | FileCheck --check-prefixes=CHECK,LINUX,LINUX_AIX %s
 // RUN: %clang_cc1 -std=c++11 -fno-use-cxa-atexit -emit-llvm %s -o - -triple x86_64-apple-darwin12 | FileCheck --check-prefix=CHECK --check-prefix=DARWIN %s
 
 int f();
 int g();
 
-// LINUX-DAG: @a ={{.*}} thread_local global i32 0
+// LINUX_AIX-DAG: @a ={{.*}} thread_local global i32 0
 // DARWIN-DAG: @a = internal thread_local global i32 0
 thread_local int a = f();
 extern thread_local int b;
@@ -23,7 +24,7 @@
 static thread_local int d = g();
 
 struct U { static thread_local int m; };
-// LINUX-DAG: @_ZN1U1mE ={{.*}} thread_local global i32 0
+// LINUX_AIX-DAG: @_ZN1U1mE ={{.*}} thread_local global i32 0
 // DARWIN-DAG: @_ZN1U1mE = internal thread_local global i32 0
 thread_local int U::m = f();
 
@@ -89,9 +90,9 @@
 
 // CHECK-DAG: @llvm.global_ctors = appending global {{.*}} @[[GLOBAL_INIT:[^ ]*]]
 
-// LINUX-DAG: @_ZTH1a ={{.*}} alias void (), void ()* @__tls_init
+// LINUX_AIX-DAG: @_ZTH1a ={{.*}} alias void (), void ()* @__tls_init
 // DARWIN-DAG: @_ZTH1a = internal alias void (), void ()* @__tls_init
-// LINUX-DAG: @_ZTHN1U1mE ={{.*}} alias void (), void ()* @__tls_init
+// LINUX_AIX-DAG: @_ZTHN1U1mE ={{.*}} alias void (), void ()* @__tls_init
 // DARWIN-DAG: @_ZTHN1U1mE = internal alias void (), void ()* @__tls_init
 // CHECK-DAG: @_ZTHN1VIiE1mE = linkonce_odr alias void (), void ()* @[[V_M_INIT:[^, ]*]]
 // CHECK-DAG: @_ZTHN1XIiE1mE = linkonce_odr alias void (), void ()* @[[X_M_INIT:[^, ]*]]
@@ -106,16 +107,16 @@
 // Individual variable initialization functions:
 
 // CHECK: define {{.*}} @[[A_INIT:.*]]()
-// CHECK: call i32 @_Z1fv()
+// CHECK: call{{.*}} i32 @_Z1fv()
 // CHECK-NEXT: store i32 {{.*}}, i32* @a, align 4
 
 // CHECK-LABEL: define{{.*}} i32 @_Z1fv()
 int f() {
   // CHECK: %[[GUARD:.*]] = load i8, i8* @_ZGVZ1fvE1n, align 1
   // CHECK: %[[NEED_INIT:.*]] = icmp eq i8 %[[GUARD]], 0
-  // CHECK: br i1 %[[NEED_INIT]]
+  // CHECK: br i1 %[[NEED_INIT]]{{.*}}
 
-  // CHECK: %[[CALL:.*]] = call i32 @_Z1gv()
+  // CHECK: %[[CALL:.*]] = call{{.*}} i32 @_Z1gv()
   // CHECK: store i32 %[[CAL

[PATCH] D106070: [HIP] Remove workaround in __clang_hip_runtime_wrapper.h

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

Since this is not easily tested with lit tests, I added a test to 
llvm-test-suite: https://reviews.llvm.org/D106069

My understanding is that OpenMP no longer uses __clang_hip_runtime_wrapper.h, 
so we should be able to remove this workaround.


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

https://reviews.llvm.org/D106070

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

[clang] d40e809 - [PowerPC] Add PowerPC rotate related builtins and emit target independent code for XL compatibility

[Victor Huang via cfe-commits]

Author: Victor Huang
Date: 2021-07-15T10:23:54-05:00
New Revision: d40e8091bd1f48e8d3f64e4f99952f0139e9c27b

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

LOG: [PowerPC] Add PowerPC rotate related builtins and emit target independent 
code for XL compatibility

This patch is in a series of patches to provide builtins for compatibility
with the XL compiler. This patch adds the builtins and emit target independent
code for rotate related operations.

Reviewed By: nemanjai, #powerpc

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

Added: 
clang/test/CodeGen/builtins-ppc-xlcompat-rotate.c

Modified: 
clang/include/clang/Basic/BuiltinsPPC.def
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Sema/Sema.h
clang/lib/Basic/Targets/PPC.cpp
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/Sema/SemaChecking.cpp
clang/test/CodeGen/builtins-ppc-xlcompat-error.c

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsPPC.def 
b/clang/include/clang/Basic/BuiltinsPPC.def
index 09769b3f974eb..6bbd70c8368ec 100644
--- a/clang/include/clang/Basic/BuiltinsPPC.def
+++ b/clang/include/clang/Basic/BuiltinsPPC.def
@@ -83,6 +83,10 @@ BUILTIN(__builtin_ppc_mulhwu, "UiUiUi", "")
 BUILTIN(__builtin_ppc_maddhd, "LLiLLiLLiLLi", "")
 BUILTIN(__builtin_ppc_maddhdu, "ULLiULLiULLiULLi", "")
 BUILTIN(__builtin_ppc_maddld, "LLiLLiLLiLLi", "")
+// Rotate
+BUILTIN(__builtin_ppc_rlwnm, "UiUiIUiIUi", "")
+BUILTIN(__builtin_ppc_rlwimi, "UiUiUiIUiIUi", "")
+BUILTIN(__builtin_ppc_rldimi, "ULLiULLiULLiIUiIULLi", "")
 
 BUILTIN(__builtin_ppc_get_timebase, "ULLi", "n")
 

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index f4c189a3d178f..779093977da8f 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -9726,6 +9726,8 @@ def err_argument_not_shifted_byte : Error<
   "argument should be an 8-bit value shifted by a multiple of 8 bits">;
 def err_argument_not_shifted_byte_or_xxff : Error<
   "argument should be an 8-bit value shifted by a multiple of 8 bits, or in 
the form 0x??FF">;
+def err_argument_not_contiguous_bit_field : Error<
+  "argument %0 value should represent a contiguous bit field">;
 def err_rotation_argument_to_cadd
 : Error<"argument should be the value 90 or 270">;
 def err_rotation_argument_to_cmla

diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 3435834fbf5b3..8201e61fa63d8 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -12573,6 +12573,7 @@ class Sema final {
   bool SemaBuiltinComplex(CallExpr *TheCall);
   bool SemaBuiltinVSX(CallExpr *TheCall);
   bool SemaBuiltinOSLogFormat(CallExpr *TheCall);
+  bool SemaValueIsRunOfOnes(CallExpr *TheCall, unsigned ArgNum);
 
 public:
   // Used by C++ template instantiation.

diff  --git a/clang/lib/Basic/Targets/PPC.cpp b/clang/lib/Basic/Targets/PPC.cpp
index b79b30d7a4cdb..947e8c945c887 100644
--- a/clang/lib/Basic/Targets/PPC.cpp
+++ b/clang/lib/Basic/Targets/PPC.cpp
@@ -140,6 +140,9 @@ static void defineXLCompatMacros(MacroBuilder &Builder) {
   Builder.defineMacro("__maddhd", "__builtin_ppc_maddhd");
   Builder.defineMacro("__maddhdu", "__builtin_ppc_maddhdu");
   Builder.defineMacro("__maddld", "__builtin_ppc_maddld");
+  Builder.defineMacro("__rlwnm", "__builtin_ppc_rlwnm");
+  Builder.defineMacro("__rlwimi", "__builtin_ppc_rlwimi");
+  Builder.defineMacro("__rldimi", "__builtin_ppc_rldimi");
 }
 
 /// PPCTargetInfo::getTargetDefines - Return a set of the PowerPC-specific

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 2819931664ba4..67f57015e49fd 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -15172,6 +15172,31 @@ Value *CodeGenFunction::EmitPPCBuiltinExpr(unsigned 
BuiltinID,
 else
   return Builder.CreateSub(Ops[0], Ops[1], "vsubuqm");
   }
+  // Rotate and insert under mask operation.
+  // __rldimi(rs, is, shift, mask)
+  // (rotl64(rs, shift) & mask) | (is & ~mask)
+  // __rlwimi(rs, is, shift, mask)
+  // (rotl(rs, shift) & mask) | (is & ~mask)
+  case PPC::BI__builtin_ppc_rldimi:
+  case PPC::BI__builtin_ppc_rlwimi: {
+llvm::Type *Ty = Ops[0]->getType();
+Function *F = CGM.getIntrinsic(Intrinsic::fshl, Ty);
+if (BuiltinID == PPC::BI__builtin_ppc_rldimi)
+  Ops[2] = Builder.CreateZExt(Ops[2], Int64Ty);
+Value *Shift = Builder.CreateCall(F, {Ops[0], Ops[0], Ops[2]});
+Value *X = Builder.CreateAnd(Shift, Ops[3]);
+Value *Y = Builder.CreateAnd(Ops[1], Builder.CreateNot(Ops[3]));
+return Builder.CreateOr(X, Y);
+  }
+  // Rotate and insert under mask operation.
+  // __rlwn

[PATCH] D104744: [PowerPC] Add PowerPC rotate related builtins and emit target independent code for XL compatibility

[Victor Huang 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 rGd40e8091bd1f: [PowerPC] Add PowerPC rotate related builtins 
and emit target independent code… (authored by NeHuang).

Changed prior to commit:
  https://reviews.llvm.org/D104744?vs=358761&id=358986#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104744

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-rotate.c

Index: clang/test/CodeGen/builtins-ppc-xlcompat-rotate.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-rotate.c
@@ -0,0 +1,56 @@
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+
+extern unsigned int ui;
+extern unsigned long long ull;
+
+void test_builtin_ppc_rldimi() {
+  // CHECK-LABEL: test_builtin_ppc_rldimi
+  // CHECK:   %res = alloca i64, align 8
+  // CHECK-NEXT:  [[RA:%[0-9]+]] = load i64, i64* @ull, align 8
+  // CHECK-NEXT:  [[RB:%[0-9]+]] = load i64, i64* @ull, align 8
+  // CHECK-NEXT:  [[RC:%[0-9]+]] = call i64 @llvm.fshl.i64(i64 [[RA]], i64 [[RA]], i64 63)
+  // CHECK-NEXT:  [[RD:%[0-9]+]] = and i64 [[RC]], 72057593769492480
+  // CHECK-NEXT:  [[RE:%[0-9]+]] = and i64 [[RB]], -72057593769492481
+  // CHECK-NEXT:  [[RF:%[0-9]+]] = or i64 [[RD]], [[RE]]
+  // CHECK-NEXT:  store i64 [[RF]], i64* %res, align 8
+  // CHECK-NEXT:  ret void
+
+  /*shift = 63, mask = 0x00FFF000 = 72057593769492480, ~mask = 0xFF000FFF = -72057593769492481*/
+  unsigned long long res = __builtin_ppc_rldimi(ull, ull, 63, 0x00FFF000);
+}
+
+void test_builtin_ppc_rlwimi() {
+  // CHECK-LABEL: test_builtin_ppc_rlwimi
+  // CHECK:   %res = alloca i32, align 4
+  // CHECK-NEXT:  [[RA:%[0-9]+]] = load i32, i32* @ui, align 4
+  // CHECK-NEXT:  [[RB:%[0-9]+]] = load i32, i32* @ui, align 4
+  // CHECK-NEXT:  [[RC:%[0-9]+]] = call i32 @llvm.fshl.i32(i32 [[RA]], i32 [[RA]], i32 31)
+  // CHECK-NEXT:  [[RD:%[0-9]+]] = and i32 [[RC]], 16776960
+  // CHECK-NEXT:  [[RE:%[0-9]+]] = and i32 [[RB]], -16776961
+  // CHECK-NEXT:  [[RF:%[0-9]+]] = or i32 [[RD]], [[RE]]
+  // CHECK-NEXT:  store i32 [[RF]], i32* %res, align 4
+  // CHECK-NEXT:  ret void
+
+  /*shift = 31, mask = 0x00 = 16776960, ~mask = 0xFFFF = -16776961*/
+  unsigned int res = __builtin_ppc_rlwimi(ui, ui, 31, 0x00);
+}
+
+void test_builtin_ppc_rlwnm() {
+  // CHECK-LABEL: test_builtin_ppc_rlwnm
+  // CHECK:   %res = alloca i32, align 4
+  // CHECK-NEXT:  [[RA:%[0-9]+]] = load i32, i32* @ui, align 4
+  // CHECK-NEXT:  [[RB:%[0-9]+]] = call i32 @llvm.fshl.i32(i32 [[RA]], i32 [[RA]], i32 31)
+  // CHECK-NEXT:  [[RC:%[0-9]+]] = and i32 [[RB]], 511
+  // CHECK-NEXT:  store i32 [[RC]], i32* %res, align 4
+  // CHECK-NEXT:  ret void
+
+  /*shift = 31, mask = 0x1FF = 511*/
+  unsigned int res = __builtin_ppc_rlwnm(ui, 31, 0x1FF);
+}
Index: clang/test/CodeGen/builtins-ppc-xlcompat-error.c
===
--- clang/test/CodeGen/builtins-ppc-xlcompat-error.c
+++ clang/test/CodeGen/builtins-ppc-xlcompat-error.c
@@ -10,6 +10,8 @@
 
 extern long long lla, llb;
 extern int ia, ib;
+extern unsigned int ui;
+extern unsigned long long ull;
 
 void test_trap(void) {
 #ifdef __PPC64__
@@ -17,3 +19,27 @@
 #endif
   __tw(ia, ib, 50); //expected-error {{argument value 50 is outside the valid range [0, 31]}}
 }
+
+void test_builtin_ppc_rldimi() {
+  unsigned int shift;
+  unsigned long long mask;
+  unsigned long long res = __builtin_ppc_rldimi(ull, ull, shift, 7); // expected-error {{argument to '__builtin_ppc_rldimi' must be a constant integer}}
+  res = __builtin_ppc_rldimi(ull, ull, 63, mask);// expected-error {{argument to '__builtin_ppc_rldimi' must be a constant integer}}
+  res = __builtin_ppc_rldimi(ull, ull, 63, 0x0F00);  // expected-error {{argument 3 value should represent a contiguous bit field}}
+}
+
+void test_builtin_ppc_rlwimi() {
+  unsigned int shift;
+  unsigned int mask;
+  unsigned int res = __builtin_ppc_rlwimi(ui, ui, shift, 7); // expected-error {{argument to '__builtin_ppc_rlwimi' must be a constant integer}}
+  res = __bu

[PATCH] D105909: [clang][CallGraphSection] Add type id metadata to indirect call and targets

[Necip Fazil Yildiran via Phabricator via cfe-commits]

necipfazil added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:2068
+EmittedMDIdGeneralized = true;
+  }
+

morehouse wrote:
> This code also seems unnecessary as it puts metadata on function definitions.
We need the metadata for mapping indirect calls to receiver indirect targets 
with matching type id.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:2177
+  !CodeGenOpts.SanitizeCfiCanonicalJumpTables ||
+  CodeGenOpts.CallGraphSection)
 CreateFunctionTypeMetadataForIcall(FD, F);

morehouse wrote:
> Also seems unnecessary.
As described above, we need the metadata for indirect targets.



Comment at: clang/test/CodeGen/call-graph-section.c:20
+
+// CHECK-DAG: define {{(dso_local)?}} i32 @baz({{.*}} !type 
[[F_TPRIMITIVE:![0-9]+]]
+int baz(char a, float b, double c) {

morehouse wrote:
> Do we still expect type metadata on function definitions on the latest diff?
As described above, we need the metadata for indirect targets.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105909

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

[PATCH] D105909: [clang][CallGraphSection] Add type id metadata to indirect call and targets

[Necip Fazil Yildiran via Phabricator via cfe-commits]

necipfazil updated this revision to Diff 358996.
necipfazil added a comment.

- rebase
- add C struct parameter test
- add C++ tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105909

Files:
  clang/lib/CodeGen/CGClass.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprCXX.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/test/CodeGen/call-graph-section-1.cpp
  clang/test/CodeGen/call-graph-section-2.cpp
  clang/test/CodeGen/call-graph-section-3.cpp
  clang/test/CodeGen/call-graph-section.c

Index: clang/test/CodeGen/call-graph-section.c
===
--- /dev/null
+++ clang/test/CodeGen/call-graph-section.c
@@ -0,0 +1,87 @@
+// Tests that we assign appropriate identifiers to indirect calls and targets.
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -fcall-graph-section -S \
+// RUN: -emit-llvm -o - %s | FileCheck --check-prefixes=CHECK,ITANIUM %s
+
+// RUN: %clang_cc1 -triple x86_64-pc-windows-msvc -fcall-graph-section -S \
+// RUN: -emit-llvm -o - %s | FileCheck --check-prefixes=CHECK,MS %s
+
+// CHECK-DAG: define {{(dso_local)?}} void @foo({{.*}} !type [[F_TVOID:![0-9]+]]
+void foo() {
+}
+
+// CHECK-DAG: define {{(dso_local)?}} void @bar({{.*}} !type [[F_TVOID]]
+void bar() {
+  void (*fp)() = foo;
+  // CHECK: call {{.*}} !type [[CS_TVOID:![0-9]+]]
+  fp();
+}
+
+// CHECK-DAG: define {{(dso_local)?}} i32 @baz({{.*}} !type [[F_TPRIMITIVE:![0-9]+]]
+int baz(char a, float b, double c) {
+  return 1;
+}
+
+// CHECK-DAG: define {{(dso_local)?}} i32* @qux({{.*}} !type [[F_TPTR:![0-9]+]]
+int *qux(char *a, float *b, double *c) {
+  return 0;
+}
+
+// CHECK-DAG: define {{(dso_local)?}} void @corge({{.*}} !type [[F_TVOID]]
+void corge() {
+  int (*fp_baz)(char, float, double) = baz;
+  // CHECK: call i32 {{.*}}, !type [[CS_TPRIMITIVE:![0-9]+]]
+  fp_baz('a', .0f, .0);
+
+  int *(*fp_qux)(char *, float *, double *) = qux;
+  // CHECK: call i32* {{.*}}, !type [[CS_TPTR:![0-9]+]]
+  fp_qux(0, 0, 0);
+}
+
+struct st1 {
+  int *(*fp)(char *, float *, double *);
+};
+
+struct st2 {
+  struct st1 m;
+};
+
+// CHECK-DAG: define {{(dso_local)?}} void @stparam({{.*}} !type [[F_TSTRUCT:![0-9]+]]
+void stparam(struct st2 a, struct st2 *b) {}
+
+// CHECK-DAG: define {{(dso_local)?}} void @stf({{.*}} !type [[F_TVOID]]
+void stf() {
+  struct st1 St1;
+  St1.fp = qux;
+  // CHECK: call i32* {{.*}}, !type [[CS_TPTR]]
+  St1.fp(0, 0, 0);
+
+  struct st2 St2;
+  St2.m.fp = qux;
+  // CHECK: call i32* {{.*}}, !type [[CS_TPTR]]
+  St2.m.fp(0, 0, 0);
+
+  // CHECK: call void {{.*}} !type [[CS_TSTRUCT:![0-9]+]]
+  void (*fp_stparam)(struct st2, struct st2 *) = stparam;
+  fp_stparam(St2, &St2);
+}
+
+// ITANIUM-DAG: [[F_TVOID]] = !{i64 0, !"_ZTSFvE.generalized"}
+// ITANIUM-DAG: [[CS_TVOID]] = !{!"_ZTSFvE.generalized"}
+// MS-DAG: [[F_TVOID]] = !{i64 0, !"?6AX@Z.generalized"}
+// MS-DAG: [[CS_TVOID]] = !{!"?6AX@Z.generalized"}
+
+// ITANIUM-DAG: [[F_TPRIMITIVE]] = !{i64 0, !"_ZTSFicfdE.generalized"}
+// ITANIUM-DAG: [[CS_TPRIMITIVE]] = !{!"_ZTSFicfdE.generalized"}
+// MS-DAG: [[F_TPRIMITIVE]] = !{i64 0, !"?6AHDMN@Z.generalized"}
+// MS-DAG: [[CS_TPRIMITIVE]] = !{!"?6AHDMN@Z.generalized"}
+
+// ITANIUM-DAG: [[F_TPTR]] = !{i64 0, !"_ZTSFPvS_S_S_E.generalized"}
+// ITANIUM-DAG: [[CS_TPTR]] = !{!"_ZTSFPvS_S_S_E.generalized"}
+// MS-DAG: [[F_TPTR]] = !{i64 0, !"?6APEAXPEAX00@Z.generalized"}
+// MS-DAG: [[CS_TPTR]] = !{!"?6APEAXPEAX00@Z.generalized"}
+
+// ITANIUM-DAG: [[F_TSTRUCT]] = !{i64 0, !"_ZTSFv3st2PvE.generalized"}
+// MS-DAG: [[F_TSTRUCT]] = !{i64 0, !"?6AXUst2@@PEAX@Z.generalized"}
+// ITANIUM-DAG: [[CS_TSTRUCT]] = !{!"_ZTSFv3st2PvE.generalized"}
+// MS-DAG: [[CS_TSTRUCT]] = !{!"?6AXUst2@@PEAX@Z.generalized"}
\ No newline at end of file
Index: clang/test/CodeGen/call-graph-section-3.cpp
===
--- /dev/null
+++ clang/test/CodeGen/call-graph-section-3.cpp
@@ -0,0 +1,54 @@
+// Tests that we assign appropriate identifiers to indirect calls and targets
+// specifically for virtual methods.
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux -fcall-graph-section -S \
+// RUN: -emit-llvm -o %t %s
+// RUN: FileCheck --check-prefix=FT %s < %t
+// RUN: FileCheck --check-prefix=CST %s < %t
+
+
+// Class definitions (check for indirect target metadata)
+
+class Base {
+public:
+  // FT-DAG: define {{.*}} @_ZN4Base2vfEPc({{.*}} !type [[F_TVF:![0-9]+]]
+  virtual int vf(char *a) { return 0; };
+};
+
+class Derived : public Base {
+public:
+  // FT-DAG: define {{.*}} @_ZN7Derived2vfEPc({{.*}} !type [[F_TVF]]
+  int vf(char *a) override { return 1; };
+};
+
+// FT-DAG: [[F_TVF]] = !{i64 0, !"_ZTSFiPvE.generalized"}
+
+
+// Callsites (c

[PATCH] D105821: [analyzer] [WIP] Model destructor for std::unique_ptr

[Deep Majumder via Phabricator via cfe-commits]

RedDocMD updated this revision to Diff 358998.
RedDocMD added a comment.

Removed one bug, many more to go


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105821

Files:
  clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
  clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp


Index: clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -19,6 +19,7 @@
 #include "clang/StaticAnalyzer/Core/CheckerManager.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
+#include "llvm/Support/raw_ostream.h"
 
 using namespace clang;
 using namespace ento;
@@ -754,9 +755,10 @@
 
   ExplodedNodeSet DstInvalidated;
   StmtNodeBuilder Bldr(DstPreCall, DstInvalidated, *currBldrCtx);
-  for (ExplodedNodeSet::iterator I = DstPreCall.begin(), E = DstPreCall.end();
-   I != E; ++I)
-defaultEvalCall(Bldr, *I, *Call, CallOpts);
+  // for (ExplodedNodeSet::iterator I = DstPreCall.begin(), E = 
DstPreCall.end();
+  //  I != E; ++I)
+  //   defaultEvalCall(Bldr, *I, *Call, CallOpts);
+  getCheckerManager().runCheckersForEvalCall(DstInvalidated, DstPreCall, 
*Call, *this, CallOpts);
 
   getCheckerManager().runCheckersForPostCall(Dst, DstInvalidated,
  *Call, *this);
Index: clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
+++ clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
@@ -664,14 +664,13 @@
 for (const auto &EvalCallChecker : EvalCallCheckers) {
   // TODO: Support the situation when the call doesn't correspond
   // to any Expr.
-  ProgramPoint L = ProgramPoint::getProgramPoint(
-  Call.getOriginExpr(), ProgramPoint::PostStmtKind,
-  Pred->getLocationContext(), EvalCallChecker.Checker);
   bool evaluated = false;
   { // CheckerContext generates transitions(populates checkDest) on
 // destruction, so introduce the scope to make sure it gets properly
 // populated.
-CheckerContext C(B, Eng, Pred, L);
+CheckerContext C(B, Eng, Pred, Call.getProgramPoint());
+Call.getProgramPoint().dump();
+llvm::errs() << "\n";
 evaluated = EvalCallChecker(Call, C);
   }
   assert(!(evaluated && anyEvaluated)
Index: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
@@ -177,7 +177,9 @@
 
 bool SmartPtrModeling::evalCall(const CallEvent &Call,
 CheckerContext &C) const {
+
   ProgramStateRef State = C.getState();
+  Call.dump();
   if (!smartptr::isStdSmartPtrCall(Call))
 return false;
 
@@ -261,6 +263,11 @@
 return true;
   }
 
+  if (const auto *DC = dyn_cast(&Call)) {
+llvm::errs() << "Wohoo\n";
+return true;
+  }
+
   if (handleAssignOp(Call, C))
 return true;
 


Index: clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -19,6 +19,7 @@
 #include "clang/StaticAnalyzer/Core/CheckerManager.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
+#include "llvm/Support/raw_ostream.h"
 
 using namespace clang;
 using namespace ento;
@@ -754,9 +755,10 @@
 
   ExplodedNodeSet DstInvalidated;
   StmtNodeBuilder Bldr(DstPreCall, DstInvalidated, *currBldrCtx);
-  for (ExplodedNodeSet::iterator I = DstPreCall.begin(), E = DstPreCall.end();
-   I != E; ++I)
-defaultEvalCall(Bldr, *I, *Call, CallOpts);
+  // for (ExplodedNodeSet::iterator I = DstPreCall.begin(), E = DstPreCall.end();
+  //  I != E; ++I)
+  //   defaultEvalCall(Bldr, *I, *Call, CallOpts);
+  getCheckerManager().runCheckersForEvalCall(DstInvalidated, DstPreCall, *Call, *this, CallOpts);
 
   getCheckerManager().runCheckersForPostCall(Dst, DstInvalidated,
  *Call, *this);
Index: clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
+++ clang/lib/StaticAnalyzer/Core/CheckerManager.cpp
@@ -664,14 +664,13 @@
 for (const auto &EvalCallChecker : EvalCallCheckers) {
   // TODO: Support the situation when the call doesn't correspond
   // to any Expr.
-  ProgramPoint L = P

[PATCH] D106074: [AIX] Emit unsupported 128-bit long double option for AIX

[Anjan Kumar via Phabricator via cfe-commits]

anjankgk created this revision.
anjankgk added reviewers: daltenty, Whitney, hubert.reinterpretcast.
anjankgk requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

AIX currently doesn't support the 128-bit long double.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106074

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/unsupported-option.c


Index: clang/test/Driver/unsupported-option.c
===
--- clang/test/Driver/unsupported-option.c
+++ clang/test/Driver/unsupported-option.c
@@ -21,3 +21,11 @@
 // RUN: not %clang -fprofile-generate -flto=thin --target=powerpc64-ibm-aix %s 
2>&1 | \
 // RUN: FileCheck %s --check-prefix=AIX-PROFILE-THINLTO
 // AIX-PROFILE-THINLTO: error: invalid argument '-fprofile-generate' only 
allowed with '-flto'
+
+// RUN: not %clang --target=powerpc-ibm-aix %s -mlong-double-128 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-LONGDOUBLE128-ERR
+// AIX-LONGDOUBLE128-ERR: error: unsupported option '-mlong-double-128' for 
target 'powerpc-ibm-aix'
+
+// RUN: not %clang --target=powerpc64-ibm-aix %s -mlong-double-128 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX64-LONGDOUBLE128-ERR
+// AIX64-LONGDOUBLE128-ERR: error: unsupported option '-mlong-double-128' for 
target 'powerpc64-ibm-aix'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4841,6 +4841,13 @@
   CmdArgs.push_back("-mabi=vec-default");
   }
 
+  if (Arg *A = Args.getLastArg(options::OPT_mlong_double_128)) {
+// AIX doesn't support 128-bit long double yet.
+if (Triple.isOSAIX())
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << A->getSpelling() << RawTriple.str();
+  }
+
   if (Arg *A = Args.getLastArg(options::OPT_Wframe_larger_than_EQ)) {
 StringRef v = A->getValue();
 // FIXME: Validate the argument here so we don't produce meaningless errors


Index: clang/test/Driver/unsupported-option.c
===
--- clang/test/Driver/unsupported-option.c
+++ clang/test/Driver/unsupported-option.c
@@ -21,3 +21,11 @@
 // RUN: not %clang -fprofile-generate -flto=thin --target=powerpc64-ibm-aix %s 2>&1 | \
 // RUN: FileCheck %s --check-prefix=AIX-PROFILE-THINLTO
 // AIX-PROFILE-THINLTO: error: invalid argument '-fprofile-generate' only allowed with '-flto'
+
+// RUN: not %clang --target=powerpc-ibm-aix %s -mlong-double-128 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX-LONGDOUBLE128-ERR
+// AIX-LONGDOUBLE128-ERR: error: unsupported option '-mlong-double-128' for target 'powerpc-ibm-aix'
+
+// RUN: not %clang --target=powerpc64-ibm-aix %s -mlong-double-128 2>&1 | \
+// RUN: FileCheck %s --check-prefix=AIX64-LONGDOUBLE128-ERR
+// AIX64-LONGDOUBLE128-ERR: error: unsupported option '-mlong-double-128' for target 'powerpc64-ibm-aix'
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4841,6 +4841,13 @@
   CmdArgs.push_back("-mabi=vec-default");
   }
 
+  if (Arg *A = Args.getLastArg(options::OPT_mlong_double_128)) {
+// AIX doesn't support 128-bit long double yet.
+if (Triple.isOSAIX())
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << A->getSpelling() << RawTriple.str();
+  }
+
   if (Arg *A = Args.getLastArg(options::OPT_Wframe_larger_than_EQ)) {
 StringRef v = A->getValue();
 // FIXME: Validate the argument here so we don't produce meaningless errors
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D105904: [clangd] Support `#pragma mark` in the outline

[David Goldman via Phabricator via cfe-commits]

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

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105904

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/FindSymbols.cpp
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/ParsedAST.h
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/TextMarks.cpp
  clang-tools-extra/clangd/TextMarks.h
  clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
  clang/include/clang/Lex/PPCallbacks.h

Index: clang/include/clang/Lex/PPCallbacks.h
===
--- clang/include/clang/Lex/PPCallbacks.h
+++ clang/include/clang/Lex/PPCallbacks.h
@@ -492,6 +492,11 @@
 Second->PragmaComment(Loc, Kind, Str);
   }
 
+  void PragmaMark(SourceLocation Loc, StringRef Trivia) override {
+First->PragmaMark(Loc, Trivia);
+Second->PragmaMark(Loc, Trivia);
+  }
+
   void PragmaDetectMismatch(SourceLocation Loc, StringRef Name,
 StringRef Value) override {
 First->PragmaDetectMismatch(Loc, Name, Value);
Index: clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
+++ clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp
@@ -1027,6 +1027,106 @@
 AllOf(WithName("-pur"), WithKind(SymbolKind::Method));
 }
 
+TEST(DocumentSymbolsTest, PragmaMarkGroups) {
+  TestTU TU;
+  TU.ExtraArgs = {"-xobjective-c++", "-Wno-objc-root-class"};
+  Annotations Main(R"cpp(
+  $DogDef[[@interface Dog
+  @end]]
+
+  $DogImpl[[@implementation Dog
+
+  + (id)sharedDoggo { return 0; }
+
+  #pragma $Overrides[[mark - Overrides
+
+  - (id)init {
+return self;
+  }
+  - (void)bark {}]]
+
+  #pragma $Specifics[[mark - Dog Specifics
+
+  - (int)isAGoodBoy {
+return 1;
+  }]]
+  @]]end  // FIXME: Why doesn't this include the 'end'?
+
+  #pragma $End[[mark - End
+]]
+)cpp");
+  TU.Code = Main.code().str();
+  EXPECT_THAT(
+  getSymbols(TU.build()),
+  ElementsAre(
+  AllOf(WithName("Dog"), SymRange(Main.range("DogDef"))),
+  AllOf(WithName("Dog"), SymRange(Main.range("DogImpl")),
+Children(AllOf(WithName("+sharedDoggo"),
+   WithKind(SymbolKind::Method)),
+ AllOf(WithName("Overrides"),
+   SymRange(Main.range("Overrides")),
+   Children(AllOf(WithName("-init"),
+  WithKind(SymbolKind::Method)),
+AllOf(WithName("-bark"),
+  WithKind(SymbolKind::Method,
+ AllOf(WithName("Dog Specifics"),
+   SymRange(Main.range("Specifics")),
+   Children(AllOf(WithName("-isAGoodBoy"),
+  WithKind(SymbolKind::Method)),
+  AllOf(WithName("End"), SymRange(Main.range("End");
+}
+
+TEST(DocumentSymbolsTest, PragmaMarkGroupsNoNesting) {
+  TestTU TU;
+  TU.ExtraArgs = {"-xobjective-c++", "-Wno-objc-root-class"};
+  Annotations Main(R"cpp(
+  // FIXME: We miss the mark below, is it in the preamble instead?
+  // Unclear if it's worth supporting, likely very uncommon.
+  #pragma mark Helpers
+  void helpA(id obj) {}
+
+  #pragma mark -
+  #pragma mark Core
+
+  void coreMethod() {}
+)cpp");
+  TU.Code = Main.code().str();
+  EXPECT_THAT(
+  getSymbols(TU.build()),
+  ElementsAre(AllOf(WithName("helpA")), AllOf(WithName("(unnamed group)")),
+  AllOf(WithName("Core")), AllOf(WithName("coreMethod";
+}
+
+TEST(DocumentSymbolsTest, SymbolsAreSorted) {
+  TestTU TU;
+  TU.ExtraArgs = {"-xobjective-c++", "-Wno-objc-root-class"};
+  Annotations Main(R"cpp(
+  @interface MYObject
+  @end
+
+  void someFunctionAbove() {}
+
+  @implementation MYObject
+  - (id)init { return self; }
+
+  void someHelperFunction() {}
+
+  - (void)retain {}
+  - (void)release {}
+  @end
+)cpp");
+  TU.Code = Main.code().str();
+  EXPECT_THAT(getSymbols(TU.build()),
+  ElementsAre(AllOf(WithName("MYObject")),
+  AllOf(WithName("someFunctionAbove")),
+  // FIXME: This should be nested under MYObject below.
+  AllOf(WithName("someHelperFunction")),
+  AllOf(WithName("MYObject"),
+Children(AllOf(WithName("-init")),
+ AllOf(WithName("-retain")),
+ AllOf(WithName("-rele

[PATCH] D106044: [RISCV] Update to vlm.v and vsm.v according to v1.0-rc1.

[Craig Topper via Phabricator via cfe-commits]

craig.topper added inline comments.



Comment at: clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vse.c:1182
+void test_vsm_v_b1(uint8_t *base, vbool1_t value, size_t vl) {
   return vse1(base, value, vl);
 }

Was the call supposed to be renamed or just the test name?



Comment at: clang/test/CodeGen/RISCV/rvv-intrinsics/vle.c:1258
 //
 vbool64_t test_vle1_v_b64(const uint8_t *base, size_t vl) {
   return vle1_v_b64(base, vl);

Did you mean to leave the old test name? I don't see the same in the vse.c file


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106044

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

[PATCH] D103096: [analyzer] Implement cast for ranges of symbolic integers.

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov updated this revision to Diff 359007.
ASDenysPetrov edited the summary of this revision.
ASDenysPetrov added a comment.

Improved `ignoreCasts` implementation. Adapted to `ConstraintAssignor`.


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

https://reviews.llvm.org/D103096

Files:
  clang/include/clang/StaticAnalyzer/Checkers/SValExplainer.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/SymExpr.h
  clang/lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
  clang/lib/StaticAnalyzer/Core/SymbolManager.cpp
  clang/test/Analysis/symbol-integral-cast.cpp

Index: clang/test/Analysis/symbol-integral-cast.cpp
===
--- /dev/null
+++ clang/test/Analysis/symbol-integral-cast.cpp
@@ -0,0 +1,361 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=debug.ExprInspection -analyzer-config eagerly-assume=false -analyzer-config support-symbolic-integer-casts=true -verify %s
+
+template 
+void clang_analyzer_eval(T);
+void clang_analyzer_warnIfReached();
+
+typedef short int16_t;
+typedef int int32_t;
+typedef unsigned short uint16_t;
+typedef unsigned int uint32_t;
+
+void test1(int x) {
+  // Even if two lower bytes of `x` equal to zero, it doesn't mean that
+  // the entire `x` is zero. We are not able to know the exact value of x.
+  // It can be one of  65536 possible values like [0, 65536, 131072, ...]
+  // and so on. To avoid huge range sets we still assume `x` in the range
+  // [INT_MIN, INT_MAX].
+  if (!(short)x) {
+if (!x)
+  clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
+else
+  clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
+  }
+}
+
+void test2(int x) {
+  // If two lower bytes of `x` equal to zero, and we know x to be 65537,
+  // which is not truncated to short as zero. Thus the branch is infisible.
+  short s = x;
+  if (!s) {
+if (x == 65537)
+  clang_analyzer_warnIfReached(); // no-warning
+else
+  clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
+  }
+}
+
+void test3(int x, short s) {
+  s = x;
+  if ((short)x > -10 && s < 10) {
+if (x > 0 && x < 10) {
+  // If the range of the whole variable was constrained then reason again
+  // about truncated bytes to make the ranges more precise.
+  clang_analyzer_eval((short)x <= 0); // expected-warning {{FALSE}}
+}
+  }
+}
+
+void test4(unsigned x) {
+  if ((char)x > 8) {
+// Constraint the range of the lowest byte of `x` to [9, CHAR_MAX].
+// The original range of `x` still remains [0, UINT_MAX].
+clang_analyzer_eval((char)x < 42); // expected-warning {{UNKNOWN}}
+if (x < 42) {
+  // Constraint the original range to [0, 42] and update (re-constraint)
+  // the range of the lowest byte of 'x' to [9, 42].
+  clang_analyzer_eval((char)x < 42); // expected-warning {{TRUE}}
+}
+  }
+}
+
+void test5(unsigned x) {
+  if ((char)x > -10 && (char)x < 10) {
+if ((short)x == 8) {
+  // If the range of higher bytes(short) was constrained then reason again
+  // about smaller truncated ranges(char) to make it more precise.
+  clang_analyzer_eval((char)x == 8);  // expected-warning {{TRUE}}
+  clang_analyzer_eval((short)x == 8); // expected-warning {{TRUE}}
+  // We still assume full version of `x` in the range [INT_MIN, INT_MAX].
+  clang_analyzer_eval(x == 8); // expected-warning {{UNKNOWN}}
+}
+  }
+}
+
+void test6(int x) {
+  // Even if two lower bytes of `x` less than zero, it doesn't mean that `x`
+  // can't be greater than zero. Thence we don't change the native range of
+  // `x` and this branch is feasible.
+  if (x > 0)
+if ((short)x < 0)
+  clang_analyzer_eval(x > 0); // expected-warning {{TRUE}}
+}
+
+void test7(int x) {
+  // The range of two lower bytes of `x` [1, SHORT_MAX] is enough to cover
+  // all possible values of char [CHAR_MIN, CHAR_MAX]. So the lowest byte
+  // can be lower than zero.
+  if ((short)x > 0) {
+if ((char)x < 0)
+  clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
+else
+  clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
+  }
+}
+
+void test8(int x) {
+  // Promotion from `signed int` to `signed long long` also reasoning about the
+  // original range, because we know the fact that even after promotion it
+  // remains in the range [INT_MIN, INT_MAX].
+  if ((long long)x < 0)
+clang_analyzer_eval(x < 0); // expected-warning {{TRUE}}
+}
+
+void test9(signed int x) {
+  // Any cast `signed` to `unsigned` produces an unsigned range, which is
+  // [0, UNSIGNED_MAX] and can not be lower than zero.
+  if ((unsigned long long)x < 0)
+clang_analyzer_warnIfReached(); // no-warning
+  else
+clang_analyzer_warnIfReached(); // expected-warning {{REACHABLE}}
+
+  if ((unsigned int)x < 0)
+clan

[PATCH] D105907: [CallGraphSection] Add call graph section options and documentation

[Necip Fazil Yildiran via Phabricator via cfe-commits]

necipfazil updated this revision to Diff 359010.
necipfazil marked 2 inline comments as done.
necipfazil added a comment.

- test new clang flags
- rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105907

Files:
  clang/docs/CallGraphSection.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/clang_f_opts.c
  llvm/include/llvm/CodeGen/CommandFlags.h
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/CommandFlags.cpp

Index: llvm/lib/CodeGen/CommandFlags.cpp
===
--- llvm/lib/CodeGen/CommandFlags.cpp
+++ llvm/lib/CodeGen/CommandFlags.cpp
@@ -86,6 +86,7 @@
 CGOPT(DebuggerKind, DebuggerTuningOpt)
 CGOPT(bool, EnableStackSizeSection)
 CGOPT(bool, EnableAddrsig)
+CGOPT(bool, EnableCallGraphSection)
 CGOPT(bool, EmitCallSiteInfo)
 CGOPT(bool, EnableMachineFunctionSplitter)
 CGOPT(bool, EnableDebugEntryValues)
@@ -407,6 +408,11 @@
   cl::init(false));
   CGBINDOPT(EnableAddrsig);
 
+  static cl::opt EnableCallGraphSection(
+  "call-graph-section", cl::desc("Emit a call graph section"),
+  cl::init(false));
+  CGBINDOPT(EnableCallGraphSection);
+
   static cl::opt EmitCallSiteInfo(
   "emit-call-site-info",
   cl::desc(
@@ -520,6 +526,7 @@
   Options.EmitStackSizeSection = getEnableStackSizeSection();
   Options.EnableMachineFunctionSplitter = getEnableMachineFunctionSplitter();
   Options.EmitAddrsig = getEnableAddrsig();
+  Options.EmitCallGraphSection = getEnableCallGraphSection();
   Options.EmitCallSiteInfo = getEmitCallSiteInfo();
   Options.EnableDebugEntryValues = getEnableDebugEntryValues();
   Options.PseudoProbeForProfiling = getPseudoProbeForProfiling();
Index: llvm/include/llvm/Target/TargetOptions.h
===
--- llvm/include/llvm/Target/TargetOptions.h
+++ llvm/include/llvm/Target/TargetOptions.h
@@ -127,11 +127,11 @@
   EmulatedTLS(false), ExplicitEmulatedTLS(false), EnableIPRA(false),
   EmitStackSizeSection(false), EnableMachineOutliner(false),
   EnableMachineFunctionSplitter(false), SupportsDefaultOutlining(false),
-  EmitAddrsig(false), EmitCallSiteInfo(false),
-  SupportsDebugEntryValues(false), EnableDebugEntryValues(false),
-  PseudoProbeForProfiling(false), ValueTrackingVariableLocations(false),
-  ForceDwarfFrameSection(false), XRayOmitFunctionIndex(false),
-  DebugStrictDwarf(false),
+  EmitAddrsig(false), EmitCallGraphSection(false),
+  EmitCallSiteInfo(false), SupportsDebugEntryValues(false),
+  EnableDebugEntryValues(false), PseudoProbeForProfiling(false),
+  ValueTrackingVariableLocations(false), ForceDwarfFrameSection(false),
+  XRayOmitFunctionIndex(false), DebugStrictDwarf(false),
   FPDenormalMode(DenormalMode::IEEE, DenormalMode::IEEE) {}
 
 /// DisableFramePointerElim - This returns true if frame pointer elimination
@@ -290,6 +290,9 @@
 /// to selectively generate basic block sections.
 std::shared_ptr BBSectionsFuncListBuf;
 
+/// Emit section containing call graph metadata.
+unsigned EmitCallGraphSection : 1;
+
 /// The flag enables call site info production. It is used only for debug
 /// info, and it is restricted only to optimized code. This can be used for
 /// something else, so that should be controlled in the frontend.
Index: llvm/include/llvm/CodeGen/CommandFlags.h
===
--- llvm/include/llvm/CodeGen/CommandFlags.h
+++ llvm/include/llvm/CodeGen/CommandFlags.h
@@ -122,6 +122,8 @@
 
 bool getEnableAddrsig();
 
+bool getEnableCallGraphSection();
+
 bool getEmitCallSiteInfo();
 
 bool getEnableMachineFunctionSplitter();
Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -231,6 +231,7 @@
 // RUN: -falign-functions -falign-functions=2 -fno-align-functions\
 // RUN: -fasynchronous-unwind-tables -fno-asynchronous-unwind-tables  \
 // RUN: -fbuiltin -fno-builtin\
+// RUN: -fcall-graph-section -fno-call-graph-section  \
 // RUN: -fdiagnostics-show-location=once  \
 // RUN: -ffloat-store -fno-float-store\
 // RUN: -feliminate-unused-debug-types -fno-eliminate-unused-debug-types  \
@@ -596,3 +597,9 @@
 // RUN: %clang -### -xobjective-c %s 2>&1 | FileCheck -check-prefix=CHECK_NO_DISABLE_DIRECT %s
 // CHECK_DISABLE_DIRECT: -fobjc-disable-direct-methods-for-testing
 // CHECK_NO_DISABLE_DIRECT-NOT: -fobjc-disa

[PATCH] D103096: [analyzer] Implement cast for ranges of symbolic integers.

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1908-1912
+// Handle SymbolCast before actual assignment.
+std::tie(Sym, NewConstraint) =
+modifySymbolAndConstraints(Sym, NewConstraint);
+if (!State)
+  return nullptr;

That's not using `ConstraintAssignor`, you simply put your implementation in 
here.  That won't do!


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

https://reviews.llvm.org/D103096

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

[PATCH] D105904: [clangd] Support `#pragma mark` in the outline

[David Goldman via Phabricator via cfe-commits]

dgoldman added a comment.

In D105904#2879445 , @kadircet wrote:

> In D105904#2877281 , @dgoldman 
> wrote:
>
>> Yep, I can you send you some searches internally with how prevalent they are.
>
> Thanks!
>
>> I don't think this an Xcode limitation really - more of an LSP spec 
>> limitation. If we create a group inside of another symbol, we are 
>> effectively contained in it and cannot escape without violating the spec, 
>> right? To be clear, Xcode rules are a bit different - see the link above - 
>> the `#pragma mark -` just creates a divider which we can't mirror.
>
> Sorry I don't follow what you mean here. I was talking about inability to 
> have something like:
>
>   #pragma mark -Foo
> #pragma mark -Bar
> #pragma mark SPECIAL_BAR_END
>   #pragma mark SPECIAL_FOO_END
>
> By making sure groups are terminated **explicitly** we gain the ability to 
> nest them, whereas otherwise `-Bar` above will always terminate the previous 
> group implicitly.

Ah I see what you mean. Xcode has implicit termination - the #pragma mark - Foo 
just makes a horizontal line and labels Foo after, so a subsequent #pragma mark 
- Bar ends up creating a new line, ending the previous. There's too much 
relying on this behavior for us to change it. My point was we can't avoid an 
implicit end here of the Foo mark due to how we nest things, so either way we'd 
have some form of implicit termination:

  @interface Foo
  #pragma mark - Foo
  @end



In D105904#2879750 , @sammccall wrote:

> However those difficulties don't apply here - I believe you can take the 
> current final representation (`vector`) + the list of marks 
> and produce a markified `vector` via a fairly natural tree 
> walk. And this does a *really* good job of isolating this feature - we 
> literally run the rest of the algorithm without it.
> (This is slightly different to what's done in the patch, I would actually 
> take it out of the `DocumentOutline` class entirely).
> I don't think this hurts efficiency much (I think/hope this ends up being a 
> move rather than a copy for most nodes). And I think it actually makes the 
> markifying code easier to reason about in this case, as it just deals with 
> line numbers/positions, without having the distraction of SourceLocation.

That seems reasonable, it seems quite similar to this, we can probably simplify 
it if we remove the requirement that the children are in order. Note that my 
current approach doesn't really add much overhead if the absence of the 
TextMarks, but we should be able to special case that there as well.




Comment at: clang-tools-extra/clangd/TextMarks.h:22
+/// Represents a programmer specified mark/note, typically used to easily 
locate
+/// or differentiate code. e.g. a `pragma mark`, a `TODO`.
+///

sammccall wrote:
> This seems like premature abstraction - you don't handle TODOs here, nor are 
> they appropriate for the single use case we have. Moreover they don't satisfy 
> the definition here: `int foo; // TODO: turn into a float` the TODO doesn't 
> occupy the whole line.
> 
> If we need it, the appropriate generalization seems just as likely to be 
> "pragmas" or "directives" as "textual marks".
> 
> Similarly, it's not clear that the logic around interpreting the strings e.g. 
> as groups needs to be shared across features, nor is it terribly complicated.
> So the interface here seems like it could be much simpler:
> ```
> struct PragmaMark {
>   unsigned Line;
>   string Text;
> }
> unique_ptr collectPragmaMarksCallback(const SourceManager&, 
> vector &Out);
> ```
> 
> I'd suggest putting this in CollectMacros.h (which would be misnamed but not 
> terribly, or we could always rename) rather than adding a new header.
We don't handle them at the moment, but Xcode does (for both Swift + ObjC): 
https://medium.com/@cboynton/todo-make-your-notes-on-xcode-stand-out-5f5124ec064c.
 You're right that they don't necessarily have to occupy the whole line though, 
it's possible to have multiple per line although I'm not sure how often that is 
used in practice.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105904

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

[PATCH] D106070: [HIP] Remove workaround in __clang_hip_runtime_wrapper.h

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

OK from the openmp gpu side as far as I can tell. This is probably another 
instance of where we really wanted _OPENMP_TARGET or similar.


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

https://reviews.llvm.org/D106070

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

[PATCH] D103096: [analyzer] Implement cast for ranges of symbolic integers.

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1908-1912
+// Handle SymbolCast before actual assignment.
+std::tie(Sym, NewConstraint) =
+modifySymbolAndConstraints(Sym, NewConstraint);
+if (!State)
+  return nullptr;

vsavchenko wrote:
> That's not using `ConstraintAssignor`, you simply put your implementation in 
> here.  That won't do!
OK, please tell me how to use it correctly in my case.


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

https://reviews.llvm.org/D103096

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

[PATCH] D106070: [HIP] Remove workaround in __clang_hip_runtime_wrapper.h

[Aaron Enye Shi via Phabricator via cfe-commits]

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

LGTM!


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

https://reviews.llvm.org/D106070

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

[PATCH] D103096: [analyzer] Implement cast for ranges of symbolic integers.

[Valeriy Savchenko via Phabricator via cfe-commits]

vsavchenko added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1908-1912
+// Handle SymbolCast before actual assignment.
+std::tie(Sym, NewConstraint) =
+modifySymbolAndConstraints(Sym, NewConstraint);
+if (!State)
+  return nullptr;

ASDenysPetrov wrote:
> vsavchenko wrote:
> > That's not using `ConstraintAssignor`, you simply put your implementation 
> > in here.  That won't do!
> OK, please tell me how to use it correctly in my case.
Can you read the comments first and then ask me if you have any specific 
questions?


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

https://reviews.llvm.org/D103096

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

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

[Harald van Dijk via Phabricator via cfe-commits]

hvdijk updated this revision to Diff 359016.
hvdijk edited the summary of this revision.
hvdijk added a reviewer: MaskRay.
hvdijk added a comment.

Updated to use `Triple.isX32()`.

Should we perhaps just merge this as is, ahead of the update to compiler-rt to 
create x32 objects? For non-x32, this change is NFC, for x32, the change 
results in a better error message about compiler-rt objects not existing rather 
than being for the wrong architecture.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100148

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/test/Driver/sanitizer-ld.c


Index: clang/test/Driver/sanitizer-ld.c
===
--- clang/test/Driver/sanitizer-ld.c
+++ clang/test/Driver/sanitizer-ld.c
@@ -284,28 +284,28 @@
 // CHECK-MSAN-NO-LINK-RUNTIME-LINUX-NOT: libclang_rt.msan
 
 // RUN: %clang -fsanitize=undefined %s -### -o %t.o 2>&1 \
-// RUN: -target i386-unknown-linux -fuse-ld=ld \
+// RUN: -target x86_64-unknown-linux-gnux32 -fuse-ld=ld \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
-// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-LINUX %s
 
 // RUN: %clang -fsanitize=float-divide-by-zero %s -### -o %t.o 2>&1 \
-// RUN: -target i386-unknown-linux -fuse-ld=ld \
+// RUN: -target x86_64-unknown-linux-gnux32 -fuse-ld=ld \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
-// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-LINUX %s
 
 // RUN: %clang -fsanitize=undefined %s -### -o %t.o 2>&1 \
-// RUN: -target i386-unknown-linux -fuse-ld=ld \
+// RUN: -target x86_64-unknown-linux-gnux32 -fuse-ld=ld \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
-// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
 // RUN: -static-libsan \
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-LINUX %s
 
 // CHECK-UBSAN-LINUX: "{{.*}}ld{{(.exe)?}}"
 // CHECK-UBSAN-LINUX-NOT: libclang_rt.asan
 // CHECK-UBSAN-LINUX-NOT: libclang_rt.ubsan_standalone_cxx
-// CHECK-UBSAN-LINUX: "--whole-archive" 
"{{.*}}libclang_rt.ubsan_standalone-i386.a" "--no-whole-archive"
+// CHECK-UBSAN-LINUX: "--whole-archive" 
"{{.*}}libclang_rt.ubsan_standalone-x32.a" "--no-whole-archive"
 // CHECK-UBSAN-LINUX-NOT: libclang_rt.asan
 // CHECK-UBSAN-LINUX-NOT: libclang_rt.ubsan_standalone_cxx
 // CHECK-UBSAN-LINUX-NOT: "-lstdc++"
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -383,6 +383,9 @@
   if (TC.getArch() == llvm::Triple::x86 && Triple.isAndroid())
 return "i686";
 
+  if (TC.getArch() == llvm::Triple::x86_64 && Triple.isX32())
+return "x32";
+
   return llvm::Triple::getArchTypeName(TC.getArch());
 }
 


Index: clang/test/Driver/sanitizer-ld.c
===
--- clang/test/Driver/sanitizer-ld.c
+++ clang/test/Driver/sanitizer-ld.c
@@ -284,28 +284,28 @@
 // CHECK-MSAN-NO-LINK-RUNTIME-LINUX-NOT: libclang_rt.msan
 
 // RUN: %clang -fsanitize=undefined %s -### -o %t.o 2>&1 \
-// RUN: -target i386-unknown-linux -fuse-ld=ld \
+// RUN: -target x86_64-unknown-linux-gnux32 -fuse-ld=ld \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
-// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-LINUX %s
 
 // RUN: %clang -fsanitize=float-divide-by-zero %s -### -o %t.o 2>&1 \
-// RUN: -target i386-unknown-linux -fuse-ld=ld \
+// RUN: -target x86_64-unknown-linux-gnux32 -fuse-ld=ld \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
-// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-LINUX %s
 
 // RUN: %clang -fsanitize=undefined %s -### -o %t.o 2>&1 \
-// RUN: -target i386-unknown-linux -fuse-ld=ld \
+// RUN: -target x86_64-unknown-linux-gnux32 -fuse-ld=ld \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
-// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
 // RUN: -static-libsan \
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-LINUX %s
 
 // CHECK-UBSAN-LINUX: "{{.*}}ld{{(.exe)?}}"
 // CHECK-UBSAN-LINUX-NOT: libclang_rt.asan
 // CHECK-UBSAN-LINUX-NOT: libclang_rt.ubsan_standalone_cxx
-// CHECK-UBSAN-LINUX: "--whole-archive" "{{.*}}libclang_rt.ubsan_standalone-i386.a" "--no-whole-archive"
+// CHECK-UBSAN-LINUX: "--whole-archive" "{{.*}}libclang_rt.ubsan_standalone-x32.a" "--no-whole-archive"
 /

[PATCH] D106069: [HIP] Add test with_fopenmp.hip

[Aaron Enye Shi via Phabricator via cfe-commits]

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

LGTM!


Repository:
  rT test-suite

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

https://reviews.llvm.org/D106069

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

[PATCH] D100148: [Driver] Fix compiler-rt lookup for x32

[John Paul Adrian Glaubitz via Phabricator via cfe-commits]

glaubitz added a comment.

In D100148#2880499 , @hvdijk wrote:

> Updated to use `Triple.isX32()`.
>
> Should we perhaps just merge this as is, ahead of the update to compiler-rt 
> to create x32 objects? For non-x32, this change is NFC, for x32, the change 
> results in a better error message about compiler-rt objects not existing 
> rather than being for the wrong architecture.

Yes, I fully agree on this stance. I've been waiting for this patch for Debian, 
plus the remaining changes to get Rust to build on x32 ;-).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100148

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

[PATCH] D105951: [clang] P2266 implicit moves STL workaround

[Melanie Blower via Phabricator via cfe-commits]

mibintc added a comment.

Intel compiles VS2019 #include files regularly with clang, and the file 
 compiled with -std:c++latest encounters this error report, which 
@aaron.ballman suggests is related to this effort.

  In file included from tst_incl_filesystem.cpp:2:
  c:/Program files (x86)/Microsoft Visual 
Studio/2019/Professional/VC/Tools/MSVC/14.28.29910/include\filesystem(3099,20): 
error: call to deleted constructor of 'unique_ptr'
  return _Cleaned_link;
 ^
  c:/Program files (x86)/Microsoft Visual 
Studio/2019/Professional/VC/Tools/MSVC/14.28.29910/include\memory(3566,5): 
note: 'unique_ptr' has been explicitly marked deleted here
  unique_ptr(const unique_ptr&) = delete;
  ^
  In file included from tst_incl_filesystem.cpp:2:
  c:/Program files (x86)/Microsoft Visual 
Studio/2019/Professional/VC/Tools/MSVC/14.28.29910/include\filesystem(3125,16): 
error: call to deleted constructor of 'unique_ptr'
  return _Cleaned_link;
 ^
  c:/Program files (x86)/Microsoft Visual 
Studio/2019/Professional/VC/Tools/MSVC/14.28.29910/include\memory(3566,5): 
note: 'unique_ptr' has been explicitly marked deleted here
  unique_ptr(const unique_ptr&) = delete;

I used creduce with the same command line, looking for that error diagnostic 
with std:c++latest versus no diagnostic with std:c++20 ; this smaller test 
case, with a few edits, is the result

  # 1 "test.cpp" 1
  # 2 "test.cpp" 3
  namespace std {
  template  struct b { static constexpr c = a; };
  template  using d = b;
  using e = d;
  template  using f = int;
  template  using g = int;
  template  constexpr am = e ::c;
  template  constexpr au = false;
  class h {
  public:
template  h(i);
template  using j = f>;
template , int, int>>> h(h &) = delete;
  };
  h k() {
h l(new wchar_t);
return l;
  }
  }
  # 22 "test.cpp" 2


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105951

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

[PATCH] D105946: [PowerPC] Store, load, move from and to registers related builtins

[Nemanja Ivanovic via Phabricator via cfe-commits]

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

We have encountered an issue with `lwarx/ldarx` that required that they emit 
inline asm rather than an intrinsic. What makes `lbarx/lharx` different?




Comment at: clang/lib/Sema/SemaChecking.cpp:3370
+  case PPC::BI__builtin_ppc_lbarx:
+return SemaFeatureCheck(*this, TheCall, "extdiv",
+diag::err_ppc_builtin_only_on_arch, "8");

Why do these need the `extdiv` feature?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105946

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

[PATCH] D105904: [clangd] Support `#pragma mark` in the outline

[Sam McCall via Phabricator via cfe-commits]

sammccall added inline comments.



Comment at: clang-tools-extra/clangd/TextMarks.h:22
+/// Represents a programmer specified mark/note, typically used to easily 
locate
+/// or differentiate code. e.g. a `pragma mark`, a `TODO`.
+///

dgoldman wrote:
> sammccall wrote:
> > This seems like premature abstraction - you don't handle TODOs here, nor 
> > are they appropriate for the single use case we have. Moreover they don't 
> > satisfy the definition here: `int foo; // TODO: turn into a float` the TODO 
> > doesn't occupy the whole line.
> > 
> > If we need it, the appropriate generalization seems just as likely to be 
> > "pragmas" or "directives" as "textual marks".
> > 
> > Similarly, it's not clear that the logic around interpreting the strings 
> > e.g. as groups needs to be shared across features, nor is it terribly 
> > complicated.
> > So the interface here seems like it could be much simpler:
> > ```
> > struct PragmaMark {
> >   unsigned Line;
> >   string Text;
> > }
> > unique_ptr collectPragmaMarksCallback(const SourceManager&, 
> > vector &Out);
> > ```
> > 
> > I'd suggest putting this in CollectMacros.h (which would be misnamed but 
> > not terribly, or we could always rename) rather than adding a new header.
> We don't handle them at the moment, but Xcode does (for both Swift + ObjC): 
> https://medium.com/@cboynton/todo-make-your-notes-on-xcode-stand-out-5f5124ec064c.
>  You're right that they don't necessarily have to occupy the whole line 
> though, it's possible to have multiple per line although I'm not sure how 
> often that is used in practice.
This seems like a very different case, and I'm not convinced we should support 
it.

That `#pragma mark`s are used for grouping seems like the strongest argument 
for including them in the outline.  TODOs are not used for grouping.

The majority of `#pragma mark`s are written with XCode's conventions in mind, 
the majority of TODO comments are not. So there's a real question of whether 
authors want this. (And whether it should include all comments, or other kinds 
of structured comments...)

I'd suggest keeping the scope small and concrete. If you'd like to add 
abstractions because more cases are imminent, we probably need to get consensus 
on (some of) these cases first.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105904

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

[PATCH] D105564: Fix for DWARF parsing to better handle auto return type for member functions

[Adrian Prantl via Phabricator via cfe-commits]

aprantl added inline comments.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:2693
+other_die = dcu->LookupAddress(
+symtab->SymbolAtIndex(symbol_indexes[index])->GetFileAddress());
+  }

should there be an early exit if we found other_die?


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

https://reviews.llvm.org/D105564

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

[PATCH] D106065: [Clang] Add an empty builtins.h file.

[Nemanja Ivanovic via Phabricator via cfe-commits]

nemanjai added inline comments.



Comment at: clang/lib/Headers/builtins.h:8
+\*===--===*/
+
+#ifndef __BUILTINS_H

Please describe the purpose of this header file in a comment here.



Comment at: clang/test/Headers/builtins-header.c:1
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown -ffreestanding -emit-llvm 
-o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown -ffreestanding 
-emit-llvm -o - %s | FileCheck %s

Does this need something like `REQUIRES: powerpc-registered-target`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106065

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

[PATCH] D105384: [NVPTX, CUDA] Add .and.popc variant of the b1 MMA instruction.

[Artem Belevich via Phabricator via cfe-commits]

tra updated this revision to Diff 359047.
tra marked an inline comment as done.
tra added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105384

Files:
  clang/include/clang/Basic/BuiltinsNVPTX.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-nvptx-mma.cu
  clang/test/CodeGen/builtins-nvptx-mma.py
  llvm/include/llvm/IR/IntrinsicsNVVM.td
  llvm/lib/Target/NVPTX/NVPTXInstrInfo.td
  llvm/lib/Target/NVPTX/NVPTXIntrinsics.td
  llvm/test/CodeGen/NVPTX/wmma.py

Index: llvm/test/CodeGen/NVPTX/wmma.py
===
--- llvm/test/CodeGen/NVPTX/wmma.py
+++ llvm/test/CodeGen/NVPTX/wmma.py
@@ -55,14 +55,14 @@
 # RUN: llc < %t-ptx65-sm_75.ll -march=nvptx64 -mcpu=sm_75 -mattr=+ptx65 \
 # RUN:   | FileCheck %t-ptx65-sm_75.ll
 
-# Check all variants of instructions supported by PTX70 on SM80+
-# RUN: %python %s --ptx=70 --gpu-arch=80 > %t-ptx70-sm_80.ll
-# RUN: FileCheck %t-ptx70-sm_80.ll < %t-ptx70-sm_80.ll \
-# RUN:   --check-prefixes=INTRINSICS,M16N16,EXTGEOM,INT,SUBINT,MMA,ALTFLOAT,DOUBLE,PTX65MMA,PTX70MMA
-# RUN: FileCheck %t-ptx70-sm_80.ll < %t-ptx70-sm_80.ll \
+# Check all variants of instructions supported by PTX71 on SM80+
+# RUN: %python %s --ptx=71 --gpu-arch=80 > %t-ptx71-sm_80.ll
+# RUN: FileCheck %t-ptx71-sm_80.ll < %t-ptx71-sm_80.ll \
+# RUN:   --check-prefixes=INTRINSICS,M16N16,EXTGEOM,INT,SUBINT,MMA,ALTFLOAT,DOUBLE,PTX65MMA,PTX71MMA
+# RUN: FileCheck %t-ptx71-sm_80.ll < %t-ptx71-sm_80.ll \
 # RUN:   --check-prefixes=INTRINSICS
-# RUN: llc < %t-ptx70-sm_80.ll -march=nvptx64 -mcpu=sm_80 -mattr=+ptx70 \
-# RUN:   | FileCheck %t-ptx70-sm_80.ll
+# RUN: llc < %t-ptx71-sm_80.ll -march=nvptx64 -mcpu=sm_80 -mattr=+ptx71 \
+# RUN:   | FileCheck %t-ptx71-sm_80.ll
 
 from __future__ import print_function
 
@@ -649,9 +649,16 @@
   print(Template(mma_template).substitute(test_params))
   return (test_params["intrinsic"], test_params["instruction"])
 
+def get_b1_ops(ptx_type):
+  if ptx_type != "b1":
+return [""]
+  if ptx_version >= 71:
+return [".xor.popc", ".and.popc"]
+  return [".xor.popc"]
+
 def gen_wmma_mma_tests():
-  wmma_intrinsic_template = "llvm.nvvm.wmma.${geom}.mma.${alayout}.${blayout}${rnd}.${intrinsic_signature}${satf}"
-  wmma_instruction_template = "wmma.mma${mma_variant}.sync${aligned}.${alayout}.${blayout}.${geom}${rnd}.${ptx_signature}${satf}"
+  wmma_intrinsic_template = "llvm.nvvm.wmma.${geom}.mma${b1op}.${alayout}.${blayout}${rnd}.${intrinsic_signature}${satf}"
+  wmma_instruction_template = "wmma.mma${b1op}.sync${aligned}.${alayout}.${blayout}.${geom}${rnd}.${ptx_signature}${satf}"
 
   generated_items=[]
 
@@ -665,29 +672,30 @@
 if not is_wmma_variant_supported(op, alayout, blayout, rnd, satf):
   continue
 
-params = {
-"aligned" : ".aligned" if ptx_version >= 63 else "",
-"alayout" : alayout,
-"blayout" : blayout,
-"intrinsic_signature" : wmma_signature(op),
-"ptx_signature" : wmma_ptx_signature(op),
-"satf"  : satf,
-"rnd"   : rnd,
-"geom"  : op.a.geom,
-"mma_variant" : ".xor.popc" if op.a.mma_type.ptx_type == "b1" else "",
-}
+for b1op in get_b1_ops(op.a.mma_type.ptx_type):
+  params = {
+  "aligned" : ".aligned" if ptx_version >= 63 else "",
+  "alayout" : alayout,
+  "blayout" : blayout,
+  "intrinsic_signature" : wmma_signature(op),
+  "ptx_signature" : wmma_ptx_signature(op),
+  "satf"  : satf,
+  "rnd"   : rnd,
+  "geom"  : op.a.geom,
+  "b1op"  : b1op
+  }
 
-intrinsic_template = wmma_intrinsic_template
-instruction_template = wmma_instruction_template
+  intrinsic_template = wmma_intrinsic_template
+  instruction_template = wmma_instruction_template
 
-generated_items.append(common_mma_test_gen(params, op,
-  intrinsic_template, instruction_template))
+  generated_items.append(common_mma_test_gen(params, op,
+ intrinsic_template, instruction_template))
 
   return generated_items
 
 def gen_mma_tests():
-  mma_intrinsic_template = "llvm.nvvm.mma.${geom}.${alayout}.${blayout}${satf}.${intrinsic_signature}"
-  mma_instruction_template = "mma.sync${aligned}.${geom}.${alayout}.${blayout}${satf}.${ptx_signature}${mma_variant}"
+  mma_intrinsic_template = "llvm.nvvm.mma${b1op}.${geom}.${alayout}.${blayout}${satf}.${intrinsic_signature}"
+  mma_instruction_template = "mma.sync${aligned}.${geom}.${alayout}.${blayout}${satf}.${ptx_signature}${b1op}"
 
   generated_items=[]
 
@@ -700,22 +708,23 @@
 if not is_mma_variant_supported(op, alayout, blayout, satf):
   continue
 
-params = {
-"aligned" : ".aligned" if ptx_version >= 63 else "",
-"alayout" : alayout,
-"blayout" : blayout,
-

[PATCH] D101759: [PowerPC] Scalar IBM MASS library conversion pass

[Bardia Mahjour via Phabricator via cfe-commits]

bmahjour added inline comments.



Comment at: clang/include/clang/Driver/Options.td:1726
   NegFlag>;
-def fapprox_func : Flag<["-"], "fapprox-func">, Group, 
Flags<[CC1Option, NoDriverOption]>,
-  MarshallingInfoFlag>, 
ImpliedByAnyOf<[menable_unsafe_fp_math.KeyPath]>;
+defm approx_func : BoolFOption<"approx-func", LangOpts<"ApproxFunc">, 
DefaultFalse,
+  PosFlag, 
NegFlag>;

I think we should separate out the clang driver interface into its own patch 
and ask for feedback on the mailing list. One key question would be, should 
this option assume no-errno and no-trapping-math or not (given that there is no 
IR representation for them).

There should also be LIT tests dedicated to this to verify the clang interface. 
I only see llc interface being tested in this patch.



Comment at: llvm/include/llvm/Target/TargetOptions.h:179
+/// with approximate calculations
+unsigned ApproxFuncFPMath : 1;
+

We already have the `PPCGenScalarMASSEntries` bit, why do we need another one? 
Perhaps we can remove `PPCGenScalarMASSEntries`, but we should not have to turn 
on two options to get one transformation enabled.



Comment at: llvm/lib/Target/PowerPC/PPCGenScalarMASSEntries.cpp:72
+  // checking fast flag insread of nnan/ninf/afn because errno and 
+  // trapping-math don't have IR representation.
+  return CI.isFast();

...but errno and trapping-math would be an issue for non-finite entries as well.

Again, I think this function should just check for nnan/ninf/afn flags. We need 
to find out (with the help of the wider community) how to deal with the 
concerns surrounding errno and traps separately. One way to do that would be to 
broaden the definition of the `afn` flag to include no-errno and no-trapping 
semantics. Another way might be to make clang FE set the `afn` bit only if 
`-fno-math-errno` and `-fno-trapping-math` options are enabled (less 
desirable). A third way might be to add corresponding  function attributes to 
the IR for `-fno-math-errno` and `-fno-trapping-math`.

Once these issues are sorted out, we can add the appropriate constraints to the 
`isCandidateSafeToLower` function.



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:1370
+  // to be consistent to PPCGenScalarMASSEntries pass
+  if (TM.Options.PPCGenScalarMASSEntries && TM.Options.ApproxFuncFPMath) {
+if (TM.Options.NoInfsFPMath && TM.Options.NoNaNsFPMath &&

if someone compiles with -Ofast without any extra options, would 
`TM.Options.ApproxFuncFPMath` be true here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101759

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

[PATCH] D105384: [NVPTX, CUDA] Add .and.popc variant of the b1 MMA instruction.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D105384#2879308 , @steffenlarsen 
wrote:

> LGTM! Are the test failures related to this, you reckon?

AFAICT, no, the test failures don't seem to be related. It appears that the 
test runs rarely succeed in general. They are mostly red for nearly all build 
attempts 
(https://reviews.llvm.org/harbormaster/build/?plan=PHID-HMCP-p2oc4ocen3l2yzymvg2l),
 even though LLVM buildbots are green (https://lab.llvm.org/buildbot/#/).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105384

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

[PATCH] D105930: [PowerPC] Implement XL compact math builtins

[Lei Huang via Phabricator via cfe-commits]

lei updated this revision to Diff 359050.
lei marked 3 inline comments as done.
lei added a comment.

Address review comments to add/upate:

- builtin encoding for params that need to be folded into constant expr
- llvm intrinsic property for immediates
- test line for `-mattr=-vsx`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105930

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-math.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9-64bit.c
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr9.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/lib/Target/PowerPC/PPCInstrVSX.td
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9-64bit.ll
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9.ll

Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9.ll
@@ -0,0 +1,27 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s --check-prefix=CHECK-32BIT
+
+define dso_local zeroext i32 @extract_exp(double %d) {
+; CHECK-LABEL: extract_exp:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xsxexpdp 3, 1
+; CHECK-NEXT:clrldi 3, 3, 32
+; CHECK-NEXT:blr
+;
+; CHECK-32BIT-LABEL: extract_exp:
+; CHECK-32BIT:   # %bb.0: # %entry
+; CHECK-32BIT-NEXT:xsxexpdp 3, 1
+; CHECK-32BIT-NEXT:# kill: def $r3 killed $r3 killed $x3
+; CHECK-32BIT-NEXT:blr
+entry:
+  %0 = tail call i32 @llvm.ppc.extract.exp(double %d)
+  ret i32 %0
+}
+declare i32 @llvm.ppc.extract.exp(double)
Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9-64bit.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr9-64bit.ll
@@ -0,0 +1,31 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN:   -mcpu=pwr9 < %s | FileCheck %s
+
+define dso_local i64 @extract_sig(double %d) {
+; CHECK-LABEL: extract_sig:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:xsxsigdp 3, 1
+; CHECK-NEXT:blr
+entry:
+  %0 = tail call i64 @llvm.ppc.extract.sig(double %d)
+  ret i64 %0
+}
+declare i64 @llvm.ppc.extract.sig(double)
+
+define dso_local double @insert_exp(double %d, i64 %ull) {
+; CHECK-LABEL: insert_exp:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:mffprd 3, 1
+; CHECK-NEXT:xsiexpdp 1, 3, 4
+; CHECK-NEXT:# kill: def $f1 killed $f1 killed $vsl1
+; CHECK-NEXT:blr
+entry:
+  %0 = tail call double @llvm.ppc.insert.exp(double %d, i64 %ull)
+  ret double %0
+}
+declare double @llvm.ppc.insert.exp(double, i64)
Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.ll
@@ -0,0 +1,231 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu < %s |\
+; RUN:   FileCheck %s --check-prefix=CHECK-PWR8
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mattr=-vsx < %s | FileCheck %s --check-prefix=CHECK-NOVSX
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN:   -mcpu=pwr7 < %s | FileCheck %s --check-prefix=CHECK-PWR7
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix -mcpu=pwr7 \
+; RUN:   < %s | FileCheck %s --check-prefix=CHECK-PWR7
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix -mcpu=pwr8 < %s |\
+; RUN:   FileCheck %s --check-prefix=CHECK-PWR8
+
+define dso_local void @mtfsb0() {
+; CHECK-PWR8-LABEL: mtfsb0:
+; CHECK-PWR8:   # %bb.0: # %entry
+; CHECK-PWR8-NEXT:mtfsb0 10
+; CHECK-PWR8-NEXT:blr
+;
+; CHECK-NOVSX-LABEL: mtfsb0:
+; CHECK-NOVSX:   # %bb.0: # %entry
+; CHECK-NOVSX-NEXT:mtfsb0 10
+; CHECK-NOVSX-NEXT:   

[PATCH] D105930: [PowerPC] Implement XL compact math builtins

[Lei Huang via Phabricator via cfe-commits]

lei added inline comments.



Comment at: llvm/lib/Target/PowerPC/PPCInstrInfo.td:3650
+// XL Compat intrinsics.
+def : Pat<(int_ppc_fmsub f64:$A, f64:$B, f64:$C), (FMSUB $A, $B, $C)>;
+def : Pat<(int_ppc_fmsubs f32:$A, f32:$B, f32:$C), (FMSUBS $A, $B, $C)>;

nemanjai wrote:
> Please review the order of operands carefully here. I believe the order is 
> wrong either for this one or for the VSX version. Double-check all of the 
> others as well please.
I double checked and both seem correct to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105930

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

[PATCH] D106084: [DebugInfo] Switch to using constructor homing (-debug-info-kind=constructor) by default when debug info is enabled

[Amy Huang via Phabricator via cfe-commits]

akhuang created this revision.
Herald added subscribers: dexonsmith, fedor.sergeev.
akhuang requested review of this revision.
Herald added projects: clang, LLDB.
Herald added subscribers: lldb-commits, cfe-commits.

Constructor homing reduces the amount of class type info that is emitted
by emitting conmplete type info for a class only when a constructor for
that class is emitted.

This will mainly reduce the amount of duplicate debug info in object
files. In Chrome enabling ctor homing decreased total build directory sizes
by about 30%.

It's also expected that some class types (such as unused classes)
will no longer be emitted in the debug info. This is fine, since we wouldn't
expect to need these types when debugging.

In some cases (e.g. libc++, https://reviews.llvm.org/D98750), classes
are used without calling the constructor. Since this is technically
undefined behavior, enabling constructor homing should be fine.
However Clang now has an attribute
`__attribute__((standalone_debug))` that can be used on classes to
ignore ctor homing.

Bug: https://bugs.llvm.org/show_bug.cgi?id=46537


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106084

Files:
  clang/include/clang/Basic/DebugInfoOptions.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGenCXX/debug-info-template-deduction-guide.cpp
  clang/test/Driver/cl-options.c
  clang/test/Driver/clang-g-opts.c
  clang/test/Driver/cuda-dwarf-2.cu
  clang/test/Driver/debug-options-as.c
  clang/test/Driver/debug-options.c
  clang/test/Driver/integrated-as.s
  clang/test/Driver/myriad-toolchain.c
  clang/test/Driver/openmp-offload-gpu.c
  clang/test/Driver/split-debug.c
  lldb/test/Shell/SymbolFile/PDB/Inputs/ClassLayoutTest.cpp

Index: lldb/test/Shell/SymbolFile/PDB/Inputs/ClassLayoutTest.cpp
===
--- lldb/test/Shell/SymbolFile/PDB/Inputs/ClassLayoutTest.cpp
+++ lldb/test/Shell/SymbolFile/PDB/Inputs/ClassLayoutTest.cpp
@@ -106,6 +106,9 @@
 int main() {
   MemberTest::Base B1;
   B1.Get();
+  // Create instance of C1 so that it has debug info (due to constructor
+  // homing).
+  MemberTest::Class C1;
   MemberTest::Class::StaticMemberFunc(1, 10, 2);
   return 0;
 }
Index: clang/test/Driver/split-debug.c
===
--- clang/test/Driver/split-debug.c
+++ clang/test/Driver/split-debug.c
@@ -9,7 +9,7 @@
 
 // INLINE: "-fsplit-dwarf-inlining"
 // NOINLINE-NOT: "-fsplit-dwarf-inlining"
-// SPLIT:  "-debug-info-kind=limited"
+// SPLIT:  "-debug-info-kind=constructor"
 // SPLIT-SAME: "-ggnu-pubnames"
 // SPLIT-SAME: "-split-dwarf-file" "split-debug.dwo" "-split-dwarf-output" "split-debug.dwo"
 
@@ -38,14 +38,14 @@
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=single -g -gno-split-dwarf %s 2>&1 | FileCheck %s --check-prefix=NOSPLIT
 // RUN: %clang -### -c -target x86_64 -gno-split-dwarf -g -gsplit-dwarf %s 2>&1 | FileCheck %s --check-prefixes=NOINLINE,SPLIT
 
-// NOSPLIT: "-debug-info-kind=limited"
+// NOSPLIT: "-debug-info-kind=constructor"
 // NOSPLIT-NOT: "-ggnu-pubnames"
 // NOSPLIT-NOT: "-split-dwarf
 
 /// Test -gsplit-dwarf=single.
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=single -g %s 2>&1 | FileCheck %s --check-prefix=SINGLE
 
-// SINGLE: "-debug-info-kind=limited"
+// SINGLE: "-debug-info-kind=constructor"
 // SINGLE: "-split-dwarf-file" "split-debug.o"
 // SINGLE-NOT: "-split-dwarf-output"
 
@@ -62,7 +62,7 @@
 
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=split -g -gno-pubnames %s 2>&1 | FileCheck %s --check-prefixes=NOPUBNAMES
 // RUN: %clang -### -c -target x86_64 -gsplit-dwarf=split -g -gno-gnu-pubnames %s 2>&1 | FileCheck %s --check-prefixes=NOPUBNAMES
-// NOPUBNAMES:  "-debug-info-kind=limited"
+// NOPUBNAMES:  "-debug-info-kind=constructor"
 // NOPUBNAMES-NOT:  "-ggnu-pubnames"
 // NOPUBNAMES-SAME: "-split-dwarf-file" "split-debug.dwo" "-split-dwarf-output" "split-debug.dwo"
 
Index: clang/test/Driver/openmp-offload-gpu.c
===
--- clang/test/Driver/openmp-offload-gpu.c
+++ clang/test/Driver/openmp-offload-gpu.c
@@ -248,7 +248,7 @@
 
 // HAS_DEBUG-NOT: warning: debug
 // HAS_DEBUG: "-triple" "nvptx64-nvidia-cuda"
-// HAS_DEBUG-SAME: "-debug-info-kind={{limited|line-tables-only}}"
+// HAS_DEBUG-SAME: "-debug-info-kind={{constructor|line-tables-only}}"
 // HAS_DEBUG-SAME: "-dwarf-version=2"
 // HAS_DEBUG-SAME: "-fopenmp-is-device"
 // HAS_DEBUG: ptxas
Index: clang/test/Driver/myriad-toolchain.c
===
--- clang/test/Driver/myriad-toolchain.c
+++ clang/test/Driver/myriad-toolchain.c
@@ -83,7 +83,7 @@
 // NOSTDLIB-NOT: "-lc"
 
 // RUN: %clang -### -c -g %s -target sparc-myriad 2>&1 | FileCheck -check-prefix=G_SPARC %s
-// G_SPARC: "-debug-info-kind=limited" "-dwarf-version=2"
+// G_SPARC: "-debug-info-kind=constructor" "-dwarf-version=2"

[PATCH] D104386: [PowerPC][Builtins] Added a number of builtins for compatibility with XL.

[Stefan Pintilie via Phabricator via cfe-commits]

stefanp updated this revision to Diff 359054.
stefanp added a comment.

Realized after I updated the patch that I got the darn tests wrong.
I've updated the patch and fixed that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104386

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-abs.c
  clang/test/CodeGen/builtins-ppc-xlcompat-alloca.c
  clang/test/CodeGen/builtins-ppc-xlcompat-bpermd.c
  clang/test/CodeGen/builtins-ppc-xlcompat-cipher.c
  clang/test/CodeGen/builtins-ppc-xlcompat-cmplx.c
  clang/test/CodeGen/builtins-ppc-xlcompat-darn.c
  clang/test/CodeGen/builtins-ppc-xlcompat-div.c
  clang/test/CodeGen/builtins-ppc-xlcompat-error.c
  clang/test/CodeGen/builtins-ppc-xlcompat-expect.c
  clang/test/CodeGen/builtins-ppc-xlcompat-fma.c
  clang/test/CodeGen/builtins-ppc-xlcompat-memory.c
  clang/test/CodeGen/builtins-ppc-xlcompat-mode.c
  clang/test/CodeGen/builtins-ppc-xlcompat-popcnt.c
  clang/test/CodeGen/builtins-ppc-xlcompat-rotate.c

Index: clang/test/CodeGen/builtins-ppc-xlcompat-rotate.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-rotate.c
@@ -0,0 +1,39 @@
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc-unknown-unknown \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpcle-unknown-unknown \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc-unknown-aix \
+// RUN:   -emit-llvm %s -o -  -target-cpu pwr7 | FileCheck %s
+
+// CHECK-LABEL: @testrotatel4(
+// CHECK: [[TMP:%.*]] = call i32 @llvm.fshl.i32(i32 {{%.*}}, i32 {{%.*}}, i32 {{%.*}})
+// CHECK-NEXT:ret i32 [[TMP]]
+//
+unsigned int testrotatel4(unsigned int rs, unsigned int shift) {
+  return __rotatel4(rs, shift);
+}
+
+// CHECK-LABEL: @testrotatel8(
+// CHECK: [[TMP:%.*]] = call i64 @llvm.fshl.i64(i64 {{%.*}}, i64 {{%.*}}, i64 {{%.*}})
+// CHECK-NEXT:ret i64 [[TMP]]
+//
+unsigned long long testrotatel8(unsigned long long rs, unsigned long long shift) {
+  return __rotatel8(rs, shift);
+}
+
+// CHECK-LABEL: @testrdlam(
+// CHECK: [[TMP0:%.*]] = call i64 @llvm.fshl.i64(i64 {{%.*}}, i64 {{%.*}}, i64 {{%.*}})
+// CHECK-NEXT:[[TMP1:%.*]] = and i64 [[TMP0]], 7
+// CHECK-NEXT:ret i64 [[TMP1]]
+//
+unsigned long long testrdlam(unsigned long long rs, unsigned int shift) {
+  // The third parameter is a mask that must be a constant that represents a
+  // contiguous bit field.
+  return __rdlam(rs, shift, 7);
+}
Index: clang/test/CodeGen/builtins-ppc-xlcompat-popcnt.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-ppc-xlcompat-popcnt.c
@@ -0,0 +1,63 @@
+// RUN: %clang_cc1 -triple powerpc64-unknown-unknown \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64le-unknown-unknown \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc64-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc-unknown-unknown \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpcle-unknown-unknown \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr8 | FileCheck %s
+// RUN: %clang_cc1 -triple powerpc-unknown-aix \
+// RUN:   -emit-llvm %s -o - -target-cpu pwr7 | FileCheck %s
+
+// CHECK-LABEL: @testcntlz4(
+// CHECK: [[TMP:%.*]] = call i32 @llvm.ctlz.i32(i32 {{%.*}}, i1 false)
+// CHECK-NEXT:ret i32 [[TMP]]
+//
+unsigned int testcntlz4(unsigned int value) {
+  return __cntlz4(value);
+}
+
+// CHECK-LABEL: @testcntlz8(
+// CHECK: [[TMP:%.*]] = call i64 @llvm.ctlz.i64(i64 {{%.*}}, i1 false)
+// CHECK-NEXT:[[CAST:%.*]] = trunc i64 [[TMP]] to i32
+// CHECK-NEXT:ret i32 [[CAST]]
+//
+unsigned int testcntlz8(unsigned long long value) {
+  return __cntlz8(value);
+}
+
+// CHECK-LABEL: @testcnttz4(
+// CHECK: [[TMP:%.*]] = call i32 @llvm.cttz.i32(i32 {{%.*}}, i1 false)
+// CHECK-NEXT:ret i32 [[TMP]]
+//
+unsigned int testcnttz4(unsigned int value) {
+  return __cnttz4(value);
+}
+
+// CHECK-LABEL: @testcnttz8(
+// CHECK: [[TMP:%.*]] = call i64 @llvm.cttz.i64(i64 {{%.*}}, i1 false)
+// CHECK-NEXT:[[CAST:%.*]] = trunc i64

[PATCH] D104887: [clang] Evaluate strlen of strcpy argument for -Wfortify-source.

[Christopher Di Bella via Phabricator via cfe-commits]

cjdb added a comment.

Thanks for getting around to this! Just a nit and a clarifying question.




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:821
+  "'%0' will always overflow; destination buffer has size %1,"
+  " but the source string has length %2 (including null byte)">,
+  InGroup;

Nit: s/null/NUL



Comment at: clang/lib/AST/ExprConstant.cpp:15737
+
+// Fall through to slow path.
+  }

This comment is slightly different to the RHS: does that mean that a diagnostic 
might not be issued?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104887

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

[PATCH] D106084: [DebugInfo] Switch to using constructor homing (-debug-info-kind=constructor) by default when debug info is enabled

[David Blaikie via Phabricator via cfe-commits]

dblaikie accepted this revision.
dblaikie added subscribers: probinson, aprantl.
dblaikie added a comment.
This revision is now accepted and ready to land.

Please wait for sign-off from @aprantl (or another appropriate Apple 
representative) & @probinson (or another appropriate Sony representative) as 
well - at least to check everyone's ready for this. (Apple I think still uses 
-fstandalone-debug, so won't be immediately relevant, but good to know it's 
coming in case some of their users are using -fno-standalone-debug or they have 
plans in motion, etc)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106084

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

[PATCH] D105951: [clang] P2266 implicit moves STL workaround

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D105951#2880654 , @mibintc wrote:

> Intel compiles VS2019 #include files regularly with clang, and the file 
>  compiled with -std:c++latest encounters this error report, which 
> @aaron.ballman suggests is related to this effort.

I think we might be in an awkward situation where some MSVC STL code needs the 
implicit cast in order to work, such as:

  In file included from c:/Program files (x86)/Microsoft Visual 
Studio/2019/Professional/VC/Tools/MSVC/14.28.29910/include\string:11:
  c:/Program files (x86)/Microsoft Visual 
Studio/2019/Professional/VC/Tools/MSVC/14.28.29910/include\xstring(4714,12): 
error: non-const lvalue reference to type 'basic_istream<...>' cannot bind to a 
temporary of type 'basic_istream<...>'
  return _Istr;
 ^

This issue was fixed with the previous workaround. But other MSVC STL code 
fails without the implicit cast, such as:

  In file included from tst_incl_filesystem.cpp:2:
  c:/Program files (x86)/Microsoft Visual 
Studio/2019/Professional/VC/Tools/MSVC/14.28.29910/include\filesystem(3099,20): 
error: call to deleted constructor of 'unique_ptr'
  return _Cleaned_link;
 ^

(At least, Melanie's reduced example fails with this patch, but if you remove 
the system header or namespace std bits from the test, then it passes.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105951

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