[clang] [alpha.webkit.UncountedLocalVarsChecker] Allow uncounted object references within trivial statements (PR #82229)

2024-03-01 Thread Ryosuke Niwa via cfe-commits

https://github.com/rniwa updated https://github.com/llvm/llvm-project/pull/82229

>From fd171b82d03b29926984b5b835ad9c0ccf197536 Mon Sep 17 00:00:00 2001
From: Ryosuke Niwa 
Date: Mon, 19 Feb 2024 01:07:13 -0800
Subject: [PATCH 1/5] [alpha.webkit.UncountedLocalVarsChecker] Allow uncounted
 object references within trivial statements

This PR makes alpha.webkit.UncountedLocalVarsChecker ignore raw references and 
pointers to
a ref counted type which appears within "trival" statements. To do this, this 
PR extends
TrivialFunctionAnalysis so that it can also analyze "triviality" of statements 
as well as
that of functions Each Visit* function is now augmented with withCachedResult, 
which is
responsible for looking up and updating the cache for each Visit* functions.

As this PR dramatically improves the false positive rate of the checker, it 
also deletes
the code to ignore raw pointers and references within if and for statements.
---
 .../Checkers/WebKit/PtrTypesSemantics.cpp | 221 --
 .../Checkers/WebKit/PtrTypesSemantics.h   |  21 +-
 .../WebKit/UncountedLocalVarsChecker.cpp  |  69 +++---
 .../Analysis/Checkers/WebKit/mock-types.h |   2 +
 .../Checkers/WebKit/uncounted-local-vars.cpp  |  92 +++-
 5 files changed, 286 insertions(+), 119 deletions(-)

diff --git a/clang/lib/StaticAnalyzer/Checkers/WebKit/PtrTypesSemantics.cpp 
b/clang/lib/StaticAnalyzer/Checkers/WebKit/PtrTypesSemantics.cpp
index defd83ec8e179c1..904781e6ea72ae2 100644
--- a/clang/lib/StaticAnalyzer/Checkers/WebKit/PtrTypesSemantics.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/WebKit/PtrTypesSemantics.cpp
@@ -245,18 +245,41 @@ class TrivialFunctionAnalysisVisitor
 
   // Returns false if at least one child is non-trivial.
   bool VisitChildren(const Stmt *S) {
-for (const Stmt *Child : S->children()) {
-  if (Child && !Visit(Child))
+return withCachedResult(S, [&]() {
+  for (const Stmt *Child : S->children()) {
+if (Child && !Visit(Child))
+  return false;
+  }
+  return true;
+});
+  }
+
+  bool VisitSubExpr(const Expr *Parent, const Expr *E) {
+return withCachedResult(Parent, [&]() {
+  if (!Visit(E))
 return false;
-}
+  return true;
+});
+  }
 
-return true;
+  template 
+  bool withCachedResult(const StmtType *S, CheckFunction Function) {
+// Insert false to the cache first to avoid infinite recursion.
+auto [It, IsNew] = StatementCache.insert(std::make_pair(S, false));
+if (!IsNew)
+  return It->second;
+bool Result = Function();
+It->second = Result;
+return Result;
   }
 
 public:
-  using CacheTy = TrivialFunctionAnalysis::CacheTy;
+  using FunctionCacheTy = TrivialFunctionAnalysis::FunctionCacheTy;
+  using StatementCacheTy = TrivialFunctionAnalysis::StatementCacheTy;
 
-  TrivialFunctionAnalysisVisitor(CacheTy &Cache) : Cache(Cache) {}
+  TrivialFunctionAnalysisVisitor(FunctionCacheTy &FunctionCache,
+ StatementCacheTy &StatementCache)
+  : FunctionCache(FunctionCache), StatementCache(StatementCache) {}
 
   bool VisitStmt(const Stmt *S) {
 // All statements are non-trivial unless overriden later.
@@ -272,13 +295,21 @@ class TrivialFunctionAnalysisVisitor
 
   bool VisitReturnStmt(const ReturnStmt *RS) {
 // A return statement is allowed as long as the return value is trivial.
-if (auto *RV = RS->getRetValue())
-  return Visit(RV);
-return true;
+return withCachedResult(RS, [&]() {
+  if (auto *RV = RS->getRetValue())
+return Visit(RV);
+  return true;
+});
+  }
+
+  bool VisitCXXForRangeStmt(const CXXForRangeStmt *FS) {
+return VisitChildren(FS);
   }
 
   bool VisitDeclStmt(const DeclStmt *DS) { return VisitChildren(DS); }
   bool VisitDoStmt(const DoStmt *DS) { return VisitChildren(DS); }
+  bool VisitForStmt(const ForStmt *FS) { return VisitChildren(FS); }
+  bool VisitWhileStmt(const WhileStmt *WS) { return VisitChildren(WS); }
   bool VisitIfStmt(const IfStmt *IS) { return VisitChildren(IS); }
   bool VisitSwitchStmt(const SwitchStmt *SS) { return VisitChildren(SS); }
   bool VisitCaseStmt(const CaseStmt *CS) { return VisitChildren(CS); }
@@ -286,17 +317,26 @@ class TrivialFunctionAnalysisVisitor
 
   bool VisitUnaryOperator(const UnaryOperator *UO) {
 // Operator '*' and '!' are allowed as long as the operand is trivial.
-if (UO->getOpcode() == UO_Deref || UO->getOpcode() == UO_AddrOf ||
-UO->getOpcode() == UO_LNot)
-  return Visit(UO->getSubExpr());
-
-// Other operators are non-trivial.
-return false;
+return withCachedResult(UO, [&]() {
+  auto op = UO->getOpcode();
+  if (op == UO_Deref || op == UO_AddrOf || op == UO_LNot)
+return Visit(UO->getSubExpr());
+  if (UO->isIncrementOp() || UO->isDecrementOp()) {
+if (auto *RefExpr = dyn_cast(UO->getSubExpr())) {
+  if (auto *Decl = dyn_cast(RefExpr->getDecl()))
+return Decl-

[clang] [llvm] [AMDGPU] Emit a waitcnt instruction after each memory instruction (PR #79236)

2024-03-01 Thread Pierre van Houtryve via cfe-commits


@@ -2594,12 +2594,10 @@ bool SIMemoryLegalizer::expandAtomicCmpxchgOrRmw(const 
SIMemOpInfo &MOI,
 MOI.getOrdering() == AtomicOrdering::SequentiallyConsistent ||
 MOI.getFailureOrdering() == AtomicOrdering::Acquire ||
 MOI.getFailureOrdering() == AtomicOrdering::SequentiallyConsistent) {
-  Changed |= CC->insertWait(MI, MOI.getScope(),

Pierre-vh wrote:

extra formatting change

https://github.com/llvm/llvm-project/pull/79236
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [AMDGPU] Emit a waitcnt instruction after each memory instruction (PR #79236)

2024-03-01 Thread Pierre van Houtryve via cfe-commits


@@ -2326,6 +2326,20 @@ bool 
SIInsertWaitcnts::insertWaitcntInBlock(MachineFunction &MF,
 }
 #endif
 
+if (ST->isPreciseMemoryEnabled()) {
+  AMDGPU::Waitcnt Wait;
+  if (WCG == &WCGPreGFX12)

Pierre-vh wrote:

Use `ST->hasExtendedWaitCounts()` instead of checking the pointer?

https://github.com/llvm/llvm-project/pull/79236
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Support RISC-V Profiles in -march option (PR #76357)

2024-03-01 Thread Wang Pengcheng via cfe-commits

wangpc-pp wrote:

Ping.

https://github.com/llvm/llvm-project/pull/76357
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 128780b - [clang][dataflow] Correctly treat empty initializer lists for unions. (#82986)

2024-03-01 Thread via cfe-commits

Author: martinboehme
Date: 2024-03-01T09:27:59+01:00
New Revision: 128780b06f5bd0e586ee81e1e0e75f63c5664cfc

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

LOG: [clang][dataflow] Correctly treat empty initializer lists for unions. 
(#82986)

This fixes a crash introduced by
https://github.com/llvm/llvm-project/pull/82348
but also adds additional handling to make sure that we treat empty
initializer
lists for both unions and structs/classes correctly (see tests added in
this
patch).

Added: 


Modified: 
clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
clang/lib/Analysis/FlowSensitive/Transfer.cpp
clang/unittests/Analysis/FlowSensitive/TestingSupport.h
clang/unittests/Analysis/FlowSensitive/TransferTest.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
index 7f8c70d169376e..62e7af7ac219bc 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
@@ -723,9 +723,12 @@ RecordStorageLocation *getImplicitObjectLocation(const 
CXXMemberCallExpr &MCE,
 RecordStorageLocation *getBaseObjectLocation(const MemberExpr &ME,
  const Environment &Env);
 
-/// Returns the fields of `RD` that are initialized by an `InitListExpr`, in 
the
-/// order in which they appear in `InitListExpr::inits()`.
-std::vector getFieldsForInitListExpr(const RecordDecl *RD);
+/// Returns the fields of a `RecordDecl` that are initialized by an
+/// `InitListExpr`, in the order in which they appear in
+/// `InitListExpr::inits()`.
+/// `Init->getType()` must be a record type.
+std::vector
+getFieldsForInitListExpr(const InitListExpr *InitList);
 
 /// Associates a new `RecordValue` with `Loc` and returns the new value.
 RecordValue &refreshRecordValue(RecordStorageLocation &Loc, Environment &Env);

diff  --git a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp 
b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
index d487944ce92111..fd7b06efcc7861 100644
--- a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -361,8 +361,8 @@ getFieldsGlobalsAndFuncs(const Stmt &S, FieldSet &Fields,
 if (const auto *FD = dyn_cast(VD))
   Fields.insert(FD);
   } else if (auto *InitList = dyn_cast(&S)) {
-if (RecordDecl *RD = InitList->getType()->getAsRecordDecl())
-  for (const auto *FD : getFieldsForInitListExpr(RD))
+if (InitList->getType()->isRecordType())
+  for (const auto *FD : getFieldsForInitListExpr(InitList))
 Fields.insert(FD);
   }
 }
@@ -983,7 +983,7 @@ StorageLocation &Environment::createObjectInternal(const 
ValueDecl *D,
   }
 
   Value *Val = nullptr;
-  if (InitExpr)
+  if (InitExpr) {
 // In the (few) cases where an expression is intentionally
 // "uninterpreted", `InitExpr` is not associated with a value.  There are
 // two ways to handle this situation: propagate the status, so that
@@ -998,6 +998,11 @@ StorageLocation &Environment::createObjectInternal(const 
ValueDecl *D,
 // default value (assuming we don't update the environment API to return
 // references).
 Val = getValue(*InitExpr);
+
+if (!Val && isa(InitExpr) &&
+InitExpr->getType()->isPointerType())
+  Val = 
&getOrCreateNullPointerValue(InitExpr->getType()->getPointeeType());
+  }
   if (!Val)
 Val = createValue(Ty);
 
@@ -1104,12 +1109,22 @@ RecordStorageLocation *getBaseObjectLocation(const 
MemberExpr &ME,
   return Env.get(*Base);
 }
 
-std::vector getFieldsForInitListExpr(const RecordDecl *RD) {
+std::vector
+getFieldsForInitListExpr(const InitListExpr *InitList) {
+  const RecordDecl *RD = InitList->getType()->getAsRecordDecl();
+  assert(RD != nullptr);
+
+  std::vector Fields;
+
+  if (InitList->getType()->isUnionType()) {
+Fields.push_back(InitList->getInitializedFieldInUnion());
+return Fields;
+  }
+
   // Unnamed bitfields are only used for padding and do not appear in
   // `InitListExpr`'s inits. However, those fields do appear in `RecordDecl`'s
   // field list, and we thus need to remove them before mapping inits to
   // fields to avoid mapping inits to the wrongs fields.
-  std::vector Fields;
   llvm::copy_if(
   RD->fields(), std::back_inserter(Fields),
   [](const FieldDecl *Field) { return !Field->isUnnamedBitfield(); });

diff  --git a/clang/lib/Analysis/FlowSensitive/Transfer.cpp 
b/clang/lib/Analysis/FlowSensitive/Transfer.cpp
index 089854264f483a..04aa2831df0558 100644
--- a/clang/lib/Analysis/FlowSensitive/Trans

[clang] [clang][dataflow] Correctly treat empty initializer lists for unions. (PR #82986)

2024-03-01 Thread via cfe-commits

https://github.com/martinboehme closed 
https://github.com/llvm/llvm-project/pull/82986
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [clangd] [HeuristicResolver] Protect against infinite recursion on DependentNameTypes (PR #83542)

2024-03-01 Thread Nathan Ridge via cfe-commits

https://github.com/HighCommander4 created 
https://github.com/llvm/llvm-project/pull/83542

Fixes https://github.com/clangd/clangd/issues/1951

>From 0ad99c63ab1482c28f5226f8611798c035493495 Mon Sep 17 00:00:00 2001
From: Nathan Ridge 
Date: Fri, 1 Mar 2024 03:27:51 -0500
Subject: [PATCH] [clangd] [HeuristicResolver] Protect against infinite
 recursion on DependentNameTypes

Fixes https://github.com/clangd/clangd/issues/1951
---
 .../clangd/HeuristicResolver.cpp  | 170 ++
 clang-tools-extra/clangd/HeuristicResolver.h  |  37 
 .../clangd/unittests/FindTargetTests.cpp  |  10 ++
 3 files changed, 148 insertions(+), 69 deletions(-)

diff --git a/clang-tools-extra/clangd/HeuristicResolver.cpp 
b/clang-tools-extra/clangd/HeuristicResolver.cpp
index 3c147b6b582bf0..26d54200eeffd2 100644
--- a/clang-tools-extra/clangd/HeuristicResolver.cpp
+++ b/clang-tools-extra/clangd/HeuristicResolver.cpp
@@ -16,6 +16,80 @@
 namespace clang {
 namespace clangd {
 
+namespace {
+
+// Helper class for implementing HeuristicResolver.
+// Unlike HeuristicResolver which is a long-lived class,
+// a new instance of this class is created for every external
+// call into a HeuristicResolver operation. That allows this
+// class to store state that's local to such a top-level call,
+// particularly "recursion protection sets" that keep track of
+// nodes that have already been seen to avoid infinite recursion.
+class HeuristicResolverImpl {
+public:
+  HeuristicResolverImpl(ASTContext &Ctx) : Ctx(Ctx) {}
+
+  // These functions match the public interface of HeuristicResolver
+  // (but aren't const since they may modify the recursion protection sets).
+  std::vector
+  resolveMemberExpr(const CXXDependentScopeMemberExpr *ME);
+  std::vector
+  resolveDeclRefExpr(const DependentScopeDeclRefExpr *RE);
+  std::vector resolveTypeOfCallExpr(const CallExpr *CE);
+  std::vector resolveCalleeOfCallExpr(const CallExpr *CE);
+  std::vector
+  resolveUsingValueDecl(const UnresolvedUsingValueDecl *UUVD);
+  std::vector
+  resolveDependentNameType(const DependentNameType *DNT);
+  std::vector resolveTemplateSpecializationType(
+  const DependentTemplateSpecializationType *DTST);
+  const Type *resolveNestedNameSpecifierToType(const NestedNameSpecifier *NNS);
+  const Type *getPointeeType(const Type *T);
+
+private:
+  ASTContext &Ctx;
+
+  // Recursion protection sets
+  llvm::SmallSet SeenDependentNameTypes;
+
+  // Given a tag-decl type and a member name, heuristically resolve the
+  // name to one or more declarations.
+  // The current heuristic is simply to look up the name in the primary
+  // template. This is a heuristic because the template could potentially
+  // have specializations that declare different members.
+  // Multiple declarations could be returned if the name is overloaded
+  // (e.g. an overloaded method in the primary template).
+  // This heuristic will give the desired answer in many cases, e.g.
+  // for a call to vector::size().
+  std::vector
+  resolveDependentMember(const Type *T, DeclarationName Name,
+ llvm::function_ref Filter);
+
+  // Try to heuristically resolve the type of a possibly-dependent expression
+  // `E`.
+  const Type *resolveExprToType(const Expr *E);
+  std::vector resolveExprToDecls(const Expr *E);
+
+  // Helper function for HeuristicResolver::resolveDependentMember()
+  // which takes a possibly-dependent type `T` and heuristically
+  // resolves it to a CXXRecordDecl in which we can try name lookup.
+  CXXRecordDecl *resolveTypeToRecordDecl(const Type *T);
+
+  // This is a reimplementation of CXXRecordDecl::lookupDependentName()
+  // so that the implementation can call into other HeuristicResolver helpers.
+  // FIXME: Once HeuristicResolver is upstreamed to the clang libraries
+  // (https://github.com/clangd/clangd/discussions/1662),
+  // CXXRecordDecl::lookupDepenedentName() can be removed, and its call sites
+  // can be modified to benefit from the more comprehensive heuristics offered
+  // by HeuristicResolver instead.
+  std::vector
+  lookupDependentName(CXXRecordDecl *RD, DeclarationName Name,
+  llvm::function_ref Filter);
+  bool findOrdinaryMemberInDependentClasses(const CXXBaseSpecifier *Specifier,
+CXXBasePath &Path,
+DeclarationName Name);
+};
+
 // Convenience lambdas for use as the 'Filter' parameter of
 // HeuristicResolver::resolveDependentMember().
 const auto NoFilter = [](const NamedDecl *D) { return true; };
@@ -31,8 +105,6 @@ const auto TemplateFilter = [](const NamedDecl *D) {
   return isa(D);
 };
 
-namespace {
-
 const Type *resolveDeclsToType(const std::vector &Decls,
ASTContext &Ctx) {
   if (Decls.size() != 1) // Names an overload set -- just bail.
@@ -46,12 +118,10 @@ const Type *resolveDeclsToType(const std::vector &Decls,
   return nullptr;
 }
 
-} // name

[clang-tools-extra] [clangd] [HeuristicResolver] Protect against infinite recursion on DependentNameTypes (PR #83542)

2024-03-01 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clangd

Author: Nathan Ridge (HighCommander4)


Changes

Fixes https://github.com/clangd/clangd/issues/1951

---
Full diff: https://github.com/llvm/llvm-project/pull/83542.diff


3 Files Affected:

- (modified) clang-tools-extra/clangd/HeuristicResolver.cpp (+138-32) 
- (modified) clang-tools-extra/clangd/HeuristicResolver.h (-37) 
- (modified) clang-tools-extra/clangd/unittests/FindTargetTests.cpp (+10) 


``diff
diff --git a/clang-tools-extra/clangd/HeuristicResolver.cpp 
b/clang-tools-extra/clangd/HeuristicResolver.cpp
index 3c147b6b582bf0..26d54200eeffd2 100644
--- a/clang-tools-extra/clangd/HeuristicResolver.cpp
+++ b/clang-tools-extra/clangd/HeuristicResolver.cpp
@@ -16,6 +16,80 @@
 namespace clang {
 namespace clangd {
 
+namespace {
+
+// Helper class for implementing HeuristicResolver.
+// Unlike HeuristicResolver which is a long-lived class,
+// a new instance of this class is created for every external
+// call into a HeuristicResolver operation. That allows this
+// class to store state that's local to such a top-level call,
+// particularly "recursion protection sets" that keep track of
+// nodes that have already been seen to avoid infinite recursion.
+class HeuristicResolverImpl {
+public:
+  HeuristicResolverImpl(ASTContext &Ctx) : Ctx(Ctx) {}
+
+  // These functions match the public interface of HeuristicResolver
+  // (but aren't const since they may modify the recursion protection sets).
+  std::vector
+  resolveMemberExpr(const CXXDependentScopeMemberExpr *ME);
+  std::vector
+  resolveDeclRefExpr(const DependentScopeDeclRefExpr *RE);
+  std::vector resolveTypeOfCallExpr(const CallExpr *CE);
+  std::vector resolveCalleeOfCallExpr(const CallExpr *CE);
+  std::vector
+  resolveUsingValueDecl(const UnresolvedUsingValueDecl *UUVD);
+  std::vector
+  resolveDependentNameType(const DependentNameType *DNT);
+  std::vector resolveTemplateSpecializationType(
+  const DependentTemplateSpecializationType *DTST);
+  const Type *resolveNestedNameSpecifierToType(const NestedNameSpecifier *NNS);
+  const Type *getPointeeType(const Type *T);
+
+private:
+  ASTContext &Ctx;
+
+  // Recursion protection sets
+  llvm::SmallSet SeenDependentNameTypes;
+
+  // Given a tag-decl type and a member name, heuristically resolve the
+  // name to one or more declarations.
+  // The current heuristic is simply to look up the name in the primary
+  // template. This is a heuristic because the template could potentially
+  // have specializations that declare different members.
+  // Multiple declarations could be returned if the name is overloaded
+  // (e.g. an overloaded method in the primary template).
+  // This heuristic will give the desired answer in many cases, e.g.
+  // for a call to vector::size().
+  std::vector
+  resolveDependentMember(const Type *T, DeclarationName Name,
+ llvm::function_ref Filter);
+
+  // Try to heuristically resolve the type of a possibly-dependent expression
+  // `E`.
+  const Type *resolveExprToType(const Expr *E);
+  std::vector resolveExprToDecls(const Expr *E);
+
+  // Helper function for HeuristicResolver::resolveDependentMember()
+  // which takes a possibly-dependent type `T` and heuristically
+  // resolves it to a CXXRecordDecl in which we can try name lookup.
+  CXXRecordDecl *resolveTypeToRecordDecl(const Type *T);
+
+  // This is a reimplementation of CXXRecordDecl::lookupDependentName()
+  // so that the implementation can call into other HeuristicResolver helpers.
+  // FIXME: Once HeuristicResolver is upstreamed to the clang libraries
+  // (https://github.com/clangd/clangd/discussions/1662),
+  // CXXRecordDecl::lookupDepenedentName() can be removed, and its call sites
+  // can be modified to benefit from the more comprehensive heuristics offered
+  // by HeuristicResolver instead.
+  std::vector
+  lookupDependentName(CXXRecordDecl *RD, DeclarationName Name,
+  llvm::function_ref Filter);
+  bool findOrdinaryMemberInDependentClasses(const CXXBaseSpecifier *Specifier,
+CXXBasePath &Path,
+DeclarationName Name);
+};
+
 // Convenience lambdas for use as the 'Filter' parameter of
 // HeuristicResolver::resolveDependentMember().
 const auto NoFilter = [](const NamedDecl *D) { return true; };
@@ -31,8 +105,6 @@ const auto TemplateFilter = [](const NamedDecl *D) {
   return isa(D);
 };
 
-namespace {
-
 const Type *resolveDeclsToType(const std::vector &Decls,
ASTContext &Ctx) {
   if (Decls.size() != 1) // Names an overload set -- just bail.
@@ -46,12 +118,10 @@ const Type *resolveDeclsToType(const std::vector &Decls,
   return nullptr;
 }
 
-} // namespace
-
 // Helper function for HeuristicResolver::resolveDependentMember()
 // which takes a possibly-dependent type `T` and heuristically
 // resolves it to a CXXRecordDecl in which we can try name lookup.

[clang] [llvm] [RISCV] Support RISC-V Profiles in -march option (PR #76357)

2024-03-01 Thread Yingwei Zheng via cfe-commits


@@ -839,6 +860,33 @@ RISCVISAInfo::parseArchString(StringRef Arch, bool 
EnableExperimentalExtension,
  "string must be lowercase");
   }
 
+  bool IsProfile = Arch.starts_with("rvi") || Arch.starts_with("rva") ||
+   Arch.starts_with("rvb") || Arch.starts_with("rvm");

dtcxzyw wrote:

> profile-name ::= 
> "RV"``
> profile-family-name ::= "I" | "M" | "A"

Missing tests for `rvm`.
Do you know what "rvb" stands for?


https://github.com/llvm/llvm-project/pull/76357
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 40c9a01 - [clang][Interp][NFC] Add an assertion to classify(Expr*)

2024-03-01 Thread Timm Bäder via cfe-commits

Author: Timm Bäder
Date: 2024-03-01T09:47:54+01:00
New Revision: 40c9a01773507e485f35aa76d3e31cf3ea8c3011

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

LOG: [clang][Interp][NFC] Add an assertion to classify(Expr*)

NFC but makes the backtrace easier to read in case the expression
somehow ends up being null.

Added: 


Modified: 
clang/lib/AST/Interp/Context.h

Removed: 




diff  --git a/clang/lib/AST/Interp/Context.h b/clang/lib/AST/Interp/Context.h
index c7620921e467e7..dbb63e36918161 100644
--- a/clang/lib/AST/Interp/Context.h
+++ b/clang/lib/AST/Interp/Context.h
@@ -75,6 +75,7 @@ class Context final {
 
   /// Classifies an expression.
   std::optional classify(const Expr *E) const {
+assert(E);
 if (E->isGLValue()) {
   if (E->getType()->isFunctionType())
 return PT_FnPtr;



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


[clang] [cfi][CodeGen] Call SetLLVMFunctionAttributes{, ForDefinition} on __cf… (PR #78253)

2024-03-01 Thread John McCall via cfe-commits

https://github.com/rjmccall approved this pull request.

LGTM

https://github.com/llvm/llvm-project/pull/78253
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [openmp] [OpenMP] Respect LLVM per-target install directories (PR #83282)

2024-03-01 Thread Björn Pettersson via cfe-commits

bjope wrote:

Hi @jhuber6, @MaskRay 

We are having some problems with this patch on a server where the file 
/lib64/libomptarget-nvptx-sm_52.bc exists.
The test case that fails is clang/test/Driver/openmp-offload-gpu.c.

**Problem 1**
I think one problem is related to this check line
`// CHK-ENV-BCLIB: 
clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}subdir{{/|}}libomptarget-nvptx-sm_52.bc
`
That test is using `env LIBRARY_PATH` but your changes in 
`tools::addOpenMPDeviceRTL` makes it prioritize the standard library paths 
before the environment. Not sure if that is how it should be or if env should 
have higher prio (i.e. added to LibraryPaths before the paths found in HostTC).

**Problem 2**
This check line also started failing:
`// CHK-BCLIB-WARN: no library 'libomptarget-nvptx-sm_52.bc' found in the 
default clang lib directory or in LIBRARY_PATH; use 
'--libomptarget-nvptx-bc-path' to specify nvptx bitcode library
`

Now, with your path, I guess it starts picking up the 
`/lib64/libomptarget-nvptx-sm_52.bc` file from the system. So we no longer get 
the warning. Is that the intention with your patch? Regardless, I think you 
need to do something with that test case because I think the "should never 
exist" part in
```
/// Check that the warning is thrown when the libomptarget bitcode library is 
not found.
/// Libomptarget requires sm_52 or newer so an sm_52 bitcode library should 
never exist.
```
no longer holds with your patch.

https://github.com/llvm/llvm-project/pull/83282
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] e81ef46 - [FMV] Use lexicographic order of feature names when mangling. (#83464)

2024-03-01 Thread via cfe-commits

Author: Alexandros Lamprineas
Date: 2024-03-01T09:10:06Z
New Revision: e81ef463f10851bfbcd56a4f3450821f1e7c862f

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

LOG: [FMV] Use lexicographic order of feature names when mangling. (#83464)

This decouples feature priorities from name mangling. Doing so will
prevent ABI breakages in case we change the feature priorities.
Formalized in ACLE here: https://github.com/ARM-software/acle/pull/303.

Added: 


Modified: 
clang/lib/CodeGen/Targets/AArch64.cpp
clang/test/CodeGen/attr-target-clones-aarch64.c
clang/test/CodeGen/attr-target-version.c
clang/test/CodeGenCXX/attr-target-clones-aarch64.cpp
clang/test/CodeGenCXX/attr-target-version.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/Targets/AArch64.cpp 
b/clang/lib/CodeGen/Targets/AArch64.cpp
index 2b8e2aeb4265f3..79a9c1d5978a14 100644
--- a/clang/lib/CodeGen/Targets/AArch64.cpp
+++ b/clang/lib/CodeGen/Targets/AArch64.cpp
@@ -882,13 +882,9 @@ void AArch64ABIInfo::appendAttributeMangling(StringRef 
AttrStr,
   for (auto &Feat : Features)
 Feat = Feat.trim();
 
-  // FIXME: It was brought up in #79316 that sorting the features which are
-  // used for mangling based on their multiversion priority is not a good
-  // practice. Changing the feature priorities will break the ABI. Perhaps
-  // it would be preferable to perform a lexicographical sort instead.
   const TargetInfo &TI = CGT.getTarget();
   llvm::sort(Features, [&TI](const StringRef LHS, const StringRef RHS) {
-return TI.multiVersionSortPriority(LHS) < TI.multiVersionSortPriority(RHS);
+return LHS.compare(RHS) < 0;
   });
 
   for (auto &Feat : Features)

diff  --git a/clang/test/CodeGen/attr-target-clones-aarch64.c 
b/clang/test/CodeGen/attr-target-clones-aarch64.c
index 5ea3f4a9b0b112..276a7b87b7a1b4 100644
--- a/clang/test/CodeGen/attr-target-clones-aarch64.c
+++ b/clang/test/CodeGen/attr-target-clones-aarch64.c
@@ -43,7 +43,7 @@ inline int __attribute__((target_clones("fp16", 
"sve2-bitperm+fcma", "default"))
 // CHECK: @ftc_inline3 = weak_odr ifunc i32 (), ptr @ftc_inline3.resolver
 //.
 // CHECK: Function Attrs: noinline nounwind optnone
-// CHECK-LABEL: @ftc._MlseMaes(
+// CHECK-LABEL: @ftc._MaesMlse(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:ret i32 0
 //
@@ -69,7 +69,7 @@ inline int __attribute__((target_clones("fp16", 
"sve2-bitperm+fcma", "default"))
 // CHECK-NEXT:[[TMP3:%.*]] = and i1 true, [[TMP2]]
 // CHECK-NEXT:br i1 [[TMP3]], label [[RESOLVER_RETURN:%.*]], label 
[[RESOLVER_ELSE:%.*]]
 // CHECK:   resolver_return:
-// CHECK-NEXT:ret ptr @ftc._MlseMaes
+// CHECK-NEXT:ret ptr @ftc._MaesMlse
 // CHECK:   resolver_else:
 // CHECK-NEXT:[[TMP4:%.*]] = load i64, ptr @__aarch64_cpu_features, align 8
 // CHECK-NEXT:[[TMP5:%.*]] = and i64 [[TMP4]], 68719476736
@@ -89,7 +89,7 @@ inline int __attribute__((target_clones("fp16", 
"sve2-bitperm+fcma", "default"))
 //
 //
 // CHECK: Function Attrs: noinline nounwind optnone
-// CHECK-LABEL: @ftc_def._Msha2Mmemtag2(
+// CHECK-LABEL: @ftc_def._Mmemtag2Msha2(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:ret i32 1
 //
@@ -109,7 +109,7 @@ inline int __attribute__((target_clones("fp16", 
"sve2-bitperm+fcma", "default"))
 // CHECK-NEXT:[[TMP3:%.*]] = and i1 true, [[TMP2]]
 // CHECK-NEXT:br i1 [[TMP3]], label [[RESOLVER_RETURN:%.*]], label 
[[RESOLVER_ELSE:%.*]]
 // CHECK:   resolver_return:
-// CHECK-NEXT:ret ptr @ftc_def._Msha2Mmemtag2
+// CHECK-NEXT:ret ptr @ftc_def._Mmemtag2Msha2
 // CHECK:   resolver_else:
 // CHECK-NEXT:[[TMP4:%.*]] = load i64, ptr @__aarch64_cpu_features, align 8
 // CHECK-NEXT:[[TMP5:%.*]] = and i64 [[TMP4]], 4096
@@ -155,7 +155,7 @@ inline int __attribute__((target_clones("fp16", 
"sve2-bitperm+fcma", "default"))
 //
 //
 // CHECK: Function Attrs: noinline nounwind optnone
-// CHECK-LABEL: @ftc_dup2._MdotprodMcrc(
+// CHECK-LABEL: @ftc_dup2._McrcMdotprod(
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:ret i32 3
 //
@@ -175,7 +175,7 @@ inline int __attribute__((target_clones("fp16", 
"sve2-bitperm+fcma", "default"))
 // CHECK-NEXT:[[TMP3:%.*]] = and i1 true, [[TMP2]]
 // CHECK-NEXT:br i1 [[TMP3]], label [[RESOLVER_RETURN:%.*]], label 
[[RESOLVER_ELSE:%.*]]
 // CHECK:   resolver_return:
-// CHECK-NEXT:ret ptr @ftc_dup2._MdotprodMcrc
+// CHECK-NEXT:ret ptr @ftc_dup2._McrcMdotprod
 // CHECK:   resolver_else:
 // CHECK-NEXT:[[TMP4:%.*]] = load i64, ptr @__aarch64_cpu_features, align 8
 // CHECK-NEXT:[[TMP5:%.*]] = and i64 [[TMP4]], 256
@@ -239,7 +239,7 @@ inline int __attribute__((target_clones("fp16", 
"sve2-bitperm+fcma", "default"))
 // CHECK-NEXT:[[TMP7:%.*]] = and i1 true, [[TMP6]]
 // CHECK-NEXT:br i1 [[TMP7]], label [[RESOLVER_RE

[clang] [FMV] Use lexicographic order of feature names when mangling. (PR #83464)

2024-03-01 Thread Alexandros Lamprineas via cfe-commits

https://github.com/labrinea closed 
https://github.com/llvm/llvm-project/pull/83464
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 990dbf2 - [clang][Interp] OpaqueValueExprs can have null subexprs

2024-03-01 Thread Timm Bäder via cfe-commits

Author: Timm Bäder
Date: 2024-03-01T10:12:50+01:00
New Revision: 990dbf2b7ebb1ddf1a53eb0b25061a0ea42f4ae1

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

LOG: [clang][Interp] OpaqueValueExprs can have null subexprs

Added: 


Modified: 
clang/lib/AST/Interp/ByteCodeExprGen.cpp

Removed: 




diff  --git a/clang/lib/AST/Interp/ByteCodeExprGen.cpp 
b/clang/lib/AST/Interp/ByteCodeExprGen.cpp
index 122b9045a75f6e..0185214fb455de 100644
--- a/clang/lib/AST/Interp/ByteCodeExprGen.cpp
+++ b/clang/lib/AST/Interp/ByteCodeExprGen.cpp
@@ -1220,14 +1220,18 @@ bool ByteCodeExprGen::VisitArrayInitLoopExpr(
 
 template 
 bool ByteCodeExprGen::VisitOpaqueValueExpr(const OpaqueValueExpr *E) {
+  const Expr *SourceExpr = E->getSourceExpr();
+  if (!SourceExpr)
+return false;
+
   if (Initializing)
-return this->visitInitializer(E->getSourceExpr());
+return this->visitInitializer(SourceExpr);
 
-  PrimType SubExprT = classify(E->getSourceExpr()).value_or(PT_Ptr);
+  PrimType SubExprT = classify(SourceExpr).value_or(PT_Ptr);
   if (auto It = OpaqueExprs.find(E); It != OpaqueExprs.end())
 return this->emitGetLocal(SubExprT, It->second, E);
 
-  if (!this->visit(E->getSourceExpr()))
+  if (!this->visit(SourceExpr))
 return false;
 
   // At this point we either have the evaluated source expression or a pointer



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


[clang] [analyzer] Improve some comments in ArrayBoundCheckerV2 (NFC) (PR #83545)

2024-03-01 Thread via cfe-commits
=?utf-8?q?Donát?= Nagy 
Message-ID: 
In-Reply-To:


https://github.com/NagyDonat created 
https://github.com/llvm/llvm-project/pull/83545

This comment-only change fixes a typo, clarifies some comments and includes 
some thoughts about the difficulties in resolving a certain FIXME.

>From b15b88d1449d81e23629d79c914e80a4ee9e19eb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?= 
Date: Fri, 1 Mar 2024 09:57:26 +0100
Subject: [PATCH 1/2] [analyzer] Fix a typo in a comment in ArrayBoundCheckerV2
 (NFC)

...which was introduced by one of my recent commits.
---
 clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp 
b/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp
index fdcc46e58580b4..65aad35315976c 100644
--- a/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp
@@ -304,7 +304,7 @@ compareValueToThreshold(ProgramStateRef State, NonLoc 
Value, NonLoc Threshold,
   // negative_value == unsigned_value is always false
   return {nullptr, State};
 }
-// negative_value < unsigned_value is always false
+// negative_value < unsigned_value is always true
 return {State, nullptr};
   }
   if (isUnsigned(SVB, Value) && isNegative(SVB, State, Threshold)) {

>From 467b9c6094018efead1981d607b67dfa174ca969 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?= 
Date: Fri, 1 Mar 2024 10:17:20 +0100
Subject: [PATCH 2/2] [analyzer] Improve some comments in ArrayBoundCheckerV2
 (NFC)

To clarify them and include some thoughts about the difficulties in
resolving a certain FIXME.
---
 .../Checkers/ArrayBoundCheckerV2.cpp | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp 
b/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp
index 65aad35315976c..29eb932584027d 100644
--- a/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp
@@ -301,21 +301,27 @@ compareValueToThreshold(ProgramStateRef State, NonLoc 
Value, NonLoc Threshold,
   // calling `evalBinOpNN`:
   if (isNegative(SVB, State, Value) && isUnsigned(SVB, Threshold)) {
 if (CheckEquality) {
-  // negative_value == unsigned_value is always false
+  // negative_value == unsigned_threshold is always false
   return {nullptr, State};
 }
-// negative_value < unsigned_value is always true
+// negative_value < unsigned_threshold is always true
 return {State, nullptr};
   }
   if (isUnsigned(SVB, Value) && isNegative(SVB, State, Threshold)) {
-// unsigned_value == negative_value and unsigned_value < negative_value are
-// both always false
+// unsigned_value == negative_threshold and
+// unsigned_value < negative_threshold are both always false
 return {nullptr, State};
   }
-  // FIXME: these special cases are sufficient for handling real-world
+  // FIXME: These special cases are sufficient for handling real-world
   // comparisons, but in theory there could be contrived situations where
   // automatic conversion of a symbolic value (which can be negative and can be
   // positive) leads to incorrect results.
+  // NOTE: We NEED to use the `evalBinOpNN` call in the "common" case, because
+  // we want to ensure that assumptions coming from this precondition and
+  // assumptions coming from regular C/C++ operator calls are represented by
+  // constraints on the same symbolic expression. A solution that would
+  // evaluate these "mathematical" compariosns through a separate pathway would
+  // be a step backwards in this sense.
 
   const BinaryOperatorKind OpKind = CheckEquality ? BO_EQ : BO_LT;
   auto BelowThreshold =

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


[clang] [analyzer] Improve some comments in ArrayBoundCheckerV2 (NFC) (PR #83545)

2024-03-01 Thread via cfe-commits
=?utf-8?q?Donát?= Nagy 
Message-ID:
In-Reply-To: 


llvmbot wrote:




@llvm/pr-subscribers-clang-static-analyzer-1

Author: None (NagyDonat)


Changes

This comment-only change fixes a typo, clarifies some comments and includes 
some thoughts about the difficulties in resolving a certain FIXME.

---
Full diff: https://github.com/llvm/llvm-project/pull/83545.diff


1 Files Affected:

- (modified) clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp (+11-5) 


``diff
diff --git a/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp 
b/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp
index fdcc46e58580b4..29eb932584027d 100644
--- a/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp
@@ -301,21 +301,27 @@ compareValueToThreshold(ProgramStateRef State, NonLoc 
Value, NonLoc Threshold,
   // calling `evalBinOpNN`:
   if (isNegative(SVB, State, Value) && isUnsigned(SVB, Threshold)) {
 if (CheckEquality) {
-  // negative_value == unsigned_value is always false
+  // negative_value == unsigned_threshold is always false
   return {nullptr, State};
 }
-// negative_value < unsigned_value is always false
+// negative_value < unsigned_threshold is always true
 return {State, nullptr};
   }
   if (isUnsigned(SVB, Value) && isNegative(SVB, State, Threshold)) {
-// unsigned_value == negative_value and unsigned_value < negative_value are
-// both always false
+// unsigned_value == negative_threshold and
+// unsigned_value < negative_threshold are both always false
 return {nullptr, State};
   }
-  // FIXME: these special cases are sufficient for handling real-world
+  // FIXME: These special cases are sufficient for handling real-world
   // comparisons, but in theory there could be contrived situations where
   // automatic conversion of a symbolic value (which can be negative and can be
   // positive) leads to incorrect results.
+  // NOTE: We NEED to use the `evalBinOpNN` call in the "common" case, because
+  // we want to ensure that assumptions coming from this precondition and
+  // assumptions coming from regular C/C++ operator calls are represented by
+  // constraints on the same symbolic expression. A solution that would
+  // evaluate these "mathematical" compariosns through a separate pathway would
+  // be a step backwards in this sense.
 
   const BinaryOperatorKind OpKind = CheckEquality ? BO_EQ : BO_LT;
   auto BelowThreshold =

``




https://github.com/llvm/llvm-project/pull/83545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Improve some comments in ArrayBoundCheckerV2 (NFC) (PR #83545)

2024-03-01 Thread via cfe-commits
=?utf-8?q?Donát?= Nagy 
Message-ID:
In-Reply-To: 


llvmbot wrote:




@llvm/pr-subscribers-clang

Author: None (NagyDonat)


Changes

This comment-only change fixes a typo, clarifies some comments and includes 
some thoughts about the difficulties in resolving a certain FIXME.

---
Full diff: https://github.com/llvm/llvm-project/pull/83545.diff


1 Files Affected:

- (modified) clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp (+11-5) 


``diff
diff --git a/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp 
b/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp
index fdcc46e58580b4..29eb932584027d 100644
--- a/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp
@@ -301,21 +301,27 @@ compareValueToThreshold(ProgramStateRef State, NonLoc 
Value, NonLoc Threshold,
   // calling `evalBinOpNN`:
   if (isNegative(SVB, State, Value) && isUnsigned(SVB, Threshold)) {
 if (CheckEquality) {
-  // negative_value == unsigned_value is always false
+  // negative_value == unsigned_threshold is always false
   return {nullptr, State};
 }
-// negative_value < unsigned_value is always false
+// negative_value < unsigned_threshold is always true
 return {State, nullptr};
   }
   if (isUnsigned(SVB, Value) && isNegative(SVB, State, Threshold)) {
-// unsigned_value == negative_value and unsigned_value < negative_value are
-// both always false
+// unsigned_value == negative_threshold and
+// unsigned_value < negative_threshold are both always false
 return {nullptr, State};
   }
-  // FIXME: these special cases are sufficient for handling real-world
+  // FIXME: These special cases are sufficient for handling real-world
   // comparisons, but in theory there could be contrived situations where
   // automatic conversion of a symbolic value (which can be negative and can be
   // positive) leads to incorrect results.
+  // NOTE: We NEED to use the `evalBinOpNN` call in the "common" case, because
+  // we want to ensure that assumptions coming from this precondition and
+  // assumptions coming from regular C/C++ operator calls are represented by
+  // constraints on the same symbolic expression. A solution that would
+  // evaluate these "mathematical" compariosns through a separate pathway would
+  // be a step backwards in this sense.
 
   const BinaryOperatorKind OpKind = CheckEquality ? BO_EQ : BO_LT;
   auto BelowThreshold =

``




https://github.com/llvm/llvm-project/pull/83545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Headers][X86] Add rounding and exception notes to conversions (PR #83447)

2024-03-01 Thread Phoebe Wang via cfe-commits


@@ -2180,7 +2180,8 @@ _mm256_cvtepi32_pd(__m128i __a)
   return (__m256d)__builtin_convertvector((__v4si)__a, __v4df);
 }
 
-/// Converts a vector of [8 x i32] into a vector of [8 x float].
+/// Converts a vector of [8 x i32] into a vector of [8 x float]. Rounds inexact
+///results according to the rounding control bits in the MXCSR register.

phoebewang wrote:

I think we don't need to mention it. This is the default behavior if not 
mentioned otherwise.

https://github.com/llvm/llvm-project/pull/83447
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Headers][X86] Add rounding and exception notes to conversions (PR #83447)

2024-03-01 Thread Phoebe Wang via cfe-commits


@@ -2211,7 +2213,12 @@ _mm256_cvtpd_ps(__m256d __a)
   return (__m128)__builtin_ia32_cvtpd2ps256((__v4df) __a);
 }
 
-/// Converts a vector of [8 x float] into a vector of [8 x i32].
+/// Converts a vector of [8 x float] into a vector of [8 x i32]. Rounds inexact
+///results according to the rounding control bits in the MXCSR register.
+///
+///If a converted value is larger than the maximum possible result,

phoebewang wrote:

Not only larger than, considering the negative number.

https://github.com/llvm/llvm-project/pull/83447
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 6ed67ca - [clang] Remove unused-lambda-capture in AArch64.cpp (NFC)

2024-03-01 Thread Jie Fu via cfe-commits

Author: Jie Fu
Date: 2024-03-01T17:37:11+08:00
New Revision: 6ed67ca14cd05596a8253eeceb247d2743e00f6e

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

LOG: [clang] Remove unused-lambda-capture in AArch64.cpp (NFC)

llvm-project/clang/lib/CodeGen/Targets/AArch64.cpp:886:26:
error: lambda capture 'TI' is not used [-Werror,-Wunused-lambda-capture]
  886 |   llvm::sort(Features, [&TI](const StringRef LHS, const StringRef RHS) {
  | ~^~
1 error generated.

Added: 


Modified: 
clang/lib/CodeGen/Targets/AArch64.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/Targets/AArch64.cpp 
b/clang/lib/CodeGen/Targets/AArch64.cpp
index 79a9c1d5978a14..725e8a70fddfe6 100644
--- a/clang/lib/CodeGen/Targets/AArch64.cpp
+++ b/clang/lib/CodeGen/Targets/AArch64.cpp
@@ -882,8 +882,7 @@ void AArch64ABIInfo::appendAttributeMangling(StringRef 
AttrStr,
   for (auto &Feat : Features)
 Feat = Feat.trim();
 
-  const TargetInfo &TI = CGT.getTarget();
-  llvm::sort(Features, [&TI](const StringRef LHS, const StringRef RHS) {
+  llvm::sort(Features, [](const StringRef LHS, const StringRef RHS) {
 return LHS.compare(RHS) < 0;
   });
 



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


[clang] Don't do casting of atomic FP loads/stores in FE. (PR #83446)

2024-03-01 Thread Jonas Paulsson via cfe-commits


@@ -1410,13 +1414,14 @@ RValue 
AtomicInfo::ConvertIntToValueOrAtomic(llvm::Value *IntVal,
 auto *ValTy = AsValue
   ? CGF.ConvertTypeForMem(ValueTy)
   : getAtomicAddress().getElementType();
-if (ValTy->isIntegerTy()) {
-  assert(IntVal->getType() == ValTy && "Different integer types.");
-  return RValue::get(CGF.EmitFromMemory(IntVal, ValueTy));
+if (ValTy->isIntegerTy() || (!CastFP && ValTy->isIEEELikeFPTy())) {
+  assert((!ValTy->isIntegerTy() || Val->getType() == ValTy) &&
+ "Different integer types.");
+  return RValue::get(CGF.EmitFromMemory(Val, ValueTy));
 } else if (ValTy->isPointerTy())
-  return RValue::get(CGF.Builder.CreateIntToPtr(IntVal, ValTy));
-else if (llvm::CastInst::isBitCastable(IntVal->getType(), ValTy))
-  return RValue::get(CGF.Builder.CreateBitCast(IntVal, ValTy));
+  return RValue::get(CGF.Builder.CreateIntToPtr(Val, ValTy));
+else if (llvm::CastInst::isBitCastable(Val->getType(), ValTy))
+  return RValue::get(CGF.Builder.CreateBitCast(Val, ValTy));

JonPsson1 wrote:

As AtomicExpandPass doesn't do any casting of AtomicCmpXchg - at least 
currently - I think the other users of ConvertIntToValueOrAtomic() (which emit 
AtomicCmpXchg) need the current behavior.

https://github.com/llvm/llvm-project/pull/83446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [TargetParser][AArch64] Add alias for FEAT_RDM. (PR #80540)

2024-03-01 Thread Alexandros Lamprineas via cfe-commits

https://github.com/labrinea updated 
https://github.com/llvm/llvm-project/pull/80540

>From 6f1f4e18de7ebad5e090ea268f3f053562db444c Mon Sep 17 00:00:00 2001
From: Alexandros Lamprineas 
Date: Tue, 30 Jan 2024 11:17:55 +
Subject: [PATCH] [TargetParser][AArch64] Add alias for FEAT_RDM.

This patch allows using the name "rdma" as an alias for "rdm".
The name makes its way to target attributes as well as the
command line via the -march and -mcpu options. The motivation
was originally to support this in Function Multi Versioning
but it also makes sense to align with GCC on the command line.
---
 clang/docs/ReleaseNotes.rst   |  5 +
 clang/test/CodeGen/attr-target-version.c  | 12 ++--
 clang/test/Driver/aarch64-rdm.c   |  3 +++
 clang/test/Sema/attr-target-clones-aarch64.c  |  2 +-
 clang/test/SemaCXX/attr-target-version.cpp|  1 +
 .../llvm/TargetParser/AArch64TargetParser.h   | 13 -
 llvm/lib/TargetParser/AArch64TargetParser.cpp | 15 +--
 7 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index f44fef28b9f17f..530158dda66689 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -333,6 +333,11 @@ Arm and AArch64 Support
   improvements for most targets. We have not changed the default behavior for
   ARMv6, but may revisit that decision in the future. Users can restore the old
   behavior with -m[no-]unaligned-access.
+- An alias identifier (rdma) has been added for targeting the AArch64
+  Architecture Extension which uses Rounding Doubling Multiply Accumulate
+  instructions (rdm). The identifier is available on the command line as
+  a feature modifier for -march and -mcpu as well as via target attributes
+  like ``target_version`` or ``target_clones``.
 
 Android Support
 ^^^
diff --git a/clang/test/CodeGen/attr-target-version.c 
b/clang/test/CodeGen/attr-target-version.c
index ae97977a9144f6..56a42499d0a7ca 100644
--- a/clang/test/CodeGen/attr-target-version.c
+++ b/clang/test/CodeGen/attr-target-version.c
@@ -25,7 +25,7 @@ int foo() {
 }
 
 inline int __attribute__((target_version("sha1+pmull+f64mm"))) 
fmv_inline(void) { return 1; }
-inline int __attribute__((target_version("fp16+fcma+sme+ fp16 "))) 
fmv_inline(void) { return 2; }
+inline int __attribute__((target_version("fp16+fcma+rdma+sme+ fp16 "))) 
fmv_inline(void) { return 2; }
 inline int __attribute__((target_version("sha3+i8mm+f32mm"))) fmv_inline(void) 
{ return 12; }
 inline int __attribute__((target_version("dit+sve-ebf16"))) fmv_inline(void) { 
return 8; }
 inline int __attribute__((target_version("dpb+rcpc2 "))) fmv_inline(void) { 
return 6; }
@@ -261,12 +261,12 @@ int hoo(void) {
 // CHECK-NEXT:  resolver_entry:
 // CHECK-NEXT:call void @__init_cpu_features_resolver()
 // CHECK-NEXT:[[TMP0:%.*]] = load i64, ptr @__aarch64_cpu_features, align 8
-// CHECK-NEXT:[[TMP1:%.*]] = and i64 [[TMP0]], 4398048608256
-// CHECK-NEXT:[[TMP2:%.*]] = icmp eq i64 [[TMP1]], 4398048608256
+// CHECK-NEXT:[[TMP1:%.*]] = and i64 [[TMP0]], 4398048608320
+// CHECK-NEXT:[[TMP2:%.*]] = icmp eq i64 [[TMP1]], 4398048608320
 // CHECK-NEXT:[[TMP3:%.*]] = and i1 true, [[TMP2]]
 // CHECK-NEXT:br i1 [[TMP3]], label [[RESOLVER_RETURN:%.*]], label 
[[RESOLVER_ELSE:%.*]]
 // CHECK:   resolver_return:
-// CHECK-NEXT:ret ptr @fmv_inline._MfcmaMfp16Mfp16Msme
+// CHECK-NEXT:ret ptr @fmv_inline._MfcmaMfp16Mfp16MrdmMsme
 // CHECK:   resolver_else:
 // CHECK-NEXT:[[TMP4:%.*]] = load i64, ptr @__aarch64_cpu_features, align 8
 // CHECK-NEXT:[[TMP5:%.*]] = and i64 [[TMP4]], 864726312827224064
@@ -575,7 +575,7 @@ int hoo(void) {
 //
 //
 // CHECK: Function Attrs: noinline nounwind optnone
-// CHECK-LABEL: define {{[^@]+}}@fmv_inline._MfcmaMfp16Mfp16Msme
+// CHECK-LABEL: define {{[^@]+}}@fmv_inline._MfcmaMfp16Mfp16MrdmMsme
 // CHECK-SAME: () #[[ATTR13:[0-9]+]] {
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:ret i32 2
@@ -829,7 +829,7 @@ int hoo(void) {
 // CHECK: attributes #[[ATTR10]] = { noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-features"="+bf16,+fullfp16,+ls64,+sme,+sme2" }
 // CHECK: attributes #[[ATTR11]] = { noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-features"="+ccpp,+fullfp16,+ls64" }
 // CHECK: attributes #[[ATTR12]] = { noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-features"="+aes,+f64mm,+fp-armv8,+fullfp16,+ls64,+neon,+sve" }
-// CHECK: attributes #[[ATTR13]] = { noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-features"="+bf16,+complxnum,+fp-armv8,+fullfp16,+ls64,+neon,+sme" }
+// CHECK: attributes #[[ATTR13]] = { noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-feature

[clang] [clang] Better bitfield access units (PR #65742)

2024-03-01 Thread John McCall via cfe-commits

https://github.com/rjmccall commented:

I think using the existing information as a default is fine, but please 
continue to call the hook something like `hasCheapUnalignedAccess()` to 
preserve the intent, even if it always just calls the other hook.

https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Better bitfield access units (PR #65742)

2024-03-01 Thread John McCall via cfe-commits

https://github.com/rjmccall edited 
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Better bitfield access units (PR #65742)

2024-03-01 Thread John McCall via cfe-commits


@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() {
   : getStorageType(*Field),
   *Field));
   ++Field;
-} else {
-  ++Field;
 }
   }
 }
 
-void
-CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
-  RecordDecl::field_iterator FieldEnd) {
-  // Run stores the first element of the current run of bitfields.  FieldEnd is
-  // used as a special value to note that we don't have a current run.  A
-  // bitfield run is a contiguous collection of bitfields that can be stored in
-  // the same storage block.  Zero-sized bitfields and bitfields that would
-  // cross an alignment boundary break a run and start a new one.
-  RecordDecl::field_iterator Run = FieldEnd;
-  // Tail is the offset of the first bit off the end of the current run.  It's
-  // used to determine if the ASTRecordLayout is treating these two bitfields 
as
-  // contiguous.  StartBitOffset is offset of the beginning of the Run.
-  uint64_t StartBitOffset, Tail = 0;
+namespace {
+
+// A run of bitfields assigned to the same access unit -- the size of memory
+// loads & stores.
+class BitFieldAccessUnit {
+  RecordDecl::field_iterator Begin; // Field at start of this access unit.
+  RecordDecl::field_iterator End;   // Field just after this access unit.
+
+  CharUnits StartOffset; // Starting offset in the containing record.
+  CharUnits EndOffset;   // Finish offset (exclusive) in the containing record.
+
+  bool ContainsVolatile; // This access unit contains a volatile bitfield.
+
+public:
+  // End barrier constructor.
+  BitFieldAccessUnit(RecordDecl::field_iterator F, CharUnits Offset,
+ bool Volatile = false)
+  : Begin(F), End(F), StartOffset(Offset), EndOffset(Offset),
+ContainsVolatile(Volatile) {}
+
+  // Collect contiguous bitfields into an access unit.
+  BitFieldAccessUnit(RecordDecl::field_iterator FieldBegin,
+ RecordDecl::field_iterator FieldEnd,
+ const CGRecordLowering &CGRL);
+
+  // Compute the access unit following this one -- which might be a barrier at
+  // Limit.
+  BitFieldAccessUnit accumulateNextUnit(RecordDecl::field_iterator FieldEnd,
+CharUnits Limit,
+const CGRecordLowering &CGRL) const {
+return end() != FieldEnd ? BitFieldAccessUnit(end(), FieldEnd, CGRL)
+ : BitFieldAccessUnit(FieldEnd, Limit);
+  }
+  // Re-set the end of this unit if there is space before Probe starts.
+  void enlargeIfSpace(const BitFieldAccessUnit &Probe, CharUnits Offset) {
+if (Probe.getStartOffset() >= Offset) {
+  End = Probe.begin();
+  EndOffset = Offset;
+}
+  }
+
+public:
+  RecordDecl::field_iterator begin() const { return Begin; }
+  RecordDecl::field_iterator end() const { return End; }
+
+public:
+  // Accessors
+  CharUnits getSize() const { return EndOffset - StartOffset; }
+  CharUnits getStartOffset() const { return StartOffset; }
+  CharUnits getEndOffset() const { return EndOffset; }
+
+  // Predicates
+  bool isBarrier() const { return getSize().isZero(); }
+  bool hasVolatile() const { return ContainsVolatile; }
+
+  // Create the containing access unit and install the bitfields.
+  void installUnit(CGRecordLowering &CGRL) const {
+if (!isBarrier()) {
+  // Add the storage member for the access unit to the record. The
+  // bitfields get the offset of their storage but come afterward and 
remain
+  // there after a stable sort.
+  llvm::Type *Type = CGRL.getIntNType(CGRL.Context.toBits(getSize()));
+  CGRL.Members.push_back(CGRL.StorageInfo(getStartOffset(), Type));
+  for (auto F : *this)
+if (!F->isZeroLengthBitField(CGRL.Context))
+  CGRL.Members.push_back(CGRecordLowering::MemberInfo(
+  getStartOffset(), CGRecordLowering::MemberInfo::Field, nullptr,
+  F));
+}
+  }
+};
+
+// Create an access unit of contiguous bitfields.
+BitFieldAccessUnit::BitFieldAccessUnit(RecordDecl::field_iterator FieldBegin,
+   RecordDecl::field_iterator FieldEnd,
+   const CGRecordLowering &CGRL)
+: BitFieldAccessUnit(FieldBegin, CharUnits::Zero(),
+ FieldBegin->getType().isVolatileQualified()) {
+  assert(End != FieldEnd);
+
+  uint64_t StartBit = CGRL.getFieldBitOffset(*FieldBegin);
+  uint64_t BitSize = End->getBitWidthValue(CGRL.Context);
+  unsigned CharBits = CGRL.Context.getCharWidth();
+
+  assert(!(StartBit % CharBits) && "Not at start of char");
+
+  ++End;
+  if (BitSize ||
+  !(CGRL.Context.getTargetInfo().useZeroLengthBitfieldAlignment() ||
+CGRL.Context.getTargetInfo().useBitFieldTypeAlignment()))
+// The first field is not a (zero-width) barrier. Collect contiguous 
fields.
+for (; End != FieldEnd; ++End) {
+  uin

[clang] [clang] Better bitfield access units (PR #65742)

2024-03-01 Thread John McCall via cfe-commits


@@ -858,6 +861,10 @@ class TargetInfo : public TransferrableTargetInfo,
 return PointerWidth;
   }
 
+  /// Return true, iff unaligned accesses are a single instruction (rather than

rjmccall wrote:

```suggestion
  /// Return true iff unaligned accesses are a single instruction (rather than
```

https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Better bitfield access units (PR #65742)

2024-03-01 Thread John McCall via cfe-commits


@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() {
   : getStorageType(*Field),
   *Field));
   ++Field;
-} else {
-  ++Field;
 }
   }
 }
 
-void
-CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
-  RecordDecl::field_iterator FieldEnd) {
-  // Run stores the first element of the current run of bitfields.  FieldEnd is
-  // used as a special value to note that we don't have a current run.  A
-  // bitfield run is a contiguous collection of bitfields that can be stored in
-  // the same storage block.  Zero-sized bitfields and bitfields that would
-  // cross an alignment boundary break a run and start a new one.
-  RecordDecl::field_iterator Run = FieldEnd;
-  // Tail is the offset of the first bit off the end of the current run.  It's
-  // used to determine if the ASTRecordLayout is treating these two bitfields 
as
-  // contiguous.  StartBitOffset is offset of the beginning of the Run.
-  uint64_t StartBitOffset, Tail = 0;
+namespace {
+
+// A run of bitfields assigned to the same access unit -- the size of memory
+// loads & stores.
+class BitFieldAccessUnit {
+  RecordDecl::field_iterator Begin; // Field at start of this access unit.
+  RecordDecl::field_iterator End;   // Field just after this access unit.
+
+  CharUnits StartOffset; // Starting offset in the containing record.
+  CharUnits EndOffset;   // Finish offset (exclusive) in the containing record.
+
+  bool ContainsVolatile; // This access unit contains a volatile bitfield.
+
+public:
+  // End barrier constructor.
+  BitFieldAccessUnit(RecordDecl::field_iterator F, CharUnits Offset,
+ bool Volatile = false)
+  : Begin(F), End(F), StartOffset(Offset), EndOffset(Offset),
+ContainsVolatile(Volatile) {}
+
+  // Collect contiguous bitfields into an access unit.
+  BitFieldAccessUnit(RecordDecl::field_iterator FieldBegin,
+ RecordDecl::field_iterator FieldEnd,
+ const CGRecordLowering &CGRL);

rjmccall wrote:

The structure here is pretty weird to me.  This class seems to be mostly a 
helper class for breaking down the bit-field run into access units, but it's 
also a short-term representation of those access units?  If having a helper 
class for breaking the run is useful, let's separate that and have it generate 
these access units.

https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] d50dec6 - Fix MSVC "not all control paths return a value" warnings. NFC.

2024-03-01 Thread Simon Pilgrim via cfe-commits

Author: Simon Pilgrim
Date: 2024-03-01T09:57:09Z
New Revision: d50dec6f413ce1953bede94bdd11261b6684c7c4

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

LOG: Fix MSVC "not all control paths return a value" warnings. NFC.

Added: 


Modified: 
clang/include/clang/Basic/TargetInfo.h

Removed: 




diff  --git a/clang/include/clang/Basic/TargetInfo.h 
b/clang/include/clang/Basic/TargetInfo.h
index b94d13609c3dd2..7682f84e491c7b 100644
--- a/clang/include/clang/Basic/TargetInfo.h
+++ b/clang/include/clang/Basic/TargetInfo.h
@@ -1386,7 +1386,7 @@ class TargetInfo : public TransferrableTargetInfo,
   case LangOptions::SignReturnAddressScopeKind::All:
 return "all";
   }
-  assert(false && "Unexpected SignReturnAddressScopeKind");
+  llvm_unreachable("Unexpected SignReturnAddressScopeKind");
 }
 
 const char *getSignKeyStr() const {
@@ -1396,7 +1396,7 @@ class TargetInfo : public TransferrableTargetInfo,
   case LangOptions::SignReturnAddressKeyKind::BKey:
 return "b_key";
   }
-  assert(false && "Unexpected SignReturnAddressKeyKind");
+  llvm_unreachable("Unexpected SignReturnAddressKeyKind");
 }
   };
 



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


[clang] [clang-format] Enable again some operator tests (PR #83380)

2024-03-01 Thread via cfe-commits

https://github.com/rayroudc updated 
https://github.com/llvm/llvm-project/pull/83380

>From e1b4c152dc00cacdbc846f8dd7bf2ca5858115bd Mon Sep 17 00:00:00 2001
From: "C. Rayroud" 
Date: Mon, 26 Feb 2024 06:52:52 +
Subject: [PATCH] [clang-format] Enable again some operator tests

---
 clang/unittests/Format/FormatTest.cpp | 23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index d9752c73e34e79..fc367a7a5a8981 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -11159,10 +11159,8 @@ TEST_F(FormatTest, UnderstandsOverloadedOperators) {
   verifyFormat("void f() { a.operator*(b & b); }");
   verifyFormat("void f() { a->operator&(a * b); }");
   verifyFormat("void f() { NS::a.operator+(*b * *b); }");
-  // TODO: Calling an operator as a non-member function is hard to distinguish.
-  // https://llvm.org/PR50629
-  // verifyFormat("void f() { operator*(a & a); }");
-  // verifyFormat("void f() { operator&(a, b * b); }");
+  verifyFormat("void f() { operator*(a & a); }");
+  verifyFormat("void f() { operator&(a, b * b); }");
 
   verifyFormat("void f() { return operator()(x) * b; }");
   verifyFormat("void f() { return operator[](x) * b; }");
@@ -16551,9 +16549,8 @@ TEST_F(FormatTest, ConfigurableSpaceBeforeParens) {
   verifyFormat("static_assert (sizeof (char) == 1, \"Impossible!\");", Space);
   verifyFormat("int f () throw (Deprecated);", Space);
   verifyFormat("typedef void (*cb) (int);", Space);
-  // FIXME these tests regressed behaviour.
-  // verifyFormat("T A::operator() ();", Space);
-  // verifyFormat("X A::operator++ (T);", Space);
+  verifyFormat("T A::operator() ();", Space);
+  verifyFormat("X A::operator++ (T);", Space);
   verifyFormat("auto lambda = [] () { return 0; };", Space);
   verifyFormat("int x = int (y);", Space);
   verifyFormat("#define F(...) __VA_OPT__ (__VA_ARGS__)", Space);
@@ -16612,8 +16609,7 @@ TEST_F(FormatTest, ConfigurableSpaceBeforeParens) {
   verifyFormat("int f() throw (Deprecated);", SomeSpace);
   verifyFormat("typedef void (*cb) (int);", SomeSpace);
   verifyFormat("T A::operator()();", SomeSpace);
-  // FIXME these tests regressed behaviour.
-  // verifyFormat("X A::operator++ (T);", SomeSpace);
+  verifyFormat("X A::operator++ (T);", SomeSpace);
   verifyFormat("int x = int (y);", SomeSpace);
   verifyFormat("auto lambda = []() { return 0; };", SomeSpace);
 
@@ -16671,9 +16667,8 @@ TEST_F(FormatTest, ConfigurableSpaceBeforeParens) {
SpaceFuncDecl);
   verifyFormat("int f () throw(Deprecated);", SpaceFuncDecl);
   verifyFormat("typedef void (*cb)(int);", SpaceFuncDecl);
-  // FIXME these tests regressed behaviour.
-  // verifyFormat("T A::operator() ();", SpaceFuncDecl);
-  // verifyFormat("X A::operator++ (T);", SpaceFuncDecl);
+  verifyFormat("T A::operator()();", SpaceFuncDecl);
+  verifyFormat("X A::operator++(T);", SpaceFuncDecl);
   verifyFormat("T A::operator()() {}", SpaceFuncDecl);
   verifyFormat("auto lambda = []() { return 0; };", SpaceFuncDecl);
   verifyFormat("int x = int(y);", SpaceFuncDecl);
@@ -16710,7 +16705,7 @@ TEST_F(FormatTest, ConfigurableSpaceBeforeParens) {
   verifyFormat("typedef void (*cb)(int);", SpaceFuncDef);
   verifyFormat("T A::operator()();", SpaceFuncDef);
   verifyFormat("X A::operator++(T);", SpaceFuncDef);
-  // verifyFormat("T A::operator() () {}", SpaceFuncDef);
+  verifyFormat("T A::operator()() {}", SpaceFuncDef);
   verifyFormat("auto lambda = [] () { return 0; };", SpaceFuncDef);
   verifyFormat("int x = int(y);", SpaceFuncDef);
   verifyFormat("M(std::size_t R, std::size_t C) : C(C), data(R) {}",
@@ -16797,7 +16792,7 @@ TEST_F(FormatTest, ConfigurableSpaceBeforeParens) {
   verifyFormat("int f() throw (Deprecated);", SomeSpace2);
   verifyFormat("typedef void (*cb) (int);", SomeSpace2);
   verifyFormat("T A::operator()();", SomeSpace2);
-  // verifyFormat("X A::operator++ (T);", SomeSpace2);
+  verifyFormat("X A::operator++ (T);", SomeSpace2);
   verifyFormat("int x = int (y);", SomeSpace2);
   verifyFormat("auto lambda = []() { return 0; };", SomeSpace2);
 

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


[clang] [clang] Remove unused lambda capture. (PR #83550)

2024-03-01 Thread Alexandros Lamprineas via cfe-commits

https://github.com/labrinea created 
https://github.com/llvm/llvm-project/pull/83550

Fixes the `sanitizer-x86_64-linux-android` buildbot.

>From df67789e087ff560d39b038f7073b3ae90061ff2 Mon Sep 17 00:00:00 2001
From: Alexandros Lamprineas 
Date: Fri, 1 Mar 2024 09:59:51 +
Subject: [PATCH] [clang] Remove unused lambda capture.

Fixes the `sanitizer-x86_64-linux-android` buildbot.
---
 clang/lib/CodeGen/Targets/AArch64.cpp | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/clang/lib/CodeGen/Targets/AArch64.cpp 
b/clang/lib/CodeGen/Targets/AArch64.cpp
index 79a9c1d5978a14..725e8a70fddfe6 100644
--- a/clang/lib/CodeGen/Targets/AArch64.cpp
+++ b/clang/lib/CodeGen/Targets/AArch64.cpp
@@ -882,8 +882,7 @@ void AArch64ABIInfo::appendAttributeMangling(StringRef 
AttrStr,
   for (auto &Feat : Features)
 Feat = Feat.trim();
 
-  const TargetInfo &TI = CGT.getTarget();
-  llvm::sort(Features, [&TI](const StringRef LHS, const StringRef RHS) {
+  llvm::sort(Features, [](const StringRef LHS, const StringRef RHS) {
 return LHS.compare(RHS) < 0;
   });
 

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


[clang] [clang] Remove unused lambda capture. (PR #83550)

2024-03-01 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-backend-aarch64

Author: Alexandros Lamprineas (labrinea)


Changes

Fixes the `sanitizer-x86_64-linux-android` buildbot.

---
Full diff: https://github.com/llvm/llvm-project/pull/83550.diff


1 Files Affected:

- (modified) clang/lib/CodeGen/Targets/AArch64.cpp (+1-2) 


``diff
diff --git a/clang/lib/CodeGen/Targets/AArch64.cpp 
b/clang/lib/CodeGen/Targets/AArch64.cpp
index 79a9c1d5978a14..725e8a70fddfe6 100644
--- a/clang/lib/CodeGen/Targets/AArch64.cpp
+++ b/clang/lib/CodeGen/Targets/AArch64.cpp
@@ -882,8 +882,7 @@ void AArch64ABIInfo::appendAttributeMangling(StringRef 
AttrStr,
   for (auto &Feat : Features)
 Feat = Feat.trim();
 
-  const TargetInfo &TI = CGT.getTarget();
-  llvm::sort(Features, [&TI](const StringRef LHS, const StringRef RHS) {
+  llvm::sort(Features, [](const StringRef LHS, const StringRef RHS) {
 return LHS.compare(RHS) < 0;
   });
 

``




https://github.com/llvm/llvm-project/pull/83550
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Remove unused lambda capture. (PR #83550)

2024-03-01 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang-codegen

Author: Alexandros Lamprineas (labrinea)


Changes

Fixes the `sanitizer-x86_64-linux-android` buildbot.

---
Full diff: https://github.com/llvm/llvm-project/pull/83550.diff


1 Files Affected:

- (modified) clang/lib/CodeGen/Targets/AArch64.cpp (+1-2) 


``diff
diff --git a/clang/lib/CodeGen/Targets/AArch64.cpp 
b/clang/lib/CodeGen/Targets/AArch64.cpp
index 79a9c1d5978a14..725e8a70fddfe6 100644
--- a/clang/lib/CodeGen/Targets/AArch64.cpp
+++ b/clang/lib/CodeGen/Targets/AArch64.cpp
@@ -882,8 +882,7 @@ void AArch64ABIInfo::appendAttributeMangling(StringRef 
AttrStr,
   for (auto &Feat : Features)
 Feat = Feat.trim();
 
-  const TargetInfo &TI = CGT.getTarget();
-  llvm::sort(Features, [&TI](const StringRef LHS, const StringRef RHS) {
+  llvm::sort(Features, [](const StringRef LHS, const StringRef RHS) {
 return LHS.compare(RHS) < 0;
   });
 

``




https://github.com/llvm/llvm-project/pull/83550
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Remove unused lambda capture. (PR #83550)

2024-03-01 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Alexandros Lamprineas (labrinea)


Changes

Fixes the `sanitizer-x86_64-linux-android` buildbot.

---
Full diff: https://github.com/llvm/llvm-project/pull/83550.diff


1 Files Affected:

- (modified) clang/lib/CodeGen/Targets/AArch64.cpp (+1-2) 


``diff
diff --git a/clang/lib/CodeGen/Targets/AArch64.cpp 
b/clang/lib/CodeGen/Targets/AArch64.cpp
index 79a9c1d5978a14..725e8a70fddfe6 100644
--- a/clang/lib/CodeGen/Targets/AArch64.cpp
+++ b/clang/lib/CodeGen/Targets/AArch64.cpp
@@ -882,8 +882,7 @@ void AArch64ABIInfo::appendAttributeMangling(StringRef 
AttrStr,
   for (auto &Feat : Features)
 Feat = Feat.trim();
 
-  const TargetInfo &TI = CGT.getTarget();
-  llvm::sort(Features, [&TI](const StringRef LHS, const StringRef RHS) {
+  llvm::sort(Features, [](const StringRef LHS, const StringRef RHS) {
 return LHS.compare(RHS) < 0;
   });
 

``




https://github.com/llvm/llvm-project/pull/83550
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] [clangd] Remove potential prefix from enum value names (PR #83412)

2024-03-01 Thread Christian Kandeler via cfe-commits

https://github.com/ckandeler updated 
https://github.com/llvm/llvm-project/pull/83412

>From 01f74ddece947755938ccecbcc5f9d18a41eb793 Mon Sep 17 00:00:00 2001
From: Christian Kandeler 
Date: Thu, 29 Feb 2024 12:26:52 +0100
Subject: [PATCH] [clangd] Remove potential prefix from enum value names

... when converting unscoped to scoped enums.
With traditional enums, a popular technique to guard against potential
name clashes is to use the enum name as a pseudo-namespace, like this:
  enum MyEnum { MyEnumValue1, MyEnumValue2 };
With scoped enums, this makes no sense, making it extremely unlikely
that the user wants to keep such a prefix when modernizing. Therefore, our
tweak now removes it.
---
 .../clangd/refactor/tweaks/ScopifyEnum.cpp| 53 +--
 .../unittests/tweaks/ScopifyEnumTests.cpp | 38 +++--
 2 files changed, 70 insertions(+), 21 deletions(-)

diff --git a/clang-tools-extra/clangd/refactor/tweaks/ScopifyEnum.cpp 
b/clang-tools-extra/clangd/refactor/tweaks/ScopifyEnum.cpp
index e36b3249bc7b92..8e13ae52d121a6 100644
--- a/clang-tools-extra/clangd/refactor/tweaks/ScopifyEnum.cpp
+++ b/clang-tools-extra/clangd/refactor/tweaks/ScopifyEnum.cpp
@@ -40,15 +40,12 @@ namespace {
 ///   void f() { E e1 = EV1; }
 ///
 /// After:
-///   enum class E { EV1, EV2 };
-///   void f() { E e1 = E::EV1; }
+///   enum class E { V1, V2 };
+///   void f() { E e1 = E::V1; }
 ///
 /// Note that the respective project code might not compile anymore
 /// if it made use of the now-gone implicit conversion to int.
 /// This is out of scope for this tweak.
-///
-/// TODO: In the above example, we could detect that the values
-///   start with the enum name, and remove that prefix.
 
 class ScopifyEnum : public Tweak {
   const char *id() const final;
@@ -63,7 +60,8 @@ class ScopifyEnum : public Tweak {
   std::function;
   llvm::Error addClassKeywordToDeclarations();
   llvm::Error scopifyEnumValues();
-  llvm::Error scopifyEnumValue(const EnumConstantDecl &CD, StringRef Prefix);
+  llvm::Error scopifyEnumValue(const EnumConstantDecl &CD, StringRef EnumName,
+   bool StripPrefix);
   llvm::Expected getContentForFile(StringRef FilePath);
   unsigned getOffsetFromPosition(const Position &Pos, StringRef Content) const;
   llvm::Error addReplacementForReference(const ReferencesResult::Reference 
&Ref,
@@ -125,25 +123,42 @@ llvm::Error ScopifyEnum::addClassKeywordToDeclarations() {
 }
 
 llvm::Error ScopifyEnum::scopifyEnumValues() {
-  std::string PrefixToInsert(D->getName());
-  PrefixToInsert += "::";
+  StringRef EnumName(D->getName());
+  bool StripPrefix = true;
+  for (auto E : D->enumerators()) {
+if (!E->getName().starts_with(EnumName)) {
+  StripPrefix = false;
+  break;
+}
+  }
   for (auto E : D->enumerators()) {
-if (auto Err = scopifyEnumValue(*E, PrefixToInsert))
+if (auto Err = scopifyEnumValue(*E, EnumName, StripPrefix))
   return Err;
   }
   return llvm::Error::success();
 }
 
 llvm::Error ScopifyEnum::scopifyEnumValue(const EnumConstantDecl &CD,
-  StringRef Prefix) {
+  StringRef EnumName,
+  bool StripPrefix) {
   for (const auto &Ref :
findReferences(*S->AST, getPosition(CD), 0, S->Index, false)
.References) {
-if (Ref.Attributes & ReferencesResult::Declaration)
+if (Ref.Attributes & ReferencesResult::Declaration) {
+  if (StripPrefix) {
+const auto MakeReplacement = [&EnumName](StringRef FilePath,
+ StringRef /* Content */,
+ unsigned Offset) {
+  return tooling::Replacement(FilePath, Offset, EnumName.size(), {});
+};
+if (auto Err = addReplacementForReference(Ref, MakeReplacement))
+  return Err;
+  }
   continue;
+}
 
-const auto MakeReplacement = [&Prefix](StringRef FilePath,
-   StringRef Content, unsigned Offset) 
{
+const auto MakeReplacement = [&](StringRef FilePath, StringRef Content,
+ unsigned Offset) {
   const auto IsAlreadyScoped = [Content, Offset] {
 if (Offset < 2)
   return false;
@@ -164,9 +179,15 @@ llvm::Error ScopifyEnum::scopifyEnumValue(const 
EnumConstantDecl &CD,
 }
 return false;
   };
-  return IsAlreadyScoped()
- ? tooling::Replacement()
- : tooling::Replacement(FilePath, Offset, 0, Prefix);
+  if (StripPrefix) {
+if (IsAlreadyScoped())
+  return tooling::Replacement(FilePath, Offset, EnumName.size(), {});
+return tooling::Replacement(FilePath, Offset + EnumName.size(), 0,
+"::");
+  }
+  return IsAlreadyScoped() ? tooling::Replacement()
+   :

[clang] 185b1df - [X86][AArch64][PowerPC] __builtin_cpu_supports accepts unknown options. (#83515)

2024-03-01 Thread via cfe-commits

Author: Pavel Iliin
Date: 2024-03-01T10:12:19Z
New Revision: 185b1df1b1f7bd88ff0159bc51d5ddaeca27106a

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

LOG: [X86][AArch64][PowerPC] __builtin_cpu_supports accepts unknown options. 
(#83515)

The patch fixes https://github.com/llvm/llvm-project/issues/83407
modifing __builtin_cpu_supports behaviour so that it returns false if
unsupported features names provided in parameter and issue a warning.
__builtin_cpu_supports is target independent, but currently supported by
X86, AArch64 and PowerPC only.

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/Sema/SemaChecking.cpp
clang/test/CodeGen/aarch64-cpu-supports.c
clang/test/Misc/warning-flags.c
clang/test/Sema/aarch64-cpu-supports.c
clang/test/Sema/builtin-cpu-supports.c

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 4f8902e37bd3bb..938de5859513f8 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -765,7 +765,7 @@ def err_builtin_redeclare : Error<"cannot redeclare builtin 
function %0">;
 def err_arm_invalid_specialreg : Error<"invalid special register for builtin">;
 def err_arm_invalid_coproc : Error<"coprocessor %0 must be configured as "
   "%select{GCP|CDE}1">;
-def err_invalid_cpu_supports : Error<"invalid cpu feature string for builtin">;
+def warn_invalid_cpu_supports : Warning<"invalid cpu feature string for 
builtin">;
 def err_invalid_cpu_is : Error<"invalid cpu name for builtin">;
 def err_invalid_cpu_specific_dispatch_value : Error<
 "invalid option '%0' for %select{cpu_specific|cpu_dispatch}1">;

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 98684448f4ff5c..e90014261217bc 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -13952,6 +13952,8 @@ Value *CodeGenFunction::EmitX86CpuIs(StringRef CPUStr) {
 Value *CodeGenFunction::EmitX86CpuSupports(const CallExpr *E) {
   const Expr *FeatureExpr = E->getArg(0)->IgnoreParenCasts();
   StringRef FeatureStr = cast(FeatureExpr)->getString();
+  if (!getContext().getTargetInfo().validateCpuSupports(FeatureStr))
+return Builder.getFalse();
   return EmitX86CpuSupports(FeatureStr);
 }
 
@@ -14041,6 +14043,8 @@ Value *CodeGenFunction::EmitAArch64CpuSupports(const 
CallExpr *E) {
   ArgStr.split(Features, "+");
   for (auto &Feature : Features) {
 Feature = Feature.trim();
+if (!llvm::AArch64::parseArchExtension(Feature))
+  return Builder.getFalse();
 if (Feature != "default")
   Features.push_back(Feature);
   }
@@ -16639,7 +16643,8 @@ Value *CodeGenFunction::EmitPPCBuiltinExpr(unsigned 
BuiltinID,
   .Case(Name, {FA_WORD, Bitmask})
 #include "llvm/TargetParser/PPCTargetParser.def"
 .Default({0, 0});
-assert(BitMask && "Invalid target feature string. Missed by 
SemaChecking?");
+if (!BitMask)
+  return Builder.getFalse();
 Value *Op0 = llvm::ConstantInt::get(Int32Ty, FeatureWord);
 llvm::Function *F = CGM.getIntrinsic(Intrinsic::ppc_fixed_addr_ld);
 Value *TheCall = Builder.CreateCall(F, {Op0}, "cpu_supports");

diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 690bdaa63d058b..7be2b31df2413f 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -2180,9 +2180,11 @@ static bool SemaBuiltinCpu(Sema &S, const TargetInfo 
&TI, CallExpr *TheCall,
 
   // Check the contents of the string.
   StringRef Feature = cast(Arg)->getString();
-  if (IsCPUSupports && !TheTI->validateCpuSupports(Feature))
-return S.Diag(TheCall->getBeginLoc(), diag::err_invalid_cpu_supports)
-   << Arg->getSourceRange();
+  if (IsCPUSupports && !TheTI->validateCpuSupports(Feature)) {
+S.Diag(TheCall->getBeginLoc(), diag::warn_invalid_cpu_supports)
+<< Arg->getSourceRange();
+return false;
+  }
   if (!IsCPUSupports && !TheTI->validateCpuIs(Feature))
 return S.Diag(TheCall->getBeginLoc(), diag::err_invalid_cpu_is)
<< Arg->getSourceRange();

diff  --git a/clang/test/CodeGen/aarch64-cpu-supports.c 
b/clang/test/CodeGen/aarch64-cpu-supports.c
index 872fec6827ef11..c54b7475a3fd5f 100644
--- a/clang/test/CodeGen/aarch64-cpu-supports.c
+++ b/clang/test/CodeGen/aarch64-cpu-supports.c
@@ -34,6 +34,11 @@
 // CHECK-NEXT:store i32 3, ptr [[RETVAL]], align 4
 // CHECK-NEXT:br label [[RETURN]]
 // CHECK:   if.end4:
+// CHECK-NEXT:br i1 false, label [[IF_THEN5:%.*]], label [[IF_END6:%.*]]
+// CHECK:   if.then5:
+// CHECK-NEXT:store i32 4, ptr [[RETVAL]], align 4
+// CHECK-NEXT

[clang] [X86][AArch64][PowerPC] __builtin_cpu_supports accepts unknown options. (PR #83515)

2024-03-01 Thread Pavel Iliin via cfe-commits

https://github.com/ilinpv closed https://github.com/llvm/llvm-project/pull/83515
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Remove unused lambda capture. (PR #83550)

2024-03-01 Thread Nikita Popov via cfe-commits

https://github.com/nikic approved this pull request.


https://github.com/llvm/llvm-project/pull/83550
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Remove unused lambda capture. (PR #83550)

2024-03-01 Thread Alexandros Lamprineas via cfe-commits

labrinea wrote:

Thanks for the quick respose!

https://github.com/llvm/llvm-project/pull/83550
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Don't do casting of atomic FP loads/stores in FE. (PR #83446)

2024-03-01 Thread Matt Arsenault via cfe-commits


@@ -1410,13 +1414,14 @@ RValue 
AtomicInfo::ConvertIntToValueOrAtomic(llvm::Value *IntVal,
 auto *ValTy = AsValue
   ? CGF.ConvertTypeForMem(ValueTy)
   : getAtomicAddress().getElementType();
-if (ValTy->isIntegerTy()) {
-  assert(IntVal->getType() == ValTy && "Different integer types.");
-  return RValue::get(CGF.EmitFromMemory(IntVal, ValueTy));
+if (ValTy->isIntegerTy() || (!CastFP && ValTy->isIEEELikeFPTy())) {
+  assert((!ValTy->isIntegerTy() || Val->getType() == ValTy) &&
+ "Different integer types.");
+  return RValue::get(CGF.EmitFromMemory(Val, ValueTy));
 } else if (ValTy->isPointerTy())
-  return RValue::get(CGF.Builder.CreateIntToPtr(IntVal, ValTy));
-else if (llvm::CastInst::isBitCastable(IntVal->getType(), ValTy))
-  return RValue::get(CGF.Builder.CreateBitCast(IntVal, ValTy));
+  return RValue::get(CGF.Builder.CreateIntToPtr(Val, ValTy));
+else if (llvm::CastInst::isBitCastable(Val->getType(), ValTy))
+  return RValue::get(CGF.Builder.CreateBitCast(Val, ValTy));

arsenm wrote:

https://github.com/llvm/llvm-project/blob/d1538c15f9c65a70f4650bd724972536f00f5094/llvm/lib/CodeGen/AtomicExpandPass.cpp#L256

It's wild how much junk clang ended up with to avoid writing proper backend 
support. It's fine to just do the FP in this patch, but I think all of this 
needs to be ripped out 

https://github.com/llvm/llvm-project/pull/83446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Don't do casting of atomic FP loads/stores in FE. (PR #83446)

2024-03-01 Thread Jonas Paulsson via cfe-commits


@@ -1410,13 +1414,14 @@ RValue 
AtomicInfo::ConvertIntToValueOrAtomic(llvm::Value *IntVal,
 auto *ValTy = AsValue
   ? CGF.ConvertTypeForMem(ValueTy)
   : getAtomicAddress().getElementType();
-if (ValTy->isIntegerTy()) {
-  assert(IntVal->getType() == ValTy && "Different integer types.");
-  return RValue::get(CGF.EmitFromMemory(IntVal, ValueTy));
+if (ValTy->isIntegerTy() || (!CastFP && ValTy->isIEEELikeFPTy())) {
+  assert((!ValTy->isIntegerTy() || Val->getType() == ValTy) &&
+ "Different integer types.");
+  return RValue::get(CGF.EmitFromMemory(Val, ValueTy));
 } else if (ValTy->isPointerTy())
-  return RValue::get(CGF.Builder.CreateIntToPtr(IntVal, ValTy));
-else if (llvm::CastInst::isBitCastable(IntVal->getType(), ValTy))
-  return RValue::get(CGF.Builder.CreateBitCast(IntVal, ValTy));
+  return RValue::get(CGF.Builder.CreateIntToPtr(Val, ValTy));
+else if (llvm::CastInst::isBitCastable(Val->getType(), ValTy))
+  return RValue::get(CGF.Builder.CreateBitCast(Val, ValTy));

JonPsson1 wrote:

Ah, I see, AtomicExpandPass is actually casting pointers to int, but not with 
the target hook to control it...

https://github.com/llvm/llvm-project/pull/83446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Don't do casting of atomic FP loads/stores in FE. (PR #83446)

2024-03-01 Thread Jonas Paulsson via cfe-commits

https://github.com/JonPsson1 edited 
https://github.com/llvm/llvm-project/pull/83446
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][RISCV] Reorder sema check for RVV type (PR #83553)

2024-03-01 Thread Brandon Wu via cfe-commits

https://github.com/4vtomat created 
https://github.com/llvm/llvm-project/pull/83553

Currently using the command `clang -cc1 -triple riscv64` to compile the
code below:
```
#include 
void foo() {
  vfloat64m1_t f64m1;
}
```
would get the error message "RISC-V type 'vfloat64m1_t' ... requires the 
'zve64x' extension"
which is supposed to be "RISC-V type 'vfloat64m1_t' ... requires the 'zve64d' 
extension".


>From 8ad3a883d29155dc26c79abdd57ea0f72d046dfc Mon Sep 17 00:00:00 2001
From: Brandon Wu 
Date: Fri, 1 Mar 2024 00:40:21 -0800
Subject: [PATCH] [clang][RISCV] Reorder sema check for RVV type

Currently using the command `clang -cc1 -triple riscv64` to compile the
code below:
```
#include 
void foo() {
  vfloat64m1_t f64m1;
}
```
would get the error message "RISC-V type 'vfloat64m1_t' ... requires the 
'zve64x' extension"
which is supposed to be "RISC-V type 'vfloat64m1_t' ... requires the 'zve64d' 
extension".
---
 clang/lib/Sema/SemaChecking.cpp | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 979b63884359fc..27ed6f2da05254 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -6332,9 +6332,12 @@ void Sema::checkRVVTypeSupport(QualType Ty, 
SourceLocation Loc, Decl *D) {
   unsigned EltSize = Context.getTypeSize(Info.ElementType);
   unsigned MinElts = Info.EC.getKnownMinValue();
 
+  if (Info.ElementType->isSpecificBuiltinType(BuiltinType::Double) &&
+   !TI.hasFeature("zve64d"))
+Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve64d";
   // (ELEN, LMUL) pairs of (8, mf8), (16, mf4), (32, mf2), (64, m1) requires at
   // least zve64x
-  if (((EltSize == 64 && Info.ElementType->isIntegerType()) || MinElts == 1) &&
+  else if (((EltSize == 64 && Info.ElementType->isIntegerType()) || MinElts == 
1) &&
   !TI.hasFeature("zve64x"))
 Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve64x";
   else if (Info.ElementType->isFloat16Type() && !TI.hasFeature("zvfh") &&
@@ -6347,9 +6350,6 @@ void Sema::checkRVVTypeSupport(QualType Ty, 
SourceLocation Loc, Decl *D) {
   else if (Info.ElementType->isSpecificBuiltinType(BuiltinType::Float) &&
!TI.hasFeature("zve32f"))
 Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve32f";
-  else if (Info.ElementType->isSpecificBuiltinType(BuiltinType::Double) &&
-   !TI.hasFeature("zve64d"))
-Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve64d";
   // Given that caller already checked isRVVType() before calling this 
function,
   // if we don't have at least zve32x supported, then we need to emit error.
   else if (!TI.hasFeature("zve32x"))

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


[clang] [clang][RISCV] Reorder sema check for RVV type (PR #83553)

2024-03-01 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Brandon Wu (4vtomat)


Changes

Currently using the command `clang -cc1 -triple riscv64` to compile the
code below:
```
#include 
void foo() {
  vfloat64m1_t f64m1;
}
```
would get the error message "RISC-V type 'vfloat64m1_t' ... requires the 
'zve64x' extension"
which is supposed to be "RISC-V type 'vfloat64m1_t' ... requires the 'zve64d' 
extension".


---
Full diff: https://github.com/llvm/llvm-project/pull/83553.diff


1 Files Affected:

- (modified) clang/lib/Sema/SemaChecking.cpp (+4-4) 


``diff
diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 979b63884359fc..27ed6f2da05254 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -6332,9 +6332,12 @@ void Sema::checkRVVTypeSupport(QualType Ty, 
SourceLocation Loc, Decl *D) {
   unsigned EltSize = Context.getTypeSize(Info.ElementType);
   unsigned MinElts = Info.EC.getKnownMinValue();
 
+  if (Info.ElementType->isSpecificBuiltinType(BuiltinType::Double) &&
+   !TI.hasFeature("zve64d"))
+Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve64d";
   // (ELEN, LMUL) pairs of (8, mf8), (16, mf4), (32, mf2), (64, m1) requires at
   // least zve64x
-  if (((EltSize == 64 && Info.ElementType->isIntegerType()) || MinElts == 1) &&
+  else if (((EltSize == 64 && Info.ElementType->isIntegerType()) || MinElts == 
1) &&
   !TI.hasFeature("zve64x"))
 Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve64x";
   else if (Info.ElementType->isFloat16Type() && !TI.hasFeature("zvfh") &&
@@ -6347,9 +6350,6 @@ void Sema::checkRVVTypeSupport(QualType Ty, 
SourceLocation Loc, Decl *D) {
   else if (Info.ElementType->isSpecificBuiltinType(BuiltinType::Float) &&
!TI.hasFeature("zve32f"))
 Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve32f";
-  else if (Info.ElementType->isSpecificBuiltinType(BuiltinType::Double) &&
-   !TI.hasFeature("zve64d"))
-Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve64d";
   // Given that caller already checked isRVVType() before calling this 
function,
   // if we don't have at least zve32x supported, then we need to emit error.
   else if (!TI.hasFeature("zve32x"))

``




https://github.com/llvm/llvm-project/pull/83553
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][RISCV] Reorder sema check for RVV type (PR #83553)

2024-03-01 Thread via cfe-commits

github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff 14d8c4563e045fc3da82cb7268b1066cfd1bb6f0 
8ad3a883d29155dc26c79abdd57ea0f72d046dfc -- clang/lib/Sema/SemaChecking.cpp
``





View the diff from clang-format here.


``diff
diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 27ed6f2da0..ae011806ee 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -6333,12 +6333,13 @@ void Sema::checkRVVTypeSupport(QualType Ty, 
SourceLocation Loc, Decl *D) {
   unsigned MinElts = Info.EC.getKnownMinValue();
 
   if (Info.ElementType->isSpecificBuiltinType(BuiltinType::Double) &&
-   !TI.hasFeature("zve64d"))
+  !TI.hasFeature("zve64d"))
 Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve64d";
   // (ELEN, LMUL) pairs of (8, mf8), (16, mf4), (32, mf2), (64, m1) requires at
   // least zve64x
-  else if (((EltSize == 64 && Info.ElementType->isIntegerType()) || MinElts == 
1) &&
-  !TI.hasFeature("zve64x"))
+  else if (((EltSize == 64 && Info.ElementType->isIntegerType()) ||
+MinElts == 1) &&
+   !TI.hasFeature("zve64x"))
 Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve64x";
   else if (Info.ElementType->isFloat16Type() && !TI.hasFeature("zvfh") &&
!TI.hasFeature("zvfhmin"))

``




https://github.com/llvm/llvm-project/pull/83553
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread Balázs Kéri via cfe-commits


@@ -27,20 +27,48 @@ class IdentifierInfo;
 
 namespace clang {
 namespace ento {
-
-enum CallDescriptionFlags : unsigned {
-  CDF_None = 0,
-
-  /// Describes a C standard function that is sometimes implemented as a macro
-  /// that expands to a compiler builtin with some __builtin prefix.
-  /// The builtin may as well have a few extra arguments on top of the 
requested
-  /// number of arguments.
-  CDF_MaybeBuiltin = 1 << 0,
-};
-
-/// This class represents a description of a function call using the number of
-/// arguments and the name of the function.
+/// A `CallDescription` is a pattern that can be used to _match_ calls
+/// based on the qualified name and the argument/parameter counts.
 class CallDescription {
+public:
+  enum class Mode {
+/// Match calls to functions from the C standard library. On some platforms
+/// some functions may be implemented as macros that expand to calls to
+/// built-in variants of the given functions, so in this mode we use some
+/// heuristics to recognize these implementation-defined variants:
+///  - We also accept calls where the name is derived from the specified
+///name by adding "__builtin" or similar prefixes/suffixes.
+///  - We also accept calls where the number of arguments or parameters is
+///greater than the specified value.
+/// For the exact heuristics, see CheckerContext::isCLibraryFunction().
+/// Note that functions whose declaration context is not a TU (e.g.
+/// methods, functions in namespaces) are not accepted as C library
+/// functions.
+/// FIXME: If I understand it correctly, this discards calls where C++ code

balazske wrote:

A FIXME comment should not be a documentation (only `//` comment).

https://github.com/llvm/llvm-project/pull/83432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread Balázs Kéri via cfe-commits

https://github.com/balazske edited 
https://github.com/llvm/llvm-project/pull/83432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread Balázs Kéri via cfe-commits


@@ -27,20 +27,48 @@ class IdentifierInfo;
 
 namespace clang {
 namespace ento {
-
-enum CallDescriptionFlags : unsigned {
-  CDF_None = 0,
-
-  /// Describes a C standard function that is sometimes implemented as a macro
-  /// that expands to a compiler builtin with some __builtin prefix.
-  /// The builtin may as well have a few extra arguments on top of the 
requested
-  /// number of arguments.
-  CDF_MaybeBuiltin = 1 << 0,
-};
-
-/// This class represents a description of a function call using the number of
-/// arguments and the name of the function.
+/// A `CallDescription` is a pattern that can be used to _match_ calls
+/// based on the qualified name and the argument/parameter counts.
 class CallDescription {
+public:
+  enum class Mode {
+/// Match calls to functions from the C standard library. On some platforms
+/// some functions may be implemented as macros that expand to calls to
+/// built-in variants of the given functions, so in this mode we use some
+/// heuristics to recognize these implementation-defined variants:
+///  - We also accept calls where the name is derived from the specified
+///name by adding "__builtin" or similar prefixes/suffixes.
+///  - We also accept calls where the number of arguments or parameters is
+///greater than the specified value.
+/// For the exact heuristics, see CheckerContext::isCLibraryFunction().
+/// Note that functions whose declaration context is not a TU (e.g.
+/// methods, functions in namespaces) are not accepted as C library
+/// functions.
+/// FIXME: If I understand it correctly, this discards calls where C++ code
+/// refers a C library function through the namespace `std::` via headers
+/// like .
+CLibrary,
+
+/// Matches "simple" functions that are not methods. (Static methods are
+/// methods.)
+SimpleFunc,
+
+/// Matches a C+ method (may be static, may be virtual, may be an
+/// overloaded operator, a constructor or a destructor).
+CXXMethod,
+
+/// Match any CallEvent that is not an ObjCMethodCall.
+/// FIXME: Previously this was the default behavior of CallDescription, but
+/// its use should be replaced by a more specific mode almost everywhere.
+Unspecified,

balazske wrote:

This could have a better name like "Any" (or an other), "Unspecified" can mean 
that it works in a default way.

https://github.com/llvm/llvm-project/pull/83432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread Balázs Kéri via cfe-commits


@@ -27,20 +27,48 @@ class IdentifierInfo;
 
 namespace clang {
 namespace ento {
-
-enum CallDescriptionFlags : unsigned {
-  CDF_None = 0,
-
-  /// Describes a C standard function that is sometimes implemented as a macro
-  /// that expands to a compiler builtin with some __builtin prefix.
-  /// The builtin may as well have a few extra arguments on top of the 
requested
-  /// number of arguments.
-  CDF_MaybeBuiltin = 1 << 0,
-};
-
-/// This class represents a description of a function call using the number of
-/// arguments and the name of the function.
+/// A `CallDescription` is a pattern that can be used to _match_ calls
+/// based on the qualified name and the argument/parameter counts.
 class CallDescription {
+public:
+  enum class Mode {
+/// Match calls to functions from the C standard library. On some platforms
+/// some functions may be implemented as macros that expand to calls to
+/// built-in variants of the given functions, so in this mode we use some
+/// heuristics to recognize these implementation-defined variants:
+///  - We also accept calls where the name is derived from the specified
+///name by adding "__builtin" or similar prefixes/suffixes.
+///  - We also accept calls where the number of arguments or parameters is
+///greater than the specified value.
+/// For the exact heuristics, see CheckerContext::isCLibraryFunction().
+/// Note that functions whose declaration context is not a TU (e.g.
+/// methods, functions in namespaces) are not accepted as C library
+/// functions.
+/// FIXME: If I understand it correctly, this discards calls where C++ code
+/// refers a C library function through the namespace `std::` via headers
+/// like .
+CLibrary,

balazske wrote:

`CLibrary` may not be the best name for this, because many functions that are 
"C library" calls are not matched with this mode. Probably `MaybeBuiltin` can 
remain for this mode. (It is another question if there are similar builtin 
things in C++ or special STL functions that we want to match.)

https://github.com/llvm/llvm-project/pull/83432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread Balázs Kéri via cfe-commits


@@ -27,20 +27,48 @@ class IdentifierInfo;
 
 namespace clang {
 namespace ento {
-
-enum CallDescriptionFlags : unsigned {
-  CDF_None = 0,
-
-  /// Describes a C standard function that is sometimes implemented as a macro
-  /// that expands to a compiler builtin with some __builtin prefix.
-  /// The builtin may as well have a few extra arguments on top of the 
requested
-  /// number of arguments.
-  CDF_MaybeBuiltin = 1 << 0,
-};
-
-/// This class represents a description of a function call using the number of
-/// arguments and the name of the function.
+/// A `CallDescription` is a pattern that can be used to _match_ calls
+/// based on the qualified name and the argument/parameter counts.
 class CallDescription {
+public:
+  enum class Mode {
+/// Match calls to functions from the C standard library. On some platforms
+/// some functions may be implemented as macros that expand to calls to
+/// built-in variants of the given functions, so in this mode we use some
+/// heuristics to recognize these implementation-defined variants:
+///  - We also accept calls where the name is derived from the specified
+///name by adding "__builtin" or similar prefixes/suffixes.
+///  - We also accept calls where the number of arguments or parameters is
+///greater than the specified value.

balazske wrote:

Should check how this looks in doxygen documentation (produces a list?).

https://github.com/llvm/llvm-project/pull/83432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread Balázs Kéri via cfe-commits

https://github.com/balazske commented:

The flag approach can probably make a sense for namespace handling (match the 
exact specified namespace, or allow a prefix before, or even something in 
between).

https://github.com/llvm/llvm-project/pull/83432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread Balázs Kéri via cfe-commits


@@ -27,20 +27,48 @@ class IdentifierInfo;
 
 namespace clang {
 namespace ento {
-
-enum CallDescriptionFlags : unsigned {
-  CDF_None = 0,
-
-  /// Describes a C standard function that is sometimes implemented as a macro
-  /// that expands to a compiler builtin with some __builtin prefix.
-  /// The builtin may as well have a few extra arguments on top of the 
requested
-  /// number of arguments.
-  CDF_MaybeBuiltin = 1 << 0,
-};
-
-/// This class represents a description of a function call using the number of
-/// arguments and the name of the function.
+/// A `CallDescription` is a pattern that can be used to _match_ calls
+/// based on the qualified name and the argument/parameter counts.
 class CallDescription {
+public:
+  enum class Mode {
+/// Match calls to functions from the C standard library. On some platforms
+/// some functions may be implemented as macros that expand to calls to
+/// built-in variants of the given functions, so in this mode we use some
+/// heuristics to recognize these implementation-defined variants:
+///  - We also accept calls where the name is derived from the specified
+///name by adding "__builtin" or similar prefixes/suffixes.
+///  - We also accept calls where the number of arguments or parameters is
+///greater than the specified value.
+/// For the exact heuristics, see CheckerContext::isCLibraryFunction().
+/// Note that functions whose declaration context is not a TU (e.g.
+/// methods, functions in namespaces) are not accepted as C library
+/// functions.
+/// FIXME: If I understand it correctly, this discards calls where C++ code
+/// refers a C library function through the namespace `std::` via headers
+/// like .
+CLibrary,
+
+/// Matches "simple" functions that are not methods. (Static methods are
+/// methods.)
+SimpleFunc,
+
+/// Matches a C+ method (may be static, may be virtual, may be an

balazske wrote:

```suggestion
/// Matches a C++ method (may be static, may be virtual, may be an
```

https://github.com/llvm/llvm-project/pull/83432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][RISCV] Reorder sema check for RVV type (PR #83553)

2024-03-01 Thread Brandon Wu via cfe-commits

https://github.com/4vtomat updated 
https://github.com/llvm/llvm-project/pull/83553

>From 8ad3a883d29155dc26c79abdd57ea0f72d046dfc Mon Sep 17 00:00:00 2001
From: Brandon Wu 
Date: Fri, 1 Mar 2024 00:40:21 -0800
Subject: [PATCH 1/2] [clang][RISCV] Reorder sema check for RVV type

Currently using the command `clang -cc1 -triple riscv64` to compile the
code below:
```
#include 
void foo() {
  vfloat64m1_t f64m1;
}
```
would get the error message "RISC-V type 'vfloat64m1_t' ... requires the 
'zve64x' extension"
which is supposed to be "RISC-V type 'vfloat64m1_t' ... requires the 'zve64d' 
extension".
---
 clang/lib/Sema/SemaChecking.cpp | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 979b63884359fc..27ed6f2da05254 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -6332,9 +6332,12 @@ void Sema::checkRVVTypeSupport(QualType Ty, 
SourceLocation Loc, Decl *D) {
   unsigned EltSize = Context.getTypeSize(Info.ElementType);
   unsigned MinElts = Info.EC.getKnownMinValue();
 
+  if (Info.ElementType->isSpecificBuiltinType(BuiltinType::Double) &&
+   !TI.hasFeature("zve64d"))
+Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve64d";
   // (ELEN, LMUL) pairs of (8, mf8), (16, mf4), (32, mf2), (64, m1) requires at
   // least zve64x
-  if (((EltSize == 64 && Info.ElementType->isIntegerType()) || MinElts == 1) &&
+  else if (((EltSize == 64 && Info.ElementType->isIntegerType()) || MinElts == 
1) &&
   !TI.hasFeature("zve64x"))
 Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve64x";
   else if (Info.ElementType->isFloat16Type() && !TI.hasFeature("zvfh") &&
@@ -6347,9 +6350,6 @@ void Sema::checkRVVTypeSupport(QualType Ty, 
SourceLocation Loc, Decl *D) {
   else if (Info.ElementType->isSpecificBuiltinType(BuiltinType::Float) &&
!TI.hasFeature("zve32f"))
 Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve32f";
-  else if (Info.ElementType->isSpecificBuiltinType(BuiltinType::Double) &&
-   !TI.hasFeature("zve64d"))
-Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve64d";
   // Given that caller already checked isRVVType() before calling this 
function,
   // if we don't have at least zve32x supported, then we need to emit error.
   else if (!TI.hasFeature("zve32x"))

>From 779aebac10d2128d4507f74c2c929ab0924a80b6 Mon Sep 17 00:00:00 2001
From: Brandon Wu 
Date: Fri, 1 Mar 2024 02:57:00 -0800
Subject: [PATCH 2/2] fixup! [clang][RISCV] Reorder sema check for RVV type

---
 clang/lib/Sema/SemaChecking.cpp | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 27ed6f2da05254..ae011806eec629 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -6333,12 +6333,13 @@ void Sema::checkRVVTypeSupport(QualType Ty, 
SourceLocation Loc, Decl *D) {
   unsigned MinElts = Info.EC.getKnownMinValue();
 
   if (Info.ElementType->isSpecificBuiltinType(BuiltinType::Double) &&
-   !TI.hasFeature("zve64d"))
+  !TI.hasFeature("zve64d"))
 Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve64d";
   // (ELEN, LMUL) pairs of (8, mf8), (16, mf4), (32, mf2), (64, m1) requires at
   // least zve64x
-  else if (((EltSize == 64 && Info.ElementType->isIntegerType()) || MinElts == 
1) &&
-  !TI.hasFeature("zve64x"))
+  else if (((EltSize == 64 && Info.ElementType->isIntegerType()) ||
+MinElts == 1) &&
+   !TI.hasFeature("zve64x"))
 Diag(Loc, diag::err_riscv_type_requires_extension, D) << Ty << "zve64x";
   else if (Info.ElementType->isFloat16Type() && !TI.hasFeature("zvfh") &&
!TI.hasFeature("zvfhmin"))

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


[clang] [clang] Remove unused lambda capture. (PR #83550)

2024-03-01 Thread Alexandros Lamprineas via cfe-commits

https://github.com/labrinea closed 
https://github.com/llvm/llvm-project/pull/83550
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [RISCV] Support RISC-V Profiles in -march option (PR #76357)

2024-03-01 Thread Wang Pengcheng via cfe-commits


@@ -839,6 +860,33 @@ RISCVISAInfo::parseArchString(StringRef Arch, bool 
EnableExperimentalExtension,
  "string must be lowercase");
   }
 
+  bool IsProfile = Arch.starts_with("rvi") || Arch.starts_with("rva") ||
+   Arch.starts_with("rvb") || Arch.starts_with("rvm");

wangpc-pp wrote:

RV[A|B|M]23 haven't been ratified, but I can add them as well.
`RVB` means some low-end APs I think?

https://github.com/llvm/llvm-project/pull/76357
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread via cfe-commits
=?utf-8?q?Donát?= Nagy 
Message-ID:
In-Reply-To: 



@@ -27,20 +27,48 @@ class IdentifierInfo;
 
 namespace clang {
 namespace ento {
-
-enum CallDescriptionFlags : unsigned {
-  CDF_None = 0,
-
-  /// Describes a C standard function that is sometimes implemented as a macro
-  /// that expands to a compiler builtin with some __builtin prefix.
-  /// The builtin may as well have a few extra arguments on top of the 
requested
-  /// number of arguments.
-  CDF_MaybeBuiltin = 1 << 0,
-};
-
-/// This class represents a description of a function call using the number of
-/// arguments and the name of the function.
+/// A `CallDescription` is a pattern that can be used to _match_ calls
+/// based on the qualified name and the argument/parameter counts.
 class CallDescription {
+public:
+  enum class Mode {
+/// Match calls to functions from the C standard library. On some platforms
+/// some functions may be implemented as macros that expand to calls to
+/// built-in variants of the given functions, so in this mode we use some
+/// heuristics to recognize these implementation-defined variants:
+///  - We also accept calls where the name is derived from the specified
+///name by adding "__builtin" or similar prefixes/suffixes.
+///  - We also accept calls where the number of arguments or parameters is
+///greater than the specified value.
+/// For the exact heuristics, see CheckerContext::isCLibraryFunction().
+/// Note that functions whose declaration context is not a TU (e.g.
+/// methods, functions in namespaces) are not accepted as C library
+/// functions.
+/// FIXME: If I understand it correctly, this discards calls where C++ code
+/// refers a C library function through the namespace `std::` via headers
+/// like .
+CLibrary,
+
+/// Matches "simple" functions that are not methods. (Static methods are
+/// methods.)
+SimpleFunc,
+
+/// Matches a C+ method (may be static, may be virtual, may be an
+/// overloaded operator, a constructor or a destructor).
+CXXMethod,
+
+/// Match any CallEvent that is not an ObjCMethodCall.
+/// FIXME: Previously this was the default behavior of CallDescription, but
+/// its use should be replaced by a more specific mode almost everywhere.
+Unspecified,

NagyDonat wrote:

At first I also wanted to name it "Any", but I discarded that idea because it 
doesn't match the Objective-C method calls. (And AFAIK Objective-C method calls 
are very weird stuff, whose AST/CallEvent representation is significantly 
different from the "normal" function/method calls, so I don't want to extend 
`CallDescription` support for them.)

I'd say that reading `Unspecified` as "works in a default way" is also fine for 
this enumerator, as this _is_ the old default mode that should be eventually 
eliminated.

https://github.com/llvm/llvm-project/pull/83432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [AMDGPU] Emit a waitcnt instruction after each memory instruction (PR #79236)

2024-03-01 Thread Pierre van Houtryve via cfe-commits


@@ -2326,6 +2326,20 @@ bool 
SIInsertWaitcnts::insertWaitcntInBlock(MachineFunction &MF,
 }
 #endif
 
+if (ST->isPreciseMemoryEnabled()) {
+  AMDGPU::Waitcnt Wait;
+  if (WCG == &WCGPreGFX12)
+Wait = AMDGPU::Waitcnt(0, 0, 0, 0);

Pierre-vh wrote:

I was looking at https://github.com/ROCm/ROCm-CompilerSupport/issues/66 and it 
made me wonder, why do we have to emit all zeroes instead of just emitting 
what's in `ScoreBrackets`? Is there an advantage?

I'm wondering if this should just emit `ScoreBrackets`, then `+precise-memory` 
+ `-amdgpu-waitcnt-forcezero` need to be used together achieve the behavior we 
have here?


https://github.com/llvm/llvm-project/pull/79236
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread via cfe-commits
=?utf-8?q?Donát?= Nagy 
Message-ID:
In-Reply-To: 



@@ -27,20 +27,48 @@ class IdentifierInfo;
 
 namespace clang {
 namespace ento {
-
-enum CallDescriptionFlags : unsigned {
-  CDF_None = 0,
-
-  /// Describes a C standard function that is sometimes implemented as a macro
-  /// that expands to a compiler builtin with some __builtin prefix.
-  /// The builtin may as well have a few extra arguments on top of the 
requested
-  /// number of arguments.
-  CDF_MaybeBuiltin = 1 << 0,
-};
-
-/// This class represents a description of a function call using the number of
-/// arguments and the name of the function.
+/// A `CallDescription` is a pattern that can be used to _match_ calls
+/// based on the qualified name and the argument/parameter counts.
 class CallDescription {
+public:
+  enum class Mode {
+/// Match calls to functions from the C standard library. On some platforms
+/// some functions may be implemented as macros that expand to calls to
+/// built-in variants of the given functions, so in this mode we use some
+/// heuristics to recognize these implementation-defined variants:
+///  - We also accept calls where the name is derived from the specified
+///name by adding "__builtin" or similar prefixes/suffixes.
+///  - We also accept calls where the number of arguments or parameters is
+///greater than the specified value.
+/// For the exact heuristics, see CheckerContext::isCLibraryFunction().
+/// Note that functions whose declaration context is not a TU (e.g.
+/// methods, functions in namespaces) are not accepted as C library
+/// functions.
+/// FIXME: If I understand it correctly, this discards calls where C++ code
+/// refers a C library function through the namespace `std::` via headers
+/// like .
+CLibrary,

NagyDonat wrote:

> many functions that are "C library" calls are not matched with this mode

I'm planning to ensure that:
- this mode works "out of the box" for matching the C standard library 
functions and
- the checkers that are looking for a C standard library function do use it.
This is an NFC commit so I didn't change the behavior of this mode yet, but I'm 
planning to do so in a followup commit. I picked the name `CLibrary` because it 
reflects the name of the method `isCLibraryFunction()` which is used to 
implement this mode. I'd say that if `isCLibraryFunction()` returns false for a 
C library function, then it's buggy and I'll fix its behavior.

Do you see any difficulties that would hinder or block this path?

By the way I dislike the name `MaybeBuiltin` because at first I thought that 
that it clearly meant "this _may be_ a builtin function (with a modified name), 
but it _may be_ anything else as well", while in fact it always calls 
`isCLibraryFunction` (and doesn't accept anything that isn't a C library 
function).

https://github.com/llvm/llvm-project/pull/83432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread via cfe-commits
=?utf-8?q?Donát?= Nagy 
Message-ID:
In-Reply-To: 


https://github.com/NagyDonat edited 
https://github.com/llvm/llvm-project/pull/83432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Bugfix for choosing the more specialized overload (PR #83279)

2024-03-01 Thread Botond István Horváth via cfe-commits


@@ -5548,13 +5504,100 @@ static bool isAtLeastAsSpecializedAs(Sema &S,
 FunctionTemplateDecl *Sema::getMoreSpecializedTemplate(
 FunctionTemplateDecl *FT1, FunctionTemplateDecl *FT2, SourceLocation Loc,
 TemplatePartialOrderingContext TPOC, unsigned NumCallArguments1,
-unsigned NumCallArguments2, bool Reversed) {
+unsigned NumCallArguments2, QualType RawObjType1, QualType RawObjType2,
+bool Reversed) {
+  SmallVector Args1;
+  SmallVector Args2;
+  const FunctionDecl *FD1 = FT1->getTemplatedDecl();
+  const FunctionDecl *FD2 = FT2->getTemplatedDecl();
+  bool shouldConvert1 = false;
+  bool shouldConvert2 = false;
+  QualType ObjType1;
+  QualType ObjType2;
+  if (TPOC == TPOC_Call) {
+const FunctionProtoType *Proto1 =
+FD1->getType()->getAs();
+const FunctionProtoType *Proto2 =
+FD2->getType()->getAs();
+
+//   - In the context of a function call, the function parameter types are
+// used.
+const CXXMethodDecl *Method1 = dyn_cast(FD1);
+const CXXMethodDecl *Method2 = dyn_cast(FD2);
+
+if (getLangOpts().CPlusPlus20) {
+  // C++20 [temp.func.order]p3
+  //   [...] Each function template M that is a member function is
+  //   considered to have a new first parameter of type
+  //   X(M), described below, inserted in its function parameter list.
+  //
+  // Note that we interpret "that is a member function" as
+  // "that is a member function with no expicit object argument".
+  // Otherwise the ordering rules for methods with expicit objet arguments
+  // against anything else make no sense.
+  shouldConvert1 = Method1 && !Method1->isExplicitObjectMemberFunction();
+  shouldConvert2 = Method2 && !Method2->isExplicitObjectMemberFunction();
+} else {
+  // C++11 [temp.func.order]p3:
+  //   [...] If only one of the function templates is a non-static
+  //   member, that function template is considered to have a new
+  //   first parameter inserted in its function parameter list.
+  //
+  // Note that we interpret this to mean "if one of the function
+  // templates is a non-static member and the other is a non-member";
+  // otherwise, the ordering rules for static functions against non-static
+  // functions don't make any sense.
+  //
+  // C++98/03 doesn't have this provision but we've extended DR532 to cover
+  // it as wording was broken prior to it.
+  shouldConvert1 =
+  !Method2 && Method1 && Method1->isImplicitObjectMemberFunction();
+  shouldConvert2 =
+  !Method1 && Method2 && Method2->isImplicitObjectMemberFunction();
+}
+if (shouldConvert1) {
+  bool isR2 =
+  getLangOpts().CPlusPlus20 &&
+  (shouldConvert1
+   ? Method2->getRefQualifier() == RQ_RValue
+   : Proto2->param_type_begin()[0]->isRValueReferenceType());
+  // Compare 'this' from Method1 against first parameter from Method2.
+  ObjType1 = GetImplicitObjectParameterType(this->Context, Method1,
+RawObjType1, isR2);
+  Args1.push_back(ObjType1);
+}
+if (shouldConvert2) {
+  bool isR1 =
+  getLangOpts().CPlusPlus20 &&
+  (shouldConvert2
+   ? Method1->getRefQualifier() == RQ_RValue
+   : Proto1->param_type_begin()[0]->isRValueReferenceType());
+  // Compare 'this' from Method2 against first parameter from Method1.
+  ObjType2 = GetImplicitObjectParameterType(this->Context, Method2,
+RawObjType2, isR1);
+  Args2.push_back(ObjType2);
+}
+unsigned NumComparedArguments = NumCallArguments1 + shouldConvert1;
 
-  bool Better1 = isAtLeastAsSpecializedAs(*this, Loc, FT1, FT2, TPOC,
-  NumCallArguments1, Reversed);
-  bool Better2 = isAtLeastAsSpecializedAs(*this, Loc, FT2, FT1, TPOC,
-  NumCallArguments2, Reversed);
+Args1.insert(Args1.end(), Proto1->param_type_begin(),
+ Proto1->param_type_end());
+Args2.insert(Args2.end(), Proto2->param_type_begin(),
+ Proto2->param_type_end());
 
+// C++ [temp.func.order]p5:
+//   The presence of unused ellipsis and default arguments has no effect on
+//   the partial ordering of function templates.
+if (Args1.size() > NumComparedArguments)

HoBoIs wrote:

How can I make it less confusing? Should I put in a comment explaining that in 
`Args1` and `Args2` after the first `NumComparedArguments` elements there can 
only be unused ellipsis and default arguments? (It already states that  unused 
ellipsis and default arguments has no effect on the partial ordering of 
function templates. Just above the if)

https://github.com/llvm/llvm-project/pull/83279
___
cfe-commits mailing list
cfe-commits@li

[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread via cfe-commits
=?utf-8?q?Donát?= Nagy 
Message-ID:
In-Reply-To: 



@@ -27,20 +27,48 @@ class IdentifierInfo;
 
 namespace clang {
 namespace ento {
-
-enum CallDescriptionFlags : unsigned {
-  CDF_None = 0,
-
-  /// Describes a C standard function that is sometimes implemented as a macro
-  /// that expands to a compiler builtin with some __builtin prefix.
-  /// The builtin may as well have a few extra arguments on top of the 
requested
-  /// number of arguments.
-  CDF_MaybeBuiltin = 1 << 0,
-};
-
-/// This class represents a description of a function call using the number of
-/// arguments and the name of the function.
+/// A `CallDescription` is a pattern that can be used to _match_ calls
+/// based on the qualified name and the argument/parameter counts.
 class CallDescription {
+public:
+  enum class Mode {
+/// Match calls to functions from the C standard library. On some platforms
+/// some functions may be implemented as macros that expand to calls to
+/// built-in variants of the given functions, so in this mode we use some
+/// heuristics to recognize these implementation-defined variants:
+///  - We also accept calls where the name is derived from the specified
+///name by adding "__builtin" or similar prefixes/suffixes.
+///  - We also accept calls where the number of arguments or parameters is
+///greater than the specified value.
+/// For the exact heuristics, see CheckerContext::isCLibraryFunction().
+/// Note that functions whose declaration context is not a TU (e.g.
+/// methods, functions in namespaces) are not accepted as C library
+/// functions.
+/// FIXME: If I understand it correctly, this discards calls where C++ code

NagyDonat wrote:

In general, I agree, but in this particular case I think this FIXME note is an 
important disclaimer and without it the auto-generated documentation would be 
misleading.

https://github.com/llvm/llvm-project/pull/83432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread via cfe-commits
=?utf-8?q?Donát?= Nagy 
Message-ID:
In-Reply-To: 



@@ -27,20 +27,48 @@ class IdentifierInfo;
 
 namespace clang {
 namespace ento {
-
-enum CallDescriptionFlags : unsigned {
-  CDF_None = 0,
-
-  /// Describes a C standard function that is sometimes implemented as a macro
-  /// that expands to a compiler builtin with some __builtin prefix.
-  /// The builtin may as well have a few extra arguments on top of the 
requested
-  /// number of arguments.
-  CDF_MaybeBuiltin = 1 << 0,
-};
-
-/// This class represents a description of a function call using the number of
-/// arguments and the name of the function.
+/// A `CallDescription` is a pattern that can be used to _match_ calls
+/// based on the qualified name and the argument/parameter counts.
 class CallDescription {
+public:
+  enum class Mode {
+/// Match calls to functions from the C standard library. On some platforms
+/// some functions may be implemented as macros that expand to calls to
+/// built-in variants of the given functions, so in this mode we use some
+/// heuristics to recognize these implementation-defined variants:
+///  - We also accept calls where the name is derived from the specified
+///name by adding "__builtin" or similar prefixes/suffixes.
+///  - We also accept calls where the number of arguments or parameters is
+///greater than the specified value.
+/// For the exact heuristics, see CheckerContext::isCLibraryFunction().
+/// Note that functions whose declaration context is not a TU (e.g.
+/// methods, functions in namespaces) are not accepted as C library
+/// functions.
+/// FIXME: If I understand it correctly, this discards calls where C++ code
+/// refers a C library function through the namespace `std::` via headers
+/// like .
+CLibrary,
+
+/// Matches "simple" functions that are not methods. (Static methods are
+/// methods.)
+SimpleFunc,
+
+/// Matches a C+ method (may be static, may be virtual, may be an

NagyDonat wrote:

Nice catch ;)

https://github.com/llvm/llvm-project/pull/83432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread via cfe-commits
=?utf-8?q?Donát?= Nagy 
Message-ID:
In-Reply-To: 



@@ -27,20 +27,48 @@ class IdentifierInfo;
 
 namespace clang {
 namespace ento {
-
-enum CallDescriptionFlags : unsigned {
-  CDF_None = 0,
-
-  /// Describes a C standard function that is sometimes implemented as a macro
-  /// that expands to a compiler builtin with some __builtin prefix.
-  /// The builtin may as well have a few extra arguments on top of the 
requested
-  /// number of arguments.
-  CDF_MaybeBuiltin = 1 << 0,
-};
-
-/// This class represents a description of a function call using the number of
-/// arguments and the name of the function.
+/// A `CallDescription` is a pattern that can be used to _match_ calls
+/// based on the qualified name and the argument/parameter counts.
 class CallDescription {
+public:
+  enum class Mode {
+/// Match calls to functions from the C standard library. On some platforms
+/// some functions may be implemented as macros that expand to calls to
+/// built-in variants of the given functions, so in this mode we use some
+/// heuristics to recognize these implementation-defined variants:
+///  - We also accept calls where the name is derived from the specified
+///name by adding "__builtin" or similar prefixes/suffixes.
+///  - We also accept calls where the number of arguments or parameters is
+///greater than the specified value.

NagyDonat wrote:

I assume that it does, but I don't know how to generate the doxygen docs and I 
feel that messing with them is a waste of time.

https://github.com/llvm/llvm-project/pull/83432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread via cfe-commits
=?utf-8?q?Donát?= Nagy 
Message-ID:
In-Reply-To: 


NagyDonat wrote:

> The flag approach can probably make a sense for namespace handling (match the 
> exact specified namespace, or allow a prefix before, or even something in 
> between).

Even in that case, I'd prefer a separate second parameter (that's either 
boolean or a different `enum`). Squeezing unrelated things into the same flag 
only makes sense if (1) memory use is strongly limited (2) there would be too 
many separate parameters. 


https://github.com/llvm/llvm-project/pull/83432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread via cfe-commits
=?utf-8?q?Donát?= Nagy ,NagyDonat
 
Message-ID:
In-Reply-To: 


https://github.com/NagyDonat updated 
https://github.com/llvm/llvm-project/pull/83432

>From 7a72174f9df2211febf789941ed0adb75ebacc89 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Don=C3=A1t=20Nagy?= 
Date: Thu, 22 Feb 2024 18:09:15 +0100
Subject: [PATCH 1/3] [analyzer] Refactor CallDescription match mode (NFC)

The class `CallDescription` is used to define patterns that are used for
matching `CallEvent`s. For example, a `CallEvent{{"std", "find_if"}, 3}`
matches a call to `std::find_if` with 3 arguments.

However, these patterns are somewhat fuzzy, so this pattern could also
match something like `std::__1::find_if` (with an additional namespace
layer), or, unfortunately, a `CallDescription` for the well-known
function `free()` can match a C++ method named `free()`:
https://github.com/llvm/llvm-project/issues/81597

To prevent this kind of ambiguity this commit introduces the enum
`CallDescription::Mode` which can limit the pattern matching to
non-method function calls (or method calls etc.). After this NFC change,
one or more follow-up commits will apply the right pattern matching
modes in the ~30 checkers that use `CallDescription`s.

Note that `CallDescription` previously had a `Flags` field which had
only two supported values:
 - CDF_None was the default "match anything" mode,
 - CDF_MaybeBuiltin was a "match only C library functions and accept
   some inexact matches" mode.
This commit preserves `CDF_MaybeBuiltin` under the more descriptive name
`CallDescription::Mode::CLibrary` (or `CDM::CLibrary`).

Instead of this "Flags" model I'm switching to a plain enumeration
becasue I don't think that there is a natural usecase to combine the
different matching modes. (Except for the default "match anything" mode,
which is currently kept for compatibility, but will be phased out in the
follow-up commits.)
---
 .../Core/PathSensitive/CallDescription.h  | 72 ++-
 .../Checkers/CStringChecker.cpp   | 64 -
 .../Checkers/GenericTaintChecker.cpp  | 44 ++--
 .../StaticAnalyzer/Checkers/MallocChecker.cpp |  8 +--
 .../StaticAnalyzer/Core/CallDescription.cpp   | 19 +++--
 .../StaticAnalyzer/CallDescriptionTest.cpp| 16 ++---
 6 files changed, 133 insertions(+), 90 deletions(-)

diff --git 
a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h 
b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h
index 965838a4408c23..d4985238a3c73b 100644
--- a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h
+++ b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h
@@ -27,20 +27,46 @@ class IdentifierInfo;
 
 namespace clang {
 namespace ento {
-
-enum CallDescriptionFlags : unsigned {
-  CDF_None = 0,
-
-  /// Describes a C standard function that is sometimes implemented as a macro
-  /// that expands to a compiler builtin with some __builtin prefix.
-  /// The builtin may as well have a few extra arguments on top of the 
requested
-  /// number of arguments.
-  CDF_MaybeBuiltin = 1 << 0,
-};
-
-/// This class represents a description of a function call using the number of
-/// arguments and the name of the function.
+/// A `CallDescription` is a pattern that can be used to _match_ calls
+/// based on the qualified name and the argument/parameter counts.
 class CallDescription {
+public:
+  enum class Mode {
+/// Match calls to functions from the C standard library. On some platforms
+/// some functions may be implemented as macros that expand to calls to
+/// built-in variants of the given functions, so in this mode we use some
+/// heuristics to recognize these implementation-defined variants:
+///  - We also accept calls where the name is derived from the specified
+///name by adding "__builtin" or similar prefixes/suffixes.
+///  - We also accept calls where the number of arguments or parameters is
+///greater than the specified value.
+/// For the exact heuristics, see CheckerContext::isCLibraryFunction().
+/// Note that functions whose declaration context is not a TU (e.g.
+/// methods, functions in namespaces) are not accepted as C library 
functions.
+/// FIXME: If I understand it correctly, this discards calls where C++ code
+/// refers a C library function through the namespace `std::` via headers
+/// like .
+CLibrary,
+
+/// Matches "simple" functions that are not methods. (Static methods are
+/// methods.)
+SimpleFunc,
+
+/// Matches a C+ method (may be static, may be virtual, may be an
+/// overloaded operator, a constructor or a destructor).
+CXXMethod,
+
+/// Match any CallEvent that is not an ObjCMethodCall.
+/// FIXME: Previously this was the default behavior of CallDescription, but
+/// its use should be replaced by a more specific mode almost everywhere.
+Unspecified,
+
+/// FIXME: Add support for 

[clang] [clang][AMDGPU] Don't define feature macros on host code (PR #83558)

2024-03-01 Thread Pierre van Houtryve via cfe-commits

https://github.com/Pierre-vh created 
https://github.com/llvm/llvm-project/pull/83558

Those macros are unreliable because our features are mostly uninitialized at 
that stage, so any macro we define is unreliable.

Fixes SWDEV-447308

>From 3730631ac58425f559f4bc3cfe3da89e6367c1c5 Mon Sep 17 00:00:00 2001
From: pvanhout 
Date: Fri, 1 Mar 2024 12:43:55 +0100
Subject: [PATCH] [clang][AMDGPU] Don't define feature macros on host code

Those macros are unreliable because our features are mostly uninitialized at 
that stage, so any macro we define is unreliable.

Fixes SWDEV-447308
---
 clang/lib/Basic/Targets/AMDGPU.cpp   | 8 +++-
 clang/test/Preprocessor/predefined-arch-macros.c | 2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/clang/lib/Basic/Targets/AMDGPU.cpp 
b/clang/lib/Basic/Targets/AMDGPU.cpp
index 5742885df0461b..df9a5855068ed3 100644
--- a/clang/lib/Basic/Targets/AMDGPU.cpp
+++ b/clang/lib/Basic/Targets/AMDGPU.cpp
@@ -292,8 +292,14 @@ void AMDGPUTargetInfo::getTargetDefines(const LangOptions 
&Opts,
   }
 
   Builder.defineMacro(Twine("__") + Twine(CanonName) + Twine("__"));
+
+  // Don't emit feature macros in host code because in such cases the
+  // feature list is not accurate.
+  if (IsHIPHost)
+return;
+
   // Emit macros for gfx family e.g. gfx906 -> __GFX9__, gfx1030 -> __GFX10___
-  if (isAMDGCN(getTriple()) && !IsHIPHost) {
+  if (isAMDGCN(getTriple())) {
 assert(StringRef(CanonName).starts_with("gfx") &&
"Invalid amdgcn canonical name");
 StringRef CanonFamilyName = getArchFamilyNameAMDGCN(GPUKind);
diff --git a/clang/test/Preprocessor/predefined-arch-macros.c 
b/clang/test/Preprocessor/predefined-arch-macros.c
index ca51f2fc22c517..8904bcea1a1f68 100644
--- a/clang/test/Preprocessor/predefined-arch-macros.c
+++ b/clang/test/Preprocessor/predefined-arch-macros.c
@@ -4340,7 +4340,7 @@
 // RUN: %clang -x hip -E -dM %s -o - 2>&1 --offload-host-only -nogpulib \
 // RUN: -nogpuinc --offload-arch=gfx803 -target x86_64-unknown-linux \
 // RUN:   | FileCheck -match-full-lines %s -check-prefixes=CHECK_HIP_HOST
-// CHECK_HIP_HOST: #define __AMDGCN_WAVEFRONT_SIZE__ 64
+// CHECK_HIP_HOST-NOT: #define __AMDGCN_WAVEFRONT_SIZE__ 64
 // CHECK_HIP_HOST: #define __AMDGPU__ 1
 // CHECK_HIP_HOST: #define __AMD__ 1
 

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


[clang] [clang][AMDGPU] Don't define feature macros on host code (PR #83558)

2024-03-01 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Pierre van Houtryve (Pierre-vh)


Changes

Those macros are unreliable because our features are mostly uninitialized at 
that stage, so any macro we define is unreliable.

Fixes SWDEV-447308

---
Full diff: https://github.com/llvm/llvm-project/pull/83558.diff


2 Files Affected:

- (modified) clang/lib/Basic/Targets/AMDGPU.cpp (+7-1) 
- (modified) clang/test/Preprocessor/predefined-arch-macros.c (+1-1) 


``diff
diff --git a/clang/lib/Basic/Targets/AMDGPU.cpp 
b/clang/lib/Basic/Targets/AMDGPU.cpp
index 5742885df0461b..df9a5855068ed3 100644
--- a/clang/lib/Basic/Targets/AMDGPU.cpp
+++ b/clang/lib/Basic/Targets/AMDGPU.cpp
@@ -292,8 +292,14 @@ void AMDGPUTargetInfo::getTargetDefines(const LangOptions 
&Opts,
   }
 
   Builder.defineMacro(Twine("__") + Twine(CanonName) + Twine("__"));
+
+  // Don't emit feature macros in host code because in such cases the
+  // feature list is not accurate.
+  if (IsHIPHost)
+return;
+
   // Emit macros for gfx family e.g. gfx906 -> __GFX9__, gfx1030 -> __GFX10___
-  if (isAMDGCN(getTriple()) && !IsHIPHost) {
+  if (isAMDGCN(getTriple())) {
 assert(StringRef(CanonName).starts_with("gfx") &&
"Invalid amdgcn canonical name");
 StringRef CanonFamilyName = getArchFamilyNameAMDGCN(GPUKind);
diff --git a/clang/test/Preprocessor/predefined-arch-macros.c 
b/clang/test/Preprocessor/predefined-arch-macros.c
index ca51f2fc22c517..8904bcea1a1f68 100644
--- a/clang/test/Preprocessor/predefined-arch-macros.c
+++ b/clang/test/Preprocessor/predefined-arch-macros.c
@@ -4340,7 +4340,7 @@
 // RUN: %clang -x hip -E -dM %s -o - 2>&1 --offload-host-only -nogpulib \
 // RUN: -nogpuinc --offload-arch=gfx803 -target x86_64-unknown-linux \
 // RUN:   | FileCheck -match-full-lines %s -check-prefixes=CHECK_HIP_HOST
-// CHECK_HIP_HOST: #define __AMDGCN_WAVEFRONT_SIZE__ 64
+// CHECK_HIP_HOST-NOT: #define __AMDGCN_WAVEFRONT_SIZE__ 64
 // CHECK_HIP_HOST: #define __AMDGPU__ 1
 // CHECK_HIP_HOST: #define __AMD__ 1
 

``




https://github.com/llvm/llvm-project/pull/83558
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][AMDGPU] Don't define feature macros on host code (PR #83558)

2024-03-01 Thread Matt Arsenault via cfe-commits


@@ -292,8 +292,14 @@ void AMDGPUTargetInfo::getTargetDefines(const LangOptions 
&Opts,
   }
 
   Builder.defineMacro(Twine("__") + Twine(CanonName) + Twine("__"));
+
+  // Don't emit feature macros in host code because in such cases the
+  // feature list is not accurate.
+  if (IsHIPHost)

arsenm wrote:

This should apply to all hosts, not just hip 

https://github.com/llvm/llvm-project/pull/83558
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang-format] Enable again some operator tests (PR #83380)

2024-03-01 Thread via cfe-commits

rayroudc wrote:

@owenca, thanks for the review!
As I do not have write access, would it be possible for you to merge this 
change ?

https://github.com/llvm/llvm-project/pull/83380
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Improve some comments in ArrayBoundCheckerV2 (NFC) (PR #83545)

2024-03-01 Thread Gábor Spaits via cfe-commits


@@ -301,21 +301,27 @@ compareValueToThreshold(ProgramStateRef State, NonLoc 
Value, NonLoc Threshold,
   // calling `evalBinOpNN`:
   if (isNegative(SVB, State, Value) && isUnsigned(SVB, Threshold)) {
 if (CheckEquality) {
-  // negative_value == unsigned_value is always false
+  // negative_value == unsigned_threshold is always false
   return {nullptr, State};
 }
-// negative_value < unsigned_value is always false
+// negative_value < unsigned_threshold is always true
 return {State, nullptr};
   }
   if (isUnsigned(SVB, Value) && isNegative(SVB, State, Threshold)) {
-// unsigned_value == negative_value and unsigned_value < negative_value are
-// both always false
+// unsigned_value == negative_threshold and
+// unsigned_value < negative_threshold are both always false

spaits wrote:

Just a minor nit: Wouldn't it be better to write `<=`?

https://github.com/llvm/llvm-project/pull/83545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][RISCV] Reorder sema check for RVV type (PR #83553)

2024-03-01 Thread Kito Cheng via cfe-commits

https://github.com/kito-cheng commented:

Could you add a testcase?

https://github.com/llvm/llvm-project/pull/83553
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [TargetParser][AArch64] Add alias for FEAT_RDM. (PR #80540)

2024-03-01 Thread Alexandros Lamprineas via cfe-commits

https://github.com/labrinea updated 
https://github.com/llvm/llvm-project/pull/80540

>From d2c973c8ebd7605b47a8c5fc928d2d85426c8a6d Mon Sep 17 00:00:00 2001
From: Alexandros Lamprineas 
Date: Tue, 30 Jan 2024 11:17:55 +
Subject: [PATCH] [TargetParser][AArch64] Add alias for FEAT_RDM.

This patch allows using the name "rdma" as an alias for "rdm".
The name makes its way to target attributes as well as the
command line via the -march and -mcpu options. The motivation
was originally to support this in Function Multi Versioning
but it also makes sense to align with GCC on the command line.
---
 clang/docs/ReleaseNotes.rst   |  5 +
 clang/test/CodeGen/attr-target-version.c  | 12 ++--
 clang/test/Driver/aarch64-rdm.c   |  3 +++
 clang/test/Sema/attr-target-clones-aarch64.c  |  2 +-
 clang/test/SemaCXX/attr-target-version.cpp|  1 +
 .../llvm/TargetParser/AArch64TargetParser.h   | 13 -
 llvm/lib/TargetParser/AArch64TargetParser.cpp | 15 +--
 7 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index f44fef28b9f17f..530158dda66689 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -333,6 +333,11 @@ Arm and AArch64 Support
   improvements for most targets. We have not changed the default behavior for
   ARMv6, but may revisit that decision in the future. Users can restore the old
   behavior with -m[no-]unaligned-access.
+- An alias identifier (rdma) has been added for targeting the AArch64
+  Architecture Extension which uses Rounding Doubling Multiply Accumulate
+  instructions (rdm). The identifier is available on the command line as
+  a feature modifier for -march and -mcpu as well as via target attributes
+  like ``target_version`` or ``target_clones``.
 
 Android Support
 ^^^
diff --git a/clang/test/CodeGen/attr-target-version.c 
b/clang/test/CodeGen/attr-target-version.c
index ae97977a9144f6..56a42499d0a7ca 100644
--- a/clang/test/CodeGen/attr-target-version.c
+++ b/clang/test/CodeGen/attr-target-version.c
@@ -25,7 +25,7 @@ int foo() {
 }
 
 inline int __attribute__((target_version("sha1+pmull+f64mm"))) 
fmv_inline(void) { return 1; }
-inline int __attribute__((target_version("fp16+fcma+sme+ fp16 "))) 
fmv_inline(void) { return 2; }
+inline int __attribute__((target_version("fp16+fcma+rdma+sme+ fp16 "))) 
fmv_inline(void) { return 2; }
 inline int __attribute__((target_version("sha3+i8mm+f32mm"))) fmv_inline(void) 
{ return 12; }
 inline int __attribute__((target_version("dit+sve-ebf16"))) fmv_inline(void) { 
return 8; }
 inline int __attribute__((target_version("dpb+rcpc2 "))) fmv_inline(void) { 
return 6; }
@@ -261,12 +261,12 @@ int hoo(void) {
 // CHECK-NEXT:  resolver_entry:
 // CHECK-NEXT:call void @__init_cpu_features_resolver()
 // CHECK-NEXT:[[TMP0:%.*]] = load i64, ptr @__aarch64_cpu_features, align 8
-// CHECK-NEXT:[[TMP1:%.*]] = and i64 [[TMP0]], 4398048608256
-// CHECK-NEXT:[[TMP2:%.*]] = icmp eq i64 [[TMP1]], 4398048608256
+// CHECK-NEXT:[[TMP1:%.*]] = and i64 [[TMP0]], 4398048608320
+// CHECK-NEXT:[[TMP2:%.*]] = icmp eq i64 [[TMP1]], 4398048608320
 // CHECK-NEXT:[[TMP3:%.*]] = and i1 true, [[TMP2]]
 // CHECK-NEXT:br i1 [[TMP3]], label [[RESOLVER_RETURN:%.*]], label 
[[RESOLVER_ELSE:%.*]]
 // CHECK:   resolver_return:
-// CHECK-NEXT:ret ptr @fmv_inline._MfcmaMfp16Mfp16Msme
+// CHECK-NEXT:ret ptr @fmv_inline._MfcmaMfp16Mfp16MrdmMsme
 // CHECK:   resolver_else:
 // CHECK-NEXT:[[TMP4:%.*]] = load i64, ptr @__aarch64_cpu_features, align 8
 // CHECK-NEXT:[[TMP5:%.*]] = and i64 [[TMP4]], 864726312827224064
@@ -575,7 +575,7 @@ int hoo(void) {
 //
 //
 // CHECK: Function Attrs: noinline nounwind optnone
-// CHECK-LABEL: define {{[^@]+}}@fmv_inline._MfcmaMfp16Mfp16Msme
+// CHECK-LABEL: define {{[^@]+}}@fmv_inline._MfcmaMfp16Mfp16MrdmMsme
 // CHECK-SAME: () #[[ATTR13:[0-9]+]] {
 // CHECK-NEXT:  entry:
 // CHECK-NEXT:ret i32 2
@@ -829,7 +829,7 @@ int hoo(void) {
 // CHECK: attributes #[[ATTR10]] = { noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-features"="+bf16,+fullfp16,+ls64,+sme,+sme2" }
 // CHECK: attributes #[[ATTR11]] = { noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-features"="+ccpp,+fullfp16,+ls64" }
 // CHECK: attributes #[[ATTR12]] = { noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-features"="+aes,+f64mm,+fp-armv8,+fullfp16,+ls64,+neon,+sve" }
-// CHECK: attributes #[[ATTR13]] = { noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-features"="+bf16,+complxnum,+fp-armv8,+fullfp16,+ls64,+neon,+sme" }
+// CHECK: attributes #[[ATTR13]] = { noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-feature

[clang] [llvm] [TargetParser][AArch64] Add alias for FEAT_RDM. (PR #80540)

2024-03-01 Thread Alexandros Lamprineas via cfe-commits

labrinea wrote:

ping

https://github.com/llvm/llvm-project/pull/80540
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][AMDGPU] Don't define feature macros on host code (PR #83558)

2024-03-01 Thread Pierre van Houtryve via cfe-commits

https://github.com/Pierre-vh updated 
https://github.com/llvm/llvm-project/pull/83558

>From 3730631ac58425f559f4bc3cfe3da89e6367c1c5 Mon Sep 17 00:00:00 2001
From: pvanhout 
Date: Fri, 1 Mar 2024 12:43:55 +0100
Subject: [PATCH 1/2] [clang][AMDGPU] Don't define feature macros on host code

Those macros are unreliable because our features are mostly uninitialized at 
that stage, so any macro we define is unreliable.

Fixes SWDEV-447308
---
 clang/lib/Basic/Targets/AMDGPU.cpp   | 8 +++-
 clang/test/Preprocessor/predefined-arch-macros.c | 2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/clang/lib/Basic/Targets/AMDGPU.cpp 
b/clang/lib/Basic/Targets/AMDGPU.cpp
index 5742885df0461b..df9a5855068ed3 100644
--- a/clang/lib/Basic/Targets/AMDGPU.cpp
+++ b/clang/lib/Basic/Targets/AMDGPU.cpp
@@ -292,8 +292,14 @@ void AMDGPUTargetInfo::getTargetDefines(const LangOptions 
&Opts,
   }
 
   Builder.defineMacro(Twine("__") + Twine(CanonName) + Twine("__"));
+
+  // Don't emit feature macros in host code because in such cases the
+  // feature list is not accurate.
+  if (IsHIPHost)
+return;
+
   // Emit macros for gfx family e.g. gfx906 -> __GFX9__, gfx1030 -> __GFX10___
-  if (isAMDGCN(getTriple()) && !IsHIPHost) {
+  if (isAMDGCN(getTriple())) {
 assert(StringRef(CanonName).starts_with("gfx") &&
"Invalid amdgcn canonical name");
 StringRef CanonFamilyName = getArchFamilyNameAMDGCN(GPUKind);
diff --git a/clang/test/Preprocessor/predefined-arch-macros.c 
b/clang/test/Preprocessor/predefined-arch-macros.c
index ca51f2fc22c517..8904bcea1a1f68 100644
--- a/clang/test/Preprocessor/predefined-arch-macros.c
+++ b/clang/test/Preprocessor/predefined-arch-macros.c
@@ -4340,7 +4340,7 @@
 // RUN: %clang -x hip -E -dM %s -o - 2>&1 --offload-host-only -nogpulib \
 // RUN: -nogpuinc --offload-arch=gfx803 -target x86_64-unknown-linux \
 // RUN:   | FileCheck -match-full-lines %s -check-prefixes=CHECK_HIP_HOST
-// CHECK_HIP_HOST: #define __AMDGCN_WAVEFRONT_SIZE__ 64
+// CHECK_HIP_HOST-NOT: #define __AMDGCN_WAVEFRONT_SIZE__ 64
 // CHECK_HIP_HOST: #define __AMDGPU__ 1
 // CHECK_HIP_HOST: #define __AMD__ 1
 

>From a60d9fa16876b90a69b60de429261a3d10404f7a Mon Sep 17 00:00:00 2001
From: pvanhout 
Date: Fri, 1 Mar 2024 13:56:46 +0100
Subject: [PATCH 2/2] use CudaIssDevice

---
 clang/lib/Basic/Targets/AMDGPU.cpp|   2 +-
 .../CodeGenOpenCL/builtins-amdgcn-wave32.cl   |   2 +-
 clang/test/Driver/amdgpu-macros.cl| 212 +-
 clang/test/Driver/target-id-macros.cl |  10 +-
 .../Preprocessor/predefined-arch-macros.c |   6 +-
 5 files changed, 116 insertions(+), 116 deletions(-)

diff --git a/clang/lib/Basic/Targets/AMDGPU.cpp 
b/clang/lib/Basic/Targets/AMDGPU.cpp
index df9a5855068ed3..0c5f6bb13ec2eb 100644
--- a/clang/lib/Basic/Targets/AMDGPU.cpp
+++ b/clang/lib/Basic/Targets/AMDGPU.cpp
@@ -295,7 +295,7 @@ void AMDGPUTargetInfo::getTargetDefines(const LangOptions 
&Opts,
 
   // Don't emit feature macros in host code because in such cases the
   // feature list is not accurate.
-  if (IsHIPHost)
+  if (!Opts.CUDAIsDevice)
 return;
 
   // Emit macros for gfx family e.g. gfx906 -> __GFX9__, gfx1030 -> __GFX10___
diff --git a/clang/test/CodeGenOpenCL/builtins-amdgcn-wave32.cl 
b/clang/test/CodeGenOpenCL/builtins-amdgcn-wave32.cl
index da1ae244431556..de3020fdb6f98f 100644
--- a/clang/test/CodeGenOpenCL/builtins-amdgcn-wave32.cl
+++ b/clang/test/CodeGenOpenCL/builtins-amdgcn-wave32.cl
@@ -42,6 +42,6 @@ void test_read_exec_hi(global uint* out) {
   *out = __builtin_amdgcn_read_exec_hi();
 }
 
-#if __AMDGCN_WAVEFRONT_SIZE != 32
+#if defined(__AMDGCN_WAVEFRONT_SIZE) && __AMDGCN_WAVEFRONT_SIZE != 32
 #error Wrong wavesize detected
 #endif
diff --git a/clang/test/Driver/amdgpu-macros.cl 
b/clang/test/Driver/amdgpu-macros.cl
index 004619321b271f..1f03ccc6ab9223 100644
--- a/clang/test/Driver/amdgpu-macros.cl
+++ b/clang/test/Driver/amdgpu-macros.cl
@@ -6,32 +6,32 @@
 // R600-based processors.
 //
 
-// RUN: %clang -E -dM -target r600 -mcpu=r600 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,R600 %s -DCPU=r600
-// RUN: %clang -E -dM -target r600 -mcpu=rv630 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,R600 %s -DCPU=r600
-// RUN: %clang -E -dM -target r600 -mcpu=rv635 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,R600 %s -DCPU=r600
-// RUN: %clang -E -dM -target r600 -mcpu=r630 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,R630 %s -DCPU=r630
-// RUN: %clang -E -dM -target r600 -mcpu=rs780 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,RS880 %s -DCPU=rs880
-// RUN: %clang -E -dM -target r600 -mcpu=rs880 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,RS880 %s -DCPU=rs880
-// RUN: %clang -E -dM -target r600 -mcpu=rv610 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,RS880 %s -DCPU=rs880
-// RUN: %clang -E -dM -target r600 -mcpu=rv620 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,RS880 %s -DCPU=rs880
-// RUN: %clang -E -dM -target r600 -

[clang] [clang] Sequence C++20 Parenthesized List Init (PR #83476)

2024-03-01 Thread Douglas Deslauriers via cfe-commits

https://github.com/vapdrs edited https://github.com/llvm/llvm-project/pull/83476
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Sema] -Wpointer-bool-conversion: suppress lambda function pointer conversion diagnostic during instantiation (PR #83497)

2024-03-01 Thread Aaron Ballman via cfe-commits

https://github.com/AaronBallman edited 
https://github.com/llvm/llvm-project/pull/83497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Sema] -Wpointer-bool-conversion: suppress lambda function pointer conversion diagnostic during instantiation (PR #83497)

2024-03-01 Thread Aaron Ballman via cfe-commits


@@ -92,6 +92,19 @@ void foo() {
   bool is_true = [](){ return true; };
   // expected-warning@-1{{address of lambda function pointer conversion 
operator will always evaluate to 'true'}}
 }
+
+template 
+static bool IsFalse(const Ts&...) { return false; }
+template 
+static bool IsFalse(const T& p) {
+  bool b;
+  b = f7; // expected-warning {{address of lambda function pointer conversion 
operator will always evaluate to 'true'}}
+  return p ? false : true;

AaronBallman wrote:

```suggestion
  // Intentionally not warned on because p could be a lambda type in one 
instantiation, but a pointer
  // type in another.
  return p ? false : true;
```
(May need to adjust for 80-col limits.)

https://github.com/llvm/llvm-project/pull/83497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [Sema] -Wpointer-bool-conversion: suppress lambda function pointer conversion diagnostic during instantiation (PR #83497)

2024-03-01 Thread Aaron Ballman via cfe-commits

https://github.com/AaronBallman approved this pull request.

LGTM with a minor commenting nit. Thank you for catching this and the quick 
patch!

https://github.com/llvm/llvm-project/pull/83497
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [AMDGPU] Enable OpenCL hostcall printf (WIP) (PR #72556)

2024-03-01 Thread Vikram Hegde via cfe-commits


@@ -3616,6 +3617,12 @@ unsigned FunctionDecl::getBuiltinID(bool 
ConsiderWrapperFunctions) const {
   if (!ConsiderWrapperFunctions && getStorageClass() == SC_Static)
 return 0;
 
+  // AMDGCN implementation supports printf as a builtin
+  // for OpenCL
+  if (Context.getTargetInfo().getTriple().isAMDGCN() &&
+  Context.getLangOpts().OpenCL && BuiltinID == AMDGPU::BIprintf)
+return BuiltinID;

vikramRH wrote:

The signatures of C-printf and OCL printf differ and I dont think generic 
builtin handling provides a way to register overloaded builtins with "shared" 
builtin ID's. do you have any alternate suggestions here ?

https://github.com/llvm/llvm-project/pull/72556
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [AMDGPU] Enable OpenCL hostcall printf (WIP) (PR #72556)

2024-03-01 Thread Vikram Hegde via cfe-commits


@@ -2550,6 +2550,11 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl 
GD, unsigned BuiltinID,
   &getTarget().getLongDoubleFormat() == &llvm::APFloat::IEEEquad())
 BuiltinID = mutateLongDoubleBuiltin(BuiltinID);
 
+  // Mutate the printf builtin ID so that we use the same CodeGen path for
+  // HIP and OpenCL with AMDGPU targets.
+  if (getTarget().getTriple().isAMDGCN() && BuiltinID == AMDGPU::BIprintf)
+BuiltinID = Builtin::BIprintf;

vikramRH wrote:

This can be removed if you feel so, probably we would need a new case in Expr 
CodeGen

https://github.com/llvm/llvm-project/pull/72556
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] Fix implementation of [temp.param]p14's first sentence. (PR #83487)

2024-03-01 Thread Aaron Ballman via cfe-commits

https://github.com/AaronBallman commented:

The changes look correct to me, but I think we should add a DR test for this so 
that we can properly regenerate cxx_dr_status.html

Also, the changes should come with a release note.

https://github.com/llvm/llvm-project/pull/83487
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [AMDGPU] Enable OpenCL hostcall printf (WIP) (PR #72556)

2024-03-01 Thread Vikram Hegde via cfe-commits


@@ -202,12 +207,20 @@ RValue 
CodeGenFunction::EmitAMDGPUDevicePrintfCallExpr(const CallExpr *E) {
 Args.push_back(Arg);
   }
 
-  llvm::IRBuilder<> IRB(Builder.GetInsertBlock(), Builder.GetInsertPoint());
-  IRB.SetCurrentDebugLocation(Builder.getCurrentDebugLocation());
+  auto PFK = CGM.getTarget().getTargetOpts().AMDGPUPrintfKindVal;
+  bool isBuffered = (PFK == clang::TargetOptions::AMDGPUPrintfKind::Buffered);
+
+  StringRef FmtStr;
+  if (llvm::getConstantStringInfo(Args[0], FmtStr)) {
+if (FmtStr.empty())
+  FmtStr = StringRef("", 1);

vikramRH wrote:

not really. This is just to say the format string is not really empty (i.e size 
= 0) when the user input is an empty format string (a weird corner case)

https://github.com/llvm/llvm-project/pull/72556
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Sequence C++20 Parenthesized List Init (PR #83476)

2024-03-01 Thread Douglas Deslauriers via cfe-commits

https://github.com/vapdrs updated 
https://github.com/llvm/llvm-project/pull/83476

>From f66254c6be64a7270ce2df8556c540344ade0619 Mon Sep 17 00:00:00 2001
From: Douglas Deslauriers 
Date: Thu, 29 Feb 2024 20:18:34 +
Subject: [PATCH] [clang] Sequence C++20 Parenthesized List Init

Parenthesized list intializers are sequenced operations, see C++20
[decl.init]p16.5 and [decl.init]p16.6.2.2 for more details.

Fixes #83474
---
 clang/lib/Sema/SemaChecking.cpp   | 30 +--
 .../warn-unsequenced-paren-list-init.cpp  | 15 ++
 2 files changed, 29 insertions(+), 16 deletions(-)
 create mode 100644 clang/test/SemaCXX/warn-unsequenced-paren-list-init.cpp

diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 7be2b31df2413f..e14b8600818c1b 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -17617,20 +17617,8 @@ class SequenceChecker : public 
ConstEvaluatedExprVisitor {
   return VisitExpr(CCE);
 
 // In C++11, list initializations are sequenced.
-SmallVector Elts;
-SequenceTree::Seq Parent = Region;
-for (CXXConstructExpr::const_arg_iterator I = CCE->arg_begin(),
-  E = CCE->arg_end();
- I != E; ++I) {
-  Region = Tree.allocate(Parent);
-  Elts.push_back(Region);
-  Visit(*I);
-}
-
-// Forget that the initializers are sequenced.
-Region = Parent;
-for (unsigned I = 0; I < Elts.size(); ++I)
-  Tree.merge(Elts[I]);
+SequenceExpressionsInOrder(
+llvm::ArrayRef(CCE->getArgs(), CCE->getNumArgs()));
   }
 
   void VisitInitListExpr(const InitListExpr *ILE) {
@@ -17638,10 +17626,20 @@ class SequenceChecker : public 
ConstEvaluatedExprVisitor {
   return VisitExpr(ILE);
 
 // In C++11, list initializations are sequenced.
+SequenceExpressionsInOrder(ILE->inits());
+  }
+
+  void VisitCXXParenListInitExpr(const CXXParenListInitExpr *PLIE) {
+// C++20 parenthesized list initializations are sequenced. See C++20
+// [decl.init.general]p16.5 and [decl.init.general]p16.6.2.2.
+SequenceExpressionsInOrder(PLIE->getInitExprs());
+  }
+
+private:
+  void SequenceExpressionsInOrder(ArrayRef ExpressionList) {
 SmallVector Elts;
 SequenceTree::Seq Parent = Region;
-for (unsigned I = 0; I < ILE->getNumInits(); ++I) {
-  const Expr *E = ILE->getInit(I);
+for (const Expr *E : ExpressionList) {
   if (!E)
 continue;
   Region = Tree.allocate(Parent);
diff --git a/clang/test/SemaCXX/warn-unsequenced-paren-list-init.cpp 
b/clang/test/SemaCXX/warn-unsequenced-paren-list-init.cpp
new file mode 100644
index 00..5aeeb45f81e226
--- /dev/null
+++ b/clang/test/SemaCXX/warn-unsequenced-paren-list-init.cpp
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -Wno-unused -Wunsequenced -verify 
%s
+
+struct A {
+  int x, y;
+};
+
+void test() {
+  int a = 0;
+
+  A agg1( a++, a++ ); // no warning
+  A agg2( a++ + a, a++ ); // expected-warning {{unsequenced modification and 
access to 'a'}}
+
+  int arr1[]( a++, a++ ); // no warning
+  int arr2[]( a++ + a, a++ ); // expected-warning {{unsequenced modification 
and access to 'a'}}
+}

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


[clang] [analyzer] Improve some comments in ArrayBoundCheckerV2 (NFC) (PR #83545)

2024-03-01 Thread via cfe-commits
=?utf-8?q?Donát?= Nagy 
Message-ID:
In-Reply-To: 



@@ -301,21 +301,27 @@ compareValueToThreshold(ProgramStateRef State, NonLoc 
Value, NonLoc Threshold,
   // calling `evalBinOpNN`:
   if (isNegative(SVB, State, Value) && isUnsigned(SVB, Threshold)) {
 if (CheckEquality) {
-  // negative_value == unsigned_value is always false
+  // negative_value == unsigned_threshold is always false
   return {nullptr, State};
 }
-// negative_value < unsigned_value is always false
+// negative_value < unsigned_threshold is always true
 return {State, nullptr};
   }
   if (isUnsigned(SVB, Value) && isNegative(SVB, State, Threshold)) {
-// unsigned_value == negative_value and unsigned_value < negative_value are
-// both always false
+// unsigned_value == negative_threshold and
+// unsigned_value < negative_threshold are both always false

NagyDonat wrote:

I'm mentioning them separately because these are separate cases in this 
function. (It may check either "value < threshold" or "value == threshold" 
depending on the last argument.)

https://github.com/llvm/llvm-project/pull/83545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [openmp] [OpenMP] Respect LLVM per-target install directories (PR #83282)

2024-03-01 Thread Joseph Huber via cfe-commits

jhuber6 wrote:

> Hi @jhuber6, @MaskRay
> 
> We are having some problems with this patch on a server where the file 
> /lib64/libomptarget-nvptx-sm_52.bc exists. The test case that fails is 
> clang/test/Driver/openmp-offload-gpu.c.
> 
> **Problem 1** I think one problem is related to this check line `// 
> CHK-ENV-BCLIB: 
> clang{{.*}}-triple{{.*}}nvptx64-nvidia-cuda{{.*}}-mlink-builtin-bitcode{{.*}}subdir{{/|}}libomptarget-nvptx-sm_52.bc
>  ` That test is using `env LIBRARY_PATH` but your changes in 
> `tools::addOpenMPDeviceRTL` makes it prioritize the standard library paths 
> before the environment. Not sure if that is how it should be or if env should 
> have higher prio (i.e. added to LibraryPaths before the paths found in 
> HostTC).
> 
> **Problem 2** This check line also started failing: `// CHK-BCLIB-WARN: no 
> library 'libomptarget-nvptx-sm_52.bc' found in the default clang lib 
> directory or in LIBRARY_PATH; use '--libomptarget-nvptx-bc-path' to specify 
> nvptx bitcode library `
> 
> Now, with your path, I guess it starts picking up the 
> `/lib64/libomptarget-nvptx-sm_52.bc` file from the system. So we no longer 
> get the warning. Is that the intention with your patch? Regardless, I think 
> you need to do something with that test case because I think the "should 
> never exist" part in
> 
> ```
> /// Check that the warning is thrown when the libomptarget bitcode library is 
> not found.
> /// Libomptarget requires sm_52 or newer so an sm_52 bitcode library should 
> never exist.
> ```
> 
> no longer holds with your patch.

I think it's standard to prioritize library path stuff. Does this work if you 
just flip the order we fill the library search path? I think the behavioral 
change here is that we didn't used to look in the system directory.

https://github.com/llvm/llvm-project/pull/83282
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [lld] [llvm] [RISCV] Support .note.gnu.property for enable Zicfiss and Zicfilp extension (PR #77414)

2024-03-01 Thread Kito Cheng via cfe-commits

https://github.com/kito-cheng edited 
https://github.com/llvm/llvm-project/pull/77414
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Bugfix for choosing the more specialized overload (PR #83279)

2024-03-01 Thread Botond István Horváth via cfe-commits

https://github.com/HoBoIs updated 
https://github.com/llvm/llvm-project/pull/83279

From 68200ecf3267d1b3940fa73c25c50ee706932a98 Mon Sep 17 00:00:00 2001
From: Botond Istvan Horvath 
Date: Wed, 28 Feb 2024 13:09:15 +0100
Subject: [PATCH 1/5] Bugfix for choosing the more specialized overload

There was a bug in clang where it couldn't choose which overload candidate is
more specialized if it was comparing a member-function to a non-member
function. Previously, this was detected as an ambigouity, now clang chooses 
correctly.

This patch fixes the bug by fully implementing CWG2445 and moving the template
transformation described in [temp.func.order] paragraph 3 from
isAtLeastAsSpecializedAs to Sema::getMoreSpecializedTemplate so we have the
transformed parameter list during the whole comperrassion. Also, to be able
to add the correct type for the implicit object parameter
Sema::getMoreSpecializedTemplate has new parameters for the object type.
---
 clang/include/clang/Sema/Sema.h  |   4 +-
 clang/lib/Sema/SemaOverload.cpp  |  12 +-
 clang/lib/Sema/SemaTemplateDeduction.cpp | 263 +++
 3 files changed, 186 insertions(+), 93 deletions(-)

diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index ef4b93fac95ce5..1a2a3a6bebd95e 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -9463,7 +9463,9 @@ class Sema final {
   FunctionTemplateDecl *getMoreSpecializedTemplate(
   FunctionTemplateDecl *FT1, FunctionTemplateDecl *FT2, SourceLocation Loc,
   TemplatePartialOrderingContext TPOC, unsigned NumCallArguments1,
-  unsigned NumCallArguments2, bool Reversed = false);
+  unsigned NumCallArguments2, QualType ObjType1 = {},
+  QualType ObjType2 = {}, bool Reversed = false);
+
   UnresolvedSetIterator
   getMostSpecialized(UnresolvedSetIterator SBegin, UnresolvedSetIterator SEnd,
  TemplateSpecCandidateSet &FailedCandidates,
diff --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index 7d38043890ca20..60138236abf1d8 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -10526,14 +10526,24 @@ bool clang::isBetterOverloadCandidate(
   //  according to the partial ordering rules described in 14.5.5.2, or,
   //  if not that,
   if (Cand1IsSpecialization && Cand2IsSpecialization) {
+const auto *ObjContext1 =
+dyn_cast(Cand1.FoundDecl->getDeclContext());
+const auto *ObjContext2 =
+dyn_cast(Cand2.FoundDecl->getDeclContext());
 if (FunctionTemplateDecl *BetterTemplate = S.getMoreSpecializedTemplate(
 Cand1.Function->getPrimaryTemplate(),
 Cand2.Function->getPrimaryTemplate(), Loc,
 isa(Cand1.Function) ? TPOC_Conversion
: TPOC_Call,
 Cand1.ExplicitCallArguments, Cand2.ExplicitCallArguments,
-Cand1.isReversed() ^ Cand2.isReversed()))
+ObjContext1 ? QualType(ObjContext1->getTypeForDecl(), 0)
+: QualType{},
+ObjContext2 ? QualType(ObjContext2->getTypeForDecl(), 0)
+: QualType{},
+Cand1.isReversed() ^ Cand2.isReversed())) {
   return BetterTemplate == Cand1.Function->getPrimaryTemplate();
+}
+
   }
 
   //   -— F1 and F2 are non-template functions with the same
diff --git a/clang/lib/Sema/SemaTemplateDeduction.cpp 
b/clang/lib/Sema/SemaTemplateDeduction.cpp
index 563491f76f5478..2af3c29ae1f1c4 100644
--- a/clang/lib/Sema/SemaTemplateDeduction.cpp
+++ b/clang/lib/Sema/SemaTemplateDeduction.cpp
@@ -5333,11 +5333,31 @@ bool 
Sema::CheckIfFunctionSpecializationIsImmediate(FunctionDecl *FD,
   return false;
 }
 
+static QualType GetImplicitObjectParameterTypeCXX20(ASTContext &Context,
+const CXXMethodDecl 
*Method,
+QualType rawType,
+bool isOtherRvr) {
+  // C++20 [temp.func.order]p3.1, p3.2:
+  //- The type X(M ) is “rvalue reference to cv A” if the optional 
ref-qualifier
+  //  of M is && or if M has no ref-qualifier and the 
positionally-corresponding
+  //  parameter of the other transformed template has rvalue reference type;
+  //  if this determination depends recursively upon whether X(M ) is an rvalue
+  //  reference type, it is not considered to have rvalue reference type.
+  //- Otherwise, X(M ) is “lvalue reference to cv A”.
+  assert(Method && !Method->isExplicitObjectMemberFunction() &&
+ "expected a member function with no explicit object parameter");
+
+  rawType = Context.getQualifiedType(rawType, Method->getMethodQualifiers());
+  if (Method->getRefQualifier() == RQ_RValue ||
+  (isOtherRvr && Method->getRefQualifier() == RQ_None))
+return Context.getRValueReferenceType(rawType);
+  return Context.getLValueReferenceType(

[clang] [lld] [llvm] [RISCV] Support .note.gnu.property for enable Zicfiss and Zicfilp extension (PR #77414)

2024-03-01 Thread via cfe-commits

llvmbot wrote:




@llvm/pr-subscribers-backend-risc-v

Author: None (SuHo-llrr)


Changes

Emit Zicfiss/Zicfilp to .note.gnu.property sections

1. for spec v0.4.0 Zicifss/Zicfilp is AND feature means that all objects need 
to have this feature.
2. Emit note section when Zicifss/Zicfilp extension is enabled.
3. Checking all objects enable Zicifss/Zicfilp when linking.
4. Add -zforce-zicfilp/-zforce-zicfiss options to force emit Zicifss/Zicfilp 
flags on in .note.gnu.property

Ref:  https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/417


---

Patch is 20.21 KiB, truncated to 20.00 KiB below, full version: 
https://github.com/llvm/llvm-project/pull/77414.diff


10 Files Affected:

- (added) clang/test/Driver/riscv-cfi-property.c (+29) 
- (modified) lld/ELF/Config.h (+4) 
- (modified) lld/ELF/Driver.cpp (+40-2) 
- (modified) lld/ELF/InputFiles.cpp (+12-3) 
- (modified) lld/ELF/SyntheticSections.cpp (+12-3) 
- (added) lld/test/ELF/riscv-force-cfi-property.s (+35) 
- (modified) llvm/include/llvm/BinaryFormat/ELF.h (+7) 
- (modified) llvm/lib/Target/RISCV/MCTargetDesc/RISCVELFStreamer.cpp (+43) 
- (modified) llvm/lib/Target/RISCV/MCTargetDesc/RISCVELFStreamer.h (+1) 
- (modified) llvm/tools/llvm-readobj/ELFDumper.cpp (+34-15) 


``diff
diff --git a/clang/test/Driver/riscv-cfi-property.c 
b/clang/test/Driver/riscv-cfi-property.c
new file mode 100644
index 00..7a4044c9328dc4
--- /dev/null
+++ b/clang/test/Driver/riscv-cfi-property.c
@@ -0,0 +1,29 @@
+// When -march with zicfiss0p4 or zicfilp0p4 add GNU property to file object
+
+// RUN: %clang --target=riscv32-linux-gnu -menable-experimental-extensions 
-march=rv32gc_zicfiss0p4 -c -o - %s | llvm-readobj -n - | FileCheck 
-check-prefix=CHECK -check-prefix=CHECK_ZICFISS %s
+// RUN: %clang --target=riscv64-linux-gnu -menable-experimental-extensions 
-march=rv64gc_zicfiss0p4 -c -o - %s | llvm-readobj -n - | FileCheck 
-check-prefix=CHECK -check-prefix=CHECK_ZICFISS %s
+// RUN: %clang --target=riscv32-linux-gnu -menable-experimental-extensions 
-march=rv32gc_zicfilp0p4 -c -o - %s | llvm-readobj -n - | FileCheck 
-check-prefix=CHECK -check-prefix=CHECK_ZICFILP %s
+// RUN: %clang --target=riscv64-linux-gnu -menable-experimental-extensions 
-march=rv64gc_zicfilp0p4 -c -o - %s | llvm-readobj -n - | FileCheck 
-check-prefix=CHECK -check-prefix=CHECK_ZICFILP %s
+// RUN: %clang --target=riscv32-linux-gnu -menable-experimental-extensions 
-march=rv32gc_zicfilp0p4_zicfiss0p4 -c -o - %s | llvm-readobj -n - | FileCheck 
-check-prefix=CHECK -check-prefix=CHECK_ZICFILP_ZICFISS %s
+// RUN: %clang --target=riscv64-linux-gnu -menable-experimental-extensions 
-march=rv64gc_zicfilp0p4_zicfiss0p4 -c -o - %s | llvm-readobj -n - | FileCheck 
-check-prefix=CHECK -check-prefix=CHECK_ZICFILP_ZICFISS %s
+
+
+// CHECK: Name: .note.gnu.property
+// CHECK: Type: NT_GNU_PROPERTY_TYPE_0
+// CHECK: Property [
+// CHECK_ZICFISS: riscv feature: ZICFISS
+// CHECK_ZICFILP: riscv feature: ZICFILP
+// CHECK_ZICFILP_ZICFISS: riscv feature: ZICFILP, ZICFISS
+// CHECK: ]
+
+// GNU Note Section Example
+/*.section .note.gnu.property, "a";
+.balign 8;
+.long 0x4;
+.long 0x10;
+.long 0x5
+.asciz "GNU"
+.long 0xc000
+.long 4
+.long 3
+.long 0*/
diff --git a/lld/ELF/Config.h b/lld/ELF/Config.h
index fcca8c42b29b71..552a5060452729 100644
--- a/lld/ELF/Config.h
+++ b/lld/ELF/Config.h
@@ -187,6 +187,8 @@ struct Config {
   llvm::StringRef cmseOutputLib;
   StringRef zBtiReport = "none";
   StringRef zCetReport = "none";
+  llvm::StringRef zZicfilpReport = "none";
+  llvm::StringRef zZicfissReport = "none";
   bool ltoBBAddrMap;
   llvm::StringRef ltoBasicBlockSections;
   std::pair thinLTOObjectSuffixReplace;
@@ -324,6 +326,8 @@ struct Config {
   bool zText;
   bool zRetpolineplt;
   bool zWxneeded;
+  bool zForceZicfilp;
+  bool zForceZicfiss;
   DiscardPolicy discard;
   GnuStackKind zGnustack;
   ICFLevel icf;
diff --git a/lld/ELF/Driver.cpp b/lld/ELF/Driver.cpp
index 4bb9b7a0b2a983..1791d275a4d00c 100644
--- a/lld/ELF/Driver.cpp
+++ b/lld/ELF/Driver.cpp
@@ -463,6 +463,13 @@ static void checkOptions() {
   error("-z bti-report only supported on AArch64");
   }
 
+  if (config->emachine != EM_RISCV) {
+if (config->zZicfilpReport != "none")
+  error("-z zicfilip-report only support on RISCV32/RISCV64");
+if (config->zZicfissReport != "none")
+  error("-z zicfiss-report only support on RISCV32/RISCV64");
+  }
+
   if (config->emachine != EM_386 && config->emachine != EM_X86_64 &&
   config->zCetReport != "none")
 error("-z cet-report only supported on X86 and X86_64");
@@ -1455,6 +1462,8 @@ static void readConfigs(opt::InputArgList &args) {
   config->zWxneeded = hasZOption(args, "wxneeded");
   setUnresolvedSymbolPolicy(args);
   config->power10Stubs = args.getLastArgValue(OPT_power10_stubs_eq) != "no";
+  config->zForceZicfilp = hasZOption(args, "force-zicfilp");
+  config->zForceZicfiss = hasZOption(args, "force-zicfiss");
 
   if (opt::Arg *arg = args

[clang] [openmp] [OpenMP] Respect LLVM per-target install directories (PR #83282)

2024-03-01 Thread Björn Pettersson via cfe-commits

bjope wrote:

Problem 1 can be solved by flipping the order.
But Problem 2 would remain as it doesn't depend on the order.

https://github.com/llvm/llvm-project/pull/83282
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [llvm] [HLSL][DXIL] Implementation of round intrinsic (PR #83570)

2024-03-01 Thread Farzon Lotfi via cfe-commits

https://github.com/farzonl created 
https://github.com/llvm/llvm-project/pull/83570

hlsl_intrinsics.h - add the round  api
DXIL.td add the llvm intrinsic to DXIL lowering mapping 
This chane reuses llvms existing `__builtin_elementwise_round`\`int_round`
This change implements: #70077

>From 24325b14e63e20a44b7a8b51c426b88a337ff5fc Mon Sep 17 00:00:00 2001
From: Farzon Lotfi 
Date: Thu, 29 Feb 2024 21:48:47 -0500
Subject: [PATCH] [HLSL][DXIL] Implementation of round intrinsic
 hlsl_intrinsics.h - add the round  api DXIL.td add the llvm intrinsic to DXIL
 lowering mapping This change implements: #70077

---
 clang/lib/Headers/hlsl/hlsl_intrinsics.h  | 34 
 clang/test/CodeGenHLSL/builtins/round.hlsl| 53 +++
 .../test/SemaHLSL/BuiltIns/round-errors.hlsl  | 27 ++
 llvm/lib/Target/DirectX/DXIL.td   |  3 ++
 llvm/test/CodeGen/DirectX/round.ll| 43 +++
 5 files changed, 160 insertions(+)
 create mode 100644 clang/test/CodeGenHLSL/builtins/round.hlsl
 create mode 100644 clang/test/SemaHLSL/BuiltIns/round-errors.hlsl
 create mode 100644 llvm/test/CodeGen/DirectX/round.ll

diff --git a/clang/lib/Headers/hlsl/hlsl_intrinsics.h 
b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
index 0aa8651ba80dc4..312304e13979ff 100644
--- a/clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -831,6 +831,40 @@ uint64_t3 reversebits(uint64_t3);
 _HLSL_BUILTIN_ALIAS(__builtin_elementwise_bitreverse)
 uint64_t4 reversebits(uint64_t4);
 
+//===--===//
+// frac builtins
+//===--===//
+
+/// \fn T round(T x)
+/// \brief Rounds the specified value to the nearest integer. Halfway cases are
+/// rounded to the nearest even. \a x parameter. \param x The specified input
+/// value.
+///
+/// The return value is the \a x parameter, rounded to the nearest integer
+/// within a floating-point type.
+
+_HLSL_16BIT_AVAILABILITY(shadermodel, 6.2)
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+half round(half);
+_HLSL_16BIT_AVAILABILITY(shadermodel, 6.2)
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+half2 round(half2);
+_HLSL_16BIT_AVAILABILITY(shadermodel, 6.2)
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+half3 round(half3);
+_HLSL_16BIT_AVAILABILITY(shadermodel, 6.2)
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+half4 round(half4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+float round(float);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+float2 round(float2);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+float3 round(float3);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+float4 round(float4);
+
 
//===--===//
 // sin builtins
 
//===--===//
diff --git a/clang/test/CodeGenHLSL/builtins/round.hlsl 
b/clang/test/CodeGenHLSL/builtins/round.hlsl
new file mode 100644
index 00..b9f35bd3712d18
--- /dev/null
+++ b/clang/test/CodeGenHLSL/builtins/round.hlsl
@@ -0,0 +1,53 @@
+// RUN: %clang_cc1 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -fnative-half-type \
+// RUN:   -emit-llvm -disable-llvm-passes -o - | FileCheck %s \ 
+// RUN:   --check-prefixes=CHECK,NATIVE_HALF
+// RUN: %clang_cc1 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
+// RUN:   -o - | FileCheck %s --check-prefixes=CHECK,NO_HALF
+
+// NATIVE_HALF: define noundef half @
+// NATIVE_HALF: %elt.round = call half @llvm.round.f16(
+// NATIVE_HALF: ret half %elt.round
+// NO_HALF: define noundef float @"?test_round_half@@YA$halff@$halff@@Z"(
+// NO_HALF: %elt.round = call float @llvm.round.f32(
+// NO_HALF: ret float %elt.round
+half test_round_half(half p0) { return round(p0); }
+// NATIVE_HALF: define noundef <2 x half> @
+// NATIVE_HALF: %elt.round = call <2 x half> @llvm.round.v2f16
+// NATIVE_HALF: ret <2 x half> %elt.round
+// NO_HALF: define noundef <2 x float> @
+// NO_HALF: %elt.round = call <2 x float> @llvm.round.v2f32(
+// NO_HALF: ret <2 x float> %elt.round
+half2 test_round_half2(half2 p0) { return round(p0); }
+// NATIVE_HALF: define noundef <3 x half> @
+// NATIVE_HALF: %elt.round = call <3 x half> @llvm.round.v3f16
+// NATIVE_HALF: ret <3 x half> %elt.round
+// NO_HALF: define noundef <3 x float> @
+// NO_HALF: %elt.round = call <3 x float> @llvm.round.v3f32(
+// NO_HALF: ret <3 x float> %elt.round
+half3 test_round_half3(half3 p0) { return round(p0); }
+// NATIVE_HALF: define noundef <4 x half> @
+// NATIVE_HALF: %elt.round = call <4 x half> @llvm.round.v4f16
+// NATIVE_HALF: ret <4 x half> %elt.round
+// NO_HALF: define noundef <4 x float> @
+// NO_HALF: %elt.round = call <4 x float> @llvm.round.v4f32(
+// NO_HALF: ret <4 x float>

[clang] [llvm] [HLSL][DXIL] Implementation of round intrinsic (PR #83570)

2024-03-01 Thread via cfe-commits

llvmbot wrote:



@llvm/pr-subscribers-hlsl

@llvm/pr-subscribers-backend-directx

Author: Farzon Lotfi (farzonl)


Changes

hlsl_intrinsics.h - add the round  api
DXIL.td add the llvm intrinsic to DXIL lowering mapping 
This chane reuses llvms existing `__builtin_elementwise_round`\`int_round`
This change implements: #70077

---
Full diff: https://github.com/llvm/llvm-project/pull/83570.diff


5 Files Affected:

- (modified) clang/lib/Headers/hlsl/hlsl_intrinsics.h (+34) 
- (added) clang/test/CodeGenHLSL/builtins/round.hlsl (+53) 
- (added) clang/test/SemaHLSL/BuiltIns/round-errors.hlsl (+27) 
- (modified) llvm/lib/Target/DirectX/DXIL.td (+3) 
- (added) llvm/test/CodeGen/DirectX/round.ll (+43) 


``diff
diff --git a/clang/lib/Headers/hlsl/hlsl_intrinsics.h 
b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
index 0aa8651ba80dc4..312304e13979ff 100644
--- a/clang/lib/Headers/hlsl/hlsl_intrinsics.h
+++ b/clang/lib/Headers/hlsl/hlsl_intrinsics.h
@@ -831,6 +831,40 @@ uint64_t3 reversebits(uint64_t3);
 _HLSL_BUILTIN_ALIAS(__builtin_elementwise_bitreverse)
 uint64_t4 reversebits(uint64_t4);
 
+//===--===//
+// frac builtins
+//===--===//
+
+/// \fn T round(T x)
+/// \brief Rounds the specified value to the nearest integer. Halfway cases are
+/// rounded to the nearest even. \a x parameter. \param x The specified input
+/// value.
+///
+/// The return value is the \a x parameter, rounded to the nearest integer
+/// within a floating-point type.
+
+_HLSL_16BIT_AVAILABILITY(shadermodel, 6.2)
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+half round(half);
+_HLSL_16BIT_AVAILABILITY(shadermodel, 6.2)
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+half2 round(half2);
+_HLSL_16BIT_AVAILABILITY(shadermodel, 6.2)
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+half3 round(half3);
+_HLSL_16BIT_AVAILABILITY(shadermodel, 6.2)
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+half4 round(half4);
+
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+float round(float);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+float2 round(float2);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+float3 round(float3);
+_HLSL_BUILTIN_ALIAS(__builtin_elementwise_round)
+float4 round(float4);
+
 
//===--===//
 // sin builtins
 
//===--===//
diff --git a/clang/test/CodeGenHLSL/builtins/round.hlsl 
b/clang/test/CodeGenHLSL/builtins/round.hlsl
new file mode 100644
index 00..b9f35bd3712d18
--- /dev/null
+++ b/clang/test/CodeGenHLSL/builtins/round.hlsl
@@ -0,0 +1,53 @@
+// RUN: %clang_cc1 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -fnative-half-type \
+// RUN:   -emit-llvm -disable-llvm-passes -o - | FileCheck %s \ 
+// RUN:   --check-prefixes=CHECK,NATIVE_HALF
+// RUN: %clang_cc1 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
+// RUN:   -o - | FileCheck %s --check-prefixes=CHECK,NO_HALF
+
+// NATIVE_HALF: define noundef half @
+// NATIVE_HALF: %elt.round = call half @llvm.round.f16(
+// NATIVE_HALF: ret half %elt.round
+// NO_HALF: define noundef float @"?test_round_half@@YA$halff@$halff@@Z"(
+// NO_HALF: %elt.round = call float @llvm.round.f32(
+// NO_HALF: ret float %elt.round
+half test_round_half(half p0) { return round(p0); }
+// NATIVE_HALF: define noundef <2 x half> @
+// NATIVE_HALF: %elt.round = call <2 x half> @llvm.round.v2f16
+// NATIVE_HALF: ret <2 x half> %elt.round
+// NO_HALF: define noundef <2 x float> @
+// NO_HALF: %elt.round = call <2 x float> @llvm.round.v2f32(
+// NO_HALF: ret <2 x float> %elt.round
+half2 test_round_half2(half2 p0) { return round(p0); }
+// NATIVE_HALF: define noundef <3 x half> @
+// NATIVE_HALF: %elt.round = call <3 x half> @llvm.round.v3f16
+// NATIVE_HALF: ret <3 x half> %elt.round
+// NO_HALF: define noundef <3 x float> @
+// NO_HALF: %elt.round = call <3 x float> @llvm.round.v3f32(
+// NO_HALF: ret <3 x float> %elt.round
+half3 test_round_half3(half3 p0) { return round(p0); }
+// NATIVE_HALF: define noundef <4 x half> @
+// NATIVE_HALF: %elt.round = call <4 x half> @llvm.round.v4f16
+// NATIVE_HALF: ret <4 x half> %elt.round
+// NO_HALF: define noundef <4 x float> @
+// NO_HALF: %elt.round = call <4 x float> @llvm.round.v4f32(
+// NO_HALF: ret <4 x float> %elt.round
+half4 test_round_half4(half4 p0) { return round(p0); }
+
+// CHECK: define noundef float @
+// CHECK: %elt.round = call float @llvm.round.f32(
+// CHECK: ret float %elt.round
+float test_round_float(float p0) { return round(p0); }
+// CHECK: define noundef <2 x float> @
+// CHECK: %elt.round = call <2 x float> @llvm.round.v2f32
+// CHECK: ret <2 x float> %elt.round
+float2 test_round_float2(float2 p0) { return round(p0); 

[clang] [llvm] [HLSL][DXIL] Implementation of round intrinsic (PR #83570)

2024-03-01 Thread Farzon Lotfi via cfe-commits

https://github.com/farzonl edited 
https://github.com/llvm/llvm-project/pull/83570
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][AMDGPU] Don't define feature macros on host code (PR #83558)

2024-03-01 Thread Joseph Huber via cfe-commits

jhuber6 wrote:

This was the original behavior of my patch, but I reverted it because it broke 
all the HIP headers that were unintentionally relying on this. Has that been 
resolved?

https://github.com/llvm/llvm-project/pull/83558
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][AMDGPU] Don't define feature macros on host code (PR #83558)

2024-03-01 Thread Pierre van Houtryve via cfe-commits

Pierre-vh wrote:

> This was the original behavior of my patch, but I reverted it because it 
> broke all the HIP headers that were unintentionally relying on this. Has that 
> been resolved?

Was an issue opened for that? How many headers are affected?

https://github.com/llvm/llvm-project/pull/83558
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Bugfix for choosing the more specialized overload (PR #83279)

2024-03-01 Thread Vlad Serebrennikov via cfe-commits
Botond =?utf-8?q?István_Horváth?=,Botond Istvan Horvath
 ,Botond Istvan Horvath
 ,Botond Istvan Horvath
 
Message-ID:
In-Reply-To: 


https://github.com/Endilll edited 
https://github.com/llvm/llvm-project/pull/83279
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Bugfix for choosing the more specialized overload (PR #83279)

2024-03-01 Thread Vlad Serebrennikov via cfe-commits
Botond =?utf-8?q?Istv=C3=A1n_Horv=C3=A1th?=,Botond Istvan Horvath
 ,Botond Istvan Horvath
 ,Botond Istvan Horvath
 
Message-ID:
In-Reply-To: 


https://github.com/Endilll requested changes to this pull request.


https://github.com/llvm/llvm-project/pull/83279
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang] Bugfix for choosing the more specialized overload (PR #83279)

2024-03-01 Thread Vlad Serebrennikov via cfe-commits
Botond =?utf-8?q?István_Horváth?=,Botond Istvan Horvath
 ,Botond Istvan Horvath
 ,Botond Istvan Horvath
 
Message-ID:
In-Reply-To: 



@@ -14478,7 +14478,7 @@ C++ defect report implementation 
status
 https://cplusplus.github.io/CWG/issues/2445.html";>2445
 C++20
 Partial ordering with rewritten candidates
-Unknown
+Clang 18

Endilll wrote:

You shouldn't edit this file by hand. Instead, you should place a test in 
`/clang/test/CXX/drs/24xx.cpp` with a `// dr2445: 18` status, then run 
`/clang/www/make_cxx_dr_status` script. Follow the example of other tests in 
`24xx.cpp` while doing that.

https://github.com/llvm/llvm-project/pull/83279
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][AMDGPU] Don't define feature macros on host code (PR #83558)

2024-03-01 Thread Yaxun Liu via cfe-commits

yxsamliu wrote:

Did you try this patch with internal PSDB? This will likely break all HIP 
programs.

This is because HIP is single source program and users usually expect the 
common device-side predefined macros is seen in both host and device 
compilations. e.g. they could write a kernel using the wavefront size macro 
without conditioning the code for device only. In most cases, they do not care 
about whether the wavefront size macro is accurate in host side compilation. 
They just need it to be defined so that the code can be compiled.

This is unfortunate but I think at least the wavefront size macro needs to be 
kept for host compilation.

https://github.com/llvm/llvm-project/pull/83558
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [clang][AMDGPU] Don't define feature macros on host code (PR #83558)

2024-03-01 Thread Yaxun Liu via cfe-commits


@@ -6,32 +6,32 @@
 // R600-based processors.
 //
 
-// RUN: %clang -E -dM -target r600 -mcpu=r600 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,R600 %s -DCPU=r600
-// RUN: %clang -E -dM -target r600 -mcpu=rv630 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,R600 %s -DCPU=r600
-// RUN: %clang -E -dM -target r600 -mcpu=rv635 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,R600 %s -DCPU=r600
-// RUN: %clang -E -dM -target r600 -mcpu=r630 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,R630 %s -DCPU=r630
-// RUN: %clang -E -dM -target r600 -mcpu=rs780 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,RS880 %s -DCPU=rs880
-// RUN: %clang -E -dM -target r600 -mcpu=rs880 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,RS880 %s -DCPU=rs880
-// RUN: %clang -E -dM -target r600 -mcpu=rv610 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,RS880 %s -DCPU=rs880
-// RUN: %clang -E -dM -target r600 -mcpu=rv620 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,RS880 %s -DCPU=rs880
-// RUN: %clang -E -dM -target r600 -mcpu=rv670 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,RV670 %s -DCPU=rv670
-// RUN: %clang -E -dM -target r600 -mcpu=rv710 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,RV710 %s -DCPU=rv710
-// RUN: %clang -E -dM -target r600 -mcpu=rv730 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,RV730 %s -DCPU=rv730
-// RUN: %clang -E -dM -target r600 -mcpu=rv740 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,RV770 %s -DCPU=rv770
-// RUN: %clang -E -dM -target r600 -mcpu=rv770 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,RV770 %s -DCPU=rv770
-// RUN: %clang -E -dM -target r600 -mcpu=cedar %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,CEDAR %s -DCPU=cedar
-// RUN: %clang -E -dM -target r600 -mcpu=palm %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,CEDAR %s -DCPU=cedar
-// RUN: %clang -E -dM -target r600 -mcpu=cypress %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,CYPRESS %s -DCPU=cypress
-// RUN: %clang -E -dM -target r600 -mcpu=hemlock %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,CYPRESS %s -DCPU=cypress
-// RUN: %clang -E -dM -target r600 -mcpu=juniper %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,JUNIPER %s -DCPU=juniper
-// RUN: %clang -E -dM -target r600 -mcpu=redwood %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,REDWOOD %s -DCPU=redwood
-// RUN: %clang -E -dM -target r600 -mcpu=sumo %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,SUMO %s -DCPU=sumo
-// RUN: %clang -E -dM -target r600 -mcpu=sumo2 %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,SUMO %s -DCPU=sumo
-// RUN: %clang -E -dM -target r600 -mcpu=barts %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,BARTS %s -DCPU=barts
-// RUN: %clang -E -dM -target r600 -mcpu=caicos %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,CAICOS %s -DCPU=caicos
-// RUN: %clang -E -dM -target r600 -mcpu=aruba %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,CAYMAN %s -DCPU=cayman
-// RUN: %clang -E -dM -target r600 -mcpu=cayman %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,CAYMAN %s -DCPU=cayman
-// RUN: %clang -E -dM -target r600 -mcpu=turks %s 2>&1 | FileCheck 
--check-prefixes=ARCH-R600,TURKS %s -DCPU=turks
+// RUN: %clang -E -dM -Xclang -fcuda-is-device -target r600 -mcpu=r600 %s 2>&1 
| FileCheck --check-prefixes=ARCH-R600,R600 %s -DCPU=r600

yxsamliu wrote:

OpenCL code should depend on -fcuda-is-device since OpenCL code is always 
compiled for device

https://github.com/llvm/llvm-project/pull/83558
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] [analyzer] Refactor CallDescription match mode (NFC) (PR #83432)

2024-03-01 Thread Balázs Kéri via cfe-commits


@@ -27,20 +27,48 @@ class IdentifierInfo;
 
 namespace clang {
 namespace ento {
-
-enum CallDescriptionFlags : unsigned {
-  CDF_None = 0,
-
-  /// Describes a C standard function that is sometimes implemented as a macro
-  /// that expands to a compiler builtin with some __builtin prefix.
-  /// The builtin may as well have a few extra arguments on top of the 
requested
-  /// number of arguments.
-  CDF_MaybeBuiltin = 1 << 0,
-};
-
-/// This class represents a description of a function call using the number of
-/// arguments and the name of the function.
+/// A `CallDescription` is a pattern that can be used to _match_ calls
+/// based on the qualified name and the argument/parameter counts.
 class CallDescription {
+public:
+  enum class Mode {
+/// Match calls to functions from the C standard library. On some platforms
+/// some functions may be implemented as macros that expand to calls to
+/// built-in variants of the given functions, so in this mode we use some
+/// heuristics to recognize these implementation-defined variants:
+///  - We also accept calls where the name is derived from the specified
+///name by adding "__builtin" or similar prefixes/suffixes.
+///  - We also accept calls where the number of arguments or parameters is
+///greater than the specified value.
+/// For the exact heuristics, see CheckerContext::isCLibraryFunction().
+/// Note that functions whose declaration context is not a TU (e.g.
+/// methods, functions in namespaces) are not accepted as C library
+/// functions.
+/// FIXME: If I understand it correctly, this discards calls where C++ code
+/// refers a C library function through the namespace `std::` via headers
+/// like .
+CLibrary,

balazske wrote:

It is good if it can be used for any C library (or like) function. I saw cases 
at MallocChecker where it is not used, then it should be used in these cases 
too. If for some reason we want to find C library functions that are not 
"builtin" another mode (the "Unspecified") can be used. Probably it is OK if 
later this mode can find functions in the `std::` namespace.

https://github.com/llvm/llvm-project/pull/83432
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


  1   2   3   4   >