Follows up on commit cd5d5ce235 by
additionally ignoring relative paths ending in "lto-wrapper.exe" as
can be the case for GCC cross-compiled for Windows.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D138065
(cherry picked from commit cf4f35b78871aecc21e663067c57e60595bd7197)
This patch is spamming compiles with unhelpful and confusing messages.
E.g. the Linux kernel uses "grep -q" in several places. It's meant to
quit with a return code of zero when the first match is found. This can
cause a SIGPIPE signal, but that's expected, and there's no way to turn
this error message off to avoid spurious error messages.
UNIX03 apparently doesn't require printing an error message on SIGPIPE,
but specifically when there's an error on the stdout stream in a normal
program flow, e.g. when SIGPIPE trap is disabled.
A separate patch is planned to address the specific case we care most
about (involving llvm-nm).
This reverts commit b89bcefa62.
Link: https://github.com/llvm/llvm-project/issues/59037
Link: https://github.com/ClangBuiltLinux/linux/issues/1651
Differential Revision: https://reviews.llvm.org/D138244
(cherry picked from commit 4787efa38066adb51e2c049499d25b3610c0877b)
Currently, codegen doesn't support cases where the type size doesn't
match the alloc size. Skip them for now.
Fixes#58722.
(cherry picked from commit 758699c39984296f20a4dac44c6892065601c4cd)
Fix the failure caused by change in SwigValueWraper for C++11 and later
for improved move semantics in SWIG commit.
d1055f4b3d
(cherry picked from commit f0a25fe0b746f56295d5c02116ba28d2f965c175)
Varargs and inalloca have a weird interaction where varargs are actually
passed via the inalloca alloca. Removing inalloca breaks the varargs
because they're still not passed as separate arguments.
Fixes#58718
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D137182
(cherry picked from commit 8c49b01a1ee051ab2c09be4cffc83656ccc0fbe6)
The Clang Static Analyzer will crash on this code:
```lang=C++
struct Box {
int value;
};
template <Box V> int get() {
return V.value;
}
template int get<Box{-1}>();
```
https://godbolt.org/z/5Yb1sMMMb
The problem is that we don't account for encountering `TemplateParamObjectDecl`s
within the `DeclRefExpr` handler in the `ExprEngine`.
IMO we should create a new memregion for representing such template
param objects, to model their language semantics.
Such as:
- it should have global static storage
- for two identical values, their addresses should be identical as well
http://eel.is/c%2B%2Bdraft/temp.param#8
I was thinking of introducing a `TemplateParamObjectRegion` under `DeclRegion`
for this purpose. It could have `TemplateParamObjectDecl` as a field.
The `TemplateParamObjectDecl::getValue()` returns `APValue`, which might
represent multiple levels of structures, unions and other goodies -
making the transformation from `APValue` to `SVal` a bit complicated.
That being said, for now, I think having `Unknowns` for such cases is
definitely an improvement to crashing, hence I'm proposing this patch.
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D135763
(cherry picked from commit b062ee7dc4515b0a42157717105839627d5542bb)
This is necessary at least on PPC32.
Depends on D136280.
Bug: https://bugs.gentoo.org/874024
Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
Tested-by: erhard_f@mailbox.org <erhard_f@mailbox.org>
Differential Revision: https://reviews.llvm.org/D136282
(cherry picked from commit 20132d8eaa68a6c53e152718beda1dc0f4c9ff6c)
Also simplify code for liblldCommon using the new LLVM_ATOMIC_LIB variable.
Depends on D136280.
Bug: https://bugs.gentoo.org/832675
Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
Tested-by: erhard_f@mailbox.org <erhard_f@mailbox.org>
Differential Revision: https://reviews.llvm.org/D136281
(cherry picked from commit f0b451c77f14947e3e7d314f048679fa2f5c6298)
* Set LLVM_ATOMIC_LIB to keep track of when we need to link against libatomic.
* Add detection of mold linker which is required for this.
* Use --as-needed when linking against libatomic as a bonus. On some platforms,
libatomic may be required only sometimes.
Bug: https://bugs.gentoo.org/832675
Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
Tested-by: erhard_f@mailbox.org <erhard_f@mailbox.org>
Differential Revision: https://reviews.llvm.org/D136280
(cherry picked from commit fa981b541365190ae646d2dce575706cd0626cf7)
Add the missing include to fix an error when `cmake_push_check_state()`
is called and incidentally the CMakePushCheckState module is not loaded
by any other check running prior to `FindLibEdit.cmake`:
CMake Error at /var/no-tmpfs/portage/dev-util/lldb-15.0.4/work/cmake/Modules/FindLibEdit.cmake:24 (cmake_push_check_state):
Unknown CMake command "cmake_push_check_state".
Call Stack (most recent call first):
cmake/modules/LLDBConfig.cmake:52 (find_package)
cmake/modules/LLDBConfig.cmake:59 (add_optional_dependency)
CMakeLists.txt:28 (include)
Gentoo Bug: https://bugs.gentoo.org/880065
Differential Revision: https://reviews.llvm.org/D137555
(cherry picked from commit 3676a86a4322e8c2b9c541f057b5d3704146b8f3)
gnu17 and earlier modes automatically expose several POSIX C APIs, and
this was accidentally disabled for gnu2x in
7d644e1215.
This restores the behavior for gnu2x mode (without changing the
behavior in C standards modes instead of GNU modes).
Fixes#56607
Fixes warnings (or errors, if someone injects -Werror in their build system,
which happens in fact with some folks vendoring LLVM too) with Clang 16:
```
+/var/tmp/portage.notmp/portage/sys-devel/llvm-15.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: warning: a function declaration without a prototype
is deprecated in all versions of C [-Wstrict-prototypes]
-/var/tmp/portage.notmp/portage/sys-devel/llvm-14.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: error: a function declaration without a prototype is
deprecated in all versions of C [-Werror,-Wstrict-prototypes]
int main() {return 0;}
^
void
```
Differential Revision: https://reviews.llvm.org/D137503
(cherry picked from commit 32a2af44e1e882f13d1cc2817f0a8d4d8b375d4d)
Surprisingly these were getting legalized to something
zero initialized.
This fixes an infinite loop when combining some vector types.
Also fixes zero initializing some undef values.
SimplifyDemandedVectorElts / SimplifyDemandedBits are not checking
for the legality of the output undefs they are replacing unused
operations with. This resulted in turning vectors into undefs
that were later re-legalized back into zero vectors.
(cherry picked from commit 7a84624079a2656c684bed6100708544500c5a32)
For the following program,
$ cat t.c
struct t {
int (__attribute__((btf_type_tag("rcu"))) *f)();
int a;
};
int foo(struct t *arg) {
return arg->a;
}
Compiling with 'clang -g -O2 -S t.c' will cause a failure like below:
clang: /home/yhs/work/llvm-project/clang/lib/Sema/SemaType.cpp:6391: void {anonymous}::DeclaratorLocFiller::VisitParenTypeLoc(clang::ParenTypeLoc):
Assertion `Chunk.Kind == DeclaratorChunk::Paren' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
......
#5 0x00007f89e4280ea5 abort (/lib64/libc.so.6+0x21ea5)
#6 0x00007f89e4280d79 _nl_load_domain.cold.0 (/lib64/libc.so.6+0x21d79)
#7 0x00007f89e42a6456 (/lib64/libc.so.6+0x47456)
#8 0x00000000045c2596 GetTypeSourceInfoForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0
#9 0x00000000045ccfa5 GetFullTypeForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0
......
The reason of the failure is due to the mismatch of TypeLoc and D.getTypeObject().Kind. For example,
the TypeLoc is
BTFTagAttributedType 0x88614e0 'int btf_type_tag(rcu)()' sugar
|-ParenType 0x8861480 'int ()' sugar
| `-FunctionNoProtoType 0x8861450 'int ()' cdecl
| `-BuiltinType 0x87fd500 'int'
while corresponding D.getTypeObject().Kind points to DeclaratorChunk::Paren, and
this will cause later assertion.
To fix the issue, similar to AttributedTypeLoc, let us skip BTFTagAttributedTypeLoc in
GetTypeSourceInfoForDeclarator().
Differential Revision: https://reviews.llvm.org/D136807
Implement CanLowerReturn and associated CallingConv changes for SPARC/SPARC64.
In particular, for SPARC64 there's new `RetCC_Sparc64_*` functions that handles the return case of the calling convention.
It uses the same analysis as `CC_Sparc64_*` family of funtions, but fails if the return value doesn't fit into the return registers.
This makes calls to functions with big return values converted to an sret function as expected, instead of crashing LLVM.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D132465
(cherry picked from commit d3fcbee10d893b9e01e563c3840414ba89283484)
We already do this for personality pointers referenced from compact
unwind entries; this patch extends that behavior to personalities
referenced via EH frames as well.
This reduces the number of distinct personalities we need in the final
binary, and helps us avoid hitting the "too many personalities" error.
I renamed `UnwindInfoSection::prepareRelocations()` to simply `prepare`
since we now do some non-reloc-specific stuff within.
Fixes#58277.
Reviewed By: #lld-macho, oontvoo
Differential Revision: https://reviews.llvm.org/D135728
(cherry picked from commit 7b45dfc6811a52ff4e9a6054dc276d70d77fddaf)
Fixes github.com/clangd/clangd/issues/1216
If the Snippet string is empty, Snippet.front() would trigger a crash.
Move the Snippet->empty() check up a few lines to avoid this. Should not
break any existing behavior.
Differential Revision: https://reviews.llvm.org/D134137
(cherry picked from commit 60528c690a4c334d2a3a2c22eb97af9e67d7a91d)
When looking at template arguments in LLDB, we usually care about what
the user passed in his code, not whether some of those arguments where
passed as a variadic parameter pack.
This patch extends all the C++ APIs to look at template parameters to
take an additional 'expand_pack' boolean that automatically unwraps the
potential argument packs. The equivalent SBAPI calls have been changed
to pass true for this parameter.
A byproduct of the patch is to also fix the support for template type
that have only a parameter pack as argument (like the OnlyPack type in
the test). Those were not recognized as template instanciations before.
The added test verifies that the SBAPI is able to iterate over the
arguments of a variadic template.
The original patch was written by Fred Riss almost 4 years ago.
Differential revision: https://reviews.llvm.org/D51387
(cherry picked from commit b706f56133a77f9d7c55270ac24ff59e6fce3fa4)
Unfortunately these notes were compiled until now, but these are the release notes for SystemZ.
(Did not find anything under clang)
@tstellar Should I push this patch onto release/15.x once approved, or will you apply it?
Differential Revision: https://reviews.llvm.org/D134430
```
template <typename T> struct A {
A() {}
int value = 0;
};
template <typename Value> struct B {
static A<int> a;
};
template <typename Value> A<int> B<Value>::a;
inline int foo() {
return B<int>::a.value;
}
```
```
clang++ -c -fno-pic a.cc -o weak.o
g++ -c -fno-pic a.cc -o unique.o # --enable-gnu-unique-object
# Duplicate symbol error. In postParse, we do not check `sym.binding`
ld.lld -e 0 weak.o unique.o
```
Mixing GCC and Clang object files in this case is not ideal. .bss._ZGVN1BIiE1aE
has different COMDAT groups. It appears to work in practice because the guard
variable prevents harm due to double initialization.
For the linker, we just stick with the rule that a weak binding does not cause
"duplicate symbol" errors.
Close https://github.com/llvm/llvm-project/issues/58232
Differential Revision: https://reviews.llvm.org/D136381
(cherry picked from commit 0051b6bb78772b0658f28e5f31ddf91c1589aab5)
This was remangling the old function rather than the new one, and
could result in failures when we were performing both a struct
return upgrade and an opaque pointer upgrade.
(cherry picked from commit c8938809d155682ef5eec170897b8c26b8cbf3ea)
Fixes an SROA crash.
Fallout from opaque pointers since with typed pointers we'd bail out at the bitcast.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D136119
(cherry picked from commit 6219ec07c6f8d1ead51beca7cf21fbf2323c51d7)
This check performs an extremely large amount of work (for each variable, it
runs very many full matcher-driven traversals of the whole scope the variable
is defined in).
When (inadvertently) enabled for Fuchsia, it regressed BuildAST times by >10x
(400ms -> 7s on my machine).
Differential Revision: https://reviews.llvm.org/D135829
(cherry picked from commit e78165f0ba1e2fbf72b36a36c8560645b69a168a)
Previously, some uses of std::function with blocks would crash when ARC was enabled.
rdar://100907096
Differential Revision: https://reviews.llvm.org/D135706
(cherry picked from commit 0e4802bf45952b1120c52d4d1bf6bfa2800fd102)
This module is used to find the system zstd library. The imported
targets intentionally use the same name as the generate zstd config
CMake file so these can be used interchangeably.
Differential Revision: https://reviews.llvm.org/D134990
(cherry picked from commit 2d4fd0b6d5d5582ebb8b521d807104235d67aee4)
Add LLVM_ENABLE_ZSTD to llvm_canonicalize_cmake_booleans(). This is
needed to ensure that the substitutions in lit.site.cfg.py resolve
to correct Python booleans.
Differential Revision: https://reviews.llvm.org/D135357
(cherry picked from commit bc4bcbcfc820b324f680e8f260691c38052eedc9)
Fix the use_lld() to use llvm_shlib_dir similarly to how use_clang()
does it. This fixes use_lld() wrongly prepending llvm_libs_dir,
i.e. the directory with system-installed LLVM libraries before
the build directory of standalone build. As a result, the shared
libraries from an earlier version of clang end up being used instead of
the newly built version when running the test suite prior to installing.
To reproduce the problem, build and install LLVM with dylibs first,
e.g.:
cmake ../llvm -G Ninja -DCMAKE_BUILD_TYPE=MinSizeRel \
-DCMAKE_INSTALL_PREFIX="${HOME}"/llvm-test \
-DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON \
-DLLVM_INSTALL_UTILS=ON
ninja install
Then build clang against that installation and run tests:
export LD_LIBRARY_PATH=~/llvm-test/lib
export PATh=~/llvm-test/bin:"${PATH}"
cmake ../clang -G Ninja -DCMAKE_BUILD_TYPE=MinSizeRel \
-DCMAKE_INSTALL_PREFIX="${HOME}"/llvm-test \
-DCLANG_LINK_CLANG_DYLIB=ON -DLLVM_BUILD_TESTS=ON \
-DLLVM_EXTERNAL_LIT="${PWD}"/bin/llvm-lit
ninja check-clang
The tests will be run with LD_LIBRARY_PATH of:
/home/${USER}/llvm-test/lib:/home/${USER}/llvm-project/build-clang/lib
As a result, installed libclang-cpp will take precedence over the one
from build dir. With the patch, the correct path is used, i.e.:
/home/${USER}/llvm-project/build-clang/lib:/home/${USER}/llvm-test/lib
Differential Revision: https://reviews.llvm.org/D135368
(cherry picked from commit a64ea173d7b152678780d5443407d1071277642b)
This reverts commit 20d798bd47.
This commit caused crashes in some cases, see github issue #58152.
This is fixed on main, but backporting it requires multiple
nontrivial cherrypicks.
Updating llvm/test/Transforms/LoopVectorize/create-induction-resume.ll
with update_test_checks.py, so this isn't an exact automatic revert,
as that test case was added after the reverted commit.
This fixes#58152 for the release branch.
These fields are guarded elsewhere, but were missing here.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D133778
(chery picked from a9ffb473453519bae158e5d9c72431aa0f6aac2b)
A few cases were not handled correctly. Notably:
#define ID(X) X
#define HIDE a ID(b)
HIDE
spelledForExpanded() would claim HIDE is an equivalent range of the 'b' it
contains, despite the fact that HIDE also covers 'a'.
While trying to fix this bug, I found findCommonRangeForMacroArgs hard
to understand (both the implementation and how it's used in spelledForExpanded).
It relies on details of the SourceLocation graph that are IMO fairly obscure.
So I've added/revised quite a lot of comments and made some naming tweaks.
Fixes https://github.com/clangd/clangd/issues/1289
Differential Revision: https://reviews.llvm.org/D134618
(cherry picked from commit 67268ee11c220b1dfdf84afb10a12371c5ae6400)
When we aim a hint at some expanded tokens, we're only willing to attach it
to spelled tokens that exactly corresponde.
e.g.
int zoom(int x, int y, int z);
int dummy = zoom(NUMBERS);
Here we want to place a hint "x:" on the expanded "1", but we shouldn't
be willing to place it on NUMBERS, because it doesn't *exactly*
correspond (it has more tokens).
Fortunately we don't even have to implement this algorithm from scratch,
TokenBuffer has it.
Fixes https://github.com/clangd/clangd/issues/1289
Fixes https://github.com/clangd/clangd/issues/1118
Fixes https://github.com/clangd/clangd/issues/1018
Differential Revision: https://reviews.llvm.org/D133982
(cherry picked from commit 924974a3a13b03090d04860f209ce11b3d9d00a6)
Assigning char* (pointing at comment start) to StringRef was causing us
to scan the rest of the source file looking for the null terminator.
This seems to be eating about 8% of our *total* CPU!
While fixing this, factor out the common bits from the two places we're
parsing IWYU pragmas.
Differential Revision: https://reviews.llvm.org/D135314
(cherry picked from commit 5d2d527c32da2081b814ef8b446bc3e037f74b0a)
After 20d798bd47, SCEV looks through PHIs with a single incoming
value. This means adding a new incoming value may change the SCEV for a
phi. Add missing invalidation when an existing PHI is reused during
LoopVersioning. New incoming values will be added later from the
versioned loop.
Similar issues have been fixed by also adding missing invalidation.
Fixes#57825.
Note that the test case unfortunately requires running loop-vectorize
followed by loop-load-elimination, which does the actual versioning. I
don't think it is possible to reproduce the failure without that
combination.
(cherry picked from commit 623c4a7a55f716b96070a5c2f83fe0096cb38d38)
Add llvm_shlib_dir to variables used in clangd test suite, consistently
to how it is used in the test suites of clang, clang-tools-extra
and a few other components. This is necessary to ensure that
the correct shared libraries are used when building clang standalone --
otherwise, use_clang() sets LD_LIBRARY_PATH to the directory containing
the earlier system installation of clang rather than the just-built
library.
Differential Revision: https://reviews.llvm.org/D135062
(cherry picked from commit 77945a344c3dee3f9735744c8d4151ef2cec6a8d)
