[AArch64] Fix widening of half/bfloat partial reductions. (#220261)
Includes testing aimed at letting us use partial reductions as the
default for add/fadd reductions when ordering isn't required.
AMDGPU: Fix LDS bank count for gfx704 and gfx950
Both inherited a bank count that does not match the hardware: Bonaire
has 16 banks, and gfx950 doubled the count to 64 along with its larger
LDS. The ROCm device metadata has reported these values all along, so
the subtarget and the TargetParser table were the outliers.
Moving the count out of FeatureISAVersion9_4_Common is required because
the emitter rejects a GPU whose feature closure sets a field twice.
Change-Id: I9b6fb9edafbf3f2c5eb834308cc8388604382160
Co-Authored-By: Claude Opus 5 (1M context) <noreply at anthropic.com>
[libc] Stop printing \0 in stdio/fputc_test.cpp (#220544)
This test defines two strings in the form of constant char[] arrays, and
then loops over the characters of each one using a range-for. This
iteration includes the implicit terminating \0, which is printed to the
output channels along with everything else. This is mildly inconvenient
because the presence of a \0 in a log file causes standard tools like
`grep` and `less` to default to treating it as binary.
Now each loop breaks before printing the NUL, so the characters sent to
the output streams are exactly the same as in fputs_test.cpp.
Also, while I was here, I moved the check of fputc's return value into
the loop, so that it's checked on every iteration instead of just the
final one, matching the other loop checking putchar. (Surely this was
intended all along; there was no comment explaining the difference.)
www/freenginx-devel: third-party modules management
- njs module security update to 1.0.1
Bump PORTREVISION.
Sponsored by: tipi.work
<ChangeLog>
nginx modules:
*) Security: fixed an access control bypass in js_access when an
asynchronous request body continuation threw an exception or
produced an unhandled rejection. Previously, nginx could continue
processing the request as though the js_access check had succeeded.
Thanks to Ta Duc Thien.
*) Security: fixed a worker process crash when reading
[48 lines not shown]
NAS-142731 / 26.0.0-RC.1 / Fix bond transmit hash policy never reaching the kernel (by Qubad786) (#19594)
## Problem
The stored hash policy string was translated into the `truenas_pynetif`
enum by member-name lookup. The stored values are `layer2`, `layer2+3`
and `layer3+4`, while the enum members are `LAYER2`, `LAYER23` and
`LAYER34` — `+` cannot appear in a Python identifier, so two of the
three resolved to `None`, and `getattr`'s default swallowed the miss
with no log or exception. The netlink attribute was then never packed
and the kernel silently kept its default `layer2`, so outbound traffic
could not spread across bond members. Every LACP/LOADBALANCE bond
defaults to `layer2+3`, so this was not limited to people who picked a
policy explicitly. `lacpdu_rate` goes through the identical construct
and only works because `SLOW` and `FAST` happen to be valid identifiers.
## Solution
Map the choice enums to library members explicitly, behind two helpers
that take the stored string and return an enum or `None`. Dict literals
rather than a name lookup, so a rename on the library side becomes a
[4 lines not shown]
NAS-142731 / 26.0.0 / Fix bond transmit hash policy never reaching the kernel (by Qubad786) (#19593)
## Problem
The stored hash policy string was translated into the `truenas_pynetif`
enum by member-name lookup. The stored values are `layer2`, `layer2+3`
and `layer3+4`, while the enum members are `LAYER2`, `LAYER23` and
`LAYER34` — `+` cannot appear in a Python identifier, so two of the
three resolved to `None`, and `getattr`'s default swallowed the miss
with no log or exception. The netlink attribute was then never packed
and the kernel silently kept its default `layer2`, so outbound traffic
could not spread across bond members. Every LACP/LOADBALANCE bond
defaults to `layer2+3`, so this was not limited to people who picked a
policy explicitly. `lacpdu_rate` goes through the identical construct
and only works because `SLOW` and `FAST` happen to be valid identifiers.
## Solution
Map the choice enums to library members explicitly, behind two helpers
that take the stored string and return an enum or `None`. Dict literals
rather than a name lookup, so a rename on the library side becomes a
[4 lines not shown]
Fix bond transmit hash policy never reaching the kernel
## Problem
The stored hash policy string was translated into the `truenas_pynetif` enum by member-name lookup. The stored values are `layer2`, `layer2+3` and `layer3+4`, while the enum members are `LAYER2`, `LAYER23` and `LAYER34` — `+` cannot appear in a Python identifier, so two of the three resolved to `None`, and `getattr`'s default swallowed the miss with no log or exception. The netlink attribute was then never packed and the kernel silently kept its default `layer2`, so outbound traffic could not spread across bond members. Every LACP/LOADBALANCE bond defaults to `layer2+3`, so this was not limited to people who picked a policy explicitly. `lacpdu_rate` goes through the identical construct and only works because `SLOW` and `FAST` happen to be valid identifiers.
## Solution
Resolve the library member by name through the existing choice enums, whose member names already line up: `XmitHashChoices.LAYER23` carries the value `LAYER2+3` and matches `BondXmitHashPolicy.LAYER23`. An unmappable value now raises rather than quietly becoming `None`.
The call sites catch that and log the offending value instead of letting it propagate, because `configure_bonds_impl` swallows per-bond exceptions — raising here would abandon the bond before its members are enslaved and its MTU is set, turning a degraded network into an absent one on the boot path.
(cherry picked from commit 72ff889f1943261945ada456bc6d27ed1f1416ce)
Fix bond transmit hash policy never reaching the kernel
## Problem
The stored hash policy string was translated into the `truenas_pynetif` enum by member-name lookup. The stored values are `layer2`, `layer2+3` and `layer3+4`, while the enum members are `LAYER2`, `LAYER23` and `LAYER34` — `+` cannot appear in a Python identifier, so two of the three resolved to `None`, and `getattr`'s default swallowed the miss with no log or exception. The netlink attribute was then never packed and the kernel silently kept its default `layer2`, so outbound traffic could not spread across bond members. Every LACP/LOADBALANCE bond defaults to `layer2+3`, so this was not limited to people who picked a policy explicitly. `lacpdu_rate` goes through the identical construct and only works because `SLOW` and `FAST` happen to be valid identifiers.
## Solution
Resolve the library member by name through the existing choice enums, whose member names already line up: `XmitHashChoices.LAYER23` carries the value `LAYER2+3` and matches `BondXmitHashPolicy.LAYER23`. An unmappable value now raises rather than quietly becoming `None`.
The call sites catch that and log the offending value instead of letting it propagate, because `configure_bonds_impl` swallows per-bond exceptions — raising here would abandon the bond before its members are enslaved and its MTU is set, turning a degraded network into an absent one on the boot path.
(cherry picked from commit 72ff889f1943261945ada456bc6d27ed1f1416ce)
NAS-142731 / 27.0.0-BETA.1 / Fix bond transmit hash policy never reaching the kernel (#19586)
## Problem
The stored hash policy string was translated into the `truenas_pynetif`
enum by member-name lookup. The stored values are `layer2`, `layer2+3`
and `layer3+4`, while the enum members are `LAYER2`, `LAYER23` and
`LAYER34` — `+` cannot appear in a Python identifier, so two of the
three resolved to `None`, and `getattr`'s default swallowed the miss
with no log or exception. The netlink attribute was then never packed
and the kernel silently kept its default `layer2`, so outbound traffic
could not spread across bond members. Every LACP/LOADBALANCE bond
defaults to `layer2+3`, so this was not limited to people who picked a
policy explicitly. `lacpdu_rate` goes through the identical construct
and only works because `SLOW` and `FAST` happen to be valid identifiers.
## Solution
Map the choice enums to library members explicitly, behind two helpers
that take the stored string and return an enum or `None`. Dict literals
rather than a name lookup, so a rename on the library side becomes a
static attribute error at import time instead of another silent `None`.
[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]
