[Lldb-commits] [lldb] [lldb] Add support for large watchpoints in lldb (PR #79962)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda created 
https://github.com/llvm/llvm-project/pull/79962

This patch is the next piece of work in my Large Watchpoint proposal, 
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116

This patch breaks a user's watchpoint into one or more WatchpointResources 
which reflect what the hardware registers can cover. This means we can watch 
objects larger than 8 bytes, and we can watched unaligned address ranges.  On a 
typical 64-bit target with 4 watchpoint registers you can watch 32 bytes of 
memory if the start address is doubleword aligned.

Additionally, if the remote stub implements AArch64 MASK style watchpoints 
(e.g. debugserver on Darwin), we can watch any power-of-2 size region of memory 
up to 2GB, aligned to that same size.

I updated the Watchpoint constructor and CommandObjectWatchpoint to create a 
CompilerType of Array when the size of the watched region is greater 
than pointer-size and we don't have a variable type to use.  For pointer-size 
and smaller, we can display the watched granule as an integer value; for 
larger-than-pointer-size we will display as an array of bytes.

I have `watchpoint list` now print the WatchpointResources used to implement 
the watchpoint.

I added a WatchpointAlgorithm class which has a top-level static method that 
takes an enum flag mask WatchpointHardwareFeature and a user address and size, 
and returns a vector of WatchpointResources covering the request.  It does not 
take into account the number of watchpoint registers the target has, or the 
number still available for use.  Right now there is only one algorithm, which 
monitors power-of-2 regions of memory.  For up to pointer-size, this is what 
Intel hardware supports. AArch64 Byte Address Select watchpoints can watch any 
number of contiguous bytes in a pointer-size memory granule, that is not 
currently supported so if you ask to watch bytes 3-5, the algorithm will watch 
the entire doubleword (8 bytes). The newly default "modify" style means we will 
silently ignore modifications to bytes outside the watched range.

I've temporarily skipped TestLargeWatchpoint.py for all targets. It was only 
run on Darwin when using the in-tree debugserver, which was a proxy for 
"debugserver supports MASK watchpoints".  I'll be adding the aforementioned 
feature flag from the stub and enabling full mask watchpoints when a 
debugserver with that feature is enabled, and re-enable this test.

I added a new TestUnalignedLargeWatchpoint.py which only has one test but it's 
a great one, watching a 22-byte range that is unaligned and requires four 
8-byte watchpoints to cover.

I also added a unit test, WatchpointAlgorithmsTests, which has a number of 
simple tests against WatchpointAlgorithms::PowerOf2Watchpoints. I think there's 
interesting possible different approaches to how we cover these; I note in the 
unit test that a user requesting a watch on address 0x12e0 of 120 bytes will be 
covered by two watchpoints today, a 128-bytes at 0x1280 and at 0x1300.  But it 
could be done with a 16-byte watchpoint at 0x12e0 and a 128-byte at 0x1300, 
which would have fewer false positives/private stops.  As we try refining this 
one, it's helpful to have a collection of tests to make sure things don't 
regress.

I tested this on arm64 macOS, (genuine) x86_64 macOS, and AArch64 Ubuntu.  I 
have not modifed the Windows process plugins yet, I might try that as a 
standalone patch, I'd be making the change blind, but the necessary changes 
(see ProcessGDBRemote::EnableWatchpoint) are pretty small so it might be 
obvious enough that I can change it and see what the Windows CI thinks.

There isn't yet a packet (or a qSupported feature query) for the gdb remote 
serial protocol stub to communicate its watchpoint capabilities to lldb.  I'll 
be doing that in a patch right after this is landed, having debugserver 
advertise its capability of AArch64 MASK watchpoints, and have ProcessGDBRemote 
add eWatchpointHardwareArmMASK to WatchpointAlgorithms so we can watch larger 
than 32-byte requests on Darwin.

I haven't yet tackled WatchpointResource *sharing* by multiple Watchpoints.  
This is all part of the goal, especially when we may be watching a larger 
memory range than the user requested, if they then add another watchpoint next 
to their first request, it may be covered by the same WatchpointResource 
(hardware watchpoint register). Also one "read" watchpoint and one "write" 
watchpoint on the same memory granule need to be handled, making the 
WatchpointResource cover all requests.

As WatchpointResources aren't shared among multiple Watchpoints yet, there's no 
handling of running the conditions/commands/etc on multiple Watchpoints when 
their shared WatchpointResource is hit. The goal beyond "large watchpoint" is 
to unify (much more) the Watchpoint and Breakpoint behavior and commands.  I 
have a feeling I may be slowly chipping away at this for a while.

rdar://108234227

>From 

[Lldb-commits] [lldb] [lldb] Add support for large watchpoints in lldb (PR #79962)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Jason Molenda (jasonmolenda)


Changes

This patch is the next piece of work in my Large Watchpoint proposal, 
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116

This patch breaks a user's watchpoint into one or more WatchpointResources 
which reflect what the hardware registers can cover. This means we can watch 
objects larger than 8 bytes, and we can watched unaligned address ranges.  On a 
typical 64-bit target with 4 watchpoint registers you can watch 32 bytes of 
memory if the start address is doubleword aligned.

Additionally, if the remote stub implements AArch64 MASK style watchpoints 
(e.g. debugserver on Darwin), we can watch any power-of-2 size region of memory 
up to 2GB, aligned to that same size.

I updated the Watchpoint constructor and CommandObjectWatchpoint to create a 
CompilerType of Array when the size of the watched region is 
greater than pointer-size and we don't have a variable type to use.  For 
pointer-size and smaller, we can display the watched granule as an integer 
value; for larger-than-pointer-size we will display as an array of bytes.

I have `watchpoint list` now print the WatchpointResources used to implement 
the watchpoint.

I added a WatchpointAlgorithm class which has a top-level static method that 
takes an enum flag mask WatchpointHardwareFeature and a user address and size, 
and returns a vector of WatchpointResources covering the request.  It does not 
take into account the number of watchpoint registers the target has, or the 
number still available for use.  Right now there is only one algorithm, which 
monitors power-of-2 regions of memory.  For up to pointer-size, this is what 
Intel hardware supports. AArch64 Byte Address Select watchpoints can watch any 
number of contiguous bytes in a pointer-size memory granule, that is not 
currently supported so if you ask to watch bytes 3-5, the algorithm will watch 
the entire doubleword (8 bytes). The newly default "modify" style means we will 
silently ignore modifications to bytes outside the watched range.

I've temporarily skipped TestLargeWatchpoint.py for all targets. It was only 
run on Darwin when using the in-tree debugserver, which was a proxy for 
"debugserver supports MASK watchpoints".  I'll be adding the aforementioned 
feature flag from the stub and enabling full mask watchpoints when a 
debugserver with that feature is enabled, and re-enable this test.

I added a new TestUnalignedLargeWatchpoint.py which only has one test but it's 
a great one, watching a 22-byte range that is unaligned and requires four 
8-byte watchpoints to cover.

I also added a unit test, WatchpointAlgorithmsTests, which has a number of 
simple tests against WatchpointAlgorithms::PowerOf2Watchpoints. I think there's 
interesting possible different approaches to how we cover these; I note in the 
unit test that a user requesting a watch on address 0x12e0 of 120 bytes will be 
covered by two watchpoints today, a 128-bytes at 0x1280 and at 0x1300.  But it 
could be done with a 16-byte watchpoint at 0x12e0 and a 128-byte at 0x1300, 
which would have fewer false positives/private stops.  As we try refining this 
one, it's helpful to have a collection of tests to make sure things don't 
regress.

I tested this on arm64 macOS, (genuine) x86_64 macOS, and AArch64 Ubuntu.  I 
have not modifed the Windows process plugins yet, I might try that as a 
standalone patch, I'd be making the change blind, but the necessary changes 
(see ProcessGDBRemote::EnableWatchpoint) are pretty small so it might be 
obvious enough that I can change it and see what the Windows CI thinks.

There isn't yet a packet (or a qSupported feature query) for the gdb remote 
serial protocol stub to communicate its watchpoint capabilities to lldb.  I'll 
be doing that in a patch right after this is landed, having debugserver 
advertise its capability of AArch64 MASK watchpoints, and have ProcessGDBRemote 
add eWatchpointHardwareArmMASK to WatchpointAlgorithms so we can watch larger 
than 32-byte requests on Darwin.

I haven't yet tackled WatchpointResource *sharing* by multiple Watchpoints.  
This is all part of the goal, especially when we may be watching a larger 
memory range than the user requested, if they then add another watchpoint next 
to their first request, it may be covered by the same WatchpointResource 
(hardware watchpoint register). Also one "read" watchpoint and one "write" 
watchpoint on the same memory granule need to be handled, making the 
WatchpointResource cover all requests.

As WatchpointResources aren't shared among multiple Watchpoints yet, there's no 
handling of running the conditions/commands/etc on multiple Watchpoints when 
their shared WatchpointResource is hit. The goal beyond "large watchpoint" is 
to unify (much more) the Watchpoint and Breakpoint behavior and commands.  I 
have a feeling I may be slowly chipping away at this for a while.

rdar://108234

[Lldb-commits] [lldb] [lldb] Add support for large watchpoints in lldb (PR #79962)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda updated 
https://github.com/llvm/llvm-project/pull/79962

>From 24cf5649fee074e9f6c72c7f768999ce4253b268 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Tue, 30 Jan 2024 00:16:30 -0800
Subject: [PATCH 1/2] [lldb] Add support for large watchpoints in lldb

This patch is the next piece of work in my Large Watchpoint proposal,
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116

This patch breaks a user's watchpoint into one or more WatchpointResources
which reflect what the hardware registers can cover. This means we
can watch objects larger than 8 bytes, and we can watched unaligned
address ranges.  On a typical 64-bit target with 4 watchpoint
registers you can watch 32 bytes of memory if the start address is
doubleword aligned.

Additionally, if the remote stub implements AArch64 MASK style
watchpoints (e.g. debugserver on Darwin), we can watch any power-of-2
size region of memory up to 2GB, aligned to that same size.

I updated the Watchpoint constructor and CommandObjectWatchpoint
to create a CompilerType of Array when the size of the watched
region is greater than pointer-size and we don't have a variable
type to use.  For pointer-size and smaller, we can display the
watched granule as an integer value; for larger-than-pointer-size
we will display as an array of bytes.

I have `watchpoint list` now print the WatchpointResources used to
implement the watchpoint.

I added a WatchpointAlgorithm class which has a top-level static
method that takes an enum flag mask WatchpointHardwareFeature and
a user address and size, and returns a vector of WatchpointResources
covering the request.  It does not take into account the number of
watchpoint registers the target has, or the number still available
for use.  Right now there is only one algorithm, which monitors
power-of-2 regions of memory.  For up to pointer-size, this is what
Intel hardware supports. AArch64 Byte Address Select watchpoints
can watch any number of contiguous bytes in a pointer-size memory
granule, that is not currently supported so if you ask to watch
bytes 3-5, the algorithm will watch the entire doubleword (8 bytes).
The newly default "modify" style means we will silently ignore
modifications to bytes outside the watched range.

I've temporarily skipped TestLargeWatchpoint.py for all targets.
It was only run on Darwin when using the in-tree debugserver, which
was a proxy for "debugserver supports MASK watchpoints".  I'll be
adding the aforementioned feature flag from the stub and enabling
full mask watchpoints when a debugserver with that feature is enabled,
and re-enable this test.

I added a new TestUnalignedLargeWatchpoint.py which only has one
test but it's a great one, watching a 22-byte range that is unaligned
and requires four 8-byte watchpoints to cover.

I also added a unit test, WatchpointAlgorithmsTests, which has a
number of simple tests against WatchpointAlgorithms::PowerOf2Watchpoints.
I think there's interesting possible different approaches to how
we cover these; I note in the unit test that a user requesting a
watch on address 0x12e0 of 120 bytes will be covered by two watchpoints
today, a 128-bytes at 0x1280 and at 0x1300.  But it could be done
with a 16-byte watchpoint at 0x12e0 and a 128-byte at 0x1300, which
would have fewer false positives/private stops.  As we try refining
this one, it's helpful to have a collection of tests to make sure
things don't regress.

I tested this on arm64 macOS, x86_64 macOS, and AArch64 Ubuntu.  I
have not modifed the Windows process plugins yet, I might try that
as a standalone patch, I'd be making the change blind, but the
necessary changes (see ProcessGDBRemote::EnableWatchpoint) are
pretty small so it might be obvious enough that I can change it and
see what the Windows CI thinks.

There isn't yet a packet (or a qSupported feature query) for the
gdb remote serial protocol stub to communicate its watchpoint
capabilities to lldb.  I'll be doing that in a patch right after
this is landed, having debugserver advertise its capability of
AArch64 MASK watchpoints, and have ProcessGDBRemote add
eWatchpointHardwareArmMASK to WatchpointAlgorithms so we can watch
larger than 32-byte requests on Darwin.

I haven't yet tackled WatchpointResource *sharing* by multiple
Watchpoints.  This is all part of the goal, especially when we may
be watching a larger memory range than the user requested, if they
then add another watchpoint next to their first request, it may be
covered by the same WatchpointResource (hardware watchpoint register).
Also one "read" watchpoint and one "write" watchpoint on the same
memory granule need to be handled, making the WatchpointResource
cover all requests.

As WatchpointResources aren't shared among multiple Watchpoints
yet, there's no handling of running the conditions/commands/etc on
multiple Watchpoints when their shared WatchpointResource is hit.
The goal beyond "large watchpoint" is to unify (much more) the
Watchp

[Lldb-commits] [libc] [libcxx] [compiler-rt] [lldb] [flang] [clang-tools-extra] [lld] [clang] [llvm] LLVM_FAULTMAPS section can be put after the DWARF section. (PR #77107)

[Rafael Ávila de Espíndola via lldb-commits]

espindola wrote:

I no longer work on llvm:

https://lists.llvm.org/pipermail/llvm-dev/2018-May/122922.html


shamithoke ***@***.***> writes:

> @espindola 
>
> -- 
> Reply to this email directly or view it on GitHub:
> https://github.com/llvm/llvm-project/pull/77107#issuecomment-1914952526
> You are receiving this because you were mentioned.
>
> Message ID: ***@***.***>


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

[Lldb-commits] [lld] [flang] [clang] [clang-tools-extra] [libc] [libcxx] [llvm] [lldb] [compiler-rt] [concepts] Set up an instantiation scope for constraint expression comparison (PR #79698)

[Younan Zhang via lldb-commits]

https://github.com/zyn0217 updated 
https://github.com/llvm/llvm-project/pull/79698

>From 39f64e6fa02392415f0e2776166d4451346e7e81 Mon Sep 17 00:00:00 2001
From: Younan Zhang 
Date: Sun, 28 Jan 2024 01:17:32 +0800
Subject: [PATCH] [concepts] Set up an instantiation scope for constraint
 expression comparison

This is a follow-up for the comparison of constraints on out-of-line
function template definitions. We require the instantiation of a
ParmVarDecl while transforming the expression if that Decl gets
referenced by a DeclRefExpr. However, we're not actually performing
the class or function template instantiation at the time of such
comparison. Therefore, let's map these parameters to themselves so
that they get preserved after the substitution.

Fixes https://github.com/llvm/llvm-project/issues/74447.
---
 clang/docs/ReleaseNotes.rst   |  3 +++
 clang/lib/Sema/SemaConcept.cpp|  9 
 .../SemaTemplate/concepts-out-of-line-def.cpp | 22 +++
 3 files changed, 34 insertions(+)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index aa06e2b60ce91..3c5856788e717 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -128,6 +128,9 @@ Bug Fixes to C++ Support
 - Fixed a bug where variables referenced by requires-clauses inside
   nested generic lambdas were not properly injected into the constraint scope.
   (`#73418 `_)
+- Fixed a crash where substituting into a requires-expression that refers to 
function
+  parameters during the equivalence determination of two constraint 
expressions.
+  (`#74447 `)
 
 Bug Fixes to AST Handling
 ^
diff --git a/clang/lib/Sema/SemaConcept.cpp b/clang/lib/Sema/SemaConcept.cpp
index 88fc846c89e42..19a460f411757 100644
--- a/clang/lib/Sema/SemaConcept.cpp
+++ b/clang/lib/Sema/SemaConcept.cpp
@@ -797,6 +797,15 @@ static const Expr 
*SubstituteConstraintExpressionWithoutSatisfaction(
   if (Inst.isInvalid())
 return nullptr;
 
+  // Set up a dummy 'instantiation' scope in the case of reference to function
+  // parameters that the surrounding function hasn't been instantiated yet. 
Note
+  // this may happen while we're comparing two templates' constraint
+  // equivalence.
+  LocalInstantiationScope ScopeForParameters(S);
+  if (auto *FD = llvm::dyn_cast(DeclInfo.getDecl()))
+for (auto *PVD : FD->parameters())
+  ScopeForParameters.InstantiatedLocal(PVD, PVD);
+
   std::optional ThisScope;
   if (auto *RD = dyn_cast(DeclInfo.getDeclContext()))
 ThisScope.emplace(S, const_cast(RD), Qualifiers());
diff --git a/clang/test/SemaTemplate/concepts-out-of-line-def.cpp 
b/clang/test/SemaTemplate/concepts-out-of-line-def.cpp
index c4e8e6f720c49..7323ad8d9ef2c 100644
--- a/clang/test/SemaTemplate/concepts-out-of-line-def.cpp
+++ b/clang/test/SemaTemplate/concepts-out-of-line-def.cpp
@@ -536,3 +536,25 @@ void X::bar(decltype(requires { requires 
something_interesting; })) {}
 template 
 void X::bar(decltype(requires { requires is_not_same_v; })) {}
 } // namespace GH74314
+
+namespace GH74447 {
+template  struct S {
+  template 
+  void test(T target, U... value)
+requires requires {
+  target;
+  sizeof...(value) == 1;
+  V == 2;
+};
+};
+
+template 
+template 
+void S::test(T target, U... value)
+  requires requires {
+target;
+sizeof...(value) == 1;
+V == 2;
+  }
+{}
+} // namespace GH74447

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

[Lldb-commits] [lld] [flang] [clang] [clang-tools-extra] [libc] [libcxx] [llvm] [lldb] [compiler-rt] [concepts] Set up an instantiation scope for constraint expression comparison (PR #79698)

[Younan Zhang via lldb-commits]

zyn0217 wrote:

I'll try the CI again before landing it.

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

[Lldb-commits] [lldb] [test] Switch LLDB API tests from vendored unittest2 to unittest (PR #79945)

[David Spickett via lldb-commits]

@@ -86,20 +86,45 @@ def execute(self, test, litConfig):
 if timeoutInfo:
 return lit.Test.TIMEOUT, output
 
-# Parse the dotest output from stderr.
-result_regex = r"\((\d+) passes, (\d+) failures, (\d+) errors, (\d+) 
skipped, (\d+) expected failures, (\d+) unexpected successes\)"
-results = re.search(result_regex, err)
+# Parse the dotest output from stderr. First get the # of total tests, 
in order to infer the # of passes.
+# Example: "Ran 5 tests in 0.042s"
+num_ran_regex = r"^Ran (\d+) tests? in "
+num_ran_results = re.search(num_ran_regex, err, re.MULTILINE)
+
+# If parsing fails mark this test as unresolved.
+if not num_ran_results:
+return lit.Test.UNRESOLVED, output
+num_ran = int(num_ran_results.group(1))
+
+# Then look for a detailed summary, which is OK or FAILED followed by 
optional details.
+# Example: "OK (skipped=1, expected failures=1)"
+# Example: "FAILED (failures=3)"
+# Example: "OK"
+result_regex = r"^(?:OK|FAILED)(?: \((.*)\))?$"
+results = re.search(result_regex, err, re.MULTILINE)
 
 # If parsing fails mark this test as unresolved.
 if not results:
 return lit.Test.UNRESOLVED, output
 
-passes = int(results.group(1))
-failures = int(results.group(2))
-errors = int(results.group(3))
-skipped = int(results.group(4))
-expected_failures = int(results.group(5))
-unexpected_successes = int(results.group(6))
+details = results.group(1)
+parsed_details = {}
+if details:
+for detail in details.split(", "):
+detail_parts = detail.split("=")
+if len(detail_parts) != 2:
+return lit.Test.UNRESOLVED, output
+parsed_details[detail_parts[0]] = int(detail_parts[1])
+
+failures = parsed_details.get("failures", 0)

DavidSpickett wrote:

Could use `defaultdict(int)` 
(https://docs.python.org/3/library/collections.html#collections.defaultdict) or 
https://docs.python.org/3/library/stdtypes.html#dict.setdefault here.

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

[Lldb-commits] [lldb] [lldb][test] Switch LLDB API tests from vendored unittest2 to unittest (PR #79945)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett edited 
https://github.com/llvm/llvm-project/pull/79945
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][test] Switch LLDB API tests from vendored unittest2 to unittest (PR #79945)

[David Spickett via lldb-commits]

DavidSpickett wrote:

I ran this on Arm and AArch64 Linux. One test 
`lldb/test/API/functionalities/breakpoint/hardware_breakpoints/require_hw_breakpoints/TestRequireHWBreakpoints.py`
 was xfailed on AArch64 is now not. Before:
```
PASS: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
test_breakpoint (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
XFAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
test_step_out (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
XFAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
test_step_over (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
XFAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
test_step_range (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
XFAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
test_step_until (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
```
After:
```
PASS: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
test_breakpoint (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
FAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
test_step_out (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
FAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
test_step_over (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
FAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
test_step_range (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
FAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
test_step_until (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
```
To be honest, the way the XFAIL is written is very strange. We wrap a `skipIf` 
around `supports_hw_breakpoints` then we `expectedFailureIfFn` on that. Which 
sounds like we expect failure if we support hardware breakpoints, but that 
can't be how that works.

Also, I think the XFAIL was added for Arm (32 bit) 
(30308d1eb966afa35ee2fd5c5b47b17eb0382896) and did not intend to include 
AArch64. Whatever the intent was, this now fails on AArch64 so it should be 
both.

I will see if I can just rewrite the xfail here, because we're definitely doing 
something weird at the moment.

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

[Lldb-commits] [lld] [clang] [llvm] [lldb] [clang-tools-extra] [libc] [compiler-rt] [libcxx] [flang] [concepts] Push a CurContext before substituting into out-of-line constraints for comparison (PR #7

[Younan Zhang via lldb-commits]

https://github.com/zyn0217 updated 
https://github.com/llvm/llvm-project/pull/79985

>From 7ee1874af426d7879d218c6b8852fca0a87b1836 Mon Sep 17 00:00:00 2001
From: Younan Zhang 
Date: Tue, 30 Jan 2024 18:49:08 +0800
Subject: [PATCH] [concepts] Push a CurContext before substituting into
 out-of-line constraints for comparison

InjectedClassNameType is such that every template specialization within
the Record scope ought to canonicalize to it, as outlined above the
definition of that Type.

This invariant is maintained during the tree transformation at the rebuilding
stage for a template specialization type; see RebuildTemplateSpecializationType.
In that, we attempt to retrieve the current instantiation from Sema.CurContext,
and if that fails, the transformation proceeds silently.

In terms of this issue, we previously set no CurContext other than that set
by Parser, who had left the FunctionDecl before performing the constraint 
comparison.
As a result, we would profile these types (i.e. InjectedClassNameType and its
specialization type) into different values and fail to consider two expressions
equivalent, although they are.

In passing, this also fixes a crash while attempting to dump the transformed 
expression.
We failed to look into the template parameters from a CXXRecordDecl, which we
should have done since the Decl we bound to a SubstTemplateTypeParmType can be 
of
a CXXRecord type per the call to `getTemplateInstantiationArgs`
within `SubstituteConstraintExpressionWithoutSatisfaction.`

This addresses https://github.com/llvm/llvm-project/issues/56482.
---
 clang/docs/ReleaseNotes.rst   |  3 +++
 clang/lib/AST/DeclTemplate.cpp|  4 +++
 clang/lib/Sema/SemaConcept.cpp| 14 ++-
 .../SemaTemplate/concepts-out-of-line-def.cpp | 25 +++
 4 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index aa06e2b60ce9..52fe4fabfb61 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -128,6 +128,9 @@ Bug Fixes to C++ Support
 - Fixed a bug where variables referenced by requires-clauses inside
   nested generic lambdas were not properly injected into the constraint scope.
   (`#73418 `_)
+- Addressed an issue where constraints involving injected class types are 
perceived
+  distinct from its specialization types.
+  (`#56482 `_)
 
 Bug Fixes to AST Handling
 ^
diff --git a/clang/lib/AST/DeclTemplate.cpp b/clang/lib/AST/DeclTemplate.cpp
index 7d7556e670f9..946a34ea8830 100644
--- a/clang/lib/AST/DeclTemplate.cpp
+++ b/clang/lib/AST/DeclTemplate.cpp
@@ -1583,6 +1583,10 @@ void 
TemplateParamObjectDecl::printAsInit(llvm::raw_ostream &OS,
 
 TemplateParameterList *clang::getReplacedTemplateParameterList(Decl *D) {
   switch (D->getKind()) {
+  case Decl::Kind::CXXRecord:
+return cast(D)
+->getDescribedTemplate()
+->getTemplateParameters();
   case Decl::Kind::ClassTemplate:
 return cast(D)->getTemplateParameters();
   case Decl::Kind::ClassTemplateSpecialization: {
diff --git a/clang/lib/Sema/SemaConcept.cpp b/clang/lib/Sema/SemaConcept.cpp
index 88fc846c89e4..b0974ca7f4a4 100644
--- a/clang/lib/Sema/SemaConcept.cpp
+++ b/clang/lib/Sema/SemaConcept.cpp
@@ -798,8 +798,20 @@ static const Expr 
*SubstituteConstraintExpressionWithoutSatisfaction(
 return nullptr;
 
   std::optional ThisScope;
-  if (auto *RD = dyn_cast(DeclInfo.getDeclContext()))
+
+  // See TreeTransform::RebuildTemplateSpecializationType. A context scope is
+  // essential for having an injected class as the canonical type for a 
template
+  // specialization type at the rebuilding stage. This guarantees that, for
+  // out-of-line definitions, injected class name types and their equivalent
+  // template specializations can be profiled to the same value, which makes it
+  // possible that e.g. constraints involving C> and C are
+  // perceived identical.
+  std::optional ContextScope;
+  if (auto *RD = dyn_cast(DeclInfo.getDeclContext())) {
 ThisScope.emplace(S, const_cast(RD), Qualifiers());
+ContextScope.emplace(S, const_cast(cast(RD)),
+ /*NewThisContext=*/false);
+  }
   ExprResult SubstConstr = S.SubstConstraintExprWithoutSatisfaction(
   const_cast(ConstrExpr), MLTAL);
   if (SFINAE.hasErrorOccurred() || !SubstConstr.isUsable())
diff --git a/clang/test/SemaTemplate/concepts-out-of-line-def.cpp 
b/clang/test/SemaTemplate/concepts-out-of-line-def.cpp
index c4e8e6f720c4..3a0c59f01217 100644
--- a/clang/test/SemaTemplate/concepts-out-of-line-def.cpp
+++ b/clang/test/SemaTemplate/concepts-out-of-line-def.cpp
@@ -536,3 +536,28 @@ void X::bar(decltype(requires { requires 
something_interesting; })) {}
 template 
 void X::bar(decltype(requires { requires is_not_same_v; })) {}
 } // namespace GH74314
+
+namesp

[Lldb-commits] [lld] [clang] [llvm] [lldb] [clang-tools-extra] [libc] [compiler-rt] [libcxx] [flang] [concepts] Set up an instantiation scope for constraint expression comparison (PR #79698)

[Younan Zhang via lldb-commits]

https://github.com/zyn0217 closed 
https://github.com/llvm/llvm-project/pull/79698
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [lld] [libc] [lldb] [llvm] [clang-tools-extra] [flang] [libcxx] [compiler-rt] [concepts] Push a CurContext before substituting into out-of-line constraints for comparison (PR #7

[Younan Zhang via lldb-commits]

https://github.com/zyn0217 updated 
https://github.com/llvm/llvm-project/pull/79985

>From 7ee1874af426d7879d218c6b8852fca0a87b1836 Mon Sep 17 00:00:00 2001
From: Younan Zhang 
Date: Tue, 30 Jan 2024 18:49:08 +0800
Subject: [PATCH] [concepts] Push a CurContext before substituting into
 out-of-line constraints for comparison

InjectedClassNameType is such that every template specialization within
the Record scope ought to canonicalize to it, as outlined above the
definition of that Type.

This invariant is maintained during the tree transformation at the rebuilding
stage for a template specialization type; see RebuildTemplateSpecializationType.
In that, we attempt to retrieve the current instantiation from Sema.CurContext,
and if that fails, the transformation proceeds silently.

In terms of this issue, we previously set no CurContext other than that set
by Parser, who had left the FunctionDecl before performing the constraint 
comparison.
As a result, we would profile these types (i.e. InjectedClassNameType and its
specialization type) into different values and fail to consider two expressions
equivalent, although they are.

In passing, this also fixes a crash while attempting to dump the transformed 
expression.
We failed to look into the template parameters from a CXXRecordDecl, which we
should have done since the Decl we bound to a SubstTemplateTypeParmType can be 
of
a CXXRecord type per the call to `getTemplateInstantiationArgs`
within `SubstituteConstraintExpressionWithoutSatisfaction.`

This addresses https://github.com/llvm/llvm-project/issues/56482.
---
 clang/docs/ReleaseNotes.rst   |  3 +++
 clang/lib/AST/DeclTemplate.cpp|  4 +++
 clang/lib/Sema/SemaConcept.cpp| 14 ++-
 .../SemaTemplate/concepts-out-of-line-def.cpp | 25 +++
 4 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index aa06e2b60ce91..52fe4fabfb619 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -128,6 +128,9 @@ Bug Fixes to C++ Support
 - Fixed a bug where variables referenced by requires-clauses inside
   nested generic lambdas were not properly injected into the constraint scope.
   (`#73418 `_)
+- Addressed an issue where constraints involving injected class types are 
perceived
+  distinct from its specialization types.
+  (`#56482 `_)
 
 Bug Fixes to AST Handling
 ^
diff --git a/clang/lib/AST/DeclTemplate.cpp b/clang/lib/AST/DeclTemplate.cpp
index 7d7556e670f95..946a34ea8830e 100644
--- a/clang/lib/AST/DeclTemplate.cpp
+++ b/clang/lib/AST/DeclTemplate.cpp
@@ -1583,6 +1583,10 @@ void 
TemplateParamObjectDecl::printAsInit(llvm::raw_ostream &OS,
 
 TemplateParameterList *clang::getReplacedTemplateParameterList(Decl *D) {
   switch (D->getKind()) {
+  case Decl::Kind::CXXRecord:
+return cast(D)
+->getDescribedTemplate()
+->getTemplateParameters();
   case Decl::Kind::ClassTemplate:
 return cast(D)->getTemplateParameters();
   case Decl::Kind::ClassTemplateSpecialization: {
diff --git a/clang/lib/Sema/SemaConcept.cpp b/clang/lib/Sema/SemaConcept.cpp
index 88fc846c89e42..b0974ca7f4a49 100644
--- a/clang/lib/Sema/SemaConcept.cpp
+++ b/clang/lib/Sema/SemaConcept.cpp
@@ -798,8 +798,20 @@ static const Expr 
*SubstituteConstraintExpressionWithoutSatisfaction(
 return nullptr;
 
   std::optional ThisScope;
-  if (auto *RD = dyn_cast(DeclInfo.getDeclContext()))
+
+  // See TreeTransform::RebuildTemplateSpecializationType. A context scope is
+  // essential for having an injected class as the canonical type for a 
template
+  // specialization type at the rebuilding stage. This guarantees that, for
+  // out-of-line definitions, injected class name types and their equivalent
+  // template specializations can be profiled to the same value, which makes it
+  // possible that e.g. constraints involving C> and C are
+  // perceived identical.
+  std::optional ContextScope;
+  if (auto *RD = dyn_cast(DeclInfo.getDeclContext())) {
 ThisScope.emplace(S, const_cast(RD), Qualifiers());
+ContextScope.emplace(S, const_cast(cast(RD)),
+ /*NewThisContext=*/false);
+  }
   ExprResult SubstConstr = S.SubstConstraintExprWithoutSatisfaction(
   const_cast(ConstrExpr), MLTAL);
   if (SFINAE.hasErrorOccurred() || !SubstConstr.isUsable())
diff --git a/clang/test/SemaTemplate/concepts-out-of-line-def.cpp 
b/clang/test/SemaTemplate/concepts-out-of-line-def.cpp
index c4e8e6f720c49..3a0c59f012179 100644
--- a/clang/test/SemaTemplate/concepts-out-of-line-def.cpp
+++ b/clang/test/SemaTemplate/concepts-out-of-line-def.cpp
@@ -536,3 +536,28 @@ void X::bar(decltype(requires { requires 
something_interesting; })) {}
 template 
 void X::bar(decltype(requires { requires is_not_same_v; })) {}
 } // namespace GH74314
+

[Lldb-commits] [lldb] [lldb][gdb-remote][RISCV] Fix connection error to gdb server for RISC-V (PR #79990)

[via lldb-commits]

https://github.com/ita-sc created 
https://github.com/llvm/llvm-project/pull/79990

This patch fix connection for LLDB for remote gdb server running on RISC-V.

You can test connection with OpenOCD or qemu-riscv64.

>From 54cc2f5f35d64266a74e3192e6fefb03844359ea Mon Sep 17 00:00:00 2001
From: Ivan Tetyushkin 
Date: Thu, 11 Jan 2024 17:48:51 +0300
Subject: [PATCH] [lldb][gdb-remote][RISCV] Fix connection error to gdb server
 for RISC-V

---
 lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index 4a06027501a8..fd724350b155 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -4620,6 +4620,8 @@ bool 
ProcessGDBRemote::GetGDBServerRegisterInfoXMLAndProcess(
   // We don't have any information about vendor or OS.
   arch_to_use.SetTriple(llvm::StringSwitch(target_info.arch)
 .Case("i386:x86-64", "x86_64")
+.Case("riscv:rv64", "riscv64")
+.Case("riscv:rv32", "riscv32")
 .Default(target_info.arch) +
 "--");
 

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

[Lldb-commits] [lldb] [lldb][gdb-remote][RISCV] Fix connection error to gdb server for RISC-V (PR #79990)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (ita-sc)


Changes

This patch fix connection for LLDB for remote gdb server running on RISC-V.

You can test connection with OpenOCD or qemu-riscv64.

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


1 Files Affected:

- (modified) lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp (+2) 


``diff
diff --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index 4a06027501a8..fd724350b155 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -4620,6 +4620,8 @@ bool 
ProcessGDBRemote::GetGDBServerRegisterInfoXMLAndProcess(
   // We don't have any information about vendor or OS.
   arch_to_use.SetTriple(llvm::StringSwitch(target_info.arch)
 .Case("i386:x86-64", "x86_64")
+.Case("riscv:rv64", "riscv64")
+.Case("riscv:rv32", "riscv32")
 .Default(target_info.arch) +
 "--");
 

``




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

[Lldb-commits] [openmp] [libc] [libcxx] [libcxxabi] [compiler-rt] [mlir] [flang] [libunwind] [lld] [llvm] [clang-tools-extra] [lldb] [clang] [clang] static operators should evaluate object argument (P

[Tianlan Zhou via lldb-commits]

https://github.com/SuperSodaSea updated 
https://github.com/llvm/llvm-project/pull/68485

>From 03276260c48d9cafb2a0d80825156e77cdf02eba Mon Sep 17 00:00:00 2001
From: SuperSodaSea 
Date: Sat, 7 Oct 2023 21:05:17 +0800
Subject: [PATCH 01/15] [clang] static operators should evaluate object
 argument

---
 clang/lib/AST/ExprConstant.cpp|  3 +-
 clang/lib/CodeGen/CGExpr.cpp  |  2 +-
 clang/lib/CodeGen/CGExprCXX.cpp   | 41 --
 clang/lib/CodeGen/CodeGenFunction.h   |  3 +
 clang/lib/Sema/SemaChecking.cpp   |  5 +-
 clang/lib/Sema/SemaOverload.cpp   | 33 ---
 clang/test/AST/ast-dump-static-operators.cpp  | 55 +++
 .../CodeGenCXX/cxx2b-static-call-operator.cpp | 26 ++---
 .../cxx2b-static-subscript-operator.cpp   | 11 +++-
 9 files changed, 137 insertions(+), 42 deletions(-)
 create mode 100644 clang/test/AST/ast-dump-static-operators.cpp

diff --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index 5a33e918db8e..a6c81f467fbe 100644
--- a/clang/lib/AST/ExprConstant.cpp
+++ b/clang/lib/AST/ExprConstant.cpp
@@ -7806,7 +7806,8 @@ class ExprEvaluatorBase
   // Overloaded operator calls to member functions are represented as 
normal
   // calls with '*this' as the first argument.
   const CXXMethodDecl *MD = dyn_cast(FD);
-  if (MD && MD->isImplicitObjectMemberFunction()) {
+  if (MD &&
+  (MD->isImplicitObjectMemberFunction() || (OCE && MD->isStatic( {
 // FIXME: When selecting an implicit conversion for an overloaded
 // operator delete, we sometimes try to evaluate calls to conversion
 // operators without a 'this' parameter!
diff --git a/clang/lib/CodeGen/CGExpr.cpp b/clang/lib/CodeGen/CGExpr.cpp
index 54a1d300a9ac..19406ff174de 100644
--- a/clang/lib/CodeGen/CGExpr.cpp
+++ b/clang/lib/CodeGen/CGExpr.cpp
@@ -5070,7 +5070,7 @@ RValue CodeGenFunction::EmitCallExpr(const CallExpr *E,
   if (const auto *CE = dyn_cast(E))
 if (const auto *MD =
 dyn_cast_if_present(CE->getCalleeDecl());
-MD && MD->isImplicitObjectMemberFunction())
+MD && !MD->isExplicitObjectMemberFunction())
   return EmitCXXOperatorMemberCallExpr(CE, MD, ReturnValue);
 
   CGCallee callee = EmitCallee(E->getCallee());
diff --git a/clang/lib/CodeGen/CGExprCXX.cpp b/clang/lib/CodeGen/CGExprCXX.cpp
index 2e7059cc8f5b..a580c6359985 100644
--- a/clang/lib/CodeGen/CGExprCXX.cpp
+++ b/clang/lib/CodeGen/CGExprCXX.cpp
@@ -489,11 +489,42 @@ RValue
 CodeGenFunction::EmitCXXOperatorMemberCallExpr(const CXXOperatorCallExpr *E,
const CXXMethodDecl *MD,
ReturnValueSlot ReturnValue) {
-  assert(MD->isImplicitObjectMemberFunction() &&
- "Trying to emit a member call expr on a static method!");
-  return EmitCXXMemberOrOperatorMemberCallExpr(
-  E, MD, ReturnValue, /*HasQualifier=*/false, /*Qualifier=*/nullptr,
-  /*IsArrow=*/false, E->getArg(0));
+  assert(!MD->isExplicitObjectMemberFunction() &&
+ "Trying to emit a member call expr on an explicit object member "
+ "function!");
+
+  if (MD->isStatic())
+return EmitCXXStaticOperatorMemberCallExpr(E, MD, ReturnValue);
+  else
+return EmitCXXMemberOrOperatorMemberCallExpr(
+E, MD, ReturnValue, /*HasQualifier=*/false, /*Qualifier=*/nullptr,
+/*IsArrow=*/false, E->getArg(0));
+}
+
+RValue CodeGenFunction::EmitCXXStaticOperatorMemberCallExpr(
+const CXXOperatorCallExpr *E, const CXXMethodDecl *MD,
+ReturnValueSlot ReturnValue) {
+  assert(MD->isStatic());
+
+  CGCallee Callee = EmitCallee(E->getCallee());
+
+  // Emit and ignore `this` pointer.
+  EmitIgnoredExpr(E->getArg(0));
+
+  auto ProtoType = MD->getFunctionType()->castAs();
+
+  // Emit the rest of the call args.
+  CallArgList Args;
+  EmitCallArgs(Args, ProtoType, drop_begin(E->arguments(), 1),
+   E->getDirectCallee());
+
+  bool Chain = E == MustTailCall;
+  const CGFunctionInfo &FnInfo =
+  CGM.getTypes().arrangeFreeFunctionCall(Args, ProtoType, Chain);
+  llvm::CallBase *CallOrInvoke = nullptr;
+
+  return EmitCall(FnInfo, Callee, ReturnValue, Args, &CallOrInvoke, Chain,
+  E->getExprLoc());
 }
 
 RValue CodeGenFunction::EmitCUDAKernelCallExpr(const CUDAKernelCallExpr *E,
diff --git a/clang/lib/CodeGen/CodeGenFunction.h 
b/clang/lib/CodeGen/CodeGenFunction.h
index d5336382a2b9..42de125e7489 100644
--- a/clang/lib/CodeGen/CodeGenFunction.h
+++ b/clang/lib/CodeGen/CodeGenFunction.h
@@ -4163,6 +4163,9 @@ class CodeGenFunction : public CodeGenTypeCache {
   RValue EmitCXXOperatorMemberCallExpr(const CXXOperatorCallExpr *E,
const CXXMethodDecl *MD,
ReturnValueSlot ReturnValue);
+  RValue EmitCXXStaticOperatorMemberCallExpr(const CXXOperatorCallExpr *CE,
+

[Lldb-commits] [openmp] [libc] [libcxx] [libcxxabi] [compiler-rt] [mlir] [flang] [libunwind] [lld] [llvm] [clang-tools-extra] [lldb] [clang] [clang] static operators should evaluate object argument (P

[Tianlan Zhou via lldb-commits]

SuperSodaSea wrote:

Ping @MitalAshok, are you happy with this PR?

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

[Lldb-commits] [libc] [compiler-rt] [lldb] [libcxxabi] [llvm] [clang-tools-extra] [lld] [flang] [libunwind] [libcxx] [mlir] [clang] [openmp] [clang] static operators should evaluate object argument (P

[via lldb-commits]

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

Feel free to land this if he doesn't reply within the day.

@AaronBallman can we backport that? It's a pretty nasty bug

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

[Lldb-commits] [compiler-rt] [libcxxabi] [llvm] [lld] [mlir] [openmp] [libunwind] [clang-tools-extra] [clang] [libcxx] [lldb] [libc] [flang] [clang] static operators should evaluate object argument (P

[Tianlan Zhou via lldb-commits]

https://github.com/SuperSodaSea updated 
https://github.com/llvm/llvm-project/pull/68485

>From 03276260c48d9cafb2a0d80825156e77cdf02eba Mon Sep 17 00:00:00 2001
From: SuperSodaSea 
Date: Sat, 7 Oct 2023 21:05:17 +0800
Subject: [PATCH 01/15] [clang] static operators should evaluate object
 argument

---
 clang/lib/AST/ExprConstant.cpp|  3 +-
 clang/lib/CodeGen/CGExpr.cpp  |  2 +-
 clang/lib/CodeGen/CGExprCXX.cpp   | 41 --
 clang/lib/CodeGen/CodeGenFunction.h   |  3 +
 clang/lib/Sema/SemaChecking.cpp   |  5 +-
 clang/lib/Sema/SemaOverload.cpp   | 33 ---
 clang/test/AST/ast-dump-static-operators.cpp  | 55 +++
 .../CodeGenCXX/cxx2b-static-call-operator.cpp | 26 ++---
 .../cxx2b-static-subscript-operator.cpp   | 11 +++-
 9 files changed, 137 insertions(+), 42 deletions(-)
 create mode 100644 clang/test/AST/ast-dump-static-operators.cpp

diff --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index 5a33e918db8e..a6c81f467fbe 100644
--- a/clang/lib/AST/ExprConstant.cpp
+++ b/clang/lib/AST/ExprConstant.cpp
@@ -7806,7 +7806,8 @@ class ExprEvaluatorBase
   // Overloaded operator calls to member functions are represented as 
normal
   // calls with '*this' as the first argument.
   const CXXMethodDecl *MD = dyn_cast(FD);
-  if (MD && MD->isImplicitObjectMemberFunction()) {
+  if (MD &&
+  (MD->isImplicitObjectMemberFunction() || (OCE && MD->isStatic( {
 // FIXME: When selecting an implicit conversion for an overloaded
 // operator delete, we sometimes try to evaluate calls to conversion
 // operators without a 'this' parameter!
diff --git a/clang/lib/CodeGen/CGExpr.cpp b/clang/lib/CodeGen/CGExpr.cpp
index 54a1d300a9ac..19406ff174de 100644
--- a/clang/lib/CodeGen/CGExpr.cpp
+++ b/clang/lib/CodeGen/CGExpr.cpp
@@ -5070,7 +5070,7 @@ RValue CodeGenFunction::EmitCallExpr(const CallExpr *E,
   if (const auto *CE = dyn_cast(E))
 if (const auto *MD =
 dyn_cast_if_present(CE->getCalleeDecl());
-MD && MD->isImplicitObjectMemberFunction())
+MD && !MD->isExplicitObjectMemberFunction())
   return EmitCXXOperatorMemberCallExpr(CE, MD, ReturnValue);
 
   CGCallee callee = EmitCallee(E->getCallee());
diff --git a/clang/lib/CodeGen/CGExprCXX.cpp b/clang/lib/CodeGen/CGExprCXX.cpp
index 2e7059cc8f5b..a580c6359985 100644
--- a/clang/lib/CodeGen/CGExprCXX.cpp
+++ b/clang/lib/CodeGen/CGExprCXX.cpp
@@ -489,11 +489,42 @@ RValue
 CodeGenFunction::EmitCXXOperatorMemberCallExpr(const CXXOperatorCallExpr *E,
const CXXMethodDecl *MD,
ReturnValueSlot ReturnValue) {
-  assert(MD->isImplicitObjectMemberFunction() &&
- "Trying to emit a member call expr on a static method!");
-  return EmitCXXMemberOrOperatorMemberCallExpr(
-  E, MD, ReturnValue, /*HasQualifier=*/false, /*Qualifier=*/nullptr,
-  /*IsArrow=*/false, E->getArg(0));
+  assert(!MD->isExplicitObjectMemberFunction() &&
+ "Trying to emit a member call expr on an explicit object member "
+ "function!");
+
+  if (MD->isStatic())
+return EmitCXXStaticOperatorMemberCallExpr(E, MD, ReturnValue);
+  else
+return EmitCXXMemberOrOperatorMemberCallExpr(
+E, MD, ReturnValue, /*HasQualifier=*/false, /*Qualifier=*/nullptr,
+/*IsArrow=*/false, E->getArg(0));
+}
+
+RValue CodeGenFunction::EmitCXXStaticOperatorMemberCallExpr(
+const CXXOperatorCallExpr *E, const CXXMethodDecl *MD,
+ReturnValueSlot ReturnValue) {
+  assert(MD->isStatic());
+
+  CGCallee Callee = EmitCallee(E->getCallee());
+
+  // Emit and ignore `this` pointer.
+  EmitIgnoredExpr(E->getArg(0));
+
+  auto ProtoType = MD->getFunctionType()->castAs();
+
+  // Emit the rest of the call args.
+  CallArgList Args;
+  EmitCallArgs(Args, ProtoType, drop_begin(E->arguments(), 1),
+   E->getDirectCallee());
+
+  bool Chain = E == MustTailCall;
+  const CGFunctionInfo &FnInfo =
+  CGM.getTypes().arrangeFreeFunctionCall(Args, ProtoType, Chain);
+  llvm::CallBase *CallOrInvoke = nullptr;
+
+  return EmitCall(FnInfo, Callee, ReturnValue, Args, &CallOrInvoke, Chain,
+  E->getExprLoc());
 }
 
 RValue CodeGenFunction::EmitCUDAKernelCallExpr(const CUDAKernelCallExpr *E,
diff --git a/clang/lib/CodeGen/CodeGenFunction.h 
b/clang/lib/CodeGen/CodeGenFunction.h
index d5336382a2b9..42de125e7489 100644
--- a/clang/lib/CodeGen/CodeGenFunction.h
+++ b/clang/lib/CodeGen/CodeGenFunction.h
@@ -4163,6 +4163,9 @@ class CodeGenFunction : public CodeGenTypeCache {
   RValue EmitCXXOperatorMemberCallExpr(const CXXOperatorCallExpr *E,
const CXXMethodDecl *MD,
ReturnValueSlot ReturnValue);
+  RValue EmitCXXStaticOperatorMemberCallExpr(const CXXOperatorCallExpr *CE,
+

[Lldb-commits] [openmp] [lld] [clang-tools-extra] [flang] [compiler-rt] [clang] [lldb] [libunwind] [llvm] [libcxx] [libcxxabi] [mlir] [libc] [clang] static operators should evaluate object argument (P

[Tianlan Zhou via lldb-commits]

SuperSodaSea wrote:

Should be easy to backport using llvmbot once it is merged.

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

[Lldb-commits] [lldb] 7565ae6 - [lldb][test][NFC] Refactor xfails in TestRequireHWBreakpoints.py

[David Spickett via lldb-commits]

Author: David Spickett
Date: 2024-01-30T13:46:09Z
New Revision: 7565ae6eb99b6d3c5d83d04404a2df1b3785dbfe

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

LOG: [lldb][test][NFC] Refactor xfails in TestRequireHWBreakpoints.py

This file used a strange, multi-level setup where we skipped on
a function we used for xfailing. Let's not do that, just skip
the one test we care about.

Also added a comment to explain how this file works. The tests
*want* calls to fail when we ask for only hardware breaks
but have none to use.

If you don't know that, it all seems backwards.

Added: 


Modified: 

lldb/test/API/functionalities/breakpoint/hardware_breakpoints/require_hw_breakpoints/TestRequireHWBreakpoints.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/breakpoint/hardware_breakpoints/require_hw_breakpoints/TestRequireHWBreakpoints.py
 
b/lldb/test/API/functionalities/breakpoint/hardware_breakpoints/require_hw_breakpoints/TestRequireHWBreakpoints.py
index 6d7719af8d69..ae4f7ea071ed 100644
--- 
a/lldb/test/API/functionalities/breakpoint/hardware_breakpoints/require_hw_breakpoints/TestRequireHWBreakpoints.py
+++ 
b/lldb/test/API/functionalities/breakpoint/hardware_breakpoints/require_hw_breakpoints/TestRequireHWBreakpoints.py
@@ -1,5 +1,8 @@
 """
 Test require hardware breakpoints.
+
+Some of these tests require a target that does not have hardware breakpoints.
+So that we can check we fail when required to use them.
 """
 
 
@@ -12,10 +15,6 @@
 
 
 class BreakpointLocationsTestCase(HardwareBreakpointTestBase):
-@skipIf(oslist=["linux"], archs=["arm"])
-def supports_hw_breakpoints(self):
-return super().supports_hw_breakpoints()
-
 def test_breakpoint(self):
 """Test regular breakpoints when hardware breakpoints are required."""
 self.build()
@@ -27,7 +26,7 @@ def test_breakpoint(self):
 breakpoint = target.BreakpointCreateByLocation("main.c", 1)
 self.assertTrue(breakpoint.IsHardware())
 
-@expectedFailureIfFn(supports_hw_breakpoints)
+@expectedFailureIfFn(HardwareBreakpointTestBase.supports_hw_breakpoints)
 def test_step_range(self):
 """Test stepping when hardware breakpoints are required."""
 self.build()
@@ -50,7 +49,7 @@ def test_step_range(self):
 "Could not create hardware breakpoint for thread plan" in 
error.GetCString()
 )
 
-@expectedFailureIfFn(supports_hw_breakpoints)
+@expectedFailureIfFn(HardwareBreakpointTestBase.supports_hw_breakpoints)
 def test_step_out(self):
 """Test stepping out when hardware breakpoints are required."""
 self.build()
@@ -72,7 +71,7 @@ def test_step_out(self):
 "Could not create hardware breakpoint for thread plan" in 
error.GetCString()
 )
 
-@expectedFailureIfFn(supports_hw_breakpoints)
+@expectedFailureIfFn(HardwareBreakpointTestBase.supports_hw_breakpoints)
 def test_step_over(self):
 """Test stepping over when hardware breakpoints are required."""
 self.build()
@@ -90,7 +89,9 @@ def test_step_over(self):
 substrs=["error: Could not create hardware breakpoint for thread 
plan."],
 )
 
-@expectedFailureIfFn(supports_hw_breakpoints)
+# Was reported to sometimes pass on certain hardware.
+@skipIf(oslist=["linux"], archs=["arm"])
+@expectedFailureIfFn(HardwareBreakpointTestBase.supports_hw_breakpoints)
 def test_step_until(self):
 """Test stepping until when hardware breakpoints are required."""
 self.build()



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

[Lldb-commits] [lldb] [lldb][test] Switch LLDB API tests from vendored unittest2 to unittest (PR #79945)

[David Spickett via lldb-commits]

@@ -130,14 +130,14 @@ def expectedFailure_impl(func):
 
 def expectedFailureIfFn(expected_fn, bugnumber=None):
 def expectedFailure_impl(func):
-if isinstance(func, type) and issubclass(func, unittest2.TestCase):
+if isinstance(func, type) and issubclass(func, unittest.TestCase):
 raise Exception("Decorator can only be used to decorate a test 
method")
 
 @wraps(func)
 def wrapper(*args, **kwargs):
 xfail_reason = expected_fn(*args, **kwargs)
 if xfail_reason is not None:
-xfail_func = unittest2.expectedFailure(func)
+xfail_func = unittest.expectedFailure(func)

DavidSpickett wrote:

I think there's something wrong here. With this PR, the tests in 
`lldb/test/API/functionalities/breakpoint/hardware_breakpoints/require_hw_breakpoints/TestRequireHWBreakpoints.py`
 don't xfail, they just fail.

But I presume that `expectedFailureIf` is working, so perhaps it's this extra 
wrapper layer doing something different and the behaviour of `expectedFailure` 
has changed since.

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

[Lldb-commits] [lldb] [lldb][test] Switch LLDB API tests from vendored unittest2 to unittest (PR #79945)

[David Spickett via lldb-commits]

DavidSpickett wrote:

I've simplified that strange xfail in 
https://github.com/llvm/llvm-project/commit/7565ae6eb99b6d3c5d83d04404a2df1b3785dbfe.
 Still seeing the tests fail instead of xfail though, see my comment.

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

[Lldb-commits] [lldb] [lldb][RISCV] Fix connection error to gdb server for RISC-V (PR #79990)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett edited 
https://github.com/llvm/llvm-project/pull/79990
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb][RISCV] Fix connection error to gdb server for RISC-V (PR #79990)

[David Spickett via lldb-commits]

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

LGTM

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

[Lldb-commits] [lldb] [lldb][RISCV] Fix connection error to gdb server for RISC-V (PR #79990)

[David Spickett via lldb-commits]

https://github.com/DavidSpickett closed 
https://github.com/llvm/llvm-project/pull/79990
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] 8774d29 - [lldb][RISCV] Fix connection error to gdb server for RISC-V (#79990)

[via lldb-commits]

Author: ita-sc
Date: 2024-01-30T14:02:49Z
New Revision: 8774d2936dd1cf0ee8d74ff600359d465179d009

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

LOG: [lldb][RISCV] Fix connection error to gdb server for RISC-V (#79990)

This patch fix connection for LLDB for remote gdb server running on
RISC-V.

You can test connection with OpenOCD or qemu-riscv64.

Added: 


Modified: 
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

Removed: 




diff  --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index 4a06027501a8..fd724350b155 100644
--- a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
+++ b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
@@ -4620,6 +4620,8 @@ bool 
ProcessGDBRemote::GetGDBServerRegisterInfoXMLAndProcess(
   // We don't have any information about vendor or OS.
   arch_to_use.SetTriple(llvm::StringSwitch(target_info.arch)
 .Case("i386:x86-64", "x86_64")
+.Case("riscv:rv64", "riscv64")
+.Case("riscv:rv32", "riscv32")
 .Default(target_info.arch) +
 "--");
 



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

[Lldb-commits] [clang-tools-extra] [compiler-rt] [libcxx] [lld] [libc] [flang] [clang] [lldb] [llvm] [concepts] Push a CurContext before substituting into out-of-line constraints for comparison (PR #7

[Erich Keane via lldb-commits]

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


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

[Lldb-commits] [clang-tools-extra] [mlir] [compiler-rt] [libcxx] [lld] [flang] [libcxxabi] [libc] [lldb] [libunwind] [openmp] [clang] [llvm] [clang] static operators should evaluate object argument (P

[Tianlan Zhou via lldb-commits]

@@ -5865,10 +5867,24 @@ RValue CodeGenFunction::EmitCall(QualType CalleeType, 
const CGCallee &OrigCallee
 break;
   }
 }
+
+if (const auto *MD =
+dyn_cast_if_present(OCE->getCalleeDecl());
+MD && MD->isStatic())
+  StaticOperator = true;
   }
 
-  EmitCallArgs(Args, dyn_cast(FnType), E->arguments(),
-   E->getDirectCallee(), /*ParamsToSkip*/ 0, Order);
+  if (StaticOperator) {
+// If we're calling a static operator, we need to emit the object argument
+// and ignore it.
+EmitIgnoredExpr(E->getArg(0));
+
+EmitCallArgs(Args, dyn_cast(FnType),
+ drop_begin(E->arguments(), 1), E->getDirectCallee(),
+ /*ParamsToSkip=*/0, Order);
+  } else
+EmitCallArgs(Args, dyn_cast(FnType), E->arguments(),
+ E->getDirectCallee(), /*ParamsToSkip=*/0, Order);

SuperSodaSea wrote:

I tried to use `ParamsToSkip` before, and got assertion error for type mismatch 
in test **cxx2b-static-call-operator.cpp** & 
**cxx2b-static-subscript-operator.cpp**:

```
# | Assertion failed: (isGenericMethod || Ty->isVariablyModifiedType() || 
Ty.getNonReferenceType()->isObjCRetainableType() || getContext() 
.getCanonicalType(Ty.getNonReferenceType()) .getTypePtr() == 
getContext().getCanonicalType((*Arg)->getType()).getTypePtr()) && "type 
mismatch in call argument!", file 
.../llvm-project/clang/lib/CodeGen/CGCall.cpp, line 4470
```

https://github.com/llvm/llvm-project/blob/22be6a2c66fceead40cf7561806bdaf424cd3c71/clang/lib/CodeGen/CGCall.cpp#L4463-L4470

So I have to use `drop_begin` instead.

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

[Lldb-commits] [lldb] [clang] [llvm] [libc] [compiler-rt] [lld] [libcxx] [clang-tools-extra] [libcxxabi] [flang] [SLP]Improve findReusedOrderedScalars and graph rotation. (PR #77529)

[Alexey Bataev via lldb-commits]

https://github.com/alexey-bataev updated 
https://github.com/llvm/llvm-project/pull/77529

>From 7440ee8ba235fd871af0999f66d5d6130456400b Mon Sep 17 00:00:00 2001
From: Alexey Bataev 
Date: Tue, 9 Jan 2024 21:43:31 +
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
 =?UTF-8?q?l=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Created using spr 1.3.5
---
 .../Transforms/Vectorize/SLPVectorizer.cpp| 476 ++
 .../AArch64/extractelements-to-shuffle.ll |  16 +-
 .../AArch64/reorder-fmuladd-crash.ll  |   7 +-
 .../SLPVectorizer/AArch64/tsc-s116.ll |  22 +-
 .../Transforms/SLPVectorizer/X86/pr35497.ll   |  16 +-
 .../SLPVectorizer/X86/reduction-transpose.ll  |  16 +-
 .../X86/reorder-clustered-node.ll |  11 +-
 .../X86/reorder-reused-masked-gather.ll   |   7 +-
 .../SLPVectorizer/X86/reorder-vf-to-resize.ll |   2 +-
 .../X86/scatter-vectorize-reorder.ll  |  17 +-
 .../X86/shrink_after_reorder2.ll  |  11 +-
 11 files changed, 445 insertions(+), 156 deletions(-)

diff --git a/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp 
b/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
index 8e22b54f002d1..4765cef290b9d 100644
--- a/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
+++ b/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
@@ -858,7 +858,7 @@ static void addMask(SmallVectorImpl &Mask, 
ArrayRef SubMask,
 /// values 3 and 7 respectively:
 /// before:  6 9 5 4 9 2 1 0
 /// after:   6 3 5 4 7 2 1 0
-static void fixupOrderingIndices(SmallVectorImpl &Order) {
+static void fixupOrderingIndices(MutableArrayRef Order) {
   const unsigned Sz = Order.size();
   SmallBitVector UnusedIndices(Sz, /*t=*/true);
   SmallBitVector MaskedIndices(Sz);
@@ -2418,7 +2418,8 @@ class BoUpSLP {
   std::optional
   isGatherShuffledSingleRegisterEntry(
   const TreeEntry *TE, ArrayRef VL, MutableArrayRef Mask,
-  SmallVectorImpl &Entries, unsigned Part);
+  SmallVectorImpl &Entries, unsigned Part,
+  bool ForOrder);
 
   /// Checks if the gathered \p VL can be represented as multi-register
   /// shuffle(s) of previous tree entries.
@@ -2432,7 +2433,7 @@ class BoUpSLP {
   isGatherShuffledEntry(
   const TreeEntry *TE, ArrayRef VL, SmallVectorImpl &Mask,
   SmallVectorImpl> &Entries,
-  unsigned NumParts);
+  unsigned NumParts, bool ForOrder = false);
 
   /// \returns the scalarization cost for this list of values. Assuming that
   /// this subtree gets vectorized, we may need to extract the values from the
@@ -3756,65 +3757,169 @@ static void reorderOrder(SmallVectorImpl 
&Order, ArrayRef Mask) {
 std::optional
 BoUpSLP::findReusedOrderedScalars(const BoUpSLP::TreeEntry &TE) {
   assert(TE.State == TreeEntry::NeedToGather && "Expected gather node only.");
-  unsigned NumScalars = TE.Scalars.size();
+  // Try to find subvector extract/insert patterns and reorder only such
+  // patterns.
+  SmallVector GatheredScalars(TE.Scalars.begin(), TE.Scalars.end());
+  Type *ScalarTy = GatheredScalars.front()->getType();
+  int NumScalars = GatheredScalars.size();
+  if (!isValidElementType(ScalarTy))
+return std::nullopt;
+  auto *VecTy = FixedVectorType::get(ScalarTy, NumScalars);
+  int NumParts = TTI->getNumberOfParts(VecTy);
+  if (NumParts == 0 || NumParts >= NumScalars)
+NumParts = 1;
+  SmallVector ExtractMask;
+  SmallVector Mask;
+  SmallVector> Entries;
+  SmallVector> ExtractShuffles 
=
+  tryToGatherExtractElements(GatheredScalars, ExtractMask, NumParts);
+  SmallVector> GatherShuffles =
+  isGatherShuffledEntry(&TE, GatheredScalars, Mask, Entries, NumParts,
+/*ForOrder=*/true);
+  // No shuffled operands - ignore.
+  if (GatherShuffles.empty() && ExtractShuffles.empty())
+return std::nullopt;
   OrdersType CurrentOrder(NumScalars, NumScalars);
-  SmallVector Positions;
-  SmallBitVector UsedPositions(NumScalars);
-  const TreeEntry *STE = nullptr;
-  // Try to find all gathered scalars that are gets vectorized in other
-  // vectorize node. Here we can have only one single tree vector node to
-  // correctly identify order of the gathered scalars.
-  for (unsigned I = 0; I < NumScalars; ++I) {
-Value *V = TE.Scalars[I];
-if (!isa(V))
-  continue;
-if (const auto *LocalSTE = getTreeEntry(V)) {
-  if (!STE)
-STE = LocalSTE;
-  else if (STE != LocalSTE)
-// Take the order only from the single vector node.
-return std::nullopt;
-  unsigned Lane =
-  std::distance(STE->Scalars.begin(), find(STE->Scalars, V));
-  if (Lane >= NumScalars)
-return std::nullopt;
-  if (CurrentOrder[Lane] != NumScalars) {
-if (Lane != I)
+  if (GatherShuffles.size() == 1 &&
+  *GatherShuffles.front() == TTI::SK_PermuteSingleSrc &&
+  Entries.front().front()->isSame(TE.Scalars)) {
+// Exclude nodes for strided geps from analysis, better

[Lldb-commits] [lldb] [openmp] [clang] [llvm] [libc] [libcxx] [libcxxabi] [mlir] [flang] [Clang] Dump the rewritten sub-expressions in CXXDefaultArgExpr/CXXDefaultInitExpr (PR #80001)

[via lldb-commits]

https://github.com/yronglin updated 
https://github.com/llvm/llvm-project/pull/80001

>From 1e45decdaeb529904fd2076b9be42234dbd5a871 Mon Sep 17 00:00:00 2001
From: yronglin 
Date: Tue, 30 Jan 2024 21:11:48 +0800
Subject: [PATCH] [Clang] Dump the rewritten sub-expressions in
 CXXDefaultArgExpr/CXXDefaultInitExpr

Signed-off-by: yronglin 
---
 clang/include/clang/AST/TextNodeDumper.h  |  2 +
 clang/lib/AST/TextNodeDumper.cpp  | 20 +
 .../test/AST/ast-dump-for-range-lifetime.cpp  | 78 ++-
 .../Import/cxx-default-init-expr/test.cpp |  6 ++
 4 files changed, 105 insertions(+), 1 deletion(-)

diff --git a/clang/include/clang/AST/TextNodeDumper.h 
b/clang/include/clang/AST/TextNodeDumper.h
index 732749ad305e1..99183918dfde6 100644
--- a/clang/include/clang/AST/TextNodeDumper.h
+++ b/clang/include/clang/AST/TextNodeDumper.h
@@ -291,6 +291,8 @@ class TextNodeDumper
   void VisitTypeTraitExpr(const TypeTraitExpr *Node);
   void VisitArrayTypeTraitExpr(const ArrayTypeTraitExpr *Node);
   void VisitExpressionTraitExpr(const ExpressionTraitExpr *Node);
+  void VisitCXXDefaultArgExpr(const CXXDefaultArgExpr *Node);
+  void VisitCXXDefaultInitExpr(const CXXDefaultInitExpr *Node);
   void VisitMaterializeTemporaryExpr(const MaterializeTemporaryExpr *Node);
   void VisitExprWithCleanups(const ExprWithCleanups *Node);
   void VisitUnresolvedLookupExpr(const UnresolvedLookupExpr *Node);
diff --git a/clang/lib/AST/TextNodeDumper.cpp b/clang/lib/AST/TextNodeDumper.cpp
index ecf5de0be543d..748bfb0127a28 100644
--- a/clang/lib/AST/TextNodeDumper.cpp
+++ b/clang/lib/AST/TextNodeDumper.cpp
@@ -1397,6 +1397,26 @@ void TextNodeDumper::VisitExpressionTraitExpr(const 
ExpressionTraitExpr *Node) {
   OS << " " << getTraitSpelling(Node->getTrait());
 }
 
+void TextNodeDumper::VisitCXXDefaultArgExpr(const CXXDefaultArgExpr *Node) {
+  if (Node->hasRewrittenInit()) {
+OS << " has rewritten init";
+AddChild([=] {
+  ColorScope Color(OS, ShowColors, StmtColor);
+  Visit(Node->getExpr());
+});
+  }
+}
+
+void TextNodeDumper::VisitCXXDefaultInitExpr(const CXXDefaultInitExpr *Node) {
+  if (Node->hasRewrittenInit()) {
+OS << " has rewritten init";
+AddChild([=] {
+  ColorScope Color(OS, ShowColors, StmtColor);
+  Visit(Node->getExpr());
+});
+  }
+}
+
 void TextNodeDumper::VisitMaterializeTemporaryExpr(
 const MaterializeTemporaryExpr *Node) {
   if (const ValueDecl *VD = Node->getExtendingDecl()) {
diff --git a/clang/test/AST/ast-dump-for-range-lifetime.cpp 
b/clang/test/AST/ast-dump-for-range-lifetime.cpp
index dec2e29184526..88b838268be2e 100644
--- a/clang/test/AST/ast-dump-for-range-lifetime.cpp
+++ b/clang/test/AST/ast-dump-for-range-lifetime.cpp
@@ -122,7 +122,16 @@ int (&default_arg_fn(const A & = A()))[3];
 void test4() {
 
   // CHECK: FunctionDecl {{.*}} test4 'void ()'
-  // FIXME: Should dump CXXDefaultArgExpr->getExpr() if CXXDefaultArgExpr has 
been rewrited?
+  // CHECK:  -CXXForRangeStmt {{.*}}
+  // CHECK-NEXT:  |-<<>>
+  // CHECK-NEXT:  |-DeclStmt {{.*}}
+  // CHECK-NEXT:  | `-VarDecl{{.*}} implicit used __range1 'int (&)[3]' cinit
+  // CHECK-NEXT:  |   `-ExprWithCleanups {{.*}} 'int[3]' lvalue
+  // CHECK-NEXT:  | `-CallExpr {{.*}} 'int[3]' lvalue
+  // CHECK-NEXT:  |   |-ImplicitCastExpr {{.*}} 'int (&(*)(const A &))[3]' 

+  // CHECK-NEXT:  |   | `-DeclRefExpr {{.*}} 'int (&(const A &))[3]' 
lvalue Function {{.*}} 'default_arg_fn' 'int (&(const A &))[3]'
+  // CHECK-NEXT:  |   `-CXXDefaultArgExpr {{.*}} <> 'const 
A':'const P2718R0::A' lvalue has rewritten init
+  // CHECK-NEXT:  | `-MaterializeTemporaryExpr {{.*}} 'const A':'const 
P2718R0::A' lvalue extended by Var {{.*}} '__range1' 'int (&)[3]'
   for (auto e : default_arg_fn()) 
 bar(e);
 }
@@ -137,6 +146,43 @@ A foo(const A&, const DefaultA &Default = DefaultA()) {
 }
 
 void test5() {
+  // CHECK: FunctionDecl {{.*}} test5 'void ()'
+  // CHECK:  -CXXForRangeStmt {{.*}}
+  // CHECK-NEXT:  |-<<>>
+  // CHECK-NEXT:  |-DeclStmt {{.*}}
+  // CHECK-NEXT:  | `-VarDecl {{.*}} implicit used __range1 'int (&)[3]' cinit
+  // CHECK-NEXT:  |   `-ExprWithCleanups {{.*}} 'int[3]' lvalue
+  // CHECK-NEXT:  | `-CallExpr {{.*}} 'int[3]' lvalue
+  // CHECK-NEXT:  |   |-ImplicitCastExpr {{.*}} 'int (&(*)(const A &))[3]' 

+  // CHECK-NEXT:  |   | `-DeclRefExpr {{.*}} 'int (&(const A &))[3]' 
lvalue Function {{.*}} 'default_arg_fn' 'int (&(const A &))[3]'
+  // CHECK-NEXT:  |   `-MaterializeTemporaryExpr {{.*}} 'const A':'const 
P2718R0::A' lvalue extended by Var {{.*}} '__range1' 'int (&)[3]'
+  // CHECK-NEXT:  | `-ImplicitCastExpr {{.*}} 'const A':'const 
P2718R0::A' 
+  // CHECK-NEXT:  |   `-CXXBindTemporaryExpr {{.*}} 'A':'P2718R0::A'
+  // CHECK-NEXT:  | `-CallExpr {{.*}} 'A':'P2718R0::A'
+  // CHECK-NEXT:  |   |-ImplicitCastExpr {{.*}} 'A (*)(const A &, 
const DefaultA &)' 
+  // CHECK-NEXT:  |  

[Lldb-commits] [lld] [clang-tools-extra] [clang] [flang] [openmp] [compiler-rt] [mlir] [llvm] [libc] [lldb] [libcxx] [mlir][transform] Add elementwise criteria to `match.structured.body` (PR #79626)

[Oleksandr Alex Zinenko via lldb-commits]

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


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

[Lldb-commits] [compiler-rt] [libcxx] [mlir] [flang] [llvm] [clang-tools-extra] [clang] [libc] [lldb] [AArch64] add intrinsic to generate a bfi instruction (PR #79672)

[Dawei Pan via lldb-commits]

dwpan wrote:

> Hello. Can you explain why this is needed, as opposed to using the equivalent 
> shift/and/ors?

In Verilog/SystemVerilog language, the basic type is bit or bit vector, and 
length is arbitrary, insert/extract bits are common features in language.  
Introducing corresponding intrinsics could help gradually lower it and bring 
more optimization opportunities in llc.

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

[Lldb-commits] [lldb] [lldb][test] Switch LLDB API tests from vendored unittest2 to unittest (PR #79945)

[Jordan Rupprecht via lldb-commits]

rupprecht wrote:

> I ran this on Arm and AArch64 Linux. One test 
> `lldb/test/API/functionalities/breakpoint/hardware_breakpoints/require_hw_breakpoints/TestRequireHWBreakpoints.py`
>  was xfailed on AArch64 is now not. Before:
> 
> ```
> PASS: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
> test_breakpoint (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
> XFAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
> test_step_out (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
> XFAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
> test_step_over (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
> XFAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
> test_step_range (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
> XFAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
> test_step_until (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
> ```
> 
> After:
> 
> ```
> PASS: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
> test_breakpoint (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
> FAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
> test_step_out (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
> FAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
> test_step_over (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
> FAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
> test_step_range (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
> FAIL: LLDB (/home/david.spickett/build-llvm-aarch64/bin/clang-aarch64) :: 
> test_step_until (TestRequireHWBreakpoints.BreakpointLocationsTestCase)
> ```
> 
> To be honest, the way the XFAIL is written is very strange. We wrap a 
> `skipIf` around `supports_hw_breakpoints` then we `expectedFailureIfFn` on 
> that. Which sounds like we expect failure if we support hardware breakpoints, 
> but that can't be how that works.
> 
> Also, I think the XFAIL was added for Arm (32 bit) 
> ([30308d1](https://github.com/llvm/llvm-project/commit/30308d1eb966afa35ee2fd5c5b47b17eb0382896))
>  and did not intend to include AArch64. Whatever the intent was, this now 
> fails on AArch64 so it should be both.
> 
> I will see if I can just rewrite the xfail here, because we're definitely 
> doing something weird at the moment.

Argh, thanks very much for running those tests -- I had noticed that issue 
before, but forgot about it when mailing this. The issue is that 
`expectedFailureIfFn` inherently doesn't work anymore. I need to remove that 
usage first. Thankfully it's only used in three test case files.

Versions of both `unittest` and `unittest2` from trunk expect that any xfail 
annotations are applied at test class instantiation (or something; a Python 
compiler expert can correct me). But our local copy of `unittest2` is forked 
from an older version which allows the xfail annotation to apply at test 
runtime. So anything that relies on lazily deciding if a test case should be 
xfail will not work when unittest tries to eagerly check if something is xfail. 
`expectedFailureIfFn` is a decorator that wraps the test case and only calls 
the fn when the test has just finished setup and is about to start the actual 
test case.

More details w/ commit & bug links in 
https://github.com/llvm/llvm-project/pull/73067#issuecomment-1828761806.

Anyway, I'll see about landing that first, and hopefully it doesn't interfere 
w/ this PR much.

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

[Lldb-commits] [clang-tools-extra] [lld] [clang] [flang] [compiler-rt] [llvm] [libc] [lldb] [libcxx] [Clang][C++23] Implement P2448R2: Relaxing some constexpr restrictions (PR #77753)

[Mariya Podchishchaeva via lldb-commits]

Fznamznon wrote:

Given the problem in 
https://github.com/llvm/llvm-project/pull/77753#issuecomment-1912258038 , 
@cor3ntin , @AaronBallman WDYT about adding new flags to `CXXRecordDecl`, 
saying that constructor/destructor is not really `constexpr` before C++23?

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

[Lldb-commits] [libcxx] [libcxxabi] [lldb] [libunwind] [clang-tools-extra] [libc] [mlir] [compiler-rt] [clang] [lld] [llvm] [openmp] [flang] [clang] static operators should evaluate object argument (P

[Aaron Ballman via lldb-commits]

@@ -5865,10 +5867,24 @@ RValue CodeGenFunction::EmitCall(QualType CalleeType, 
const CGCallee &OrigCallee
 break;
   }
 }
+
+if (const auto *MD =
+dyn_cast_if_present(OCE->getCalleeDecl());
+MD && MD->isStatic())
+  StaticOperator = true;
   }
 
-  EmitCallArgs(Args, dyn_cast(FnType), E->arguments(),
-   E->getDirectCallee(), /*ParamsToSkip*/ 0, Order);
+  if (StaticOperator) {
+// If we're calling a static operator, we need to emit the object argument
+// and ignore it.
+EmitIgnoredExpr(E->getArg(0));
+
+EmitCallArgs(Args, dyn_cast(FnType),
+ drop_begin(E->arguments(), 1), E->getDirectCallee(),
+ /*ParamsToSkip=*/0, Order);
+  } else
+EmitCallArgs(Args, dyn_cast(FnType), E->arguments(),
+ E->getDirectCallee(), /*ParamsToSkip=*/0, Order);

AaronBallman wrote:

I think that suggests there's still a problem; we should not have to manually 
drop the arguments when there's a parameter explicitly for that. I think what's 
happening is that there's a mismatch between static call operator prototypes 
and the checking logic in `EmitCallArgs`. CC @efriedma-quic @rjmccall 

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

[Lldb-commits] [libcxx] [libcxxabi] [lldb] [mlir] [clang-tools-extra] [libc] [compiler-rt] [clang] [lld] [llvm] [openmp] [flang] [mlir][transform] Add elementwise criteria to `match.structured.body` (

[via 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/3] Add elementwise criteria to match.structured.body

---
 .../Linalg/TransformOps/LinalgMatchOps.td |  4 +++
 .../Linalg/TransformOps/LinalgMatchOps.cpp|  9 -
 .../Dialect/Linalg/match-ops-interpreter.mlir | 34 +++
 .../Dialect/Linalg/match-ops-invalid.mlir |  2 +-
 4 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgMatchOps.td 
b/mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgMatchOps.td
index 162dd05f93030..dfeb8ae5d5ddb 100644
--- a/mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgMatchOps.td
+++ b/mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgMatchOps.td
@@ -106,6 +106,9 @@ def MatchStructuredBodyOp : Op((bbarg0, bbarg1), bbarg2)` where `` and
 `` are binary operations whose names are specified in the 
attribute
@@ -123,6 +126,7 @@ def MatchStructuredBodyOp : Op:$reduction_position,
UnitAttr:$passthrough,
+   UnitAttr:$elementwise,
OptionalAttr:$contraction);
   let assemblyFormat = "$operand_handle attr-dict `:` type($operand_handle)";
   let extraClassDeclaration = SingleOpMatcher.extraDeclaration;
diff --git a/mlir/lib/Dialect/Linalg/TransformOps/LinalgMatchOps.cpp 
b/mlir/lib/Dialect/Linalg/TransformOps/LinalgMatchOps.cpp
index 115da4b90e063..fb18886c16b16 100644
--- a/mlir/lib/Dialect/Linalg/TransformOps/LinalgMatchOps.cpp
+++ b/mlir/lib/Dialect/Linalg/TransformOps/LinalgMatchOps.cpp
@@ -11,6 +11,7 @@
 #include "mlir/Dialect/Linalg/IR/Linalg.h"
 #include "mlir/Dialect/Linalg/IR/LinalgInterfaces.h"
 #include "mlir/Dialect/Linalg/TransformOps/Syntax.h"
+#include "mlir/Dialect/Linalg/Utils/Utils.h"
 #include "mlir/Dialect/Transform/IR/MatchInterfaces.h"
 #include "mlir/IR/BuiltinAttributes.h"
 #include "mlir/Interfaces/FunctionImplementation.h"
@@ -187,6 +188,11 @@ DiagnosedSilenceableFailure 
transform::MatchStructuredBodyOp::matchOperation(
 }
 return DiagnosedSilenceableFailure::success();
   }
+  if (getElementwise()) {
+if (!isElementwise(linalgOp))
+  return emitSilenceableError() << "not elementwise";
+return DiagnosedSilenceableFailure::success();
+  }
   if (std::optional contractionOps = getContraction()) {
 Block &body = linalgOp->getRegion(0).front();
 std::string message;
@@ -209,13 +215,14 @@ DiagnosedSilenceableFailure 
transform::MatchStructuredBodyOp::matchOperation(
 
 LogicalResult transform::MatchStructuredBodyOp::verify() {
   int64_t numOptions = getReductionPosition().has_value() + getPassthrough() +
-   getContraction().has_value();
+   getElementwise() + getContraction().has_value();
 
   if (numOptions > 1) {
 std::string attributeNames;
 llvm::raw_string_ostream os(attributeNames);
 llvm::interleaveComma(ArrayRef{getReductionPositionAttrName(),
getPassthroughAttrName(),
+   getElementwiseAttrName(),
getContractionAttrName()},
   os);
 return emitOpError() << "only one of {" << os.str() << "} is allowed";
diff --git a/mlir/test/Dialect/Linalg/match-ops-interpreter.mlir 
b/mlir/test/Dialect/Linalg/match-ops-interpreter.mlir
index a7353a4c38881..0efe70a7b9ae1 100644
--- a/mlir/test/Dialect/Linalg/match-ops-interpreter.mlir
+++ b/mlir/test/Dialect/Linalg/match-ops-interpreter.mlir
@@ -180,6 +180,40 @@ module attributes { transform.with_named_sequence } {
 
 // -
 
+module attributes { transform.with_named_sequence } {
+  transform.named_sequence @print_elementwise(%arg0: !transform.any_op 
{transform.readonly}) {
+transform.test_print_remark_at_operand %arg0, "elementwise" : 
!transform.any_op
+transform.yield
+  }
+
+  transform.named_sequence @match_structured_body_elementwise(%arg0: 
!transform.any_op {transform.readonly}) -> !transform.any_op {
+%0 = transform.match.structured failures(propagate) %arg0 : 
(!transform.any_op) -> !transform.any_op {
+^bb0(%arg1: !transform.any_op):
+  transform.match.structured.body %arg1 { elementwise } : !transform.any_op
+  transform.match.structured.yield %arg1 : !transform.any_op
+}
+transform.yield %0 : !transform.any_op
+  }
+
+  transform.named_sequence @__transform_main(%arg0: !transform.any_op 
{transform.consumed}) {
+transform.foreach_match in %arg0
+@match_structured_body_elementwise -> @print_elementwise
+: (!transform.any_op) -> !transform.any_op
+transform.yield
+  }
+
+  func.func @payload(%in1: tensor<2xf32>, %in2: tensor<2xf32>, %out: 
tensor<2xf32>) -> tensor<2xf32> attributes { transform.target_tag = 
"start_here

[Lldb-commits] [libcxx] [llvm] [mlir] [libcxxabi] [clang] [compiler-rt] [openmp] [flang] [lld] [clang-tools-extra] [libc] [lldb] [libunwind] [clang] static operators should evaluate object argument (P

[Aaron Ballman via lldb-commits]

@@ -5865,10 +5867,24 @@ RValue CodeGenFunction::EmitCall(QualType CalleeType, 
const CGCallee &OrigCallee
 break;
   }
 }
+
+if (const auto *MD =
+dyn_cast_if_present(OCE->getCalleeDecl());
+MD && MD->isStatic())
+  StaticOperator = true;
   }
 
-  EmitCallArgs(Args, dyn_cast(FnType), E->arguments(),
-   E->getDirectCallee(), /*ParamsToSkip*/ 0, Order);
+  if (StaticOperator) {
+// If we're calling a static operator, we need to emit the object argument
+// and ignore it.
+EmitIgnoredExpr(E->getArg(0));
+
+EmitCallArgs(Args, dyn_cast(FnType),
+ drop_begin(E->arguments(), 1), E->getDirectCallee(),
+ /*ParamsToSkip=*/0, Order);
+  } else
+EmitCallArgs(Args, dyn_cast(FnType), E->arguments(),
+ E->getDirectCallee(), /*ParamsToSkip=*/0, Order);

AaronBallman wrote:

Ah, thank you Eli! I missed that this was a params vs args issue.

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

[Lldb-commits] [libcxx] [llvm] [mlir] [libcxxabi] [clang] [compiler-rt] [openmp] [flang] [lld] [clang-tools-extra] [libc] [lldb] [libunwind] [clang] static operators should evaluate object argument (P

[Aaron Ballman via lldb-commits]

AaronBallman wrote:

LGTM now, thank you for bearing with me! Do you need one of us to commit this 
on your behalf?

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

[Lldb-commits] [llvm] [libcxx] [libcxxabi] [compiler-rt] [openmp] [clang] [libc] [libunwind] [mlir] [clang-tools-extra] [lld] [flang] [lldb] [clang] static operators should evaluate object argument (P

[Tianlan Zhou via lldb-commits]

SuperSodaSea wrote:

Yeah, I'd be happy if anyone with write access could help. I'll create a 
backport issue after the commit.

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

[Lldb-commits] [libc] [compiler-rt] [mlir] [clang] [libcxx] [flang] [libcxxabi] [lld] [lldb] [llvm] [mlir][sparse] Expand LevelType to 64 bits and implement n out of m (PR #79935)

[Yinying Li via lldb-commits]

https://github.com/yinying-lisa-li updated 
https://github.com/llvm/llvm-project/pull/79935

>From fa5210448dea1f88d8e0a242543ad1be655087e0 Mon Sep 17 00:00:00 2001
From: Yinying Li 
Date: Tue, 30 Jan 2024 01:01:52 +
Subject: [PATCH 1/3] [mlir][sparse] Expand LevelType to 64 bit and implement n
 out of m

---
 mlir/include/mlir-c/Dialect/SparseTensor.h|  28 +--
 .../mlir/Dialect/SparseTensor/IR/Enums.h  | 225 +++---
 .../SparseTensor/IR/SparseTensorAttrDefs.td   |   4 +-
 .../SparseTensor/IR/SparseTensorType.h|   2 +-
 .../mlir/Dialect/SparseTensor/Utils/Merger.h  |   2 +-
 .../ExecutionEngine/SparseTensor/Storage.h|  14 +-
 .../Bindings/Python/DialectSparseTensor.cpp   |   2 +-
 mlir/lib/CAPI/Dialect/SparseTensor.cpp|  49 ++--
 .../IR/Detail/DimLvlMapParser.cpp |   2 +
 .../SparseTensor/IR/Detail/LvlTypeParser.cpp  |  55 -
 .../SparseTensor/IR/Detail/LvlTypeParser.h|   6 +-
 .../Transforms/SparseGPUCodegen.cpp   |   2 +-
 .../Transforms/SparseTensorCodegen.cpp|   6 +-
 .../Transforms/Sparsification.cpp |   2 +-
 .../Transforms/Utils/CodegenUtils.h   |   2 +-
 .../Transforms/Utils/SparseTensorLevel.cpp|   2 +-
 .../lib/Dialect/SparseTensor/Utils/Merger.cpp |   4 +-
 .../ExecutionEngine/SparseTensor/Storage.cpp  |   2 +-
 mlir/test/CAPI/sparse_tensor.c|   6 +-
 .../SparseTensor/GPU/gpu_matmul24_lib.mlir|   2 +-
 .../test/Dialect/SparseTensor/conversion.mlir |  16 +-
 .../SparseTensor/roundtrip_encoding.mlir  |  12 +-
 .../SparseTensor/sparse_fill_zero.mlir|  12 +-
 .../SparseTensor/CPU/sparse_block_matmul.mlir |   2 +-
 .../Dialect/SparseTensor/CPU/sparse_ds.mlir   |   2 +-
 .../CUDA/sm80-lt/sparse-matmul-2-4-lib.mlir   |   2 +-
 .../CUDA/sm80-lt/sparse-matmul-2-4-prune.mlir |   2 +-
 .../python/dialects/sparse_tensor/dialect.py  | 148 ++--
 28 files changed, 358 insertions(+), 255 deletions(-)

diff --git a/mlir/include/mlir-c/Dialect/SparseTensor.h 
b/mlir/include/mlir-c/Dialect/SparseTensor.h
index 41d024db04964..5fc1f51452482 100644
--- a/mlir/include/mlir-c/Dialect/SparseTensor.h
+++ b/mlir/include/mlir-c/Dialect/SparseTensor.h
@@ -26,20 +26,20 @@ MLIR_DECLARE_CAPI_DIALECT_REGISTRATION(SparseTensor, 
sparse_tensor);
 /// If updating, keep them in sync and update the static_assert in the impl
 /// file.
 enum MlirSparseTensorLevelType {
-  MLIR_SPARSE_TENSOR_LEVEL_DENSE = 4,   // 0b1_00
-  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED = 8,  // 0b00010_00
-  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED_NU = 9,   // 0b00010_01
-  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED_NO = 10,  // 0b00010_10
-  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED_NU_NO = 11,   // 0b00010_11
-  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON = 16,  // 0b00100_00
-  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON_NU = 17,   // 0b00100_01
-  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON_NO = 18,   // 0b00100_10
-  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON_NU_NO = 19,// 0b00100_11
-  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED = 32,   // 0b01000_00
-  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED_NU = 33,// 0b01000_01
-  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED_NO = 34,// 0b01000_10
-  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED_NU_NO = 35, // 0b01000_11
-  MLIR_SPARSE_TENSOR_LEVEL_TWO_OUT_OF_FOUR = 64,// 0b1_00
+  MLIR_SPARSE_TENSOR_LEVEL_DENSE = 65536,   // 
0x00_00_0001_
+  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED = 131072, // 
0x00_00_0002_
+  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED_NU = 131073,  // 
0x00_00_0002_0001
+  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED_NO = 131074,  // 
0x00_00_0002_0002
+  MLIR_SPARSE_TENSOR_LEVEL_COMPRESSED_NU_NO = 131075,   // 
0x00_00_0002_0003
+  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON = 262144,  // 
0x00_00_0004_
+  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON_NU = 262145,   // 
0x00_00_0004_0001
+  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON_NO = 262146,   // 
0x00_00_0004_0002
+  MLIR_SPARSE_TENSOR_LEVEL_SINGLETON_NU_NO = 262147,// 
0x00_00_0004_0003
+  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED = 524288,   // 
0x00_00_0008_
+  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED_NU = 524289,// 
0x00_00_0008_0001
+  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED_NO = 524290,// 
0x00_00_0008_0002
+  MLIR_SPARSE_TENSOR_LEVEL_LOOSE_COMPRESSED_NU_NO = 524291, // 
0x00_00_0008_0003
+  MLIR_SPARSE_TENSOR_LEVEL_N_OUT_OF_M = 1048576,// 
0x00_00_0010_
 };
 
 
//===--===//
diff --git a/mlir/include/mlir/Dialect/SparseTensor/IR/Enums.h 
b/mlir/include/mlir/Dialect/SparseTensor/IR/Enums.h
index ac91bfa5ae622..6ddc9326179fe 100644
--- a/mlir/include/mlir/Dialect/SparseTensor/IR/Enums.h
+++ b/mlir/include/mlir/Dialect/SparseTensor/IR/Enums.h
@@ -154,9 +154,10 @@ enum class Action : uint32_t {
 
 /// 

[Lldb-commits] [libc] [mlir] [compiler-rt] [openmp] [clang-tools-extra] [clang] [libcxx] [flang] [libunwind] [libcxxabi] [lld] [lldb] [llvm] [clang] static operators should evaluate object argument (P

[Aaron Ballman via lldb-commits]

https://github.com/AaronBallman closed 
https://github.com/llvm/llvm-project/pull/68485
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [libcxx] [llvm] [mlir] [libcxxabi] [clang] [compiler-rt] [openmp] [flang] [lld] [clang-tools-extra] [libc] [lldb] [libunwind] [clang] static operators should evaluate object argument (P

[Aaron Ballman via lldb-commits]

AaronBallman wrote:

> Yeah, I'd be happy if anyone with write access could help. I'll create a 
> backport issue after the commit.

I've landed the changes, thank you for the fix and the offer to help backport!

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

[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

[Adrian Prantl via lldb-commits]

@@ -218,6 +219,104 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
   m_fallback.GetCompleteObjCClass(class_name, must_be_implementation, 
callback);
 }
 
+namespace {
+using Entry = llvm::DWARFDebugNames::Entry;
+
+/// If `entry` and all of its parents have an `IDX_parent`, use that 
information
+/// to build and return a list of at most `max_parents` parent Entries.
+/// `entry` itself is not included in the list.
+/// If any parent does not have an `IDX_parent`, or the Entry data is 
corrupted,
+/// nullopt is returned.
+static std::optional>
+getParentChain(Entry entry, uint32_t max_parents) {
+  llvm::SmallVector parent_entries;
+
+  do {
+if (!entry.hasParentInformation())
+  return std::nullopt;
+
+llvm::Expected> parent = entry.getParentDIEEntry();
+if (!parent) { // Bad data.
+  consumeError(parent.takeError());
+  return std::nullopt;
+}
+
+// Last parent in the chain
+if (!parent->has_value())
+  break;
+
+parent_entries.push_back(**parent);
+entry = **parent;
+  } while (parent_entries.size() < max_parents);
+
+  return parent_entries;
+}
+} // namespace
+
+void DebugNamesDWARFIndex::GetFullyQualifiedType(
+const DWARFDeclContext &context,
+llvm::function_ref callback) {
+  if (context.GetSize() == 0)
+return;
+
+  // Fallback: use the base class implementation.
+  auto fallback_impl = [&](const DebugNames::Entry &entry) {
+return ProcessEntry(entry, [&](DWARFDIE die) {
+  return GetFullyQualifiedTypeImpl(context, die, callback);
+});
+  };
+
+  llvm::StringRef leaf_name = context[0].name;
+  llvm::SmallVector parent_names;
+  for (auto idx : llvm::seq(1, context.GetSize()))
+parent_names.emplace_back(context[idx].name);
+
+  for (const DebugNames::Entry &entry :
+   m_debug_names_up->equal_range(leaf_name)) {
+if (!isType(entry.tag()))
+  continue;
+
+// Grab at most one extra parent, subsequent parents are not necessary to
+// test equality.
+auto parent_chain = getParentChain(entry, parent_names.size() + 1);
+
+if (!parent_chain) {
+  if (!fallback_impl(entry))
+return;
+  continue;
+}
+
+if (SameParentChain(parent_names, *parent_chain) &&

adrian-prantl wrote:

This might benefit fro a few high-level comments about what's happening in this 
loop?

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

[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

[Adrian Prantl via lldb-commits]

@@ -218,6 +219,104 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
   m_fallback.GetCompleteObjCClass(class_name, must_be_implementation, 
callback);
 }
 
+namespace {
+using Entry = llvm::DWARFDebugNames::Entry;
+
+/// If `entry` and all of its parents have an `IDX_parent`, use that 
information
+/// to build and return a list of at most `max_parents` parent Entries.
+/// `entry` itself is not included in the list.
+/// If any parent does not have an `IDX_parent`, or the Entry data is 
corrupted,
+/// nullopt is returned.
+static std::optional>

adrian-prantl wrote:

isn't `namespace` and `static` redundant?

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

[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

[Adrian Prantl via lldb-commits]

@@ -218,6 +219,104 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
   m_fallback.GetCompleteObjCClass(class_name, must_be_implementation, 
callback);
 }
 
+namespace {
+using Entry = llvm::DWARFDebugNames::Entry;
+
+/// If `entry` and all of its parents have an `IDX_parent`, use that 
information
+/// to build and return a list of at most `max_parents` parent Entries.
+/// `entry` itself is not included in the list.
+/// If any parent does not have an `IDX_parent`, or the Entry data is 
corrupted,
+/// nullopt is returned.
+static std::optional>
+getParentChain(Entry entry, uint32_t max_parents) {
+  llvm::SmallVector parent_entries;
+
+  do {
+if (!entry.hasParentInformation())
+  return std::nullopt;
+
+llvm::Expected> parent = entry.getParentDIEEntry();
+if (!parent) { // Bad data.
+  consumeError(parent.takeError());
+  return std::nullopt;
+}
+
+// Last parent in the chain
+if (!parent->has_value())
+  break;
+
+parent_entries.push_back(**parent);
+entry = **parent;
+  } while (parent_entries.size() < max_parents);
+
+  return parent_entries;
+}
+} // namespace
+
+void DebugNamesDWARFIndex::GetFullyQualifiedType(
+const DWARFDeclContext &context,
+llvm::function_ref callback) {
+  if (context.GetSize() == 0)
+return;
+
+  // Fallback: use the base class implementation.
+  auto fallback_impl = [&](const DebugNames::Entry &entry) {
+return ProcessEntry(entry, [&](DWARFDIE die) {
+  return GetFullyQualifiedTypeImpl(context, die, callback);
+});
+  };
+
+  llvm::StringRef leaf_name = context[0].name;
+  llvm::SmallVector parent_names;
+  for (auto idx : llvm::seq(1, context.GetSize()))
+parent_names.emplace_back(context[idx].name);
+
+  for (const DebugNames::Entry &entry :
+   m_debug_names_up->equal_range(leaf_name)) {
+if (!isType(entry.tag()))
+  continue;
+
+// Grab at most one extra parent, subsequent parents are not necessary to
+// test equality.
+auto parent_chain = getParentChain(entry, parent_names.size() + 1);
+
+if (!parent_chain) {
+  if (!fallback_impl(entry))
+return;
+  continue;
+}
+
+if (SameParentChain(parent_names, *parent_chain) &&
+!ProcessEntry(entry, callback))
+  return;
+  }
+}
+
+bool DebugNamesDWARFIndex::SameParentChain(

adrian-prantl wrote:

Any comments that would be useful in this function?

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

[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

[Adrian Prantl via lldb-commits]

@@ -218,6 +219,104 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
   m_fallback.GetCompleteObjCClass(class_name, must_be_implementation, 
callback);
 }
 
+namespace {
+using Entry = llvm::DWARFDebugNames::Entry;
+
+/// If `entry` and all of its parents have an `IDX_parent`, use that 
information
+/// to build and return a list of at most `max_parents` parent Entries.
+/// `entry` itself is not included in the list.
+/// If any parent does not have an `IDX_parent`, or the Entry data is 
corrupted,
+/// nullopt is returned.
+static std::optional>
+getParentChain(Entry entry, uint32_t max_parents) {
+  llvm::SmallVector parent_entries;
+
+  do {
+if (!entry.hasParentInformation())
+  return std::nullopt;
+
+llvm::Expected> parent = entry.getParentDIEEntry();
+if (!parent) { // Bad data.

adrian-prantl wrote:

comment should be on its own line.

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

[Lldb-commits] [clang] [flang] [compiler-rt] [lld] [lldb] [libcxx] [llvm] [libc] [clang-tools-extra] [libcxxabi] Move ExpandMemCmp and MergeIcmp to the middle end (PR #77370)

[Gabriel Baraldi via lldb-commits]

gbaraldi wrote:

Ok, it seems CI is finally a bit happier, not sure what was going on. @nikic 
what do you think is needed to get this in? 

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

[Lldb-commits] [openmp] [mlir] [clang] [flang] [compiler-rt] [lld] [lldb] [libcxx] [libunwind] [llvm] [libc] [clang-tools-extra] [libcxxabi] [clang] static operators should evaluate object argument (P

[Nico Weber via lldb-commits]

nico wrote:

This might've broken clangd tests: http://45.33.8.238/linux/129484/step_9.txt

Does that look related? If so, please take a look and revert for now if it 
takes a while to fix.

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

[Lldb-commits] [openmp] [clang] [lldb] [libc] [compiler-rt] [flang] [libcxxabi] [libcxx] [llvm] [mlir] [clang-tools-extra] [lld] [mlir][transform] Add elementwise criteria to `match.structured.body` (

[via lldb-commits]

srcarroll wrote:

anyone know what's up with the buildkite failure?

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

[Lldb-commits] [libcxxabi] [clang] [libc] [compiler-rt] [lldb] [flang] [openmp] [libcxx] [libunwind] [llvm] [mlir] [clang-tools-extra] [lld] [clang] static operators should evaluate object argument (P

[Aaron Ballman via lldb-commits]

AaronBallman wrote:

Hmmm that does look related. I'll revert so we get back to green. CC 
@sam-mccall in case he has opinions on how we can ease tension between making 
fixes in Clang that impact clangd tests (clangd is a consumer of Clang and we 
usually expect consumers to react when their tests break due to conforming and 
correct changes in Clang). I mostly want to be mindful of the new contributor 
experience, as in this case.

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

[Lldb-commits] [compiler-rt] [libc] [clang] [flang] [lldb] [libcxx] [llvm] [mlir] [clang-tools-extra] [OpenMP] atomic compare weak : Parser & AST support (PR #79475)

[via lldb-commits]

https://github.com/SunilKuravinakop updated 
https://github.com/llvm/llvm-project/pull/79475

>From 6614e517cf0888b4502efc0af974d1612fa7a822 Mon Sep 17 00:00:00 2001
From: Sunil Kuravinakop 
Date: Thu, 25 Jan 2024 10:37:20 -0600
Subject: [PATCH 1/3] Changes to Support Parsing & Sema of atomic compare weak.

  Changes to be committed:
modified:   clang/include/clang/AST/OpenMPClause.h
modified:   clang/include/clang/AST/RecursiveASTVisitor.h
modified:   clang/include/clang/Basic/DiagnosticSemaKinds.td
modified:   clang/include/clang/Sema/Sema.h
modified:   clang/lib/AST/OpenMPClause.cpp
modified:   clang/lib/AST/StmtProfile.cpp
modified:   clang/lib/CodeGen/CGStmtOpenMP.cpp
modified:   clang/lib/Parse/ParseOpenMP.cpp
modified:   clang/lib/Sema/SemaOpenMP.cpp
modified:   clang/lib/Sema/TreeTransform.h
modified:   clang/lib/Serialization/ASTReader.cpp
modified:   clang/lib/Serialization/ASTWriter.cpp
modified:   clang/test/OpenMP/atomic_ast_print.cpp
modified:   clang/test/OpenMP/atomic_messages.cpp
modified:   clang/tools/libclang/CIndex.cpp
modified:   llvm/include/llvm/Frontend/OpenMP/OMP.td
---
 clang/include/clang/AST/OpenMPClause.h| 40 +++
 clang/include/clang/AST/RecursiveASTVisitor.h |  5 +++
 .../clang/Basic/DiagnosticSemaKinds.td|  3 +-
 clang/include/clang/Sema/Sema.h   |  3 ++
 clang/lib/AST/OpenMPClause.cpp|  2 +
 clang/lib/AST/StmtProfile.cpp |  2 +
 clang/lib/CodeGen/CGStmtOpenMP.cpp|  3 ++
 clang/lib/Parse/ParseOpenMP.cpp   |  1 +
 clang/lib/Sema/SemaOpenMP.cpp | 35 +++-
 clang/lib/Sema/TreeTransform.h|  6 +++
 clang/lib/Serialization/ASTReader.cpp |  5 +++
 clang/lib/Serialization/ASTWriter.cpp |  2 +
 clang/test/OpenMP/atomic_ast_print.cpp|  8 
 clang/test/OpenMP/atomic_messages.cpp | 11 +
 clang/tools/libclang/CIndex.cpp   |  2 +
 llvm/include/llvm/Frontend/OpenMP/OMP.td  |  4 +-
 16 files changed, 129 insertions(+), 3 deletions(-)

diff --git a/clang/include/clang/AST/OpenMPClause.h 
b/clang/include/clang/AST/OpenMPClause.h
index 924ca189381ba..325a1baa44614 100644
--- a/clang/include/clang/AST/OpenMPClause.h
+++ b/clang/include/clang/AST/OpenMPClause.h
@@ -2513,6 +2513,46 @@ class OMPRelaxedClause final : public OMPClause {
   }
 };
 
+/// This represents 'weak' clause in the '#pragma omp atomic'
+/// directives.
+///
+/// \code
+/// #pragma omp atomic compare weak
+/// \endcode
+/// In this example directive '#pragma omp atomic' has 'weak' clause.
+class OMPWeakClause final : public OMPClause {
+public:
+  /// Build 'weak' clause.
+  ///
+  /// \param StartLoc Starting location of the clause.
+  /// \param EndLoc Ending location of the clause.
+  OMPWeakClause(SourceLocation StartLoc, SourceLocation EndLoc)
+  : OMPClause(llvm::omp::OMPC_weak, StartLoc, EndLoc) {}
+
+  /// Build an empty clause.
+  OMPWeakClause()
+  : OMPClause(llvm::omp::OMPC_weak, SourceLocation(), SourceLocation()) {}
+
+  child_range children() {
+return child_range(child_iterator(), child_iterator());
+  }
+
+  const_child_range children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
+
+  child_range used_children() {
+return child_range(child_iterator(), child_iterator());
+  }
+  const_child_range used_children() const {
+return const_child_range(const_child_iterator(), const_child_iterator());
+  }
+
+  static bool classof(const OMPClause *T) {
+return T->getClauseKind() == llvm::omp::OMPC_weak;
+  }
+};
+
 /// This represents 'fail' clause in the '#pragma omp atomic'
 /// directive.
 ///
diff --git a/clang/include/clang/AST/RecursiveASTVisitor.h 
b/clang/include/clang/AST/RecursiveASTVisitor.h
index 8f2714e142bbe..0fbf3e30e2d8d 100644
--- a/clang/include/clang/AST/RecursiveASTVisitor.h
+++ b/clang/include/clang/AST/RecursiveASTVisitor.h
@@ -3423,6 +3423,11 @@ bool 
RecursiveASTVisitor::VisitOMPRelaxedClause(OMPRelaxedClause *) {
   return true;
 }
 
+template 
+bool RecursiveASTVisitor::VisitOMPWeakClause(OMPWeakClause *) {
+  return true;
+}
+
 template 
 bool RecursiveASTVisitor::VisitOMPThreadsClause(OMPThreadsClause *) {
   return true;
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index a97182cad5d51..42fa19e0424fb 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -10996,7 +10996,8 @@ def note_omp_atomic_compare: Note<
   "expect lvalue for result value|expect scalar value|expect integer 
value|unexpected 'else' statement|expect '==' operator|expect an assignment 
statement 'v = x'|"
   "expect a 'if' statement|expect no more than two statements|expect a 
compound statement|expe

[Lldb-commits] [clang-tools-extra] [clang] [lldb] [c++20] P1907R1: Support for generalized non-type template arguments of scalar type. (PR #78041)

[Andrey Ali Khan Bolshakov via lldb-commits]

bolshakov-a wrote:

@eaeltsin, could you try out [that 
branch](https://github.com/bolshakov-a/llvm-project/tree/avoid_regressions)?

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

[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

[Felipe de Azevedo Piovezan via lldb-commits]

@@ -218,6 +219,104 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
   m_fallback.GetCompleteObjCClass(class_name, must_be_implementation, 
callback);
 }
 
+namespace {
+using Entry = llvm::DWARFDebugNames::Entry;
+
+/// If `entry` and all of its parents have an `IDX_parent`, use that 
information
+/// to build and return a list of at most `max_parents` parent Entries.
+/// `entry` itself is not included in the list.
+/// If any parent does not have an `IDX_parent`, or the Entry data is 
corrupted,
+/// nullopt is returned.
+static std::optional>

felipepiovezan wrote:

Ooops.
Errr let me ask the specialist:
https://github.com/llvm/llvm-project/assets/5406686/db92ada8-4b45-4d6f-8a5f-9df9889169c3";>


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

[Lldb-commits] [flang] [mlir] [libunwind] [libcxx] [compiler-rt] [clang] [openmp] [llvm] [lld] [libcxxabi] [lldb] [clang-tools-extra] [libc] [clang] static operators should evaluate object argument (P

[Erich Keane via lldb-commits]

erichkeane wrote:

I have absolutely no idea how to fix it as I don't understand the syntax of the 
clangd tests, but it SEEMS like it is just a source-location type thing that is 
wrong?

https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/clangd/unittests/InlayHintTests.cpp#L810

>From my read of the test output, it is 'l2' on line 831 (which is line 20 of 
>the test best i can tell?) where the 'suggestion' is chars 6-8 instead of 9-10.

I have no idea what any of that means however, so hopefully someone can stop by 
and help out @SuperSodaSea .

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

[Lldb-commits] [libcxx] [flang] [clang-tools-extra] [compiler-rt] [mlir] [llvm] [lldb] [libc] [clang] [AArch64] add intrinsic to generate a bfi instruction (PR #79672)

[Dawei Pan via lldb-commits]

dwpan wrote:

> Hello. Can you explain why this is needed, as opposed to using the equivalent 
> shift/and/ors?

In Verilog/SystemVerilog language, the basic type is bit or bit vector, and 
length is arbitrary, insert/extract bits are common features in language. 
Introducing corresponding intrinsics could help gradually lower it and bring 
more optimization opportunities in llc.   Otherwise, many shift/and/or are 
needed to be translated and then depends on code pattern matching to recognize 
and optimize them. 

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

[Lldb-commits] [libc] [lldb] [libcxxabi] [llvm] [lld] [libcxx] [clang] [flang] [msan] Unpoison indirect outputs for userspace using llvm.memset.* (PR #79924)

[Fangrui Song via lldb-commits]

https://github.com/MaskRay edited 
https://github.com/llvm/llvm-project/pull/79924
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [flang] [libcxx] [clang] [llvm] [lld] [libcxxabi] [lldb] [libc] [msan] Unpoison indirect outputs for userspace using llvm.memset.* (PR #79924)

[Fangrui Song via lldb-commits]

https://github.com/MaskRay updated 
https://github.com/llvm/llvm-project/pull/79924

>From 07043d27155ffd89e23b64c77a99880b2fa57e57 Mon Sep 17 00:00:00 2001
From: Fangrui Song 
Date: Mon, 29 Jan 2024 17:02:18 -0800
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
 =?UTF-8?q?l=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Created using spr 1.3.4
---
 .../Instrumentation/MemorySanitizer.cpp  |  5 -
 .../MemorySanitizer/msan_asm_conservative.ll | 16 
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp 
b/llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
index 2b697557d8a92..0806d7a5b1452 100644
--- a/llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
+++ b/llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
@@ -4559,9 +4559,12 @@ struct MemorySanitizerVisitor : public 
InstVisitor {
 } else {
   // ElemTy, derived from elementtype(), does not encode the alignment of
   // the pointer. Conservatively assume that the shadow memory is 
unaligned.
+  // Avoid StoreInst as SizeVal may be large, expanding to many
+  // instructions.
   auto [ShadowPtr, _] =
   getShadowOriginPtrUserspace(Operand, IRB, IRB.getInt8Ty(), Align(1));
-  IRB.CreateAlignedStore(getCleanShadow(ElemTy), ShadowPtr, Align(1));
+  IRB.CreateMemSet(ShadowPtr, ConstantInt::getNullValue(IRB.getInt8Ty()),
+   SizeVal, Align(1));
 }
   }
 
diff --git a/llvm/test/Instrumentation/MemorySanitizer/msan_asm_conservative.ll 
b/llvm/test/Instrumentation/MemorySanitizer/msan_asm_conservative.ll
index 894f76b9b8d32..86ca697ed9a4c 100644
--- a/llvm/test/Instrumentation/MemorySanitizer/msan_asm_conservative.ll
+++ b/llvm/test/Instrumentation/MemorySanitizer/msan_asm_conservative.ll
@@ -177,8 +177,8 @@ entry:
 }
 
 ; CHECK-LABEL: @f_2i_2o_mem
-; USER-CONS:  store i32 0, ptr inttoptr (i64 xor (i64 ptrtoint (ptr @id1 to 
i64), i64 87960930222080) to ptr), align 1
-; USER-CONS:  store i32 0, ptr inttoptr (i64 xor (i64 ptrtoint (ptr @id2 to 
i64), i64 87960930222080) to ptr), align 1
+; USER-CONS:  call void @llvm.memset.p0.i64(ptr align 1 inttoptr (i64 xor (i64 
ptrtoint (ptr @id1 to i64), i64 87960930222080) to ptr), i8 0, i64 4, i1 false)
+; USER-CONS:  call void @llvm.memset.p0.i64(ptr align 1 inttoptr (i64 xor (i64 
ptrtoint (ptr @id2 to i64), i64 87960930222080) to ptr), i8 0, i64 4, i1 false)
 ; CHECK-CONS: call void @__msan_instrument_asm_store({{.*}}@id1{{.*}}, i64 4)
 ; CHECK-CONS: call void @__msan_instrument_asm_store({{.*}}@id2{{.*}}, i64 4)
 ; CHECK: call void asm "", "=*m,=*m,*m,*m,~{dirflag},~{fpsr},~{flags}"(ptr 
elementtype(i32) @id1, ptr elementtype(i32) @id2, ptr elementtype(i32) @is1, 
ptr elementtype(i32) @is2)
@@ -196,7 +196,7 @@ entry:
 
 ; CHECK-LABEL: @f_1i_1o_memreg
 ; CHECK: [[IS1_F7:%.*]] = load i32, ptr @is1, align 4
-; USER-CONS:  store i32 0, ptr inttoptr (i64 xor (i64 ptrtoint (ptr @id1 to 
i64), i64 87960930222080) to ptr), align 1
+; USER-CONS:  call void @llvm.memset.p0.i64(ptr align 1 inttoptr (i64 xor (i64 
ptrtoint (ptr @id1 to i64), i64 87960930222080) to ptr), i8 0, i64 4, i1 false)
 ; CHECK-CONS: call void @__msan_instrument_asm_store({{.*}}@id1{{.*}}, i64 4)
 ; CHECK: call void @__msan_warning
 ; CHECK: call i32 asm "", "=r,=*m,r,*m,~{dirflag},~{fpsr},~{flags}"(ptr 
elementtype(i32) @id1, i32 [[IS1_F7]], ptr elementtype(i32) @is1)
@@ -215,7 +215,7 @@ entry:
 }
 
 ; CHECK-LABEL: @f_3o_reg_mem_reg
-; USER-CONS:  store i32 0, ptr inttoptr (i64 xor (i64 ptrtoint (ptr @id2 to 
i64), i64 87960930222080) to ptr), align 1
+; USER-CONS:  call void @llvm.memset.p0.i64(ptr align 1 inttoptr (i64 xor (i64 
ptrtoint (ptr @id2 to i64), i64 87960930222080) to ptr), i8 0, i64 4, i1 false)
 ; CHECK-CONS: call void @__msan_instrument_asm_store(ptr @id2, i64 4)
 ; CHECK: call { i32, i32 } asm "", "=r,=*m,=r,~{dirflag},~{fpsr},~{flags}"(ptr 
elementtype(i32) @id2)
 
@@ -240,7 +240,7 @@ entry:
 ; CHECK: [[PAIR1_F9:%.*]] = load {{.*}} @pair1
 ; CHECK: [[C1_F9:%.*]] = load {{.*}} @c1
 ; CHECK: [[MEMCPY_S1_F9:%.*]] = load {{.*}} @memcpy_s1
-; USER-CONS:  store { i32, i32 } zeroinitializer, ptr inttoptr (i64 xor (i64 
ptrtoint (ptr @pair2 to i64), i64 87960930222080) to ptr), align 1
+; USER-CONS:  call void @llvm.memset.p0.i64(ptr align 1 inttoptr (i64 xor (i64 
ptrtoint (ptr @pair2 to i64), i64 87960930222080) to ptr), i8 0, i64 8, i1 
false)
 ; CHECK-CONS: call void @__msan_instrument_asm_store({{.*}}@pair2{{.*}}, i64 8)
 ; CHECK: call void @__msan_warning
 ; KMSAN: call void @__msan_warning
@@ -257,9 +257,9 @@ entry:
 }
 
 ; CHECK-LABEL: @f_3i_3o_complex_mem
-; USER-CONS:   store { i32, i32 } zeroinitializer, ptr inttoptr (i64 xor 
(i64 ptrtoint (ptr @pair2 to i64), i64 87960930222080) to ptr), align 1
-; USER-CONS-NEXT:  store i8 0, ptr inttoptr (i64 xor (i64 ptrtoint (ptr @c2 

[Lldb-commits] [flang] [libcxx] [clang] [llvm] [lld] [libcxxabi] [lldb] [libc] [msan] Unpoison indirect outputs for userspace using llvm.memset.* (PR #79924)

[Fangrui Song via lldb-commits]

MaskRay wrote:

> LGTM in general.
> 
> But the downside here is that the compiler won't be able to optimize away 
> repeated stores if they are transformed to memset calls. Maybe introduce some 
> threshold and only memset() sizes greater than, say, 64? (IIRC that's what 
> `-ftrivial-auto-var-init` does)

TIL. Changed to keep using StoreInst when size <= 32, similar to 
`shouldUseBZeroPlusStoresToInitialize` `-ftrivial-auto-var-init`)

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

[Lldb-commits] [flang] [libcxx] [clang] [llvm] [lld] [libcxxabi] [lldb] [libc] [msan] Unpoison indirect outputs for userspace using llvm.memset.* (PR #79924)

[Fangrui Song via lldb-commits]

https://github.com/MaskRay updated 
https://github.com/llvm/llvm-project/pull/79924

>From 07043d27155ffd89e23b64c77a99880b2fa57e57 Mon Sep 17 00:00:00 2001
From: Fangrui Song 
Date: Mon, 29 Jan 2024 17:02:18 -0800
Subject: [PATCH 1/2] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=
 =?UTF-8?q?itial=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Created using spr 1.3.4
---
 .../Instrumentation/MemorySanitizer.cpp  |  5 -
 .../MemorySanitizer/msan_asm_conservative.ll | 16 
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp 
b/llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
index 2b697557d8a9..0806d7a5b145 100644
--- a/llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
+++ b/llvm/lib/Transforms/Instrumentation/MemorySanitizer.cpp
@@ -4559,9 +4559,12 @@ struct MemorySanitizerVisitor : public 
InstVisitor {
 } else {
   // ElemTy, derived from elementtype(), does not encode the alignment of
   // the pointer. Conservatively assume that the shadow memory is 
unaligned.
+  // Avoid StoreInst as SizeVal may be large, expanding to many
+  // instructions.
   auto [ShadowPtr, _] =
   getShadowOriginPtrUserspace(Operand, IRB, IRB.getInt8Ty(), Align(1));
-  IRB.CreateAlignedStore(getCleanShadow(ElemTy), ShadowPtr, Align(1));
+  IRB.CreateMemSet(ShadowPtr, ConstantInt::getNullValue(IRB.getInt8Ty()),
+   SizeVal, Align(1));
 }
   }
 
diff --git a/llvm/test/Instrumentation/MemorySanitizer/msan_asm_conservative.ll 
b/llvm/test/Instrumentation/MemorySanitizer/msan_asm_conservative.ll
index 894f76b9b8d3..86ca697ed9a4 100644
--- a/llvm/test/Instrumentation/MemorySanitizer/msan_asm_conservative.ll
+++ b/llvm/test/Instrumentation/MemorySanitizer/msan_asm_conservative.ll
@@ -177,8 +177,8 @@ entry:
 }
 
 ; CHECK-LABEL: @f_2i_2o_mem
-; USER-CONS:  store i32 0, ptr inttoptr (i64 xor (i64 ptrtoint (ptr @id1 to 
i64), i64 87960930222080) to ptr), align 1
-; USER-CONS:  store i32 0, ptr inttoptr (i64 xor (i64 ptrtoint (ptr @id2 to 
i64), i64 87960930222080) to ptr), align 1
+; USER-CONS:  call void @llvm.memset.p0.i64(ptr align 1 inttoptr (i64 xor (i64 
ptrtoint (ptr @id1 to i64), i64 87960930222080) to ptr), i8 0, i64 4, i1 false)
+; USER-CONS:  call void @llvm.memset.p0.i64(ptr align 1 inttoptr (i64 xor (i64 
ptrtoint (ptr @id2 to i64), i64 87960930222080) to ptr), i8 0, i64 4, i1 false)
 ; CHECK-CONS: call void @__msan_instrument_asm_store({{.*}}@id1{{.*}}, i64 4)
 ; CHECK-CONS: call void @__msan_instrument_asm_store({{.*}}@id2{{.*}}, i64 4)
 ; CHECK: call void asm "", "=*m,=*m,*m,*m,~{dirflag},~{fpsr},~{flags}"(ptr 
elementtype(i32) @id1, ptr elementtype(i32) @id2, ptr elementtype(i32) @is1, 
ptr elementtype(i32) @is2)
@@ -196,7 +196,7 @@ entry:
 
 ; CHECK-LABEL: @f_1i_1o_memreg
 ; CHECK: [[IS1_F7:%.*]] = load i32, ptr @is1, align 4
-; USER-CONS:  store i32 0, ptr inttoptr (i64 xor (i64 ptrtoint (ptr @id1 to 
i64), i64 87960930222080) to ptr), align 1
+; USER-CONS:  call void @llvm.memset.p0.i64(ptr align 1 inttoptr (i64 xor (i64 
ptrtoint (ptr @id1 to i64), i64 87960930222080) to ptr), i8 0, i64 4, i1 false)
 ; CHECK-CONS: call void @__msan_instrument_asm_store({{.*}}@id1{{.*}}, i64 4)
 ; CHECK: call void @__msan_warning
 ; CHECK: call i32 asm "", "=r,=*m,r,*m,~{dirflag},~{fpsr},~{flags}"(ptr 
elementtype(i32) @id1, i32 [[IS1_F7]], ptr elementtype(i32) @is1)
@@ -215,7 +215,7 @@ entry:
 }
 
 ; CHECK-LABEL: @f_3o_reg_mem_reg
-; USER-CONS:  store i32 0, ptr inttoptr (i64 xor (i64 ptrtoint (ptr @id2 to 
i64), i64 87960930222080) to ptr), align 1
+; USER-CONS:  call void @llvm.memset.p0.i64(ptr align 1 inttoptr (i64 xor (i64 
ptrtoint (ptr @id2 to i64), i64 87960930222080) to ptr), i8 0, i64 4, i1 false)
 ; CHECK-CONS: call void @__msan_instrument_asm_store(ptr @id2, i64 4)
 ; CHECK: call { i32, i32 } asm "", "=r,=*m,=r,~{dirflag},~{fpsr},~{flags}"(ptr 
elementtype(i32) @id2)
 
@@ -240,7 +240,7 @@ entry:
 ; CHECK: [[PAIR1_F9:%.*]] = load {{.*}} @pair1
 ; CHECK: [[C1_F9:%.*]] = load {{.*}} @c1
 ; CHECK: [[MEMCPY_S1_F9:%.*]] = load {{.*}} @memcpy_s1
-; USER-CONS:  store { i32, i32 } zeroinitializer, ptr inttoptr (i64 xor (i64 
ptrtoint (ptr @pair2 to i64), i64 87960930222080) to ptr), align 1
+; USER-CONS:  call void @llvm.memset.p0.i64(ptr align 1 inttoptr (i64 xor (i64 
ptrtoint (ptr @pair2 to i64), i64 87960930222080) to ptr), i8 0, i64 8, i1 
false)
 ; CHECK-CONS: call void @__msan_instrument_asm_store({{.*}}@pair2{{.*}}, i64 8)
 ; CHECK: call void @__msan_warning
 ; KMSAN: call void @__msan_warning
@@ -257,9 +257,9 @@ entry:
 }
 
 ; CHECK-LABEL: @f_3i_3o_complex_mem
-; USER-CONS:   store { i32, i32 } zeroinitializer, ptr inttoptr (i64 xor 
(i64 ptrtoint (ptr @pair2 to i64), i64 87960930222080) to ptr), align 1
-; USER-CONS-NEXT:  store i8 0, ptr inttoptr (i64 xor (i64 ptrtoint (ptr @c2 

[Lldb-commits] [flang] [compiler-rt] [mlir] [lldb] [openmp] [lld] [libunwind] [libcxx] [libcxxabi] [llvm] [clang] [clang-tools-extra] [libc] [clang] static operators should evaluate object argument (P

[Tianlan Zhou via lldb-commits]

SuperSodaSea wrote:

It seems that clangd doesn't like the new usage for the static operator of the 
CXXOperatorCallExpr, so the hint is misplaced. I'm looking into 
**clang-tools-extra/clangd/InlayHints.cpp** now...

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

[Lldb-commits] [libunwind] [compiler-rt] [libcxx] [clang-tools-extra] [libcxxabi] [libc] [lld] [openmp] [mlir] [flang] [llvm] [clang] [lldb] [clang] static operators should evaluate object argument (P

[Aaron Ballman via lldb-commits]

AaronBallman wrote:

CC @zyn0217 as the original author of that test case and @HighCommander4 as the 
original reviewer.

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

[Lldb-commits] [lldb] [lldb][progress] Correctly check total for deterministic progress (PR #79912)

[Chelsea Cassanova via lldb-commits]

https://github.com/chelcassanova updated 
https://github.com/llvm/llvm-project/pull/79912

>From af9a5581702b5c9ca8009fc32c7ae10a1654d391 Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova 
Date: Mon, 29 Jan 2024 15:29:46 -0800
Subject: [PATCH 1/2] [lldb][progress] Correctly check total for deterministic
 progress

The `total` parameter for the constructor for Progress was changed to a
std::optional in https://github.com/llvm/llvm-project/pull/77547. When
initializing the `m_total` member variable for progress, it is set to 1
if the `total` parameter is std::nullopt. Other areas of the code were
still checking if `m_total` was a UINT64_MAX to determine if the
progress was deterministic or not, so these have been changed to check
for the integer 1.

The member variable `m_total` could be changed to a std::optional as
well, but this means that the `ProgressEventData::GetTotal()` (which is
used for the public API) would
either need to return a std::optional value or it would return some
specific integer to represent non-deterministic progress if `m_total`
is std::nullopt.
---
 lldb/include/lldb/Core/DebuggerEvents.h | 2 +-
 lldb/source/Core/DebuggerEvents.cpp | 2 +-
 lldb/source/Core/Progress.cpp   | 1 -
 3 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/lldb/include/lldb/Core/DebuggerEvents.h 
b/lldb/include/lldb/Core/DebuggerEvents.h
index 4a27766e94e3a..2c3fcd7069d5e 100644
--- a/lldb/include/lldb/Core/DebuggerEvents.h
+++ b/lldb/include/lldb/Core/DebuggerEvents.h
@@ -39,7 +39,7 @@ class ProgressEventData : public EventData {
   GetAsStructuredData(const Event *event_ptr);
 
   uint64_t GetID() const { return m_id; }
-  bool IsFinite() const { return m_total != UINT64_MAX; }
+  bool IsFinite() const { return m_total != 1; }
   uint64_t GetCompleted() const { return m_completed; }
   uint64_t GetTotal() const { return m_total; }
   std::string GetMessage() const {
diff --git a/lldb/source/Core/DebuggerEvents.cpp 
b/lldb/source/Core/DebuggerEvents.cpp
index dd77fff349a64..c83bc20fba97a 100644
--- a/lldb/source/Core/DebuggerEvents.cpp
+++ b/lldb/source/Core/DebuggerEvents.cpp
@@ -41,7 +41,7 @@ void ProgressEventData::Dump(Stream *s) const {
 s->PutCString(", type = update");
   // If m_total is UINT64_MAX, there is no progress to report, just "start"
   // and "end". If it isn't we will show the completed and total amounts.
-  if (m_total != UINT64_MAX)
+  if (m_total != 1)
 s->Printf(", progress = %" PRIu64 " of %" PRIu64, m_completed, m_total);
 }
 
diff --git a/lldb/source/Core/Progress.cpp b/lldb/source/Core/Progress.cpp
index 355d6952e53ca..411a27fbf7e99 100644
--- a/lldb/source/Core/Progress.cpp
+++ b/lldb/source/Core/Progress.cpp
@@ -23,7 +23,6 @@ Progress::Progress(std::string title, std::string details,
lldb_private::Debugger *debugger)
 : m_title(title), m_details(details), m_id(++g_id), m_completed(0),
   m_total(1) {
-  assert(total == std::nullopt || total > 0);
   if (total)
 m_total = *total;
 

>From 466836d9f8c462ea1f9f81744a76f90b06dcca2b Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova 
Date: Tue, 30 Jan 2024 11:18:10 -0800
Subject: [PATCH 2/2] Use UINT64_MAX, use static class var instead of magic
 number

Uses a static class member set to UINT64_MAX instead of using a magic
number of 1 to represent non-deterministic progress.
---
 lldb/include/lldb/Core/DebuggerEvents.h | 3 ++-
 lldb/include/lldb/Core/Progress.h   | 3 +++
 lldb/source/Core/DebuggerEvents.cpp | 3 ++-
 lldb/source/Core/Progress.cpp   | 2 +-
 4 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/lldb/include/lldb/Core/DebuggerEvents.h 
b/lldb/include/lldb/Core/DebuggerEvents.h
index 2c3fcd7069d5e..74bb05e6e6bf8 100644
--- a/lldb/include/lldb/Core/DebuggerEvents.h
+++ b/lldb/include/lldb/Core/DebuggerEvents.h
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "lldb/Core/ModuleSpec.h"
+#include "lldb/Core/Progress.h"
 #include "lldb/Utility/Event.h"
 #include "lldb/Utility/StructuredData.h"
 
@@ -39,7 +40,7 @@ class ProgressEventData : public EventData {
   GetAsStructuredData(const Event *event_ptr);
 
   uint64_t GetID() const { return m_id; }
-  bool IsFinite() const { return m_total != 1; }
+  bool IsFinite() const { return m_total != Progress::kNonDeterministicTotal; }
   uint64_t GetCompleted() const { return m_completed; }
   uint64_t GetTotal() const { return m_total; }
   std::string GetMessage() const {
diff --git a/lldb/include/lldb/Core/Progress.h 
b/lldb/include/lldb/Core/Progress.h
index 65d30ea25cd29..5d88291024605 100644
--- a/lldb/include/lldb/Core/Progress.h
+++ b/lldb/include/lldb/Core/Progress.h
@@ -93,6 +93,9 @@ class Progress {
   void Increment(uint64_t amount = 1,
  std::optional updated_detail = {});
 
+  /// Used to indicate a non-deterministic progress report
+  static constexpr uint64_t kNonDeterministicTotal = UINT64_MAX;
+
 private:
   

[Lldb-commits] [lldb] [lldb][progress] Correctly check total for deterministic progress (PR #79912)

[Chelsea Cassanova via lldb-commits]

@@ -39,7 +39,7 @@ class ProgressEventData : public EventData {
   GetAsStructuredData(const Event *event_ptr);
 
   uint64_t GetID() const { return m_id; }
-  bool IsFinite() const { return m_total != UINT64_MAX; }
+  bool IsFinite() const { return m_total != 1; }

chelcassanova wrote:

I added your suggestions to the PR, no longer using a magic number or the 
number 1 to represent non-deterministic progress

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

[Lldb-commits] [lldb] [lldb][progress][NFC] Add unit test for progress reports (PR #79533)

[Chelsea Cassanova via lldb-commits]

@@ -0,0 +1,125 @@
+//===-- ProgressReportTest.cpp 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "Plugins/Platform/MacOSX/PlatformMacOSX.h"
+#include "Plugins/Platform/MacOSX/PlatformRemoteMacOSX.h"
+#include "TestingSupport/SubsystemRAII.h"
+#include "lldb/Core/Debugger.h"
+#include "lldb/Core/Progress.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Utility/Listener.h"
+#include "gtest/gtest.h"
+#include 
+
+using namespace lldb;
+using namespace lldb_private;
+
+class ProgressReportTest : public ::testing::Test {
+SubsystemRAII subsystems;
+
+// The debugger's initialization function can't be called with no arguments
+// so calling it using SubsystemRAII will cause the test build to fail as
+// SubsystemRAII will call Initialize with no arguments. As such we set it 
up
+// here the usual way.
+void SetUp() override { Debugger::Initialize(nullptr); }
+void TearDown() override { Debugger::Terminate(); }
+};
+
+TEST_F(ProgressReportTest, TestReportCreation) {
+  std::chrono::milliseconds timeout(100);
+  const unsigned long long NO_TOTAL = 1;

chelcassanova wrote:

I can use the changes from https://github.com/llvm/llvm-project/pull/79912 in 
here for checking the total progress.

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

[Lldb-commits] [llvm] [clang-tools-extra] [libc] [compiler-rt] [flang] [libcxx] [openmp] [clang] [libcxxabi] [lldb] [libunwind] [lld] [mlir] [clang] static operators should evaluate object argument (P

[Tianlan Zhou via lldb-commits]

SuperSodaSea wrote:

https://github.com/SuperSodaSea/llvm-project/blob/1ceaae47b2b43fd8fa5512e20e0b32a7e8f4ab5b/clang-tools-extra/clangd/InlayHints.cpp#L660-L664

```diff
  if (const CXXMethodDecl *Method =
  dyn_cast_or_null(Callee.Decl))
-   if (Method->isInstance() &&
-   (IsFunctor || Method->hasCXXExplicitFunctionObjectParameter()))
+   if (IsFunctor || (Method->isInstance() &&
+ Method->hasCXXExplicitFunctionObjectParameter()))
  Args = Args.drop_front(1);
```

Here is the code need to be modified (`!Method->isInstance() && IsFunctor` also 
need to drop the first argument). Passed `check-clangd` on my own build.

Commit: dea08ecc0d9caf47f7e9bdac113844b8b2bfb68e

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

[Lldb-commits] [llvm] [clang-tools-extra] [libc] [compiler-rt] [flang] [libcxx] [openmp] [clang] [libcxxabi] [lldb] [libunwind] [lld] [mlir] [clang] static operators should evaluate object argument (P

[Tianlan Zhou via lldb-commits]

SuperSodaSea wrote:

By the way, maybe we should add a clangd label to this PR?

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

[Lldb-commits] [lldb] [lldb][progress] Correctly check total for deterministic progress (PR #79912)

[Greg Clayton via lldb-commits]

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

Looks good!

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

[Lldb-commits] [lldb] [lldb][test] Switch LLDB API tests from vendored unittest2 to unittest (PR #79945)

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

I ran the test suite locally (macOS on arm64) and `TestRequireHWBreakpoints.py` 
is the only regression I found, but that's covered by the other PR. I'm happy 
to go ahead with landing both PRs and fixing the bots if there's fallout. 

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

[Lldb-commits] [lldb] [lldb][test] Switch LLDB API tests from vendored unittest2 to unittest (PR #79945)

[Jonas Devlieghere via lldb-commits]

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


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

[Lldb-commits] [clang] [clang-tools-extra] [lldb] [c++20] P1907R1: Support for generalized non-type template arguments of scalar type. (PR #78041)

[via lldb-commits]

eaeltsin wrote:

> @eaeltsin, could you try out [that 
> branch](https://github.com/bolshakov-a/llvm-project/tree/avoid_regressions)?

@bolshakov-a yes, this patch makes the "undefined symbol" linker error go away. 

Will you proceed with submitting?



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

[Lldb-commits] [lldb] 733b86d - [lldb][progress] Correctly check total for deterministic progress (#79912)

[via lldb-commits]

Author: Chelsea Cassanova
Date: 2024-01-30T12:00:38-08:00
New Revision: 733b86d3ff8087f1e267c23eb315bb16e3c6c953

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

LOG: [lldb][progress] Correctly check total for deterministic progress (#79912)

The `total` parameter for the constructor for Progress was changed to a
std::optional in https://github.com/llvm/llvm-project/pull/77547. It was 
originally set to 1 to indicate non-determinisitic progress, but this commit 
changes this. First, `UINT64_MAX` will again be used for non-deterministic 
progress, and `Progress` now has a static variable set to this value so that we 
can use this instead of a magic number. 

The member variable `m_total` could be changed to a std::optional as
well, but this means that the `ProgressEventData::GetTotal()` (which is
used for the public API) would
either need to return a std::optional value or it would return some
specific integer to represent non-deterministic progress if `m_total` is
std::nullopt.

Added: 


Modified: 
lldb/include/lldb/Core/DebuggerEvents.h
lldb/include/lldb/Core/Progress.h
lldb/source/Core/DebuggerEvents.cpp
lldb/source/Core/Progress.cpp

Removed: 




diff  --git a/lldb/include/lldb/Core/DebuggerEvents.h 
b/lldb/include/lldb/Core/DebuggerEvents.h
index 4a27766e94e3a..74bb05e6e6bf8 100644
--- a/lldb/include/lldb/Core/DebuggerEvents.h
+++ b/lldb/include/lldb/Core/DebuggerEvents.h
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "lldb/Core/ModuleSpec.h"
+#include "lldb/Core/Progress.h"
 #include "lldb/Utility/Event.h"
 #include "lldb/Utility/StructuredData.h"
 
@@ -39,7 +40,7 @@ class ProgressEventData : public EventData {
   GetAsStructuredData(const Event *event_ptr);
 
   uint64_t GetID() const { return m_id; }
-  bool IsFinite() const { return m_total != UINT64_MAX; }
+  bool IsFinite() const { return m_total != Progress::kNonDeterministicTotal; }
   uint64_t GetCompleted() const { return m_completed; }
   uint64_t GetTotal() const { return m_total; }
   std::string GetMessage() const {

diff  --git a/lldb/include/lldb/Core/Progress.h 
b/lldb/include/lldb/Core/Progress.h
index 65d30ea25cd29..5d88291024605 100644
--- a/lldb/include/lldb/Core/Progress.h
+++ b/lldb/include/lldb/Core/Progress.h
@@ -93,6 +93,9 @@ class Progress {
   void Increment(uint64_t amount = 1,
  std::optional updated_detail = {});
 
+  /// Used to indicate a non-deterministic progress report
+  static constexpr uint64_t kNonDeterministicTotal = UINT64_MAX;
+
 private:
   void ReportProgress();
   static std::atomic g_id;

diff  --git a/lldb/source/Core/DebuggerEvents.cpp 
b/lldb/source/Core/DebuggerEvents.cpp
index dd77fff349a64..65aed0eba9c41 100644
--- a/lldb/source/Core/DebuggerEvents.cpp
+++ b/lldb/source/Core/DebuggerEvents.cpp
@@ -9,6 +9,7 @@
 #include "lldb/Core/DebuggerEvents.h"
 #include "lldb/Core/Debugger.h"
 #include "lldb/Core/Module.h"
+#include "lldb/Core/Progress.h"
 #include "llvm/Support/WithColor.h"
 
 using namespace lldb_private;
@@ -41,7 +42,7 @@ void ProgressEventData::Dump(Stream *s) const {
 s->PutCString(", type = update");
   // If m_total is UINT64_MAX, there is no progress to report, just "start"
   // and "end". If it isn't we will show the completed and total amounts.
-  if (m_total != UINT64_MAX)
+  if (m_total != Progress::kNonDeterministicTotal)
 s->Printf(", progress = %" PRIu64 " of %" PRIu64, m_completed, m_total);
 }
 

diff  --git a/lldb/source/Core/Progress.cpp b/lldb/source/Core/Progress.cpp
index 355d6952e53ca..732efbc342b45 100644
--- a/lldb/source/Core/Progress.cpp
+++ b/lldb/source/Core/Progress.cpp
@@ -22,8 +22,7 @@ Progress::Progress(std::string title, std::string details,
std::optional total,
lldb_private::Debugger *debugger)
 : m_title(title), m_details(details), m_id(++g_id), m_completed(0),
-  m_total(1) {
-  assert(total == std::nullopt || total > 0);
+  m_total(Progress::kNonDeterministicTotal) {
   if (total)
 m_total = *total;
 



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

[Lldb-commits] [lldb] [lldb][progress] Correctly check total for deterministic progress (PR #79912)

[Chelsea Cassanova via lldb-commits]

https://github.com/chelcassanova closed 
https://github.com/llvm/llvm-project/pull/79912
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [lldb] [clang-tools-extra] [c++20] P1907R1: Support for generalized non-type template arguments of scalar type. (PR #78041)

[Andrey Ali Khan Bolshakov via lldb-commits]

bolshakov-a wrote:

#80050 opened. Nevertheless, a reproducer for future work would be appreciated.

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

[Lldb-commits] [lldb] [lldb] Add support for large watchpoints in lldb (PR #79962)

[Alex Langford via lldb-commits]

@@ -0,0 +1,146 @@
+//===-- WatchpointAlgorithms.cpp 
--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/Breakpoint/WatchpointAlgorithms.h"
+#include "lldb/Breakpoint/WatchpointResource.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Utility/ArchSpec.h"
+
+#include 
+#include 
+
+using namespace lldb;
+using namespace lldb_private;
+
+std::vector
+WatchpointAlgorithms::AtomizeWatchpointRequest(
+addr_t addr, size_t size, bool read, bool write,
+WatchpointHardwareFeature supported_features, ArchSpec &arch) {
+
+  std::vector> entries;
+
+  if (supported_features &
+  WatchpointHardwareFeature::eWatchpointHardwareArmMASK) {
+entries =
+PowerOf2Watchpoints(addr, size,
+/* min_byte_size */ 1,
+/* max_byte_size */ 2147483648,

bulbazord wrote:

Is this just INT32_MAX? Probably better to use a constant for clarity.

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

[Lldb-commits] [lldb] [lldb] Add support for large watchpoints in lldb (PR #79962)

[Alex Langford via lldb-commits]

https://github.com/bulbazord commented:

I haven't looked at the algorithm in great detail yet but a lot of the 
surrounding stuff looks pretty reasonable I think. 

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

[Lldb-commits] [lldb] [lldb] Add support for large watchpoints in lldb (PR #79962)

[Alex Langford via lldb-commits]

@@ -0,0 +1,38 @@
+//===-- WatchpointAlgorithms.h *- C++

bulbazord wrote:

The header needs adjustment

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

[Lldb-commits] [lldb] [lldb] Add support for large watchpoints in lldb (PR #79962)

[Alex Langford via lldb-commits]

https://github.com/bulbazord edited 
https://github.com/llvm/llvm-project/pull/79962
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Add support for large watchpoints in lldb (PR #79962)

[Alex Langford via lldb-commits]

@@ -0,0 +1,38 @@
+//===-- WatchpointAlgorithms.h *- 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
+//
+//===--===//
+
+#ifndef LLDB_BREAKPOINT_WATCHPOINTALGORITHMS_H
+#define LLDB_BREAKPOINT_WATCHPOINTALGORITHMS_H
+
+#include "lldb/Breakpoint/WatchpointResource.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "lldb/lldb-public.h"
+
+#include 
+
+namespace lldb_private {
+
+class WatchpointAlgorithms {
+
+public:
+  static std::vector AtomizeWatchpointRequest(

bulbazord wrote:

Can you add some documentation for these static functions? In the form of 
doxygen comments preferrably

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

[Lldb-commits] [lldb] [lldb] Fix expressions that involve nested structs/classes/unions. (PR #77029)

[David Blaikie via lldb-commits]

dwblaikie wrote:

> > Thanks for the fix! I did test this patch with both our regression issue, 
> > and also allowing us to remove the double-lookup working around #53904 and 
> > can confirm it addressed both issues. Thanks again!
> 
> Glad it worked! It will also be a huge improvement in the expression parser 
> and avoid these weird expression parser bugs where it doesn't work sometimes 
> and does other times, so it was totally worth fixing. I am also glad to know 
> that the type lookups are being so much more efficient. Having a repro case 
> is always the best way to help us fix bugs, so thanks for posting the details 
> so we can repro easily.

Turns out it actually got worse, see 
https://github.com/llvm/llvm-project/issues/79668 - now whether or not a given 
nested type is accessible via name lookup depends on which copy of the outer 
type is loaded first & there's no workaround that I know of - the lookup then 
fails/succeeds permanently.

Be good to get this addressed - as now it's not possible to lookup these nested 
members at all reliably (even the "repeat the lookup" workaround doesn't work - 
maybe there are other workarounds? But none that I can think of)

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

[Lldb-commits] [libcxx] [llvm] [lld] [flang] [clang] [lldb] [libc] [libcxxabi] [msan] Unpoison indirect outputs for userspace using llvm.memset.* (PR #79924)

[Florian Mayer via lldb-commits]

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


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

[Lldb-commits] [lldb] [lldb][progress][NFC] Add unit test for progress reports (PR #79533)

[Chelsea Cassanova via lldb-commits]

https://github.com/chelcassanova updated 
https://github.com/llvm/llvm-project/pull/79533

>From 10343b6cdad410e09546dd5a98e29d272300ed2e Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova 
Date: Thu, 25 Jan 2024 16:40:42 -0800
Subject: [PATCH 1/4] [lldb][progress][NFC] Add unit test for progress reports

This test is being added as a way to check the behaviour of how progress
events are broadcasted when reports are started and ended with the
current implementation of progress reports. Here we're mainly checking
and ensuring that the current behaviour is that progress events are
broadcasted individually and placed in the event queue in order of
their creation.
---
 lldb/unittests/Core/CMakeLists.txt |   1 +
 lldb/unittests/Core/ProgressReportTest.cpp | 105 +
 2 files changed, 106 insertions(+)
 create mode 100644 lldb/unittests/Core/ProgressReportTest.cpp

diff --git a/lldb/unittests/Core/CMakeLists.txt 
b/lldb/unittests/Core/CMakeLists.txt
index b3cddd150635b..d40c357e3f463 100644
--- a/lldb/unittests/Core/CMakeLists.txt
+++ b/lldb/unittests/Core/CMakeLists.txt
@@ -7,6 +7,7 @@ add_lldb_unittest(LLDBCoreTests
   FormatEntityTest.cpp
   MangledTest.cpp
   ModuleSpecTest.cpp
+  ProgressReportTest.cpp
   RichManglingContextTest.cpp
   SourceLocationSpecTest.cpp
   SourceManagerTest.cpp
diff --git a/lldb/unittests/Core/ProgressReportTest.cpp 
b/lldb/unittests/Core/ProgressReportTest.cpp
new file mode 100644
index 0..bdc168c9e077d
--- /dev/null
+++ b/lldb/unittests/Core/ProgressReportTest.cpp
@@ -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/Utility/Listener.h"
+#include "gtest/gtest.h"
+#include 
+
+using namespace lldb;
+using namespace lldb_private;
+
+namespace {
+class ProgressReportTest : public ::testing::Test {
+public:
+  void SetUp() override {
+FileSystem::Initialize();
+HostInfo::Initialize();
+PlatformMacOSX::Initialize();
+Debugger::Initialize(nullptr);
+  }
+  void TearDown() override {
+Debugger::Terminate();
+PlatformMacOSX::Terminate();
+HostInfo::Terminate();
+FileSystem::Terminate();
+  }
+};
+} // namespace
+TEST_F(ProgressReportTest, TestReportCreation) {
+  std::chrono::milliseconds timeout(100);
+
+  // Set up the debugger, make sure that was done properly
+  ArchSpec arch("x86_64-apple-macosx-");
+  Platform::SetHostPlatform(PlatformRemoteMacOSX::CreateInstance(true, &arch));
+
+  DebuggerSP debugger_sp = Debugger::CreateInstance();
+  ASSERT_TRUE(debugger_sp);
+
+  // Get the debugger's broadcaster
+  Broadcaster &broadcaster = debugger_sp->GetBroadcaster();
+
+  // Create a listener, make sure it can receive events and that it's
+  // listening to the correct broadcast bit
+  ListenerSP listener_sp = Listener::MakeListener("progress-listener");
+
+  listener_sp->StartListeningForEvents(&broadcaster,
+   Debugger::eBroadcastBitProgress);
+  EXPECT_TRUE(
+  broadcaster.EventTypeHasListeners(Debugger::eBroadcastBitProgress));
+
+  EventSP event_sp;
+  const ProgressEventData *data;
+
+  // Scope this for RAII on the progress objects
+  // Create progress reports and check that their respective events for having
+  // started are broadcasted
+  {
+Progress progress1("Progress report 1", "Starting report 1");
+EXPECT_TRUE(listener_sp->GetEvent(event_sp, timeout));
+
+data = ProgressEventData::GetEventDataFromEvent(event_sp.get());
+ASSERT_EQ(data->GetDetails(), "Starting report 1");
+
+Progress progress2("Progress report 2", "Starting report 2");
+EXPECT_TRUE(listener_sp->GetEvent(event_sp, timeout));
+
+data = ProgressEventData::GetEventDataFromEvent(event_sp.get());
+ASSERT_EQ(data->GetDetails(), "Starting report 2");
+
+Progress progress3("Progress report 3", "Starting report 3");
+EXPECT_TRUE(listener_sp->GetEvent(event_sp, timeout));
+ASSERT_TRUE(event_sp);
+
+data = ProgressEventData::GetEventDataFromEvent(event_sp.get());
+ASSERT_EQ(data->GetDetails(), "Starting report 3");
+
+std::this_thread::sleep_for(timeout);
+  }
+
+  // Progress report objects should be destroyed at this point so
+  // get each report from the queue and check that they've been
+  // destroyed in reverse order
+  std::this_thread::sleep_for(timeout);
+  EXPECT_TRUE(listener_sp->GetEvent(event_sp, timeout));
+  data = ProgressEventData::GetEventDataFromEvent(event_sp.get());
+
+  ASSERT_EQ(data->GetTitle(), "Progress report 3");
+  ASSERT_TRUE(data->GetCompleted());
+
+  std::this_thread::sleep_for(timeout);
+  EXPECT_TRUE(listener_sp->GetEvent(event_sp, timeout));
+  data = ProgressEventData::GetEventDataFromEvent(event_sp.get());
+
+  ASSERT_EQ(data->GetTitle(), "Progress report 2");
+  ASSERT_TRUE(data->GetCompleted())

[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

[David Blaikie via lldb-commits]

@@ -0,0 +1,210 @@
+//===-- DWARFDIETest.cpp 
--=---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "Plugins/SymbolFile/DWARF/DWARFDIE.h"
+#include "Plugins/SymbolFile/DWARF/DWARFDebugInfo.h"
+#include "Plugins/SymbolFile/DWARF/DWARFDeclContext.h"
+#include "Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h"
+#include "TestingSupport/Symbol/YAMLModuleTester.h"
+#include "llvm/ADT/STLExtras.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+using namespace lldb;
+using namespace lldb_private;
+using namespace lldb_private::plugin::dwarf;
+using StringRef = llvm::StringRef;
+
+void check_num_matches(DebugNamesDWARFIndex &index, int expected_num_matches,
+   llvm::ArrayRef ctx_entries) {
+  DWARFDeclContext ctx(ctx_entries);
+  int num_matches = 0;
+  auto increment_matches = [&](DWARFDIE die) {
+num_matches++;
+return true;
+  };
+
+  index.GetFullyQualifiedType(ctx, increment_matches);
+  ASSERT_EQ(num_matches, expected_num_matches);
+}
+
+TEST(DWARFDebugNamesIndexTest, FullyQualifiedQueryWithIDXParent) {
+  const char *yamldata = R"(
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_EXEC
+  Machine: EM_386
+DWARF:
+  debug_str:
+- '1'
+- '2'
+- '3'
+  debug_abbrev:
+- Table:
+# We intentionally don't nest types in debug_info: if the nesting is 
not
+# inferred from debug_names, we want the test to fail.
+- Code:0x1
+  Tag: DW_TAG_compile_unit
+  Children:DW_CHILDREN_yes
+- Code:0x2
+  Tag: DW_TAG_class_type
+  Children:DW_CHILDREN_no
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+  debug_info:
+- Version: 4
+  AddrSize:8
+  Entries:
+- AbbrCode:0x1
+- AbbrCode:0x2
+  Values:
+- Value:   0x0 # Name "1"
+- AbbrCode:0x2
+  Values:
+- Value:   0x2 # Name "2"
+- AbbrCode:0x2
+  Values:
+- Value:   0x4 # Name "3"
+- AbbrCode:0x0
+  debug_names:
+Abbreviations:
+- Code:   0x11
+  Tag: DW_TAG_class_type
+  Indices:
+- Idx:   DW_IDX_parent
+  Form:  DW_FORM_flag_present
+- Idx:   DW_IDX_die_offset
+  Form:  DW_FORM_ref4
+- Code:   0x22
+  Tag: DW_TAG_class_type
+  Indices:
+- Idx:   DW_IDX_parent
+  Form:  DW_FORM_ref4
+- Idx:   DW_IDX_die_offset
+  Form:  DW_FORM_ref4
+Entries:
+- Name:   0x0  # strp to Name1
+  Code:   0x11
+  Values:
+- 0xc  # Die offset to entry named "1"
+- Name:   0x2  # strp to Name2
+  Code:   0x22
+  Values:
+- 0x0  # Parent = First entry ("1")
+- 0x11 # Die offset to entry named "1:2"
+- Name:   0x4  # strp to Name3
+  Code:   0x22
+  Values:
+- 0x6  # Parent = Second entry ("1::2")
+- 0x16 # Die offset to entry named "1::2::3"
+- Name:   0x4  # strp to Name3
+  Code:   0x11
+  Values:
+- 0x16 # Die offset to entry named "3"
+)";
+
+  YAMLModuleTester t(yamldata);
+  auto *symbol_file =
+  llvm::cast(t.GetModule()->GetSymbolFile());
+  auto *index = static_cast(symbol_file->getIndex());
+  ASSERT_NE(index, nullptr);
+
+  auto make_entry = [](const char *c) {
+return DWARFDeclContext::Entry(dwarf::DW_TAG_class_type, c);
+  };
+  check_num_matches(*index, 1, {make_entry("1")});
+  check_num_matches(*index, 1, {make_entry("2"), make_entry("1")});
+  check_num_matches(*index, 1,
+{make_entry("3"), make_entry("2"), make_entry("1")});
+  check_num_matches(*index, 0, {make_entry("2")});
+  check_num_matches(*index, 1, {make_entry("3")});
+}
+
+TEST(DWARFDebugNamesIndexTest, FullyQualifiedQueryWithoutIDXParent) {
+  const char *yamldata = R"(
+--- !ELF
+FileHeader:
+  Class:   ELFCLASS64
+  Data:ELFDATA2LSB
+  Type:ET_EXEC
+  Machine: EM_386
+DWARF:
+  debug_str:
+- '1'
+- '2'
+  debug_abbrev:
+- Table:
+- Code:0x1
+  Tag: DW_TAG_compile_unit
+  Children:DW_CHILDREN_yes
+- Code:0x2
+  Tag: DW_TAG_class_type
+  Children:DW_CHILDREN_yes
+  Attributes:
+- Attribute:   DW_AT_name
+  Form:DW_FORM_strp
+- Code:0x3
+  Tag: DW_TAG_class_type
+  Children:DW_CHILDREN_

[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

[David Blaikie via lldb-commits]

@@ -218,6 +219,104 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
   m_fallback.GetCompleteObjCClass(class_name, must_be_implementation, 
callback);
 }
 
+namespace {
+using Entry = llvm::DWARFDebugNames::Entry;
+
+/// If `entry` and all of its parents have an `IDX_parent`, use that 
information
+/// to build and return a list of at most `max_parents` parent Entries.
+/// `entry` itself is not included in the list.
+/// If any parent does not have an `IDX_parent`, or the Entry data is 
corrupted,
+/// nullopt is returned.
+static std::optional>
+getParentChain(Entry entry, uint32_t max_parents) {
+  llvm::SmallVector parent_entries;
+
+  do {
+if (!entry.hasParentInformation())
+  return std::nullopt;
+
+llvm::Expected> parent = entry.getParentDIEEntry();
+if (!parent) { // Bad data.
+  consumeError(parent.takeError());
+  return std::nullopt;
+}
+
+// Last parent in the chain
+if (!parent->has_value())
+  break;
+
+parent_entries.push_back(**parent);
+entry = **parent;
+  } while (parent_entries.size() < max_parents);
+
+  return parent_entries;
+}
+} // namespace
+
+void DebugNamesDWARFIndex::GetFullyQualifiedType(
+const DWARFDeclContext &context,
+llvm::function_ref callback) {
+  if (context.GetSize() == 0)
+return;
+
+  // Fallback: use the base class implementation.
+  auto fallback_impl = [&](const DebugNames::Entry &entry) {
+return ProcessEntry(entry, [&](DWARFDIE die) {
+  return GetFullyQualifiedTypeImpl(context, die, callback);
+});
+  };

dwblaikie wrote:

Not sure this is worth putting in a lambda? Might be simpler to write it inline 
in the one place it's used?

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

[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

[David Blaikie via lldb-commits]

@@ -218,6 +219,104 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
   m_fallback.GetCompleteObjCClass(class_name, must_be_implementation, 
callback);
 }
 
+namespace {
+using Entry = llvm::DWARFDebugNames::Entry;
+
+/// If `entry` and all of its parents have an `IDX_parent`, use that 
information
+/// to build and return a list of at most `max_parents` parent Entries.
+/// `entry` itself is not included in the list.
+/// If any parent does not have an `IDX_parent`, or the Entry data is 
corrupted,
+/// nullopt is returned.
+static std::optional>
+getParentChain(Entry entry, uint32_t max_parents) {
+  llvm::SmallVector parent_entries;
+
+  do {
+if (!entry.hasParentInformation())
+  return std::nullopt;
+
+llvm::Expected> parent = entry.getParentDIEEntry();
+if (!parent) { // Bad data.
+  consumeError(parent.takeError());
+  return std::nullopt;
+}
+
+// Last parent in the chain
+if (!parent->has_value())
+  break;
+
+parent_entries.push_back(**parent);
+entry = **parent;
+  } while (parent_entries.size() < max_parents);
+
+  return parent_entries;
+}
+} // namespace
+
+void DebugNamesDWARFIndex::GetFullyQualifiedType(
+const DWARFDeclContext &context,
+llvm::function_ref callback) {
+  if (context.GetSize() == 0)
+return;
+
+  // Fallback: use the base class implementation.
+  auto fallback_impl = [&](const DebugNames::Entry &entry) {
+return ProcessEntry(entry, [&](DWARFDIE die) {
+  return GetFullyQualifiedTypeImpl(context, die, callback);
+});
+  };
+
+  llvm::StringRef leaf_name = context[0].name;
+  llvm::SmallVector parent_names;
+  for (auto idx : llvm::seq(1, context.GetSize()))
+parent_names.emplace_back(context[idx].name);
+
+  for (const DebugNames::Entry &entry :
+   m_debug_names_up->equal_range(leaf_name)) {
+if (!isType(entry.tag()))
+  continue;
+
+// Grab at most one extra parent, subsequent parents are not necessary to
+// test equality.
+auto parent_chain = getParentChain(entry, parent_names.size() + 1);
+
+if (!parent_chain) {
+  if (!fallback_impl(entry))
+return;
+  continue;
+}
+
+if (SameParentChain(parent_names, *parent_chain) &&
+!ProcessEntry(entry, callback))
+  return;
+  }
+}
+
+bool DebugNamesDWARFIndex::SameParentChain(
+llvm::ArrayRef parent_names,
+llvm::ArrayRef parent_entries) const {
+
+  if (parent_entries.size() != parent_names.size())
+return false;
+
+  auto SameAsEntryATName = [this](llvm::StringRef name,
+  const DebugNames::Entry &entry) {
+auto maybe_dieoffset = entry.getDIEUnitOffset();
+if (!maybe_dieoffset)
+  return false;
+auto die_ref = ToDIERef(entry);
+if (!die_ref)
+  return false;
+return name == m_debug_info.PeekDIEName(*die_ref);
+  };
+

dwblaikie wrote:

Similarly, a lambda that's only called once doesn't seem to carry its weight - 
might be simpler to put it in the loop.

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

[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

[David Blaikie via lldb-commits]

@@ -0,0 +1,210 @@
+//===-- DWARFDIETest.cpp 
--=---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "Plugins/SymbolFile/DWARF/DWARFDIE.h"
+#include "Plugins/SymbolFile/DWARF/DWARFDebugInfo.h"
+#include "Plugins/SymbolFile/DWARF/DWARFDeclContext.h"
+#include "Plugins/SymbolFile/DWARF/DebugNamesDWARFIndex.h"
+#include "TestingSupport/Symbol/YAMLModuleTester.h"
+#include "llvm/ADT/STLExtras.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+using namespace lldb;
+using namespace lldb_private;
+using namespace lldb_private::plugin::dwarf;
+using StringRef = llvm::StringRef;
+
+void check_num_matches(DebugNamesDWARFIndex &index, int expected_num_matches,
+   llvm::ArrayRef ctx_entries) {
+  DWARFDeclContext ctx(ctx_entries);
+  int num_matches = 0;
+  auto increment_matches = [&](DWARFDIE die) {
+num_matches++;
+return true;
+  };
+
+  index.GetFullyQualifiedType(ctx, increment_matches);

dwblaikie wrote:

Probably inline the lambda at the call site?
```
index.GetFullyQualifiedType(ctx, [*](DWARFDIE die) {
  num_matches++;
  return true;
});
```

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

[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

[David Blaikie via lldb-commits]

@@ -218,6 +219,104 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
   m_fallback.GetCompleteObjCClass(class_name, must_be_implementation, 
callback);
 }
 
+namespace {
+using Entry = llvm::DWARFDebugNames::Entry;
+
+/// If `entry` and all of its parents have an `IDX_parent`, use that 
information
+/// to build and return a list of at most `max_parents` parent Entries.
+/// `entry` itself is not included in the list.
+/// If any parent does not have an `IDX_parent`, or the Entry data is 
corrupted,
+/// nullopt is returned.
+static std::optional>
+getParentChain(Entry entry, uint32_t max_parents) {
+  llvm::SmallVector parent_entries;
+
+  do {
+if (!entry.hasParentInformation())
+  return std::nullopt;
+
+llvm::Expected> parent = entry.getParentDIEEntry();
+if (!parent) { // Bad data.
+  consumeError(parent.takeError());
+  return std::nullopt;
+}
+
+// Last parent in the chain
+if (!parent->has_value())
+  break;
+
+parent_entries.push_back(**parent);
+entry = **parent;
+  } while (parent_entries.size() < max_parents);
+
+  return parent_entries;
+}
+} // namespace
+
+void DebugNamesDWARFIndex::GetFullyQualifiedType(
+const DWARFDeclContext &context,
+llvm::function_ref callback) {
+  if (context.GetSize() == 0)
+return;
+
+  // Fallback: use the base class implementation.
+  auto fallback_impl = [&](const DebugNames::Entry &entry) {
+return ProcessEntry(entry, [&](DWARFDIE die) {
+  return GetFullyQualifiedTypeImpl(context, die, callback);
+});
+  };
+
+  llvm::StringRef leaf_name = context[0].name;
+  llvm::SmallVector parent_names;
+  for (auto idx : llvm::seq(1, context.GetSize()))
+parent_names.emplace_back(context[idx].name);
+
+  for (const DebugNames::Entry &entry :
+   m_debug_names_up->equal_range(leaf_name)) {
+if (!isType(entry.tag()))
+  continue;
+
+// Grab at most one extra parent, subsequent parents are not necessary to
+// test equality.
+auto parent_chain = getParentChain(entry, parent_names.size() + 1);
+
+if (!parent_chain) {
+  if (!fallback_impl(entry))
+return;
+  continue;
+}
+
+if (SameParentChain(parent_names, *parent_chain) &&
+!ProcessEntry(entry, callback))
+  return;

dwblaikie wrote:

FWIW as-written does lean a bit towards the LLVM documented style ( 
https://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code
 ) - but I wouldn't be too fussed either way.

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

[Lldb-commits] [llvm] [lldb] [lld] [libc] [libcxx] [flang] [libcxxabi] [clang] [msan] Unpoison indirect outputs for userspace using llvm.memset.* (PR #79924)

[Vitaly Buka via lldb-commits]

@@ -4552,16 +4552,22 @@ struct MemorySanitizerVisitor : public 
InstVisitor {
 }
 if (!ElemTy->isSized())
   return;
-Value *SizeVal =
-  IRB.CreateTypeSize(MS.IntptrTy, DL.getTypeStoreSize(ElemTy));
+auto Size = DL.getTypeStoreSize(ElemTy);
+Value *SizeVal = IRB.CreateTypeSize(MS.IntptrTy, Size);
 if (MS.CompileKernel) {
   IRB.CreateCall(MS.MsanInstrumentAsmStoreFn, {Operand, SizeVal});
 } else {
   // ElemTy, derived from elementtype(), does not encode the alignment of
   // the pointer. Conservatively assume that the shadow memory is 
unaligned.
+  // When Size is large, avoid StoreInst as it would expand to many
+  // instructions.
   auto [ShadowPtr, _] =
   getShadowOriginPtrUserspace(Operand, IRB, IRB.getInt8Ty(), Align(1));
-  IRB.CreateAlignedStore(getCleanShadow(ElemTy), ShadowPtr, Align(1));
+  if (Size <= 32)
+IRB.CreateAlignedStore(getCleanShadow(ElemTy), ShadowPtr, Align(1));
+  else
+IRB.CreateMemSet(ShadowPtr, ConstantInt::getNullValue(IRB.getInt8Ty()),

vitalybuka wrote:

it will hit interceptor

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

[Lldb-commits] [lldb] [lldb][DWARFIndex] Use IDX_parent to implement GetFullyQualifiedType query (PR #79932)

[Felipe de Azevedo Piovezan via lldb-commits]

@@ -218,6 +219,104 @@ void DebugNamesDWARFIndex::GetCompleteObjCClass(
   m_fallback.GetCompleteObjCClass(class_name, must_be_implementation, 
callback);
 }
 
+namespace {
+using Entry = llvm::DWARFDebugNames::Entry;
+
+/// If `entry` and all of its parents have an `IDX_parent`, use that 
information
+/// to build and return a list of at most `max_parents` parent Entries.
+/// `entry` itself is not included in the list.
+/// If any parent does not have an `IDX_parent`, or the Entry data is 
corrupted,
+/// nullopt is returned.
+static std::optional>
+getParentChain(Entry entry, uint32_t max_parents) {
+  llvm::SmallVector parent_entries;
+
+  do {
+if (!entry.hasParentInformation())
+  return std::nullopt;
+
+llvm::Expected> parent = entry.getParentDIEEntry();
+if (!parent) { // Bad data.
+  consumeError(parent.takeError());
+  return std::nullopt;
+}
+
+// Last parent in the chain
+if (!parent->has_value())
+  break;
+
+parent_entries.push_back(**parent);
+entry = **parent;
+  } while (parent_entries.size() < max_parents);
+
+  return parent_entries;
+}
+} // namespace
+
+void DebugNamesDWARFIndex::GetFullyQualifiedType(
+const DWARFDeclContext &context,
+llvm::function_ref callback) {
+  if (context.GetSize() == 0)
+return;
+
+  // Fallback: use the base class implementation.
+  auto fallback_impl = [&](const DebugNames::Entry &entry) {
+return ProcessEntry(entry, [&](DWARFDIE die) {
+  return GetFullyQualifiedTypeImpl(context, die, callback);
+});
+  };
+
+  llvm::StringRef leaf_name = context[0].name;
+  llvm::SmallVector parent_names;
+  for (auto idx : llvm::seq(1, context.GetSize()))
+parent_names.emplace_back(context[idx].name);
+
+  for (const DebugNames::Entry &entry :
+   m_debug_names_up->equal_range(leaf_name)) {
+if (!isType(entry.tag()))
+  continue;
+
+// Grab at most one extra parent, subsequent parents are not necessary to
+// test equality.
+auto parent_chain = getParentChain(entry, parent_names.size() + 1);
+
+if (!parent_chain) {
+  if (!fallback_impl(entry))
+return;
+  continue;
+}
+
+if (SameParentChain(parent_names, *parent_chain) &&
+!ProcessEntry(entry, callback))
+  return;
+  }
+}
+
+bool DebugNamesDWARFIndex::SameParentChain(
+llvm::ArrayRef parent_names,
+llvm::ArrayRef parent_entries) const {
+
+  if (parent_entries.size() != parent_names.size())
+return false;
+
+  auto SameAsEntryATName = [this](llvm::StringRef name,
+  const DebugNames::Entry &entry) {
+auto maybe_dieoffset = entry.getDIEUnitOffset();
+if (!maybe_dieoffset)
+  return false;
+auto die_ref = ToDIERef(entry);
+if (!die_ref)
+  return false;
+return name == m_debug_info.PeekDIEName(*die_ref);
+  };
+

felipepiovezan wrote:

I'm not attached to the lambda, but I would like to clarify my original intent 
with the lambda and then double check if you still prefer the inlined version 
with that intent in mind.

My intent was not to re-use code, but rather to give name to things and reduce 
cognitive burden. If we go with the suggestion, this is what we end up with:

```
  for (auto [parent_name, parent_entry] :
llvm::zip_equal(parent_names, parent_entries))
auto maybe_dieoffset = entry.getDIEUnitOffset();
 if (!maybe_dieoffset)
   return false;
 auto die_ref = ToDIERef(entry);
 if (!die_ref)
   return false;
 return name == m_debug_info.PeekDIEName(*die_ref);
```

A reader needs to go through that entire block and conclude: "Oh, this is just 
comparing the AT_name with `name`.

With the current version, the code _tells_ you what it is doing 
`if (!SameAsEntryATName(parent_name, parent_entry))`

With that in mind, if you still prefer the inlined version, I'll be happy to 
update it!

(the same rationale applies to the other comment about lambdas)



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

[Lldb-commits] [llvm] [lldb] [lld] [libc] [libcxx] [flang] [libcxxabi] [clang] [msan] Unpoison indirect outputs for userspace using llvm.memset.* (PR #79924)

[Vitaly Buka via lldb-commits]

@@ -4552,16 +4552,22 @@ struct MemorySanitizerVisitor : public 
InstVisitor {
 }
 if (!ElemTy->isSized())
   return;
-Value *SizeVal =
-  IRB.CreateTypeSize(MS.IntptrTy, DL.getTypeStoreSize(ElemTy));
+auto Size = DL.getTypeStoreSize(ElemTy);
+Value *SizeVal = IRB.CreateTypeSize(MS.IntptrTy, Size);
 if (MS.CompileKernel) {
   IRB.CreateCall(MS.MsanInstrumentAsmStoreFn, {Operand, SizeVal});
 } else {
   // ElemTy, derived from elementtype(), does not encode the alignment of
   // the pointer. Conservatively assume that the shadow memory is 
unaligned.
+  // When Size is large, avoid StoreInst as it would expand to many
+  // instructions.
   auto [ShadowPtr, _] =
   getShadowOriginPtrUserspace(Operand, IRB, IRB.getInt8Ty(), Align(1));
-  IRB.CreateAlignedStore(getCleanShadow(ElemTy), ShadowPtr, Align(1));
+  if (Size <= 32)
+IRB.CreateAlignedStore(getCleanShadow(ElemTy), ShadowPtr, Align(1));
+  else
+IRB.CreateMemSet(ShadowPtr, ConstantInt::getNullValue(IRB.getInt8Ty()),

vitalybuka wrote:

Never mind, we do this all the time here.

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

[Lldb-commits] [llvm] [lldb] [lld] [libc] [libcxx] [flang] [libcxxabi] [clang] [msan] Unpoison indirect outputs for userspace using llvm.memset.* (PR #79924)

[Vitaly Buka via lldb-commits]

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


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

[Lldb-commits] [lldb] [lldb] Fix expressions that involve nested structs/classes/unions. (PR #77029)

[Greg Clayton via lldb-commits]

clayborg wrote:

The main issue we have is they way that clang works currently with the external 
AST source. We currently create a forward declaration type "struct Foo;" and we 
allow it to be completed once. Once it is completed clang expects the struct 
type to have everything that it needs, like all contained types (forward decls 
are allowed), otherwise we will never find that type as the external AST source 
thinks it is done. 

I would like to avoid having to find _all_ copies of a struct type and parse 
all contained types in all of matching entries from everywhere in the DWARF if 
possible. If we did this then we would be parsing tons of debug info to add any 
and all potentially contained types and that would cause way too much debug 
info to be parsed.

The best solution I can think of is to have the compile continue to call the 
external AST source to say "please find this type within this struct/class". 
These calls don't happen today, but if they did, we could do this very 
efficiently without having to populate all contained types into every 
struct/class anytime we complete the type.

So right now the flow is:
- any struct/class gets created as a forward declaration and has the external 
AST source enabled
- the external AST calls to complete the type when needed by expression parser 
or LLDB APIs
- we complete the type
- we remove the external AST flag on the type so no more external AST calls 
happen on this class

The new flow could be:
- any struct/class gets created as a forward declaration and has the external 
AST source enabled
- the external AST calls to complete the type when needed by expression parser 
or LLDB APIs
- we complete the type
- we leave the external AST enabled so we can get called for contained types

The last item here would require modifications to clang which could be debugger 
specific changes that are only enabled in a special debug compiler mode so they 
don't affect the actual compiler. Thoughts?

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

[Lldb-commits] [lldb] [llvm] [libcxxabi] [libcxx] [libc] [lld] [clang] [flang] [msan] Unpoison indirect outputs for userspace using memset for large operands (PR #79924)

[Fangrui Song via lldb-commits]

https://github.com/MaskRay closed 
https://github.com/llvm/llvm-project/pull/79924
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix expressions that involve nested structs/classes/unions. (PR #77029)

[David Blaikie via lldb-commits]

dwblaikie wrote:

How'd this work before your recent changes, then - when each repeated query 
would get one level further down in the nesting? How'd that work given the 
clang limitations you're describing?

In any case, the extra clang requirements here seem like they might be of 
uncertain cost/maintainability (if it's only updating one place that everyone 
calls through - great, but if it's updating multiple callers, and the risk that 
new callers miss this handling - that seems like a maintainability problem) 
which is worrying. So, I'd be uncertain about that direction without more info 
- and with that info, if it is just one codepath, yeah, maybe it's quick enough 
to address the regression.

But if it'd require substantial reengineering to clang to get this working - 
this seems an unfortunate regression to carry in the interim, and it might be 
worth reverting to the previous (differently buggy, but at least 
work-around-able) behavior.

And if this would require updating many callers in clang (unless such updates 
include an API change that would make it difficult to accidentally introduce a 
new caller that didn't handle things correctly for lldb), I'd worry about the 
future stability of such a change & might be inclined towards the less 
efficient "search all the DWARF" thing.

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

[Lldb-commits] [lldb] [lldb] Add support for large watchpoints in lldb (PR #79962)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda updated 
https://github.com/llvm/llvm-project/pull/79962

>From 24cf5649fee074e9f6c72c7f768999ce4253b268 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Tue, 30 Jan 2024 00:16:30 -0800
Subject: [PATCH 1/3] [lldb] Add support for large watchpoints in lldb

This patch is the next piece of work in my Large Watchpoint proposal,
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116

This patch breaks a user's watchpoint into one or more WatchpointResources
which reflect what the hardware registers can cover. This means we
can watch objects larger than 8 bytes, and we can watched unaligned
address ranges.  On a typical 64-bit target with 4 watchpoint
registers you can watch 32 bytes of memory if the start address is
doubleword aligned.

Additionally, if the remote stub implements AArch64 MASK style
watchpoints (e.g. debugserver on Darwin), we can watch any power-of-2
size region of memory up to 2GB, aligned to that same size.

I updated the Watchpoint constructor and CommandObjectWatchpoint
to create a CompilerType of Array when the size of the watched
region is greater than pointer-size and we don't have a variable
type to use.  For pointer-size and smaller, we can display the
watched granule as an integer value; for larger-than-pointer-size
we will display as an array of bytes.

I have `watchpoint list` now print the WatchpointResources used to
implement the watchpoint.

I added a WatchpointAlgorithm class which has a top-level static
method that takes an enum flag mask WatchpointHardwareFeature and
a user address and size, and returns a vector of WatchpointResources
covering the request.  It does not take into account the number of
watchpoint registers the target has, or the number still available
for use.  Right now there is only one algorithm, which monitors
power-of-2 regions of memory.  For up to pointer-size, this is what
Intel hardware supports. AArch64 Byte Address Select watchpoints
can watch any number of contiguous bytes in a pointer-size memory
granule, that is not currently supported so if you ask to watch
bytes 3-5, the algorithm will watch the entire doubleword (8 bytes).
The newly default "modify" style means we will silently ignore
modifications to bytes outside the watched range.

I've temporarily skipped TestLargeWatchpoint.py for all targets.
It was only run on Darwin when using the in-tree debugserver, which
was a proxy for "debugserver supports MASK watchpoints".  I'll be
adding the aforementioned feature flag from the stub and enabling
full mask watchpoints when a debugserver with that feature is enabled,
and re-enable this test.

I added a new TestUnalignedLargeWatchpoint.py which only has one
test but it's a great one, watching a 22-byte range that is unaligned
and requires four 8-byte watchpoints to cover.

I also added a unit test, WatchpointAlgorithmsTests, which has a
number of simple tests against WatchpointAlgorithms::PowerOf2Watchpoints.
I think there's interesting possible different approaches to how
we cover these; I note in the unit test that a user requesting a
watch on address 0x12e0 of 120 bytes will be covered by two watchpoints
today, a 128-bytes at 0x1280 and at 0x1300.  But it could be done
with a 16-byte watchpoint at 0x12e0 and a 128-byte at 0x1300, which
would have fewer false positives/private stops.  As we try refining
this one, it's helpful to have a collection of tests to make sure
things don't regress.

I tested this on arm64 macOS, x86_64 macOS, and AArch64 Ubuntu.  I
have not modifed the Windows process plugins yet, I might try that
as a standalone patch, I'd be making the change blind, but the
necessary changes (see ProcessGDBRemote::EnableWatchpoint) are
pretty small so it might be obvious enough that I can change it and
see what the Windows CI thinks.

There isn't yet a packet (or a qSupported feature query) for the
gdb remote serial protocol stub to communicate its watchpoint
capabilities to lldb.  I'll be doing that in a patch right after
this is landed, having debugserver advertise its capability of
AArch64 MASK watchpoints, and have ProcessGDBRemote add
eWatchpointHardwareArmMASK to WatchpointAlgorithms so we can watch
larger than 32-byte requests on Darwin.

I haven't yet tackled WatchpointResource *sharing* by multiple
Watchpoints.  This is all part of the goal, especially when we may
be watching a larger memory range than the user requested, if they
then add another watchpoint next to their first request, it may be
covered by the same WatchpointResource (hardware watchpoint register).
Also one "read" watchpoint and one "write" watchpoint on the same
memory granule need to be handled, making the WatchpointResource
cover all requests.

As WatchpointResources aren't shared among multiple Watchpoints
yet, there's no handling of running the conditions/commands/etc on
multiple Watchpoints when their shared WatchpointResource is hit.
The goal beyond "large watchpoint" is to unify (much more) the
Watchp

[Lldb-commits] [lldb] [lldb][progress][NFC] Add unit test for progress reports (PR #79533)

[Chelsea Cassanova via lldb-commits]

https://github.com/chelcassanova updated 
https://github.com/llvm/llvm-project/pull/79533

>From 10343b6cdad410e09546dd5a98e29d272300ed2e Mon Sep 17 00:00:00 2001
From: Chelsea Cassanova 
Date: Thu, 25 Jan 2024 16:40:42 -0800
Subject: [PATCH 1/4] [lldb][progress][NFC] Add unit test for progress reports

This test is being added as a way to check the behaviour of how progress
events are broadcasted when reports are started and ended with the
current implementation of progress reports. Here we're mainly checking
and ensuring that the current behaviour is that progress events are
broadcasted individually and placed in the event queue in order of
their creation.
---
 lldb/unittests/Core/CMakeLists.txt |   1 +
 lldb/unittests/Core/ProgressReportTest.cpp | 105 +
 2 files changed, 106 insertions(+)
 create mode 100644 lldb/unittests/Core/ProgressReportTest.cpp

diff --git a/lldb/unittests/Core/CMakeLists.txt 
b/lldb/unittests/Core/CMakeLists.txt
index b3cddd150635b..d40c357e3f463 100644
--- a/lldb/unittests/Core/CMakeLists.txt
+++ b/lldb/unittests/Core/CMakeLists.txt
@@ -7,6 +7,7 @@ add_lldb_unittest(LLDBCoreTests
   FormatEntityTest.cpp
   MangledTest.cpp
   ModuleSpecTest.cpp
+  ProgressReportTest.cpp
   RichManglingContextTest.cpp
   SourceLocationSpecTest.cpp
   SourceManagerTest.cpp
diff --git a/lldb/unittests/Core/ProgressReportTest.cpp 
b/lldb/unittests/Core/ProgressReportTest.cpp
new file mode 100644
index 0..bdc168c9e077d
--- /dev/null
+++ b/lldb/unittests/Core/ProgressReportTest.cpp
@@ -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/Utility/Listener.h"
+#include "gtest/gtest.h"
+#include 
+
+using namespace lldb;
+using namespace lldb_private;
+
+namespace {
+class ProgressReportTest : public ::testing::Test {
+public:
+  void SetUp() override {
+FileSystem::Initialize();
+HostInfo::Initialize();
+PlatformMacOSX::Initialize();
+Debugger::Initialize(nullptr);
+  }
+  void TearDown() override {
+Debugger::Terminate();
+PlatformMacOSX::Terminate();
+HostInfo::Terminate();
+FileSystem::Terminate();
+  }
+};
+} // namespace
+TEST_F(ProgressReportTest, TestReportCreation) {
+  std::chrono::milliseconds timeout(100);
+
+  // Set up the debugger, make sure that was done properly
+  ArchSpec arch("x86_64-apple-macosx-");
+  Platform::SetHostPlatform(PlatformRemoteMacOSX::CreateInstance(true, &arch));
+
+  DebuggerSP debugger_sp = Debugger::CreateInstance();
+  ASSERT_TRUE(debugger_sp);
+
+  // Get the debugger's broadcaster
+  Broadcaster &broadcaster = debugger_sp->GetBroadcaster();
+
+  // Create a listener, make sure it can receive events and that it's
+  // listening to the correct broadcast bit
+  ListenerSP listener_sp = Listener::MakeListener("progress-listener");
+
+  listener_sp->StartListeningForEvents(&broadcaster,
+   Debugger::eBroadcastBitProgress);
+  EXPECT_TRUE(
+  broadcaster.EventTypeHasListeners(Debugger::eBroadcastBitProgress));
+
+  EventSP event_sp;
+  const ProgressEventData *data;
+
+  // Scope this for RAII on the progress objects
+  // Create progress reports and check that their respective events for having
+  // started are broadcasted
+  {
+Progress progress1("Progress report 1", "Starting report 1");
+EXPECT_TRUE(listener_sp->GetEvent(event_sp, timeout));
+
+data = ProgressEventData::GetEventDataFromEvent(event_sp.get());
+ASSERT_EQ(data->GetDetails(), "Starting report 1");
+
+Progress progress2("Progress report 2", "Starting report 2");
+EXPECT_TRUE(listener_sp->GetEvent(event_sp, timeout));
+
+data = ProgressEventData::GetEventDataFromEvent(event_sp.get());
+ASSERT_EQ(data->GetDetails(), "Starting report 2");
+
+Progress progress3("Progress report 3", "Starting report 3");
+EXPECT_TRUE(listener_sp->GetEvent(event_sp, timeout));
+ASSERT_TRUE(event_sp);
+
+data = ProgressEventData::GetEventDataFromEvent(event_sp.get());
+ASSERT_EQ(data->GetDetails(), "Starting report 3");
+
+std::this_thread::sleep_for(timeout);
+  }
+
+  // Progress report objects should be destroyed at this point so
+  // get each report from the queue and check that they've been
+  // destroyed in reverse order
+  std::this_thread::sleep_for(timeout);
+  EXPECT_TRUE(listener_sp->GetEvent(event_sp, timeout));
+  data = ProgressEventData::GetEventDataFromEvent(event_sp.get());
+
+  ASSERT_EQ(data->GetTitle(), "Progress report 3");
+  ASSERT_TRUE(data->GetCompleted());
+
+  std::this_thread::sleep_for(timeout);
+  EXPECT_TRUE(listener_sp->GetEvent(event_sp, timeout));
+  data = ProgressEventData::GetEventDataFromEvent(event_sp.get());
+
+  ASSERT_EQ(data->GetTitle(), "Progress report 2");
+  ASSERT_TRUE(data->GetCompleted())

[Lldb-commits] [lldb] [lldb] Add support for large watchpoints in lldb (PR #79962)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda updated 
https://github.com/llvm/llvm-project/pull/79962

>From 24cf5649fee074e9f6c72c7f768999ce4253b268 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Tue, 30 Jan 2024 00:16:30 -0800
Subject: [PATCH 1/4] [lldb] Add support for large watchpoints in lldb

This patch is the next piece of work in my Large Watchpoint proposal,
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116

This patch breaks a user's watchpoint into one or more WatchpointResources
which reflect what the hardware registers can cover. This means we
can watch objects larger than 8 bytes, and we can watched unaligned
address ranges.  On a typical 64-bit target with 4 watchpoint
registers you can watch 32 bytes of memory if the start address is
doubleword aligned.

Additionally, if the remote stub implements AArch64 MASK style
watchpoints (e.g. debugserver on Darwin), we can watch any power-of-2
size region of memory up to 2GB, aligned to that same size.

I updated the Watchpoint constructor and CommandObjectWatchpoint
to create a CompilerType of Array when the size of the watched
region is greater than pointer-size and we don't have a variable
type to use.  For pointer-size and smaller, we can display the
watched granule as an integer value; for larger-than-pointer-size
we will display as an array of bytes.

I have `watchpoint list` now print the WatchpointResources used to
implement the watchpoint.

I added a WatchpointAlgorithm class which has a top-level static
method that takes an enum flag mask WatchpointHardwareFeature and
a user address and size, and returns a vector of WatchpointResources
covering the request.  It does not take into account the number of
watchpoint registers the target has, or the number still available
for use.  Right now there is only one algorithm, which monitors
power-of-2 regions of memory.  For up to pointer-size, this is what
Intel hardware supports. AArch64 Byte Address Select watchpoints
can watch any number of contiguous bytes in a pointer-size memory
granule, that is not currently supported so if you ask to watch
bytes 3-5, the algorithm will watch the entire doubleword (8 bytes).
The newly default "modify" style means we will silently ignore
modifications to bytes outside the watched range.

I've temporarily skipped TestLargeWatchpoint.py for all targets.
It was only run on Darwin when using the in-tree debugserver, which
was a proxy for "debugserver supports MASK watchpoints".  I'll be
adding the aforementioned feature flag from the stub and enabling
full mask watchpoints when a debugserver with that feature is enabled,
and re-enable this test.

I added a new TestUnalignedLargeWatchpoint.py which only has one
test but it's a great one, watching a 22-byte range that is unaligned
and requires four 8-byte watchpoints to cover.

I also added a unit test, WatchpointAlgorithmsTests, which has a
number of simple tests against WatchpointAlgorithms::PowerOf2Watchpoints.
I think there's interesting possible different approaches to how
we cover these; I note in the unit test that a user requesting a
watch on address 0x12e0 of 120 bytes will be covered by two watchpoints
today, a 128-bytes at 0x1280 and at 0x1300.  But it could be done
with a 16-byte watchpoint at 0x12e0 and a 128-byte at 0x1300, which
would have fewer false positives/private stops.  As we try refining
this one, it's helpful to have a collection of tests to make sure
things don't regress.

I tested this on arm64 macOS, x86_64 macOS, and AArch64 Ubuntu.  I
have not modifed the Windows process plugins yet, I might try that
as a standalone patch, I'd be making the change blind, but the
necessary changes (see ProcessGDBRemote::EnableWatchpoint) are
pretty small so it might be obvious enough that I can change it and
see what the Windows CI thinks.

There isn't yet a packet (or a qSupported feature query) for the
gdb remote serial protocol stub to communicate its watchpoint
capabilities to lldb.  I'll be doing that in a patch right after
this is landed, having debugserver advertise its capability of
AArch64 MASK watchpoints, and have ProcessGDBRemote add
eWatchpointHardwareArmMASK to WatchpointAlgorithms so we can watch
larger than 32-byte requests on Darwin.

I haven't yet tackled WatchpointResource *sharing* by multiple
Watchpoints.  This is all part of the goal, especially when we may
be watching a larger memory range than the user requested, if they
then add another watchpoint next to their first request, it may be
covered by the same WatchpointResource (hardware watchpoint register).
Also one "read" watchpoint and one "write" watchpoint on the same
memory granule need to be handled, making the WatchpointResource
cover all requests.

As WatchpointResources aren't shared among multiple Watchpoints
yet, there's no handling of running the conditions/commands/etc on
multiple Watchpoints when their shared WatchpointResource is hit.
The goal beyond "large watchpoint" is to unify (much more) the
Watchp

[Lldb-commits] [lldb] [lldb] Add support for large watchpoints in lldb (PR #79962)

[Jason Molenda via lldb-commits]

https://github.com/jasonmolenda updated 
https://github.com/llvm/llvm-project/pull/79962

>From 24cf5649fee074e9f6c72c7f768999ce4253b268 Mon Sep 17 00:00:00 2001
From: Jason Molenda 
Date: Tue, 30 Jan 2024 00:16:30 -0800
Subject: [PATCH 1/5] [lldb] Add support for large watchpoints in lldb

This patch is the next piece of work in my Large Watchpoint proposal,
https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116

This patch breaks a user's watchpoint into one or more WatchpointResources
which reflect what the hardware registers can cover. This means we
can watch objects larger than 8 bytes, and we can watched unaligned
address ranges.  On a typical 64-bit target with 4 watchpoint
registers you can watch 32 bytes of memory if the start address is
doubleword aligned.

Additionally, if the remote stub implements AArch64 MASK style
watchpoints (e.g. debugserver on Darwin), we can watch any power-of-2
size region of memory up to 2GB, aligned to that same size.

I updated the Watchpoint constructor and CommandObjectWatchpoint
to create a CompilerType of Array when the size of the watched
region is greater than pointer-size and we don't have a variable
type to use.  For pointer-size and smaller, we can display the
watched granule as an integer value; for larger-than-pointer-size
we will display as an array of bytes.

I have `watchpoint list` now print the WatchpointResources used to
implement the watchpoint.

I added a WatchpointAlgorithm class which has a top-level static
method that takes an enum flag mask WatchpointHardwareFeature and
a user address and size, and returns a vector of WatchpointResources
covering the request.  It does not take into account the number of
watchpoint registers the target has, or the number still available
for use.  Right now there is only one algorithm, which monitors
power-of-2 regions of memory.  For up to pointer-size, this is what
Intel hardware supports. AArch64 Byte Address Select watchpoints
can watch any number of contiguous bytes in a pointer-size memory
granule, that is not currently supported so if you ask to watch
bytes 3-5, the algorithm will watch the entire doubleword (8 bytes).
The newly default "modify" style means we will silently ignore
modifications to bytes outside the watched range.

I've temporarily skipped TestLargeWatchpoint.py for all targets.
It was only run on Darwin when using the in-tree debugserver, which
was a proxy for "debugserver supports MASK watchpoints".  I'll be
adding the aforementioned feature flag from the stub and enabling
full mask watchpoints when a debugserver with that feature is enabled,
and re-enable this test.

I added a new TestUnalignedLargeWatchpoint.py which only has one
test but it's a great one, watching a 22-byte range that is unaligned
and requires four 8-byte watchpoints to cover.

I also added a unit test, WatchpointAlgorithmsTests, which has a
number of simple tests against WatchpointAlgorithms::PowerOf2Watchpoints.
I think there's interesting possible different approaches to how
we cover these; I note in the unit test that a user requesting a
watch on address 0x12e0 of 120 bytes will be covered by two watchpoints
today, a 128-bytes at 0x1280 and at 0x1300.  But it could be done
with a 16-byte watchpoint at 0x12e0 and a 128-byte at 0x1300, which
would have fewer false positives/private stops.  As we try refining
this one, it's helpful to have a collection of tests to make sure
things don't regress.

I tested this on arm64 macOS, x86_64 macOS, and AArch64 Ubuntu.  I
have not modifed the Windows process plugins yet, I might try that
as a standalone patch, I'd be making the change blind, but the
necessary changes (see ProcessGDBRemote::EnableWatchpoint) are
pretty small so it might be obvious enough that I can change it and
see what the Windows CI thinks.

There isn't yet a packet (or a qSupported feature query) for the
gdb remote serial protocol stub to communicate its watchpoint
capabilities to lldb.  I'll be doing that in a patch right after
this is landed, having debugserver advertise its capability of
AArch64 MASK watchpoints, and have ProcessGDBRemote add
eWatchpointHardwareArmMASK to WatchpointAlgorithms so we can watch
larger than 32-byte requests on Darwin.

I haven't yet tackled WatchpointResource *sharing* by multiple
Watchpoints.  This is all part of the goal, especially when we may
be watching a larger memory range than the user requested, if they
then add another watchpoint next to their first request, it may be
covered by the same WatchpointResource (hardware watchpoint register).
Also one "read" watchpoint and one "write" watchpoint on the same
memory granule need to be handled, making the WatchpointResource
cover all requests.

As WatchpointResources aren't shared among multiple Watchpoints
yet, there's no handling of running the conditions/commands/etc on
multiple Watchpoints when their shared WatchpointResource is hit.
The goal beyond "large watchpoint" is to unify (much more) the
Watchp

[Lldb-commits] [lldb] [lldb] Fix a crash when using .dwp files and make type lookup reliable with the index cache (PR #79544)

[via lldb-commits]

https://github.com/jeffreytan81 edited 
https://github.com/llvm/llvm-project/pull/79544
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] [lldb] Fix a crash when using .dwp files and make type lookup reliable with the index cache (PR #79544)

[via lldb-commits]

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

High level makes sense. 

Can you add test to ensure both dwarf4 & dwarf5 work? Also the modified test 
covers dwp, have you tested dwo without dwp scenario for completeness? 

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

[Lldb-commits] [lldb] [lldb] Fix a crash when using .dwp files and make type lookup reliable with the index cache (PR #79544)

[via lldb-commits]

@@ -1675,20 +1675,20 @@ Type *SymbolFileDWARF::ResolveType(const DWARFDIE &die,
 
 CompileUnit *
 SymbolFileDWARF::GetCompUnitForDWARFCompUnit(DWARFCompileUnit &dwarf_cu) {
+
   if (dwarf_cu.IsDWOUnit()) {
-DWARFCompileUnit *non_dwo_cu =
-static_cast(dwarf_cu.GetUserData());
+DWARFCompileUnit *non_dwo_cu = dwarf_cu.GetSkeletonUnit();
 assert(non_dwo_cu);

jeffreytan81 wrote:

Add a comment explain why this assertion can hold - why `non_dwo_cu` can't be 
null.

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