Otherwise we get invalid results for ODR checks. See changed test for an
example: despite the fact that we merge the first concept, its **uses**
were considered different by `Profile`, leading to redefinition errors.
After this change, canonical decl for a concept can come from a
different module and may not be visible. This behavior looks suspicious,
but does not break any tests. We might want to add a mechanism to make
the canonical concept declaration visible if we find code that relies on
this invariant.
Additionally make sure we always merge with the canonical declaration to
avoid chains of merged concepts being reported as redefinitions. An
example was added to the test.
Also change the order of includes in the test. Importing a moduralized
header before its textual part causes the include guard macro to be
exported and the corresponding `#include` becomes a no-op.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D130585
Without this patch, clang will not wrap in an ElaboratedType node types written
without a keyword and nested name qualifier, which goes against the intent that
we should produce an AST which retains enough details to recover how things are
written.
The lack of this sugar is incompatible with the intent of the type printer
default policy, which is to print types as written, but to fall back and print
them fully qualified when they are desugared.
An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still
requires pointer alignment due to pre-existing bug in the TypeLoc buffer
handling.
---
Troubleshooting list to deal with any breakage seen with this patch:
1) The most likely effect one would see by this patch is a change in how
a type is printed. The type printer will, by design and default,
print types as written. There are customization options there, but
not that many, and they mainly apply to how to print a type that we
somehow failed to track how it was written. This patch fixes a
problem where we failed to distinguish between a type
that was written without any elaborated-type qualifiers,
such as a 'struct'/'class' tags and name spacifiers such as 'std::',
and one that has been stripped of any 'metadata' that identifies such,
the so called canonical types.
Example:
```
namespace foo {
struct A {};
A a;
};
```
If one were to print the type of `foo::a`, prior to this patch, this
would result in `foo::A`. This is how the type printer would have,
by default, printed the canonical type of A as well.
As soon as you add any name qualifiers to A, the type printer would
suddenly start accurately printing the type as written. This patch
will make it print it accurately even when written without
qualifiers, so we will just print `A` for the initial example, as
the user did not really write that `foo::` namespace qualifier.
2) This patch could expose a bug in some AST matcher. Matching types
is harder to get right when there is sugar involved. For example,
if you want to match a type against being a pointer to some type A,
then you have to account for getting a type that is sugar for a
pointer to A, or being a pointer to sugar to A, or both! Usually
you would get the second part wrong, and this would work for a
very simple test where you don't use any name qualifiers, but
you would discover is broken when you do. The usual fix is to
either use the matcher which strips sugar, which is annoying
to use as for example if you match an N level pointer, you have
to put N+1 such matchers in there, beginning to end and between
all those levels. But in a lot of cases, if the property you want
to match is present in the canonical type, it's easier and faster
to just match on that... This goes with what is said in 1), if
you want to match against the name of a type, and you want
the name string to be something stable, perhaps matching on
the name of the canonical type is the better choice.
3) This patch could expose a bug in how you get the source range of some
TypeLoc. For some reason, a lot of code is using getLocalSourceRange(),
which only looks at the given TypeLoc node. This patch introduces a new,
and more common TypeLoc node which contains no source locations on itself.
This is not an inovation here, and some other, more rare TypeLoc nodes could
also have this property, but if you use getLocalSourceRange on them, it's not
going to return any valid locations, because it doesn't have any. The right fix
here is to always use getSourceRange() or getBeginLoc/getEndLoc which will dive
into the inner TypeLoc to get the source range if it doesn't find it on the
top level one. You can use getLocalSourceRange if you are really into
micro-optimizations and you have some outside knowledge that the TypeLocs you are
dealing with will always include some source location.
4) Exposed a bug somewhere in the use of the normal clang type class API, where you
have some type, you want to see if that type is some particular kind, you try a
`dyn_cast` such as `dyn_cast<TypedefType>` and that fails because now you have an
ElaboratedType which has a TypeDefType inside of it, which is what you wanted to match.
Again, like 2), this would usually have been tested poorly with some simple tests with
no qualifications, and would have been broken had there been any other kind of type sugar,
be it an ElaboratedType or a TemplateSpecializationType or a SubstTemplateParmType.
The usual fix here is to use `getAs` instead of `dyn_cast`, which will look deeper
into the type. Or use `getAsAdjusted` when dealing with TypeLocs.
For some reason the API is inconsistent there and on TypeLocs getAs behaves like a dyn_cast.
5) It could be a bug in this patch perhaps.
Let me know if you need any help!
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D112374
We are supporting quadword lock free atomics on AIX. For the situation that users on AIX are using a libatomic that is lock-based for quadword types, we can't enable quadword lock free atomics by default on AIX in case user's new code and existing code accessing the same shared atomic quadword variable, we can't guarentee atomicity. So we need an option to enable quadword lock free atomics on AIX, thus we can build a quadword lock-free libatomic(also for advanced users considering atomic performance critical) for users to make the transition smooth.
Reviewed By: shchenz
Differential Revision: https://reviews.llvm.org/D127189
Add the support for `atomic compare` and `atomic compare capture` in the
release note of clang.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D129211
Without the "found declaration" it is later not possible to know where the operator declaration
was brought into the scope calling it.
The initial motivation for this fix came from #55095. However, this also has an influence on
`clang -ast-dump` which now prints a `UsingShadow` attribute for operators only visible through
`using` statements. Also, clangd now correctly references the `using` statement instead of the
operator directly.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D129973
This patch adds initial support for context-sensitive analysis of simple functions whose definition is available in the translation unit, guarded by the `ContextSensitive` flag in the new `TransferOptions` struct. When this option is true, the `VisitCallExpr` case in the builtin transfer function has a fallthrough case which checks for a direct callee with a body. In that case, it constructs a CFG from that callee body, uses the new `pushCall` method on the `Environment` to make an environment to analyze the callee, and then calls `runDataflowAnalysis` with a `NoopAnalysis` (disabling context-sensitive analysis on that sub-analysis, to avoid problems with recursion). After the sub-analysis completes, the `Environment` from its exit block is simply assigned back to the environment at the callsite.
The `pushCall` method (which currently only supports non-method functions with some restrictions) maps the `SourceLocation`s for all the parameters to the existing source locations for the corresponding arguments from the callsite.
This patch adds a few tests to check that this context-sensitive analysis works on simple functions. More sophisticated functionality will be added later; the most important next step is to explicitly model context in some fields of the `DataflowAnalysisContext` class, as mentioned in a `FIXME` comment in the `pushCall` implementation.
Reviewed By: ymandel, xazax.hun
Differential Revision: https://reviews.llvm.org/D130306
Depends On D130305
This patch adds initial support for context-sensitive analysis of simple functions whose definition is available in the translation unit, guarded by the `ContextSensitive` flag in the new `TransferOptions` struct. When this option is true, the `VisitCallExpr` case in the builtin transfer function has a fallthrough case which checks for a direct callee with a body. In that case, it constructs a CFG from that callee body, uses the new `pushCall` method on the `Environment` to make an environment to analyze the callee, and then calls `runDataflowAnalysis` with a `NoopAnalysis` (disabling context-sensitive analysis on that sub-analysis, to avoid problems with recursion). After the sub-analysis completes, the `Environment` from its exit block is simply assigned back to the environment at the callsite.
The `pushCall` method (which currently only supports non-method functions with some restrictions) first calls `initGlobalVars`, then maps the `SourceLocation`s for all the parameters to the existing source locations for the corresponding arguments from the callsite.
This patch adds a few tests to check that this context-sensitive analysis works on simple functions. More sophisticated functionality will be added later; the most important next step is to explicitly model context in some fields of the `DataflowAnalysisContext` class, as mentioned in a `TODO` comment in the `pushCall` implementation.
Reviewed By: ymandel, xazax.hun
Differential Revision: https://reviews.llvm.org/D130306
Lifting the core functionalities of the clang-offload-bundler into a
user-facing library/API. This will allow online and JIT compilers to
bundle and unbundle files without spawning a new process.
This patch lifts the classes and functions used to implement
the clang-offload-bundler into a separate OffloadBundler.cpp,
and defines three top-level API functions in OfflaodBundler.h.
BundleFiles()
UnbundleFiles()
UnbundleArchives()
This patch also introduces a Config class that locally stores the
previously global cl::opt options and arrays to allow users to call
the APIs in a multi-threaded context, and introduces an
OffloadBundler class to encapsulate the top-level API functions.
We also lift the BundlerExecutable variable, which is specific
to the clang-offload-bundler tool, from the API, and replace
its use with an ObjcopyPath variable. This variable must be set
in order to internally call llvm-objcopy.
Finally, we move the API files from
clang/tools/clang-offload-bundler into clang/lib/Driver and
clang/include/clang/Driver.
Differential Revision: https://reviews.llvm.org/D129873
These module flags use the Min merge behavior with a default value of
zero, so we don't need to emit them if zero.
Reviewed By: danielkiss
Differential Revision: https://reviews.llvm.org/D130145
Currently, the use of preferred_name would block implementing std
modules in libcxx. See https://github.com/llvm/llvm-project/issues/56490
for example.
The problem is pretty hard and it looks like we couldn't solve it in a
short time. So we sent this patch as a workaround to avoid blocking us
to modularize STL. This is intended to be fixed properly in the future.
Reviewed By: erichkeane, aaron.ballman, tahonermann
Differential Revision: https://reviews.llvm.org/D130331
WinEHPrepare marks any function call from EH funclets as unreachable, if it's not a nounwind intrinsic or has no proper funclet bundle operand. This
affects ARC intrinsics on Windows, because they are lowered to regular function calls in the PreISelIntrinsicLowering pass. It caused silent binary truncations and crashes during unwinding with the GNUstep ObjC runtime: https://github.com/gnustep/libobjc2/issues/222
This patch adds a new function `llvm::IntrinsicInst::mayLowerToFunctionCall()` that aims to collect all affected intrinsic IDs.
* Clang CodeGen uses it to determine whether or not it must emit a funclet bundle operand.
* PreISelIntrinsicLowering asserts that the function returns true for all ObjC runtime calls it lowers.
* LLVM uses it to determine whether or not a funclet bundle operand must be propagated to inlined call sites.
Reviewed By: theraven
Differential Revision: https://reviews.llvm.org/D128190
Turning on opaque pointers has uncovered an issue with WPD where we currently pattern match away `assume(type.test)` in WPD so that a later LTT doesn't resolve the type test to undef and introduce an `assume(false)`. The pattern matching can fail in cases where we transform two `assume(type.test)`s into `assume(phi(type.test.1, type.test.2))`.
Currently we create `assume(type.test)` for all virtual calls that might be devirtualized. This is to support `-Wl,--lto-whole-program-visibility`.
To prevent this, all virtual calls that may not be in the same LTO module instead use a new `llvm.public.type.test` intrinsic in place of the `llvm.type.test`. Then when we know if `-Wl,--lto-whole-program-visibility` is passed or not, we can either replace all `llvm.public.type.test` with `llvm.type.test`, or replace all `llvm.public.type.test` with `true`. This prevents WPD from trying to pattern match away `assume(type.test)` for public virtual calls when failing the pattern matching will result in miscompiles.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D128955
The original implementation uses `ND->getFormalLinkage() <=
Linkage::InternalLinkage`. It is not right since the spec only says
internal linkage and it doesn't mention 'no linkage'. This matters when
we consider constructors. According to [class.ctor.general]p1,
constructors have no name so constructors have no linkage too.
Previously we used to desugar implications and biconditionals into
equivalent CNF/DNF as soon as possible. However, this desugaring makes
debug output (Environment::dump()) less readable than it could be.
Therefore, it makes sense to keep the sugared representation of a
boolean formula, and desugar it in the solver.
Reviewed By: sgatev, xazax.hun, wyt
Differential Revision: https://reviews.llvm.org/D130519
Without this patch when using CMAKE_CXX_STANDARD=20 Microsoft compiler produces following warnings
clang\include\clang/Basic/DiagnosticIDs.h(48): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(49): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(50): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(51): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(52): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(53): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(54): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(55): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(56): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(57): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(58): warning C5054: operator '+': deprecated between enumerations of different types
clang\include\clang/Basic/DiagnosticIDs.h(59): warning C5054: operator '+': deprecated between enumerations of different types
Patch By: Godin
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D130476
Before the patch we calculated the NRVO candidate looking at the
variable's whole enclosing scope. The research in [P2025] shows that
looking at the variable's potential scope is better and covers more
cases where NRVO would be safe and desirable.
Many thanks to @Izaron for the original implementation.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D119792
Since clang15 is going to be branched in July 26, and C++ modules still
lack an update on ReleaseNotes. Although it is not complete yet, I think
it would be better to add one since we've done many works for C++20
Modules in clang15.
Differential Revision: https://reviews.llvm.org/D129138
Currently, the semantics of linkage in clang is slightly
different from the semantics in C++ spec. In C++ spec, only names
have linkage. So that all entities of the same should share
one linkage. But in clang, different entities of the same could
have different linkage.
It would break a use case where the template have external linkage and
its specialization have internal linkage due to its type argument is
internal linkage. The root cause is that the semantics of internal
linkage in clang is a mixed form of internal linkage and TU-local in
C++ spec. It is hard to solve the root problem and I tried to add a
workaround inplace.
Remove MaskedPrototype and add several fields in RVVIntrinsicRecord,
compute Prototype in runtime.
Reviewed By: rogfer01
Differential Revision: https://reviews.llvm.org/D126741
BooleanFormula::addClause has an invariant that a clause has no duplicated
literals. When the solver was desugaring a formula into CNF clauses, it
could construct a clause with such duplicated literals in two cases.
Reviewed By: sgatev, ymandel, xazax.hun
Differential Revision: https://reviews.llvm.org/D130522
Leverage the method OpenCL uses that adds C intrinsics when the lookup
failed. There is no need to define C intrinsics in the header file any
more. It could help to avoid the large header file to speed up the
compilation of RVV source code. Besides that, only the C intrinsics used
by the users will be added into the declaration table.
This patch is based on https://reviews.llvm.org/D103228 and inspired by
OpenCL implementation.
### Experimental Results
#### TL;DR:
- Binary size of clang increase ~200k, which is +0.07% for debug build and +0.13% for release build.
- Single file compilation speed up ~33x for debug build and ~8.5x for release build
- Regression time reduce ~10% (`ninja check-all`, enable all targets)
#### Header size change
```
| size | LoC |
------------------------------
Before | 4,434,725 | 69,749 |
After | 6,140 | 162 |
```
#### Single File Compilation Time
Testcase:
```
#include <riscv_vector.h>
vint32m1_t test_vadd_vv_vfloat32m1_t(vint32m1_t op1, vint32m1_t op2, size_t vl) {
return vadd(op1, op2, vl);
}
```
##### Debug build:
Before:
```
real 0m19.352s
user 0m19.252s
sys 0m0.092s
```
After:
```
real 0m0.576s
user 0m0.552s
sys 0m0.024s
```
~33x speed up for debug build
##### Release build:
Before:
```
real 0m0.773s
user 0m0.741s
sys 0m0.032s
```
After:
```
real 0m0.092s
user 0m0.080s
sys 0m0.012s
```
~8.5x speed up for release build
#### Regression time
Note: the failed case is `tools/llvm-debuginfod-find/debuginfod.test` which is unrelated to this patch.
##### Debug build
Before:
```
Testing Time: 1358.38s
Skipped : 11
Unsupported : 446
Passed : 75767
Expectedly Failed: 190
Failed : 1
```
After
```
Testing Time: 1220.29s
Skipped : 11
Unsupported : 446
Passed : 75767
Expectedly Failed: 190
Failed : 1
```
##### Release build
Before:
```
Testing Time: 381.98s
Skipped : 12
Unsupported : 1407
Passed : 74765
Expectedly Failed: 176
Failed : 1
```
After:
```
Testing Time: 346.25s
Skipped : 12
Unsupported : 1407
Passed : 74765
Expectedly Failed: 176
Failed : 1
```
#### Binary size of clang
##### Debug build
Before
```
text data bss dec hex filename
335261851 12726004 552812 348540667 14c64efb bin/clang
```
After
```
text data bss dec hex filename
335442803 12798708 552940 348794451 14ca2e53 bin/clang
```
+253K, +0.07% code size
##### Release build
Before
```
text data bss dec hex filename
144123975 8374648 483140 152981763 91e5103 bin/clang
```
After
```
text data bss dec hex filename
144255762 8447296 483268 153186326 9217016 bin/clang
```
+204K, +0.13%
Authored-by: Kito Cheng <kito.cheng@sifive.com>
Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com>
Reviewed By: khchen, aaron.ballman
Differential Revision: https://reviews.llvm.org/D111617
This patch introduces a new `ConstructionContext` for
lambda capture. This `ConstructionContext` allows the
analyzer to construct the captured object directly into
it's final region, and makes it possible to capture
non-POD arrays.
Differential Revision: https://reviews.llvm.org/D129967
This patch introduces the evaluation of ArrayInitLoopExpr
in case of structured bindings and implicit copy/move
constructor. The idea is to call the copy constructor for
every element in the array. The parameter of the copy
constructor is also manually selected, as it is not a part
of the CFG.
Differential Revision: https://reviews.llvm.org/D129496
This partially reverts c7b3a91017. Having
libclang.so with a different SONAME than the other LLVM libraries was
causing a lot of confusion for users. Also, this change did not really
acheive it's purpose of allowing apps to use newer versions of
libclang.so without rebuilding, because a new version of libclang.so
requires a new version of libLLVM.so, which does not have a stable ABI.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D129160
Also move MangleCtx when moving some lazy emission states in
CodeGenModule. Without this patch clang-repl hits an invalid address
access when passing `-Xcc -O2` flag.
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D130420
Currently in Sema::ActOnEnumBody(...) when calculating NumPositiveBits we miss
the case where there is only a single enumerator with value zero and the case of
an empty enum. In both cases we end up with zero positive bits when in fact we
need one bit to store the value zero.
This PR updates the calculation to account for these cases.
Differential Revision: https://reviews.llvm.org/D130301
This compensates for 8f0c901c1a which enabled
-Wunused-command-line-argument for unimplemented -mtune= in the generic code.
Ignoring -mtune= appears to be longstanding and the error-free behavior in the
presence of -Werror is unfortunately relied on by the Linux kernel's arm and
powerpc ports. Ignore the warnings for the upcoming 15.0.0 branch and will
implement functionality to fill the test gap soon.
Link: https://github.com/ClangBuiltLinux/linux/issues/1674
Firstly, we we make an additional GNUInstallDirs-style variable. With
NixOS, for example, this is crucial as we want those to go in
`${dev}/lib/cmake` not `${out}/lib/cmake` as that would a cmake subdir
of the "regular" libdir, which is installed even when no one needs to do
any development.
Secondly, we make *Config.cmake robust to absolute package install
paths. We for NixOS will in fact be passing them absolute paths to make
the `${dev}` vs `${out}` distinction mentioned above, and the
GNUInstallDirs-style variables are suposed to support absolute paths in
general so it's good practice besides the NixOS use-case.
Thirdly, we make `${project}_INSTALL_PACKAGE_DIR` CACHE PATHs like other
install dirs are.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D117973
We call tail-call-elim near the beginning of the pipeline,
but that is too early to annotate calls that get added later.
In the motivating case from issue #47852, the missing 'tail'
on memset leads to sub-optimal codegen.
I experimented with removing the early instance of
tail-call-elim instead of just adding another pass, but that
appears to be slightly worse for compile-time:
+0.15% vs. +0.08% time.
"tailcall" shows adding the pass; "tailcall2" shows moving
the pass to later, then adding the original early pass back
(so 1596886802 is functionally equivalent to 180b0439dc ):
https://llvm-compile-time-tracker.com/index.php?config=NewPM-O3&stat=instructions&remote=rotateright
Note that there was an effort to split the tail call functionality
into 2 passes - that could help reduce compile-time if we find
that this change costs more in compile-time than expected based
on the preliminary testing:
D60031
Differential Revision: https://reviews.llvm.org/D130374
The latter way to abbreviate is a lot more common in the LLVM codebase.
Reviewed By: sgatev, xazax.hun
Differential Revision: https://reviews.llvm.org/D130423
Fix `MapLattice` API to return `std::pair<iterator, bool>`,
allowing users to detect when an element has been inserted without
performing a redundant map lookup.
Differential Revision: https://reviews.llvm.org/D130497
and use fallback only for C.
It fixes the isssue with clang-cl:
```
#include <stdatomic.h>
#include <stdbool.h>
#ifdef __cplusplus
#include <atomic>
using namespace std;
#endif
int main() {
atomic_bool b = true;
}
```
```
$ clang-cl /TC main.cpp
# works
```
```
$ clang-cl /TP /std:c++20 main.cpp
stdatomic.h(70,6): error: conflicting types for 'atomic_thread_fence'
void atomic_thread_fence(memory_order);
^
atomic(166,24): note: previous definition is here
extern "C" inline void atomic_thread_fence(const memory_order _Order) noexcept {
...
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
```
Many errors but
`<stdatomic.h>` has many macros to built-in functions.
```
#define atomic_thread_fence(order) __c11_atomic_thread_fence(order)
```
and MSVC `<atomic>` has real functions.
and the built-in functions are redefined.
Reviewed By: #libc, aaron.ballman, Mordante
Differential Revision: https://reviews.llvm.org/D130419
This includes the revised provisions of [basic.lookup.argdep] p4
1. ADL is amended to handle p 4.3 where functions in trasitively imported modules may
become visible when they are exported in the same namespace as a visible type.
2. If a function is in a different modular TU, and has internal-linkage, we invalidate
its entry in an overload set.
[basic.lookup.argdep] p5 ex 2 now passes.
Differential Revision: https://reviews.llvm.org/D129174
Currently the C++20 concepts are only merged in `ASTReader`, i.e. when
coming from different TU. This can causes ambiguious reference errors when
trying to access the same concept that should otherwise be merged.
Please see the added test for an example.
Note that we currently use `ASTContext::isSameEntity` to check for ODR
violations. However, it will not check that concept requirements match.
The same issue holds for mering concepts from different TUs, I added a
FIXME and filed a GH issue to track this:
https://github.com/llvm/llvm-project/issues/56310
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D128921
This patch rewords the static assert diagnostic output. Failing a
_Static_assert in C should not report that static_assert failed. This
changes the wording to be more like GCC and uses "static assertion"
when possible instead of hard coding the name. This also changes some
instances of 'static_assert' to instead be based on the token in the
source code.
Differential Revision: https://reviews.llvm.org/D129048
This test is currently marked as XFAIL for Windows, but running the
test with a debug build of clang-repl.exe crashes with a modal system
dialog. This switches the test to UNSUPPORTED instead. This makes the
test behavior less onerous for those of us doing Debug builds, at the
expense of a minor bit of coverage if the test were ever to start
passing unexpectedly on Windows (which seems like an unlikely event).
specialization
Previously in D120397, we've handled the linkage for function template
and its specialization. But we forgot to handle it for class templates
and their specialization. So we make it in the patch with the similar
approach.
Copying the folder keeps the original permissions by default. This
creates problems when the source folder is read-only, e.g. in a
packaging environment.
Then, the copied folder in the build directory is read-only as well.
Later on, other files are copied into that directory (in the build
tree), failing when the directory is read-only.
Fix that problem by copying the folder without keeping the original
permissions.
Follow-up to D130254.
Differential Revision: https://reviews.llvm.org/D130338
Avoid a crash if a function is imported that has auto return type that
references to a template with an expression-type of argument that
references into the function's body.
Fixes issue #56047
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D129640
Support for functions wmemcpy, wcslen, wcsnlen is added to the checker.
Documentation and tests are updated and extended with the new functions.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D130091
report an error when encountering 'while' token parsing declarator
```
clang/test/Parser/while-loop-outside-function.c:3:1: error: while loop outside of a function
while // expected-error {{while loop outside of a function}}
^
clang/test/Parser/while-loop-outside-function.c:7:1: error: while loop outside of a function
while // expected-error {{while loop outside of a function}}
^
```
Fixes: https://github.com/llvm/llvm-project/issues/34462
Differential Revision: https://reviews.llvm.org/D129573
They have been ported and tested to work on AArch64
(see D125883, D125758, and D125873).
Reviewed By: dim, MaskRay
Differential Revision: https://reviews.llvm.org/D130063
This patch connects the check for const-correctness with the new general
utility to add `const` to variables.
The code-transformation is only done, if the detected variable for const-ness
is not part of a group-declaration.
The check allows to control multiple facets of adding `const`, e.g. if pointers themself should be
marked as `const` if they are not changed.
Reviewed By: njames93
Differential Revision: https://reviews.llvm.org/D54943
As per P2327R1,
|=, &= and ^= are no longer deprecated in all languages mode.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D130421
5ab6ee7599 assumed that if `RValue::isScalar()` returns true then `RValue::getScalarVal` will return a valid value. This is not the case when the return value is `void` and so void message returns would crash if they hit this path. This is triggered only for cases where the nil-handling path needs to do something non-trivial (destroy arguments that should be consumed by the callee).
Reviewed By: triplef
Differential Revision: https://reviews.llvm.org/D123898
llvm::sort is beneficial even when we use the iterator-based overload,
since it can optionally shuffle the elements (to detect
non-determinism). However llvm::sort is not usable everywhere, for
example, in compiler-rt.
Reviewed By: nhaehnle
Differential Revision: https://reviews.llvm.org/D130406
The #warning directive is standard in C++2b and C2x,
this adjusts the pedantic and extensions warning accordingly.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D130415
This implements
N2836 Identifier Syntax using Unicode Standard Annex 31.
The feature was already implemented for C++,
and the semantics are the same.
Unlike C++ there was, afaict, no decision to
backport the feature in older languages mode,
so C17 and earlier are not modified and the
code point tables for these language modes are conserved.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D130416
-gsplit-dwarf produces a .dwo file which will not be processed by the linker. If
.dwo files contain relocations, they will not be resolved. Therefore the
practice is that .dwo files do not contain relocations.
Address ranges and location description need to use forms/entry kinds indexing
into .debug_addr (DW_FORM_addrx/DW_RLE_startx_endx/etc), which is currently not
implemented.
There is a difficult-to-read MC error with -gsplit-dwarf with RISC-V for both -mrelax and -mno-relax.
```
% clang --target=riscv64-linux-gnu -g -gsplit-dwarf -c a.c
error: A dwo section may not contain relocations
```
We expect to fix -mno-relax soon, so report a driver error for -mrelax for now.
Link: https://github.com/llvm/llvm-project/issues/56642
Reviewed By: compnerd, kito-cheng
Differential Revision: https://reviews.llvm.org/D130190
Fixes modular build for clangPseudoGrammar from clang-tools-extra.
Starting from https://reviews.llvm.org/D126731 clangPseudoGrammar
doesn't depend on generated .inc headers but still depends on
"Basic/TokenKinds.h". It means clangPseudoGrammar depends on module
'Clang_Basic' which does depend on generated .inc headers. To avoid
these coarse dependencies and extra build steps, extract
"clang/Basic/TokenKinds.h" into a top-level module 'Clang_Basic_TokenKinds'.
rdar://97387951
Differential Revision: https://reviews.llvm.org/D130377
This commit adds a fuzzer for LLDB's expression evaluator.
The fuzzer takes a different approach than the current fuzzers
present, and uses an approach that is currently being used for
clang fuzzers.
Instead of fuzzing the evaluator with randomly mutated
characters, protobufs are used to generate a subset of C++. This
is then converted to valid C++ code and sent to the expression
evaluator. In addition, libprotobuf_mutator is used to mutate
the fuzzer's inputs from valid C++ code to valid C++ code, rather
than mutating from valid code to total nonsense.
Differential revision: https://reviews.llvm.org/D129377
Split up from the deferred concepts implementation, this function is
useful for determining the containing function of a different function.
However, in some cases it is valuable to instead get the lexical parent.
This adds a parameter to the existing function to allow a 'Lexical'
parameter to instead select the lexical parent.
In cases where a non-template function is defined inside a function
template, we don't have information about the original uninstantiated
version. In the case of concepts instantiation, we will need the
ability to get back to the original template. This patch splits a piece
of the deferred concepts instantaition patch off to accomplish the
storage of this, with minor runtime overhead, and zero additional
storage.
Clang has traditionally allowed C programs to implicitly convert
integers to pointers and pointers to integers, despite it not being
valid to do so except under special circumstances (like converting the
integer 0, which is the null pointer constant, to a pointer). In C89,
this would result in undefined behavior per 3.3.4, and in C99 this rule
was strengthened to be a constraint violation instead. Constraint
violations are most often handled as an error.
This patch changes the warning to default to an error in all C modes
(it is already an error in C++). This gives us better security posture
by calling out potential programmer mistakes in code but still allows
users who need this behavior to use -Wno-error=int-conversion to retain
the warning behavior, or -Wno-int-conversion to silence the diagnostic
entirely.
Differential Revision: https://reviews.llvm.org/D129881
This patch aims to create a webpage to document
Flang's command line options on https://flang.llvm.org/docs/
in a similar way to Clang's
https://clang.llvm.org/docs/ClangCommandLineReference.html
This is done by using clang_tablegen to generate an .rst
file from Options.td (which is current shared with Clang)
For this to work, ClangOptionDocEmitter.cpp was updated
to allow specific Flang flags to be included,
rather than bulk excluding clang flags.
Note:
Some headings in the generated documentation will incorrectly
contain references to Clang, e.g.
"Flags controlling the behaviour of Clang during compilation"
This is because Options.td (Which is shared between both Clang and Flang)
contains hard-coded DocBrief sections. I couldn't find a non-intrusive way
to make this target-dependant, as such I've left this as is, and it will need revisiting later.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D129864
Depends On D130304
This patch pulls the `ApplyBuiltinTransfer` from the `TypeErasedDataflowAnalysis` class into a new `DataflowAnalysisOptions` struct, to allow us to add additional options later without breaking existing code.
Reviewed By: gribozavr2, sgatev
Differential Revision: https://reviews.llvm.org/D130305
This patch moves `Analysis/FlowSensitive/NoopAnalysis.h` from `clang/unittests/` to `clang/include/clang/`, so that we can use it for doing context-sensitive analysis.
Reviewed By: ymandel, gribozavr2, sgatev
Differential Revision: https://reviews.llvm.org/D130304
Copying the folder keeps the original permissions by default. This
creates problems when the source folder is read-only, e.g. in a
packaging environment.
Then, the copied folder in the build directory is read-only as well.
Later on, with configure_file, ClangConfig.cmake is copied into that
directory (in the build tree), failing when the directory is read-only.
Fix that problem by copying the folder without keeping the original
permissions.
Differential Revision: https://reviews.llvm.org/D130254
The re-land fixes module map module dependencies seen on Greendragon, but
not in the clang test suite.
---
Currently we only implement this for the Itanium ABI since the correct
mangling for the initializers in other ABIs is not yet known.
Intended result:
For a module interface [which includes partition interface and implementation
units] (instead of the generic CXX initializer) we emit a module init that:
- wraps the contained initializations in a control variable to ensure that
the inits only happen once, even if a module is imported many times by
imports of the main unit.
- calls module initializers for imported modules first. Note that the
order of module import is not significant, and therefore neither is the
order of imported module initializers.
- We then call initializers for the Global Module Fragment (if present)
- We then call initializers for the current module.
- We then call initializers for the Private Module Fragment (if present)
For a module implementation unit, or a non-module TU that imports at least one
module we emit a regular CXX init that:
- Calls the initializers for any imported modules first.
- Then proceeds as normal with remaining inits.
For all module unit kinds we include a global constructor entry, this allows
for the (in most cases unusual) possibility that a module object could be
included in a final binary without a specific call to its initializer.
Implementation:
- We provide the module pointer in the AST Context so that CodeGen can act
on it and its sub-modules.
- We need to account for module build lines like this:
` clang -cc1 -std=c++20 Foo.pcm -emit-obj -o Foo.o` or
` clang -cc1 -std=c++20 -xc++-module Foo.cpp -emit-obj -o Foo.o`
- in order to do this, we add to ParseAST to set the module pointer in
the ASTContext, once we establish that this is a module build and we
know the module pointer. To be able to do this, we make the query for
current module public in Sema.
- In CodeGen, we determine if the current build requires a CXX20-style module
init and, if so, we defer any module initializers during the "Eagerly
Emitted" phase.
- We then walk the module initializers at the end of the TU but before
emitting deferred inits (which adds any hidden and static ones, fixing
https://github.com/llvm/llvm-project/issues/51873 ).
- We then proceed to emit the deferred inits and continue to emit the CXX
init function.
Differential Revision: https://reviews.llvm.org/D126189
Diagnostic for `-Wauto-import` shouldn't be a warning because it doesn't
represent a potential problem in code that should be fixed. And the
emitted fix-it is likely to trigger `-Watimport-in-framework-header`
which makes it challenging to have a warning-free codebase. But it is
still useful to see how include directives are translated into modular
imports and which module a header belongs to, that's why keep it as a remark.
Keep `-Wauto-import` for now to allow a gradual migration for codebases
using `-Wno-auto-import`, e.g., `-Weverything -Wno-auto-import`.
rdar://79594287
Differential Revision: https://reviews.llvm.org/D130138
Correct the logic used to set `ATOMIC_*_LOCK_FREE` preprocessor macros not
to rely on the ABI alignment of types. Instead, just assume all those
types are aligned correctly by default since clang uses safe alignment
for `_Atomic` types even if the underlying types are aligned to a lower
boundary by default.
For example, the `long long` and `double` types on x86 are aligned to
32-bit boundary by default. However, `_Atomic long long` and `_Atomic
double` are aligned to 64-bit boundary, therefore satisfying
the requirements of lock-free atomic operations.
This fixes PR #19355 by correcting the value of
`__GCC_ATOMIC_LLONG_LOCK_FREE` on x86, and therefore also fixing
the assumption made in libc++ tests. This also fixes PR #30581 by
applying a consistent logic between the functions used to implement
both interfaces.
Reviewed By: hfinkel, efriedma
Differential Revision: https://reviews.llvm.org/D28213
The default host CPU for an i386 triple is typically at least an i586,
which has cmpxchg8b (Clang feature, "cx8"). Therefore,
`__CLANG_ATOMIC_LLONG_LOCK_FREE` is 2 on the host, but the value should
be 1 for the device.
Also, grep for `__CLANG_ATOMIC_*` instead of `__GCC_ATOMIC_*`. The CLANG
macros are always emitted, but the GCC macros are omitted for the
*-windows-msvc targets. The `__GCC_HAVE_SYNC_COMPARE_AND_SWAP` macro
always has GCC in its name, not CLANG, however.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D127465
message expressions
For an Obj-C message expression `[o m]`, the adding matcher will match
the declaration of the method `m`. This commit overloads the existing
`callee` ASTMatcher, which originally was only for C/C++ nodes but
also applies to Obj-C messages now.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D129398
First of all, `LLVM_TOOLS_INSTALL_DIR` put there breaks our NixOS
builds, because `LLVM_TOOLS_INSTALL_DIR` defined the same as
`CMAKE_INSTALL_BINDIR` becomes an *absolute* path, and then when
downstream projects try to install there too this breaks because our
builds always install to fresh directories for isolation's sake.
Second of all, note that `LLVM_TOOLS_INSTALL_DIR` stands out against the
other specially crafted `LLVM_CONFIG_*` variables substituted in
`llvm/cmake/modules/LLVMConfig.cmake.in`.
@beanz added it in d0e1c2a550 to fix a
dangling reference in `AddLLVM`, but I am suspicious of how this
variable doesn't follow the pattern.
Those other ones are carefully made to be build-time vs install-time
variables depending on which `LLVMConfig.cmake` is being generated, are
carefully made relative as appropriate, etc. etc. For my NixOS use-case
they are also fine because they are never used as downstream install
variables, only for reading not writing.
To avoid the problems I face, and restore symmetry, I deleted the
exported and arranged to have many `${project}_TOOLS_INSTALL_DIR`s.
`AddLLVM` now instead expects each project to define its own, and they
do so based on `CMAKE_INSTALL_BINDIR`. `LLVMConfig` still exports
`LLVM_TOOLS_BINARY_DIR` which is the location for the tools defined in
the usual way, matching the other remaining exported variables.
For the `AddLLVM` changes, I tried to copy the existing pattern of
internal vs non-internal or for LLVM vs for downstream function/macro
names, but it would good to confirm I did that correctly.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D117977
EnumDecl's promotion type is set either to the parsed type or calculated type
after completing its definition. When it's bool type and has no definition,
its promotion type is bool which is not allowed by clang.
Fixes#56560.
Differential Revision: https://reviews.llvm.org/D130210
A copy-paste error caused UB in the definition of the unsigned long long
versions of the shfl intrinsics. Reported and diagnosed by @trws.
Differential Revision: https://reviews.llvm.org/D129536
The OpenMP offloading runtine currently uses an array of linked
offloading images. One downside to this is that we cannot know the
architecture or triple associated with the given image. In this patch,
instead of embedding the image itself, we embed an offloading binary
instead. This binary is simply a binary format that wraps around the
original linked image to provide some additional metadata. This will
allow us to support offloading to multiple architecture, or performing
future JIT compilation inside of the runtime, more clearly.
Additionally, these can be placed at a special section such that the
supported architectures can be identified using objdump with the support
from D126904. This needs to be stored in a new section name
`.llvm.offloading.images` because the `.llvm.offloading` section
implicitly uses the `SHF_EXCLUDE` flag and will always be stripped.
This patch does not contain the necessary code to parse these in
libomptarget.
Depends on D127246
Reviewed By: saiislam
Differential Revision: https://reviews.llvm.org/D127304
Adds `sarif` option to the existing `-fdiagnostics-format` flag
for intended future work with SARIF diagnostics. Currently issues a warning
against the use of diagnostics in SARIF mode, then defaults to clang style for
diagnostics.
Reviewed By: cjdb, denik, aaron.ballman
Differential Revision: https://reviews.llvm.org/D129886
This patch is in preparation for enabling vectorisation with tail-folding
by default for SVE targets. Once we do that many existing tests will
break that depend upon having normal unpredicated vector loops. For
all such tests I have added the flag:
-prefer-predicate-over-epilogue=scalar-epilogue
Differential Revision: https://reviews.llvm.org/D129137
Looks like we again are going to have problems with libcxx tests that
are overly specific in their dependency on clang's diagnostics.
This reverts commit 6542cb55a3.
This patch is basically the rewording of the static assert statement's
output(error) on screen after failing. Failing a _Static_assert in C
should not report that static_assert failed. It’d probably be better to
reword the diagnostic to be more like GCC and say “static assertion”
failed in both C and C++.
consider a c file having code
_Static_assert(0, "oh no!");
In clang the output is like:
<source>:1:1: error: static_assert failed: oh no!
_Static_assert(0, "oh no!");
^ ~
1 error generated.
Compiler returned: 1
Thus here the "static_assert" is not much good, it will be better to
reword it to the "static assertion failed" to more generic. as the gcc
prints as:
<source>:1:1: error: static assertion failed: "oh no!"
1 | _Static_assert(0, "oh no!");
| ^~~~~~~~~~~~~~
Compiler returned: 1
The above can also be seen here. This patch is about rewording
the static_assert to static assertion.
Differential Revision: https://reviews.llvm.org/D129048
This patch aims to create a webpage to document
Flang's command line options on https://flang.llvm.org/docs/
in a similar way to Clang's
https://clang.llvm.org/docs/ClangCommandLineReference.html
This is done by using clang_tablegen to generate an .rst
file from Options.td (which is current shared with Clang)
For this to work, ClangOptionDocEmitter.cpp was updated
to allow specific Flang flags to be included,
rather than bulk excluding clang flags.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D129864
Currently, clang may meet an infinite loop in a very tricky case when it
iterates the default args. This patch tries to fix this by adding a
`fixed` check.
These headers used to be guarded only on PowerPC64 Linux or FreeBSD, but
they can also be enabled for AIX OS target since it's big-endian ready.
Reviewed By: shchenz
Differential Revision: https://reviews.llvm.org/D129461
re-land fixes an unwanted interaction with module-map modules, seen in
Greendragon testing.
This provides updates to
[class.mfct]:
Pre C++20 [class.mfct]p2:
A member function may be defined (8.4) in its class definition, in
which case it is an inline member function (7.1.2)
Post C++20 [class.mfct]p1:
If a member function is attached to the global module and is defined
in its class definition, it is inline.
and
[class.friend]:
Pre-C++20 [class.friend]p5
A function can be defined in a friend declaration of a
class . . . . Such a function is implicitly inline.
Post C++20 [class.friend]p7
Such a function is implicitly an inline function if it is attached
to the global module.
We add the output of implicit-inline to the TextNodeDumper, and amend
a couple of existing tests to account for this, plus add tests for the
cases covered above.
Differential Revision: https://reviews.llvm.org/D129045
This patch makes use of OMPIRBuilder support for codegen of taskgroup
construct in clang.
Depends on D128203
Reviewed By: Meinersbur
Differential Revision: https://reviews.llvm.org/D129992
The heuristic used to determine where the arclite libraries are to be
found was based on the path of the `clang` executable. However, in some
scenarios the `clang` executable is within a toolchain that does not
have arclite. When this happens, derive the arclite paths from the
sysroot option.
This allows Clang to correctly derive the arclite directory in, e.g.,
Swift CI, using similar logic to what the Swift driver has been doing
for several years.
Patched by Doug Gregor.
Reviewed By: keith
Differential Revision: https://reviews.llvm.org/D130205
The new driver primarily allows us to support RDC-mode compilations with
proper linking. This is not needed for non-RDC mode compilation, but we
still would like the new driver to be able to handle this mode so we can
transition away from the old driver in the future. This patch adds the
necessary code to support creating a fatbinary for HIP code generation.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D129784
A new option -I is added for dxc mode.
It is just alias of existing cc1 -I option.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D128462
Move -lc++experimental before -lc++abi (that was forgotten in the
original patch), and mark a test as UNSUPPORTED on AIX. I contacted
the owners of the AIX bot that failed because I was unable to reproduce
the issue locally.
When F calls G calls H, G is nounwind, and G is inlined into F, then the
inlined call-site to H should be effectively nounwind so as not to lose
information during inlining.
If H itself is nounwind (which often happens when H is an intrinsic), we
no longer mark the callsite explicitly as nounwind. Previously, there
were cases where the inlined call-site of H differs from a pre-existing
call-site of H in F *only* in the explicitly added nounwind attribute,
thus preventing common subexpression elimination.
v2:
- just check CI->doesNotThrow
v3 (resubmit after revert at 3443788087):
- update Clang tests
Differential Revision: https://reviews.llvm.org/D129860
There is at least one Clang test (clang/test/CodeGen/arm_acle.c) which
has functions guarded by #if's that cause those functions to be compiled
only for a subset of RUN lines.
This results in a case where one RUN line has a body for the function
and another doesn't. Treat this case as a conflict for any prefixes that
the two RUN lines have in common.
This change exposed a bug where functions with '$' in the name weren't
properly recognized in ARM assembly (despite there being a test case
that was supposed to catch the problem!). This bug is fixed as well.
Differential Revision: https://reviews.llvm.org/D130089
Nicolai Hähnle