StringLiteral is used as internal data of EmbedExpr and we directly use
it as an initializer if a single EmbedExpr appears in the initializer
list of a char array. It is fast and convenient, but it is causing
problems when string literal character values are checked because #embed
data values are within a range [0-2^(char width)] but ordinary
StringLiteral is of maybe signed char type.
This PR introduces new kind of StringLiteral to hold binary data coming
from an embedded resource to mitigate these problems. The new kind of
StringLiteral is not assumed to have signed char type. The new kind of
StringLiteral also helps to prevent crashes when trying to find
StringLiteral token locations since these simply do not exist for binary
data.
Fixes https://github.com/llvm/llvm-project/issues/119256
Fixes#129900
If `operator delete` was called after an unsuccessful constructor call
after `operator new`, we ran into undefined behaviour.
This was discovered by our malfunction tests while preparing an upgrade
to LLVM 20, that explicitly check for such kind of bugs.
(cherry picked from commit 8d38906d08f0189a7a7f865b267f47cab0a3790f)
`WidenIV::widenWithVariantUse` assumes that exactly one of the binop
operands is the IV to be widened. This miscompilation happens when it
tries to sign-extend the "NonIV" operand while the IV is zero-extended.
Closes https://github.com/llvm/llvm-project/issues/135182.
(cherry picked from commit d14acb78065bdd331019924feaaef52e5e744529)
This fixes a regression I traced back to
8b43c1be23
/ https://github.com/llvm/llvm-project/pull/79000
The regression caused an SSE2 instruction, `movsd`, to be emitted as a
replacement for an SSE instruction, `movaps` despite the target
potentially not supporting this instruction, such as when building with
clang using `-march=pentium3`.
Fixes#134607
(cherry picked from commit 08e080ee98832c2aec6f379b04f486bea18730cc)
When coroutines are used w/ both -ffat-lto-objects and -flto=thin,
the coroutine passes are not added to the optimization pipelines.
Ensure they are added before ModuleOptimization to generate a
working ELF object.
Fixes#134409.
(cherry picked from commit 268c065eab06b81a0d7256ac62c0865b3781e236)
On some OS distros such as LoongArch Fedora 38 mate-5 [1], there are
no macro definitions NT_LOONGARCH_HW_BREAK and NT_LOONGARCH_HW_WATCH
in the system header, then there exist some errors when building LLDB
on LoongArch.
(1) Description of Problem:
```
llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp:529:16:
error: 'NT_LOONGARCH_HW_WATCH' was not declared in this scope; did you mean 'NT_LOONGARCH_LBT'?
529 | int regset = NT_LOONGARCH_HW_WATCH;
| ^~~~~~~~~~~~~~~~~~~~~
| NT_LOONGARCH_LBT
llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_loongarch64.cpp:543:12:
error: 'NT_LOONGARCH_HW_BREAK' was not declared in this scope; did you mean 'NT_LOONGARCH_CSR'?
543 | regset = NT_LOONGARCH_HW_BREAK;
| ^~~~~~~~~~~~~~~~~~~~~
| NT_LOONGARCH_CSR
```
(2) Steps to Reproduce:
```
git clone https://github.com/llvm/llvm-project.git
mkdir -p llvm-project/llvm/build && cd llvm-project/llvm/build
cmake .. -G "Ninja" \
-DCMAKE_BUILD_TYPE=Release \
-DLLVM_BUILD_RUNTIME=OFF \
-DLLVM_ENABLE_PROJECTS="clang;lldb" \
-DCMAKE_INSTALL_PREFIX=/usr/local/llvm \
-DLLVM_TARGETS_TO_BUILD="LoongArch" \
-DLLVM_HOST_TRIPLE=loongarch64-redhat-linux
ninja
```
(3) Additional Info:
Maybe there are no problems on the OS distros with newer glibc devel
library, so this issue is related with OS distros.
(4) Root Cause Analysis:
This is because the related Linux kernel commit [2] was merged in
2023-02-25 and the glibc devel library has some delay with kernel,
the glibc version of specified OS distros is not updated in time.
(5) Final Solution:
One way is to ask the maintainer of OS distros to update glibc devel
library, but it is better to not depend on the glibc version.
In order to avoid the build errors, just define NT_LOONGARCH_HW_BREAK
and NT_LOONGARCH_HW_WATCH in LLDB if there are no these definitions in
the system header.
By the way, in order to fit within 80 columns, use C++-style comments
for the new added NT_LOONGARCH_HW_BREAK and NT_LOONGARCH_HW_WATCH.
While at it, for consistency, just modify the current NT_LOONGARCH_LSX
and NT_LOONGARCH_LASX to C++-style comments too.
[1]
https://mirrors.wsyu.edu.cn/fedora/linux/development/rawhide/Everything/loongarch64/iso/livecd-fedora-mate-5.loongarch64.iso
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1a69f7a161a7
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
(cherry picked from commit 50ae1c7bf40ba50aaf3132fa869eda8f06648155)
This reverts commit 8fa0f0efce5fb81eb422e6d7eec74c66dafef4a3.
This change broke assembling for e.g. "armv7s-apple-darwin" triples,
which should enable VFPv4 by default (and did that before this
change), but after this change, only NEON/VFPv3 were available.
This is being fixed properly in latest git main as part of
https://github.com/llvm/llvm-project/pull/130623 (possibly as a
split out change), but any proper fix here seems to have too
much potential surprises for an existing release branch.
The pseudo-instruction LCMPXCHG16B_SAVE_RBX is used when RBX serves as
frame base pointer. At a very late stage it is then translated into a
regular LCMPXCHG16B, preceded by copying the actual argument into RBX,
and followed by restoring the register to the base pointer.
However, in case the `cmpxchg` operates on a local variable, RBX might
also be used as a base for the memory operand in frame finalization, and
we've overwritten RBX with the input operand for `cmpxchg16b`. So we
have to rewrite the memory operand base to use the saved value of RBX.
Fixes#119959.
(cherry picked from commit 9e0ca5720bee96f4b19eeb69a119b5eda3ab5528)
We should have had a release note in LLVM 20 about implementing P2165R4
since that is technically an ABI and API break for zip_view. We don't
expect anyone to actually hit the ABI issue, but we've come across some
(fairly small) breakage due to the API change, so this should at least
be mentioned in the release notes.
(cherry picked from commit 2cd8edd1fff2a9d82902f70270b4209463a34cba)
PR https://github.com/llvm/llvm-project/pull/91400 broke the usage of
HeaderFilterRegex via config file, because it is now created at a
different point in the execution and leads to a different value.
The result of that is that using HeaderFilterRegex only in the config
file does NOT work, in other words clang-tidy stops triggering warnings
on header files, thereby losing a lot of coverage.
This patch reverts the logic so that the header filter is created upon
calling the getHeaderFilter() function.
Additionally, this patch adds 2 unit tests to prevent regressions in the
future:
- One of them, "simple", tests the most basic use case with a single
top-level .clang-tidy file.
- The second one, "inheritance", demonstrates that the subfolder only
gets warnings from headers within it, and not from parent headers.
Fixes#118009Fixes#121969Fixes#133453
Co-authored-by: Carlos Gálvez <carlos.galvez@zenseact.com>
(cherry picked from commit 6333fa5160fbde4bd2cf6afe8856695c13ab621f)
The malloc_zone.cpp test currently fails on Darwin hosts, in SanitizerCommon tests with lsan enabled.
Need to XFAIL this test to buy time to investigate this failure. Also
we're trying to bring the number of test failing on Darwin bots to 0, to
get clearer signal of any new failures.
rdar://145873843
Co-authored-by: Mariusz Borsa <m_borsa@apple.com>
(cherry picked from commit 02837acaaf2cfdfcbf77e4a7f6629575edb6ffb4)
Using `blockaddress` should be more reliable than determining if an
operand comes from a jump table index.
Alternative: Add the `MachineInstr::MIFlag::ComputedGoto` flag when
lowering `indirectbr`. But I don't think this approach is suitable to
backport.
(cherry picked from commit 66f158d91803875de63d8f2a437ce8ecb22c4141)
While building llvm (clang, lld) against emscripten we see this
[error](https://github.com/emscripten-forge/recipes/actions/runs/13803029307/job/38608794602#step:9:1715)
```
│ │ In file included from $SRC_DIR/llvm/lib/Frontend/OpenACC/ACC.cpp:9:
│ │ $SRC_DIR/build/include/llvm/Frontend/OpenACC/ACC.h.inc:192:1: error: unknown type name 'LLVM_ABI'
│ │ 192 | LLVM_ABI Directive getOpenACCDirectiveKind(llvm::StringRef Str);
│ │ | ^
│ │ $SRC_DIR/build/include/llvm/Frontend/OpenACC/ACC.h.inc:192:19: error: expected ';' after top level declarator
│ │ 192 | LLVM_ABI Directive getOpenACCDirectiveKind(llvm::StringRef Str);
│ │ | ^
```
Now this was happening because we weren't defining LLVM_ABI correctly when building against emscripten. If you see [llvm/Support/Compiler.h](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Support/Compiler.h#L206-L210), the condition only checked for the platform __WASM__ . Now Emscripten targets WebAssembly but doesn't imply the platform by default so the check isn't complete to define LLVM_ABI.
The successful build after using this patch can be seen [here](https://github.com/emscripten-forge/recipes/actions/runs/13805214092/job/38614585621)
(cherry picked from commit e57cd100ca297cf81854e35cccbf703edddd4aad)
This also fixes errors when using Clang with step-by-step compilation.
Because the optimization will pass relocation information to memory
access instructions. For example:
t.c:
```
float f = 0.1;
float foo() { return f;}
```
```
clang --target=loongarch64 -O2 -c t.c --save-temps
```
Reviewed By: tangaac, SixWeining
Pull Request: https://github.com/llvm/llvm-project/pull/133225
(cherry picked from commit d055e58334a91dcbaee22eb87bcdae85a1f33cd4)
The File ID is incorrectly calculated, resulting in an out-of-bounds
access. The test code is more complex because the File fetching only
happens in specific scenarios.
---------
Co-authored-by: ShaderKeeper <no-reply@shaderkeeper.com>
Co-authored-by: Chuanqi Xu <yedeng.yd@linux.alibaba.com>
(cherry picked from commit cca0f8113e2f9a1bd662c62dd3ff7e1fa197e6b5)
This attempts to put limits onto CombineBaseUpdate for degenerate cases
like #127477. The biggest change is to add a limit to the number of base
updates to check in CombineBaseUpdate. 64 is hopefully plenty high
enough for most runtime unrolled loops to generate postinc where they
are beneficial.
It also moves the check for isValidBaseUpdate later so that it only
happens if we will generate a valid instruction. The 1024 limit to
hasPredecessorHelper comes from the X86 backend, which uses the same
limit.
I haven't added a test case as it would need to be very big and my
attempts at generating a smaller version did not show anything useful.
Fixes#127477.
(cherry picked from commit 86cf4ed7e9510a6828e95e8b36893eec116c9cf9)
The directive temporarily switches to the .sxdata section to emit data,
and then calls `insert`, which makes `CurFrag` out of sync of the
current section. Call push/switch/pop instead.
Related to #132464
(cherry picked from commit ece72e2731350d9840c6446db9276b04d593cc23)
In 664f345cd53d1f624d94f9889a1c9fff803e3391, a fix was introduced,
attempting to restore LLVM_DIR and Clang_DIR after doing
find_package(Clang).
However, 6775285e7695f2d45cf455f5d31b2c9fa9362d3d added a return if the
clangTidy target wasn't found. If this is hit, we don't restore LLVM_DIR
and Clang_DIR, which causes strange effects if CMake is rerun a second
time.
Move the code for restoring LLVM_DIR and Clang_DIR to directly after the
find_package calls, to make sure they are restored, regardless of the
find_package outcome.
(cherry picked from commit 51bceb46f8eeb7c3d060387be315ca41855933c2)
Reverts llvm/llvm-project#108880 .
The patch has no regression test, no description of why the fix is
necessary, and the code is modifying MC datastructures in a way that's
forbidden in the AsmPrinter.
Fixes#132055.
(cherry picked from commit cd6e959102888279dc7e75a41ebd75a08ac3f7a5)
Set the default processor version to v68 when the user does not specify
one in the command line. This includes changes in the LLVM backed and
linker (lld). Since lld normally sets the version based on inputs, this
change will only affect cases when there are no inputs.
Fixes#127558
(cherry picked from commit c0b2c10e9f3a939c227a26aec3ba377f7cc25667)
Set the default compilation target to V68 if no Hexagon processor is
specified at the command-line.
Add the elf header changes for v81/v83/v85 architectures.
(cherry picked from commit 759ef5811e2297f2cbe7578f7c118668e3467c6a)
For the ordered FP compare bitcode instructions, the Hexagon backend was
assuming that no operand could be a NaN. This assumption is flawed. This
patch fixes the code-generation to produce fpcmp.uo and and appropriate
bit comparison operators to account for the case when an operand to a FP
compare is a NaN.
Fix for https://github.com/llvm/llvm-project/issues/129391
Co-authored-by: aankit-quic <aankit@quicinc.com>
(cherry picked from commit d642eec78fc94ef3c5266dc0b10b8c51ea046e7a)
The missing `PT_GNU_EH_FRAME` was causing C++ exception handling test
failures in llvm-test-suite. We should unconditionally add this argument
like the other drivers do.
Discovered-by: Alexey Karyakin <akaryaki@quicinc.com>
Fixes: #129745
(cherry picked from commit 6657769199ad625ea0cb7f7c054d4f6a27806080)
When checking the template template parameters of template template
parameters, the PartialOrdering context was not correctly propagated.
This also has a few drive-by fixes, such as checking the template parameter
lists of template template parameters, which was previously missing and
would have been it's own bug, but we need to fix it in order to
prevent crashes in error recovery in a simple way.
Fixes#130362
Backport of: https://github.com/llvm/llvm-project/pull/130447
This patch cherry-picks 032ad590d6, 868c89ff0 and 38d71c9bd onto the 20
release branch.
The first patch addresses recently surfaced CTAD problems, which we
believe it would be nice to roll out the fix quickly, given the release
window is not closed yet.
The second patch is a follow-up to the first and fixed a test failure
on the arm32 platform.
The third patch follows-up on the previous patch that I cherry-picked to
the 20 release branch, which removes a unnecessary assertion.
This option prints the name of the DLL that gets imported, when linking
against an import library.
This is implemented using the same strategy as GNU dlltool does; looking
for the contents of .idata$6 or .idata$7 chunks. The right section name
to check for is chosen by identifying whether the library is GNU or LLVM
style. In the case of GNU import libraries, the DLL name is in an
.idata$7 chunk. However there are also other chunks with that section
name (for entries for the IAT or ILT); identify these by looking for
whether a chunk contains relocations.
Alternatively, one could also just look for .idata$2 chunks, look for
relocations at the right offset, and locate data at the symbol that the
relocation points at (which may be in the same or in another object
file).
(cherry picked from commit dcc08a17c781a5066ab17b9791e1c455f7cedbf7)
The symbol type of tls-le must be `TLS`, it was incorrectly set
as `NOTYPE`.
A later commit will fix it.
(cherry picked from commit 87adafcd2e248fa69d1f776a9e60f95df03b885d)
When searching for packets to .align, don't consider ones which would
require padding beyond a label.
There are two problems with padding beyond a label:
- the distance between labels may increase for some offsets to become
too large;
- u/sleb128 values that encode a difference will not be updated because
they are computed before the align command is handled.
This is more a short-term fix/hack. The proper solution would be to
unify `.align` and `.falign` handling and move it to the layout loop.
(cherry picked from commit 1fe463182cead6e7c6119ab410eae9e9d969325a)
ld64 issues a warning about section alignment which was counted as an
unexpected exported symbol and the test failed.
Fixed by disabling all linker warnings using -Wl,-w.
(cherry picked from commit 94426df66a8d7c2321f9e197e5ef9636b0d5ce70)
When attempting to perform complex deinterleaving on an unrolled loop
containing a reduction, the complex deinterleaving pass would fail to
accommodate the wider types when accumulating the unrolled paths.
Instead of trying to alter the incoming IR to fit expectations, the pass
should instead decide against processing any reduction that results in a
non-complex or non-vector value.
(cherry picked from commit 3f4b2f12a1e3e87e4bfb86937cc1ccdd4d38dcf5)
Without this we can try to generate invalid instructions or create
illegal types. This patch generates a SVE fcopysign instead and use its
lowering. BF16 is left out of the moment as it doesn't lower
successfully (but could use the same code as fp16).
(cherry picked from commit d4ab3df320f9eebf11cc5fb600a0919f93678abe)
