The synthesized deduction guides use injected template arguments for
distinguishment of explicit and implicit deduction guides.
In partial ordering, we may substitute into these injected types when
checking consistency. Properly substituting them needs the instantiated
class template specializations which isn't the case at that point. So
instead, we check their template specialization types.
No release note because I think we want a backport, after baking it for
a couple of days.
Fixes https://github.com/llvm/llvm-project/issues/134613
(cherry picked from commit 07faafe4a4d0a5bd82b648aa9717783f001ddfae)
The i386 psABI specifies that `__float128` has 16 byte alignment and
must be passed on the stack; however, LLVM currently stores it in a
stack slot that has an offset of 4. Add a custom lowering to correct
this alignment to 16-byte.
i386 does not specify an `__int128`, but it seems reasonable to keep the
same behavior as `__float128` so this is changed as well. There also
isn't a good way to distinguish whether a set of four registers came
from an integer or a float.
The main test demonstrating this change is `store_perturbed` in
`llvm/test/CodeGen/X86/i128-fp128-abi.ll`.
Referenced ABI:
https://gitlab.com/x86-psABIs/i386-ABI/-/wikis/uploads/14c05f1b1e156e0e46b61bfa7c1df1e2/intel386-psABI-2020-08-07.pdf
Fixes: https://github.com/llvm/llvm-project/issues/77401
(cherry picked from commit a78a0f8d204393a0cce367b63395bad90311c1b8)
This change fixes an issue with the use of `-alternatename` in the MSVC
CRT on ARM64EC, where both mangled and demangled symbol names are
specified. Without this patch, the demangled name could be resolved to
an anti-dependency alias of the target. Since chaining anti-dependency
aliases is not allowed, this results in an undefined symbol.
The root cause isn't specific to ARM64EC, it can affect other targets as
well, even when anti-dependency aliases aren't involved. The
accompanying test case demonstrates a scenario where the symbol could be
resolved from an archive. However, because the archive member is pulled
in after the first pass of alternate name resolution, and archive
members don't override weak aliases, eager resolution would incorrectly
skip it.
(cherry picked from commit ac31d64a64e8a648f6834f4cf9de10c56c8d1083)
Like in other places, ignore the reference type of the base. (It might
make sense to refactor this at some point.)
Fixes#150015.
(cherry picked from commit bba846773c7dfce0f95b8846672d8dd5fa8912be)
These float operations were expanded for scalar f32/f64/f128, but not
for f16 and more problematically, not for vectors. A small subset of
them was separately set to expand for vectors.
Change these to always expand by default, and adjust targets to mark
these as legal where necessary instead.
This is a much safer default, and avoids unnecessary legalization
failures because a target failed to manually mark them as expand.
Fixes https://github.com/llvm/llvm-project/issues/110753.
Fixes https://github.com/llvm/llvm-project/issues/121390.
(cherry picked from commit fe0dbe0f2950d95071be7140c7b4680f17a7ac4e)
This fixes the following build warnings in a mingw environment:
../../lldb/source/Host/windows/MainLoopWindows.cpp:226:50: warning:
format specifies type 'int' but the argument has type
'IOObject::WaitableHandle' (aka 'void *') [-Wformat]
226 | "File descriptor %d already monitored.", waitable_handle);
| ~~ ^~~~~~~~~~~~~~~
../../lldb/source/Host/windows/MainLoopWindows.cpp:239:49: warning:
format specifies type 'int' but the argument has type 'DWORD' (aka
'unsigned long') [-Wformat]
238 | error = Status::FromErrorStringWithFormat("Unsupported file type
%d",
| ~~
| %lu
239 | file_type);
| ^~~~~~~~~
2 warnings generated.
(cherry picked from commit 98ec927fcb8697a6f6df64298835917aa1d0d3c1)
While investigating PR #149990, I noticed that while both the Oracle
Studio compilers and GCC default to `-mv8plus` on 32-bit Solaris/SPARC,
Clang does not.
This patch fixes this by enabling the `v8plus` feature.
Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu`.
(cherry picked from commit 06233892e84f96a3b4e05338cd4f6c12b8f5a185)
When Mips process emitStartOfAsmFile and updateABIInfo, it did not know
the real value of IsSoftFloat and STI.useSoftFloat(). And when inline
asm instruction was empty, Mips did not process asm parser, so it would
not do TS.updateABIInfo(STI) again and at this time the value of
IsSoftFloat is correct.
Fix#135283.
(cherry picked from commit 778fb76e6308534a63239a91b98f5dad055f6fdb)
This fixes an issue where if the build folder is no longer present flang
cannot link anything on Windows because the path to compiler-rt in the
binary is hard-coded. Flang already links compiler-rt on Windows so it
isn't necessary for flang-rt to specify that it depends on compiler-rt
at all, other than for the unit tests, so instead we can move that logic
into the unit test compile lines.
(cherry picked from commit c20a95a7ddd8219f3e587e335a0a8e3f4613fc47)
I wasn't able to build lldb using Mingw-w64 on Windows without changing
these 3 lines. It seems like `std::atomic<bool>` wasn't being found
without `#include <atomic>` and `ceil` was defaulting to `std::ceil`
instead of `std::chrono::ceil`, but I'm not smart enough to know the
root cause. I'm sure I'm not the first people to try and compile lldb
(and clang and lld) with Mingw-w64 and I don't know if something is
wrong with my Mingw-w64, but my changes shouldn't have any affect if
they aren't needed.
(cherry picked from commit 1a32bcb4379fb90d2b764ac33b917de1431c6b16)
Commit 597ee88 moved the -X flag to a new position in the baremetal
toolchain's linker job, but unintentionally left the original instance in place.
This patch removes the redundant flag, ensuring -X is passed only once.
(cherry picked from commit 81651e9fd0a744423fc0435f199ef79fb3a91f02)
This patch backports all of the recent changes to the release branch. This
will get the CI functioning again. This backport also includes a couple
refactorings, but those will probably end up being necessary for backporting
future patches. They are relatively safe because they have already been
extensively tested on main and only impact the CI.
071765749a70b22fb62f2efc07a3f242ff5b4c52 improved constexpr-unknown
diagnostics, but potential constant expression checking broke in the
process: we produce diagnostics in more cases. Suppress the diagnostics
as appropriate.
This fix affects -Winvalid-constexpr and the enable_if attribute. (The
-Winvalid-constexpr diagnostic isn't really important right now, but it
will become important if we allow constexpr-unknown with pre-C++23
standards.)
Fixes#149041. Fixes#149188.
(cherry picked from commit 6a60f18997d62b0e2842a921fcb6beb3e52ed823)
In the `isInt` check that was added in #147661 we were passing the
zero-extended `uint64_t` value instead of the sign-extended one.
(cherry picked from commit d3937e2d12648caa49fd80f9520a391fde2f7ba5)
Prompted by PR #149652, this patch changes the Solaris/SPARC default to
-mcpu, matching both the Oracle Studio 12.6 compilers and GCC 16:
[[PATCH] Default to -mcpu=ultrasparc3 on
Solaris/SPARC](https://gcc.gnu.org/pipermail/gcc-patches/2025-July/690191.html).
This is equivalent to enabling the `vis2` feature.
Tested on `sparcv9-sun-solaris2.11` and `sparc64-unknown-linux-gnu`.
(cherry picked from commit 0f235695709d2505651a55ec7f3c8b7fba2b2dbb)
Unlike `verbose_abort`, this function merely logs the error but does not
terminate execution. It is intended to make it possible to implement the
`observe` semantic for Hardening.
(cherry picked from commit d750c6de8a75cbe2bc16c136764195471be8f0b7)
As we use getTargetConstantBitsFromNode in a wider variety of places we can't guarantee that all the sources match (or are legal) anymore - better to early out than assert.
Fixes#150117
(cherry picked from commit 33455825428f9e1b7998a66e228da7f6d483acf8)
A check for character substrings masquerading as array sections was
using expression analyzer on the array base. When this array happened to
be an assumed-size array, the analyzer emitted a semantic error that did
not correspond to any issue with the source code.
To avoid that, check whether the object is an assumed-size array before
using the expression analyzer on it.
While at it, replace the call to GetShape with a simple check for rank,
since that's the only information needed.
Fixes https://github.com/llvm/llvm-project/issues/150297
(cherry picked from commit 8fcbd06b25fd0c1b4bc4a4c8775129f7dab1affd)
This fixes#116883.
The x86 parser saves any register it encounters to a TmpReg field in its
state machine, then on encountering the next valid token immediately
afterwards saves it to either BaseReg, or IndexReg if BaseReg was
already filled. However, this saving logic was missing on the RParen
token handler, causing the parser to "forget" the register immediately
beforehand. This also would prevent later validation logic from
detecting the addressing mode as invalid, leading to a silent
misassembly rather than an error.
(cherry picked from commit a073cbbb1aeaaeac01b12e818fe47e4c04080aac)
This argument is the number of bytes to adjust the stack by for the
duration of the call. In most cases, PEI is able to eliminate the
corresponding call frame pseudos, folding them into the initial stack
frame allocation (rounded up to stack alignment), where it just ends up
allocating more space than needed. However, in the rare case where this
cannot be done, e.g. due to the use of a dynamic alloca, the 1 byte
stack adjustment persists and results in a misaligned stack for the
duration of the call. This has been the case ever since TLS support was
added in cb1dca602c43 ("[Sparc] Add support for TLS in sparc."), and I
can only assume that 1 was used erroneously thinking that it is the
number of arguments (as there is 1 register argument for the call), not
the number of bytes for on-stack arguments.
Fixes: https://github.com/llvm/llvm-project/issues/149808
(cherry picked from commit 4b99eb2eb49d8fcdb29ba494501e481cf09831ae)
In the vmerge peephole, we currently allow different AVLs for the vmerge
and its true operand.
If vmerge's VL > true's VL, vmerge can "preserve" elements from false
that would otherwise be clobbered with a tail agnostic policy on true.
mask 1 1 1 1 0 0 0 0
true x x x x|. . . . AVL=4
vmerge x x x x f f|. . AVL=6
If we convert this to vmv.v.v we will lose those false elements:
mask 1 1 1 1 0 0 0 0
true x x x x|. . . . AVL=4
vmv.v.v x x x x . .|. . AVL=6
Fix this by checking that vmerge's AVL is <= true's AVL.
Should fix#149335
(cherry picked from commit eafe31b293a5166522fff4f3e2d88c2b5c881381)
This patch fixes a bug introduced in #145878. A dependency was added in
the wrong direction, causing an assertion failure due to broken
topological order.
(cherry picked from commit 6df012ab48ececd27359bdc9448ee101b39eea7a)
getVectorInstrCostHelper would return costs of zero for vector
inserts/extracts that move data between GPR and vector registers, if
there was no 'real' use, i.e. there was no corresponding existing
instruction.
This meant that passes like LoopVectorize and SLPVectorizer, which
likely are the main users of the interface, would understimate the cost
of insert/extracts that move data between GPR and vector registers,
which has non-trivial costs.
The patch removes the special case and only returns costs of zero for
lane 0 if it there is no need to transfer between integer and vector
registers.
This impacts a number of SLP test, and most of them look like general
improvements.I think the change should make things more accurate for any
AArch64 target, but if not it could also just be Apple CPU specific.
I am seeing +2% end-to-end improvements on SLP-heavy workloads.
PR: https://github.com/llvm/llvm-project/pull/146526
Without thunks, programs will encounter link errors complaining that the
branch target is out of range. Thunks will extend the range of branch
targets, which is a critical need for large programs. Thunks provide
this flexibility at a cost of some modest code size increase.
When configured with the maximal feature set, the hexagon port of the
linux kernel would often encounter these limitations when linking with
`lld`.
The relocations which will be extended by thunks are:
* R_HEX_B22_PCREL, R_HEX_{G,L}D_PLT_B22_PCREL, R_HEX_PLT_B22_PCREL
relocations have a range of ± 8MiB on the baseline
* R_HEX_B15_PCREL: ±65,532 bytes
* R_HEX_B13_PCREL: ±16,380 bytes
* R_HEX_B9_PCREL: ±1,020 bytes
Fixes#149689
Co-authored-by: Alexey Karyakin <akaryaki@quicinc.com>
---------
Co-authored-by: Alexey Karyakin <akaryaki@quicinc.com>
(cherry picked from commit b42f96bc057fd9e31572069b241ba130c21144e5)
Handle the case where the assigned variable also has a pointer
attribute.
Fixes#121721
(cherry picked from commit fc0a978327215aa8883ae6f18d1e316f3c04520a)
Fixes#149089 and #149700.
Before #145837, when processing a reduction symbol not yet supported by
OpenMP lowering, the reduction processor would simply skip filling in
the reduction symbols and variables. With #145837, this behvaior was
slightly changed because the reduction symbols are populated before
invoking the reduction processor (this is more convenient to shared the
code with `do concurrent`).
This PR restores the previous behavior.
(cherry picked from commit 36c37b019b5daae79785e8558d693e6ec42b0ebd)
Update LV to vectorize maxnum/minnum reductions without fast-math flags,
by adding an extra check in the loop if any inputs to maxnum/minnum are
NaN, due to maxnum/minnum behavior w.r.t to signaling NaNs. Signed-zeros
are already handled consistently by maxnum/minnum.
If any input is NaN,
*exit the vector loop,
*compute the reduction result up to the vector iteration that contained
NaN inputs and
* resume in the scalar loop
New recurrence kinds are added for reductions using maxnum/minnum
without fast-math flags.
PR: https://github.com/llvm/llvm-project/pull/148239
There are cases we end up removing some intructions that use stackified
registers after RegStackify. For example,
```wasm
bb.0:
%0 = ... ;; %0 is stackified
br_if %bb.1, %0
bb.1:
```
In this code, br_if will be removed in CFGSort, so we should unstackify
%0 so that it can be correctly dropped in ExplicitLocals.
Rather than handling this in case-by-case basis, this PR just
unstackifies all stackifies register with no uses in the beginning of
ExplicitLocals, so that they can be correctly dropped.
Fixes#149097.
(cherry picked from commit b13bca7387a7aad6eaf3fa1c55bd06fe091f65ed)
DTLTO-related COFF LLD changes were cherry-picked to the LLVM 21
release branch in:
https://github.com/llvm/llvm-project/pull/149979
This commit adds the corresponding release note, modeled after
the previously added note for ELF LLD DTLTO support.
A thin archive is an archive/library format where the archive itself
contains only references to member object files on disk, rather than
embedding the file contents.
For the non-/wholearchive case, we use the path to the archive member as
the identifier for thin-archive members (see comments in
`enqueueArchiveMember`). This patch modifies the /wholearchive path to
behave the same way.
Apart from consistency, my motivation for fixing this is DTLTO
(#126654), where having the member identifier be the path on disk allows
distribution of bitcode members during ThinLTO.
(cherry picked from commit 9f733f4324412ef89cc7729bf027cdcab912ceff)
Closes#147869Closes#149679
Adds a check for a missing loop preheader during analysis. This fixes a
nullptr dereference that happened whenever LoopSimplify was unable to
generate a preheader because the loop was entered by an indirectbr
instruction (as stated in the LoopSimplify.cpp doc comment).
(cherry picked from commit 04107209856bb39e041aa38cf40de0afa90a6b2d)
This patch introduces support for Integrated Distributed ThinLTO (DTLTO)
in COFF LLD.
DTLTO enables the distribution of ThinLTO backend compilations via
external distribution systems, such as Incredibuild, during the
traditional link step: https://llvm.org/docs/DTLTO.html.
Note: Bitcode members of non-thin archives are not currently supported.
This will be addressed in a future change. This patch is sufficient to
allow for self-hosting an LLVM build with DTLTO if thin archives are
used.
Testing:
- LLD `lit` test coverage has been added, using a mock distributor to
avoid requiring Clang.
- Cross-project `lit` tests cover integration with Clang.
For the design discussion of the DTLTO feature, see:
https://github.com/llvm/llvm-project/pull/126654
(cherry picked from commit bbbbc093febffcae262cde1baa429b950842d76e)
This patch introduces support for Integrated Distributed ThinLTO (DTLTO)
in Clang.
DTLTO enables the distribution of ThinLTO backend compilations via
external distribution systems, such as Incredibuild, during the
traditional link step: https://llvm.org/docs/DTLTO.html.
Testing:
- `lit` test coverage has been added to Clang's Driver tests.
- The DTLTO cross-project tests will use this Clang support.
For the design discussion of the DTLTO feature, see:
https://github.com/llvm/llvm-project/pull/126654
(cherry picked from commit 5004c59803fdeb3389d30439a6cc8b1ff874df0c)
