[VPlan] Simplify live-ins via SCEV in epilogue plan (#215774)
The main plan's buildVPlan0 already simplifies live-ins via SCEV, and
remaining opportunity is just in the epilogue.
CodeGen: Remove TargetOptions::FloatABIType (#215796)
This is now fully replaced with the "float-abi" module flag.
If the module flag is not present, the default is computed
from the triple. Consumers are updated to read the module flag.
RuntimeLibraryAnalysis now defers analysis until run() on a Module,
instead of during the pass constructor as before. This requires copying
all of the remaining relevant TargetOptions so they are available
when the module is seen.
Unfortunately, ARM still depends on TargetOptions for determining
the float-abi. -target-abi=aapcs16 still changes the default float-abi,
but an explicit module flag wins.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
stand: set st_dev/st_ino in the loader's ZFS stat for veriexec
The loader's ZFS implementation never set st_dev or st_ino in
zfs_dnode_stat(). With an uninitialized struct stat, veriexec's device
comparison in lib/libsecureboot/veopen.c read stack garbage and skipped
the matching manifest entry, failing with a spurious "no entry" on ZFS
root under UEFI Secure Boot.
Rather than zeroing the device (which would break veriexec's ability to
tell apart the same path on different datasets), populate st_dev and
st_ino with the same intrinsic identifiers the kernel uses:
- st_dev = the dataset's ds_fsid_guid (as the kernel does via
dmu_objset_fsid_guid()/dsl_dataset_fsid_guid()), already read in
zfs_mount_dataset() and now propagated through struct zfsmount.
- st_ino = the object number resolved in zfs_lookup(), propagated
through struct file (the loader's equivalent of the kernel's z_id).
dev_t and ino_t are 64-bit on FreeBSD, so both are assigned directly
[14 lines not shown]
RuntimeLibcalls: Stop providing __powitf2 on MSVCRT
MSVCRT does not provide the powi helpers, so gate the fp128 __powitf2 on
isNotOSMSVCRT alongside the f32/f64 __powisf2/__powidf2, instead of adding it
unconditionally. The unconditional add was a hack to satisfy a test that
expected a wrongly-typed powi call on windows-msvc.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
RuntimeLibcalls: Fix wrongly typed x87/fp128 long double libcalls on x86
The x86 and default libcall sets gated the l-suffixed long double libm
functions on OS conditions rather than the long double format. This
incorrectly provided the f80 libcalls on targets whose long double is not x87
(Windows-MSVC, UEFI, x86_64 Android), double-provided frexpl/ldexpl on musl,
and provided the fp128 sincosl on targets using double as long double (m68k).
Gate the l-suffixed libm math on the long double format, mirroring the earlier
AArch64 fix: x87 targets get the _f80 calls, fp128 targets the _f128 calls, and
double targets neither. The compiler-rt f80 helpers (__extendxftf2, __fixxfti,
__powixf2, ...) are keyed to the x86_fp80 IR type, not the long double format,
so they stay unconditional on x86.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
math/octave-forge-octave_ffmpeg_free: Update to 2.0.0.
- Build will work when ffmpeg updates to version 9.
PR: 297384
Reported by: Daniel Engberg <diizzy at FreeBSD.org>
<If someone else reported the issue>
[libc] Implement sys/sysmacros.h Linux header. (#216865)
`<sys/sysmacros.h>` is a Linux header with routines for managing device
number (construct device ID from major/minor IDs) - and contains
functions `major`, `minor`, and `makedev`.
Implement them as simple macro that redirect to the llvm-libc
entrypoints with the same names. This would allow us to have more type
safety (and explicitly specify argument/return types in our entrypoint
implementation), and opens the door for defining those macro in a
different way on other systems, wrapping the invocation of our
implementation with type conversions, if needed (e.g. FreeBSD versions
of these functions use "int" instead of "unsigned int" and are supposed
to be provided by a different header - `<sys/types.h>`).
[AMDGPU] PromoteAlloca: split scalar accesses that span several elements
promoteAllocaToVector already splits a *vector* access across several
elements when it is a multiple of the element size, but a *scalar* access
had to be bitcastable to the element type, so an i64 load from an alloca
promoted to <8 x i32> was rejected as "not a supported access type" and
the object stayed in scratch.
Accept a scalar access that is a whole multiple of the element size and
route it through the existing subvector path, which already builds the
value from consecutive elements and bitcasts. Accesses with padding are
still rejected, since splitting those would put the pieces at the wrong
offsets, as are non-integer non-float types.
[clang-repl] Keep access to private nested types in out-of-line members (#217040)
Under `-fincremental-extensions`, `Parser::isCXXDeclarationStatement`
parses the nested-name-specifier of its `tok::identifier` branch with
immediate access checks. Valid out-of-line constructor, destructor,
method, and operator definitions that name a private nested type are
rejected during disambiguation:
```cpp
class C { struct S { S(); }; };
C::S::S() {} // error: 'S' is a private member of 'C'
```
The declaration context is not known during disambiguation, so the check
must be delayed. f6f0503673b7 (#178842) fixed the same problem only in
the keyword/typedef fallthrough branch.
Suppress access checks during the identifier-branch scope parse and
revert unannotated. The recognized declaration shapes redo the checks in
[9 lines not shown]
[AMDGPU] PromoteAlloca: flatten homogeneous structs to vectors
getVectorTypeForAlloca() peeled nested ArrayType and one inner
FixedVectorType, but stopped at any StructType. An alloca of an array of
structs was therefore rejected with "Cannot convert type to vector" and
fell back to scratch, even when the struct was a trivial wrapper around a
scalar.
Peel structs too, but only when every field has the same type and the
struct has no padding, so flattened elements keep the byte offsets the
surrounding index arithmetic assumes. Structs with differing field types
or with padding are left alone.
