[libc][semaphore] Zero-initialize rand_bytes to fix GCC warning (#195757)
GCC 15 warns about `rand_bytes` being maybe uninitialized when passed to
`getrandom`. Since `getrandom` writes to it, it doesn't strictly need
initialization, but zero-initializing it satisfies the compiler and
avoids the `-Werror=maybe-uninitialized` error.
Fix for https://github.com/llvm/llvm-project/pull/192278
Assisted by Gemini
[RFC][IR] Support vector splats in `ConstantPointerNull`
This PR allows `ConstantPointerNull` to represent both scalar pointer nulls and
fixed or scalable vector splats of pointer nulls. This change first aligns with
the native splat behavior of `ConstantInt` and `ConstantFP`, and second, makes
it easier to eventually change the semantics of `ConstantPointerNull` to
represent a semantic null pointer instead of a zero value, which is what it
represents today.
[clang][Analysis] Handle const-qualified pointer refs in `ExprMutationAnalyzer` (#190421)
Teach `ExprMutationAnalyzer` to recognize references to const-qualified
pointer objects, such as `T *const &`, as non-const pointee sinks when
the pointee type itself is non-const.
Fixes #190218
Fixes #157730
[compiler-rt][test] Disable create_thread_loop2 for lsan on Darwin (#195753)
create_thread_loop2 occasionally hangs on macOS till hitting timeout.
Disable the tests for LSAN on macOS.
[SandboxIR][Tracker] Support nested checkpoints (#191097)
This patch implements nested checkpointing, i.e., you can now save the
IR state more than once and revert more than once.
For example, after two saves: save(1) and save(2), a revert() will bring
you back to the IR state of save(2), one more revert will bring you back
to the IR state of save(1).
[cmake][compiler-rt][darwin] builtin libraries don't build for armv6m in Darwin (#195372)
darwin_add_builtin_libraries tests for _Float16 and __bf16 for the host
architecture rather than the one being built, add -arch to fix that so
that armv6m correctly reports that it does not support __bf16.
cfcmp/cdcmp get "error: unsupported relocation type" on their "Branch to
target address" to c{f,d}cmple. Switch those to "Call a subroutine"
instructions on Thumb-1 (e.g. armv6m).
Assisted-by: Claude Code
rdar://167828904
[flang][OpenMP] Detect DSA conflicts in nested loop constructs (#195323)
Follow-up to https://github.com/llvm/llvm-project/pull/194961
The fix from PR194961 did not detect explicit/predefined DSA conflicts
on an iteration variable in a nested loop construct. For example, in a
testcase inspired by Fujitsu 0165_0035.f90:
```
!$omp parallel do private(i) shared(j)
do i=1,1
do j=1,1
!$omp parallel do default(none) shared(k)
do k=1,1
end do
!$omp end parallel do
end do
end do
```
the "shared(k)" was not flagged as incorrect.
[2 lines not shown]
[DWARFLinker] Emit DW_IDX_parent in the accelerator table (#195403)
.debug_names entries produced by the parallel linker were always emitted
with std::nullopt for ParentDIEOffset, resulting in a missing
DW_IDX_parent. The classic linker emits it via
DWARF5AccelTableData::getDefiningParentDieOffset on the output DIE tree.
The parallel linker can't use the same approach because the records are
saved during cloneDIE, before the output DIE has been linked into its
parent, so DIE::getParent() is nullptr at that time time. Fix that by
computing the parent offset from the input-side DIE tree instead. We
look up InputDieEntry's parent via getParentIdx, skip parents marked
DW_AT_declaration, and translate them to the output offset through
CompileUnit::getDieOutOffset. Since no real DIE can live at offset 0, we
can use that to unambiguously mark input DIEs that were not cloned into
this CU's plain DWARF (e.g. routed only into the artificial type unit)
and is treated as "no parent".
Only compile-unit accelerator entries are covered. Type-unit entries
(artificial type unit) still emit no DW_IDX_parent, tracked by a TODO.
[AArch64] Fix `shufflevector` miscompilation on `aarch64_be` (#193076)
A function like
```llvm
define <4 x i16> @xtn_shuffle_even_v8i16(<8 x i16> %a) {
entry:
%r = shufflevector <8 x i16> %a, <8 x i16> poison, <4 x i32> <i32 0, i32 2, i32 4, i32 6>
ret <4 x i16> %r
}
```
will use the `xtn` instruction, which for each 32-bit vector element
keeps only the lower 16 bits, so effectively this is a truncation.
However, if the vector actually has 16-bit elements, then the conversion
from a shuffle to a truncation is only valid on LE, not on BE. On BE,
`uzp1` should be used instead. So this PR moves some logic to right
after a check for LE, so that BE does not miscompile.
[5 lines not shown]
Prevent undefined behavior caused by combination of branch and load delay slots on MIPS1 (#185427)
Under certain conditions the LLVM `MipsDelaySlotFiller` fills a branch
delay slot with an instruction requiring a load delay slot. However the
`MipsDelaySlotFiller` does not check the filled instruction for hazard
which leads to code like this:
```asm
beqz $1, $BB0_5
lbu $2, %lo(_RNvCs5jWYnRsDZoD_3app13CONTROLLERS_A)($2)
# --- Some other instructions
$BB0_5:
andi $1, $2, 1
```
`lbu` got moved into the branch delay slot but has a load delay slot -
so when jumping to `$BB0_5` the value for `$2` will not be ready, which
leads to undefined behavior.
This PR suggests to declare instructions with a load delay slot to be
hazardous for the branch delay slot, only for `MIPS1`. This will prevent
[23 lines not shown]
[RFC][NFCI][Constants] Add `Constant::isZeroValue`
The old `isZeroValue` was removed because it was functionally identical to
`Constant::isNullValue`. Currently, a "null value" in LLVM means a zero value.
We are moving toward changing the semantics of `ConstantPointerNull` to
represent a semantic null pointer instead of a zero-valued pointer. As a result,
the meaning of "null value" will also change in the future.
This PR series is the first step toward renaming the two widely used "null
value" interfaces to "zero value". As the first PR in the series, this change
adds a "new" `isZeroValue` alongside `isNullValue`, and makes `isNullValue` call
`isZeroValue` directly. Then, all uses of `isNullValue` in LLVM are replaced
with `isZeroValue`. Uses in other projects will be updated in separate PRs.
The plan is to eventually remove `isNullValue` after all uses have been
migrated.
