https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/78113
>From 36b085f21b76d7bf7c9965a86a09d1cef4fe9329 Mon Sep 17 00:00:00 2001
From: Florian Hahn
Date: Sun, 14 Jan 2024 14:13:08 +
Subject: [PATCH 1/9] [VPlan] Add new VPUniformPerUFRecipe, use for step
truncation.
@@ -491,17 +491,38 @@ void VPlanTransforms::removeDeadRecipes(VPlan &Plan) {
static VPValue *createScalarIVSteps(VPlan &Plan, const InductionDescriptor &ID,
ScalarEvolution &SE, Instruction *TruncI,
-Type
https://github.com/ayalz approved this pull request.
Looks good to me, thanks!
Adding a last minor nit.
https://github.com/llvm/llvm-project/pull/78113
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/lis
@@ -491,17 +491,39 @@ void VPlanTransforms::removeDeadRecipes(VPlan &Plan) {
static VPValue *createScalarIVSteps(VPlan &Plan, const InductionDescriptor &ID,
ScalarEvolution &SE, Instruction *TruncI,
-Type
https://github.com/ayalz edited https://github.com/llvm/llvm-project/pull/78113
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/78113
>From 36b085f21b76d7bf7c9965a86a09d1cef4fe9329 Mon Sep 17 00:00:00 2001
From: Florian Hahn
Date: Sun, 14 Jan 2024 14:13:08 +
Subject: [PATCH 1/9] [VPlan] Add new VPUniformPerUFRecipe, use for step
truncation.
Author: David Spickett
Date: 2024-01-26T10:36:22Z
New Revision: 11d76fdb0b9c500aace938427bba18602d15b17d
URL:
https://github.com/llvm/llvm-project/commit/11d76fdb0b9c500aace938427bba18602d15b17d
DIFF:
https://github.com/llvm/llvm-project/commit/11d76fdb0b9c500aace938427bba18602d15b17d.diff
LOG
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/78113
>From 36b085f21b76d7bf7c9965a86a09d1cef4fe9329 Mon Sep 17 00:00:00 2001
From: Florian Hahn
Date: Sun, 14 Jan 2024 14:13:08 +
Subject: [PATCH 01/10] [VPlan] Add new VPUniformPerUFRecipe, use for step
truncation.
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/73158
>From 13a26e8e7440c3b501730b22588af393a3e543cd Mon Sep 17 00:00:00 2001
From: Florian Hahn
Date: Thu, 6 Jul 2023 08:07:45 +0100
Subject: [PATCH 1/3] [VPlan] Implement cloning of VPlans.
This patch implements clonin
@@ -491,17 +491,39 @@ void VPlanTransforms::removeDeadRecipes(VPlan &Plan) {
static VPValue *createScalarIVSteps(VPlan &Plan, const InductionDescriptor &ID,
ScalarEvolution &SE, Instruction *TruncI,
-Type
steakhal wrote:
FYI this caused a crash in the Static Analyzer, tracked here: #79575
We will (well, probably I will) look into this to see what could be done about
it to workaround/fix the crash for clang-18.
https://github.com/llvm/llvm-project/pull/78041
__
https://github.com/fhahn closed https://github.com/llvm/llvm-project/pull/78113
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/fhahn updated https://github.com/llvm/llvm-project/pull/73158
>From 13a26e8e7440c3b501730b22588af393a3e543cd Mon Sep 17 00:00:00 2001
From: Florian Hahn
Date: Thu, 6 Jul 2023 08:07:45 +0100
Subject: [PATCH 1/4] [VPlan] Implement cloning of VPlans.
This patch implements clonin
@@ -982,6 +1037,92 @@ void VPlan::updateDominatorTree(DominatorTree *DT,
BasicBlock *LoopHeaderBB,
assert(DT->verify(DominatorTree::VerificationLevel::Fast));
}
+static void remapOperands(VPBlockBase *Entry, VPBlockBase *NewEntry,
+ DenseMap &Old2Ne
@@ -982,6 +1037,92 @@ void VPlan::updateDominatorTree(DominatorTree *DT,
BasicBlock *LoopHeaderBB,
assert(DT->verify(DominatorTree::VerificationLevel::Fast));
}
+static void remapOperands(VPBlockBase *Entry, VPBlockBase *NewEntry,
+ DenseMap &Old2Ne
@@ -982,6 +1037,92 @@ void VPlan::updateDominatorTree(DominatorTree *DT,
BasicBlock *LoopHeaderBB,
assert(DT->verify(DominatorTree::VerificationLevel::Fast));
}
+static void remapOperands(VPBlockBase *Entry, VPBlockBase *NewEntry,
fhahn wrote:
I left it as
@@ -982,6 +1037,92 @@ void VPlan::updateDominatorTree(DominatorTree *DT,
BasicBlock *LoopHeaderBB,
assert(DT->verify(DominatorTree::VerificationLevel::Fast));
}
+static void remapOperands(VPBlockBase *Entry, VPBlockBase *NewEntry,
+ DenseMap &Old2Ne
@@ -982,6 +1037,92 @@ void VPlan::updateDominatorTree(DominatorTree *DT,
BasicBlock *LoopHeaderBB,
assert(DT->verify(DominatorTree::VerificationLevel::Fast));
}
+static void remapOperands(VPBlockBase *Entry, VPBlockBase *NewEntry,
+ DenseMap &Old2Ne
@@ -614,6 +614,61 @@ void VPBasicBlock::print(raw_ostream &O, const Twine
&Indent,
printSuccessors(O, Indent);
}
#endif
+static void cloneCFG(VPBlockBase *Entry,
+ DenseMap &Old2NewVPBlocks);
+
+static VPBlockBase *cloneVPB(VPBlockBase *BB) {
Author: David Spickett
Date: 2024-01-26T11:37:50Z
New Revision: 5e9f0e37494ab42ff8d850527c5517f3006e63e9
URL:
https://github.com/llvm/llvm-project/commit/5e9f0e37494ab42ff8d850527c5517f3006e63e9
DIFF:
https://github.com/llvm/llvm-project/commit/5e9f0e37494ab42ff8d850527c5517f3006e63e9.diff
LOG
https://github.com/ayalz approved this pull request.
Looks good to me, ship it!
https://github.com/llvm/llvm-project/pull/73158
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: David Spickett
Date: 2024-01-26T12:21:42Z
New Revision: 28ee54c32e6b761e65fd2a7412776f6300ad922b
URL:
https://github.com/llvm/llvm-project/commit/28ee54c32e6b761e65fd2a7412776f6300ad922b
DIFF:
https://github.com/llvm/llvm-project/commit/28ee54c32e6b761e65fd2a7412776f6300ad922b.diff
LOG
Author: David Spickett
Date: 2024-01-26T14:06:49Z
New Revision: bb945fcd4a54c2c8f898e2bdc0d65fae841a1909
URL:
https://github.com/llvm/llvm-project/commit/bb945fcd4a54c2c8f898e2bdc0d65fae841a1909
DIFF:
https://github.com/llvm/llvm-project/commit/bb945fcd4a54c2c8f898e2bdc0d65fae841a1909.diff
LOG
erichkeane wrote:
@bolshakov-a : The original bug has a good amount of analysis to it, so if you
could see if there is a fix for it, else we probably do have to revert for that
one and miss 18 with this patch.
https://github.com/llvm/llvm-project/pull/78041
erichkeane wrote:
I see now that hte problem is probably in the Analyzer, so @steakhal is
probably the best person to be leading this, but any work you can do
@bolshakov-a would also likely be appreciated.
https://github.com/llvm/llvm-project/pull/78041
bolshakov-a wrote:
Prior to this PR, arrays in NTTP were represented as `Declaration`s and now as
`StructuralValue`s referring to their first element. @steakhal, please note
[here](https://github.com/llvm/llvm-project/pull/78041/files#diff-2f25fdb80b1a63f2e0a5a7c7a7c061b494b430ee8f5759b48022a86
MacDue wrote:
> It gets difficult to get this working for scalable at this level as we would
> have to introduce SVE or LLVM intrinsics to model the interleave in an
> scalable way.
There already are LLVM intrinsics for that, so I don't think it'd be hard to
extend to support SVE:
I wrote t
Fznamznon wrote:
> Oh gosh, I'm an idiot, i meant true
That makes it a little bit challenging to preserve old warnings for older
versions of the language, without additional flags and options, in some cases
like:
```
struct A {
~A();
};
struct B : A { };
struct C {
B a;
co
bgra8 wrote:
Heads up: we've stumbled upon this exact crash
(https://github.com/llvm/llvm-project/issues/79575) while testing clang inside
google too.
https://github.com/llvm/llvm-project/pull/78041
___
lldb-commits mailing list
lldb-commits@lists.ll
@@ -8129,29 +8067,133 @@
Sema::BuildExpressionFromIntegralTemplateArgument(const TemplateArgument &Arg,
else
Kind = CharacterLiteralKind::Ascii;
-E = new (Context) CharacterLiteral(Arg.getAsIntegral().getZExtValue(),
- Kind,
https://github.com/cor3ntin edited
https://github.com/llvm/llvm-project/pull/78041
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -8129,29 +8067,133 @@
Sema::BuildExpressionFromIntegralTemplateArgument(const TemplateArgument &Arg,
else
Kind = CharacterLiteralKind::Ascii;
-E = new (Context) CharacterLiteral(Arg.getAsIntegral().getZExtValue(),
- Kind,
@@ -8129,29 +8067,133 @@
Sema::BuildExpressionFromIntegralTemplateArgument(const TemplateArgument &Arg,
else
Kind = CharacterLiteralKind::Ascii;
-E = new (Context) CharacterLiteral(Arg.getAsIntegral().getZExtValue(),
- Kind,
@@ -0,0 +1,105 @@
+#include "Plugins/Platform/MacOSX/PlatformMacOSX.h"
+#include "Plugins/Platform/MacOSX/PlatformRemoteMacOSX.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/Progress.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/U
@@ -0,0 +1,105 @@
+#include "Plugins/Platform/MacOSX/PlatformMacOSX.h"
+#include "Plugins/Platform/MacOSX/PlatformRemoteMacOSX.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/Progress.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/U
@@ -0,0 +1,105 @@
+#include "Plugins/Platform/MacOSX/PlatformMacOSX.h"
+#include "Plugins/Platform/MacOSX/PlatformRemoteMacOSX.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/Progress.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/U
@@ -8129,29 +8067,133 @@
Sema::BuildExpressionFromIntegralTemplateArgument(const TemplateArgument &Arg,
else
Kind = CharacterLiteralKind::Ascii;
-E = new (Context) CharacterLiteral(Arg.getAsIntegral().getZExtValue(),
- Kind,
https://github.com/JDevlieghere approved this pull request.
https://github.com/llvm/llvm-project/pull/79508
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,65 @@
+# Tests for basic Debuginfod functionality
+
+Because the Debuginfod protocol is a simple HTTP path-based system, one can
+mimic a Debuginfod server by setting up a directory structure to reflect the
+protocol properly. That's how all these tests operate. We over
https://github.com/JDevlieghere edited
https://github.com/llvm/llvm-project/pull/79181
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/JDevlieghere commented:
I'm wondering if shell test are really the best way to test this. For more
complex scenarios like are being tested here, we generally prefer [1] API tests
because they're more expressive and allow you to build more complicated test
binaries with our M
@@ -4281,25 +4281,31 @@ void
Process::CalculateExecutionContext(ExecutionContext &exe_ctx) {
//return Host::GetArchSpecForExistingProcess (process_name);
//}
+EventSP Process::CreateEventFromProcessState(uint32_t event_type) {
+ auto event_data_sp =
+ std::make_shar
https://github.com/JDevlieghere approved this pull request.
https://github.com/llvm/llvm-project/pull/79045
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -8129,29 +8067,133 @@
Sema::BuildExpressionFromIntegralTemplateArgument(const TemplateArgument &Arg,
else
Kind = CharacterLiteralKind::Ascii;
-E = new (Context) CharacterLiteral(Arg.getAsIntegral().getZExtValue(),
- Kind,
@@ -8129,29 +8067,133 @@
Sema::BuildExpressionFromIntegralTemplateArgument(const TemplateArgument &Arg,
else
Kind = CharacterLiteralKind::Ascii;
-E = new (Context) CharacterLiteral(Arg.getAsIntegral().getZExtValue(),
- Kind,
@@ -0,0 +1,80 @@
+; RUN: llc -mtriple=x86_64-pc-windows-msvc %s
e-kud wrote:
It seems we still have this file on `avx512-intel64` worker:
https://lab.llvm.org/buildbot/#/builders/258/builds/12970
https://lab.llvm.org/buildbot/#/builders/258/builds/12971
https://
jimingham wrote:
LGTM This code was originally written before we used StringRef's, so making
that conversion complete is good.
https://github.com/llvm/llvm-project/pull/79508
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llv
kevinfrei wrote:
> I'm wondering if shell test are really the best way to test this. For more
> complex scenarios like are being tested here, we generally prefer [1] API
> tests because they're more expressive and allow you to build more complicated
> test binaries with our Makefile system. Th
https://github.com/MaskRay closed
https://github.com/llvm/llvm-project/pull/79256
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/JDevlieghere created
https://github.com/llvm/llvm-project/pull/79624
This fixes two issues related to the DebugSymbols symbol locator:
1. Only the default symbol locator plugin reports progress. On Darwin, which
uses the DebugSymbols framework we need to report the same pr
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jonas Devlieghere (JDevlieghere)
Changes
This fixes two issues related to the DebugSymbols symbol locator:
1. Only the default symbol locator plugin reports progress. On Darwin, which
uses the DebugSymbols framework we need to report the
@@ -0,0 +1,65 @@
+# Tests for basic Debuginfod functionality
+
+Because the Debuginfod protocol is a simple HTTP path-based system, one can
+mimic a Debuginfod server by setting up a directory structure to reflect the
+protocol properly. That's how all these tests operate. We over
@@ -0,0 +1,105 @@
+#include "Plugins/Platform/MacOSX/PlatformMacOSX.h"
+#include "Plugins/Platform/MacOSX/PlatformRemoteMacOSX.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/Progress.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/U
@@ -0,0 +1,105 @@
+#include "Plugins/Platform/MacOSX/PlatformMacOSX.h"
+#include "Plugins/Platform/MacOSX/PlatformRemoteMacOSX.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/Progress.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/U
chelcassanova wrote:
LGTM, thanks for adding new reports!
https://github.com/llvm/llvm-project/pull/79624
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Alex Langford
Date: 2024-01-26T10:19:03-08:00
New Revision: 5f22d3356cda0a9b1521c839c006f61b5cc504fc
URL:
https://github.com/llvm/llvm-project/commit/5f22d3356cda0a9b1521c839c006f61b5cc504fc
DIFF:
https://github.com/llvm/llvm-project/commit/5f22d3356cda0a9b1521c839c006f61b5cc504fc.diff
https://github.com/bulbazord closed
https://github.com/llvm/llvm-project/pull/79517
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Alex Langford
Date: 2024-01-26T10:20:52-08:00
New Revision: 176d07d360094b366b25cc009846ec64ac7d8040
URL:
https://github.com/llvm/llvm-project/commit/176d07d360094b366b25cc009846ec64ac7d8040
DIFF:
https://github.com/llvm/llvm-project/commit/176d07d360094b366b25cc009846ec64ac7d8040.diff
https://github.com/bulbazord closed
https://github.com/llvm/llvm-project/pull/79508
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
medismailben wrote:
This is only testing the `Progress` class constructor behavior. Could you check
that the `Progress::Increment` method works as expected ?
https://github.com/llvm/llvm-project/pull/79533
___
lldb-commits mailing list
lldb-commits@li
@@ -4281,25 +4281,31 @@ void
Process::CalculateExecutionContext(ExecutionContext &exe_ctx) {
//return Host::GetArchSpecForExistingProcess (process_name);
//}
+EventSP Process::CreateEventFromProcessState(uint32_t event_type) {
+ auto event_data_sp =
+ std::make_shar
https://github.com/e-kud edited https://github.com/llvm/llvm-project/pull/77608
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/e-kud edited https://github.com/llvm/llvm-project/pull/77608
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
dwblaikie wrote:
I'm not following all of this, but it appears to be based on the premise that
it's OK that sometimes split units inside a DWP file are parsed before their
skeleton unit? Why is that OK/when/why/where is that happening?
I'd think any case where that happens would be a performan
https://github.com/e-kud edited https://github.com/llvm/llvm-project/pull/77608
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,105 @@
+#include "Plugins/Platform/MacOSX/PlatformMacOSX.h"
bulbazord wrote:
Don't forget to include the license header in this file
https://github.com/llvm/llvm-project/pull/79533
___
lldb-commits mailing l
@@ -4281,25 +4281,31 @@ void
Process::CalculateExecutionContext(ExecutionContext &exe_ctx) {
//return Host::GetArchSpecForExistingProcess (process_name);
//}
+EventSP Process::CreateEventFromProcessState(uint32_t event_type) {
+ auto event_data_sp =
+ std::make_shar
Author: Alex Langford
Date: 2024-01-26T10:40:33-08:00
New Revision: 02d3a799e7eb2997950d6a288a08a5e51ff0ff59
URL:
https://github.com/llvm/llvm-project/commit/02d3a799e7eb2997950d6a288a08a5e51ff0ff59
DIFF:
https://github.com/llvm/llvm-project/commit/02d3a799e7eb2997950d6a288a08a5e51ff0ff59.diff
https://github.com/bulbazord closed
https://github.com/llvm/llvm-project/pull/79045
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,105 @@
+#include "Plugins/Platform/MacOSX/PlatformMacOSX.h"
chelcassanova wrote:
Will do! I told myself I'd add it at the end then I fully forgot to do that 🙃
https://github.com/llvm/llvm-project/pull/79533
___
JDevlieghere wrote:
> This is only testing the `Progress` class constructor behavior. Could you
> check that the `Progress::Increment` method works as expected ?
While it would be nice to have full test coverage, the goal was to cover the
existing behavior which we'll modify/extend to coalesce
https://github.com/chelcassanova updated
https://github.com/llvm/llvm-project/pull/79533
>From 9274bcd897cd3ecdb3a842bc72ee660ba335aa57 Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova
Date: Thu, 25 Jan 2024 16:40:42 -0800
Subject: [PATCH 1/2] [lldb][progress][NFC] Add unit test for progress re
@@ -831,6 +831,37 @@ bool
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommandObject(
return true;
}
+bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
+PyObject *implementor, lldb::DebuggerSP debugger,
lldb_private::StructuredDataImp
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/79533
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,105 @@
+#include "Plugins/Platform/MacOSX/PlatformMacOSX.h"
+#include "Plugins/Platform/MacOSX/PlatformRemoteMacOSX.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/Progress.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/U
https://github.com/clayborg commented:
It is great to have unit tests for this. I remember with your previous patch we
caught an issue where the completed event might not be delivered, or it would
be delivered without the values being set correctly, so this will be great to
be able to catch th
@@ -0,0 +1,105 @@
+#include "Plugins/Platform/MacOSX/PlatformMacOSX.h"
+#include "Plugins/Platform/MacOSX/PlatformRemoteMacOSX.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/Progress.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/U
@@ -0,0 +1,105 @@
+#include "Plugins/Platform/MacOSX/PlatformMacOSX.h"
+#include "Plugins/Platform/MacOSX/PlatformRemoteMacOSX.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/Progress.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/U
https://github.com/srcarroll updated
https://github.com/llvm/llvm-project/pull/79626
>From ab475c9ffb7c3562bad4772389e97b82e9f110c0 Mon Sep 17 00:00:00 2001
From: Sam
Date: Fri, 26 Jan 2024 11:55:06 -0600
Subject: [PATCH] Add elementwise criteria to match.structured.body
---
.../Linalg/Transf
@@ -831,6 +831,37 @@ bool
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommandObject(
return true;
}
+bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
+PyObject *implementor, lldb::DebuggerSP debugger,
lldb_private::StructuredDataImp
petrhosek wrote:
I tried this branch on our Windows builders although I'm not sure if it's
related or not to this patch:
```
# COMPILED WITH
C:/b/s/w/ir/x/w/llvm_build/./bin/clang-cl.exe
C:\b\s\w\ir\x\w\github-H-G-Hristov-llvm-project\libcxx\test\libcxx\fuzzing\random.pass.cpp
--driver-mode=g+
clayborg wrote:
> I'm not following all of this, but it appears to be based on the premise that
> it's OK that sometimes split units inside a DWP file are parsed before their
> skeleton unit? Why is that OK/when/why/where is that happening?
When we have accelerator tables from lldb index cache
Zingam wrote:
@petrhosek It is not related. It was supposedly fixed by this:
https://github.com/llvm/llvm-project/pull/79619
I've been observing the chromium Windows CI failing for a while. Let's see if
the above patch fixes it. I'll rebase now this one now.
https://github.com/llvm/llvm-projec
https://github.com/Zingam updated
https://github.com/llvm/llvm-project/pull/79032
>From e03452fda84a5284420bba1913299b68caabb6cd Mon Sep 17 00:00:00 2001
From: Zingam
Date: Mon, 22 Jan 2024 20:35:00 +0200
Subject: [PATCH 1/6] Revert "Revert "[libc++][format] P2637R3: Member `visit`
(`std::basi
@@ -776,6 +776,10 @@ std::optional
SymbolLocatorDebugSymbols::LocateExecutableSymbolFile(
exec_fspec ? exec_fspec->GetFilename().AsCString("") : "",
arch ? arch->GetArchitectureName() : "", (const void *)uuid);
+ Progress progress(
+ "Locating external symbo
@@ -831,6 +831,37 @@ bool
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommandObject(
return true;
}
+bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
+PyObject *implementor, lldb::DebuggerSP debugger,
lldb_private::StructuredDataImp
@@ -776,6 +776,10 @@ std::optional
SymbolLocatorDebugSymbols::LocateExecutableSymbolFile(
exec_fspec ? exec_fspec->GetFilename().AsCString("") : "",
arch ? arch->GetArchitectureName() : "", (const void *)uuid);
+ Progress progress(
+ "Locating external symbo
Zingam wrote:
@petrhosek According to the log, the tests in this patch pass. Could you please
try again. I'll wait a while and if there is not negative feedback I'll reland
the patch.
> https://logs.chromium.org/logs/fuchsia/led/phosek_google.com/62644843c966785c9dedf065a79d80df8734b4df5ff7703
https://github.com/kastiglione created
https://github.com/llvm/llvm-project/pull/79644
The `(( )?&)?` appears to match types which are references. However lldb can
load the
correct data formatters without having to pattern match against a `&` suffix.
The suffix may have been needed at one poin
https://github.com/adrian-prantl edited
https://github.com/llvm/llvm-project/pull/79624
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/adrian-prantl approved this pull request.
https://github.com/llvm/llvm-project/pull/79624
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1050,28 +1054,25 @@ bool
SymbolLocatorDebugSymbols::DownloadObjectAndSymbolFile(
const std::string file_path_str =
file_spec_ptr ? file_spec_ptr->GetPath() : "";
- Log *log = GetLog(LLDBLog::Host);
+ if (uuid_str.empty() && file_path_str.empty())
+return fal
@@ -776,6 +776,10 @@ std::optional
SymbolLocatorDebugSymbols::LocateExecutableSymbolFile(
exec_fspec ? exec_fspec->GetFilename().AsCString("") : "",
arch ? arch->GetArchitectureName() : "", (const void *)uuid);
+ Progress progress(
+ "Locating external symbo
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Dave Lee (kastiglione)
Changes
The `(( )?&)?` appears to match types which are references. However lldb
can load the
correct data formatters without having to pattern match against a `&`
suffix.
The suffix may have been needed at one poin
kastiglione wrote:
Because of clang-format, the diff obscures the fact that this change only
deletes `(( )?&)?` from these strings. There are no other changes.
https://github.com/llvm/llvm-project/pull/79644
___
lldb-commits mailing list
lldb-commits@
@@ -831,6 +831,37 @@ bool
lldb_private::python::SWIGBridge::LLDBSwigPythonCallCommandObject(
return true;
}
+bool lldb_private::python::SWIGBridge::LLDBSwigPythonCallParsedCommandObject(
+PyObject *implementor, lldb::DebuggerSP debugger,
lldb_private::StructuredDataImp
chelini wrote:
Is it ready for review? Is marked as "draft".
https://github.com/llvm/llvm-project/pull/79626
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/srcarroll updated
https://github.com/llvm/llvm-project/pull/79626
>From ab475c9ffb7c3562bad4772389e97b82e9f110c0 Mon Sep 17 00:00:00 2001
From: Sam
Date: Fri, 26 Jan 2024 11:55:06 -0600
Subject: [PATCH] Add elementwise criteria to match.structured.body
---
.../Linalg/Transf
https://github.com/JDevlieghere approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/79644
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/srcarroll updated
https://github.com/llvm/llvm-project/pull/79626
>From ab475c9ffb7c3562bad4772389e97b82e9f110c0 Mon Sep 17 00:00:00 2001
From: Sam
Date: Fri, 26 Jan 2024 11:55:06 -0600
Subject: [PATCH 1/2] Add elementwise criteria to match.structured.body
---
.../Linalg/Tr
1 - 100 of 168 matches
Mail list logo
