If we create a cross toolchain with a ${triple}-ld.lld symlink, clang
finds that symlink and when it uses it, it's not recognized as "lld".
Let's resolve that symlink and consider it when determining lld-ness.
For example, clang provides hexagon-link specific link arguments such as
`-mcpu=hexagonv65` and `-march=hexagon` when
hexagon-unknown-linux-musl-ld.lld is found. lld rejects this with the
following error:
hexagon-unknown-linux-musl-ld.lld: error: unknown emulation:
cpu=hexagonv65
(cherry picked from commit 2dc0de753b6df83e35f3d98e0e6a26c95e3399c0)
The iterator passed to `fixupCalleeSaveRestoreStackOffset` may be
incorrect when it tries to skip over the instructions that get the
current value of 'vg', when there is a 'rdsvl' instruction straight
after the prologue. That's because it doesn't check that the instruction
is still a 'frame-setup' instruction.
On Darwin we don't have any hardware that has SVE support, only SME.
Therefore we don't need to save VG for unwinders and can safely omit it.
This also fixes crashes introduced since this feature landed since Darwin's
compact unwind code can't handle the presence of VG anyway.
rdar://131072344
Remove check for PHI in pred as pointed out in #103688
Reduced the testcase to remove redundant phi in pred
Fixes: #102351
(cherry picked from commit 39601a6e5484de183bf525b7d0624e7890ccd8ab)
The default value of this CPU affects the `FeatureBits` obtained by
`LoongArchTargetELFStreamer` when creating an ELF file, and it will
further affect the `Flags` field in the generated file.
So, the default CPU value should be consistent with the
`initializeSubtargetDependencies` in `LoongArchSubtarget.cpp`.
Otherwise, the `Flags` field may be unexpected.
(cherry picked from commit 75c2888209473884cb3fa5720899d8199dafb8cb)
Need to check that the operand of the abs intrinsic can be safely
truncated before making it part of the minbitwidth transformation.
Fixes#112577
(cherry picked from commit 709abacdc350d63c61888607edb28ce272daa0a0)
The improvements in 63917e1 / #70796 do not check for memory
barriers/unmodelled sideeffects, which means we may incorrectly hoist
loads across memory barriers.
Fix this by checking any machine instruction in the loop is a load-fold
barrier.
PR: https://github.com/llvm/llvm-project/pull/116987
(cherry picked from commit ef102b4a6333a304e36dc623d5381257a7ef1ed6)
This patch bails out non-dedicated exits to avoid adding exiting
conditions to invalid context.
Closes https://github.com/llvm/llvm-project/issues/116553.
(cherry picked from commit 52361d0368b79841be12156bf03cf8c1851e5df7)
Counterexample: 219 is a multiple of 73. But `sext i8 219 to i16 =
65499` is not.
Fixes https://github.com/llvm/llvm-project/issues/116483.
(cherry picked from commit 458dfbd855806461b4508bf8845cafe0411dbfd4)
This commit fixes an issue in the large code model where non-dso_local
function calls did not use the GOT as expected in PIC mode. Instead,
direct PC-relative access was incorrectly applied, leading to linker
errors when building shared libraries.
For `ExternalSymbol`, it is not possible to determine whether it is
dso_local during pseudo-instruction expansion. We use target flags to
differentiate whether GOT should be used.
Cherry-picked from #117099, used for fix linker errors when bulding
shared libraries with large code model.
Fixes#116809.
After running some passes (SimpleLoopUnswitch, LoopInstSimplify, etc.),
MemorySSA might be outdated, and the instruction `I` may have become a
non-memory touching instruction.
LICM has already handled this, but it does not pass
`CreationMustSucceed=false` to `createDefinedAccess`.
(cherry picked from commit 18b02bbf441660683df7f3925946984203d49bab)
Range checks for R_HEX_B22_PCREL did not account for the fact that
offset is measured in instructions, not bytes.
Add a test for all range-checked relocations.
On loongarch64 with lsx extension, we select `VBITREV_W` for `v4i32 (xor
X, (shl splat(1), Y))`:
8e66303916/llvm/lib/Target/LoongArch/LoongArchLSXInstrInfo.td (L1583-L1584)
And `vsplat_imm_eq_1` is defined as:
8e66303916/llvm/lib/Target/LoongArch/LoongArchLSXInstrInfo.td (L77-L87)
For the `(bitconvert (v4i32 (build_vector)))` case, the pattern is
expected to be:
```
PATTERN: (xor:{ *:[v4i32] } v4i32:{ *:[v4i32] }:$vj, (shl:{ *:[v4i32] } (bitconvert:{ *:[v4i32] } (build_vector:{ *:[v4i32] }))<<P:Predicate_vsplat_imm_eq_1>>, v4i32:{ *:[v4i32] }:$vk))
RESULT: (VBITREV_W:{ *:[v4i32] } v4i32:{ *:[v4i32] }:$vj, v4i32:{ *:[v4i32] }:$vk)
```
However, `simplifyTree` drops the `bitconvert` node and its predicates:
8e66303916/llvm/utils/TableGen/Common/CodeGenDAGPatterns.cpp (L3036-L3062)
Then llvm will match `vsplat_imm_eq_1` for any v4i32 splats and cause a
miscompilation:
```
PATTERN: (xor:{ *:[v4i32] } v4i32:{ *:[v4i32] }:$vj, (shl:{ *:[v4i32] } (build_vector:{ *:[v4i32] }), v4i32:{ *:[v4i32] }:$vk))
RESULT: (VBITREV_W:{ *:[v4i32] } v4i32:{ *:[v4i32] }:$vj, v4i32:{ *:[v4i32] }:$vk)
```
This patch adds additional checks for predicates associated with the
trivial bitconvert node. Unused patterns in the LoongArch target are
also removed.
Fixes https://github.com/llvm/llvm-project/issues/116008.
(cherry picked from commit c727b48287cc96888f9e262f23d53cf635cf3b3d)
Resolves a FIXME and avoids needing to workaround #116075.
Adding parentheses around the (vsplat_imm_eq_1) fixes the error cited in
the FIXME by changing the ComplexPattern from a leaf node to an
operator.
(cherry picked from commit 2f4572f5e7e2d7f4626e825404c11f07d191fb05)
This parameter seems unintentional here; we're trying to grep
the input on stdin, from the earlier stage in the pipeline.
Since a recent update on Github Actions runners, the previous
form (grepping a file, while piping in data on stdin) would fail
running the test, with the test runner Python script throwing
an exception when evaluating it:
File "D:\a\llvm-mingw\llvm-mingw\llvm-project\llvm\utils\lit\lit\TestRunner.py", line 935, in _executeShCmd
out = procs[i].stdout.read()
^^^^^^^^^^^^^^^^^^^^^^
File "C:\hostedtoolcache\windows\Python\3.12.7\x64\Lib\encodings\cp1252.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: a bytes-like object is required, not 'NoneType'
(cherry picked from commit c2717a89b8437d041d532c7b2c535ca4f4b35872)
Promote v2i8 to v2i16, fixes a crash.
Re-enable a test in NVPTX/vector-returns.ll
Partial cherry-pick of fda2fea w/o the test which does not exist in release/19.x
https://github.com/llvm/llvm-project/issues/104864
So far we have assumed that we only rethrow the exception caught in the
innermost EH pad. This is true in code we directly generate, but after
inlining this may not be the case. For example, consider this code:
```ll
ehcleanup:
%0 = cleanuppad ...
call @destructor
cleanupret from %0 unwind label %catch.dispatch
```
If `destructor` gets inlined into this function, the code can be like
```ll
ehcleanup:
%0 = cleanuppad ...
invoke @throwing_func
to label %unreachale unwind label %catch.dispatch.i
catch.dispatch.i:
catchswitch ... [ label %catch.start.i ]
catch.start.i:
%1 = catchpad ...
invoke @some_function
to label %invoke.cont.i unwind label %terminate.i
invoke.cont.i:
catchret from %1 to label %destructor.exit
destructor.exit:
cleanupret from %0 unwind label %catch.dispatch
```
We lower a `cleanupret` into `rethrow`, which assumes it rethrows the
exception caught by the nearest dominating EH pad. But after the
inlining, the nearest dominating EH pad is not `ehcleanup` but
`catch.start.i`.
The problem exists in the same manner in the new (exnref) EH, because it
assumes the exception comes from the nearest EH pad and saves an exnref
from that EH pad and rethrows it (using `throw_ref`).
This problem can be fixed easily if `cleanupret` has the basic block
where its matching `cleanuppad` is. The bitcode instruction `cleanupret`
kind of has that info (it has a token from the `cleanuppad`), but that
info is lost when when we enter ISel, because `TargetSelectionDAG.td`'s
`cleanupret` node does not have any arguments:
5091a359d9/llvm/include/llvm/Target/TargetSelectionDAG.td (L700)
Note that `catchret` already has two basic block arguments, even though
neither of them means `catchpad`'s BB.
This PR adds the `cleanuppad`'s BB as an argument to `cleanupret` node
in ISel and uses it in the Wasm backend. Because this node is also used
in X86 backend we need to note its argument there too but nothing more
needs to change there as long as X86 doesn't need it.
---
- Details about changes in the Wasm backend:
After this PR, our pseudo `RETHROW` instruction takes a BB, which means
the EH pad whose exception it needs to rethrow. There are currently two
ways to generate a `RETHROW`: one is from `llvm.wasm.rethrow` intrinsic
and the other is from `CLEANUPRET` we discussed above. In case of
`llvm.wasm.rethrow`, we add a '0' as a placeholder argument when it is
lowered to a `RETHROW`, and change it to a BB in LateEHPrepare. As
written in the comments, this PR doesn't change how this BB is computed.
The BB argument will be converted to an immediate argument as with other
control flow instructions in CFGStackify.
In case of `CLEANUPRET`, it already has a BB argument pointing to an EH
pad, so it is just converted to a `RETHROW` with the same BB argument in
LateEHPrepare. This will also be lowered to an immediate in CFGStackify
with other control flow instructions.
---
Fixes#114600.
The original patch (25fd366d6a7d40266ff27c134ed8beb0a90cc33b) was
reverted in 083a5cdbeab09517d8345868970d4f41170d7ed2 because it broke
some buildbots.
This revised patch makes two changes:
- Reverts to *pre-#98200* behavior for Android. This avoids a build
breakage on Android.
- Only define KeepUnblocked if SANITIZER_LINUX: this avoids a build
breakage on solaris, which does not support internal_sigdelset.
N.B. Other buildbot failures were non-sanitizer tests and are therefore
unrelated.
Original commit message:
My earlier patch https://github.com/llvm/llvm-project/pull/98200
caused a regression because it unconditionally unblocked synchronous
signals, even if the user program had deliberately blocked them.
This patch fixes the issue by checking the current signal mask, as
suggested by Vitaly. It also adds tests.
Fixes#113385
(cherry picked from commit 531acf9e2f24977d2556b39229b22f4518a1faa5)
A test case showed up where the new vector type is v24i16, which is not a simple
MVT. In order to get an extended value type for cases like this, EVT::getVectorVT()
needs to be called instead of MVT::getVectorVT(), otherwise the following call
to getVectorElementType() in combineExtract() will fail.
(cherry picked from commit 22bc9db92b46965882b1c77aebc86430149b0912)
On Apple platforms, using system-libcxxabi as an ABI library wouldn't
work because we'd try to re-export symbols from libc++abi that the
system libc++abi.dylib might not have. Instead, only re-export those
symbols when we're using the in-tree libc++abi.
This does mean that libc++.dylib won't re-export any libc++abi symbols
when building against the system libc++abi, which could be fixed in
various ways. However, the best solution really depends on the intended
use case, so this patch doesn't try to solve that problem.
As a drive-by, also improve the diagnostic message when the user forgets
to set the LIBCXX_CXX_ABI_INCLUDE_PATHS variable, which would previously
lead to a confusing error.
Closes#104672
(cherry picked from commit 21da4e7f51c7adfd0b1c5defc8bd0d16ea1ce759)
Reproducer:
```
//--- a.cppm
export module a;
int func();
static int a = func();
//--- a.cpp
import a;
```
The `func()` should only execute once. However, before this patch we
will somehow import `static int a` from a.cppm incorrectly and
initialize that again.
This is super bad and can introduce serious runtime behaviors.
And also surprisingly, it looks like the root cause of the problem is
simply some oversight choosing APIs.
(cherry picked from commit 259eaa6878ead1e2e7ef572a874dc3d885c1899b)
Arm64EC uses a special name mangling mode that adds `$$h` between the
symbol name and its type. In MSVC's name mangling `@` is used to
separate the name and type BUT it is also used for other purposes, such
as the separator between paths in a fully qualified name.
The original algorithm was quite fragile and made assumptions that
didn't hold true for all MSVC mangled symbols, so instead of trying to
improve this algorithm we are now using the demangler to indicate where
the insertion point should be (i.e., to parse the fully-qualified name
and return the current string offset).
Also fixed `isArm64ECMangledFunctionName` to search for `@$$h` since the
`$$h` must always be after a `@`.
Fixes#115231
While building llvm (clang, lld) for wasm using emscripten (recipe
hosted on emscripten-forge
https://github.com/emscripten-forge/recipes/tree/main/recipes/recipes_emscripten/llvm)
I ended up with this error
```
│ │ wasm-ld: error: ../../../../lib/libclangInterpreter.a(Wasm.cpp.o): undefined symbol: lld::wasm::link(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm:
│ │ :raw_ostream&, bool, bool)
```
This is due to the link function here
a4819bd46d/clang/lib/Interpreter/Wasm.cpp (L25-L30)
This was added through this PR (https://github.com/llvm/llvm-project/pull/86402) as an attempt to support running clang-repl and executing C++ code interactively inside a Javascript engine using WebAssembly when built with Emscripten.
The definition for link is present in lldwasm and when building for the emscripten platform we should be linking against it.
(cherry picked from commit 075581f34035c01659cc883d0d69336c279ef0d5)
Previously, building `multc3.c` on A64 with GCC 7 or up but 9 and lower
will attempt to reference `__builtin_copysignq`, an [x86-specific
intrinsic][1]:
```
$ gcc -c multc3.c
In file included from fp_lib.h:24,
from multc3.c:14:
multc3.c: In function '__multc3':
int_math.h:71:32: warning: implicit declaration of function '__builtin_copysignq'; did you mean '__builtin_copysign'? [-Wimplicit-function-declaration]
#define crt_copysignf128(x, y) __builtin_copysignq((x), (y))
^~~~~~~~~~~~~~~~~~~
```
This is because `__has_builtin` is from GCC 10, and defined to 0 at the
top of int_math.h for affected GCC versions, so the fallback definition
is used. But `__builtin_copysignq` is unavailable on A64.
Use version detection to find `__builtin_copysignf128` instead. It's
available since GCC 7 and [available][2] on both x86 and A64, given this
macro is only used when `CRT_HAS_IEEE_TF`.
---
I realize this is fixing a problem for an out-of-tree build
configuration, but help would be greatly appreciated. Rust
[builds](https://github.com/rust-lang/compiler-builtins) `multc3.c` with
GCC 8 and this mis-selection is causing [build
issues](https://github.com/rust-lang/rust/issues/125619) way downstream.
ref: d2ce3e9621411f3391def327f89e3a650918989f
[1]: https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html
[2]: https://gcc.gnu.org/gcc-7/changes.html
(cherry picked from commit 8aa9d6206ce55bdaaf422839c351fbd63f033b89)
The lsxintrin.h and and lasxintrin.h headers uses `unsigned char`
vectors instead of `signed char` vectors. GCC also uses `unsigned char`
for them, so align their definition with the headers and GCC.
Fixes#110834.
Depends on #114512.
(cherry picked from commit 4f740f9d77cd038c8e55195fa189748e58ea6476)
The lsxintrin.h and and lasxintrin.h headers uses `signed char` vectors
instead of `unsigned char` vectors. GCC also uses `signed char` for
them, so align their definition with the headers and GCC.
Depends on #114511. Part of #110834 fix.
(cherry picked from commit 4006b28d102b09f4c736ef0f2664873305fedcd3)
These builtins operate on int8 vectors, not int16 vectors. So the old
definition does not make any sense.
Depends on #114510. Part of #110834 fix.
(cherry picked from commit 92daad2eac587cb0592de019cd5f6cbb7c42bb78)
`-flax-vector-conversions=none` does not allow an implicit conversion
from `signed char` vector to `char` vector, and we cannot remove
`signed`
from `v16i8` or `v32i8` because doing so will break our expectation with
`-fno-signed-char`. So to make lsxintrin.h and lasxintrin.h work fine
with `-flax-vector-conversions=none`, we must use `signed char` instead
of `char`.
The change is just done via
sed 's/V16c/V16Sc/g' -i BuiltinsLoongArchLSX.def
sed 's/V32c/V32Sc/g' -i BuiltinsLoongArchLASX.def
Depends on #114509. Part of #110834 fix.
(cherry picked from commit b88505414d47ca267f4df8823309264f78935686)
The use of CLANG_NO_DEFAULT_CONFIG in the tests was added because some
Linux distributions had a global default config file, that added flags
relating to hardening, which interfere with the sanitizer tests. By
setting CLANG_NO_DEFAULT_CONFIG, the global default config files that
are found are ignored, and the sanitizers get the expected default
compiler behaviour.
(This was https://github.com/llvm/llvm-project/issues/60394, which was
fixed in 8ab762557fb057af1a3015211ee116a975027e78.)
However, some toolchains may rely on default config files for mandatory
parts required for functioning at all - setting things like sysroots,
-rtlib, -unwindlib, -stdlib, -fuse-ld etc. In such a case we can't
forcibly disable any default config, because it will break the otherwise
working toolchain.
Add a test for whether the compiler works while passing
--no-default-config to it. If the option is accepted and the toolchain
still works while that is set, set CLANG_NO_DEFAULT_CONFIG while running
tests.
(This adds a little bit of inconsistency, as we're testing for the
command line option, while using the environment variable. However doing
compile testing with an environment variable isn't quite as easily
doable, and passing an extra command line flag to all compile commands
while testing, is a bit clumsy - therefore this inconsistency.)
(cherry picked from commit a14a83d9a102253eca7c02ff4c35a2ce3f7de6e5)
The Fixups vector passed into this function may already have fixups in
it from earlier instructions. We should not erase those. We just want to
erase fixups added by this function.
Fixes#108612.
(cherry picked from commit c3d3cef8d58377b02032b07b5f094a402a70435a)
Since b4130bee6bfd34d8045f02fc9f951bcb5db9d85c, we check for
_LIBCPP_HAS_THREAD_API_PTHREAD to decide between using
SetThreadDescription or pthread_setname_np for setting the thread name.
c6f3b7bcd0596d30f8dabecdfb9e44f9a07b6e4c changed how libcxx defines
their configuration macros - now they are always defined, but defined to
0 or 1, while they previously were either defined or undefined.
As these libcxx defines used to be defined to an empty string (rather
than expanding to 1) if enabled, we can't easily produce an expression
that works both with older and newer libcxx. Additionally, these defines
are libcxx internal config macros that aren't a detail that isn't
supported and isn't meant to be relied upon.
Simply skip trying to set thread name on MinGW as we can't easily know
which kind of thread native handle we have. Setting the thread name is
only a nice to have, quality of life improvement - things should work
the same even without it.
Additionally, libfuzzer isn't generally usable on MinGW targets yet
(Clang doesn't include it in the getSupportedSanitizers() method for the
MinGW target), so this shouldn't make any difference in practice anyway.
(cherry picked from commit 87f4bc0acad65b1d20160d4160c7778b187125fc)
The ASTWriter currently assumes template type constraints to be
initialized ((bool)getTypeConstraint() == hasTypeConstraint()). Issues
#99036 and #109354 identified a scenario where this assertion is
violated.
This patch removes the assumption and adds another boolean to the
serialization, to explicitly encode whether the type constraint has been
initialized.
The same issue was incidentally fixed on the main branch by #111179.
This solution avoids backporting #111179 and its dependencies.
LazyOffsetPtr currently relies on uint64_t being able to store a pointer
and, unless sizeof(uint64_t) == sizeof(void *), little endianness, since
getAddressOfPointer reinterprets the memory as a pointer. This also
doesn't properly respect the C++ object model.
As removing getAddressOfPointer would have wide-reaching implications,
improve the implementation to account for these problems by using
placement new and a suitably sized-and-aligned buffer, "right"-aligning
the objects on big-endian platforms so the LSBs are in the same place
for use as the discriminator.
Fixes: bc73ef0031b50f7443615fef614fb4ecaaa4bd11
Fixes: https://github.com/llvm/llvm-project/issues/111993
(cherry picked from commit 76196998e25b98d81abc437708622261810782ca)
