[flang][openmp] Add semantic checks in THREADPRIVATE/DECLARE TARGET (#209084)
The problem is that the automatic object was used as the
threadprivate argument.
Solution:
From the documentation (J3/24-007):
> C814 An automatic data object shall not have the SAVE attribute.
> C862 The SAVE attribute shall not be specified for a dummy argument,
> a function result, an automatic data object, or an object
> that is in a common block.
The bare SAVE statement makes any valid local variables tagged
with the SAVE attribute. As the restriction mentioned above, the
automatic object cannot have a SAVE attribute and shall not be
used as the THREADPRIVATE argument. This patch adds semantic
checks for dummy arguments, function results, and automatic data
objects in both THREADPRIVATE and DECLARE TARGET directives.
[4 lines not shown]
[flang] Statement function dummy names do not clash with host or unreferenced global names (#212396)
The check added for F2023 19.4 p2 (statement function dummy argument
name may be the same as an accessible name only if that name is a scalar
variable) looked the name up through the whole host scope chain and,
failing that, in the global scope. Both lookups overshoot what is
"accessible" in the scoping unit:
* Per F2023 19.5.1.4 p2 item (11), the appearance of a name as a
dummy-arg-name in a stmt-function-stmt makes any host entity of that
name inaccessible by host association throughout the scoping unit, so a
host entity can never conflict with the dummy.
* A global entity to which the scoping unit makes no reference at all is
not accessible in it; otherwise conformance would depend on whether
unrelated program units happen to be compiled in the same file.
This caused bogus errors on conforming code such as
```
[17 lines not shown]
[Clang] Treat line directives as header names. (#211512)
We treated line directives as being unevaluated string literal. However
- The standard has no such restriction - or rather the standard has
different, unclear restriction (https://wg21.link/CWG2693)
- Because of Windows paths, it's common for "C:\foo\bar" to be used, and
these should not form escape sequences.
To remain consistent with other implementations, we do not allow `#line
1 <>` at this time. We do however support `#line 1 ""` to avoid a
breaking change.
Fixes a regression introduced by #201413
[AMDGPU] Limit register pressure of pipelined loops
Opt AMDGPU into the generic MachinePipeliner register-pressure detector via
shouldLimitRegPressure(), and supply an occupancy-aware verdict in
isScheduleRegPressureTooHigh(): reject a schedule whose SGPR or VGPR/AGPR
pressure would drop the kernel below its target occupancy, or exceed a
register class's addressability cap. On gfx90a+ VGPRs and AGPRs share one
register file, so their combined footprint is bounded together. These match
the limits GCNSchedStrategy enforces.
AMDGPU: Remove xnack and sramecc subtarget features
Now that these are controlled by module flags, the subtarget
features were just used for assembler and disassembler controls.
Now that the assembler and disassembler can infer these from
the e_flags and target directives, they are no longer necessary.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
[MachinePipeliner] Add PipelinerLoopInfo hooks to reuse the reg-pressure detector
The generic MachinePipeliner register-pressure detector (added in #74807)
was only reachable via the global -pipeliner-register-pressure flag, which
cannot be enabled per-target, and it judges pressure against generic
per-pressure-set limits. Add two PipelinerLoopInfo hooks so a target can
reuse that detector on its own terms:
- shouldLimitRegPressure(): A target can opt the loop into the detector without
the global flag.
- isScheduleRegPressureTooHigh(MaxSetPressure): let the target replace the
detector's generic per-pressure-set limit check with its own verdict, or
return nullopt to keep that check.
Both hooks default to preserving current behavior, so targets that do not
override them are unaffected.
Exercised by the AMDGPU adoption in the following commit.
[AMDGPU] Raise the MachinePipeliner MII cap via a target hook
The pipeliner rejects any loop whose minimum initiation interval (MII)
exceeds -pipeliner-max-mii, default 27. That is far too low for real
AMDGPU loops: resource-bound GEMM/attention bodies routinely have an MII
well above 27 and are dropped before scheduling even starts.
Add a PipelinerLoopInfo::getMaxMII() hook so a target can raise the cap,
and override it to 256 for AMDGPU. The generic default is unchanged, and
an explicit -pipeliner-max-mii still takes precedence.
The cap of 256 is chosen from the II distributions of two AMDGPU
workloads.
Composable Kernels:
II range count pct
0- 24 2305 36.7%
25- 49 1681 26.8%
50- 99 1582 25.3%
[13 lines not shown]
p0f: Import p0f-2.0.8nb1
P0f v2 is a versatile passive OS fingerprinting tool. P0f can identify the
operating system on:
- machines that connect to your box (SYN mode),
- machines you connect to (SYN+ACK mode),
- machine you cannot connect to (RST+ mode),
- machines whose communications you can observe.
P0f can also do many other tricks, and can detect or measure the following:
- firewall presence or masquerading (useful for policy enforcement),
- presence of a load balancer setup,
- the distance to the remote system and its uptime,
- other guy's network hookup (DSL, OC3, avian carriers) and his ISP.
Imported from security/p0f.
[AMDGPU] Add MachinePipeliner support for AMDGPU
Implement the target hooks to enable MachinePipeliner for AMDGPU. The
pass is off by default and can be enabled with -amdgpu-enable-pipeliner
at -O2 and above.
Only uniform, single-basic-block counted loops with a scalar (SCC)
back-edge are pipelined; loops with a divergent (VCC/EXEC) back-edge, or
containing calls or inline asm, are rejected. Code is generated by the
default modulo schedule expander (DFA, window scheduler, and MVE
expansion are disabled for AMDGPU).
Validated on gfx942 and gfx950 with Composable Kernel and Triton workloads.
[flang][cuda] Restrict managed data transfers to whole-array assignments (#212593)
Assignments involving managed or unified data are lowered to
`cuf.data_transfer`, a synchronous copy. The predicate only excluded
scalar left-hand sides, so array sections were transferred too, turning
a loop that assigns one section per
iteration into a sequence of blocking copies.
Key the decision on the managed operand instead: a transfer when the
managed variable or array is whole, host code when it is a section or an
element. Managed data is host-addressable, so the host assignment is
safe. Managed function results and assignments involving device memory
are unaffected.
This is the behavior specified in the CUDA Fortran Programming Guide
3.4.1:
> An assignment statement where the right hand side is a managed array
section and
[2 lines not shown]
sysutils/rpi-firmware: Update to 1.20260521
Update the Raspberry Pi firmware binaries to the latest upstream release
to provide native support for GPT partition schemes.
This update is related to the NanoBSD Reimagined GSoC 2026 project,
which aims to standardize on GPT layouts across all supported embedded
platforms.
Reviewed by: manu
Differential Revision: https://reviews.freebsd.org/D58197
GlobalISel: Don't use GISelMatchGenericTypes for floating point opcodes
AMDGPU ends up with same input pattern that check for v2s16 so the one
that is first in tablegen table always fires (it was v2f16 in this case).
Should explictly check for f16/bf16 and v2f16/vsbf16.
NAS-141996 / 26.0.0-BETA.3 / Fix broken unit tests (by anodos325) (#19439)
This commit fixes some broken unit tests for directory services.
Original PR: https://github.com/truenas/middleware/pull/19438
Co-authored-by: Andrew Walker <andrew.walker at truenas.com>
NAS-141996 / 26.0.0-RC.1 / Fix broken unit tests (by anodos325) (#19440)
This commit fixes some broken unit tests for directory services.
Original PR: https://github.com/truenas/middleware/pull/19438
Co-authored-by: Andrew Walker <andrew.walker at truenas.com>
Stop a container in any active state when tearing down tests
## Problem
The `container` fixture only force-stops the container on teardown when it is RUNNING, but delete now refuses any container that is not STOPPED. A test that leaves one suspended fails in teardown rather than cleaning up.
## Solution
Stop it whenever it is not already STOPPED.
Say what a recursive container destroy removes
## Problem
The comment above the destroy in `do_delete` explains `recursive=True` as being about the container's own snapshots. It also destroys anything cloned from those snapshots, which is a good deal more than the comment suggests.
## Solution
Say so.
