The clang-analyzer plugins are not linked to a particular tool, so they
can only be compiled if plugins are broadly supported. We could opt
instead to decide whether to link them to specifically against clang or
with undefined symbols, depending on the value of LLVM_ENABLE_PLUGINS,
but we do not currently expect there to be a use case for that rather
niche configuration.
Differential Revision: https://reviews.llvm.org/D119591
This patch passes in the AMDPGU math libraries to the linker wrapper.
The wrapper already handles linking OpenMP bitcode libraries via the
`--target-library` option. This should be sufficient to link in math
libraries for the accompanying architecture.
Fixes#53526.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D119841
This patch adds a new Darwin clang driver environment variable in the
spirit of RC_DEBUG_OPTIONS, called RC_DEBUG_PREFIX_MAP, which allows a
meta build tool to add one additional -fdebug-prefix-map entry without
the knowledge of the build system.
rdar://85224675
Differential Revision: https://reviews.llvm.org/D119850
The named and generic address space overloads for atomic_init added
by 50f8abb9f4 ("[OpenCL] Add OpenCL 3.0 atomics to
-fdeclare-opencl-builtins", 2022-02-11) were not guarded by the
corresponding extensions.
This relands 73e585e44d (and 0574b5fc65), with a fix for
the failing test (by using Optional<StringRef>s instead of
making StringRef::empty() mean absence of value).
Differential Revision: https://reviews.llvm.org/D118070
Address space casts in general may change the element type, but
don't allow it in the method working on Address, so we can
preserve the element type.
CreatePointerBitCastOrAddrSpaceCast() still needs to be addressed.
The Itanium mangler constructors use both NSDMI and explicit member
construction for default values. This is confusing.
*) Use NSDMIs wherever possible
*) Use forwarding ctor for the nesting case with an
llvm::raw_null_ostream (and explicitly set NullOut flag in that ctor).
*) Copy the ModuleSubstitutions. This is a bug with no effect in the
current mangling, but not in the newer mangling.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119550
This reverts commit 620d99b7ed.
Let's see if removing the two offending RUN lines makes this patch pass.
Not ideal to drop tests but, it's just a debugging feature, probably not
that important.
This patch tries to implement RVO for coroutine's return object got from
get_return_object.
From [dcl.fct.def.coroutine]/p7 we could know that the return value of
get_return_object is either a reference or a prvalue. So it makes sense
to do copy elision for the return value. The return object should be
constructed directly into the storage where they would otherwise be
copied/moved to.
Test Plan: folly, check-all
Reviewed By: junparser
Differential revision: https://reviews.llvm.org/D117087
We can now configure the space between requires and the following paren,
seperate for clauses and expressions.
Differential Revision: https://reviews.llvm.org/D113369
Detect requires expressions in more unusable contexts. This is far from
perfect, but currently we have no good metric to decide between a
requires expression and a trailing requires clause.
Differential Revision: https://reviews.llvm.org/D119138
constexpr var may be initialized with address of non-const variable.
In this case the initializer is not constant in device compilation.
This has been handled for const vars but not for constexpr vars.
This patch makes handling of const var and constexpr var
consistent.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D119615
Fixes: https://github.com/llvm/llvm-project/issues/53780
This patch adds support for linking CPU offloading applications in the
linker wrapper. We generate the necessary linking job using the host
linker's path and library arguments. This may not be true for more
complex offloading schemes, but this is sufficient for now.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D119613
The `__builtin_pdepd` and `__builtin_pextd` are P10 builtins that are meant to
be used under 64-bit only. For instance, when the builtins are compiled under
32-bit mode:
```
$ cat t.c
unsigned long long foo(unsigned long long a, unsigned long long b) {
return __builtin_pextd(a,b);
}
$ clang -c t.c -mcpu=pwr10 -m32
ExpandIntegerResult #0: t31: i64 = llvm.ppc.pextd TargetConstant:i32<6928>, t28, t29
fatal error: error in backend: Do not know how to expand the result of this operator!
```
This patch adds sema checking for these builtins to compile under 64-bit
mode only and on P10. The builtins will emit a diagnostic when they are compiled on
non-P10 compilations and on 32-bit mode.
Differential Revision: https://reviews.llvm.org/D118753
Previously, Transformer would invoke the consumer once per file modified per
match, in addition to any errors encountered. The consumer is not aware of which
AtomicChanges come from any particular match. It is unclear which sets of edits
may be related or whether an error invalidates any previously emitted changes.
Modify the signature of the consumer to accept a set of changes. This keeps
related changes (i.e. all edits from a single match) together, and clarifies
that errors don't produce partial changes.
Reviewed By: ymandel
Differential Revision: https://reviews.llvm.org/D119745
The Itanium mangler uses IgnoreLinkageSpecDecls to strip linkage spec
contexts. It doesn't do this consistently, but there is no need for
it to do it at all. getEffectiveDeclContext never returns a linkage
spec, as it either recurses, uses getRedeclContext (which itself
removes the specs), or gets the decl context of non-namespace entities.
This patch removes the function and all calls to it. For safety I add
a couple of asserts to make sure we never get them.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119748
Commit 3c7d2f1b67 ("[OpenCL] opencl-c.h: add CL 3.0 non-generic
address space atomics", 2021-07-30) added some atomic_fetch_add/sub
overloads with uintptr_t arguments twice. Instead, they should have
been atomic_fetch_max overloads with non-generic address spaces.
This patch replaces a lot of index-based loops with iterators and ranges.
Depends on D117566.
Reviewed By: ahoppen
Differential Revision: https://reviews.llvm.org/D119722
This patch starts using the new iterator type in `LookupFileCacheInfo`.
Depends on D117566.
Reviewed By: ahoppen
Differential Revision: https://reviews.llvm.org/D119721
The `const DirectoryLookup *` out-parameter of `{HeaderSearch,Preprocessor}::LookupFile()` is assigned the most recently used search directory, which callers use to implement `#include_next`.
From the function signature it's not obvious the `const DirectoryLookup *` is being used as an iterator. This patch introduces `ConstSearchDirIterator` to make that affordance obvious. This would've prevented a bug that occurred after initially landing D116750.
Reviewed By: ahoppen
Differential Revision: https://reviews.llvm.org/D117566
This patch addresses a FIXME and de-duplicates some `#include_next` logic
Depends on D119714.
Reviewed By: ahoppen
Differential Revision: https://reviews.llvm.org/D119716
While scanning dependencies of a TU that depends on a PCH, the scanner basically performs mixed implicit/explicit modular compilation. (Explicit modules come from the PCH.) This seems to trip up the global module index.
This patch disables global module index in the dependency scanner.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D118890
The minimizer strips out single-line comments (introduced by `//`). This sequence of characters can also appear in `#include` or `#import` directives where they play the role of path separators. We already avoid stripping this character sequence for `#include` but not for `#import` (which has the same semantics). This patch makes it so `#import <A//A.h>` is not affected by minimization. Previously, we would incorrectly reduce it into `#import <A`.
Reviewed By: arphaman
Differential Revision: https://reviews.llvm.org/D119226
The minimizer tries to squash multi-line macro definitions into single line. For that to work, contents of each line need to be separated by a space. Since we always strip leading whitespace on lines of a macro definition, the code currently tries to preserve exactly one space that appeared before the backslash.
This means the following code:
```
#define FOO(BAR) \
#BAR \
baz
```
gets minimized into:
```
#define FOO(BAR) #BAR baz
```
However, if there are no spaces before the backslash on line 2:
```
#define FOO(BAR) \
#BAR\
baz
```
no space can be preserved, leading to (most likely) malformed macro definition:
```
#define FOO(BAR) #BARbaz
```
This patch makes sure we always put exactly one space at the end of line ending with a backslash.
Reviewed By: arphaman
Differential Revision: https://reviews.llvm.org/D119231
`Preprocessor` exposes the search directory iterator via `GetCurDirLookup()` getter, which is only used in two static functions.
To simplify reasoning about search directory iterators/references and to simplify the `Preprocessor` API, this patch makes the two static functions private member functions and removes the getter entirely.
Depends D119708.
Reviewed By: ahoppen, dexonsmith
Differential Revision: https://reviews.llvm.org/D119714
The purpose of the `FileNotFound` preprocessor callback was to add the ability to recover from failed header lookups. This was to support downstream project.
However, injecting additional search path while performing header search can invalidate currently used iterators/references to `DirectoryLookup` in `Preprocessor` and `HeaderSearch`.
The downstream project ended up maintaining a separate patch to further tweak the functionality. Since we don't have any upstream users nor open source downstream users, I'd like to remove this callback for good to prevent future misuse. I doubt there are any actual downstream users, since the functionality is definitely broken at the moment.
Reviewed By: ahoppen
Differential Revision: https://reviews.llvm.org/D119708
For redeclaration chains we maintain an invariant of having only a
single definition in the chain. In a single translation unit we make
sure not to create duplicates. But modules are separate translation
units and they can contain definitions for the same symbol
independently. When we load such modules together, we need to demote
duplicate definitions to keep the AST invariants.
Some AST clients are interested in distinguishing
declaration-that-was-demoted-from-definition and
declaration-that-was-never-a-definition. For that purpose introducing
`IsThisDeclarationADemotedDefinition`. No functional change intended.
rdar://84677782
Differential Revision: https://reviews.llvm.org/D118855
This patch extends clang driver to pass the right flags to the clang frontend, and ld64,
so that they can emit macho files with two build version load commands. It adds a new
0darwin-target-variant option which complements -target and also can be used to specify different
target variants when multi-arch compilations are invoked with multiple -arch commands.
Differential Revision: https://reviews.llvm.org/D118862
Post-commit review feedback suggested dropping the deprecated
diagnostic for the 'noreturn' macro (the diagnostic from the header
file suffices and the macro diagnostic could be confusing) and to only
issue the deprecated diagnostic for [[_Noreturn]] when the attribute
identifier is either directly written or not from a system macro.
Amends the commit made in 5029dce492.
Recently we observed high memory pressure caused by clang during some parallel builds.
We discovered that we have several projects that have a large number of #define directives
in their TUs (on the order of millions), which caused huge memory consumption in clang due
to a lot of allocations for MacroInfo. We would like to reduce the memory overhead of
clang for a single #define to reduce the memory overhead for these files, to allow us to
reduce the memory pressure on the system during highly parallel builds. This change achieves
that by removing the SmallVector in MacroInfo and instead storing the tokens in an array
allocated using the bump pointer allocator, after all tokens are lexed.
The added unit test with 1000000 #define directives illustrates the problem. Prior to this
change, on arm64 macOS, clang's PP bump pointer allocator allocated 272007616 bytes, and
used roughly 272 bytes per #define. After this change, clang's PP bump pointer allocator
allocates 120002016 bytes, and uses only roughly 120 bytes per #define.
For an example test file that we have internally with 7.8 million #define directives, this
change produces the following improvement on arm64 macOS: Persistent allocation footprint for
this test case file as it's being compiled to LLVM IR went down 22% from 5.28 GB to 4.07 GB
and the total allocations went down 14% from 8.26 GB to 7.05 GB. Furthermore, this change
reduced the total number of allocations made by the system for this clang invocation from
1454853 to 133663, an order of magnitude improvement.
The recommit fixes the LLDB build failure.
Differential Revision: https://reviews.llvm.org/D117348
when the function declaration's return type is already invalid for
some reason. This is relevant to https://github.com/llvm/llvm-project/issues/49188
because another way that the declaration's return type could become
invalid is that it might be `C auto` where `C<void>` is false.
Differential Revision: https://reviews.llvm.org/D119094
There was a typo in the rule.
`{{0}, ReturnValueIndex}` meant that the discrete index is `0` and the
variadic index is `-1`.
What we wanted instead is that both `0` and `-1` are in the discrete index
list.
Instead of this, we wanted to express that both `0` and the
`ReturnValueIndex` is in the discrete arg list.
The manual inspection revealed that `setproctitle_init` also suffered a
probably incomplete propagation rule.
Reviewed By: Szelethus, gamesh411
Differential Revision: https://reviews.llvm.org/D119129
Jameson Nash