Fix error reported by -Wrange-loop-construct (#211657)
One system I'm building on adds -Wrange-loop-construct to the list of
-W<group> options. This results in the compile error:
```
/home/perry/llvm/Woz/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUMemoryUtils.cpp:37:19: error: loop variable '[ID, N]' creates a copy from type 'std::pair<unsigned int, llvm::MDNode *> const' [-Werror,-Wrange-loop-construct]
for (const auto [ID, N] : MD) {
^
/home/perry/llvm/Woz/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUMemoryUtils.cpp:37:8: note: use reference type 'std::pair<unsigned int, llvm::MDNode *> const &' to prevent copying
for (const auto [ID, N] : MD) {
^~~~~~~~~~~~~~~~~~~~
&
1 error generated.
```
[LLVM] Auto-upgrade legacy coro.end results (#211081)
When `llvm.coro.end` and `llvm.coro.end.async` changed from returning
`i1`
to returning `void` in #159278, the bitcode auto-upgrader continued to
handle
only the older two-argument `llvm.coro.end` form.
As a result, valid bitcode produced before that transition fails
verification
when a current LLVM ThinLTO backend materializes a module containing
either:
* the three-argument, `i1`-returning `llvm.coro.end`; or
* the `i1`-returning `llvm.coro.end.async`.
Teach `AutoUpgrade` to recognize both legacy declarations and rebuild
their
calls with the current `void`-returning intrinsics. If the legacy result
[15 lines not shown]
Update to 0.06
Upstream changes:
0.06 2026-05-22
- Update to libgumbo 0.13.2
- Migrate to the new libgumbo repo on codeberg
- Add Best Practical as co-maintainer and document RT bug tracker
- Move module repo to https://github.com/bestpractical/alien-libgumbo
news: add the ports reset script
Following the freeze of the ports tree announced on 2026-07-22, this
script may be used to correct branches that contain the offending
object. Note that it contains some commit hashes that need to be
replaced if your local branch has changes included that alter these;
instructione are included inside.
The script was originally written by glebius@, with slight modifications
by kevans@ and dhw@.
Reviewed by: adrian, dhw, glebius, lwhsu (all previous version)
Differential Revision: https://reviews.freebsd.org/D58417
getpgrp(2), getsid(2): allow to call on zombies
Also be more protective in getsid().
Reported by: arrowd
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differrential revision: https://reviews.freebsd.org/D58393
[lldb] Fix qSpeedTest radix mistake, make number parsings explicit (#211495)
The documentation for qSpeedTest says
```
send packet: qSpeedTest:response_size:response-size;
read packet: data:<response data>
response-size is a hex encoded unsigned number up to 64 bits in size.
```
debugserver implements qSpeedTest as per this documentation, but lldb
sends the number in decimal (base 10), and lldb-server parses it as base
10. I changed lldb and lldb-server to base 16. This is a maintenance
command used by lldb developers exclusivley, so IMO I'm not handling a
migration for old/new servers or defining a new packet or key. I was
running some packet transmission tests with debugserver and noticed
debugserver was sending much larger packets than requested; that's the
kind of failure you see when there is a mismatch.
[21 lines not shown]
[OpenMP] Propagate PRESENT to pointee entries in mapper codegen
Extend mapper map-type-modifier propagation to include PRESENT, gated to entries
that have an attach pointer (HasAttachPtr): the pointee data, whose storage
differs from the struct being mapped. A present modifier on the outer map/motion
clause must require that pointee to be present on the device; the present-check
on the struct's own storage does not cover it.
The propagation is gated on a new PropagatePresentToPointee argument to
emitUserDefinedMapper, set by callers only for OpenMP >= 6.0. Before 6.0 the
present modifier is treated as not applying to the pointee: the spec committee
confirmed the divergence between the present 'motion' modifier (to/from) and the
present map-type modifier (map) was unintentional, to be fixed as an OpenMP 6.0
erratum, so for 5.2 present is ignored for the pointee for both map and to/from.
Regular struct members receive only ALWAYS/DELETE/CLOSE; attach-ptr/pointee
entries additionally receive PRESENT at OpenMP >= 6.0. ATTACH entries receive no
modifier bits.
[8 lines not shown]
[OpenMP] Track attach-ptr entries in mapper codegen (HasAttachPtr)
Add a per-entry HasAttachPtr flag to MapInfosTy. It is set for entries that
have an attach pointer (and thus an accompanying ATTACH entry linking that ptr
to its pointee): pointee/combined entries whose storage differs from the struct
being mapped. It is NOT set for the ATTACH entries themselves.
In emitUserDefinedMapper, entries with HasAttachPtr (or the ATTACH bit, or the
Flang/MLIR PreserveMemberOfFlags) do not receive a new outer MEMBER_OF: pointee
data occupies a different storage block than the struct, and ATTACH entries
just link a ptr to its ptee. Existing inner MEMBER_OF bits are still shifted.
Clang (CGOpenMPRuntime) and the MLIR translator populate HasAttachPtr in
parallel with the other per-entry arrays; the MLIR/Flang side currently pushes
false with a TODO to set it for pointee-storage entries (e.g. s%p(0:10)) and
eventually drop PreserveMemberOfFlags in favor of it.
Co-Authored-By: Claude Opus 4.8 <noreply at anthropic.com>
[OpenMP] Propagate ALWAYS/DELETE/CLOSE map-type modifiers to mapper entries
Per OpenMP 6.0:281:34, when a map/motion clause uses a mapper modifier, any
map-type-modifying modifier on that clause applies to each map the declared
mapper specifies. Propagate the ALWAYS, DELETE, and CLOSE bits from the outer
clause's map type into every entry emitted by emitUserDefinedMapper, except
ATTACH entries (ATTACH|ALWAYS is reserved for attach(always), and the other
bits have no meaning for an ATTACH entry).
PRESENT is intentionally NOT propagated here: it requires distinguishing
pointee entries from the struct's own storage and is handled in a follow-up.
Co-Authored-By: Claude Opus 4.8 <noreply at anthropic.com>
FreeBSD: Enable Direct IO by default
Commits 25eb538778, 178682506f, and 8dc452d907 resolve the remaining
known issues with Direct IO on FreeBSD. Enable it by default on all
platforms.
Signed-off-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Closes #16761
ZTS: add scrub-from-txg into the runfile
zpool_scrub_txg_continue_from_last (#16301) and
zpool_events_scrub_txg_continue_from_last (#17432) are listed in
Makefile.am but not referenced in common.run thus ignored into CI
and ZTS
The test defines that the last_scrubbed_txg is initially 0, which is
only valid on a pool with no scrub history. Recreate the pool so the
test does not depend on its position in the runfile.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Christos Longros <chris.longros at gmail.com>
Closes #18785
Update to 0.20
Upstream changes:
0.20 2026-05-04 09:50:45 PDT
- Fix mirror() in Curl and Wget backends to not create a local file on
failed HTTP requests, matching HTTP::Tiny's behavior. Fixes #27
- Fix Wget mirror() to properly return HTTP error status codes (e.g. 404)
instead of converting them to 599 internal errors
dnode_sync: Relax constraint on indirect freeing
One of the roles of the dnode sync thread is freeing. There are two
modes of this operation: freeing a portion of an object, and freeing
the object itself.
Freeing is handled by `free_children()`. This function verifies that
if the dnode has children there must be at least one marked as dirty
before proceeding to recursively free the tree of block pointers.
As described in a comment, this VERIFY is overly strict. In practice,
children may not be marked as dirty when the dnode itself is being
freed. Relax the VERIFY slightly by avoiding the VERIFY when indirect
blocks are to be immediately freed, to more closely match the comment
motivating the VERIFY.
While here, clarify the logic of the test by using VERIFY_IMPLY instead
of chaining multiple tests.
[5 lines not shown]
