Some of the tests moved in #134354 do not currently pass on a mac. Disable
them.
The test for testing process priority also does not build on a mac. I'm not
moving it (back) to the linux, since it's "almost" fine -- we'd just need to
implement the RLIMIT_NICE logic differently. I'm not doing that now since
(apart from linux) there are no systems which are able to retrieve the process
priority.
In #130623 support was added for `+nosimd` in the clang driver.
Following this PR, it was discovered that, if NEON is disabled in the
command line, it did not disable features that depend on this, such as
Crypto or AES. To achieve this, This PR does the following:
- Ensure that disabling NEON (e.g., via +nosimd) also disables dependent
features like Crypto and AES.
- Update the driver to automatically enable NEON when enabling features
that require it (e.g., AES).
This fixes inconsistent behavior where features relying on NEON could be
enabled without NEON itself being active, or where disabling NEON left
dependent features incorrectly enabled.
We can use the `__is_nothrow_convertible` builtin unconditionally now,
which makes the implementation very simple, so there isn't much of a
need to keep a separate header around.
The function was always trying to dereference both the synthetic and
non-synthetic view of the object. This is wrong as the caller should be
able to determine which view of the object it wants to access, as is
done e.g. for child member access.
This patch removes the nonsynthetic->synthetic fallback, which is the
more surprising path, and fixes the callers to try both versions of the
object (when appropriate). I also snuck in simplification of the member
access code path because it was possible to use the same helper function
for that, and I wanted to be sure I understand the logic correctly.
I've left the synthetic->nonsynthetic fallback in place. I think we may
want to keep that one as we often have synthetic child providers for
pointer types. They usually don't provide an explicit dereference
operation but I think users would expect that a dereference operation on
those objects would work. What we may want to do is to try the
*synthetic* operation first in this case, so that the nonsynthetic case
is really a fallback.
---------
Co-authored-by: Ilia Kuklin <kuklin.iy@mail.ru>
As of #117683, Blocks are always enclosed in a function, so these checks
never fail. We can't change the signature of
`CalculateSymbolContextFunction` as it's an abstract function (and some
of its implementations can return nullptr), but we can create a
different function that we can call when we know we're dealing with a
block.
Reverts llvm/llvm-project#137408
This change broke `lldb/test/Shell/Unwind/split-machine-functions.test`.
The test binary has a symbol named `_Z3foov.cold` and the test expects
the backtrace to print the name of the cold part of the function like
this:
```
# SPLIT: frame #1: {{.*}}`foo() (.cold) +
```
but now it gets
```
frame #1: 0x000055555555514f split-machine-functions.test.tmp`foo() + 12
```
This PR is in reference to porting LLDB on AIX.
Link to discussions on llvm discourse and github:
1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2. https://github.com/llvm/llvm-project/issues/101657
The complete changes for porting are present in this draft PR:
https://github.com/llvm/llvm-project/pull/102601
- Added changes to make the common host support functions under
`Host/posix` for unix-like system.
Also, created the `unittests/Host/posix/` to test the hostInfo & support
functions for unix-like system.
- Added changes to get the host information for AIX. (GetProcessInfo())
(Information like : executable path, arch, process status etc.)
This adds a new filtering option to be used along with the
-header-include-format=json option. The existing "only-direct-system"
filtering option is missing some things:
- It does not show module imports.
- It does not show includes of non-system headers. This new
"direct-per-file" filtering has a separate entry in the JSON output for
each non-system source file, showing the direct includes and imports
from that file. You can use this to see uses of non-system headers, and
also find the paths through non-system headers that lead up to module
imports and system headers. Modules are identified here by their
modulemap files.
Fixes#132692.
`clang -cc1` crashes when generating a module interface with
`emit-module-interface` or `emit-reduced-module-interface` using an
input file which is already a precompiled module (`.pcm`) file.
This commit adds validation for the input file format and Clang will now
emit an error message instead of crashing.
The expensive checks bots found issues with #132481, due to not setting
defs/uses correctly. In 31bd7a5071 I added verify flags, so that the
failure is reproduced without requiring expensive checks, and xfailed
the test.
This change:
- Ensures that registers are correctly marked as defs/uses.
- Removes the xfail.
- Leaves the tests with `-verify-machineinstrs` which should have been
present originally.
This patch add the test for the fmuladd reduction to show the test
change/fail for the cost model change.
Note that without the fp128 load and trunc, there is no failure.
Pre-commit test for #113903.
On 64-bit platforms, libgcc doesn't ship with __clzsi2, so __builtin_clz
gets lowered to __clzdi2. A check already exists for GCC, but as of
commit 8210ca0198 clang also lowers
__builtin_clz to __clzdi2 on sparc64.
Update the check so that building __clzdi2 with clang/sparc64 also
works.
A GCC 7 requirement on the completeness of types before using them in a
variant means we need a constructor for these (or define them outside the
current thing). This patch should fix the build, as reported by
@kewen12
My previous commit was a bit sloppy, I didn't spot that
`lldb-dap.executable-path` already had a scope and I didn't consider
that `lldb-dap.log-path` should have the same scope.
This PR addresses both:
- Fix duplicate scope for `lldb-dap.executable-path`.
- Change scope of `lldb-dap.log-path` to `machine-overridable` too.
Mutating a node after it has been created isn't a good idea. After
e17f07c4de, we have a version of setStore
that can create a truncating indexed store. Use that instead of
MorphNodeTo+setTruncatingStore in PowerPC.
Unfortunately, if we return the newly created node, DAGCombiner will
visit the node and change the constant. To prevent this, we use
DCI.CombineTo and avoid adding the new node to the worklist.
In 42622c7959, depending on the entire
utility library resulted in the lldb binary having more symbols that it
needs, duplicating those in liblldb, leading to odr violations. Now
instead we just expose the Host library's headers, which happens to be
enough for this to compile and link, referencing the symbols from
liblldb
# Summary
This patch makes the `request_attach` wait for events `process` and
`initialized` just like `request_launch`. This ensure the DAP session
can move forward somewhat correctly.
Recently `TestDap_attach.test_terminate_commands` became flaky.
It's hitting:
```
lldbsuite/test/tools/lldb-dap/dap_server.py", line 350, in send_recv
raise ValueError(desc)
ValueError: no response for "disconnect"
```
I took a look at the DAP msg from that test case and noticed:
- It's not using the regular attaching, instead it's using the
`attachCommands` to launch debug the binary and it will stop at entry.
- The `initialized` event returned after the `disconnect` request. Which
means lldb-dap didn't really get ready yet.
### NOTE
The `dap_server.py` is doing things to mimic the VSCode (or other dap
clients) but it had some assumptions. For example, it's still missing
the `configurationDone` request and response because it relies on a
continue action to trigger the `configurationDone` request.
# Test Plan
```
./bin/llvm-lit -va /Users/wanyi/llvm-upstream/llvm-project/lldb/test/API/tools/lldb-dap/attach/TestDAP_attach.py
./bin/llvm-lit -va /Users/wanyi/llvm-upstream/llvm-project/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py
```
To test the `wait_for_events` timeout case
```
events = self.wait_for_events(["process", "initialized", "fake", "event"], 1)
if events:
raise ValueError(f'no events {",".join(events)} found for within timeout 1')
```
Observed
<img width="696" alt="image"
src="https://github.com/user-attachments/assets/bc97c0ef-d91f-4561-8272-4d36f5f5d4e6"
/>
### Also
Looks like some test cases should be re-enabled in
0b8dfb5762
But only comments was removed. The skip statements survived the change.
Without this change files in `--start-lib`/`--end-lib` groups were being
marked as live, which means there static constructors were being
included in the link.
Like the NamespaceDecl, this is just emitted as a decl-context, where
all its internal declarations get emitted for it. The incubator doesn't
seem to have any good tests for this, so I wrote what I could think of
as a half-decent test for this one, though the lowering doesn't manage
whether these should be mangled, so the test is mostly just for
spot-checking purposes.
I'm implementing this as it will make writing further tests for future
features a little easier.
The 'loop' construct has some pretty strict checks as to what the for
loop associated with it has to look like. The previous implementation
was a little convoluted and missed implementing the 'condition'
checking. Additionally, it did a bad job double-diagnosing with
templates.
This patch rewrites it in a way that does a much better job with the
double-diagnosing, and proeprly implements some checks for the
'condition' of the for loop.
10s looks not enough. With highly parallel test
execution on VMs it's very possible that Asan
report will have no enough time to produce output.
I can reproduce locally 1s is not always enough,
but likely my workstation is faster then buildbot.
Additionally, don't use puts/CHECK to validate
timeout. We can exit with 0 and it should violate
"not" expectation.
Follow up to #131756.
This shows up in the extension UI and in the VSCode extension
marketplace.
I used the llvm/llvm-www/blob/main/img/LLVMWyvernSmall.png for the
image.
Here is what this looks like locally:
<img width="1020" alt="Screenshot 2025-04-28 at 12 30 33 PM"
src="https://github.com/user-attachments/assets/cd615161-06db-4a37-8f8a-df65ca620a67"
/>
Move out the logic to prepare for vectorization to a separate transform,
before creating loop regions. This was discussed as follow-up
in https://github.com/llvm/llvm-project/pull/136455.
This just moves the existing code around slightly and will simplify
follow-up patches to include the exiting edges during initial VPlan
construction.
