[clang] [clang][dataflow] Fix inaccuracies in `buildStmtToBasicBlockMap()`. (PR #82496)

[via cfe-commits]

martinboehme wrote:

> This is horrifying. It makes me think that we might want to revamp the 
> CfgBlock interface at some point.

Yes, there a quite a few surprises in the structure of the CFG that I've only 
discovered gradually over time. I'd also like to eliminate the sharp edges in 
the API, though I suspect that existing clients rely on the idiosyncrasies of 
the current API -- so we might have to introduce a second, parallel API for a 
while so we can migrate usage over gradually.

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

[clang] e899641 - [clang][dataflow] Fix inaccuracies in `buildStmtToBasicBlockMap()`. (#82496)

[via cfe-commits]

Author: martinboehme
Date: 2024-02-22T09:00:20+01:00
New Revision: e899641df2391179e8ec29ca14c53b09ae7ce85c

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

LOG: [clang][dataflow] Fix inaccuracies in `buildStmtToBasicBlockMap()`. 
(#82496)

See the comments added to the code for details on the inaccuracies that
have
now been fixed.

The patch adds tests that fail with the old implementation.

Added: 


Modified: 
clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp
clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Removed: 




diff  --git a/clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp 
b/clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp
index c9ebffe6f37801..8aed19544be6a2 100644
--- a/clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp
+++ b/clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp
@@ -39,8 +39,35 @@ buildStmtToBasicBlockMap(const CFG &Cfg) {
 
   StmtToBlock[Stmt->getStmt()] = Block;
 }
-if (const Stmt *TerminatorStmt = Block->getTerminatorStmt())
-  StmtToBlock[TerminatorStmt] = Block;
+  }
+  // Some terminator conditions don't appear as a `CFGElement` anywhere else -
+  // for example, this is true if the terminator condition is a `&&` or `||`
+  // operator.
+  // We associate these conditions with the block the terminator appears in,
+  // but only if the condition has not already appeared as a regular
+  // `CFGElement`. (The `insert()` below does nothing if the key already exists
+  // in the map.)
+  for (const CFGBlock *Block : Cfg) {
+if (Block != nullptr)
+  if (const Stmt *TerminatorCond = Block->getTerminatorCondition())
+StmtToBlock.insert({TerminatorCond, Block});
+  }
+  // Terminator statements typically don't appear as a `CFGElement` anywhere
+  // else, so we want to associate them with the block that they terminate.
+  // However, there are some important special cases:
+  // -  The conditional operator is a type of terminator, but it also appears
+  //as a regular `CFGElement`, and we want to associate it with the block
+  //in which it appears as a `CFGElement`.
+  // -  The `&&` and `||` operators are types of terminators, but like the
+  //conditional operator, they can appear as a regular `CFGElement` or
+  //as a terminator condition (see above).
+  // We process terminators last to make sure that we only associate them with
+  // the block they terminate if they haven't previously occurred as a regular
+  // `CFGElement` or as a terminator condition.
+  for (const CFGBlock *Block : Cfg) {
+if (Block != nullptr)
+  if (const Stmt *TerminatorStmt = Block->getTerminatorStmt())
+StmtToBlock.insert({TerminatorStmt, Block});
   }
   return StmtToBlock;
 }

diff  --git 
a/clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp 
b/clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
index 3bca9cced8d6f7..34f9b0b23719fe 100644
--- a/clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
+++ b/clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
@@ -77,17 +77,33 @@ class DataflowAnalysisTest : public Test {
 return runDataflowAnalysis(*CFCtx, Analysis, Env);
   }
 
+  /// Returns the `CFGBlock` containing `S` (and asserts that it exists).
+  const CFGBlock *blockForStmt(const Stmt &S) {
+const CFGBlock *Block = CFCtx->getStmtToBlock().lookup(&S);
+assert(Block != nullptr);
+return Block;
+  }
+
   template 
   const StateT &
   blockStateForStmt(const std::vector> &BlockStates,
-const Stmt *S) {
-const CFGBlock *Block = CFCtx->getStmtToBlock().lookup(S);
-assert(Block != nullptr);
-const std::optional &MaybeState = BlockStates[Block->getBlockID()];
+const Stmt &S) {
+const std::optional &MaybeState =
+BlockStates[blockForStmt(S)->getBlockID()];
 assert(MaybeState.has_value());
 return *MaybeState;
   }
 
+  /// Returns the first node that matches `Matcher` (and asserts that the match
+  /// was successful, i.e. the returned node is not null).
+  template 
+  const NodeT &matchNode(MatcherT Matcher) {
+const auto *Node = selectFirst(
+"node", match(Matcher.bind("node"), AST->getASTContext()));
+assert(Node != nullptr);
+return *Node;
+  }
+
   std::unique_ptr AST;
   std::unique_ptr CFCtx;
   std::unique_ptr DACtx;
@@ -130,6 +146,79 @@ TEST_F(DataflowAnalysisTest, 
DiagnoseFunctionDiagnoserCalledOnEachElement) {
" (Lifetime ends)\n")));
 }
 
