An enumeration is compatible with its underlying type, which means that
code like the following should be accepted:
struct A { int h; };
void func() {
extern struct A x;
enum E : int { e };
struct A { enum E h; };
extern struct A x;
}
because the structures are declared in different scopes, the two
declarations of 'x' are both compatible.
Note, the structural equivalence checker does not take scope into
account, but that is something the C standard requires. This means we
are accepting code we should be rejecting per the standard, like:
void func() {
struct A { int h; };
extern struct A x;
enum E : int { e };
struct A { enum E h; };
extern struct A x;
}
Because the structures are declared in the same scope, the type
compatibility rule require the structures to use the same types, not
merely compatible ones.
Fixes#149965
(cherry picked from commit 315e2e28b13285a352d409b739ba31fb453d661b)
This adds download links to the GitHub release pages for common
platforms. The automatically built packages' links are automatically
revealed once the builds are complete. For packages built by hand,
hidden links are included in the text for release uploaders to reveal
later.
The approach taken:
* "LLVM x.y.z Release" becomes the title for this links section.
* Automatically built packages are commented out with special markers so
we can find them to uncomment them later.
* There is placeholder text for the time between release creation and
release tasks finishing.
* Hand built packages have release links but these will need to be
un-commented by release uploaders.
* I have used vendor names for the architectures, that casual users
would recognise.
* Their signature file is linked as well. I expect most will ignore this
but better to show it to remind people it exists.
* I called it "signature" as a generic term to cover the .jsonl and .sig
files. Instructions to use these were added to the text in a previous
change.
(cherry picked from commit e8b7183d866f9d51511d5570f5f1f632046ef983)
This controls whether tag checking is performed for loads and
stores, or stores only.
It requires a specific architecture feature which we detect
with a HWCAP3 and cpuinfo feature.
Live process tests look for this and adjust expectations
accordingly, core file tests are using an updated file with
this feature enabled.
The size of the core file has increased and there's nothing
I can do about that. Could be the presence of new architecure
features or kernel changes since I last generated them.
I can generate a smaller file that has the tag segment,
but that segment does not actually contain tag data. So
that's no use.
(cherry picked from commit 0209e76fe6440bc45a9ed61b9671d9593db10957)
This will be used to detect the presence of Arm's new Memory Tagging
store only checking feature. This commit just adds the plumbing to get
that value into the detection function.
FreeBSD has not allocated a number for HWCAP3 and already has AT_ARGV
defined as 29. So instead of attempting to read from FreeBSD processes,
I've explicitly passed 0. We don't want to be reading some other entry
accidentally.
If/when FreeBSD adds HWCAP3 we can handle it like we do for
AUXV_FREEBSD_AT_HWCAP.
No extra tests here, those will be coming with the next change for MTE
support.
(cherry picked from commit d26ca8b87266024546501051ccaf75cb3756aee3)
When `ptrauth_calls` is present but `ptrauth_init_fini` is not, compiler
emits raw unsigned pointers in `.init_array`/`.fini_array` sections.
Previously, `__do_init`/`__do_fini` pointers, which are explicitly added
to the sections, were implicitly signed (due to the presense of
`ptrauth_calls`), while all the other pointers in the sections were
implicitly added by the compiler and thus non-signed.. As a result, the
sections contained a mix of unsigned function pointers and function
pointers signed with default signing schema.
This patch introduces use of inline assembly for this particular case,
so we can manually specify that we do not want to sign the pointers.
Note that we cannot use `__builtin_ptrauth_strip` for this purpose since
its result is not a constant expression.
(cherry picked from commit 19ba224fb8a925d095d84836bc9896bf564dfd99)
Assertion semantics closely mimic C++26 Contracts evaluation semantics.
This brings our implementation closer in line with C++26 Library Hardening
(one particular benefit is that using the `observe` semantic makes adopting
hardening easier for projects).
(cherry picked from commit 3eee9fc2c4d1973904b1a26fa96a8c7473ef6a5e)
On COFF platform, d1b0cbff806b50d399826e79b9a53e4726c21302 generates
a debug info linked with VTable even if that is dllimport-ed. That
causes an access violation while performing runtime pseudo-relocation
if the debug section is stripped.
For the release branch, we simply disable VTable debug info on COFF
platform to avoid this problem.
Fixes#149639
Clang's current implementation only works on array types, but GCC (which
is where we got this attribute) supports it on pointers as well as
arrays.
Fixes#150951
(cherry picked from commit 837b2d464ff16fe0d892dcf2827747c97dd5465e)
If a chunk is empty and there are no other non-empty chunks in the same
section, `removeEmptySections()` will remove the entire section. In this
case, use a section index of 0, as the MSVC linker does, instead of
asserting.
(cherry picked from commit 1ab04fc94c5f68ad0dc6755e3914f2895b85e720)
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)
