[Clang] Use Compat diagnostics for most extension/compatibility warnings (#216693)
This changes the wording of a few diagnostic messages to be more
canonical. Otherwise this should be NFC.
[lldb-server] Add dynamic loader support to accelerator plugin protocol (#214564)
Context:
https://discourse.llvm.org/t/upstreaming-basic-support-for-accelerators/89827/
This is PR#1 of a PR stack adding dynamic loader support for accelerator
(GPU) targets to lldb:
the next PR is **#214581**
In this PR we are adding the protocol foundation for the dyld
- Added handling of new GDB Remote packet
`jAcceleratorPluginGetDynamicLoaderLibraryInfo` and testing it with the
Mock Server Plugin
- see the dyld implementation in **#217393**
clang/AMDGPU: Fix test to work with -lgomp (#220331)
Recently added test fails with "error: '-fopenmp-targets' must be used
in conjunction with a '-fopenmp' option compatible with offloading;
e.g., '-fopenmp=libomp' or '-fopenmp=libiomp5'" if it is built with
-lgomp. This adds a default value (libomp) for the -fopenmp flag to
prevent this test failure.
(The test was added as part of
https://github.com/llvm/llvm-project/pull/219963)
[mlir] Remove unnecessary allow-unregistered-dialect flags (#220613)
This is bad practice, instead use unknown operations in the test dialect
when tests only need placeholders.
Use a registered SPIR-V operation for translation diagnostics.
Assisted-by: Codex
[libc][baremetal] add MVE/MVE_FP feature flags detection (#220345)
This patch adds MVE/MVE_FP SIMD feature flags for baremetal targets.
Cortex-M85/Cortex-M55 introduced the M-profile Vector Extension
(Helium). The detection is via the `__ARM_FEATURE_MVE` bitfield as
described in the Arm C Language Extensions (ACLE): bit 0 is set when
the MVE integer instructions are available, bit 1 when the
floating-point instructions are also available.
Co-authored-by: Claude Fable 5 <noreply at anthropic.com>
[SystemZ] XPLINK64: keep CCAssignToRegAndStack rule for bare i32 args (#220354)
Bare i32 arguments (no signext/zeroext, e.g. sitofp sources or
struct-coerced i32s) must be assigned to R1L/R2L/R3L by the
CCAssignToRegAndStack rule in CC_SystemZ_XPLINK64.
Without that rule they fall through to the stack fallback,
producing wrong codegen (stack loads instead of register references).
This test demonstrates the regression caused by removing the
CCIfType<[i32], CCAssignToRegAndStack<[R1L,R2L,R3L],8,8>> rule
from CC_SystemZ_XPLINK64 and serves as justification for keeping it.
This is a pre-existing independent issue extracted from #206833 per
reviewer request.
Thread Safety Analysis: Look through elidable copies of scoped lockables
Under C++11/14, initializing a guard variable from a factory --
`MutexLock scope = lock();` with `MutexLock lock() ACQUIRE(mu)` --
loses the guard: the initializer is an elidable copy (or move)
construction from the materialized temporary the call returned, and
VisitDeclStmt does not look through it, so the scope object recorded
for the call is never bound to the variable. The CFGTemporaryDtor
element then finds the object still unclaimed and runs the guard
destructor at the end of the full-expression, releasing the
underlying capabilities immediately, and the variable's own
destructor later warns "releasing mutex 'scope' that was not held".
Returning a guard by value from an annotated factory has the same
defect on the return side: in `MutexLock lock() ACQUIRE(mu)
{ return MutexLock(&mu); }` the temporary's destructor element
precedes the return, so the factory releases what it just acquired
and is diagnosed for not holding `mu` at its own end.
Fix in VisitCXXConstructExpr: an elidable copy or move construction
[28 lines not shown]
Thread Safety Analysis: Fold scoped lockables into the try-held model
A scoped lockable whose constructor is annotated with a try-acquire
attribute (`std::unique_lock lock(mu, std::try_to_lock)`-style)
bypassed the conditional model: the capabilities were recorded but no
facts created, so the guard tracked nothing -- uses under it warned
as if no acquisition existed, its destructor released nothing, and
nothing recorded that the capability is unheld after the scope. Now
the construction creates a try-held fact per recorded capability,
like a direct try-acquire call.
Design details:
* The facts are Managed -- the model's counterpart of the guard's
own ownership flag -- and the capabilities are registered as the
scoped fact's underlying mutexes, so the destructor reaches them.
* The destructor is `if (held) Unlock()`: a conditional release that
pairs exactly with the guard's conditional acquisition, so
[26 lines not shown]
Thread Safety Analysis: Resolve try-acquire results merged by a conditional operator
A non-void `?:` on a try-acquire result used to pin it unresolved
wholesale: the branch was never honored, and only a
both-arms-constant value (`ok ? 1 : 0`) could be decoded at a later
branch. The body of `if (mu.TryLock() ? use() : false)` warned
although a truthy value proves the lock is held, and the GNU form
`ok ?: 0` was not decoded at all. Now the decode computes what the
merged value determines about the result, arm by arm, and the `?:`
terminator itself is always honored as a branch.
Design details:
* Constant arms of differing truthiness carry the result as the
value itself -- its truthiness is the result's but its magnitude
is the arm's, so exact values are never applied to the result (a
new ValueMerged flag clears ValueIsResult). GNU `ok ?: 0` keeps
the result exactly, magnitude included.
[42 lines not shown]
Thread Safety Analysis: Resolve try-acquire results by exact value, not just truthiness
The attributes' success values, the branch conditions on the result,
and the resolution between them all collapsed to truthiness, which is
unsound in both directions for attributes keying distinct
capabilities to integer codes:
int trylock_codes() TRY_ACQUIRE(1, mu1) TRY_ACQUIRE(2, mu2);
`if (trylock_codes() == 2)` silently accepted uses of mu1 in its body
("truthy" promoted it too, though a result of 2 proves mu1 was never
acquired), and the other edge of `== 1` read as "result falsy",
wrongly removing mu2's fact.
Design details:
* Recording: a truthy success value that is a specific integer
constant (not a bool) is recorded as that capability's exact
success code (ExactCodes), via the constant evaluator, so
[40 lines not shown]
Thread Safety Analysis: Demote same-origin joins silently
Resolving the check-first idioms (`if (ok) continue;
ok = mu.TryLock();` and the loop-top check) creates one new join
shape: the hold a check re-materialized or promoted meets the same
call's try-held fact -- or its failure-edge negative -- at a join
whose terminator does not re-branch on the result. Both sides denote
"held iff the call's result", so intersectAndWarn() now demotes such
same-origin joins silently to the try-held fact, their exact join,
instead of diagnosing a mixed join.
Design details:
* At loop joins always; at branch joins only under
-Wthread-safety-beta: the silence trades the eager lost-hold
diagnosis at the join for the beta-only unchecked-result
diagnostics downstream, and without beta that eager warning is the
only coverage for the leak (warn-thread-safety-try-nobeta.cpp pins
it). A re-branch that fails to resolve all paths stays diagnosed
[29 lines not shown]
Thread Safety Analysis: Resolve branches on stored try-acquire results through merges and phis
The common guard pattern
bool ok = false;
if (cond)
ok = mu.TryLock();
if (ok) { ... mu.Unlock(); }
(and the spin loop `while (!ok) ok = mu.TryLock();`) was previously
unresolvable: the local-variable map discarded the merged definition
of `ok`, so the branch on it did not count as checking the result --
drawing the beta "unchecked result" warning at the very check, plus a
spurious release warning inside the guarded region. The map now
records such merges as two-operand phi definitions, and the decode
resolves the ones whose value still identifies the call's result.
Design details:
[52 lines not shown]
Thread Safety Analysis: Resolve try-acquire facts at every branch on the result
getEdgeLockset() so far resolved a call's still-try-held facts only
at a plain if/else branch directly on the result. Now every branch on
a try-acquire result resolves every fact originating from the call:
promoted and negative facts as well as try-held ones, and
re-branches, compound short-circuit conditions, and switches as well
as the plain branch. In particular this fixes the common
assert-then-branch shape -- promote at the assert, branch again later
-- which previously drew "already held" plus "not held on every path"
warnings.
Design details:
* A success-edge promotion keeps its originating call, so a later
branch on the same result re-resolves the fact instead of treating
the edge as a second acquisition: re-resolution keeps the
reentrancy depth and source, runs no second acquisition check, and
is idempotent over any number of branches. An assert-claimed
[50 lines not shown]
Thread Safety Analysis: Diagnose a try-acquire whose result is never checked
A try-held fact means "held iff the try-acquire succeeded". When the
analysis loses track of one -- at a join with a path that does not
hold the capability, or at the end of the function -- the result was
never used to determine whether the acquisition happened, so on the
paths where it succeeded the capability is leaked. Such a fact was
dropped silently. Diagnose it under -Wthread-safety-beta with a new
warn_try_acquire_never_checked, noting the try-acquire call.
Design details:
* Exempt: a join whose terminator re-branches on the result (the
fact is demoted and re-resolved on the outgoing edges instead),
and loop joins, where the result was or will be checked on the
paths around the loop (tryheld_loop_join_not_a_leak).
* Deliberately NOT exempt: a result stored where the analysis cannot
track it (a member, a parameter). The store does not prove a later
[26 lines not shown]
Thread Safety Analysis: Diagnose a try-acquire that acquires a capability regardless of its result
The same capability listed under opposite success values of a call's
try-acquire attributes is acquired whichever way the call returns. So
far that degenerate annotation was handled by the general machinery:
the capability's second recording at the call was diagnosed like any
try-acquire over a try-held capability ("may already be held"), and
the try-held fact resolved to held on both edges of a branch on the
result.
Reconcile the record at the call instead (reconcileTryAcquireCaps()):
the capability moves out of the polarity sets of its TryAcquireCapsMap
entry into an unconditional group, and handleCall() turns that group
into an unconditional acquisition under a dedicated
warn_try_lock_regardless_of_result -- the capability becomes held at
the call, and no try-held fact is left for a branch to resolve or a
failure edge to release (tryheld_regardless_of_result,
tryheld_regardless_of_result_unbranched). Every capability still
recorded then matches exactly one polarity and one kind at a branch;
[28 lines not shown]
Thread Safety Analysis: Track try-acquired capabilities as a ternary try-held state
Context: I was a bit frustrated by using conditional capabilities in
real code, since it was giving both incorrect and incomplete analysis
results. There is already this really nice fact manager here;
conditional modelling was simply ignoring it and essentially
reimplementing a simplified duplicate model on top of it which tried to
re-derive facts and inject them into the real model. But the underlying
model already seemed really close to be able to hold these facts too,
instead of leaving them invisible and wrongly diagnosed. This PR is the
beginning of a series of about 10 PRs to reduce those correctness and
completeness gaps. Claude is already happy with the state of those other
branches, but I'm not happy with them yet, so I'll drip those out as I
get time to polish them up. Throughout this series, I have tried to
often suppress new warnings except when passing `-Wthread-safety-beta`,
so that users can opt-in explicitly to the more complete and accurate
checks. The stack of branches is:
1. (users/vtjnash/tsa-tryheld-regardless-of-result) Diagnose a try-acquire that acquires a capability regardless of its result
[71 lines not shown]
Thread Safety Analysis: Decode terminator branches directly into capability resolutions [NFC]
Restructure the walk over the branched-on condition (getTrylockCallExpr,
now decodeTrylockCond) to record what it learns about the intermediate
expressions applied to the value into a TrylockDecode, instead of
returning the call while threading through a single `Negate`. This
doesn't change too much structurally while negation is the only relation
recorded, but makes it simpler to add new features to the walk without
needing duplicate analysis between the walk and the decoding.
Previously, getTrylockCallExpr threaded a Negate out-parameter through
every recursion, and getEdgeLockset re-derived from it, per edge, what
the branch proves: mapping the edge through the negations to a result
value, then re-translating every attribute of the callee to decide which
capabilities that value acquires -- with getTerminatorTrylockCaps
repeating the translation for the join exemption, and the beta-mode
SExprBuilder lookup closure escaping getTerminatorTrylockCall through a
scope_exit element of its returned tuple so callers could translate.
Now decodeTrylockBranch folds the decode, once per terminator, into the
[12 lines not shown]
Remove overly strict assertion for this-capture in blocks (#219080)
TransformBlockExpr asserted that if the instantiated block captures
'this', the uninstantiated pattern block must also have captured it.
This assumption doesn't always hold: a block that accesses a member
through a dependent qualified-id (e.g., 'T::m' inside a template
deriving from T) has no way to know at parse time that the access will
resolve to an implicit 'this->m', since T is unknown. Once the template
is instantiated and 'T::m' resolves to a non-static data member, the
instantiated block legitimately captures 'this' even though the pattern
never did.
rdar://184776458
[lldb] Return llvm::Expected from Process::ReadPointerFromMemory (#216389)
The function reported failure twice, through a Status out-parameter and
by returning LLDB_INVALID_ADDRESS. Returning
llvm::Expected<lldb::addr_t> collapses those into a single channel that
cannot be ignored.
Note that ReadScalarIntegerFromMemory can report a short read without
setting the Status so callers could previously get a success Status
alongside LLDB_INVALID_ADDRESS. That case now yields an error.
Call sites that already discarded the Status consume the error
explicitly to preserve their behavior. Error-path logging uses
LLDB_LOG_ERROR instead of passing takeError() to LLDB_LOG/LLDB_LOGF,
which only evaluate their arguments when the channel is enabled and
would otherwise leave the error unchecked and abort.
Assisted-by: Claude
[ADT] Move traits after FoldingSetNodeID to inline Equals (NFC) (#220494)
This patch moves down DefaultFoldingSetTrait and
DefaultContextualFoldingSetTrait after FoldingSetNodeID, allowing
Equals to be defined inline in DefaultFoldingSetTrait and
DefaultContextualFoldingSetTrait.
Assisted-by: Antigravity
Revert "[lldb][test] Disable two breakpoint tests for debugserver (#2… (#220615)
…18636)"
This reverts commit 7ea6d83f49d975d64ef2548561a46619c86b3570.
The tests should now pass.
[llvm][ADT] Remove function_ref equality operator (#220600)
The equality operator no longer has in-tree users.
TableGen replaced its function_ref callback wrapper with its own FnT.
Assisted-by: Codex
[GlobalISel] Remove dead declarations and functions (NFC) (#220499)
CombinerHelper::tryCombine: The corresponding function definition was
removed on September 24, 2023 in commit
bc6e7f057340ab0b995cc17a170e34545a295f03.
GISelValueTracking::getKnownBits(MachineInstr &): Added on August 6,
2019
in commit c8ac029d0ae27b8fd392f216d471ba2730be7fd1 without any callers.
GISelValueTracking::computeKnownBitsForAlignment: The last use was
removed on June 3, 2020 in commit
45e1a22a92bf2c33336ccc02ea4fa3996f60252b.
LegalizerHelper::lowerU64ToF32BitOps: The last use was removed on
September 25, 2024 in commit e9cb44090ff7b3feda386ca1ee1252ab47c0617e.
Assisted-by: Antigravity
[VectorCombine] Avoid calling getTypeSizeInBits on scalable vectors in scalarizeLoadBitcast (#220482)
Avoids `LLVM ERROR: Cannot implicitly convert a scalable size to a
fixed-width size in TypeSize::operator ScalarTy()`
[AArch64][GlobalISel] Add tablegen patterns for smull+sqshrn -> sqdmulh. (#217318)
We do this in parts in globalisel, recognizing the smull and trunc_sat,
which when combined with the correct shift can fold into a single
sqdmulh.
