[clang][APINotes] Do not drop attributes applied after a definition (#222902)
API notes are matched against whichever declaration the compiler
reaches, which can be a redeclaration that follows the definition. When
the definition lives in one module and the annotated redeclaration in
another, that is exactly what happens: checkNewAttributesAfterDef()
warns "attribute declaration must precede definition" and erases the
attribute, so the annotation is silently lost.
The warning exists to tell users that an attribute they wrote has no
effect. Attributes from API notes are not written in the source, so the
warning has nowhere to point and there is nothing for the user to
correct. Skip attributes with an invalid location, alongside the
existing exceptions.
rdar://186930250
Co-authored-by: Gabor Horvath <gaborh at apple.com>
converters/simdutf: remove stray patch
This was left over after a wrong rebase (mid-air collission).
Fixes: 81f18785a4d12bf1d01751f5e54643cf9afe9443
Reported by: Einar Bjarni Halldórsson <einar at isnic.is>
PR: 298403
Event: EuroBSDcon Devsummit 2026
[AMDGPU] Remove the VGPR-alignment check from the machine verifier (#219230)
The machine verifier had a check that a 64-bit-or-wider VALU operand uses an even-aligned VGPR/AGPR tuple on subtargets that require it. Now that most operands express their alignment requirement through `_AlignTarget`, the check is redundant: the generic verifier already rejects a register that does not fit its operand's class.
This removes the "Subtarget requires even aligned vector registers" and "Operand has incorrect register class" diagnostics, leaving the generic "Illegal virtual/physical register for instruction".
The image `vaddr` parity check is left in place: single-VGPR alignment cannot be expressed as a register class, so it still needs an explicit check.
[VPlan] Consider VPDerivedIV & VPScalarIVSteps for forced costs. (#222918)
Now that we compute VPDerivedIV and VPScalarIVSteps costs directly in
VPlan, also account for them with forced costs. They never have
underlying instructions, so always add the forced cost for them.
Previously they would have been accounted for in precomputeCosts.
PR: https://github.com/llvm/llvm-project/pull/222918
kobj: allow multiple inheritance with per-class softc
Add support for hierarchical softc layout so that a leaf class and each
of its base classes owns a private softc region inside a single
allocation.
device_get_softc_class(dev, cls) returns a pointer to the softc that
belongs to the requested class. The classic device_get_softc() still
returns the leaf softc and remains fully compatible with existing
drivers.
Existing drivers are unaffected; they simply obtain a slightly larger
softc block when they inherit from base classes.
MFC after: 2 months
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D59115
[OpenMP] Don't reserve the generic mode warp on SPIR-V (#222763)
#218790 widened a generic mode kernel's thread bound by a warp so that
the main
thread has one of its own. The bound is what lets the runtime's own warp
addition through: `getEffectiveNumThreads()` adds a warp and then clamps
to the
bound, so before that change the addition was clamped straight back off,
which
is why a `thread_limit` below one wavefront ended up with no workers.
Widening
the bound is the fix, and it is also what makes every generic mode
kernel launch
a warp wider than it used to.
`hasGridValue()` covers SPIR-V, so that geometry change reached Level
Zero.
@sarnex reports hangs and intermittent failures there and asked about a
revert
[48 lines not shown]
[ARM] Prevent use of the VFP calling convention when +soft-float is enabled (#221434)
This check was implemented in #111334 for -fpregs and Thumb1 cases, but
+soft-float is a distinct case that can lead to the same silent calling
convention mismatches.
Fix tests that were using +soft-float and the VFP calling convention.
Clarify comment about hard-float support on mve+nofp cores.
bsd.sites.mk: use static CDN to download rust crates
static.crates.io is the recommended upstream download
path. This avoids "403 Forbidden" rate limiting results
when trying to download crates too fast. This also
seems to improve download speeds/latency.
As per https://crates.io/data-access#crate-content,
> Crates can be downloaded directly from the crates.io CDN
> [...]
> No rate limits apply to static.crates.io at present.
And as per https://crates.io/data-access#api,
> you are welcome to use the crates.io API provided you abide by the following limits:
> * A maximum of 1 request per second, and
> * A user-agent header that identifies your application.
[2 lines not shown]
Updated sysutils/xenkernel420 to 20260911
Updated sysutils/xentools420 to 20260911
Updated sysutils/xenstoretools to 20260911
Updated sysutils/xenkernel418 to 20260911
Updated sysutils/xentools418 to 20260911
As suggested by deraadt@, split execvp(3) out of execv(3),
since the two groups of functions are sufficiently different and
the semantics and error handling of the *p* functions is sufficiently
complicated to make the combined manual page confusing.
In particular, the early sentence about "the initial argument"
was outright wrong and hard to fix without causing other problems.
This commit only does the minimum required for the split,
with no text changes yet, but it will allow subsequent improvements
in both pages.
