When a global is requested for definition but a definition with the same
mangled name already exists, return it as is instead of creating a fresh
global and erasing the defined one, even if its type differs from the
requested type.
The type can legitimately differ when the initializer folded to a
different (e.g. anonymous) type, as happens with unions. Erasing the
defined global dangles pointers held by callers, e.g. the
`AssociatedData` of entries in `llvm.global_ctors`, leading to a
use-after-free crash during `EmitCtorList`. This also keeps the
deferred-decls "already emitted" check sound, since it queries with
`IsForDefinition`, which must be non-destructive.
Add a header-unit regression test: an inline variable with an
anonymous-union member, constant-initialized but requiring dynamic
destructor registration, must be emitted exactly once when imported from
header units. The folded initializer has an anonymous type that differs
from the declared type; a second emission used to replace (and erase)
the already-defined global, leaving a dangling pointer in
`llvm.global_ctors` (use-after-free, observable as a crash under ASan).
Assisted-By: Meta Muse 1.3
Co-authored-by: Michael Park <mcypark@gmail.com>
(cherry picked from commit 2a6fdac960de3a6bae854474f12e8f1edfcd9a04)
This follows up to https://github.com/llvm/llvm-project/pull/207966 in order to transforms type
constraints with a ForConstraintSubstitution flag.
Assisted-by: Codex
(cherry-picked from 93c463319ebcb57e82f0c87c813a9ead536fb952)
Each execution of an alloca creates a new allocation, distinct from the
allocations of all other executions. They must not be merged, either by
CSE or via isUniformAcrossVFsAndUFs.
Update those to explicitly handle Alloca recipes.
Fixes https://github.com/llvm/llvm-project/issues/229389.
PR: https://github.com/llvm/llvm-project/pull/229929
(cherry picked from commit 95ea23b7d5b06c60c513c575577d5b7d0ed15721)
The OpenBSD Host code used FreeBSD-style sysctl MIBs, which don't
match OpenBSD's interface, so process lookups failed.
- GetOpenBSDProcessArgs: use {CTL_KERN, KERN_PROC_ARGS, pid,
KERN_PROC_ARGV}. OpenBSD returns a NULL-terminated argv array
whose pointers point into the returned buffer, so iterate it
directly.
- GetOpenBSDProcessUserAndGroup, FindProcessesImpl: KERN_PROC
takes a 6-element MIB on OpenBSD, with the kinfo_proc element
size and element count as the last two entries.
(cherry picked from commit b880f44cbad751b0784a5fbbfbdaacea25e167f8)
Fixes#233318
Before this change, we were restoring some callee-saved registers twice
when using save/restore libcalls with shadow call stack (SCS), and the
second restore was happening after the stack was deallocated using the
wrong register and offset calculation, which was causing lots of access
problems.
The problems were:
- We were using the entire list of Callee Saves rather than just the
subset that would have been restored by the libcall. This caused
duplicate restores because of how the CSI subsetting works.
- We were not using the correct offset calculation in
eliminateFrameIndex, which was causing us to calculate the wrong
address for the saves/restores.
Assisted-by: AI
Co-authored-by: Mitch Briles <mitchbriles@gmail.com>
This primarliy applies to the save-restore case, which was using
`__riscv_restore_<N>` incorrectly, entirely circumventing the software
shadow call stack.
This fix keeps the code size improvements of `__riscv_save_<N>` when
there is a shadow call stack, but it avoids the incorrect use of
`__riscv_restore_<N>`, instead emitting the correct sequence inline.
In the future, when there are better versions of `__riscv_save_<N>` and
`__riscv_restore_<N>` which support the shadow call stack variants (both
hardware and software), then we can revisit this approach and use the
correct pairs in all cases.
`TargetLowering::expandABD` expands `abd(a, b)` to `abs(sub(a, b))` when
`willNotOverflowSub` says the sub can't overflow. For `abdu` without
known
non-negative operands, this checks for unsigned overflow, which only
proves
`a >= b (unsigned)`, so `abdu(a, b) == sub(a, b)`. adding abs around it
is wrong, when the
difference is greater than INT_MAX, e.g. `abdu(lshr(x, 1), or(y,
INT_MIN))`.
Keep abs(sub) for the signed check (abds, or abdu with non-negative
operands) and use just sub when abdu and `a >= b`.
Fixes#233087.
(cherry picked from commit f16dbe0ec4b653736148c78bebdefcfe1c88198e)
alignof(std::max_align_t) is 4 on NetBSD/i386, whose <stddef.h> defines
max_align_t as a union of void *, long double, and long long.
Fix#230782
(cherry picked from commit 0b6b6ed806536c1b170101061ff3eeed91c8f061)
The OpenMP spec has a bug: the restriction should read
> If linear-modifier is ref, list items must not be polymorphic variables,
> assumed-shape arrays, or variables with the ALLOCATABLE attribute.
---------
Co-authored-by: Markus Mützel <markus.muetzel@gmx.de>
(cherry picked from commit 53d096bbf31d12fddbbe2508b7f80bab9628430d)
`clang++` defaults to `-stdlib=libc++` on OpenBSD. When building with both
`clang` and `libcxx` included, the freshly built `clang++` uses the system
version of the `libc++` headers. However, this is from the bundled `libc++`
22.1.8, thus inconsistent with the `libc++` being built.
OpenBSD has its own version of addLibCxxIncludePaths which just includes
`/usr/include/c++/v1`.
This patch removes OpenBSD::addLibCxxIncludePaths in favour of the generic
version in `Gnu.cpp`.
(cherry picked from commit 1204f6b4e9d6bef8ec319d121942dca5cbf94a26)
When accumulator recursion elimination rewrites the accumulator
instruction to use the accumulator PHI (and clones it at each return in
`cleanupAndFinalize()`), its operands change, so poison-generating
annotations derived from the original operands may no longer hold. Only
flags were dropped so far (#200624); return attributes like `range()`
and metadata like `!range` were kept.
In the reproducer from the issue, `umax(%r, 1)` carries `range(i8 1,
3)`, and the per-return copy `umax(%accumulator.tr, %k)` kept it
although it can return 0, so `-O2` inferred `range(i8 1, 3)` for the
whole function (miscompiling the Rust code linked in the issue).
This patch uses `dropPoisonGeneratingAnnotations()` instead of
`dropPoisonGeneratingFlags()`.
Fixes#233085
(cherry picked from commit 21c1bcd7059ca56dee6bc377e60a06a3b18a1d69)
`optimizeExtUses` rewrites uses of an extension's source in other blocks
to read `trunc` of the extension, which is only correct where the
extension isn't `poison`. A `zext nneg` can be valid only where it was
originally used, like behind a check that its source isn't negative. If
that check is one of the rewritten uses, it ends up reading `poison`,
and on `x86_64-pc-windows-msvc`, InstSimplify in WinEHPrepare's cleanup
folds it to true and causes a miscompile.
Drop the extension's poison-generating flags once a use has been
rewritten, like #72103 and #90382 did for similar cases in
`CodeGenPrepare`.
Fixes#234098.
(cherry picked from commit 93fccabb4ebc82695475eaaa279ea5fbb2265450)
When an HTTP request fails while it already received some data, the
cached file stream is never committed. Destroying it in that state
raises a fatal error, crashing the program (see #184728).
This PR adds an `abort` method that should be called in this situation
before destroying the stream. For the default implementation, only the
output stream is closed. For the `CacheStream` in `llvm::localCache`,
the temporary file is discarded as well.
The test is based on David's reproducer. Since WinHttp seems to discard
the content-length header, I switched to timing out the response
instead.
Fixes#184728. This is still a bug for the symstore locator in lldb, but
I'll fix that in a followup.
fix: disable test partial-response.test on system-windows
…tion
Currently DECLARE_SIMD emits a "not yet implemented" error in the MLIR
to LLVM IR translation.
DECLARE_SIMD is a hint to the compiler and ignoring it is technically
speaking a conforming implementation (although obviously not desirable).
Do not abort compilation when DECLARE_SIMD is encountered, but emit a
warning that it's currently ignored.
(cherry picked from commit 5ca62fdee645ec253263e41a45fe626c6b66be22)
Fixes: https://github.com/llvm/llvm-project/issues/234108
Split the transform into 2 phases:
1. narrow all users of all IVs
2. replace wide IVs if all users are scalar.
Together with removing the old, wide recipes, this allows us to catch
slightly more cases.
PR: https://github.com/llvm/llvm-project/pull/217765
(cherry picked from commit 932f5d22df7775f7cb65befd62053c0e93448959)
(cherry picked from commit a3ac001f673a87a014ecd6bf7ca11cc8b1cb576d)
I enabled agent clusters in BuildKite since unclustered agents are not
supported anymore. As part of that, I created a new libcxx-builders-arm
queue to replace the existing queue. This patch switches the pipeline
definition so that new jobs start targeting the new queue with clustered
agents.
(cherry picked from commit 01edf187213105e35db8aef724a63f86241b6bd4)
The API endpoint for getting a release does not work for draft releases,
so we need to fetch all the releases instead and manually search for the
one to update.
(cherry picked from commit b91e6c58859e60b5dd22a57aafbbec9764343cce)
Only mark v4i64 and v8i64 [SU]MUL_LOHI as Custom in 64-bit mode. Their
custom lowering unrolls to scalar i64 operations, whose results cannot
be expanded by the type legalizer on 32-bit targets.
Add crash regression coverage for signed division and remainder by
positive and negative constants with AVX2, AVX512F, and AVX512DQ+VL.
Fixes#228656
(cherry picked from commit e3e894a951586e653dd7910cad39804cb30ce9fd)
nuw/nsw/disjoint flags are only true at the original width. G_ANYEXT
leaves the new high bits unconstrained, so they must be dropped.
(cherry picked from commit e775aaa9724f52735285f555db534d12166715e7)
When converting select to min/max intrinsics we have to be careful about
poison-propagation, because min/max propagate unconditionally, while
select does not. Normally, this is not a problem, because the select
arms are also used in the select condition, which propagates
unconditionally.
However, SPF also matches special patterns where this may not be the
case. In particular, for `(X <u C1) ? C1 : UMIN(X, C2) ==> UMAX(UMIN(X,
C2), C1)` style transforms, if the inner min/max has poison-generating
annotations, the result can be more-poisonous.
I'm fixing this in a somewhat hacky way, by dropping the poison
annotations as part of SPF canonicalization. This makes assumptions
about the kind of patterns SPF matches. Originally, I wanted to just
move this code out of SPF into a dedicated InstCombine fold, but this
did not work around because SPF also handles cases with casts in
between, and I did not want to replicate that logic.
For https://github.com/rust-lang/rust/issues/163728.
(cherry picked from commit 4662c4a4f6d119a2daaa0c60430f611f8251f5a3)
Fixes errors such as
ld.lld: error: undefined symbol: compiler_rt.rem_pio2.rem_pio2
>>> referenced by compiler_rt
>>>
/home/alexrp/.cache/zig/o/a0062b09f46a198885da4835be133933/compiler_rt_zcu.o:(tan)
in archive
/home/alexrp/.cache/zig/o/a0062b09f46a198885da4835be133933/libcompiler_rt.a
which would happen because the actual symbol is
`$compiler_rt.rem_pio2.rem_pio2` for O32 or
`.Lcompiler_rt.rem_pio2.rem_pio2` for N64/N32.
(cherry picked from commit f93c537b4d5e128c3bc447a9e290f8c97b274e2d)
As with 85b4fbfecb65cd1f5a06e707e7ec0fc2de562407, this seems to be
another case where the backend was treating private functions
differently for no apparent reason.
This was particularly problematic for building the Zig compiler with
LLVM linked statically because we'd have enough such calls that linking
failed with thousands of these errors:
relocation R_MIPS_CALL16 out of range: 76048 is not in [-32768, 32767]
(cherry picked from commit 22371aefb10a31207de828cff7ef7511e9a552f7)
AddCombineTo64BitSMLAL16 is invoked from PerformADDECombine where the
combined node N is AddeNode, but it returned SDValue(AddcNode, 0).
Because RV.getNode() != N, DAGCombiner::Run did not stop replacing and
called DAG.ReplaceAllUsesWith(AddeNode, AddcNode), replacing uses of
the high-word carry/overflow flag (AddeNode, 1) with the low-word
addition flag (AddcNode, 1).
Assisted-by: Gemini
Fixes: e9113618cb ("[ARM] Custom Lowering for SADDO_CARRY and
SSUBO_CARRY (#154419)")
(cherry picked from commit 28999cd08f23dd7baeb63b7ca4addef4214999e3)
finalizeAddressDependentContent assigns addresses, then
--randomize-section-padding and CFI jump table relaxation
(--branch-to-branch, implied by -O2) move input sections, so the first
fixed-point iteration computes address-dependent content from stale
addresses. Since #179089, EhFrameHeader::updateAllocSize caches the
.eh_frame_hdr search table; if no iteration changes anything, the loop
exits and the table keys no longer match the FDEs' initial_location.
Neither transform reads addresses, so run them before the first
assignAddresses. SHF_LINK_ORDER sections are now sorted by the relaxed
layout as well.
LLM-aided. Partially fix#226166
(cherry picked from commit 115554f90f920fc000234c2c247b8318d4e7d2d8)
This replaces the compare-against-zero in
`PPCInstrInfo::optimizeCompareInstr` with the record form of the
instruction defining the compared register only when CR0 is dead at that
point, checked with `MachineBasicBlock::computeRegisterLiveness`
scanning to the end of the block.
Fixes#220996.
## Why
The conversion makes `MI` define CR0. CR0 can still be live there: the
`ANDI_rec_1_{EQ,GT}_BIT` pseudo expansion emits `ANDI_rec` followed by
COPYs of `$cr0eq`/`$cr0gt`, and nothing keeps those copies adjacent to
their `andi.` once other instructions are scheduled in between. A later
compare candidate sitting between an `andi.` and one of its copies gets
converted, clobbers CR0, and the copy then reads the wrong value — the
two flag tests swap conditions.
The existing backward safety scan cannot see this: it only covers the
range between the candidate and the compare's first use (the stale
reader sits after that), and it is skipped entirely when `noSub` is set,
i.e. for every 32-bit compare on PPC64. Un-skipping that scan alone does
not fix the case from the issue (verified); the forward liveness check
does.
## Verification
PowerPC-only builds with assertions on (release/19.x 19.1.7 and main
d8217655d):
- New MIR test `llvm/test/CodeGen/PowerPC/cmp-opt-cr0-live.mir`: fails
on stock `llc` — the conversion happens and `-verify-machineinstrs`
reports `Bad machine code: Using an undefined physical register` for the
stale `%6:crbitrc = COPY $cr0gt` — and passes with this patch.
- `ninja check-llvm-codegen-powerpc`-equivalent (`llvm-lit
test/CodeGen/PowerPC`): identical pass/fail sets with and without the
patch on both bases, apart from the new test. (In my PowerPC-only
environment a handful of tests that need a native default target or
unbuilt utilities fail identically with and without the patch.)
- The C reproducer from the issue and the real-world victim
(libmongocrypt `unicode_fold()`, the case/diacritic folding for MongoDB
Queryable Encryption text search on ppc64le), compiled through the
patched `llc` for `powerpc64le` and run under `qemu-ppc64le`: correct
output.
- The peephole still fires where it is safe: in `unicode_fold`, 2 of the
3 record-form `andi.` conversions remain, only the unsafe one is
dropped.
---
*Disclosure (per the LLVM developer policy on AI-assisted
contributions): the initial analysis, reproduction, and drafting of this
change were done with the assistance of an AI coding tool. I have
reproduced the failure, reviewed every line of the patch, re-run the
verification myself, and am submitting this as the responsible author.*
---------
Co-authored-by: Amy Kwan <amy.kwan1@ibm.com>
(cherry picked from commit 8ed9dd99e7a8dd2fd6b953e5ddae80566e3b49af)
`getGEPIndicesToField()` indexed into a union with 0 and kept walking the
counter's struct field numbers, but the union's IR type is its largest
member, so the count was loaded from inside that member instead.
In Linux, `landlock_domain` hits this and FORTIFY panics on every nested
`landlock_restrict_self()` on kernel 7.3.0-rc5-next as of this writing.
I ran into this bug when trying to daily drive the aforementioned
kernel.
Below is a reduced version of `landlock_domain`. The `work` member
stands in for the kernel's `struct work_struct`, which is larger than the
anonymous struct holding the count, so it becomes the union's IR type.
```c
struct dom {
void *rules[3];
void *hier;
union {
struct { long data; void *next, *prev; void (*fn)(void); } work;
struct {
int usage;
unsigned num_layers;
unsigned masks[] __attribute__((counted_by(num_layers)));
};
};
};
```
`__builtin_dynamic_object_size(d->masks, 1)` read the count at offset
40, inside `work`, instead of at `num_layers`'s offset of 36.
This PR was assisted by Claude (both in debugging & writing a
first-draft fix), though I've taken care to review the changes, and
test them with kernel recompiled w/ an llvm containing this fix, which
does fix the crash :)
(cherry picked from commit 46a1c4b6d57981a4a284ccde484afa7807153bf8)
supportedVectorShiftWithImm accepted any simple 128/256/512-bit vector with
elements of at least 16 bits, including v1i128 and v2i128. X86 has no vector
shifts for such elements, but combineAdd's ADD(x,x) -> X86ISD::VSHLI(x,1)
fold (#161843) relies on this predicate and runs before type legalization.
Reject elements wider than 64 bits.
Fixes#228829.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
(cherry picked from commit 7cfe81b25c02118add29d8d89379543510a8418d)
char has system-dependent signedness. If it is signed, then these
ConstantInt::get() uses would assert because the value is not a valid 8
bit unsigned value.
Cast to unsigned char to make sure we get a valid value on all
platforms.
Fixes https://github.com/llvm/llvm-project/issues/228213.
(cherry picked from commit b3fe8bb231fb43ae186c9ad38766bffb1e7f8e9a)
Otherwise memcmp will never get expanded if running the combination of
ThinLTO pre-link and LTO post-link, which is what Rust does, and what
unified LTO does.
The pipeline position is chosen to roughly match what the module
optimization pipeline does. There is no compile-time impact.
For https://github.com/rust-lang/rust/issues/163677.
(cherry picked from commit 17379353858fbac934f573a22e6aa5acce6884d7)
- Remove the warning message "warning: MIPS-I support is experimental" from
MipsSubtarget.cpp. The warning can interfere with build systems that do not
expect diagnostic output on stderr.
- Remove experimental / highly experimental from a few MIPS processors.
MIPS I is on track and the rest I wouldn't consider experimental anymore.
(cherry picked from commit 73641283fc038d819b5a0d3e5fd1315d501ff9e1)
--strip-unneeded and --discard-all removed the section definition symbol of
a COMDAT section if no relocation referenced it directly, which is the
common case since relocations target the COMDAT leader. The aux record of
that symbol carries the COMDAT selection; without it lld discards the
section as a leaderless COMDAT and silently drops relocations against it.
This broke e.g. .refptr.* sections in MinGW objects, producing executables
that load garbage instead of the referenced pointer.
Assisted-by: Claude Opus 5.5
(cherry picked from commit cf40a83cb398897d21bb54c5a7a2eecb8d0633b3)
Backport 847fb5cfde68fdea490171bc24087ebb0cd90738
This backport has been modified slightly by updating the LIT tests to remove
the dependency on llvm-nm. llvm-nm added GOFF support after the LLVM 23.x release
cut, and its new functionality is not available in LLVM 23.
The Windows WiX installer was missing two things for its setup:
1. The "product ID" which is used to uninstall any previous installed
LLVM versions. This avoids having versions living side-by-side with each
new release. I've reused the same GUID as the current 23.1.0 Win64
installer, to continue that "line" of product. The AArch64 installation
and any prior LLVM version (NSIS) before 23.1.0 will need to be
uninstalled manually, if we want to avoid side-by-side installatin.
2. A "per machine" scope which avoids messy installations which are
installed globally, but cannot be uninstalled globally, and available
only for the current user. After this PR, the installation is available
/ uninstallable to all users on the machine.
Since LLVM currently requires cmake 3.20 for building, and hasn't been
bumped yet to 3.31, also provide a workaround for the WiX scope setup.
Added a release note to signify that users would need to uninstall the
previous versions manually.
Assisted by Claude Opus 5.