snd_uaudio: Initialize mixer_lock with MTX_RECURSE
Fixes: fc9dc8482396 ("snd_uaudio: Lock usbd_transfer_start() in uaudio_mixer_ctl_set()")
PR: 296682
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
(cherry picked from commit 954001a9dd363da9184706657eb34f9622bb220f)
[SPIR-V] Erase dead functions in shader modules (#209672)
The LLVM offload test suite is current failing layout keyword
orientation tests. While initially appearing to be a layout problem in
the SPIR-V legalizer caused by matrix vector sizes exceeding 4, the root
cause is actually persistent dead function definitions in the SPIR-V
backend.
This behavior is standard for OpenCL, which relies on a linker to clean
up unused definitions; however, since shaders lack a linker and require
full inlining, we must handle this in a special shader only pass.
This change adds SPIRVFinalizeShaderLinkage (a shader-only analogue of
DXILFinalizeLinkage): internalize non-entry, non-exported helpers and
erase the dead ones. Globals are left alone since unreferenced externals
become interface OpVariables.
Fixes #201712
Assisted with Claude Opus 4.8
[clang] Drop stale `*-buildattr` module flag emission (#211021)
Module flags `sign-return-address-buildattr` and
`tag-stack-memory-buildattr` are never exercised elsewhere by existing
tests or code across the whole LLVM source tree, and there are no known
cases of them being used.
Moreover, the `sign-return-address-buildattr` flag emission was gated by
`ptrauth` target feature which does not actually exist: see
`AArch64TargetInfo::computeFeatureLookup()` and
`ARMTargetInfo::hasFeature(StringRef Feature)`. So, it was never
emitted.
This patch removes code responsible for these stale module flags
emission.
Note: the flags was previously introduced in
https://reviews.llvm.org/D112421
clang/AMDGPU: Stop passing redundant -target-cpu to cc1
Now that the exact target is encoded in the triple's subarch field,
-target-cpu is redundant. This avoids polluting the resultant IR with
unwanted "target-cpu" attributes. The net result is the desired codegen
when compiling libraries for a major subarch and linking it into a
program compiled for a specific arch. e.g., compiling for "gfx9-generic"
would pollute the IR with "target-cpu"="gfx9-generic", so codegen
would ultimately be performed for the generic target even after
linking into the concrete gfx9 cpu. The specialization will now be
achieved by merging the triples without the linker or optimization
passes needing to fixup function attributes.
clang: Start using new amdgpu subarch triples
Fixup invocations using --target=amdgcn + -mcpu to introduce
the subarch in the triple.
For offload toolchains, a single toolchain is constructed for the
top level amdgpu architecture, and the effective triple is used for
target specific tool invocations.
The specifics of the resource directory layout are tbd. This does
try to find resources in the subarch named directory. The paths
are searched at toolchain creation time, so that does not work
when there are multiple subarches.
Fixes #154925
Depend on websockify explicitly for SPICE display
## Problem
VMs with a SPICE display device shell out to the `websockify` binary at runtime (truenas_pylibvirt's display device runs `websockify --web /usr/share/spice-html5/ ...` to proxy the console to the web UI). We never declared that dependency though — websockify only got installed as a transitive `Recommends:` of `spice-html5`. Once truenas_build disabled `install_recommends` by default, the `truenas` package started installing with `--no-install-recommends`, so websockify silently stopped being pulled in and SPICE consoles broke.
## Solution
Add `websockify` to middlewared's `Depends`. It's a genuine hard runtime dependency of the SPICE path, so declaring it explicitly makes it come in regardless of the build's recommends setting and keeps us correct even if spice-html5's packaging changes.
TargetParser: Add Triple::getDefaultFloatABI (#210899)
In order to eliminate TargetOptions ABI fields the front and
middle end need to know what value the backend is going to choose
for the ABI properties. This is similar to how we have
getDefaultExceptionHandling and getDefaultWCharSize.
The clang driver seems to have a different notion of which targets
are default soft. This followed ARMTargetMachine as the authority.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