+// Tests for the statement-to-block map.
+using StmtToBlockTest = DataflowAnalysisTest;
+
+TEST_F(StmtToBlockTest, ConditionalOperator) {
+  std::string Code = R"(
+v

[clang] [clang][dataflow] Fix inaccuracies in `buildStmtToBasicBlockMap()`. (PR #82496)

[via cfe-commits]

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

[clang] [clang][driver] Allow unaligned access on ARMv7 and higher by default (PR #82400)

[David Green via cfe-commits]

https://github.com/davemgreen commented:

> Unaligned accesses require that SCTLR.A is 0, SCTLR.U is 1, and that the 
> memory in question is configured as "normal" memory. Almost all operating 
> systems do in fact configure their registers/memory this way, but on 
> baremetal it's not really a safe assumption. Changing the default here is 
> basically guaranteed to break someone's code.
> 
> We could make the value judgement that the performance gain outweighs 
> breaking someone's code. Disabled unaligned access is a performance hit users 
> have a hard time discovering; incorrectly enabled unaligned access will 
> generate an obvious alignment fault on v7 and up.
> 
> On pre-v7 processors, you can get the old "rotate" behavior instead of a 
> fault. This is controlled by SCTLR.U on v6, but I don't think there's any 
> reason to expect the bit is configured the "right" way on baremetal. So 
> changing the default for v6 is a bit more dubious.
> 
> The tradeoffs might be a bit different for M-class processors; I think 
> unaligned access works by default there (except for v6m and v8m.baseline).
> 
> This change needs a release note.

The issue that we have found is that as both GCC and Arm Compiler default to 
-munaligned-access, users expect it to be the default. They only notice the 
much bigger codesize/worse performance and don't understand the reason without 
a lot of digging. You are certainly right that someone who has been using clang 
bare metal in the past might hit problems with the new default, but there is a 
high chance they are just using the wrong option without noticing. And I 
believe aligning with GCC/Arm Compiler is a better default going forward, as 
more people start using Clang in bare metal. Hopefully the release note can at 
least make it clear.

M-Profile needs a bit set in the bootcode, IIRC.

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

[clang] [clang][driver] Allow unaligned access on ARMv7 and higher by default (PR #82400)

[David Green via cfe-commits]

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

[clang] [clang][driver] Allow unaligned access on ARMv7 and higher by default (PR #82400)

[David Green via cfe-commits]

@@ -22,6 +22,12 @@
 // RUN: %clang -target armv7-windows -### %s 2> %t
 // RUN: FileCheck --check-prefix=CHECK-UNALIGNED-ARM < %t %s
 
+// RUN: %clang --target=armv6 -### %s 2> %t
+// RUN: FileCheck --check-prefix=CHECK-ALIGNED-ARM < %t %s
+
+// RUN: %clang --target=armv7 -### %s 2> %t

davemgreen wrote:

Can you add some extra tests for things like 8-m.main, 8-m.base and 6-m, to 
make sure we have coverage?

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

[clang] [clang][driver] Allow unaligned access on ARMv7 and higher by default (PR #82400)

[David Green via cfe-commits]

@@ -305,6 +305,17 @@ X86 Support
 Arm and AArch64 Support
 ^^^
 
+- ARMv7+ targets now default to allowing unaligned access, except Armv6-M, and
+  Armv8-M without the Main Extension. Baremetal targets should check that the
+  new default will work with their system configurations, since it requires
+  that SCTLR.A is 0, SCTLR.U is 1, and that the memory in question is
+  configured as "normal" memory. We've made the value judgment that the
+  performance gains here outweigh breakages, since it is difficult to identify
+  performance loss from disabling unaligned access, but incorrect enabling
+  unaligned access will generate an obvious alignment fault on ARMv7+. This is
+  also the default setting for ARM's downstream compilers. We have not changed
+  the default behavior for ARMv6, but may revisit that decision in the future.

davemgreen wrote:

I would up-play the compatibility argument and downplay the judgement call a 
little. And mention the way to disable it. Maybe something like
```
- ARMv7+ targets now default to allowing unaligned access, except Armv6-M, and
  Armv8-M without the Main Extension. Baremetal targets should check that the
  new default will work with their system configurations, since it requires
  that SCTLR.A is 0, SCTLR.U is 1, and that the memory in question is
  configured as "normal" memory. This brings clang in-line with the default 
settings
  for GCC and Arm Compiler. The old behaviour can be restored with
  -mno-unaligned-access.
```
But you might want to re-add the reasoning about the performance/codesize loss.

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

[clang] [clang][driver] Allow unaligned access on ARMv7 and higher by default (PR #82400)

[David Green via cfe-commits]

davemgreen wrote:

I would also personally add Armv6 too for consistency, but don't have a strong 
opinion.

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

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Freddy Ye via cfe-commits]

https://github.com/FreddyLeaf updated 
https://github.com/llvm/llvm-project/pull/80636

>From b131b0971d5c38a29c954b37c0da8fb3177e5c92 Mon Sep 17 00:00:00 2001
From: Freddy Ye 
Date: Mon, 5 Feb 2024 14:07:29 +0800
Subject: [PATCH 1/4] [X86] Support APXF to enable __builtin_cpu_supports.

---
 clang/test/CodeGen/target-builtin-noerror.c| 1 +
 compiler-rt/lib/builtins/cpu_model/x86.c   | 4 +++-
 llvm/include/llvm/TargetParser/X86TargetParser.def | 3 ++-
 llvm/lib/TargetParser/Host.cpp | 1 +
 llvm/lib/TargetParser/X86TargetParser.cpp  | 1 +
 5 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/clang/test/CodeGen/target-builtin-noerror.c 
b/clang/test/CodeGen/target-builtin-noerror.c
index 9608b5f37baaae..b438e50848a4b6 100644
--- a/clang/test/CodeGen/target-builtin-noerror.c
+++ b/clang/test/CodeGen/target-builtin-noerror.c
@@ -141,6 +141,7 @@ void verifyfeaturestrings(void) {
   (void)__builtin_cpu_supports("sm3");
   (void)__builtin_cpu_supports("sha512");
   (void)__builtin_cpu_supports("sm4");
+  (void)__builtin_cpu_supports("apxf");
   (void)__builtin_cpu_supports("usermsr");
   (void)__builtin_cpu_supports("avx10.1-256");
   (void)__builtin_cpu_supports("avx10.1-512");
diff --git a/compiler-rt/lib/builtins/cpu_model/x86.c 
b/compiler-rt/lib/builtins/cpu_model/x86.c
index 1afa468c4ae8c1..35375c6e8d55b6 100644
--- a/compiler-rt/lib/builtins/cpu_model/x86.c
+++ b/compiler-rt/lib/builtins/cpu_model/x86.c
@@ -217,7 +217,7 @@ enum ProcessorFeatures {
   FEATURE_SM3,
   FEATURE_SHA512,
   FEATURE_SM4,
-  // FEATURE_APXF,
+  FEATURE_APXF,
   FEATURE_USERMSR = 112,
   FEATURE_AVX10_1_256,
   FEATURE_AVX10_1_512,
@@ -983,6 +983,8 @@ static void getAvailableFeatures(unsigned ECX, unsigned 
EDX, unsigned MaxLeaf,
 setFeature(FEATURE_USERMSR);
   if (HasLeaf7Subleaf1 && ((EDX >> 19) & 1))
 setFeature(FEATURE_AVX10_1_256);
+  if (HasLeaf7Subleaf1 && ((EDX >> 21) & 1))
+setFeature(FEATURE_APXF);
 
   unsigned MaxLevel;
   getX86CpuIDAndInfo(0, &MaxLevel, &EBX, &ECX, &EDX);
diff --git a/llvm/include/llvm/TargetParser/X86TargetParser.def 
b/llvm/include/llvm/TargetParser/X86TargetParser.def
index 4c630c1eb06e8c..ec52062a2baacf 100644
--- a/llvm/include/llvm/TargetParser/X86TargetParser.def
+++ b/llvm/include/llvm/TargetParser/X86TargetParser.def
@@ -248,10 +248,11 @@ X86_FEATURE_COMPAT(AVXVNNIINT16,"avxvnniint16",   
0)
 X86_FEATURE_COMPAT(SM3, "sm3",0)
 X86_FEATURE_COMPAT(SHA512,  "sha512", 0)
 X86_FEATURE_COMPAT(SM4, "sm4",0)
-X86_FEATURE   (EGPR,"egpr")
+X86_FEATURE_COMPAT(APXF,"apxf",   0)
 X86_FEATURE_COMPAT(USERMSR, "usermsr",0)
 X86_FEATURE_COMPAT(AVX10_1, "avx10.1-256",0)
 X86_FEATURE_COMPAT(AVX10_1_512, "avx10.1-512",0)
+X86_FEATURE   (EGPR,"egpr")
 X86_FEATURE   (EVEX512, "evex512")
 X86_FEATURE   (CF,  "cf")
 // These features aren't really CPU features, but the frontend can set them.
diff --git a/llvm/lib/TargetParser/Host.cpp b/llvm/lib/TargetParser/Host.cpp
index f1197c29655380..233ee12a000962 100644
--- a/llvm/lib/TargetParser/Host.cpp
+++ b/llvm/lib/TargetParser/Host.cpp
@@ -1845,6 +1845,7 @@ bool sys::getHostCPUFeatures(StringMap &Features) {
   Features["prefetchi"]  = HasLeaf7Subleaf1 && ((EDX >> 14) & 1);
   Features["usermsr"]  = HasLeaf7Subleaf1 && ((EDX >> 15) & 1);
   Features["avx10.1-256"] = HasLeaf7Subleaf1 && ((EDX >> 19) & 1);
+  Features["apxf"] = HasLeaf7Subleaf1 && ((EDX >> 21) & 1);
 
   bool HasLeafD = MaxLevel >= 0xd &&
   !getX86CpuIDAndInfoEx(0xd, 0x1, &EAX, &EBX, &ECX, &EDX);
diff --git a/llvm/lib/TargetParser/X86TargetParser.cpp 
b/llvm/lib/TargetParser/X86TargetParser.cpp
index 21f46f576490a8..ea1f8517bb3329 100644
--- a/llvm/lib/TargetParser/X86TargetParser.cpp
+++ b/llvm/lib/TargetParser/X86TargetParser.cpp
@@ -633,6 +633,7 @@ constexpr FeatureBitset ImpliedFeaturesPPX = {};
 constexpr FeatureBitset ImpliedFeaturesNDD = {};
 constexpr FeatureBitset ImpliedFeaturesCCMP = {};
 constexpr FeatureBitset ImpliedFeaturesCF = {};
+constexpr FeatureBitset ImpliedFeaturesAPXF = {};
 
 constexpr FeatureInfo FeatureInfos[X86::CPU_FEATURE_MAX] = {
 #define X86_FEATURE(ENUM, STR) {{"+" STR}, ImpliedFeatures##ENUM},

>From a1ecdf5fe54cb03045748e3d49f23e24e9428973 Mon Sep 17 00:00:00 2001
From: Freddy Ye 
Date: Tue, 6 Feb 2024 17:19:28 +0800
Subject: [PATCH 2/4] misc

---
 compiler-rt/lib/builtins/cpu_model/x86.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/compiler-rt/lib/builtins/cpu_model/x86.c 
b/compiler-rt/lib/builtins/cpu_model/x86.c
index 35375c6e8d55b6..7e8acb3e73eda9 100644
--- a/compiler-rt/lib/builtins/cpu_model/x86.c
+++ b/compiler-rt/lib/builtins/cpu_model/x86.c
@@ -218,7 +218,7 @@ enum ProcessorFeatures {
   FEATURE_SHA512,
   FEATU

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[via cfe-commits]

llvmbot wrote:




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

Author: Balazs Benics (steakhal)


Changes

I figured I could reformat all (cpp,h) files of CSA to see if anything would 
need special formatting.
Let me know if you find debatable hunks.

clang-format version 19.0.0git (bc1c86b810e518a8e3fa90d5c26908c43788873d)
```
clang/include/clang/Analysis/**/*.{cpp,h}
clang/include/clang/StaticAnalyzer/**/*.{cpp,h}
clang/lib/Analysis/**/*.{cpp,h}
clang/lib/StaticAnalyzer/**/*.{cpp,h}
```

I don't intend to merge this PR; it is just to see how it would look, and how 
broad the changes would be for us.

---

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


256 Files Affected:

- (modified) clang/include/clang/Analysis/Analyses/Consumed.h (+200-200) 
- (modified) clang/include/clang/Analysis/Analyses/Dominators.h (+19-31) 
- (modified) clang/include/clang/Analysis/Analyses/LiveVariables.h (+4-5) 
- (modified) clang/include/clang/Analysis/Analyses/PostOrderCFGView.h (+4-4) 
- (modified) clang/include/clang/Analysis/Analyses/ReachableCode.h (+9-12) 
- (modified) clang/include/clang/Analysis/Analyses/ThreadSafety.h (+3-3) 
- (modified) clang/include/clang/Analysis/Analyses/ThreadSafetyCommon.h 
(+14-16) 
- (modified) clang/include/clang/Analysis/Analyses/ThreadSafetyLogical.h 
(+6-11) 
- (modified) clang/include/clang/Analysis/Analyses/ThreadSafetyTIL.h (+195-227) 
- (modified) clang/include/clang/Analysis/Analyses/ThreadSafetyTraverse.h 
(+133-133) 
- (modified) clang/include/clang/Analysis/Analyses/ThreadSafetyUtil.h (+8-9) 
- (modified) clang/include/clang/Analysis/Analyses/UninitializedValues.h (+6-7) 
- (modified) clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h (+2-2) 
- (modified) clang/include/clang/Analysis/AnyCall.h (+5-12) 
- (modified) clang/include/clang/Analysis/CFG.h (+134-171) 
- (modified) clang/include/clang/Analysis/CFGStmtMap.h (+5-5) 
- (modified) clang/include/clang/Analysis/CallGraph.h (+15-15) 
- (modified) clang/include/clang/Analysis/CloneDetection.h (+2-2) 
- (modified) clang/include/clang/Analysis/CodeInjector.h (+1-1) 
- (modified) clang/include/clang/Analysis/ConstructionContext.h (+37-36) 
- (modified) clang/include/clang/Analysis/DomainSpecific/CocoaConventions.h 
(+8-8) 
- (modified) clang/include/clang/Analysis/DomainSpecific/ObjCNoReturn.h (+1-1) 
- (modified) clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h 
(+6-6) 
- (modified) clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h 
(+10-16) 
- (modified) clang/include/clang/Analysis/FlowSensitive/DataflowValues.h 
(+39-39) 
- (modified) clang/include/clang/Analysis/PathDiagnostic.h (+59-83) 
- (modified) clang/include/clang/Analysis/ProgramPoint.h (+112-117) 
- (modified) clang/include/clang/Analysis/RetainSummaryManager.h (+78-102) 
- (modified) clang/include/clang/Analysis/SelectorExtras.h (+2-2) 
- (modified) clang/include/clang/Analysis/Support/BumpVector.h (+19-32) 
- (modified) 
clang/include/clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h (+2-2) 
- (modified) 
clang/include/clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h (+27-16) 
- (modified) clang/include/clang/StaticAnalyzer/Checkers/SValExplainer.h 
(+12-14) 
- (modified) clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h (+10-13) 
- (modified) clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h 
(+35-53) 
- (modified) 
clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h 
(+2-2) 
- (modified) clang/include/clang/StaticAnalyzer/Core/BugReporter/BugType.h 
(+1-1) 
- (modified) clang/include/clang/StaticAnalyzer/Core/Checker.h (+93-120) 
- (modified) clang/include/clang/StaticAnalyzer/Core/CheckerManager.h (+87-124) 
- (modified) clang/include/clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h 
(+5-4) 
- (modified) clang/include/clang/StaticAnalyzer/Core/PathSensitive/APSIntType.h 
(+3-3) 
- (modified) 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h 
(+13-28) 
- (modified) 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h 
(+26-27) 
- (modified) 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/BlockCounter.h (+6-5) 
- (modified) 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h (+4-2) 
- (modified) 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h (+36-65) 
- (modified) 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerHelpers.h (+1-1) 
- (modified) 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h 
(+3-5) 
- (modified) clang/include/clang/StaticAnalyzer/Core/PathSensitive/CoreEngine.h 
(+57-71) 
- (modified) 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/Environment.h (+9-17) 
- (modified) 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExplodedGraph.h (+55-71) 
- (modified) clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h 
(+82-106) 

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Freddy Ye via cfe-commits]

FreddyLeaf wrote:

After 
[fa42b33](https://github.com/llvm/llvm-project/pull/80636/commits/fa42b33d62227bd88cc5d63431244d0caac1e286)
1. An error will be thrown out if compiling `__builtin_cpu_supports("egpr")`
2. __attribute__((__target__("apxf"))) is not supported in this patch, no 
matter amend features or FMV.
3. __attribute__((__target__("egpr,cf"))) is already supported before this PR.

I think 3rd can be a workaround of 2nd, and gcc also hasn't supported FMV for 
"apxf".

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[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 bc1c86b810e518a8e3fa90d5c26908c43788873d 
c21867a39c74b23897158989081293558feb698c -- 
clang/include/clang/Analysis/Analyses/Consumed.h 
clang/include/clang/Analysis/Analyses/Dominators.h 
clang/include/clang/Analysis/Analyses/LiveVariables.h 
clang/include/clang/Analysis/Analyses/PostOrderCFGView.h 
clang/include/clang/Analysis/Analyses/ReachableCode.h 
clang/include/clang/Analysis/Analyses/ThreadSafety.h 
clang/include/clang/Analysis/Analyses/ThreadSafetyCommon.h 
clang/include/clang/Analysis/Analyses/ThreadSafetyLogical.h 
clang/include/clang/Analysis/Analyses/ThreadSafetyTIL.h 
clang/include/clang/Analysis/Analyses/ThreadSafetyTraverse.h 
clang/include/clang/Analysis/Analyses/ThreadSafetyUtil.h 
clang/include/clang/Analysis/Analyses/UninitializedValues.h 
clang/include/clang/Analysis/Analyses/UnsafeBufferUsage.h 
clang/include/clang/Analysis/AnyCall.h clang/include/clang/Analysis/CFG.h 
clang/include/clang/Analysis/CFGStmtMap.h 
clang/include/clang/Analysis/CallGraph.h 
clang/include/clang/Analysis/CloneDetection.h 
clang/include/clang/Analysis/CodeInjector.h 
clang/include/clang/Analysis/ConstructionContext.h 
clang/include/clang/Analysis/DomainSpecific/CocoaConventions.h 
clang/include/clang/Analysis/DomainSpecific/ObjCNoReturn.h 
clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h 
clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h 
clang/include/clang/Analysis/FlowSensitive/DataflowValues.h 
clang/include/clang/Analysis/PathDiagnostic.h 
clang/include/clang/Analysis/ProgramPoint.h 
clang/include/clang/Analysis/RetainSummaryManager.h 
clang/include/clang/Analysis/SelectorExtras.h 
clang/include/clang/Analysis/Support/BumpVector.h 
clang/include/clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h 
clang/include/clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h 
clang/include/clang/StaticAnalyzer/Checkers/SValExplainer.h 
clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h 
clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h 
clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporterVisitors.h 
clang/include/clang/StaticAnalyzer/Core/BugReporter/BugType.h 
clang/include/clang/StaticAnalyzer/Core/Checker.h 
clang/include/clang/StaticAnalyzer/Core/CheckerManager.h 
clang/include/clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/APSIntType.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/BlockCounter.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallDescription.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CheckerHelpers.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CoreEngine.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/Environment.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExplodedGraph.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/FunctionSummary.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/LoopUnrolling.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramStateTrait.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState_Fwd.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SValBuilder.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SValVisitor.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SummaryManager.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SymExpr.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/WorkList.h 
clang/include/clang/StaticAnalyzer/Frontend/AnalysisConsumer.h 
clang/include/clang/StaticAnalyzer/Frontend/CheckerRegistry.h 
clang/include/clang/StaticAnalyzer/Frontend/ModelConsumer.h 
clang/lib/Analysis/AnalysisDeclContext.cpp clang/lib/Analysis/BodyFarm.cpp 
clang/lib/Analysis/CFG.cpp clang/lib/Analysis/CFGReachabilityAnalysis.cpp 
clang/lib/Analysis/CFGStmtMap.cpp clang/lib/Analysis/CallGraph.cpp 
clang/lib/Analysis/CocoaConventions.cpp 
clang/lib/Analysis/ConstructionContext.cpp clang/lib/Analysis/Consumed.cpp 
clang/lib/Analysis/Dominators.cpp clang/lib/Analysis/ExprMutationAnalyzer.cpp 
clang/lib/Analysis/FlowSens

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Phoebe Wang via cfe-commits]

@@ -1845,6 +1845,12 @@ bool sys::getHostCPUFeatures(StringMap &Features) {
   Features["prefetchi"]  = HasLeaf7Subleaf1 && ((EDX >> 14) & 1);
   Features["usermsr"]  = HasLeaf7Subleaf1 && ((EDX >> 15) & 1);
   Features["avx10.1-256"] = HasLeaf7Subleaf1 && ((EDX >> 19) & 1);
+  Features["egpr"] = HasLeaf7Subleaf1 && ((EDX >> 21) & 1);
+  Features["push2pop2"] = HasLeaf7Subleaf1 && ((EDX >> 21) & 1);
+  Features["ppx"] = HasLeaf7Subleaf1 && ((EDX >> 21) & 1);
+  Features["ndd"] = HasLeaf7Subleaf1 && ((EDX >> 21) & 1);
+  Features["ccmp"] = HasLeaf7Subleaf1 && ((EDX >> 21) & 1);
+  Features["cf"] = HasLeaf7Subleaf1 && ((EDX >> 21) & 1);

phoebewang wrote:

You should use a variable like `bool HasAPXF = HasLeaf7Subleaf1 && ((EDX >> 21) 
& 1);`

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

[clang] [clang][NFC] Regroup declarations in `Sema` (PR #82217)

[Vlad Serebrennikov via cfe-commits]

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

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Phoebe Wang via cfe-commits]

phoebewang wrote:

You may also need to transfer "apxf" feature into subfeatures here 
https://github.com/llvm/llvm-project/blob/main/clang/lib/Basic/Targets/X86.cpp#L106

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

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Freddy Ye via cfe-commits]

FreddyLeaf wrote:

> You may also need to transfer "apxf" feature into subfeatures here 
> https://github.com/llvm/llvm-project/blob/main/clang/lib/Basic/Targets/X86.cpp#L106

Thanks for pointing out! This looks like the change required by supporting 
attribute((target("apxf"))). While that supports require other relate changes 
such as adding supports for apxf in X86TargetInfo::isValidFeatureName. I prefer 
to do it in another PR.


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

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Freddy Ye via cfe-commits]

https://github.com/FreddyLeaf updated 
https://github.com/llvm/llvm-project/pull/80636

>From b131b0971d5c38a29c954b37c0da8fb3177e5c92 Mon Sep 17 00:00:00 2001
From: Freddy Ye 
Date: Mon, 5 Feb 2024 14:07:29 +0800
Subject: [PATCH 1/5] [X86] Support APXF to enable __builtin_cpu_supports.

---
 clang/test/CodeGen/target-builtin-noerror.c| 1 +
 compiler-rt/lib/builtins/cpu_model/x86.c   | 4 +++-
 llvm/include/llvm/TargetParser/X86TargetParser.def | 3 ++-
 llvm/lib/TargetParser/Host.cpp | 1 +
 llvm/lib/TargetParser/X86TargetParser.cpp  | 1 +
 5 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/clang/test/CodeGen/target-builtin-noerror.c 
b/clang/test/CodeGen/target-builtin-noerror.c
index 9608b5f37baaae..b438e50848a4b6 100644
--- a/clang/test/CodeGen/target-builtin-noerror.c
+++ b/clang/test/CodeGen/target-builtin-noerror.c
@@ -141,6 +141,7 @@ void verifyfeaturestrings(void) {
   (void)__builtin_cpu_supports("sm3");
   (void)__builtin_cpu_supports("sha512");
   (void)__builtin_cpu_supports("sm4");
+  (void)__builtin_cpu_supports("apxf");
   (void)__builtin_cpu_supports("usermsr");
   (void)__builtin_cpu_supports("avx10.1-256");
   (void)__builtin_cpu_supports("avx10.1-512");
diff --git a/compiler-rt/lib/builtins/cpu_model/x86.c 
b/compiler-rt/lib/builtins/cpu_model/x86.c
index 1afa468c4ae8c1..35375c6e8d55b6 100644
--- a/compiler-rt/lib/builtins/cpu_model/x86.c
+++ b/compiler-rt/lib/builtins/cpu_model/x86.c
@@ -217,7 +217,7 @@ enum ProcessorFeatures {
   FEATURE_SM3,
   FEATURE_SHA512,
   FEATURE_SM4,
-  // FEATURE_APXF,
+  FEATURE_APXF,
   FEATURE_USERMSR = 112,
   FEATURE_AVX10_1_256,
   FEATURE_AVX10_1_512,
@@ -983,6 +983,8 @@ static void getAvailableFeatures(unsigned ECX, unsigned 
EDX, unsigned MaxLeaf,
 setFeature(FEATURE_USERMSR);
   if (HasLeaf7Subleaf1 && ((EDX >> 19) & 1))
 setFeature(FEATURE_AVX10_1_256);
+  if (HasLeaf7Subleaf1 && ((EDX >> 21) & 1))
+setFeature(FEATURE_APXF);
 
   unsigned MaxLevel;
   getX86CpuIDAndInfo(0, &MaxLevel, &EBX, &ECX, &EDX);
diff --git a/llvm/include/llvm/TargetParser/X86TargetParser.def 
b/llvm/include/llvm/TargetParser/X86TargetParser.def
index 4c630c1eb06e8c..ec52062a2baacf 100644
--- a/llvm/include/llvm/TargetParser/X86TargetParser.def
+++ b/llvm/include/llvm/TargetParser/X86TargetParser.def
@@ -248,10 +248,11 @@ X86_FEATURE_COMPAT(AVXVNNIINT16,"avxvnniint16",   
0)
 X86_FEATURE_COMPAT(SM3, "sm3",0)
 X86_FEATURE_COMPAT(SHA512,  "sha512", 0)
 X86_FEATURE_COMPAT(SM4, "sm4",0)
-X86_FEATURE   (EGPR,"egpr")
+X86_FEATURE_COMPAT(APXF,"apxf",   0)
 X86_FEATURE_COMPAT(USERMSR, "usermsr",0)
 X86_FEATURE_COMPAT(AVX10_1, "avx10.1-256",0)
 X86_FEATURE_COMPAT(AVX10_1_512, "avx10.1-512",0)
+X86_FEATURE   (EGPR,"egpr")
 X86_FEATURE   (EVEX512, "evex512")
 X86_FEATURE   (CF,  "cf")
 // These features aren't really CPU features, but the frontend can set them.
diff --git a/llvm/lib/TargetParser/Host.cpp b/llvm/lib/TargetParser/Host.cpp
index f1197c29655380..233ee12a000962 100644
--- a/llvm/lib/TargetParser/Host.cpp
+++ b/llvm/lib/TargetParser/Host.cpp
@@ -1845,6 +1845,7 @@ bool sys::getHostCPUFeatures(StringMap &Features) {
   Features["prefetchi"]  = HasLeaf7Subleaf1 && ((EDX >> 14) & 1);
   Features["usermsr"]  = HasLeaf7Subleaf1 && ((EDX >> 15) & 1);
   Features["avx10.1-256"] = HasLeaf7Subleaf1 && ((EDX >> 19) & 1);
+  Features["apxf"] = HasLeaf7Subleaf1 && ((EDX >> 21) & 1);
 
   bool HasLeafD = MaxLevel >= 0xd &&
   !getX86CpuIDAndInfoEx(0xd, 0x1, &EAX, &EBX, &ECX, &EDX);
diff --git a/llvm/lib/TargetParser/X86TargetParser.cpp 
b/llvm/lib/TargetParser/X86TargetParser.cpp
index 21f46f576490a8..ea1f8517bb3329 100644
--- a/llvm/lib/TargetParser/X86TargetParser.cpp
+++ b/llvm/lib/TargetParser/X86TargetParser.cpp
@@ -633,6 +633,7 @@ constexpr FeatureBitset ImpliedFeaturesPPX = {};
 constexpr FeatureBitset ImpliedFeaturesNDD = {};
 constexpr FeatureBitset ImpliedFeaturesCCMP = {};
 constexpr FeatureBitset ImpliedFeaturesCF = {};
+constexpr FeatureBitset ImpliedFeaturesAPXF = {};
 
 constexpr FeatureInfo FeatureInfos[X86::CPU_FEATURE_MAX] = {
 #define X86_FEATURE(ENUM, STR) {{"+" STR}, ImpliedFeatures##ENUM},

>From a1ecdf5fe54cb03045748e3d49f23e24e9428973 Mon Sep 17 00:00:00 2001
From: Freddy Ye 
Date: Tue, 6 Feb 2024 17:19:28 +0800
Subject: [PATCH 2/5] misc

---
 compiler-rt/lib/builtins/cpu_model/x86.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/compiler-rt/lib/builtins/cpu_model/x86.c 
b/compiler-rt/lib/builtins/cpu_model/x86.c
index 35375c6e8d55b6..7e8acb3e73eda9 100644
--- a/compiler-rt/lib/builtins/cpu_model/x86.c
+++ b/compiler-rt/lib/builtins/cpu_model/x86.c
@@ -218,7 +218,7 @@ enum ProcessorFeatures {
   FEATURE_SHA512,
   FEATU

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Freddy Ye via cfe-commits]

@@ -1845,6 +1845,12 @@ bool sys::getHostCPUFeatures(StringMap &Features) {
   Features["prefetchi"]  = HasLeaf7Subleaf1 && ((EDX >> 14) & 1);
   Features["usermsr"]  = HasLeaf7Subleaf1 && ((EDX >> 15) & 1);
   Features["avx10.1-256"] = HasLeaf7Subleaf1 && ((EDX >> 19) & 1);
+  Features["egpr"] = HasLeaf7Subleaf1 && ((EDX >> 21) & 1);
+  Features["push2pop2"] = HasLeaf7Subleaf1 && ((EDX >> 21) & 1);
+  Features["ppx"] = HasLeaf7Subleaf1 && ((EDX >> 21) & 1);
+  Features["ndd"] = HasLeaf7Subleaf1 && ((EDX >> 21) & 1);
+  Features["ccmp"] = HasLeaf7Subleaf1 && ((EDX >> 21) & 1);
+  Features["cf"] = HasLeaf7Subleaf1 && ((EDX >> 21) & 1);

FreddyLeaf wrote:

[fd73a2a](https://github.com/llvm/llvm-project/pull/80636/commits/fd73a2a447e90ae6d4270bfd9fc958343995138c)

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

[clang] [clang][dataflow] Remove deprecated `ValueModel::merge()` function. (PR #82602)

[via cfe-commits]

https://github.com/martinboehme created 
https://github.com/llvm/llvm-project/pull/82602

I'm not aware of any remaining overrides of this function.

While I'm here, change an outdated comment in DataflowAnalysis.h that still
referred to `merge()`. I've made the comment more general, referring simply to
`ValueModel`, as we shouldn't really be repeating the documentation of that
class here anyway.

>From 982bd974a2060c3ee23675b44f20b0534d6a054b Mon Sep 17 00:00:00 2001
From: Martin Braenne 
Date: Thu, 22 Feb 2024 09:00:28 +
Subject: [PATCH] [clang][dataflow] Remove deprecated `ValueModel::merge()`
 function.

I'm not aware of any remaining overrides of this function.

While I'm here, change an outdated comment in DataflowAnalysis.h that still
referred to `merge()`. I've made the comment more general, referring simply to
`ValueModel`, as we shouldn't really be repeating the documentation of that
class here anyway.
---
 .../Analysis/FlowSensitive/DataflowAnalysis.h |  7 ++--
 .../FlowSensitive/DataflowEnvironment.h   | 32 +--
 2 files changed, 4 insertions(+), 35 deletions(-)

diff --git a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
index b95095d2184c0e..3c84704d0d6ceb 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
@@ -54,10 +54,9 @@ namespace dataflow {
 /// Environment &Env)` - applies the analysis transfer
 ///function for a given edge from a CFG block of a conditional statement.
 ///
-///  `Derived` can optionally override the following members:
-///   * `bool merge(QualType, const Value &, const Value &, Value &,
-/// Environment &)` -  joins distinct values. This could be a strict
-/// lattice join or a more general widening operation.
+///  `Derived` can optionally override the virtual functions in the
+///  `Environment::ValueModel` interface (which is an indirect base class of
+///  this class).
 ///
 ///  `LatticeT` is a bounded join-semilattice that is used by `Derived` and 
must
 ///  provide the following public members:
diff --git a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
index b3dc940705f870..62e7af7ac219bc 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
@@ -79,32 +79,6 @@ class Environment {
   return ComparisonResult::Unknown;
 }
 
-/// DEPRECATED. Override `join` and/or `widen`, instead.
-///
-/// Modifies `MergedVal` to approximate both `Val1` and `Val2`. This could
-/// be a strict lattice join or a more general widening operation.
-///
-/// If this function returns true, `MergedVal` will be assigned to a 
storage
-/// location of type `Type` in `MergedEnv`.
-///
-/// `Env1` and `Env2` can be used to query child values and path condition
-/// implications of `Val1` and `Val2` respectively.
-///
-/// Requirements:
-///
-///  `Val1` and `Val2` must be distinct.
-///
-///  `Val1`, `Val2`, and `MergedVal` must model values of type `Type`.
-///
-///  `Val1` and `Val2` must be assigned to the same storage location in
-///  `Env1` and `Env2` respectively.
-virtual bool merge(QualType Type, const Value &Val1,
-   const Environment &Env1, const Value &Val2,
-   const Environment &Env2, Value &MergedVal,
-   Environment &MergedEnv) {
-  return true;
-}
-
 /// Modifies `JoinedVal` to approximate both `Val1` and `Val2`. This should
 /// obey the properties of a lattice join.
 ///
@@ -121,11 +95,7 @@ class Environment {
 ///  `Env1` and `Env2` respectively.
 virtual void join(QualType Type, const Value &Val1, const Environment 
&Env1,
   const Value &Val2, const Environment &Env2,
-  Value &JoinedVal, Environment &JoinedEnv) {
-  [[maybe_unused]] bool ShouldKeep =
-  merge(Type, Val1, Env1, Val2, Env2, JoinedVal, JoinedEnv);
-  assert(ShouldKeep && "dropping merged value is unsupported");
-}
+  Value &JoinedVal, Environment &JoinedEnv) {}
 
 /// This function may widen the current value -- replace it with an
 /// approximation that can reach a fixed point more quickly than iterated

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

[clang] [clang][dataflow] Remove deprecated `ValueModel::merge()` function. (PR #82602)

[via cfe-commits]

llvmbot wrote:



@llvm/pr-subscribers-clang

@llvm/pr-subscribers-clang-analysis

Author: None (martinboehme)


Changes

I'm not aware of any remaining overrides of this function.

While I'm here, change an outdated comment in DataflowAnalysis.h that still
referred to `merge()`. I've made the comment more general, referring simply to
`ValueModel`, as we shouldn't really be repeating the documentation of that
class here anyway.

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


2 Files Affected:

- (modified) clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h 
(+3-4) 
- (modified) clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h 
(+1-31) 


``diff
diff --git a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
index b95095d2184c0e..3c84704d0d6ceb 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
@@ -54,10 +54,9 @@ namespace dataflow {
 /// Environment &Env)` - applies the analysis transfer
 ///function for a given edge from a CFG block of a conditional statement.
 ///
-///  `Derived` can optionally override the following members:
-///   * `bool merge(QualType, const Value &, const Value &, Value &,
-/// Environment &)` -  joins distinct values. This could be a strict
-/// lattice join or a more general widening operation.
+///  `Derived` can optionally override the virtual functions in the
+///  `Environment::ValueModel` interface (which is an indirect base class of
+///  this class).
 ///
 ///  `LatticeT` is a bounded join-semilattice that is used by `Derived` and 
must
 ///  provide the following public members:
diff --git a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
index b3dc940705f870..62e7af7ac219bc 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
@@ -79,32 +79,6 @@ class Environment {
   return ComparisonResult::Unknown;
 }
 
-/// DEPRECATED. Override `join` and/or `widen`, instead.
-///
-/// Modifies `MergedVal` to approximate both `Val1` and `Val2`. This could
-/// be a strict lattice join or a more general widening operation.
-///
-/// If this function returns true, `MergedVal` will be assigned to a 
storage
-/// location of type `Type` in `MergedEnv`.
-///
-/// `Env1` and `Env2` can be used to query child values and path condition
-/// implications of `Val1` and `Val2` respectively.
-///
-/// Requirements:
-///
-///  `Val1` and `Val2` must be distinct.
-///
-///  `Val1`, `Val2`, and `MergedVal` must model values of type `Type`.
-///
-///  `Val1` and `Val2` must be assigned to the same storage location in
-///  `Env1` and `Env2` respectively.
-virtual bool merge(QualType Type, const Value &Val1,
-   const Environment &Env1, const Value &Val2,
-   const Environment &Env2, Value &MergedVal,
-   Environment &MergedEnv) {
-  return true;
-}
-
 /// Modifies `JoinedVal` to approximate both `Val1` and `Val2`. This should
 /// obey the properties of a lattice join.
 ///
@@ -121,11 +95,7 @@ class Environment {
 ///  `Env1` and `Env2` respectively.
 virtual void join(QualType Type, const Value &Val1, const Environment 
&Env1,
   const Value &Val2, const Environment &Env2,
-  Value &JoinedVal, Environment &JoinedEnv) {
-  [[maybe_unused]] bool ShouldKeep =
-  merge(Type, Val1, Env1, Val2, Env2, JoinedVal, JoinedEnv);
-  assert(ShouldKeep && "dropping merged value is unsupported");
-}
+  Value &JoinedVal, Environment &JoinedEnv) {}
 
 /// This function may widen the current value -- replace it with an
 /// approximation that can reach a fixed point more quickly than iterated

``




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

[clang] [clang-format] Limit how much work guessLanguage() can do (PR #78925)

[Nathan Ridge via cfe-commits]

HighCommander4 wrote:

> If we add a `bool GuessObjC` parameter to `guessLanguage()`, would that solve 
> the problem?

I assume you mean making it so that when clangd calls into `guessLanguage()`, 
the ObjC guessing algorithm is skipped entirely.

I had a similar idea originally (discussed around 
[here](https://github.com/clangd/clangd/issues/719#issuecomment-1790284919)) 
but I realized that this introduces the possibility that a `.h` file is treated 
as one language when formatted by clangd, and a different language when 
formatted by clang-format (and so you could get e.g. a user's editor (which 
uses clangd) fighting back and forth with e.g. a post-commit hook (which uses 
clang-format)).

So, I don't think this is a viable approach; we'd be trading a crash affecting 
a small number of `.h` files, for a less severe but  annoying issue potentially 
affecting a much larger set of `.h` files.

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

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Shengchen Kan via cfe-commits]

@@ -983,6 +983,8 @@ static void getAvailableFeatures(unsigned ECX, unsigned 
EDX, unsigned MaxLeaf,
 setFeature(FEATURE_USERMSR);
   if (HasLeaf7Subleaf1 && ((EDX >> 19) & 1))
 setFeature(FEATURE_AVX10_1_256);
+  if (HasLeaf7Subleaf1 && ((EDX >> 21) & 1))

KanRobert wrote:

Add SPEC sentence in your description.

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

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Shengchen Kan via cfe-commits]

@@ -265,6 +265,7 @@ X86_MICROARCH_LEVEL(X86_64_BASELINE,"x86-64",   
95)
 X86_MICROARCH_LEVEL(X86_64_V2,  "x86-64-v2",96)
 X86_MICROARCH_LEVEL(X86_64_V3,  "x86-64-v3",97)
 X86_MICROARCH_LEVEL(X86_64_V4,  "x86-64-v4",98)
+X86_MICROARCH_LEVEL(APXF,   "apxf",111)

KanRobert wrote:

Where is 111 from?

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

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Shengchen Kan via cfe-commits]

@@ -219,6 +219,7 @@
 #define bit_PREFETCHI 0x4000
 #define bit_USERMSR   0x8000
 #define bit_AVX10 0x0008
+#define bit_APXF  0x0020

KanRobert wrote:

Where is the number from? Add the link in your description of the PR.

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

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Freddy Ye via cfe-commits]

@@ -265,6 +265,7 @@ X86_MICROARCH_LEVEL(X86_64_BASELINE,"x86-64",   
95)
 X86_MICROARCH_LEVEL(X86_64_V2,  "x86-64-v2",96)
 X86_MICROARCH_LEVEL(X86_64_V3,  "x86-64-v3",97)
 X86_MICROARCH_LEVEL(X86_64_V4,  "x86-64-v4",98)
+X86_MICROARCH_LEVEL(APXF,   "apxf",111)

FreddyLeaf wrote:

this is to align with libgcc

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

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Freddy Ye via cfe-commits]

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

[clang] [clang][analyzer] Fix argument invalidations in StreamChecker. (PR #79470)

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

https://github.com/balazske updated 
https://github.com/llvm/llvm-project/pull/79470

From 70eeae8170a782b93b546b81ac913e1b8eacd28e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bal=C3=A1zs=20K=C3=A9ri?= 
Date: Thu, 22 Feb 2024 10:18:06 +0100
Subject: [PATCH] [clang][analyzer] Fix argument invalidations in
 StreamChecker.

Specific arguments passed to stream handling functions are changed by the 
function,
this means these should be invalidated ("escaped") by the analyzer.
This change adds the argument invalidation (in specific cases) to the checker.
---
 .../StaticAnalyzer/Checkers/StreamChecker.cpp | 39 ++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
index a070f451694a3b..65bdc4cac30940 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
@@ -21,6 +21,7 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramStateTrait.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h"
+#include "llvm/ADT/Sequence.h"
 #include 
 #include 
 
@@ -629,6 +630,21 @@ const ExplodedNode 
*StreamChecker::getAcquisitionSite(const ExplodedNode *N,
   return nullptr;
 }
 
+static ProgramStateRef escapeArgs(ProgramStateRef State, CheckerContext &C,
+  const CallEvent &Call,
+  ArrayRef EscapingArgs) {
+  const auto *CE = Call.getOriginExpr();
+
+  SmallVector EscapingVals;
+  EscapingVals.reserve(EscapingArgs.size());
+  for (auto EscArgIdx : EscapingArgs)
+EscapingVals.push_back(Call.getArgSVal(EscArgIdx));
+  State = State->invalidateRegions(EscapingVals, CE, C.blockCount(),
+   C.getLocationContext(),
+   /*CausesPointerEscape=*/false);
+  return State;
+}
+
 
//===--===//
 // Methods of StreamChecker.
 
//===--===//
@@ -819,6 +835,11 @@ void StreamChecker::evalFreadFwrite(const FnDescription 
*Desc,
 return;
   }
 
+  // At read, invalidate the buffer in any case of error or success,
+  // except if EOF was already present.
+  if (IsFread && !E.isStreamEof())
+State = escapeArgs(State, C, Call, {0});
+
   // Generate a transition for the success state.
   // If we know the state to be FEOF at fread, do not add a success state.
   if (!IsFread || !E.isStreamEof()) {
@@ -863,6 +884,9 @@ void StreamChecker::evalFgetx(const FnDescription *Desc, 
const CallEvent &Call,
 return;
 
   if (!E.isStreamEof()) {
+// If there was already EOF, assume that read buffer is not changed.
+// Otherwise it may change at success or failure.
+State = escapeArgs(State, C, Call, {0});
 if (SingleChar) {
   // Generate a transition for the success state of `fgetc`.
   NonLoc RetVal = makeRetVal(C, E.CE).castAs();
@@ -1011,6 +1035,14 @@ void StreamChecker::evalFscanf(const FnDescription 
*Desc, const CallEvent &Call,
 State->BindExpr(E.CE, C.getLocationContext(), RetVal);
 StateNotFailed =
 E.assumeBinOpNN(StateNotFailed, BO_GE, RetVal, E.getZeroVal(Call));
+if (!StateNotFailed)
+  return;
+
+SmallVector EscArgs;
+for (auto EscArg : llvm::seq(2u, Call.getNumArgs()))
+  EscArgs.push_back(EscArg);
+StateNotFailed = escapeArgs(StateNotFailed, C, Call, EscArgs);
+
 if (StateNotFailed)
   C.addTransition(StateNotFailed);
   }
@@ -1073,8 +1105,12 @@ void StreamChecker::evalGetdelim(const FnDescription 
*Desc,
   // return -1.
   // If an error occurs, the function shall return -1 and set 'errno'.
 
-  // Add transition for the successful state.
   if (!E.isStreamEof()) {
+// Escape buffer and size (may change by the call).
+// May happen even at error (partial read?).
+State = escapeArgs(State, C, Call, {0, 1});
+
+// Add transition for the successful state.
 NonLoc RetVal = makeRetVal(C, E.CE).castAs();
 ProgramStateRef StateNotFailed =
 State->BindExpr(E.CE, C.getLocationContext(), RetVal);
@@ -1161,6 +1197,7 @@ void StreamChecker::evalFgetpos(const FnDescription *Desc,
 
   ProgramStateRef StateNotFailed, StateFailed;
   std::tie(StateFailed, StateNotFailed) = E.makeRetValAndAssumeDual(State, C);
+  StateNotFailed = escapeArgs(StateNotFailed, C, Call, {1});
 
   // This function does not affect the stream state.
   // Still we add success and failure state with the appropriate return value.

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

[clang] [clang][analyzer] Fix argument invalidations in StreamChecker. (PR #79470)

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

balazske wrote:

I have rebased the branch to latest version of `StreamChecker`, no other 
changes were made to the patch.

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

[clang] [Clang] fix static operator()/[] call not evaluating object (PR #78356)

[via cfe-commits]

cor3ntin wrote:

@MitalAshok Can we close this?

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

[clang] fix: constexpr bit_cast with empty base classes (PR #82383)

[via cfe-commits]

cor3ntin wrote:

This will need a release note.
I'm curious why the removed code was there in the first place. Any idea 
@tbaederr ?

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

[clang] [Clang][Sema] Remove invalid ctor (NFC) (PR #82161)

[via cfe-commits]

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


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

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Freddy Ye via cfe-commits]

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

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Freddy Ye via cfe-commits]

@@ -219,6 +219,7 @@
 #define bit_PREFETCHI 0x4000
 #define bit_USERMSR   0x8000
 #define bit_AVX10 0x0008
+#define bit_APXF  0x0020

FreddyLeaf wrote:

Done.

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

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Freddy Ye via cfe-commits]

@@ -983,6 +983,8 @@ static void getAvailableFeatures(unsigned ECX, unsigned 
EDX, unsigned MaxLeaf,
 setFeature(FEATURE_USERMSR);
   if (HasLeaf7Subleaf1 && ((EDX >> 19) & 1))
 setFeature(FEATURE_AVX10_1_256);
+  if (HasLeaf7Subleaf1 && ((EDX >> 21) & 1))

FreddyLeaf wrote:

Done.

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

[clang] [clang] Support `__is_trivially_copyable(int()&)==false` (PR #81298)

[via cfe-commits]

@@ -3899,7 +3899,9 @@ ExprResult Parser::ParseTypeTrait() {
   SmallVector Args;
   do {
 // Parse the next type.
-TypeResult Ty = ParseTypeName();
+TypeResult Ty = ParseTypeName(nullptr, getLangOpts().CPlusPlus

cor3ntin wrote:

```suggestion
TypeResult Ty = ParseTypeName(/*SourceRange=*/nullptr, 
getLangOpts().CPlusPlus
```

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

[clang] [Clang][Parser] Have the depth of the abbreviated generic lambdas inside a requires clause differ from the surrounding generic lambda (PR #80656)

[Younan Zhang via cfe-commits]

zyn0217 wrote:

@cor3ntin would you mind taking a look? thanks!

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

[clang] [clang] Support `__is_trivially_copyable(int()&)==false` (PR #81298)

[via cfe-commits]

@@ -3941,7 +3943,7 @@ ExprResult Parser::ParseArrayTypeTrait() {
   if (T.expectAndConsume())
 return ExprError();
 
-  TypeResult Ty = ParseTypeName();
+  TypeResult Ty = ParseTypeName(nullptr, DeclaratorContext::TemplateArg);

cor3ntin wrote:

```suggestion
  TypeResult Ty = ParseTypeName(/*SourceRange=*/nullptr, 
DeclaratorContext::TemplateArg);
```

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

[clang] [clang] Support `__is_trivially_copyable(int()&)==false` (PR #81298)

[via cfe-commits]

https://github.com/cor3ntin commented:

This is going to need additional tests (ie a test for 
`__is_trivially_copyable(int()&)` would be a good start!)

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

[clang] [clang] Support `__is_trivially_copyable(int()&)==false` (PR #81298)

[via cfe-commits]

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

[clang] [OpenMP][Clang] Enable inscan modifier for generic datatypes (PR #82220)

[Animesh Kumar via cfe-commits]

https://github.com/animeshk-amd updated 
https://github.com/llvm/llvm-project/pull/82220

>From 53a7d681198006460a6e2b38d1a89146b3d26b03 Mon Sep 17 00:00:00 2001
From: Animesh Kumar 
Date: Mon, 19 Feb 2024 00:28:39 -0600
Subject: [PATCH] [OpenMP][Clang] Enable inscan modifier for generic datatypes

This patch fixes the #67002 ([OpenMP][Clang] Scan Directive not
supported for Generic types). It disables the Sema checks/analysis
that are run on the helper arrays which go into the implementation
of the `omp scan` directive until the template instantiation
happens.
---
 clang/lib/Sema/SemaOpenMP.cpp|  3 ++-
 clang/test/OpenMP/scan_ast_print.cpp | 18 ++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/clang/lib/Sema/SemaOpenMP.cpp b/clang/lib/Sema/SemaOpenMP.cpp
index 7f75cfc5b54f35..f4364a259ad57f 100644
--- a/clang/lib/Sema/SemaOpenMP.cpp
+++ b/clang/lib/Sema/SemaOpenMP.cpp
@@ -4962,7 +4962,8 @@ StmtResult Sema::ActOnOpenMPRegionEnd(StmtResult S,
   if (RC->getModifier() != OMPC_REDUCTION_inscan)
 continue;
   for (Expr *E : RC->copy_array_temps())
-MarkDeclarationsReferencedInExpr(E);
+if (E)
+  MarkDeclarationsReferencedInExpr(E);
 }
 if (auto *AC = dyn_cast(C)) {
   for (Expr *E : AC->varlists())
diff --git a/clang/test/OpenMP/scan_ast_print.cpp 
b/clang/test/OpenMP/scan_ast_print.cpp
index 3bbd3b60c3e8c4..82cb13eb6e70f7 100644
--- a/clang/test/OpenMP/scan_ast_print.cpp
+++ b/clang/test/OpenMP/scan_ast_print.cpp
@@ -17,6 +17,10 @@ T tmain(T argc) {
   static T a;
 #pragma omp for reduction(inscan, +: a)
   for (int i = 0; i < 10; ++i) {
+#pragma omp scan inclusive(a)
+  }
+#pragma omp parallel for reduction(inscan, +:a)
+  for (int i = 0; i < 10; ++i) {
 #pragma omp scan inclusive(a)
   }
   return a + argc;
@@ -25,15 +29,29 @@ T tmain(T argc) {
 // CHECK-NEXT: #pragma omp for reduction(inscan, +: a)
 // CHECK-NEXT: for (int i = 0; i < 10; ++i) {
 // CHECK-NEXT: #pragma omp scan inclusive(a){{$}}
+
+// CHECK: #pragma omp parallel for reduction(inscan, +: a)
+// CHECK-NEXT: for (int i = 0; i < 10; ++i) {
+// CHECK-NEXT: #pragma omp scan inclusive(a){{$}}
+
 // CHECK:  static int a;
 // CHECK-NEXT: #pragma omp for reduction(inscan, +: a)
 // CHECK-NEXT: for (int i = 0; i < 10; ++i) {
 // CHECK-NEXT: #pragma omp scan inclusive(a)
+
+// CHECK: #pragma omp parallel for reduction(inscan, +: a)
+// CHECK-NEXT: for (int i = 0; i < 10; ++i) {
+// CHECK-NEXT: #pragma omp scan inclusive(a)
+
 // CHECK:  static char a;
 // CHECK-NEXT: #pragma omp for reduction(inscan, +: a)
 // CHECK-NEXT: for (int i = 0; i < 10; ++i) {
 // CHECK-NEXT: #pragma omp scan inclusive(a)
 
+// CHECK: #pragma omp parallel for reduction(inscan, +: a)
+// CHECK-NEXT: for (int i = 0; i < 10; ++i) {
+// CHECK-NEXT: #pragma omp scan inclusive(a)
+
 int main(int argc, char **argv) {
   static int a;
 // CHECK: static int a;

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

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Shengchen Kan via cfe-commits]

@@ -265,6 +265,7 @@ X86_MICROARCH_LEVEL(X86_64_BASELINE,"x86-64",   
95)
 X86_MICROARCH_LEVEL(X86_64_V2,  "x86-64-v2",96)
 X86_MICROARCH_LEVEL(X86_64_V3,  "x86-64-v3",97)
 X86_MICROARCH_LEVEL(X86_64_V4,  "x86-64-v4",98)
+X86_MICROARCH_LEVEL(APXF,   "apxf",111)

KanRobert wrote:

Add the link in the description?

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

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Freddy Ye via cfe-commits]

https://github.com/FreddyLeaf updated 
https://github.com/llvm/llvm-project/pull/80636

>From b131b0971d5c38a29c954b37c0da8fb3177e5c92 Mon Sep 17 00:00:00 2001
From: Freddy Ye 
Date: Mon, 5 Feb 2024 14:07:29 +0800
Subject: [PATCH 1/6] [X86] Support APXF to enable __builtin_cpu_supports.

---
 clang/test/CodeGen/target-builtin-noerror.c| 1 +
 compiler-rt/lib/builtins/cpu_model/x86.c   | 4 +++-
 llvm/include/llvm/TargetParser/X86TargetParser.def | 3 ++-
 llvm/lib/TargetParser/Host.cpp | 1 +
 llvm/lib/TargetParser/X86TargetParser.cpp  | 1 +
 5 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/clang/test/CodeGen/target-builtin-noerror.c 
b/clang/test/CodeGen/target-builtin-noerror.c
index 9608b5f37baaae..b438e50848a4b6 100644
--- a/clang/test/CodeGen/target-builtin-noerror.c
+++ b/clang/test/CodeGen/target-builtin-noerror.c
@@ -141,6 +141,7 @@ void verifyfeaturestrings(void) {
   (void)__builtin_cpu_supports("sm3");
   (void)__builtin_cpu_supports("sha512");
   (void)__builtin_cpu_supports("sm4");
+  (void)__builtin_cpu_supports("apxf");
   (void)__builtin_cpu_supports("usermsr");
   (void)__builtin_cpu_supports("avx10.1-256");
   (void)__builtin_cpu_supports("avx10.1-512");
diff --git a/compiler-rt/lib/builtins/cpu_model/x86.c 
b/compiler-rt/lib/builtins/cpu_model/x86.c
index 1afa468c4ae8c1..35375c6e8d55b6 100644
--- a/compiler-rt/lib/builtins/cpu_model/x86.c
+++ b/compiler-rt/lib/builtins/cpu_model/x86.c
@@ -217,7 +217,7 @@ enum ProcessorFeatures {
   FEATURE_SM3,
   FEATURE_SHA512,
   FEATURE_SM4,
-  // FEATURE_APXF,
+  FEATURE_APXF,
   FEATURE_USERMSR = 112,
   FEATURE_AVX10_1_256,
   FEATURE_AVX10_1_512,
@@ -983,6 +983,8 @@ static void getAvailableFeatures(unsigned ECX, unsigned 
EDX, unsigned MaxLeaf,
 setFeature(FEATURE_USERMSR);
   if (HasLeaf7Subleaf1 && ((EDX >> 19) & 1))
 setFeature(FEATURE_AVX10_1_256);
+  if (HasLeaf7Subleaf1 && ((EDX >> 21) & 1))
+setFeature(FEATURE_APXF);
 
   unsigned MaxLevel;
   getX86CpuIDAndInfo(0, &MaxLevel, &EBX, &ECX, &EDX);
diff --git a/llvm/include/llvm/TargetParser/X86TargetParser.def 
b/llvm/include/llvm/TargetParser/X86TargetParser.def
index 4c630c1eb06e8c..ec52062a2baacf 100644
--- a/llvm/include/llvm/TargetParser/X86TargetParser.def
+++ b/llvm/include/llvm/TargetParser/X86TargetParser.def
@@ -248,10 +248,11 @@ X86_FEATURE_COMPAT(AVXVNNIINT16,"avxvnniint16",   
0)
 X86_FEATURE_COMPAT(SM3, "sm3",0)
 X86_FEATURE_COMPAT(SHA512,  "sha512", 0)
 X86_FEATURE_COMPAT(SM4, "sm4",0)
-X86_FEATURE   (EGPR,"egpr")
+X86_FEATURE_COMPAT(APXF,"apxf",   0)
 X86_FEATURE_COMPAT(USERMSR, "usermsr",0)
 X86_FEATURE_COMPAT(AVX10_1, "avx10.1-256",0)
 X86_FEATURE_COMPAT(AVX10_1_512, "avx10.1-512",0)
+X86_FEATURE   (EGPR,"egpr")
 X86_FEATURE   (EVEX512, "evex512")
 X86_FEATURE   (CF,  "cf")
 // These features aren't really CPU features, but the frontend can set them.
diff --git a/llvm/lib/TargetParser/Host.cpp b/llvm/lib/TargetParser/Host.cpp
index f1197c29655380..233ee12a000962 100644
--- a/llvm/lib/TargetParser/Host.cpp
+++ b/llvm/lib/TargetParser/Host.cpp
@@ -1845,6 +1845,7 @@ bool sys::getHostCPUFeatures(StringMap &Features) {
   Features["prefetchi"]  = HasLeaf7Subleaf1 && ((EDX >> 14) & 1);
   Features["usermsr"]  = HasLeaf7Subleaf1 && ((EDX >> 15) & 1);
   Features["avx10.1-256"] = HasLeaf7Subleaf1 && ((EDX >> 19) & 1);
+  Features["apxf"] = HasLeaf7Subleaf1 && ((EDX >> 21) & 1);
 
   bool HasLeafD = MaxLevel >= 0xd &&
   !getX86CpuIDAndInfoEx(0xd, 0x1, &EAX, &EBX, &ECX, &EDX);
diff --git a/llvm/lib/TargetParser/X86TargetParser.cpp 
b/llvm/lib/TargetParser/X86TargetParser.cpp
index 21f46f576490a8..ea1f8517bb3329 100644
--- a/llvm/lib/TargetParser/X86TargetParser.cpp
+++ b/llvm/lib/TargetParser/X86TargetParser.cpp
@@ -633,6 +633,7 @@ constexpr FeatureBitset ImpliedFeaturesPPX = {};
 constexpr FeatureBitset ImpliedFeaturesNDD = {};
 constexpr FeatureBitset ImpliedFeaturesCCMP = {};
 constexpr FeatureBitset ImpliedFeaturesCF = {};
+constexpr FeatureBitset ImpliedFeaturesAPXF = {};
 
 constexpr FeatureInfo FeatureInfos[X86::CPU_FEATURE_MAX] = {
 #define X86_FEATURE(ENUM, STR) {{"+" STR}, ImpliedFeatures##ENUM},

>From a1ecdf5fe54cb03045748e3d49f23e24e9428973 Mon Sep 17 00:00:00 2001
From: Freddy Ye 
Date: Tue, 6 Feb 2024 17:19:28 +0800
Subject: [PATCH 2/6] misc

---
 compiler-rt/lib/builtins/cpu_model/x86.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/compiler-rt/lib/builtins/cpu_model/x86.c 
b/compiler-rt/lib/builtins/cpu_model/x86.c
index 35375c6e8d55b6..7e8acb3e73eda9 100644
--- a/compiler-rt/lib/builtins/cpu_model/x86.c
+++ b/compiler-rt/lib/builtins/cpu_model/x86.c
@@ -218,7 +218,7 @@ enum ProcessorFeatures {
   FEATURE_SHA512,
   FEATU

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Freddy Ye via cfe-commits]

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

[clang] [compiler-rt] [llvm] [X86] Support APXF to enable __builtin_cpu_supports. (PR #80636)

[Freddy Ye via cfe-commits]

@@ -265,6 +265,7 @@ X86_MICROARCH_LEVEL(X86_64_BASELINE,"x86-64",   
95)
 X86_MICROARCH_LEVEL(X86_64_V2,  "x86-64-v2",96)
 X86_MICROARCH_LEVEL(X86_64_V3,  "x86-64-v3",97)
 X86_MICROARCH_LEVEL(X86_64_V4,  "x86-64-v4",98)
+X86_MICROARCH_LEVEL(APXF,   "apxf",111)

FreddyLeaf wrote:

done.

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

[clang] [clang-format] Do not update cursor pos if no includes replacement (PR #77456)

[Owen Pan via cfe-commits]

@@ -3123,6 +3123,7 @@ static void sortCppIncludes(const FormatStyle &Style,
   }
 
   std::string result;
+  unsigned NewCursor = UINT_MAX;

owenca wrote:

```suggestion
  const auto OldCursor = Cursor ? *Cursor : 0;
```

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

https://github.com/steakhal commented:

Right now I don't have more time for this. I reached this part:
https://github.com/llvm/llvm-project/pull/82599/files#diff-e06d50a75016837f80877b3aae594298eeead1f2260da82167e74289beca116dL2563


So far I haven't found anything critical. Only a handful of license headers 
break and maybe a few other tables looked better in the previous revision - but 
that's subjective.
I plan to come back and continue this.

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

@@ -1,15 +1,16 @@
-//ProgramStateTrait.h - Partial implementations of ProgramStateTrait -*- C++ 
-*-
+// ProgramStateTrait.h - Partial implementations of ProgramStateTrait -*- C++
+// -*-
 //
-// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
-// See https://llvm.org/LICENSE.txt for license information.
-// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//  Part of the LLVM Project, under the Apache License v2.0 with LLVM
+//  Exceptions. See https://llvm.org/LICENSE.txt for license information.
+//  SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 
//===--===//
 //
-//  This file defines partial implementations of template specializations of
-//  the class ProgramStateTrait<>.  ProgramStateTrait<> is used by ProgramState
-//  to implement set/get methods for manipulating a ProgramState's
-//  generic data map.
+//   This file defines partial implementations of template specializations of
+//   the class ProgramStateTrait<>.  ProgramStateTrait<> is used by 
ProgramState
+//   to implement set/get methods for manipulating a ProgramState's
+//   generic data map.

steakhal wrote:

This comment header is just bad. I should come back to this.

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

@@ -107,7 +107,8 @@ class CallDescription {
 return CD1.matches(Call);
   }
 
-  /// \copydoc clang::ento::CallDescription::matchesAny(const CallEvent &, 
const CallDescription &)
+  /// \copydoc clang::ento::CallDescription::matchesAny(const CallEvent &, 
const
+  /// CallDescription &)

steakhal wrote:

I'm not sure how to resolve this. I'd need to check how to resolve this for 
Doxygen.
https://clang.llvm.org/doxygen/classclang_1_1ento_1_1CallDescription.html#ac6873d422bacd2cc5a9857b4f96248ff

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

@@ -188,88 +187,79 @@ struct ValueType {
 
 inline ValueType::SizeType ValueType::getSizeType(unsigned nbytes) {
   switch (nbytes) {
-case 1: return ST_8;
-case 2: return ST_16;
-case 4: return ST_32;
-case 8: return ST_64;
-case 16: return ST_128;
-default: return ST_0;
+  case 1:
+return ST_8;
+  case 2:
+return ST_16;
+  case 4:
+return ST_32;
+  case 8:
+return ST_64;
+  case 16:
+return ST_128;
+  default:
+return ST_0;

steakhal wrote:

```suggestion
// clang-format off
case 1: return ST_8;
case 2: return ST_16;
case 4: return ST_32;
case 8: return ST_64;
case 16: return ST_128;
default: return ST_0;
// clang-format on
```

This was previously nicely aligned.

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

@@ -441,48 +419,79 @@ class PrettyPrinter {
   // Return the precedence of a given node, for use in pretty printing.
   unsigned precedence(const SExpr *E) {
 switch (E->opcode()) {
-  case COP_Future: return Prec_Atom;
-  case COP_Undefined:  return Prec_Atom;
-  case COP_Wildcard:   return Prec_Atom;
-
-  case COP_Literal:return Prec_Atom;
-  case COP_LiteralPtr: return Prec_Atom;
-  case COP_Variable:   return Prec_Atom;
-  case COP_Function:   return Prec_Decl;
-  case COP_SFunction:  return Prec_Decl;
-  case COP_Code:   return Prec_Decl;
-  case COP_Field:  return Prec_Decl;
-
-  case COP_Apply:  return Prec_Postfix;
-  case COP_SApply: return Prec_Postfix;
-  case COP_Project:return Prec_Postfix;
-
-  case COP_Call:   return Prec_Postfix;
-  case COP_Alloc:  return Prec_Other;
-  case COP_Load:   return Prec_Postfix;
-  case COP_Store:  return Prec_Other;
-  case COP_ArrayIndex: return Prec_Postfix;
-  case COP_ArrayAdd:   return Prec_Postfix;
-
-  case COP_UnaryOp:return Prec_Unary;
-  case COP_BinaryOp:   return Prec_Binary;
-  case COP_Cast:   return Prec_Atom;
-
-  case COP_SCFG:   return Prec_Decl;
-  case COP_BasicBlock: return Prec_MAX;
-  case COP_Phi:return Prec_Atom;
-  case COP_Goto:   return Prec_Atom;
-  case COP_Branch: return Prec_Atom;
-  case COP_Return: return Prec_Other;
-
-  case COP_Identifier: return Prec_Atom;
-  case COP_IfThenElse: return Prec_Other;
-  case COP_Let:return Prec_Decl;
+case COP_Future:
+  return Prec_Atom;
+case COP_Undefined:
+  return Prec_Atom;
+case COP_Wildcard:
+  return Prec_Atom;
+
+case COP_Literal:
+  return Prec_Atom;
+case COP_LiteralPtr:
+  return Prec_Atom;
+case COP_Variable:
+  return Prec_Atom;
+case COP_Function:
+  return Prec_Decl;
+case COP_SFunction:
+  return Prec_Decl;
+case COP_Code:
+  return Prec_Decl;
+case COP_Field:
+  return Prec_Decl;
+
+case COP_Apply:
+  return Prec_Postfix;
+case COP_SApply:
+  return Prec_Postfix;
+case COP_Project:
+  return Prec_Postfix;
+
+case COP_Call:
+  return Prec_Postfix;
+case COP_Alloc:
+  return Prec_Other;
+case COP_Load:
+  return Prec_Postfix;
+case COP_Store:
+  return Prec_Other;
+case COP_ArrayIndex:
+  return Prec_Postfix;
+case COP_ArrayAdd:
+  return Prec_Postfix;
+
+case COP_UnaryOp:
+  return Prec_Unary;
+case COP_BinaryOp:
+  return Prec_Binary;
+case COP_Cast:
+  return Prec_Atom;
+
+case COP_SCFG:
+  return Prec_Decl;
+case COP_BasicBlock:
+  return Prec_MAX;
+case COP_Phi:
+  return Prec_Atom;
+case COP_Goto:
+  return Prec_Atom;
+case COP_Branch:
+  return Prec_Atom;
+case COP_Return:
+  return Prec_Other;
+
+case COP_Identifier:
+  return Prec_Atom;
+case COP_IfThenElse:
+  return Prec_Other;
+case COP_Let:
+  return Prec_Decl;

steakhal wrote:

```suggestion
  // clang-format off
  case COP_Future: return Prec_Atom;
  case COP_Undefined:  return Prec_Atom;
  case COP_Wildcard:   return Prec_Atom;

  case COP_Literal:return Prec_Atom;
  case COP_LiteralPtr: return Prec_Atom;
  case COP_Variable:   return Prec_Atom;
  case COP_Function:   return Prec_Decl;
  case COP_SFunction:  return Prec_Decl;
  case COP_Code:   return Prec_Decl;
  case COP_Field:  return Prec_Decl;

  case COP_Apply:  return Prec_Postfix;
  case COP_SApply: return Prec_Postfix;
  case COP_Project:return Prec_Postfix;

  case COP_Call:   return Prec_Postfix;
  case COP_Alloc:  return Prec_Other;
  case COP_Load:   return Prec_Postfix;
  case COP_Store:  return Prec_Other;
  case COP_ArrayIndex: return Prec_Postfix;
  case COP_ArrayAdd:   return Prec_Postfix;

  case COP_UnaryOp:return Prec_Unary;
  case COP_BinaryOp:   return Prec_Binary;
  case COP_Cast:   return Prec_Atom;

  case COP_SCFG:   return Prec_Decl;
  case COP_BasicBlock: return Prec_MAX;
  case COP_Phi:return Prec_Atom;
  case COP_Goto:   return Prec_Atom;
  case COP_Branch: return Prec_Atom;
  case COP_Return: return Prec_Other;

  case COP_Identifier: return Prec_Atom;
  case COP_IfThenElse: return Prec_Other;
  case COP_Let:return Prec_Decl;
  // clang-format on
```

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

@@ -1481,22 +1449,24 @@ class Return : public Terminator {
 return Vs.reduceReturn(*this, Ne);
   }
 
-  template 
-  typename C::CType compare(const Return *E, C &Cmp) const {
+  template  typename C::CType compare(const Return *E, C &Cmp) const {
 return Cmp.compare(Retval, E->Retval);
   }
 
 private:
-  SExpr* Retval;
+  SExpr *Retval;
 };
 
-inline ArrayRef Terminator::successors() {
+inline ArrayRef Terminator::successors() {
   switch (opcode()) {
-case COP_Goto:   return cast(this)->successors();
-case COP_Branch: return cast(this)->successors();
-case COP_Return: return cast(this)->successors();
-default:
-  return std::nullopt;
+  case COP_Goto:
+return cast(this)->successors();
+  case COP_Branch:
+return cast(this)->successors();
+  case COP_Return:
+return cast(this)->successors();
+  default:
+return std::nullopt;

steakhal wrote:

This was aligned before, but I don't see much value keeping it.

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

@@ -898,18 +867,18 @@ class CFGBlock {
 
   size_t getIndexInCFG() const;
 
-  CFGElement front()   const { return Elements.front();   }
-  CFGElement back()const { return Elements.back();}
+  CFGElement front() const { return Elements.front(); }
+  CFGElement back() const { return Elements.back(); }
 
-  iterator   begin() { return Elements.begin();   }
-  iterator   end()   { return Elements.end(); }
-  const_iterator begin()   const { return Elements.begin();   }
-  const_iterator end() const { return Elements.end(); }
+  iterator begin() { return Elements.begin(); }
+  iterator end() { return Elements.end(); }
+  const_iterator begin() const { return Elements.begin(); }
+  const_iterator end() const { return Elements.end(); }
 
-  reverse_iterator   rbegin(){ return Elements.rbegin();  }
-  reverse_iterator   rend()  { return Elements.rend();}
-  const_reverse_iterator rbegin()  const { return Elements.rbegin();  }
-  const_reverse_iterator rend()const { return Elements.rend();}
+  reverse_iterator rbegin() { return Elements.rbegin(); }
+  reverse_iterator rend() { return Elements.rend(); }
+  const_reverse_iterator rbegin() const { return Elements.rbegin(); }
+  const_reverse_iterator rend() const { return Elements.rend(); }

steakhal wrote:

These hunks were aligned before, but I don't think it's worth to keep it.
There are some similar later, that I won't explicitly highlight.

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

@@ -145,7 +146,8 @@ class CallDescription {
 return CD1.matchesAsWritten(CE);
   }
 
-  /// \copydoc clang::ento::CallDescription::matchesAnyAsWritten(const 
CallExpr &, const CallDescription &)
+  /// \copydoc clang::ento::CallDescription::matchesAnyAsWritten(const CallExpr
+  /// &, const CallDescription &)

steakhal wrote:

Same Doxygen problem here.

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

@@ -48,17 +48,26 @@ class ConstructionContextItem {
 
   LLVM_DUMP_METHOD static StringRef getKindAsString(ItemKind K) {
 switch (K) {
-  case VariableKind:return "construct into local variable";
-  case NewAllocatorKind:return "construct into new-allocator";
-  case ReturnKind:  return "construct into return address";
-  case MaterializationKind: return "materialize temporary";
-  case TemporaryDestructorKind: return "destroy temporary";
-  case ElidedDestructorKind:return "elide destructor";
-  case ElidableConstructorKind: return "elide constructor";
-  case ArgumentKind:return "construct into argument";
-  case LambdaCaptureKind:
-return "construct into lambda captured variable";
-  case InitializerKind: return "construct into member variable";
+case VariableKind:
+  return "construct into local variable";
+case NewAllocatorKind:
+  return "construct into new-allocator";
+case ReturnKind:
+  return "construct into return address";
+case MaterializationKind:
+  return "materialize temporary";
+case TemporaryDestructorKind:
+  return "destroy temporary";
+case ElidedDestructorKind:
+  return "elide destructor";
+case ElidableConstructorKind:
+  return "elide constructor";
+case ArgumentKind:
+  return "construct into argument";
+case LambdaCaptureKind:
+  return "construct into lambda captured variable";
+case InitializerKind:
+  return "construct into member variable";

steakhal wrote:

This hunk was aligned before, but I actually like the new format more.

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

@@ -393,20 +385,19 @@ class ExprEngine {
   ProgramStateRef processAssume(ProgramStateRef state, SVal cond,
 bool assumption);
 
-  /// processRegionChanges - Called by ProgramStateManager whenever a change 
is made
+  /// processRegionChanges - Called by ProgramStateManager whenever a change is
+  /// made

steakhal wrote:

```suggestion
  /// It's called by ProgramStateManager whenever a change is made.
```

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

@@ -28,29 +28,29 @@ namespace clang {
 
//===--===//
 
 namespace dataflow {
-  struct forward_analysis_tag {};
-  struct backward_analysis_tag {};
+struct forward_analysis_tag {};
+struct backward_analysis_tag {};
 } // end namespace dataflow
 
 
//===--===//
 /// DataflowValues.  Container class to store dataflow values for a CFG.
 
//===--===//
 
 template 
+  typename _AnalysisDirTag = dataflow::forward_analysis_tag>
 class DataflowValues {
 
   
//======//
   // Type declarations.
   
//======//
 
 public:
-  typedef typename ValueTypes::ValTy   ValTy;
-  typedef typename ValueTypes::AnalysisDataTy  AnalysisDataTy;
-  typedef _AnalysisDirTag  AnalysisDirTag;
-  typedef llvm::DenseMap  EdgeDataMapTy;
-  typedef llvm::DenseMap   BlockDataMapTy;
-  typedef llvm::DenseMap   StmtDataMapTy;
+  typedef typename ValueTypes::ValTy ValTy;
+  typedef typename ValueTypes::AnalysisDataTy AnalysisDataTy;
+  typedef _AnalysisDirTag AnalysisDirTag;
+  typedef llvm::DenseMap EdgeDataMapTy;
+  typedef llvm::DenseMap BlockDataMapTy;
+  typedef llvm::DenseMap StmtDataMapTy;

steakhal wrote:

This was aligned before.

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

@@ -1,4 +1,5 @@
-//===--- PathDiagnosticConsumers.h - Path Diagnostic Clients --*- C++ 
-*-===//
+//===--- PathDiagnosticConsumers.h - Path Diagnostic Clients --*- C++
+//-*-===//

steakhal wrote:

```suggestion
//===--- PathDiagnosticConsumers.h - Path Diagnostic Clients *- C++ -*-===//
```
Uhh, I hope I didn't miss similar cases.

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

@@ -128,14 +128,14 @@ enum TIL_CastOpcode : unsigned char {
   CAST_objToPtr
 };
 
-const TIL_Opcode   COP_Min  = COP_Future;
-const TIL_Opcode   COP_Max  = COP_Branch;
-const TIL_UnaryOpcode  UOP_Min  = UOP_Minus;
-const TIL_UnaryOpcode  UOP_Max  = UOP_LogicNot;
-const TIL_BinaryOpcode BOP_Min  = BOP_Add;
-const TIL_BinaryOpcode BOP_Max  = BOP_LogicOr;
-const TIL_CastOpcode   CAST_Min = CAST_none;
-const TIL_CastOpcode   CAST_Max = CAST_toInt;
+const TIL_Opcode COP_Min = COP_Future;
+const TIL_Opcode COP_Max = COP_Branch;
+const TIL_UnaryOpcode UOP_Min = UOP_Minus;
+const TIL_UnaryOpcode UOP_Max = UOP_LogicNot;
+const TIL_BinaryOpcode BOP_Min = BOP_Add;
+const TIL_BinaryOpcode BOP_Max = BOP_LogicOr;
+const TIL_CastOpcode CAST_Min = CAST_none;
+const TIL_CastOpcode CAST_Max = CAST_toInt;

steakhal wrote:

```suggestion
// clang-format off
const TIL_Opcode   COP_Min  = COP_Future;
const TIL_Opcode   COP_Max  = COP_Branch;
const TIL_UnaryOpcode  UOP_Min  = UOP_Minus;
const TIL_UnaryOpcode  UOP_Max  = UOP_LogicNot;
const TIL_BinaryOpcode BOP_Min  = BOP_Add;
const TIL_BinaryOpcode BOP_Max  = BOP_LogicOr;
const TIL_CastOpcode   CAST_Min = CAST_none;
const TIL_CastOpcode   CAST_Max = CAST_toInt;
// clang-format on
```
This was previously nicely aligned.

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

@@ -520,18 +518,19 @@ class TypedRegion : public SubRegion {
 
   bool isBoundable() const override { return true; }
 
-  static bool classof(const MemRegion* R) {
+  static bool classof(const MemRegion *R) {
 unsigned k = R->getKind();
 return k >= BEGIN_TYPED_REGIONS && k <= END_TYPED_REGIONS;
   }
 };
 
-/// TypedValueRegion - An abstract class representing regions having a typed 
value.
+/// TypedValueRegion - An abstract class representing regions having a typed
+/// value.

steakhal wrote:

```suggestion
/// An abstract class representing regions having a typed value.
```

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

[clang] [DRAFT][analyzer][NFC] clang-format our folders (PR #82599)

[Balazs Benics via cfe-commits]

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

[clang] [OpenMP] Clang Codegen Interop : Accept multiple init (PR #82604)

[via cfe-commits]

https://github.com/SunilKuravinakop created 
https://github.com/llvm/llvm-project/pull/82604

Modifying clang/lib/CodeGen/CGStmtOpenMP.cpp to accept multiple `init` clauses 
with `interop` directive.

>From 6444ef3f60a9f8ed8b3f413997259fe5006396b7 Mon Sep 17 00:00:00 2001
From: Sunil Kuravinakop 
Date: Tue, 20 Feb 2024 11:29:49 -0600
Subject: [PATCH] Accept multiple init clauses in interop directive.

  Changes to be committed:
modified:   clang/lib/CodeGen/CGStmtOpenMP.cpp
---
 clang/lib/CodeGen/CGStmtOpenMP.cpp | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/clang/lib/CodeGen/CGStmtOpenMP.cpp 
b/clang/lib/CodeGen/CGStmtOpenMP.cpp
index 8fd74697de3c0f..c512b0bd851f7a 100644
--- a/clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ b/clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -7023,19 +7023,25 @@ void CodeGenFunction::EmitOMPInteropDirective(const 
OMPInteropDirective &S) {
  S.getSingleClause())) &&
  "OMPNowaitClause clause is used separately in OMPInteropDirective.");
 
-  if (const auto *C = S.getSingleClause()) {
-llvm::Value *InteropvarPtr =
-EmitLValue(C->getInteropVar()).getPointer(*this);
-llvm::omp::OMPInteropType InteropType = llvm::omp::OMPInteropType::Unknown;
-if (C->getIsTarget()) {
-  InteropType = llvm::omp::OMPInteropType::Target;
-} else {
-  assert(C->getIsTargetSync() && "Expected interop-type 
target/targetsync");
-  InteropType = llvm::omp::OMPInteropType::TargetSync;
+  auto It = S.getClausesOfKind();
+  if (!It.empty()) {
+// Look at the multiple init clauses
+for (auto C : It) {
+  llvm::Value *InteropvarPtr =
+  EmitLValue(C->getInteropVar()).getPointer(*this);
+  llvm::omp::OMPInteropType InteropType =
+  llvm::omp::OMPInteropType::Unknown;
+  if (C->getIsTarget()) {
+InteropType = llvm::omp::OMPInteropType::Target;
+  } else {
+assert(C->getIsTargetSync() &&
+   "Expected interop-type target/targetsync");
+InteropType = llvm::omp::OMPInteropType::TargetSync;
+  }
+  OMPBuilder.createOMPInteropInit(Builder, InteropvarPtr, InteropType,
+  Device, NumDependences, DependenceList,
+  Data.HasNowaitClause);
 }
-OMPBuilder.createOMPInteropInit(Builder, InteropvarPtr, InteropType, 
Device,
-NumDependences, DependenceList,
-Data.HasNowaitClause);
   } else if (const auto *C = S.getSingleClause()) {
 llvm::Value *InteropvarPtr =
 EmitLValue(C->getInteropVar()).getPointer(*this);

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

[clang] [clang-format] Do not update cursor pos if no includes replacement (PR #77456)

[Owen Pan via cfe-commits]

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

[clang] [clang-format] Do not update cursor pos if no includes replacement (PR #77456)

[Owen Pan via cfe-commits]

@@ -3134,20 +3135,24 @@ static void sortCppIncludes(const FormatStyle &Style,
 }
 result += Includes[Index].Text;
 if (Cursor && CursorIndex == Index)
-  *Cursor = IncludesBeginOffset + result.size() - CursorToEOLOffset;
+  NewCursor = IncludesBeginOffset + result.size() - CursorToEOLOffset;
 CurrentCategory = Includes[Index].Category;
   }
 
-  if (Cursor && *Cursor >= IncludesEndOffset)
-*Cursor += result.size() - IncludesBlockSize;
-
   // If the #includes are out of order, we generate a single replacement fixing
   // the entire range of blocks. Otherwise, no replacement is generated.
   if (replaceCRLF(result) == replaceCRLF(std::string(Code.substr(
  IncludesBeginOffset, IncludesBlockSize {
 return;

owenca wrote:

```suggestion
if (Cursor)
  *Cursor = OldCursor;
return;
```

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

[clang] [clang-format] Do not update cursor pos if no includes replacement (PR #77456)

[Owen Pan via cfe-commits]

@@ -3134,20 +3135,24 @@ static void sortCppIncludes(const FormatStyle &Style,
 }
 result += Includes[Index].Text;
 if (Cursor && CursorIndex == Index)
-  *Cursor = IncludesBeginOffset + result.size() - CursorToEOLOffset;
+  NewCursor = IncludesBeginOffset + result.size() - CursorToEOLOffset;

owenca wrote:

```suggestion
  *Cursor = IncludesBeginOffset + result.size() - CursorToEOLOffset;
```
i.e. undo the change.

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

[clang] [clang-format] Do not update cursor pos if no includes replacement (PR #77456)

[Owen Pan via cfe-commits]

https://github.com/owenca commented:

`git diff Format.cpp` output:
```
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -3116,6 +3116,7 @@ static void sortCppIncludes(const FormatStyle &Style,
 return;
   }
 
+  const auto OldCursor = Cursor ? *Cursor : 0;
   std::string result;
   for (unsigned Index : Indices) {
 if (!result.empty()) {
@@ -3139,6 +3140,8 @@ static void sortCppIncludes(const FormatStyle &Style,
   // the entire range of blocks. Otherwise, no replacement is generated.
   if (replaceCRLF(result) == replaceCRLF(std::string(Code.substr(
  IncludesBeginOffset, IncludesBlockSize {
+if (Cursor)
+  *Cursor = OldCursor;
 return;
   }
 
```

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

[clang] [clang-format] Do not update cursor pos if no includes replacement (PR #77456)

[Owen Pan via cfe-commits]

@@ -3134,20 +3135,24 @@ static void sortCppIncludes(const FormatStyle &Style,
 }
 result += Includes[Index].Text;
 if (Cursor && CursorIndex == Index)
-  *Cursor = IncludesBeginOffset + result.size() - CursorToEOLOffset;
+  NewCursor = IncludesBeginOffset + result.size() - CursorToEOLOffset;
 CurrentCategory = Includes[Index].Category;
   }
 
-  if (Cursor && *Cursor >= IncludesEndOffset)
-*Cursor += result.size() - IncludesBlockSize;
-
   // If the #includes are out of order, we generate a single replacement fixing
   // the entire range of blocks. Otherwise, no replacement is generated.
   if (replaceCRLF(result) == replaceCRLF(std::string(Code.substr(
  IncludesBeginOffset, IncludesBlockSize {
 return;
   }
 
+  if (Cursor) {
+if (NewCursor != UINT_MAX)
+  *Cursor = NewCursor;
+else if (*Cursor >= IncludesEndOffset)
+  *Cursor += result.size() - IncludesBlockSize;
+  }
+

owenca wrote:

```suggestion
```

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

[clang] [OpenMP] Clang Codegen Interop : Accept multiple init (PR #82604)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: None (SunilKuravinakop)


Changes

Modifying clang/lib/CodeGen/CGStmtOpenMP.cpp to accept multiple `init` clauses 
with `interop` directive.

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


1 Files Affected:

- (modified) clang/lib/CodeGen/CGStmtOpenMP.cpp (+18-12) 


``diff
diff --git a/clang/lib/CodeGen/CGStmtOpenMP.cpp 
b/clang/lib/CodeGen/CGStmtOpenMP.cpp
index 8fd74697de3c0f..c512b0bd851f7a 100644
--- a/clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ b/clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -7023,19 +7023,25 @@ void CodeGenFunction::EmitOMPInteropDirective(const 
OMPInteropDirective &S) {
  S.getSingleClause())) &&
  "OMPNowaitClause clause is used separately in OMPInteropDirective.");
 
-  if (const auto *C = S.getSingleClause()) {
-llvm::Value *InteropvarPtr =
-EmitLValue(C->getInteropVar()).getPointer(*this);
-llvm::omp::OMPInteropType InteropType = llvm::omp::OMPInteropType::Unknown;
-if (C->getIsTarget()) {
-  InteropType = llvm::omp::OMPInteropType::Target;
-} else {
-  assert(C->getIsTargetSync() && "Expected interop-type 
target/targetsync");
-  InteropType = llvm::omp::OMPInteropType::TargetSync;
+  auto It = S.getClausesOfKind();
+  if (!It.empty()) {
+// Look at the multiple init clauses
+for (auto C : It) {
+  llvm::Value *InteropvarPtr =
+  EmitLValue(C->getInteropVar()).getPointer(*this);
+  llvm::omp::OMPInteropType InteropType =
+  llvm::omp::OMPInteropType::Unknown;
+  if (C->getIsTarget()) {
+InteropType = llvm::omp::OMPInteropType::Target;
+  } else {
+assert(C->getIsTargetSync() &&
+   "Expected interop-type target/targetsync");
+InteropType = llvm::omp::OMPInteropType::TargetSync;
+  }
+  OMPBuilder.createOMPInteropInit(Builder, InteropvarPtr, InteropType,
+  Device, NumDependences, DependenceList,
+  Data.HasNowaitClause);
 }
-OMPBuilder.createOMPInteropInit(Builder, InteropvarPtr, InteropType, 
Device,
-NumDependences, DependenceList,
-Data.HasNowaitClause);
   } else if (const auto *C = S.getSingleClause()) {
 llvm::Value *InteropvarPtr =
 EmitLValue(C->getInteropVar()).getPointer(*this);

``




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

[clang] [clang-format] Do not update cursor pos if no includes replacement (PR #77456)

[Owen Pan via cfe-commits]

owenca wrote:

> As a side note, I tried adding these two tests but they fail, meaning the 
> cursor is still incorrectly computed with CRLF when replacing lines.
> 
> This is due to adding lines between the include groups (with Regroup option), 
> as this new line is added with only the character `\n` (while the line break 
> between include lines is right because the include line itself contains a 
> trailing `\r`). I am not sure how to fix this correctly because I do not want 
> to break things by trimming the include line and I do not think 
> `sortCppIncludes` should manage whitespaces (`WhitespaceManager` seems to be 
> the correct class to handle this?). Maybe the cursor should be updated when 
> replacing these whitespaces?
> 
> ```c++
> TEST_F(
>SortIncludesTest,
>
> CalculatesCorrectCursorPositionWhenNewLineReplacementsWithRegroupingAndCRLF) {
>   Style.IncludeBlocks   = Style.IBS_Regroup;
>   FmtStyle.LineEnding   = FormatStyle::LE_CRLF;
>   Style.IncludeCategories = {
>   {"^\"a\"", 0, 0, false}, {"^\"b\"", 1, 1, false}, {".*", 2, 2, false}};
>   std::string Code = "#include \"a\"\r\n" // Start of line: 0
>  "#include \"b\"\r\n" // Start of line: 14
>  "#include \"c\"\r\n" // Start of line: 28
>  "\r\n"   // Start of line: 42
>  "int i;";// Start of line: 44
>   std::string Expected = "#include \"a\"\r\n" // Start of line: 0
>  "\r\n"   // Start of line: 14
>  "#include \"b\"\r\n" // Start of line: 16
>  "\r\n"   // Start of line: 30
>  "#include \"c\"\r\n" // Start of line: 32
>  "\r\n"   // Start of line: 46
>  "int i;";// Start of line: 48
>   EXPECT_EQ(Expected, sort(Code));
>   EXPECT_EQ(0u, newCursor(Code, 0));
>   EXPECT_EQ(15u, newCursor(Code, 14)); // FIXME: should expect 16, caused by 
> \r
>   EXPECT_EQ(30u, newCursor(Code, 28)); // FIXME: should expect 32, caused by 
> \r
>   EXPECT_EQ(44u, newCursor(Code, 42)); // FIXME: should expect 46, caused by 
> \r
>   EXPECT_EQ(46u, newCursor(Code, 44)); // FIXME: should expect 48, caused by 
> \r
> }
> 
> TEST_F(
>SortIncludesTest,
>
> CalculatesCorrectCursorPositionWhenNoNewLineReplacementsWithRegroupingAndCRLF)
>  {
>   Style.IncludeBlocks = Style.IBS_Regroup;
>   FmtStyle.LineEnding = FormatStyle::LE_CRLF;
>   Style.IncludeCategories = {
>   {"^\"a\"", 0, 0, false}, {"^\"b\"", 1, 1, false}, {".*", 2, 2, false}};
>   std::string Code = "#include \"a\"\r\n" // Start of line: 0
>  "\r\n"   // Start of line: 14
>  "#include \"c\"\r\n" // Start of line: 16
>  "\r\n"   // Start of line: 30
>  "#include \"b\"\r\n" // Start of line: 32
>  "\r\n"   // Start of line: 46
>  "int i;";// Start of line: 48
>   std::string Expected = "#include \"a\"\r\n" // Start of line: 0
>  "\r\n"   // Start of line: 14
>  "#include \"b\"\r\n" // Start of line: 16
>  "\r\n"   // Start of line: 30
>  "#include \"c\"\r\n" // Start of line: 32
>  "\r\n"   // Start of line: 46
>  "int i;";// Start of line: 48
>   EXPECT_EQ(Expected, sort(Code));
>   EXPECT_EQ(0u, newCursor(Code, 0));
>   EXPECT_EQ(14u, newCursor(Code, 14));
>   EXPECT_EQ(30u, newCursor(Code, 16)); // FIXME: should expect 32, caused by 
> \r
>   EXPECT_EQ(30u, newCursor(Code, 30));
>   EXPECT_EQ(15u, newCursor(Code, 32)); // FIXME: should expect 15, caused by 
> \r
>   EXPECT_EQ(44u, newCursor(Code, 46)); // FIXME: should expect 46, caused by 
> \r
>   EXPECT_EQ(46u, newCursor(Code, 48)); // FIXME: should expect 48, caused by 
> \r
> }
> ```

With my suggested fix, these tests should also pass.

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

[clang] [llvm] [LV][LAA] Vectorize math lib calls with mem write-only attribute (PR #78432)

[Paschalis Mpeis via cfe-commits]

https://github.com/paschalis-mpeis updated 
https://github.com/llvm/llvm-project/pull/78432

>From 869079fa57b3a8da9b9f9ea541f7d542be1bb8bc Mon Sep 17 00:00:00 2001
From: Paschalis Mpeis 
Date: Tue, 16 Jan 2024 10:53:09 +
Subject: [PATCH 1/5] LAA cannot vectorize lib calls like modf/modff

Functions like modf/modff are math lib calls that set memory write-only
attribute. Given that a target has vectorized mappings, LAA should allow
vectorization.
---
 ...arch64-veclib-function-calls-linear-ptrs.c | 57 +++
 1 file changed, 57 insertions(+)
 create mode 100644 
clang/test/CodeGen/aarch64-veclib-function-calls-linear-ptrs.c

diff --git a/clang/test/CodeGen/aarch64-veclib-function-calls-linear-ptrs.c 
b/clang/test/CodeGen/aarch64-veclib-function-calls-linear-ptrs.c
new file mode 100644
index 00..a449fac147058a
--- /dev/null
+++ b/clang/test/CodeGen/aarch64-veclib-function-calls-linear-ptrs.c
@@ -0,0 +1,57 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --filter "call.*(frexp|modf)" --version 4
+// RUN: %clang --target=aarch64-linux-gnu -march=armv8-a+sve -O3 -mllvm 
-vector-library=ArmPL -mllvm -force-vector-interleave=1 -mllvm 
-prefer-predicate-over-epilogue=predicate-dont-vectorize -emit-llvm -S -o - %s 
| FileCheck %s
+
+// REQUIRES: aarch64-registered-target
+
+/*
+Testing vectorization of math functions that have the attribute write-only to
+memory set. Given they have vectorized counterparts, they should be able to
+vectorize.
+*/
+
+// The following define is required to access some math functions.
+#define _GNU_SOURCE
+#include 
+
+// frexp/frexpf have no TLI mappings yet.
+
+// CHECK-LABEL: define dso_local void @frexp_f64(
+// CHECK-SAME: ptr nocapture noundef readonly [[IN:%.*]], ptr nocapture 
noundef writeonly [[OUT1:%.*]], ptr nocapture noundef writeonly [[OUT2:%.*]], 
i32 noundef [[N:%.*]]) local_unnamed_addr #[[ATTR0:[0-9]+]] {
+// CHECK:[[CALL:%.*]] = tail call double @frexp(double noundef 
[[TMP0:%.*]], ptr noundef [[ADD_PTR:%.*]]) #[[ATTR2:[0-9]+]]
+//
+void frexp_f64(double *in, double *out1, int *out2, int N) {
+  for (int i = 0; i < N; ++i)
+*out1 = frexp(in[i], out2+i);
+}
+
+// CHECK-LABEL: define dso_local void @frexp_f32(
+// CHECK-SAME: ptr nocapture noundef readonly [[IN:%.*]], ptr nocapture 
noundef writeonly [[OUT1:%.*]], ptr nocapture noundef writeonly [[OUT2:%.*]], 
i32 noundef [[N:%.*]]) local_unnamed_addr #[[ATTR0]] {
+// CHECK:[[CALL:%.*]] = tail call float @frexpf(float noundef 
[[TMP0:%.*]], ptr noundef [[ADD_PTR:%.*]]) #[[ATTR2]]
+//
+void frexp_f32(float *in, float *out1, int *out2, int N) {
+  for (int i = 0; i < N; ++i)
+*out1 = frexpf(in[i], out2+i);
+}
+
+
+// TODO: LAA must allow vectorization.
+
+// CHECK-LABEL: define dso_local void @modf_f64(
+// CHECK-SAME: ptr nocapture noundef readonly [[IN:%.*]], ptr nocapture 
noundef writeonly [[OUT1:%.*]], ptr nocapture noundef writeonly [[OUT2:%.*]], 
i32 noundef [[N:%.*]]) local_unnamed_addr #[[ATTR0]] {
+// CHECK:[[CALL:%.*]] = tail call double @modf(double noundef 
[[TMP0:%.*]], ptr noundef [[ADD_PTR:%.*]]) #[[ATTR3:[0-9]+]]
+//
+void modf_f64(double *in, double *out1, double *out2, int N) {
+  for (int i = 0; i < N; ++i)
+  out1[i] = modf(in[i], out2+i);
+}
+
+// TODO: LAA must allow vectorization.
+
+// CHECK-LABEL: define dso_local void @modf_f32(
+// CHECK-SAME: ptr nocapture noundef readonly [[IN:%.*]], ptr nocapture 
noundef writeonly [[OUT1:%.*]], ptr nocapture noundef writeonly [[OUT2:%.*]], 
i32 noundef [[N:%.*]]) local_unnamed_addr #[[ATTR0]] {
+// CHECK:[[CALL:%.*]] = tail call float @modff(float noundef [[TMP0:%.*]], 
ptr noundef [[ADD_PTR:%.*]]) #[[ATTR4:[0-9]+]]
+//
+void modf_f32(float *in, float *out1, float *out2, int N) {
+  for (int i = 0; i < N; ++i)
+  out1[i] = modff(in[i], out2+i);
+}

>From 32d2b4581dd19e289f5b21de6de931b4f6268612 Mon Sep 17 00:00:00 2001
From: Paschalis Mpeis 
Date: Wed, 17 Jan 2024 09:44:45 +
Subject: [PATCH 2/5] [LV][LAA] Vectorize math lib calls with mem write-only
 attribute

Teach LAA to consider safe specific math lib calls which are known to
have set the memory write-only attribute. Those attributes are set to
calls by inferNonMandatoryLibFuncAttrs, in BuildLibCalls.cpp, and the
current ones are modf/modff and frexp/frexpf.

This happens only when the calls are found through TLI to have
vectorized counterparts.
---
 ...arch64-veclib-function-calls-linear-ptrs.c | 15 ++-
 llvm/lib/Analysis/LoopAccessAnalysis.cpp  | 19 +++
 2 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/clang/test/CodeGen/aarch64-veclib-function-calls-linear-ptrs.c 
b/clang/test/CodeGen/aarch64-veclib-function-calls-linear-ptrs.c
index a449fac147058a..957b3f5cb235d3 100644
--- a/clang/test/CodeGen/aarch64-veclib-function-calls-linear-ptrs.c
+++ b/clang/test/CodeGen/aarch64-veclib-function-calls-linear-ptrs.c
@@ -17,7 +17,7 @@ vectorize.
 
 // CHE

[clang] [clang] Implement CWG2759 "`[[no_unique_address]` and common initial sequence" (PR #82607)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll created 
https://github.com/llvm/llvm-project/pull/82607

This patch implements said defect report resolution by adding additional check 
to common initial sequence evaluation. Consequently, this fixes CWG2759.

No special handling of `[[msvc::no_unique_address]]` is performed, so it should 
follow `[[no_unique_address]]` behavior.

>From 22facf44ec3f97fcdc40f2431ec26ca7ef441c67 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Thu, 22 Feb 2024 13:28:04 +0300
Subject: [PATCH] [clang] Implement CWG2759 "`[[no_unique_address]` and common
 initial sequence"

This patch implements said defect report resolution by adding additional check 
to common initial sequence evaluation. Consequently, this fixes CWG2759.

No special handling of `[[msvc::no_unique_address]]` is performed, so it should 
follow `[[no_unique_address]]` behavior.
---
 clang/docs/ReleaseNotes.rst|  6 ++-
 clang/lib/Sema/SemaChecking.cpp|  5 ++
 clang/test/CXX/drs/dr27xx.cpp  | 83 ++
 clang/test/SemaCXX/type-traits.cpp | 10 ++--
 clang/www/cxx_dr_status.html   |  2 +-
 5 files changed, 98 insertions(+), 8 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index bac166e6c35627..a7c0f2fbbe7604 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -83,8 +83,6 @@ C++20 Feature Support
 
 - Implemented the `__is_layout_compatible` intrinsic to support
   `P0466R5: Layout-compatibility and Pointer-interconvertibility Traits 
`_.
-  Note: `CWG2759: [[no_unique_address] and common initial sequence 
`_
-  is not yet implemented.
 
 C++23 Feature Support
 ^
@@ -108,6 +106,10 @@ Resolutions to C++ Defect Reports
   of two types.
   (`CWG1719: Layout compatibility and cv-qualification revisited 
`_).
 
+- ``[[no_unique_address]]`` is now respected when evaluating layout
+  compatibility of two types.
+  (`CWG2759: [[no_unique_address] and common initial sequence  
`_).
+
 C Language Changes
 --
 
diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index e8bfb215a5b4c5..aba8852f6cfca4 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -19033,6 +19033,11 @@ static bool isLayoutCompatible(ASTContext &C, 
FieldDecl *Field1,
   return false;
   }
 
+  if (Field1->hasAttr() ||
+  Field2->hasAttr()) {
+return false;
+  }
+
   return true;
 }
 
diff --git a/clang/test/CXX/drs/dr27xx.cpp b/clang/test/CXX/drs/dr27xx.cpp
index dd3fd5a20163fa..3fdf384bef27a7 100644
--- a/clang/test/CXX/drs/dr27xx.cpp
+++ b/clang/test/CXX/drs/dr27xx.cpp
@@ -10,6 +10,89 @@
 // expected-no-diagnostics
 #endif
 
+namespace dr2759 { // dr2759: 19
+#if __cplusplus >= 201103L
+
+struct CStruct {
+  int one;
+  int two;
+};
+
+struct CEmptyStruct {};
+struct CEmptyStruct2 {};
+
+struct CStructNoUniqueAddress {
+  int one;
+  [[no_unique_address]] int two;
+};
+
+struct CStructNoUniqueAddress2 {
+  int one;
+  [[no_unique_address]] int two;
+};
+
+union UnionLayout {
+  int a;
+  double b;
+  CStruct c;
+  [[no_unique_address]] CEmptyStruct d;
+  [[no_unique_address]] CEmptyStruct2 e;
+};
+
+union UnionLayout2 {
+  CStruct c;
+  int a;
+  CEmptyStruct2 e;
+  double b;
+  [[no_unique_address]] CEmptyStruct d;
+};
+
+union UnionLayout3 {
+  CStruct c;
+  int a;
+  double b;
+  [[no_unique_address]] CEmptyStruct d;
+};
+
+struct StructWithAnonUnion {
+  union {
+int a;
+double b;
+CStruct c;
+[[no_unique_address]] CEmptyStruct d;
+[[no_unique_address]] CEmptyStruct2 e;
+  };
+};
+
+struct StructWithAnonUnion2 {
+  union {
+CStruct c;
+int a;
+CEmptyStruct2 e;
+double b;
+[[no_unique_address]] CEmptyStruct d;
+  };
+};
+
+struct StructWithAnonUnion3 {
+  union {
+CStruct c;
+int a;
+CEmptyStruct2 e;
+double b;
+[[no_unique_address]] CEmptyStruct d;
+  } u;
+};
+
+static_assert(__is_layout_compatible(CStruct, CStructNoUniqueAddress) != 
bool(__has_cpp_attribute(no_unique_address)), "");
+static_assert(__is_layout_compatible(CStructNoUniqueAddress, 
CStructNoUniqueAddress2) != bool(__has_cpp_attribute(no_unique_address)), "");
+static_assert(!__is_layout_compatible(UnionLayout, UnionLayout2), "");
+static_assert(!__is_layout_compatible(UnionLayout, UnionLayout3), "");
+static_assert(!__is_layout_compatible(StructWithAnonUnion, 
StructWithAnonUnion2), "");
+static_assert(!__is_layout_compatible(StructWithAnonUnion, 
StructWithAnonUnion3), "");
+#endif
+} // namespace dr2759
+
 namespace dr2789 { // dr2789: 18
 #if __cplusplus >= 202302L
 template 
diff --git a/clang/test/SemaCXX/type-traits.cpp 
b/clang/test/SemaCXX/type-traits.cpp
index 2c35d5ee19a4c6..23c339ebdf0826 100644
--- a/clang/test/SemaCXX/type-traits.cpp
+++ b/c

[clang] [clang] Implement CWG2759 "`[[no_unique_address]` and common initial sequence" (PR #82607)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Vlad Serebrennikov (Endilll)


Changes

This patch implements said defect report resolution by adding additional check 
to common initial sequence evaluation. Consequently, this fixes CWG2759.

No special handling of `[[msvc::no_unique_address]]` is performed, so it should 
follow `[[no_unique_address]]` behavior.

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


5 Files Affected:

- (modified) clang/docs/ReleaseNotes.rst (+4-2) 
- (modified) clang/lib/Sema/SemaChecking.cpp (+5) 
- (modified) clang/test/CXX/drs/dr27xx.cpp (+83) 
- (modified) clang/test/SemaCXX/type-traits.cpp (+5-5) 
- (modified) clang/www/cxx_dr_status.html (+1-1) 


``diff
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index bac166e6c35627..a7c0f2fbbe7604 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -83,8 +83,6 @@ C++20 Feature Support
 
 - Implemented the `__is_layout_compatible` intrinsic to support
   `P0466R5: Layout-compatibility and Pointer-interconvertibility Traits 
`_.
-  Note: `CWG2759: [[no_unique_address] and common initial sequence 
`_
-  is not yet implemented.
 
 C++23 Feature Support
 ^
@@ -108,6 +106,10 @@ Resolutions to C++ Defect Reports
   of two types.
   (`CWG1719: Layout compatibility and cv-qualification revisited 
`_).
 
+- ``[[no_unique_address]]`` is now respected when evaluating layout
+  compatibility of two types.
+  (`CWG2759: [[no_unique_address] and common initial sequence  
`_).
+
 C Language Changes
 --
 
diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index e8bfb215a5b4c5..aba8852f6cfca4 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -19033,6 +19033,11 @@ static bool isLayoutCompatible(ASTContext &C, 
FieldDecl *Field1,
   return false;
   }
 
+  if (Field1->hasAttr() ||
+  Field2->hasAttr()) {
+return false;
+  }
+
   return true;
 }
 
diff --git a/clang/test/CXX/drs/dr27xx.cpp b/clang/test/CXX/drs/dr27xx.cpp
index dd3fd5a20163fa..3fdf384bef27a7 100644
--- a/clang/test/CXX/drs/dr27xx.cpp
+++ b/clang/test/CXX/drs/dr27xx.cpp
@@ -10,6 +10,89 @@
 // expected-no-diagnostics
 #endif
 
+namespace dr2759 { // dr2759: 19
+#if __cplusplus >= 201103L
+
+struct CStruct {
+  int one;
+  int two;
+};
+
+struct CEmptyStruct {};
+struct CEmptyStruct2 {};
+
+struct CStructNoUniqueAddress {
+  int one;
+  [[no_unique_address]] int two;
+};
+
+struct CStructNoUniqueAddress2 {
+  int one;
+  [[no_unique_address]] int two;
+};
+
+union UnionLayout {
+  int a;
+  double b;
+  CStruct c;
+  [[no_unique_address]] CEmptyStruct d;
+  [[no_unique_address]] CEmptyStruct2 e;
+};
+
+union UnionLayout2 {
+  CStruct c;
+  int a;
+  CEmptyStruct2 e;
+  double b;
+  [[no_unique_address]] CEmptyStruct d;
+};
+
+union UnionLayout3 {
+  CStruct c;
+  int a;
+  double b;
+  [[no_unique_address]] CEmptyStruct d;
+};
+
+struct StructWithAnonUnion {
+  union {
+int a;
+double b;
+CStruct c;
+[[no_unique_address]] CEmptyStruct d;
+[[no_unique_address]] CEmptyStruct2 e;
+  };
+};
+
+struct StructWithAnonUnion2 {
+  union {
+CStruct c;
+int a;
+CEmptyStruct2 e;
+double b;
+[[no_unique_address]] CEmptyStruct d;
+  };
+};
+
+struct StructWithAnonUnion3 {
+  union {
+CStruct c;
+int a;
+CEmptyStruct2 e;
+double b;
+[[no_unique_address]] CEmptyStruct d;
+  } u;
+};
+
+static_assert(__is_layout_compatible(CStruct, CStructNoUniqueAddress) != 
bool(__has_cpp_attribute(no_unique_address)), "");
+static_assert(__is_layout_compatible(CStructNoUniqueAddress, 
CStructNoUniqueAddress2) != bool(__has_cpp_attribute(no_unique_address)), "");
+static_assert(!__is_layout_compatible(UnionLayout, UnionLayout2), "");
+static_assert(!__is_layout_compatible(UnionLayout, UnionLayout3), "");
+static_assert(!__is_layout_compatible(StructWithAnonUnion, 
StructWithAnonUnion2), "");
+static_assert(!__is_layout_compatible(StructWithAnonUnion, 
StructWithAnonUnion3), "");
+#endif
+} // namespace dr2759
+
 namespace dr2789 { // dr2789: 18
 #if __cplusplus >= 202302L
 template 
diff --git a/clang/test/SemaCXX/type-traits.cpp 
b/clang/test/SemaCXX/type-traits.cpp
index 2c35d5ee19a4c6..23c339ebdf0826 100644
--- a/clang/test/SemaCXX/type-traits.cpp
+++ b/clang/test/SemaCXX/type-traits.cpp
@@ -1768,8 +1768,8 @@ void is_layout_compatible(int n)
   static_assert(!__is_layout_compatible(CppStructNonStandardBySameBase, 
CppStructNonStandardBySameBase2), "");
   static_assert(!__is_layout_compatible(CppStructNonStandardBy2ndVirtBase, 
CppStructNonStandardBy2ndVirtBase2), "");
   static_assert(__is_layout_compatible(CStruct, CStructWithQualifiers), "");
-  static_assert(__is_layout_compatible(CStruc

[clang] [clang] Implement CWG2759 "`[[no_unique_address]` and common initial sequence" (PR #82607)

[via cfe-commits]

cor3ntin wrote:

> No special handling of [[msvc::no_unique_address]] is performed, so it should 
> follow [[no_unique_address]] behavior.

I do not think the code does that.
And we should test what it does.

At the very least, a type with msvc::no_unique_address should not be layout 
compatible with an equivalent declaration using no_unique_address.

Whether two msvc::no_unique_address are layout compatible is less important, 
because the intent of msvc::no_unique_address is not documented and/or msvc 
does not implement CWG2759

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

[clang] [clang-tools-extra] [flang] [lld] [llvm] [flang][clang] Add Visibility specific help text for options (PR #81869)

[David Spickett via cfe-commits]

https://github.com/DavidSpickett updated 
https://github.com/llvm/llvm-project/pull/81869

>From 72bbd9d38cb6e292d92391fcf04154cfbc336192 Mon Sep 17 00:00:00 2001
From: David Spickett 
Date: Thu, 15 Feb 2024 09:52:22 +
Subject: [PATCH 1/3] [flang][clang] Add Visibility specific help text for
 options

And use it to print the correct default OpenMP version for flang.

This change adds an optional HelpTextForVisibility to options.
This allows you to change the help text (shown in documentation
and --help) for one specific visibility.

It could be generalised to a list, but we only need to pick out
flang right now so I've kept it simple but not so simple that it's
"if flang else".

For example the OpenMP option will show one default value for
Clang and another for Flang. Clang will use the existing HelpText
string.

I have not applied this to group descriptions just because
I don't know of one that needs changing. It could easily be
enabled for those too if needed. There are minor changes to them
just to get it all to compile.

This approach of storing many help strings per option in the 1
driver library seemed perferrable to making a whole new library
for Flang (even if that would mostly be including stuff from Clang).
---
 clang/include/clang/Driver/Options.td |  5 ++-
 clang/lib/Frontend/CompilerInvocation.cpp | 16 
 .../utils/TableGen/ClangOptionDocEmitter.cpp  | 21 +-
 flang/test/Driver/driver-help-hidden.f90  |  2 +-
 flang/test/Driver/driver-help.f90 |  2 +-
 lld/MachO/DriverUtils.cpp | 20 ++---
 lld/MinGW/Driver.cpp  | 20 ++---
 lld/wasm/Driver.cpp   | 20 ++---
 llvm/include/llvm/Option/OptParser.td | 10 +
 llvm/include/llvm/Option/OptTable.h   | 41 +--
 llvm/lib/Option/OptTable.cpp  | 14 ---
 .../Option/OptionMarshallingTest.cpp  |  6 +--
 llvm/utils/TableGen/OptParserEmitter.cpp  | 16 
 13 files changed, 143 insertions(+), 50 deletions(-)

diff --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 3a028fadb25b18..765d5fbc1e692d 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -3385,7 +3385,10 @@ def fno_openmp : Flag<["-"], "fno-openmp">, 
Group,
 def fopenmp_version_EQ : Joined<["-"], "fopenmp-version=">, Group,
   Flags<[NoArgumentUnused]>,
   Visibility<[ClangOption, CC1Option, FlangOption, FC1Option]>,
-  HelpText<"Set OpenMP version (e.g. 45 for OpenMP 4.5, 51 for OpenMP 5.1). 
Default value is 51 for Clang">;
+  HelpText<"Set OpenMP version (e.g. 45 for OpenMP 4.5, 51 for OpenMP 5.1). 
Default value is 51 for Clang">,
+  HelpForVisibility>;
 defm openmp_extensions: BoolFOption<"openmp-extensions",
   LangOpts<"OpenMPExtensions">, DefaultTrue,
   PosFlag(R->getValueInit("HelpTextForVisibility"))) {
+const Record *VisibilityHelp = R->getValueAsDef("HelpTextForVisibility");
+std::string VisibilityStr =
+VisibilityHelp->getValue("Visibility")->getValue()->getAsString();
+
+for (StringRef Mask : DocInfo->getValueAsListOfStrings("VisibilityMask")) {
+  if (VisibilityStr == Mask) {
+Description = escapeRST(VisibilityHelp->getValueAsString("Text"));
+break;
+  }
+}
+  }
+
+  // If there's not a program specific string, use the default one.
+  if (Description.empty())
+Description = getRSTStringWithTextFallback(R, "DocBrief", "HelpText");
 
   if (!isa(R->getValueInit("Values"))) {
 if (!Description.empty() && Description.back() != '.')
diff --git a/flang/test/Driver/driver-help-hidden.f90 
b/flang/test/Driver/driver-help-hidden.f90
index 44dbac44772b29..94f2f4d1f522ec 100644
--- a/flang/test/Driver/driver-help-hidden.f90
+++ b/flang/test/Driver/driver-help-hidden.f90
@@ -83,7 +83,7 @@
 ! CHECK-NEXT: -fopenmp-targets=
 ! CHECK-NEXT: Specify comma-separated list of triples 
OpenMP offloading targets to be supported
 ! CHECK-NEXT: -fopenmp-version=
-! CHECK-NEXT: Set OpenMP version (e.g. 45 for OpenMP 
4.5, 51 for OpenMP 5.1). Default value is 51 for Clang
+! CHECK-NEXT: Set OpenMP version (e.g. 45 for OpenMP 
4.5, 51 for OpenMP 5.1). Default value is 11 for Flang
 ! CHECK-NEXT: -fopenmpParse OpenMP pragmas and generate 
parallel code.
 ! CHECK-NEXT: -foptimization-record-file=
 ! CHECK-NEXT: Specify the output name of the file 
containing the optimization remarks. Implies -fsave-optimization-record. On 
Darwin platforms, this cannot be used with multiple -arch  options.
diff --git a/flang/test/Driver/driver-help.f90 
b/flang/test/Driver/driver-help.f90
index b4280a454e3128..31bc67e1742482 100644
--- a/flang/test/Driver/driver-help.f90
+++ b/flang/test/Driver/driver-help.f90
@@ -69,7 +69,7 @@
 ! HELP-NEXT: -fopenmp-targets=
 ! HELP-NEXT:   

[clang] [Clang] Fixes to immediate-escalating functions (PR #82281)

[Balazs Benics via cfe-commits]

steakhal wrote:

I've submitted a PR #82609 to backport this commit to release/18.x as it fixes 
a crash and would be also important for us downstream.

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

[clang] [clang][analyzer] Fix argument invalidations in StreamChecker. (PR #79470)

[Alejandro Álvarez Ayllón via cfe-commits]

@@ -763,6 +779,11 @@ void StreamChecker::evalFreadFwrite(const FnDescription 
*Desc,
 return;
   }
 
+  // At read, invalidate the buffer in any case of error or success,
+  // except if EOF was already present.
+  if (IsFread && (OldSS->ErrorState != ErrorFEof))
+State = escapeArgs(State, C, Call, {0});

alejandro-alvarez-sonarsource wrote:

It turns out I was comparing with our downstream copy of v17, where 
`UpdateBufferRegionForFread` is defined.
So it can be done for the case of arrays. I have double-checked with the 
original author and he agrees it can be upstreamed. Let me uplift the patch and 
then I will share it with you.

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

[clang] [clang] Implement CWG2759 "`[[no_unique_address]` and common initial sequence" (PR #82607)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll updated 
https://github.com/llvm/llvm-project/pull/82607

>From 22facf44ec3f97fcdc40f2431ec26ca7ef441c67 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Thu, 22 Feb 2024 13:28:04 +0300
Subject: [PATCH 1/2] [clang] Implement CWG2759 "`[[no_unique_address]` and
 common initial sequence"

This patch implements said defect report resolution by adding additional check 
to common initial sequence evaluation. Consequently, this fixes CWG2759.

No special handling of `[[msvc::no_unique_address]]` is performed, so it should 
follow `[[no_unique_address]]` behavior.
---
 clang/docs/ReleaseNotes.rst|  6 ++-
 clang/lib/Sema/SemaChecking.cpp|  5 ++
 clang/test/CXX/drs/dr27xx.cpp  | 83 ++
 clang/test/SemaCXX/type-traits.cpp | 10 ++--
 clang/www/cxx_dr_status.html   |  2 +-
 5 files changed, 98 insertions(+), 8 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index bac166e6c35627..a7c0f2fbbe7604 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -83,8 +83,6 @@ C++20 Feature Support
 
 - Implemented the `__is_layout_compatible` intrinsic to support
   `P0466R5: Layout-compatibility and Pointer-interconvertibility Traits 
`_.
-  Note: `CWG2759: [[no_unique_address] and common initial sequence 
`_
-  is not yet implemented.
 
 C++23 Feature Support
 ^
@@ -108,6 +106,10 @@ Resolutions to C++ Defect Reports
   of two types.
   (`CWG1719: Layout compatibility and cv-qualification revisited 
`_).
 
+- ``[[no_unique_address]]`` is now respected when evaluating layout
+  compatibility of two types.
+  (`CWG2759: [[no_unique_address] and common initial sequence  
`_).
+
 C Language Changes
 --
 
diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index e8bfb215a5b4c5..aba8852f6cfca4 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -19033,6 +19033,11 @@ static bool isLayoutCompatible(ASTContext &C, 
FieldDecl *Field1,
   return false;
   }
 
+  if (Field1->hasAttr() ||
+  Field2->hasAttr()) {
+return false;
+  }
+
   return true;
 }
 
diff --git a/clang/test/CXX/drs/dr27xx.cpp b/clang/test/CXX/drs/dr27xx.cpp
index dd3fd5a20163fa..3fdf384bef27a7 100644
--- a/clang/test/CXX/drs/dr27xx.cpp
+++ b/clang/test/CXX/drs/dr27xx.cpp
@@ -10,6 +10,89 @@
 // expected-no-diagnostics
 #endif
 
+namespace dr2759 { // dr2759: 19
+#if __cplusplus >= 201103L
+
+struct CStruct {
+  int one;
+  int two;
+};
+
+struct CEmptyStruct {};
+struct CEmptyStruct2 {};
+
+struct CStructNoUniqueAddress {
+  int one;
+  [[no_unique_address]] int two;
+};
+
+struct CStructNoUniqueAddress2 {
+  int one;
+  [[no_unique_address]] int two;
+};
+
+union UnionLayout {
+  int a;
+  double b;
+  CStruct c;
+  [[no_unique_address]] CEmptyStruct d;
+  [[no_unique_address]] CEmptyStruct2 e;
+};
+
+union UnionLayout2 {
+  CStruct c;
+  int a;
+  CEmptyStruct2 e;
+  double b;
+  [[no_unique_address]] CEmptyStruct d;
+};
+
+union UnionLayout3 {
+  CStruct c;
+  int a;
+  double b;
+  [[no_unique_address]] CEmptyStruct d;
+};
+
+struct StructWithAnonUnion {
+  union {
+int a;
+double b;
+CStruct c;
+[[no_unique_address]] CEmptyStruct d;
+[[no_unique_address]] CEmptyStruct2 e;
+  };
+};
+
+struct StructWithAnonUnion2 {
+  union {
+CStruct c;
+int a;
+CEmptyStruct2 e;
+double b;
+[[no_unique_address]] CEmptyStruct d;
+  };
+};
+
+struct StructWithAnonUnion3 {
+  union {
+CStruct c;
+int a;
+CEmptyStruct2 e;
+double b;
+[[no_unique_address]] CEmptyStruct d;
+  } u;
+};
+
+static_assert(__is_layout_compatible(CStruct, CStructNoUniqueAddress) != 
bool(__has_cpp_attribute(no_unique_address)), "");
+static_assert(__is_layout_compatible(CStructNoUniqueAddress, 
CStructNoUniqueAddress2) != bool(__has_cpp_attribute(no_unique_address)), "");
+static_assert(!__is_layout_compatible(UnionLayout, UnionLayout2), "");
+static_assert(!__is_layout_compatible(UnionLayout, UnionLayout3), "");
+static_assert(!__is_layout_compatible(StructWithAnonUnion, 
StructWithAnonUnion2), "");
+static_assert(!__is_layout_compatible(StructWithAnonUnion, 
StructWithAnonUnion3), "");
+#endif
+} // namespace dr2759
+
 namespace dr2789 { // dr2789: 18
 #if __cplusplus >= 202302L
 template 
diff --git a/clang/test/SemaCXX/type-traits.cpp 
b/clang/test/SemaCXX/type-traits.cpp
index 2c35d5ee19a4c6..23c339ebdf0826 100644
--- a/clang/test/SemaCXX/type-traits.cpp
+++ b/clang/test/SemaCXX/type-traits.cpp
@@ -1768,8 +1768,8 @@ void is_layout_compatible(int n)
   static_assert(!__is_layout_compatible(CppStructNonStandardBySameBase, 
CppStructNonStandardBySameBase2), "");
   static_assert(!__is_layout_compatible(CppStructNonStandardBy2ndVirtB

[clang] [OpenMP][Clang] Enable inscan modifier for generic datatypes (PR #82220)

[Animesh Kumar via cfe-commits]

https://github.com/animeshk-amd updated 
https://github.com/llvm/llvm-project/pull/82220

>From ccf9823e7349435af2311a1ea15b4457ecb65107 Mon Sep 17 00:00:00 2001
From: Animesh Kumar 
Date: Mon, 19 Feb 2024 00:28:39 -0600
Subject: [PATCH] [OpenMP][Clang] Enable inscan modifier for generic datatypes

This patch fixes the #67002 ([OpenMP][Clang] Scan Directive not
supported for Generic types). It disables the Sema checks/analysis
that are run on the helper arrays which go into the implementation
of the `omp scan` directive until the template instantiation
happens.
---
 clang/lib/Sema/SemaOpenMP.cpp|  3 ++-
 clang/test/OpenMP/scan_ast_print.cpp | 18 ++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/clang/lib/Sema/SemaOpenMP.cpp b/clang/lib/Sema/SemaOpenMP.cpp
index 7f75cfc5b54f35..f4364a259ad57f 100644
--- a/clang/lib/Sema/SemaOpenMP.cpp
+++ b/clang/lib/Sema/SemaOpenMP.cpp
@@ -4962,7 +4962,8 @@ StmtResult Sema::ActOnOpenMPRegionEnd(StmtResult S,
   if (RC->getModifier() != OMPC_REDUCTION_inscan)
 continue;
   for (Expr *E : RC->copy_array_temps())
-MarkDeclarationsReferencedInExpr(E);
+if (E)
+  MarkDeclarationsReferencedInExpr(E);
 }
 if (auto *AC = dyn_cast(C)) {
   for (Expr *E : AC->varlists())
diff --git a/clang/test/OpenMP/scan_ast_print.cpp 
b/clang/test/OpenMP/scan_ast_print.cpp
index 3bbd3b60c3e8c4..82cb13eb6e70f7 100644
--- a/clang/test/OpenMP/scan_ast_print.cpp
+++ b/clang/test/OpenMP/scan_ast_print.cpp
@@ -17,6 +17,10 @@ T tmain(T argc) {
   static T a;
 #pragma omp for reduction(inscan, +: a)
   for (int i = 0; i < 10; ++i) {
+#pragma omp scan inclusive(a)
+  }
+#pragma omp parallel for reduction(inscan, +:a)
+  for (int i = 0; i < 10; ++i) {
 #pragma omp scan inclusive(a)
   }
   return a + argc;
@@ -25,15 +29,29 @@ T tmain(T argc) {
 // CHECK-NEXT: #pragma omp for reduction(inscan, +: a)
 // CHECK-NEXT: for (int i = 0; i < 10; ++i) {
 // CHECK-NEXT: #pragma omp scan inclusive(a){{$}}
+
+// CHECK: #pragma omp parallel for reduction(inscan, +: a)
+// CHECK-NEXT: for (int i = 0; i < 10; ++i) {
+// CHECK-NEXT: #pragma omp scan inclusive(a){{$}}
+
 // CHECK:  static int a;
 // CHECK-NEXT: #pragma omp for reduction(inscan, +: a)
 // CHECK-NEXT: for (int i = 0; i < 10; ++i) {
 // CHECK-NEXT: #pragma omp scan inclusive(a)
+
+// CHECK: #pragma omp parallel for reduction(inscan, +: a)
+// CHECK-NEXT: for (int i = 0; i < 10; ++i) {
+// CHECK-NEXT: #pragma omp scan inclusive(a)
+
 // CHECK:  static char a;
 // CHECK-NEXT: #pragma omp for reduction(inscan, +: a)
 // CHECK-NEXT: for (int i = 0; i < 10; ++i) {
 // CHECK-NEXT: #pragma omp scan inclusive(a)
 
+// CHECK: #pragma omp parallel for reduction(inscan, +: a)
+// CHECK-NEXT: for (int i = 0; i < 10; ++i) {
+// CHECK-NEXT: #pragma omp scan inclusive(a)
+
 int main(int argc, char **argv) {
   static int a;
 // CHECK: static int a;

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

[clang] [clang] Implement CWG2759 "`[[no_unique_address]` and common initial sequence" (PR #82607)

[Vlad Serebrennikov via cfe-commits]

https://github.com/Endilll updated 
https://github.com/llvm/llvm-project/pull/82607

>From 22facf44ec3f97fcdc40f2431ec26ca7ef441c67 Mon Sep 17 00:00:00 2001
From: Vlad Serebrennikov 
Date: Thu, 22 Feb 2024 13:28:04 +0300
Subject: [PATCH 1/3] [clang] Implement CWG2759 "`[[no_unique_address]` and
 common initial sequence"

This patch implements said defect report resolution by adding additional check 
to common initial sequence evaluation. Consequently, this fixes CWG2759.

No special handling of `[[msvc::no_unique_address]]` is performed, so it should 
follow `[[no_unique_address]]` behavior.
---
 clang/docs/ReleaseNotes.rst|  6 ++-
 clang/lib/Sema/SemaChecking.cpp|  5 ++
 clang/test/CXX/drs/dr27xx.cpp  | 83 ++
 clang/test/SemaCXX/type-traits.cpp | 10 ++--
 clang/www/cxx_dr_status.html   |  2 +-
 5 files changed, 98 insertions(+), 8 deletions(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index bac166e6c35627..a7c0f2fbbe7604 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -83,8 +83,6 @@ C++20 Feature Support
 
 - Implemented the `__is_layout_compatible` intrinsic to support
   `P0466R5: Layout-compatibility and Pointer-interconvertibility Traits 
`_.
-  Note: `CWG2759: [[no_unique_address] and common initial sequence 
`_
-  is not yet implemented.
 
 C++23 Feature Support
 ^
@@ -108,6 +106,10 @@ Resolutions to C++ Defect Reports
   of two types.
   (`CWG1719: Layout compatibility and cv-qualification revisited 
`_).
 
+- ``[[no_unique_address]]`` is now respected when evaluating layout
+  compatibility of two types.
+  (`CWG2759: [[no_unique_address] and common initial sequence  
`_).
+
 C Language Changes
 --
 
diff --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index e8bfb215a5b4c5..aba8852f6cfca4 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -19033,6 +19033,11 @@ static bool isLayoutCompatible(ASTContext &C, 
FieldDecl *Field1,
   return false;
   }
 
+  if (Field1->hasAttr() ||
+  Field2->hasAttr()) {
+return false;
+  }
+
   return true;
 }
 
diff --git a/clang/test/CXX/drs/dr27xx.cpp b/clang/test/CXX/drs/dr27xx.cpp
index dd3fd5a20163fa..3fdf384bef27a7 100644
--- a/clang/test/CXX/drs/dr27xx.cpp
+++ b/clang/test/CXX/drs/dr27xx.cpp
@@ -10,6 +10,89 @@
 // expected-no-diagnostics
 #endif
 
+namespace dr2759 { // dr2759: 19
+#if __cplusplus >= 201103L
+
+struct CStruct {
+  int one;
+  int two;
+};
+
+struct CEmptyStruct {};
+struct CEmptyStruct2 {};
+
+struct CStructNoUniqueAddress {
+  int one;
+  [[no_unique_address]] int two;
+};
+
+struct CStructNoUniqueAddress2 {
+  int one;
+  [[no_unique_address]] int two;
+};
+
+union UnionLayout {
+  int a;
+  double b;
+  CStruct c;
+  [[no_unique_address]] CEmptyStruct d;
+  [[no_unique_address]] CEmptyStruct2 e;
+};
+
+union UnionLayout2 {
+  CStruct c;
+  int a;
+  CEmptyStruct2 e;
+  double b;
+  [[no_unique_address]] CEmptyStruct d;
+};
+
+union UnionLayout3 {
+  CStruct c;
+  int a;
+  double b;
+  [[no_unique_address]] CEmptyStruct d;
+};
+
+struct StructWithAnonUnion {
+  union {
+int a;
+double b;
+CStruct c;
+[[no_unique_address]] CEmptyStruct d;
+[[no_unique_address]] CEmptyStruct2 e;
+  };
+};
+
+struct StructWithAnonUnion2 {
+  union {
+CStruct c;
+int a;
+CEmptyStruct2 e;
+double b;
+[[no_unique_address]] CEmptyStruct d;
+  };
+};
+
+struct StructWithAnonUnion3 {
+  union {
+CStruct c;
+int a;
+CEmptyStruct2 e;
+double b;
+[[no_unique_address]] CEmptyStruct d;
+  } u;
+};
+
+static_assert(__is_layout_compatible(CStruct, CStructNoUniqueAddress) != 
bool(__has_cpp_attribute(no_unique_address)), "");
+static_assert(__is_layout_compatible(CStructNoUniqueAddress, 
CStructNoUniqueAddress2) != bool(__has_cpp_attribute(no_unique_address)), "");
+static_assert(!__is_layout_compatible(UnionLayout, UnionLayout2), "");
+static_assert(!__is_layout_compatible(UnionLayout, UnionLayout3), "");
+static_assert(!__is_layout_compatible(StructWithAnonUnion, 
StructWithAnonUnion2), "");
+static_assert(!__is_layout_compatible(StructWithAnonUnion, 
StructWithAnonUnion3), "");
+#endif
+} // namespace dr2759
+
 namespace dr2789 { // dr2789: 18
 #if __cplusplus >= 202302L
 template 
diff --git a/clang/test/SemaCXX/type-traits.cpp 
b/clang/test/SemaCXX/type-traits.cpp
index 2c35d5ee19a4c6..23c339ebdf0826 100644
--- a/clang/test/SemaCXX/type-traits.cpp
+++ b/clang/test/SemaCXX/type-traits.cpp
@@ -1768,8 +1768,8 @@ void is_layout_compatible(int n)
   static_assert(!__is_layout_compatible(CppStructNonStandardBySameBase, 
CppStructNonStandardBySameBase2), "");
   static_assert(!__is_layout_compatible(CppStructNonStandardBy2ndVirtB

[clang] [llvm] [LV][LAA] Vectorize math lib calls with mem write-only attribute (PR #78432)

[Paschalis Mpeis via cfe-commits]

paschalis-mpeis wrote:

Rebased to main after a couple of weeks of inactivity.

Note: windows x64 build failure seems unrelated; more likely a wide problem, 
failing at cmake configure.

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

[clang] [clang] Implement CWG2759 "`[[no_unique_address]` and common initial sequence" (PR #82607)

[via cfe-commits]

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

LGTM, Thanks!

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

[clang] [clang][nullability] Don't discard expression state before end of full-expression. (PR #82611)

[via cfe-commits]

https://github.com/martinboehme created 
https://github.com/llvm/llvm-project/pull/82611

In https://github.com/llvm/llvm-project/pull/72985, I made a change to discard
expression state (`ExprToLoc` and `ExprToVal`) at the beginning of each basic
block. I did so with the claim that "we never need to access entries from these
maps outside of the current basic block", noting that there are exceptions to
this claim when control flow happens inside a full-expression (the operands of
`&&`, `||`, and the conditional operator live in different basic blocks than the
operator itself) but that we already have a mechanism for retrieving the values
of these operands from the environment for the block they are computed in.

It turns out, however, that the operands of these operators aren't the only
expressions whose values can be accessed from a different basic block; when
control flow happens within a full-expression, that control flow can be
"interposed" between an expression and its parent. Here is an example:

```cxx
void f(int*, int);
bool cond();

void target() {
  int i = 0;
  f(&i, cond() ? 1 : 0);
}
```

([godbolt](https://godbolt.org/z/hrbj1Mj3o))

In the CFG[^1] , note how the expression for `&i` is computed in block B4,
but the parent of this expression (the `CallExpr`) is located in block B1.
The the argument expression `&i` and the `CallExpr` are essentially "torn apart"
into different basic blocks by the conditional operator in the second argument.
In other words, the edge between the `CallExpr` and its argument `&i` straddles
the boundary between two blocks.

I used to think that this scenario -- where an edge between an expression and
one of its children straddles a block boundary -- could only happen between the
expression that triggers the control flow (`&&`, `||`, or the conditional
operator) and its children, but the example above shows that other expressions
can be affected as well; the control flow is still triggered by `&&`, `||` or
the conditional operator, but the expressions affected lie outside these
operators.

Discarding expression state too soon is harmful. For example, an analysis that
checks the arguments of the `CallExpr` above would not be able to retrieve a
value for the `&i` argument.

This patch therefore ensures that we don't discard expression state before the
end of a full-expression. In other cases -- when the evaluation of a
full-expression is complete -- we still want to discard expression state for the
reasons explained in https://github.com/llvm/llvm-project/pull/72985 (avoid
performing joins on boolean values that are no longer needed, which
unnecessarily extends the flow condition; improve debuggability by removing
clutter from the expression state).

[^1]:
```
 [B5 (ENTRY)]
   Succs (1): B4

 [B1]
   1: [B4.9] ? [B2.1] : [B3.1]
   2: [B4.4]([B4.6], [B1.1])
   Preds (2): B2 B3
   Succs (1): B0

 [B2]
   1: 1
   Preds (1): B4
   Succs (1): B1

 [B3]
   1: 0
   Preds (1): B4
   Succs (1): B1

 [B4]
   1: 0
   2: int i = 0;
   3: f
   4: [B4.3] (ImplicitCastExpr, FunctionToPointerDecay, void (*)(int *, int))
   5: i
   6: &[B4.5]
   7: cond
   8: [B4.7] (ImplicitCastExpr, FunctionToPointerDecay, _Bool (*)(void))
   9: [B4.8]()
   T: [B4.9] ? ... : ...
   Preds (1): B5
   Succs (2): B2 B3

 [B0 (EXIT)]
   Preds (1): B1
```

>From 109e72445fb8da4dd0cf08b5985986ca864a3536 Mon Sep 17 00:00:00 2001
From: Martin Braenne 
Date: Thu, 22 Feb 2024 11:23:30 +
Subject: [PATCH] [clang][nullability] Don't discard expression state before
 end of full-expression.

In https://github.com/llvm/llvm-project/pull/72985, I made a change to discard
expression state (`ExprToLoc` and `ExprToVal`) at the beginning of each basic
block. I did so with the claim that "we never need to access entries from these
maps outside of the current basic block", noting that there are exceptions to
this claim when control flow happens inside a full-expression (the operands of
`&&`, `||`, and the conditional operator live in different basic blocks than the
operator itself) but that we already have a mechanism for retrieving the values
of these operands from the environment for the block they are computed in.

It turns out, however, that the operands of these operators aren't the only
expressions whose values can be accessed from a different basic block; when
control flow happens within a full-expression, that control flow can be
"interposed" between an expression and its parent. Here is an example:

```cxx
void f(int*, int);
bool cond();

void target() {
  int i = 0;
  f(&i, cond() ? 1 : 0);
}
```

([godbolt](https://godbolt.org/z/hrbj1Mj3o))

In the CFG[^1] , note how the expression for `&i` is computed in block B4,
but the parent of this expression (the `CallExpr`) is located in block B1.
The the argument expression `&i` and the `CallExpr` are essentially "torn apart"
into different basic blocks by the conditional operator in the second argument.
In other words, the edge between the `CallExpr` and its argument

[clang] [clang][nullability] Don't discard expression state before end of full-expression. (PR #82611)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang-analysis

Author: None (martinboehme)


Changes

In https://github.com/llvm/llvm-project/pull/72985, I made a change to discard
expression state (`ExprToLoc` and `ExprToVal`) at the beginning of each basic
block. I did so with the claim that "we never need to access entries from these
maps outside of the current basic block", noting that there are exceptions to
this claim when control flow happens inside a full-expression (the operands of
`&&`, `||`, and the conditional operator live in different basic blocks 
than the
operator itself) but that we already have a mechanism for retrieving the values
of these operands from the environment for the block they are computed in.

It turns out, however, that the operands of these operators aren't the only
expressions whose values can be accessed from a different basic block; when
control flow happens within a full-expression, that control flow can be
"interposed" between an expression and its parent. Here is an example:

```cxx
void f(int*, int);
bool cond();

void target() {
  int i = 0;
  f(&i, cond() ? 1 : 0);
}
```

([godbolt](https://godbolt.org/z/hrbj1Mj3o))

In the CFG[^1] , note how the expression for `&i` is computed in block B4,
but the parent of this expression (the `CallExpr`) is located in block B1.
The the argument expression `&i` and the `CallExpr` are essentially "torn 
apart"
into different basic blocks by the conditional operator in the second argument.
In other words, the edge between the `CallExpr` and its argument `&i` 
straddles
the boundary between two blocks.

I used to think that this scenario -- where an edge between an expression and
one of its children straddles a block boundary -- could only happen between the
expression that triggers the control flow (`&&`, `||`, or the 
conditional
operator) and its children, but the example above shows that other expressions
can be affected as well; the control flow is still triggered by `&&`, 
`||` or
the conditional operator, but the expressions affected lie outside these
operators.

Discarding expression state too soon is harmful. For example, an analysis that
checks the arguments of the `CallExpr` above would not be able to retrieve a
value for the `&i` argument.

This patch therefore ensures that we don't discard expression state before the
end of a full-expression. In other cases -- when the evaluation of a
full-expression is complete -- we still want to discard expression state for the
reasons explained in https://github.com/llvm/llvm-project/pull/72985 (avoid
performing joins on boolean values that are no longer needed, which
unnecessarily extends the flow condition; improve debuggability by removing
clutter from the expression state).

[^1]:
```
 [B5 (ENTRY)]
   Succs (1): B4

 [B1]
   1: [B4.9] ? [B2.1] : [B3.1]
   2: [B4.4]([B4.6], [B1.1])
   Preds (2): B2 B3
   Succs (1): B0

 [B2]
   1: 1
   Preds (1): B4
   Succs (1): B1

 [B3]
   1: 0
   Preds (1): B4
   Succs (1): B1

 [B4]
   1: 0
   2: int i = 0;
   3: f
   4: [B4.3] (ImplicitCastExpr, FunctionToPointerDecay, void (*)(int *, int))
   5: i
   6: &[B4.5]
   7: cond
   8: [B4.7] (ImplicitCastExpr, FunctionToPointerDecay, _Bool (*)(void))
   9: [B4.8]()
   T: [B4.9] ? ... : ...
   Preds (1): B5
   Succs (2): B2 B3

 [B0 (EXIT)]
   Preds (1): B1
```

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


7 Files Affected:

- (modified) clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h 
(+21-4) 
- (modified) clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h 
(+10-1) 
- (modified) clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp (+35-1) 
- (modified) clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp (+24-4) 
- (modified) clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp 
(+25-7) 
- (modified) clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp 
(+2-1) 
- (modified) 
clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp 
(+70-34) 


``diff
diff --git a/clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h 
b/clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
index 405e93287a05d3..9a0a00f3c01343 100644
--- a/clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
+++ b/clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
@@ -58,19 +58,36 @@ class ControlFlowContext {
 return BlockReachable[B.getBlockID()];
   }
 
+  /// Returns whether `B` contains an expression that is consumed in a
+  /// different block than `B` (i.e. the parent of the expression is in a
+  /// different block).
+  /// This happens if there is control flow within a full-expression (triggered
+  /// by `&&`, `||`, or the conditional operator). Note that the operands of
+  /// these operators are not the only expressions that can be consumed in a
+  /// different block. For example, in the function call
+  /// `f(&i, cond() ? 1 : 0)`, `&i` is in a different block than t

[clang] [clang][nullability] Don't discard expression state before end of full-expression. (PR #82611)

[via cfe-commits]

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: None (martinboehme)


Changes

In https://github.com/llvm/llvm-project/pull/72985, I made a change to discard
expression state (`ExprToLoc` and `ExprToVal`) at the beginning of each basic
block. I did so with the claim that "we never need to access entries from these
maps outside of the current basic block", noting that there are exceptions to
this claim when control flow happens inside a full-expression (the operands of
`&&`, `||`, and the conditional operator live in different basic blocks 
than the
operator itself) but that we already have a mechanism for retrieving the values
of these operands from the environment for the block they are computed in.

It turns out, however, that the operands of these operators aren't the only
expressions whose values can be accessed from a different basic block; when
control flow happens within a full-expression, that control flow can be
"interposed" between an expression and its parent. Here is an example:

```cxx
void f(int*, int);
bool cond();

void target() {
  int i = 0;
  f(&i, cond() ? 1 : 0);
}
```

([godbolt](https://godbolt.org/z/hrbj1Mj3o))

In the CFG[^1] , note how the expression for `&i` is computed in block B4,
but the parent of this expression (the `CallExpr`) is located in block B1.
The the argument expression `&i` and the `CallExpr` are essentially "torn 
apart"
into different basic blocks by the conditional operator in the second argument.
In other words, the edge between the `CallExpr` and its argument `&i` 
straddles
the boundary between two blocks.

I used to think that this scenario -- where an edge between an expression and
one of its children straddles a block boundary -- could only happen between the
expression that triggers the control flow (`&&`, `||`, or the 
conditional
operator) and its children, but the example above shows that other expressions
can be affected as well; the control flow is still triggered by `&&`, 
`||` or
the conditional operator, but the expressions affected lie outside these
operators.

Discarding expression state too soon is harmful. For example, an analysis that
checks the arguments of the `CallExpr` above would not be able to retrieve a
value for the `&i` argument.

This patch therefore ensures that we don't discard expression state before the
end of a full-expression. In other cases -- when the evaluation of a
full-expression is complete -- we still want to discard expression state for the
reasons explained in https://github.com/llvm/llvm-project/pull/72985 (avoid
performing joins on boolean values that are no longer needed, which
unnecessarily extends the flow condition; improve debuggability by removing
clutter from the expression state).

[^1]:
```
 [B5 (ENTRY)]
   Succs (1): B4

 [B1]
   1: [B4.9] ? [B2.1] : [B3.1]
   2: [B4.4]([B4.6], [B1.1])
   Preds (2): B2 B3
   Succs (1): B0

 [B2]
   1: 1
   Preds (1): B4
   Succs (1): B1

 [B3]
   1: 0
   Preds (1): B4
   Succs (1): B1

 [B4]
   1: 0
   2: int i = 0;
   3: f
   4: [B4.3] (ImplicitCastExpr, FunctionToPointerDecay, void (*)(int *, int))
   5: i
   6: &[B4.5]
   7: cond
   8: [B4.7] (ImplicitCastExpr, FunctionToPointerDecay, _Bool (*)(void))
   9: [B4.8]()
   T: [B4.9] ? ... : ...
   Preds (1): B5
   Succs (2): B2 B3

 [B0 (EXIT)]
   Preds (1): B1
```

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


7 Files Affected:

- (modified) clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h 
(+21-4) 
- (modified) clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h 
(+10-1) 
- (modified) clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp (+35-1) 
- (modified) clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp (+24-4) 
- (modified) clang/lib/Analysis/FlowSensitive/TypeErasedDataflowAnalysis.cpp 
(+25-7) 
- (modified) clang/unittests/Analysis/FlowSensitive/DataflowEnvironmentTest.cpp 
(+2-1) 
- (modified) 
clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp 
(+70-34) 


``diff
diff --git a/clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h 
b/clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
index 405e93287a05d3..9a0a00f3c01343 100644
--- a/clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
+++ b/clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
@@ -58,19 +58,36 @@ class ControlFlowContext {
 return BlockReachable[B.getBlockID()];
   }
 
+  /// Returns whether `B` contains an expression that is consumed in a
+  /// different block than `B` (i.e. the parent of the expression is in a
+  /// different block).
+  /// This happens if there is control flow within a full-expression (triggered
+  /// by `&&`, `||`, or the conditional operator). Note that the operands of
+  /// these operators are not the only expressions that can be consumed in a
+  /// different block. For example, in the function call
+  /// `f(&i, cond() ? 1 : 0)`, `&i` is in a different block than the 
`Call

[clang] fix: constexpr bit_cast with empty base classes (PR #82383)

[Timm Baeder via cfe-commits]

tbaederr wrote:

> This will need a release note. I'm curious why the removed code was there in 
> the first place. Any idea @tbaederr ?

No idea, it's been there since the original commit introducing 
`__builtin_bit_cast`. Maybe just an optimization, or maybe something else in 
that loop used to assert that the class isn't empty.

Aside from the release not, this LGTM.

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

[clang] [clang] Implement CWG2759 "`[[no_unique_address]` and common initial sequence" (PR #82607)

[Timm Baeder via cfe-commits]

@@ -19033,6 +19033,11 @@ static bool isLayoutCompatible(ASTContext &C, 
FieldDecl *Field1,
   return false;
   }
 
+  if (Field1->hasAttr() ||
+  Field2->hasAttr()) {
+return false;
+  }
+

tbaederr wrote:

```suggestion
  if (Field1->hasAttr() ||
  Field2->hasAttr()) 
return false;
```

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

[clang] Multilib support for libraries with exceptions (PR #75031)

[via cfe-commits]

https://github.com/pwprzybyla updated 
https://github.com/llvm/llvm-project/pull/75031

>From 78acc1685def3efa6e5af212f4edee7842de28a6 Mon Sep 17 00:00:00 2001
From: Piotr Przybyla 
Date: Wed, 29 Nov 2023 14:05:00 +
Subject: [PATCH] Multilib support for libraries with exceptions and rtti

---
 clang/include/clang/Driver/ToolChain.h | 10 ++
 clang/lib/Driver/ToolChain.cpp | 23 ++-
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/clang/include/clang/Driver/ToolChain.h 
b/clang/include/clang/Driver/ToolChain.h
index 2d0c1f826c1728..fbe2e8fe8e88d8 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -120,6 +120,11 @@ class ToolChain {
 RM_Disabled,
   };
 
+  enum ExceptionsMode {
+EM_Enabled,
+EM_Disabled,
+  };
+
   struct BitCodeLibraryInfo {
 std::string Path;
 bool ShouldInternalize;
@@ -141,6 +146,8 @@ class ToolChain {
 
   const RTTIMode CachedRTTIMode;
 
+  const ExceptionsMode CachedExceptionsMode;
+
   /// The list of toolchain specific path prefixes to search for libraries.
   path_list LibraryPaths;
 
@@ -318,6 +325,9 @@ class ToolChain {
   // Returns the RTTIMode for the toolchain with the current arguments.
   RTTIMode getRTTIMode() const { return CachedRTTIMode; }
 
+  // Returns the ExceptionsMode for the toolchain with the current arguments.
+  ExceptionsMode getExceptionsMode() const { return CachedExceptionsMode; }
+
   /// Return any implicit target and/or mode flag for an invocation of
   /// the compiler driver as `ProgName`.
   ///
diff --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 388030592b4836..f8c13c86daf9b0 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -77,10 +77,19 @@ static ToolChain::RTTIMode CalculateRTTIMode(const ArgList 
&Args,
   return NoRTTI ? ToolChain::RM_Disabled : ToolChain::RM_Enabled;
 }
 
+static ToolChain::ExceptionsMode CalculateExceptionsMode(const ArgList &Args) {
+  if (Args.hasFlag(options::OPT_fexceptions, options::OPT_fno_exceptions,
+   true)) {
+return ToolChain::EM_Enabled;
+  }
+  return ToolChain::EM_Disabled;
+}
+
 ToolChain::ToolChain(const Driver &D, const llvm::Triple &T,
  const ArgList &Args)
 : D(D), Triple(T), Args(Args), CachedRTTIArg(GetRTTIArgument(Args)),
-  CachedRTTIMode(CalculateRTTIMode(Args, Triple, CachedRTTIArg)) {
+  CachedRTTIMode(CalculateRTTIMode(Args, Triple, CachedRTTIArg)),
+  CachedExceptionsMode(CalculateExceptionsMode(Args)) {
   auto addIfExists = [this](path_list &List, const std::string &Path) {
 if (getVFS().exists(Path))
   List.push_back(Path);
@@ -264,6 +273,18 @@ ToolChain::getMultilibFlags(const llvm::opt::ArgList 
&Args) const {
 break;
   }
 
+  // Include fno-exceptions and fno-rtti
+  // to improve multilib selection
+  if (getRTTIMode() == ToolChain::RTTIMode::RM_Disabled)
+Result.push_back("-fno-rtti");
+  else
+Result.push_back("-frtti");
+
+  if (getExceptionsMode() == ToolChain::ExceptionsMode::EM_Disabled)
+Result.push_back("-fno-exceptions");
+  else
+Result.push_back("-fexceptions");
+
   // Sort and remove duplicates.
   std::sort(Result.begin(), Result.end());
   Result.erase(std::unique(Result.begin(), Result.end()), Result.end());

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

[clang] [llvm] [Clang][SME] Detect always_inline used with mismatched streaming attributes (PR #77936)

[Sander de Smalen via cfe-commits]

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

[clang] [llvm] [Clang][SME] Detect always_inline used with mismatched streaming attributes (PR #77936)

[Sander de Smalen via cfe-commits]

@@ -814,6 +820,43 @@ Address AArch64ABIInfo::EmitMSVAArg(CodeGenFunction &CGF, 
Address VAListAddr,
   /*allowHigherAlign*/ false);
 }
 
+static bool isStreaming(const FunctionDecl *F) {
+  if (F->hasAttr())
+return true;
+  if (const auto *T = F->getType()->getAs())
+return T->getAArch64SMEAttributes() & 
FunctionType::SME_PStateSMEnabledMask;
+  return false;
+}
+
+static bool isStreamingCompatible(const FunctionDecl *F) {
+  if (const auto *T = F->getType()->getAs())
+return T->getAArch64SMEAttributes() &
+   FunctionType::SME_PStateSMCompatibleMask;
+  return false;
+}

sdesmalen-arm wrote:

Yes it makes sense to create a single interface for these and remove any 
duplicates!

I think we'll want to have two interfaces:
* One for QualType for the type attributes (declared in AST/Type.h?)
* One for FunctionDecl that also checks the declaration attributes (declared in 
AST/Decl.h?)

I'm happy for it to be done as part of this patch or as a follow-up to keep 
this patch simpler.

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

[clang] [llvm] [Clang][SME] Detect always_inline used with mismatched streaming attributes (PR #77936)

[Sander de Smalen via cfe-commits]

https://github.com/sdesmalen-arm approved this pull request.


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

[clang] [Clang][Parser] Have the depth of the abbreviated generic lambdas inside a requires clause differ from the surrounding generic lambda (PR #80656)

[via cfe-commits]

@@ -1385,6 +1385,16 @@ ExprResult Parser::ParseLambdaExpressionAfterIntroducer(
   Diag(RAngleLoc,
diag::err_lambda_template_parameter_list_empty);
 } else {
+  // We increase the template depth before recursing into a 
requires-clause.
+  //
+  // This depth is used for setting up a LambdaScopeInfo (at

cor3ntin wrote:

```suggestion
  // This depth is used for setting up a LambdaScopeInfo (in
```

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

[clang] [Clang][Parser] Have the depth of the abbreviated generic lambdas inside a requires clause differ from the surrounding generic lambda (PR #80656)

[via cfe-commits]

@@ -193,6 +193,10 @@ Bug Fixes to C++ Support
 - Fixed an out-of-bounds error caused by building a recovery expression for 
ill-formed
   function calls while substituting into constraints.
   (`#58548 `_)
+- Fixed an issue where template parameters of the nested abbreviated generic 
lambda within

cor3ntin wrote:

```suggestion
- Fixed an issue where template parameters of a nested abbreviated generic 
lambda within
```

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

[clang] [Clang][Parser] Have the depth of the abbreviated generic lambdas inside a requires clause differ from the surrounding generic lambda (PR #80656)

[via cfe-commits]

@@ -1385,6 +1385,16 @@ ExprResult Parser::ParseLambdaExpressionAfterIntroducer(
   Diag(RAngleLoc,
diag::err_lambda_template_parameter_list_empty);
 } else {
+  // We increase the template depth before recursing into a 
requires-clause.
+  //
+  // This depth is used for setting up a LambdaScopeInfo (at
+  // Sema::RecordParsingTemplateParameterDepth), which participates in the
+  // invented template parameters later at InventTemplateParameter.
+  //
+  // This way, abbreviated generic lambdas could have different template
+  // depths, avoiding substitution into wrong template parameters during 
the

cor3ntin wrote:

```suggestion
  // depths, avoiding substitution into wrong template parameters during 
constraints
```

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

[clang] [Clang][Parser] Have the depth of the abbreviated generic lambdas inside a requires clause differ from the surrounding generic lambda (PR #80656)

[via cfe-commits]

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

[clang] [Clang][Parser] Have the depth of the abbreviated generic lambdas inside a requires clause differ from the surrounding generic lambda (PR #80656)

[via cfe-commits]

@@ -1385,6 +1385,16 @@ ExprResult Parser::ParseLambdaExpressionAfterIntroducer(
   Diag(RAngleLoc,
diag::err_lambda_template_parameter_list_empty);
 } else {
+  // We increase the template depth before recursing into a 
requires-clause.
+  //
+  // This depth is used for setting up a LambdaScopeInfo (at
+  // Sema::RecordParsingTemplateParameterDepth), which participates in the
+  // invented template parameters later at InventTemplateParameter.

cor3ntin wrote:

```suggestion
  // Sema::RecordParsingTemplateParameterDepth), which is used later when 
inventing 
  // template parameters in InventTemplateParameter.
```

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

[clang] [Clang][Parser] Have the depth of the abbreviated generic lambdas inside a requires clause differ from the surrounding generic lambda (PR #80656)

[via cfe-commits]

@@ -193,6 +193,10 @@ Bug Fixes to C++ Support
 - Fixed an out-of-bounds error caused by building a recovery expression for 
ill-formed
   function calls while substituting into constraints.
   (`#58548 `_)
+- Fixed an issue where template parameters of the nested abbreviated generic 
lambda within
+  a requires-clause lie at the same depth as those of the surrounding lambda. 
This,
+  in turn, results in the wrong template argument substitution during the 
constraint checking.

cor3ntin wrote:

```suggestion
  in turn, results in the wrong template argument substitution during 
constraint checking.
```

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

[clang] [Clang][Parser] Have the depth of the abbreviated generic lambdas inside a requires clause differ from the surrounding generic lambda (PR #80656)

[via cfe-commits]

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

I have some suggestion to improve the (very useful) comments.

Otherwise, LGTM

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

[clang] [Clang][Parser] Have the depth of the abbreviated generic lambdas inside a requires clause differ from the surrounding generic lambda (PR #80656)

[via cfe-commits]

@@ -1385,6 +1385,16 @@ ExprResult Parser::ParseLambdaExpressionAfterIntroducer(
   Diag(RAngleLoc,
diag::err_lambda_template_parameter_list_empty);
 } else {
+  // We increase the template depth before recursing into a 
requires-clause.
+  //
+  // This depth is used for setting up a LambdaScopeInfo (at
+  // Sema::RecordParsingTemplateParameterDepth), which participates in the
+  // invented template parameters later at InventTemplateParameter.
+  //
+  // This way, abbreviated generic lambdas could have different template
+  // depths, avoiding substitution into wrong template parameters during 
the

cor3ntin wrote:

```suggestion
  // depths, avoiding substitution into the wrong template parameters 
during the
```

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

[clang] [llvm] [LV][LAA] Vectorize math lib calls with mem write-only attribute (PR #78432)

[Nikita Popov via cfe-commits]

@@ -0,0 +1,52 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --filter "call.*(frexp|modf)" --version 4
+// RUN: %clang --target=aarch64-linux-gnu -march=armv8-a+sve -O3 -isystem 
%S/../Headers/Inputs/include -mllvm -vector-library=ArmPL -mllvm 
-force-vector-interleave=1 -mllvm 
-prefer-predicate-over-epilogue=predicate-dont-vectorize -emit-llvm -S -o - %s 
| FileCheck %s
+
+// REQUIRES: aarch64-registered-target
+
+/*
+Testing vectorization of math functions that have the attribute write-only to
+memory set. Given they have vectorized counterparts, they should be able to
+vectorize.
+*/
+
+// The following define is required to access some math functions.
+#define _GNU_SOURCE
+#include 
+
+// frexp/frexpf have no TLI mappings yet.
+
+// CHECK-LABEL: define dso_local void @frexp_f64(
+// CHECK-SAME: ptr nocapture noundef readonly [[IN:%.*]], ptr nocapture 
noundef writeonly [[OUT1:%.*]], ptr nocapture noundef writeonly [[OUT2:%.*]], 
i32 noundef [[N:%.*]]) local_unnamed_addr #[[ATTR0:[0-9]+]] {
+// CHECK:[[CALL:%.*]] = tail call double @frexp(double noundef 
[[TMP0:%.*]], ptr noundef [[ADD_PTR:%.*]]) #[[ATTR2:[0-9]+]]
+//
+void frexp_f64(double *in, double *out1, int *out2, int N) {
+  for (int i = 0; i < N; ++i)
+*out1 = frexp(in[i], out2+i);
+}
+
+// CHECK-LABEL: define dso_local void @frexp_f32(
+// CHECK-SAME: ptr nocapture noundef readonly [[IN:%.*]], ptr nocapture 
noundef writeonly [[OUT1:%.*]], ptr nocapture noundef writeonly [[OUT2:%.*]], 
i32 noundef [[N:%.*]]) local_unnamed_addr #[[ATTR0]] {
+// CHECK:[[CALL:%.*]] = tail call float @frexpf(float noundef 
[[TMP0:%.*]], ptr noundef [[ADD_PTR:%.*]]) #[[ATTR2]]
+//
+void frexp_f32(float *in, float *out1, int *out2, int N) {
+  for (int i = 0; i < N; ++i)
+*out1 = frexpf(in[i], out2+i);
+}
+
+// CHECK-LABEL: define dso_local void @modf_f64(
+// CHECK-SAME: ptr nocapture noundef readonly [[IN:%.*]], ptr nocapture 
noundef writeonly [[OUT1:%.*]], ptr nocapture noundef writeonly [[OUT2:%.*]], 
i32 noundef [[N:%.*]]) local_unnamed_addr #[[ATTR0]] {
+// CHECK:[[CALL:%.*]] = tail call double @modf(double noundef 
[[TMP0:%.*]], ptr noundef [[ADD_PTR:%.*]]) #[[ATTR3:[0-9]+]]
+//
+void modf_f64(double *in, double *out1, double *out2, int N) {
+  for (int i = 0; i < N; ++i)
+  out1[i] = modf(in[i], out2+i);
+}
+
+// CHECK-LABEL: define dso_local void @modf_f32(
+// CHECK-SAME: ptr nocapture noundef readonly [[IN:%.*]], ptr nocapture 
noundef writeonly [[OUT1:%.*]], ptr nocapture noundef writeonly [[OUT2:%.*]], 
i32 noundef [[N:%.*]]) local_unnamed_addr #[[ATTR0]] {
+// CHECK:[[CALL:%.*]] = tail call float @modff(float noundef [[TMP0:%.*]], 
ptr noundef [[ADD_PTR:%.*]]) #[[ATTR4:[0-9]+]]
+//
+void modf_f32(float *in, float *out1, float *out2, int N) {
+  for (int i = 0; i < N; ++i)
+  out1[i] = modff(in[i], out2+i);
+}

nikic wrote:

This test needs to be in either `llvm/test/Transforms/LoopVectorize` or 
`llvm/test/Analysis/LoopAccessAnalysis`, depending on what exactly you want to 
test.

I don't really get what this test is checking for though, it doesn't look like 
anything was actually vectorized?

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

[clang] [llvm] [Clang][SME] Detect always_inline used with mismatched streaming attributes (PR #77936)

[Dinar Temirbulatov via cfe-commits]

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


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