[libc++] Require the exact assignment expression to be trivial in __uninitialized_allocator_copy_impl
__uninitialized_allocator_copy_impl has an optimization that replaces allocator_traits::construct with std::copy for raw pointer ranges when the element type is trivially copy constructible and trivially copy assignable.
The copy-assignment trait only checks whether assignment from const T& is trivial. That is weaker than the expression used by std::copy, which evaluates *out = *in. If overload resolution selects a different non-trivial assignment operator for that expression, std::copy can call that operator on uninitialized storage.
Check is_trivially_assignable<_Out&, _In&> instead. This matches the assignment expression used by std::copy, preserves the optimized path when that assignment is actually trivial, and falls back to placement construction otherwise.
Add a regression test with a type whose defaulted copy assignment is trivial but whose templated assignment operator is selected for non-const lvalue sources.
Tested with:
~/llvm-project/build-libcxx-fresh/bin/llvm-lit ~/llvm-project/libcxx/test/libcxx/memory/uninitialized_allocator_copy_template_op_assign.pass.cpp ~/llvm-project/libcxx/test/libcxx/memory/uninitialized_allocator_copy.pass.cpp -q
[libc] Disable -march=native in CI to fix sccache poisoning (#196560)
-march=native is incompatible with shared build caches because sccache
treats it as a literal string. Object files compiled on one CPU model
get silently served to runners with a different CPU, causing SIGILL
crashes in the opt_host memory tests.
Made LIBC_COMPILE_OPTIONS_NATIVE a CMake cache variable so CI can
override it. Both overlay and fullbuild workflows now pass
-DLIBC_COMPILE_OPTIONS_NATIVE="" to disable -march=native. Local
developer builds are unaffected and still default to -march=native.
Reverted the per-CPU cache key approach from #196477 in favour of this
fix, which addresses the root cause.
Bumped sccache key versions (v2) in both workflows to invalidate the
poisoned caches.
Assisted-by: Automated tooling, human reviewed.
NAS-140905 / 26.0.0-RC.1 / Stop migration 0015 from forcing MISSION_CRITICAL profile (#18916)
Two small fixes for issues present on Goldeye:
- Migration `0015_update_profile.py` was force-setting `update.profile =
MISSION_CRITICAL` on every enterprise system regardless of the running
version's actual profile. A user upgrading from Fangtooth to a Goldeye
`EARLY_ADOPTER` release (e.g. 25.10-RC.1) was silently locked into
`MISSION_CRITICAL`. Once 25.10.3 (the first `MISSION_CRITICAL` Goldeye
release) shipped, `update.status` started returning a profile mismatch
and the `CurrentlyRunningVersionDoesNotMatchProfile` alert fired.
Migration is now a no-op; `update.config` already auto-populates
`profile` from `current_version_profile()` on first read.
- The mismatch alert was resolving profile names through
`update.profile_choices`, which filters out profiles outside the user's
product type (enterprise hides `DEVELOPER`/`EARLY_ADOPTER`). When the
running profile fell outside that filter, the alert text rendered
`<Unknown>` instead of the friendly name. Switched to resolving via
`UpdateProfiles[...].describe().name`.
[3 lines not shown]
[DWARFLinker] Don't duplicate classes with in-class static decls (#196442)
An in-class static declaration was forced to PlainDwarf placement and
cascaded that up to its enclosing class. If the class was already in the
type table via the out-of-line definition's specification, it ended up
with Both placement and cloneDIE emitted two copies. Keep in-class
static declarations in the type table so they stay with their enclosing
type.
[libc] Skip targets with unavailable __ONLY flags (#196637)
When SKIP_FLAG_EXPANSION strips a flag that has the __ONLY modifier,
remove_duplicated_flags drops the flag from the list. This leaves
expand_flags_for_target with an empty flag list, causing it to create a
plain (non-flag) target. The __ONLY semantics, "only build this target
with the flag active", are silently violated.
On x86-64 CI runners without FMA, this results in cosf_float_test and
sinf_float_test being built and linked without FMA. The sincosf
algorithm was tuned assuming fused multiply-add precision, so the
unfused x*y+z fallback exceeds the 3.5 ULP tolerance (57 ULP for cosf,
12 ULP for sinf).
Added an early return in add_target_with_flags: if any flag with the
__ONLY modifier would be skipped, the target is not generated.
Assisted-by: Automated tooling, human reviewed.
[DWARFLinker] Deduplicate .debug_frame CIEs across LinkContexts (#195393)
Each LinkContext held its own EmittedCIEs map, so linking the same
object twice (or two objects with identical CIEs) produced one CIE per
LinkContext instead of one shared CIE. Hoist the registry to linker
scope and split emission into three phases so contexts can emit their
frames concurrently while still sharing one deduplicated CIE pool:
1. Scan (parallel, during link). scanFrameData() records the unique CIEs
referenced by retained FDEs, in first-reference order, into
FrameScanResult::CIEs. scanAndUnloadInput() chains the scan in front of
the existing input-unload so the DWARFContext can be released before the
post-link emit pass.
2. Merge (serial, after link completes). registerCIEs() walks each
context's scanned CIEs in ObjectContexts order and try_emplaces them
into the linker-wide CIERegistry. The first LinkContext to reference a
CIE becomes its owner and reserves a local offset in its own
.debug_frame section; later contexts only learn the owner's section and
[14 lines not shown]
experimental expose vector contract lowerings to have multiple options
Signed-off-by: Eric Feng <Eric.Feng at amd.com>
add more tests and parallelarith
Signed-off-by: Eric Feng <Eric.Feng at amd.com>
Keep contract lowering filter patch focused
Reuse filter constraint naming for contract lowering policy
Rename vector contract default filter
[VPlan] Fix cyclic phi type inference in early outer loop plans. (#196634)
For phis check if any of the operands are VPIRValues or we already have
cached types. If so, return them.
This fixes a verification stack overflow in the VPlan outer loop path
after https://github.com/llvm/llvm-project/pull/192868.
[AMDGPU] Implement -amdgpu-spill-cfi-saved-regs
These spills need special CFI anyway, so implementing them directly
where CFI is emitted avoids the need to invent a mechanism to track them
from ISel.
Change-Id: If4f34abb3a8e0e46b859a7c74ade21eff58c4047
Co-authored-by: Scott Linder scott.linder at amd.com
Co-authored-by: Venkata Ramanaiah Nalamothu VenkataRamanaiah.Nalamothu at amd.com
[AMDGPU] Implement CFI for CSR spills
Introduce new SPILL pseudos to allow CFI to be generated for only CSR
spills, and to make ISA-instruction-level accurate information.
Other targets either generate slightly incorrect information or rely on
conventions for how spills are placed within the entry block. The
approach in this change produces larger unwind tables, with the
increased size being spent on additional DW_CFA_advance_location
instructions needed to describe the unwinding accurately.
Change-Id: I9b09646abd2ac4e56eddf5e9aeca1a5bebbd43dd
Co-authored-by: Scott Linder <scott.linder at amd.com>
Co-authored-by: Venkata Ramanaiah Nalamothu <VenkataRamanaiah.Nalamothu at amd.com>
[AMDGPU] Implement CFI for non-kernel functions
This does not implement CSR spills other than those AMDGPU handles
during PEI. The remaining spills are handled in a subsequent patch.
Change-Id: I5e3a9a62cf9189245011a82a129790d813d49373
Co-authored-by: Scott Linder <scott.linder at amd.com>
Co-authored-by: Venkata Ramanaiah Nalamothu <VenkataRamanaiah.Nalamothu at amd.com>
[AMDGPU] Emit entry function Dwarf CFI
Entry functions represent the end of unwinding, as they are the
outer-most frame. This implies they can only have a meaningful
definition for the CFA, which AMDGPU defines using a memory location
description with a literal private address space address. The return
address is set to undefined as a sentinel value to signal the end of
unwinding.
Change-Id: I21580f6a24f4869ba32939c9c6332506032cc654
Co-authored-by: Scott Linder <scott.linder at amd.com>
Co-authored-by: Venkata Ramanaiah Nalamothu <VenkataRamanaiah.Nalamothu at amd.com>
