This is to fix compile error with explicit Clang modules like
```
../../third_party/libc++/src/include/__vector/vector_bool.h:85:11: error: default argument of '__bit_iterator' must be imported from module 'std.bit_reference_fwd' before it is required
85 | typedef __bit_iterator<vector, false> pointer;
| ^
../../third_party/libc++/src/include/__fwd/bit_reference.h:23:68: note: default argument declared here is not reachable
23 | template <class _Cp, bool _IsConst, typename _Cp::__storage_type = 0>
| ^
```
(cherry picked from commit 672e3858a4e4b9e155adb72426074ea2af0dd922)
The pull request [1] changed bpf default cpu from -mcpu=v1 to
-mcpu=v3 in clang20. Recently in [1], Yuval Deutscher suggested
to add an entry to clang20 ReleaseNotes so users can easily find
the change from documentation.
[1] https://github.com/llvm/llvm-project/pull/107008
Co-authored-by: Yonghong Song <yonghong.song@linux.dev>
For an expression `nodiscard_function().static_member(), the nodiscard
warnings added by #120223, are not useful or actionable, and are
disruptive to some library implementations; we just remove them.
Fixes#131410
(cherry picked from commit 9a1e39062b2ab445f1f4424ecdc5ffb46e8cb9e0)
When inferring host device attr of virtual dtor of explicit
template class instantiation, clang should be conservative.
This guarantees dtors that may call host functions not to
have implicit device attr, therefore will not be emitted
on device side.
Backports: 0f0665db067f d37a39207bc1
Fixes: #108548
It seems that Apple Clang 17 starts to be used for CI, while it hasn't
supported `__builtin_is_virtual_base_of` yet. And thus we need to skip
the test for `is_virtual_base_of`.
Follows up #131302.
In some cases, it is possible for the same underlying object to be
accessed via pointers to different address spaces. This could lead to
pointers from different address spaces ending up in the same dependency
set, which isn't allowed (and triggers an assertion).
Update the mapping from underlying object -> last access to also include
the accessing address space.
Fixes https://github.com/llvm/llvm-project/issues/124759.
PR: https://github.com/llvm/llvm-project/pull/129087
Alexei reported a bpf selftest failure with recent llvm for bpf prog
file progs/arena_spin_lock.c. The failure only happens when clang is
built with cmake option LLVM_ENABLE_ASSERTIONS=ON.
The error message looks like:
```
clang: /home/yhs/work/yhs/llvm-project/llvm/lib/IR/Instructions.cpp:3460:
llvm::BitCastInst::BitCastInst(Value *, Type *, const Twine &, InsertPosition):
Assertion `castIsValid(getOpcode(), S, Ty) && "Illegal BitCast"' failed.
```
Further investigation shows that the problem is triggered in
BPF/BPFAbstractMemberAccess.cpp
for code
```
auto *BCInst =
new BitCastInst(Base, PointerType::getUnqual(BB->getContext()));
```
For the above BitCastInst, Since 'Base' has non-zero AddrSapce, the
compiler expects the type also has the same AddrSpace. But the above
PointerType::getUnqual(...) does not have AddrSpace and hence causes the
assertion failure.
Providing the proper AddrSpace for the BitCast type fixed the issue.
Co-authored-by: Yonghong Song <yonghong.song@linux.dev>
(cherry picked from commit 5686786c550c6da6d1169b9bffc31cece1161902)
This mitigates a regression introduced in #87824.
The mitigation here is to store pointers the deduplicated AST nodes, rather than copies of the nodes themselves. This allows a pointer-optimized set to be used and saves a lot of memory because `clang::DynTypedNode` is ~5 times larger than a pointer.
Fixes#129808.
(cherry picked from commit 8c7f0eaa6ee3f84e3d8260535cced234bed4fa28)
Fix's not rejecting global_load_lds_dwordx3 and x4 on other targets.
The encoded versions of instructions should not touch
SubtargetPredicate,
and only AssemblerPredicate.
(cherry picked from commit f319a6546613d65661e1ad1ef1a2a648cefee84b)
Bug introduced #120995. The LLD code calculates the "size" of the Mach-O
headers, and then uses that size to place the segments, but the `__TEXT`
section stays at `fileoff` zero. When I wrote the code into llvm-objcopy
I calculated the extra space into the initial offset, which moved all
the sections back 1 page.
Besides the modified test checking for the right `fileoff` values of the
sections and the segments, I also manually checked the generated
binaries after `llvm-objcopy` using `dyld_info`, as the bug report
suggested.
Fixes#130472
(cherry picked from commit 8413f4d837a96458104f63bab72c751b8285a458)
Backports b8d1f3d62.
This fixes a potential integer overflow bug that has been around for
many versions and was exposed by my patch recently. So we think it
warrants a backport
This effectively reverts #108535. The old AA code was looking for
the *first* clobber between the load and store and then trying to
move all the way up there. The new MSSA based code instead found
the *last* clobber. There might still be an earlier clobber that
has not been accounted for.
Fixes#130632.
(cherry picked from commit 5da9044c40840187330526ca888290a95927a629)
It has found to be quite a slowdown to traverse the users of a
function from each call site when it is called many (~70k)
times. This patch fixes this for now as long as this verification
is disabled by default, but there is still a need to eventually
cache the results to avoid recomputation.
Fixes#130541
(cherry picked from commit 378739f18208165f9831571a57f34d82f6663bc6)
If any extract is waiting to be erased, then bail out as this will distort the cost calculation and possibly lead to infinite loops.
Fixes#129373
(cherry picked from commit 5ddf40fa78705384966c22da78e12134df7bd723)
Summary:
These return values are actually signed, meaning that casting will
extend it and then all the bits will be one.
(cherry picked from commit 4ca8ea8c972ae05a891687eda6704ec607184fae)
The default triple of Amazon Linux on AArch64 is aarch64-amazon-linux,
see issue highlighded by PR #109263, somewhat serious linker issues are
encountered if any other triple is being used.
Unfortunately, this makes XFAIL lines like
`XFAIL: target=aarch64{{.*}}-linux-gnu` ineffective, making it
impossible to complete all of the check-cxx on Amazon Linux without
failing.
(cherry picked from commit 8f4ee42d59976a9343d7576ef9a1fe2cf482a057)
- Allow 'u' and 'w' on LASX, LSX or floating point register operands.
- Also add missing description in LangRef.
Fixes#129863.
(cherry picked from commit bae6644e1227b2555f92b1962dac6c2444eaaaf2)
Fixes (keep it open) #130110.
If the incoming value is PHI itself, we can skip this. If we can
guarantee that the other incoming values are neither undef nor poison,
then we can also guarantee that the value isn't either. If we cannot
guarantee that, it makes no sense in calculating it.
(cherry picked from commit 462eb7e28ef4507b16a4b45efb356bc6a3523615)
Fixes a crash with extract_subvectors in Hexagon backend seen when the
source vector is a vector-pair and result vector is not hvx vector size.
LLVM Issue: https://github.com/llvm/llvm-project/issues/128775Fixes#128775
---------
Co-authored-by: aankit-quic <aankit@quicinc.com>
(cherry picked from commit 29d3fc3f11d272a72ac255af9277c740f26c3dfc)
Fixes#106846.
This is what I learned from GCC. I found that GCC does not duplicate the
BB that has indirect jumps with the jump table. I believe GCC has
provided a clear explanation here:
> Duplicate the blocks containing computed gotos. This basically
unfactors computed gotos that were factored early on in the compilation
process to speed up edge based data flow. We used to not unfactor them
again, which can seriously pessimize code with many computed jumps in
the source code, such as interpreters.
(cherry picked from commit dd21aacd76e36d4db157a5d7a7b5370d456426e6)
https://github.com/llvm/llvm-project/pull/129952 /
42d49a77241df73a17cb442973702fc460e7fb90 added this test which is
failing on 32-bit ARM because the alignment chosen is 4 not 8. Which
would make sense if this is a 32/64 bit difference
https://lab.llvm.org/buildbot/#/builders/154/builds/13059
```
<stdin>:34:30: note: scanning from here
define dso_local void @_Z1fv(ptr dead_on_unwind noalias writable sret(%struct.B) align 4 %agg.result) #0 {
^
<stdin>:38:2: note: possible intended match here
%0 = load ptr, ptr @x, align 4
^
```
The other test does not check alignment, so I'm assuming that it is not
important here.
Perform the check for constexpr-unknown values in the same place we
perform checks for other values which don't count as constant
expressions.
While I'm here, also fix a rejects-valid with a reference that doesn't
have an initializer. This diagnostic was also covering up some of the
bugs here.
The existing behavior with -fexperimental-new-constant-interpreter seems
to be correct, but the diagnostics are slightly different; it would be
helpful if someone could check on that as a followup.
Followup to #128409.
Fixes#129844. Fixes#129845.
A bitcast, being defined as a load and a store, can change the lane
order. We need to use a NVCAST instead to keep the lanes out of the
VADDV the same in big-endian. The extracting from a v2i64 vector is
to keep the types of the nvcast legal, but also allow us to replace a
lane mov with a mov 0.
Fixes#129843
(cherry picked from commit ab811e75734a77247dae6df1579fa6f29394f200)
In https://github.com/llvm/llvm-project/pull/97762, we assume the
minimum possible value of X is NaN implies X is NaN. But it doesn't hold
for x86_fp80 format. If the knownbits of X are
`?'011111111111110'????????????????????????????????????????????????????????????????`,
the minimum possible value of X is NaN/unnormal. However, it can be a
normal value.
Closes https://github.com/llvm/llvm-project/issues/130408.
(cherry picked from commit 029e10289a02b438f1a22f401c94ed60ab4bb704)
Also clean up `case tok::r_paren` in
`UnwrappedLineParser::parseParens()`.
Fix#130359
(cherry picked from commit 7d4d8509cbec7eecd8aaf2510015b54bc5c173e1)
If we do not have fp then we do not need to try and custom lower fp16
selects.
Fixes#129394.
(cherry picked from commit cb850fef2a564ea330e8a4878fafb4f5b4a7a98e)
Since N2 will be reused in the fold, we cannot skip N2's undef elements
if the corresponding element in N1 is well-defined.
For example:
```
t2: v4i32 = BUILD_VECTOR Constant:i32<0>, Constant:i32<0>, Constant:i32<0>, Constant:i32<0>
t24: v4i32 = BUILD_VECTOR undef:i32, undef:i32, Constant:i32<1>, undef:i32
t11: v4i32 = vselect t8, t2, t10
```
Before this patch, we fold t11 into:
```
t26: v4i32 = sign_extend t8
t27: v4i32 = add t26, t24
```
The last element of t27 is incorrect.
Closes https://github.com/llvm/llvm-project/issues/129181.
(cherry picked from commit 2709366f75b054e2cba4f61310de5a9605f4aa24)
For some operating systems (e.g. chromiumos), terminfo is a separate
package and library from ncurses. Both are still requirements for curses
support in lldb, individually.
This is a rework of this original spack commit:
9ea2612650
Instead though, this PR uses CMake to detect whether the symbol is
present and defined in the curses library, and only falls back to a separate
tinfo if not found.
Without this fix, LLDB cannot be built on these systems.
Fixes#101368
(cherry picked from commit 8fff0c181f26a5e8b2344c061ebf2559118b1160)
This commit updates the Hexagon backend to handle
vxi1 call operands. It ensures compatibility for
vector types of sizes 4, 8, 16, 32, 64, and 128 x i1 when HVX is
enabled.
~Fixes #59009 and #118879~
(cherry picked from commit 37559c8401cf9236d561eebd75bd3d70be6ab723)
The codecvt class is defined in <locale> and the contents of the
<codecvt> header don't work when localization is disabled. Without this
guard, builds with localization disabled that happen to include
<codecvt> could be broken because they would try to include <__locale>,
which ends up trying to include the locale base API and eventually
platform headers like <xlocale.h> that may not exist.
(cherry picked from commit fda7373daf5790833101c504be1c749bbb0fceb8)
Add header guard macros to clang/lib/Headers/vecintrin.h. Found while
compiling the latest numpy with clang 19 on s390x which ends up
including vecintrin.h twice. The gcc version of this file has header
guards so numpy compiles fine with gcc.
Signed-off-by: Jonathan Albrecht <jonathan.albrecht@ibm.com>
(cherry picked from commit ddaa5b3bfb2980f79c6f277608ad33a6efe8d554)
This also fixes test failures in the clang-cl build configs that started
a couple days ago. It seems like the failures were triggered by an update
to the base image on the Github provided runners.
There were failures in test/libcxx/system_reserved_names.gen.py, due to
an issue in an Clang intrinsics header (avx512fp16intrin.h); this issue
was observed and fixed for Clang 19 in 6f04f46927c. The test does
#define A SYSTEM_RESERVED_NAME
which clashes with a parameter with the name `A` in that header.
By upgrading the toolchain to Clang 19, we get fixed version of this
intrinsics header.
Also update the llvm-mingw toolchains to a version with Clang 19.1.7.
(cherry picked from commit e6a0ee3d1d12c9c02c1a361109e282d18dd2430c)
Since d194c6b9a7fdda7a61abcd6bfe39ab465bf0cc87 this workflow was missing
the secret input which was causing it to fail.
(cherry picked from commit a684e0ea57ebb93c81506c066afb25cb496dcc11)
