MachineVerifier: Disallow kill flags on virtual registers
Kill flags are deprecated, and nothing introduces them on virtual
registers anymore. Reject them in the verifier to prevent new uses
from creeping back in. Kill flags on physical registers are still
permitted. There are still some lingering post-RA kill flag reliance.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
www/caddy: Update to 2.11.8
This contains numerous fixes to handling broken-by-design scenarios,
such as PHP. All users should update, especially if caddy drives a
php_fastcgi backend.
Read the Changes for details.
Changes: https://github.com/caddyserver/caddy/releases/tag/v2.11.8
CodeGen: Handle uses in unreachable blocks in LiveIntervals
Previously LiveIntervals had the unenforced assumption that the
function does not contain any unreachable blocks. A register which had
a definition somewhere but also a use in an unreachable block would
hit a "Use not jointly dominated by defs" assertion.
Avoiding no-unreachable-blocks as a hard requirement avoids assertions
in some pass configuration edge cases. In particular when the
MachinePipeliner is enabled in an optimized pipeline there could still
be unreachable blocks in an optnone function which would hit the
assert. Not handling unreachable blocks was also a large problem for
llvm-reduce's MIR support and was one of the main obstacles to landing
a basic block reduction.
Give a value live into an unreachable block a phi-def at the start of
the block, using the dominator tree to identify unreachable blocks.
ConnectedVNInfoEqClasses::Classify joins a component made only of
phi-defs in unreachable blocks with a component that has a real def;
[6 lines not shown]
libsecureboot: add support for more signatures
For 2027 we need to support new, stronger signatures and hashes.
Re-work Makefile.inc and local.trust.mk to define
VE_SIGN_URL_LIST or VE_SIGNATURE_LIST (can be derrived from
VE_SIGN_URL_LIST) containing tuples of sig/method/hash/flags and
for VE_SIGN_URL_LIST the same plus /url.
From VE_SIGNATURE_LIST we derrive VE_SIGNATURE_EXT_LIST used to populate
signature_ext_list which defines the order in which we look for
signatures for a manifest.
We also populate signature_info_list which maps a signature ext to the
needed hash and flags to indicate whether that hash needs to be repeated.
verify_sig will lookup signature_info_list, no match means not
supported. For asc we just call verify_asc() otherwise we call
verify_ec() or verify_rsa() depending on the key type found in the
[15 lines not shown]
nfs_clrpcops.c: Fix typo in commit db8444c1b7e4
Reported by: markj
MFC after: 1 month
Fixes: 884ee8d6c9b4 ("nfscl: Add some glue for client side NFS over RDMA")
[CIR] Make LoweringPrepare safe to rerun on C++20 module units (#237395)
LoweringPrepare builds the initializer of a C++20 module interface unit
from the 'cir.cxx_module_init_fn_name' and 'cir.cxx_module_imported_inits'
module attributes, but left them in place. Running the pass again on its
own output, e.g. on an emitted .cir file, rebuilt the initializer and asserted
with "function already has an entry block".
Drop both attributes once the initializer is built. This related to:
https://github.com/llvm/llvm-project/pull/234013
[CIR] Make LoweringPrepare safe to rerun on TLS globals (#237376)
LoweringPrepare builds the wrapper (`_ZTW*`) and init alias (`_ZTH*`) of
each thread-local global from its `tls_refs` attribute, but leaves the
attribute in place. Running the pass again on its own output, e.g. on an emitted
`.cir` file, rebuilds the wrappers and fails:
```
error: redefinition of symbol named '_ZTW2tl'
```
This was partially discovered in this discussion: #234013 . The solution
is to drop the `tls_refs` attribute after the pass consumes it.
[clang][CodeGen] Emit callee_type metadata for all indirect calls
CodeGenFunction::EmitCall only attached the call graph section callee_type
metadata to an indirect call when its caller asked for the emitted call
instruction through the callOrInvoke out parameter, because the emission
was nested in the block that stores it. Indirect calls emitted by callers
that do not pass callOrInvoke, such as the virtual destructor call of a
delete expression (emitVirtualObjectDelete -> EmitCXXDestructorCall), got
no callee_type metadata and therefore no indirect callee type identifiers
in the .llvm.callgraph section, so the call graph missed those edges.
Attach the metadata to the emitted call instruction regardless of whether
the caller asked for it.
Stacked on #230831.
Assisted-by: Claude
[clang][CodeGen] Identify virtual methods by their override chain root in the call graph section
A virtual call site is typed after the method named at the call site, but it
can reach any overrider of that method, and overriders may differ from it in
their covariant return type. In that case the `!callee_type` identifier of a
call through a base class pointer did not match the `!callgraph` identifier
of the overrider, and the call graph section missed the edge.
Identify every method of an override chain, at definitions, call sites and
thunks, by the type of the method that introduced the virtual function, so
that virtual calls through a pointer to any class of the hierarchy match the
overriders they can reach.
Stacked on #230838.
Assisted-by: Claude
[clang][CodeGen] Use the primary base chain for virtual method IDs
Identify a virtual method in the call graph section after the method it
overrides along the primary base chain of its class, as given by the record
layout. That is the vtable entry the method is placed in, which is not always
the first method it overrides.
Assisted-by: Claude
[clang][CodeGen] Attach a single callgraph type identifier to function definitions (#230838)
A function definition is annotated with its call graph section type identifier
twice, when its declaration is created (SetFunctionAttributes) and when its
body is emitted (SetLLVMFunctionAttributesForDefinition), so every
defined function carries two identical `!callgraph` attachments:
define void @foo() #0 !callgraph !3 !callgraph !3 {
Replace the attachment instead of adding a second one, so that a
function carries exactly one identifier. The `.llvm.callgraph` section is
unaffected, the AsmPrinter only uses the first identifier of a function.
Assisted-by: Claude
nodejs: bump libuv BUILDLINK_API_DEPENDS minimum to 1.52
Recent releases expect the following feature in libuv, or builds will
fail due to the missing field.
* unix,win: add f_frsize field to uv_statfs_t (Ben Noordhuis)
SafeStack: Use RuntimeLibcallsInfo signatures for libcalls
Take the function type, attributes and calling convention of
__stack_chk_fail and __safestack_pointer_address from RuntimeLibcallsInfo
instead of constructing them by hand. These now use arm_aapcscc on AAPCS
targets.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[NFC] Update check lines for nofpclass-multiunitfptype.ll (#238989)
Runs `update_test_checks.py` for `nofpclass-multiunitfptype.ll` since I
forgot to re-run them in
https://github.com/llvm/llvm-project/pull/223296
LinuxKPI: set pci_dev msi_cap and msix_cap
Linux drivers find their MSI and MSI-X registers through pdev->msi_cap and
pdev->msix_cap, which hold where those capabilities start in PCI config
space. LinuxKPI never set them, so they stayed 0, and every access meant
for the MSI registers went to the start of config space instead.
Drivers using these fields, e.g. ath11k and amdgpu, are affected.
Fill in both fields from the capability offsets that the native PCI code
already records.
Reviewed by: dumbbell
Differential Revision: https://reviews.freebsd.org/D61125
Event: NetApp/Vendor Summit Hackathon 202611
AMDGPU: Remove kill flags on virtual registers from MIR tests (#236977)
Soon the verifier will disallow this. Delete redundant tests which
only differed from others by kill flag uses. twoaddr-bundle.mir relied
on the input kill flags in TwoAddressInstruction, so compute
LiveIntervals first as the real pipeline does.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[mlir][OpenACC] Unwrap multi-block regions in ACCRegionUnwrapConversion (#236289)
Follow-up to #236052, reworked based on @razvanlupusoru's review.
`ACCRegionUnwrapConversion` inlines the region of a structured construct
like `acc.host_data` or `acc.data` into the parent block when
specializing for host or device. It asserted that the region has exactly
one block, but these ops accept any region, so a multi-block body
crashed `acc-specialize-for-host` and `acc-specialize-for-device`.
A multi-block region is now wrapped in `scf.execute_region` with the
existing `wrapMultiBlockRegionWithSCFExecuteRegion` utility, and an
empty region just erases the op. `acc-specialize-for-device` now
declares SCF as a dependent dialect, like `acc-specialize-for-host`
already does.
The canonicalizer still bails out on multi-block regions, so the OpenACC
dialect does not pick up a dependency on `cf`.
Fixes #236287
DwarfEHPrepare: Use RuntimeLibcallsInfo signature for the rewind libcall
Report an error if no rewind libcall is available, rather than
emitting a call to a function with an empty name.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[CIR] Pass the promise address to cir.coro.intrinsic.id (#236293)
CIRGen was emitting `cir.coro.intrinsic.id` with a null promise operand.
Classic codegen fills it in with the promise alloca once the promise
variable has been emitted. Do the same in CIRGen, bitcasting the promise
address to `!cir.ptr<!void>` to match the expected type.
AtomicExpand: Use RuntimeLibcallsInfo signatures for atomic libcalls
Take the function type and attributes of the emitted __atomic_* calls
from RuntimeLibcallsInfo instead of building them by hand.
This fixes missing extension attributes on the value operand and
result of the sized variants, which are unsigned integers of the
access size. On targets whose C ABI extends narrow integer arguments,
such as RISC-V and ARM, the callee could see unextended high bits. i8
and i16 values now get zeroext, and i32 values get signext on
RV64. Callers can also rely on the extended return value, which
removes redundant extensions after some calls.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
RuntimeLibcalls: Use <2 x i64> for i128 libcall types on Win64 (#238221)
Win64 passes __int128 by reference and returns it in XMM0. i128 uses
GPR pairs, and <2 x i64> uses the correct vector register. This
matches the type AtomicExpand and clang uses for these functions.
Also fix AtomicExpand to use the correct type for UEFI (which should
eventually use the type information in RuntimeLibcallsInfo).
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
