Moves the work required for retrieving annotation states into the `SetupTest` and `PostVisitCFG` callback to avoid having to run a separate pass over the CFG after analysis has completed.
Reviewed By: gribozavr2, sgatev, ymandel
Differential Revision: https://reviews.llvm.org/D132377
- Add `AnalysisInputs` struct as the parameters for `checkDataflow`, and renamed `AnalysisData` struct to `AnalysisOutputs` which contains the data structures generated from a dataflow analysis run.
- Remove compulsory binding from statement to annotations. Instead, `checkDataflow` in the most general form takes a `VerifyResults` callback which takes as input an `AnalysisOutputs` struct. This struct contains the data structures generated by the analysis that can then be tested. We then introduce two overloads/wrappers of `checkDataflow` for different mechanisms of testing - one which exposes annotation line numbers and is not restricted to statements, and the other which exposes states computed after annotated statements. In the future, we should look at retrieving the analysis states for constructs other than statements.
Reviewed By: gribozavr2, sgatev
Differential Revision: https://reviews.llvm.org/D132147
This is a follow up to https://reviews.llvm.org/D126864, addressing some remaining
comments.
It also considers union with a single zero-length array field as FAM for each
value of -fstrict-flex-arrays.
Differential Revision: https://reviews.llvm.org/D132944
This is a valid HTML5 tag. Previously it triggered a Clang error (`HTML start tag prematurely ended, expected attribute name or '>'`) since Clang was treating `/>` as a text token. This was happening because after lexing the closing quote (`"`) the lexer state was reset to "Normal" while the tag was not actually closed yet: `>` was not yet parsed at that point.
rdar://91464292
Differential Revision: https://reviews.llvm.org/D132932
`MatchSwitch` currently takes in matchers and functions for the `Stmt` class.
This patch generalises the match switch utility (renamed to `ASTMatchSwitch`) to work for different AST node types by introducing a template argument which is the base type for the AST nodes that the match switch will handle.
A `CFGMatchSwitch` is introduced as a wrapper around multiple `ASTMatchSwitch`s for different base types. It works by unwrapping `CFGElement`s into their contained AST nodes and passing the nodes to the relevant `ASTMatchSwitch`. The `CFGMatchSwitch` currently only handles `CFGStmt` and `CFGInitializer`.
Reviewed By: gribozavr2, sgatev
Differential Revision: https://reviews.llvm.org/D131616
Added a test case that enhances coverage of opaque pointers
particularly for the problematic case with extern functions
for which there is no solution found for type recovery.
Differential Revision: https://reviews.llvm.org/D130768
All the coroutine builtins were emitted in EmitCoroutineIntrinsic except
__builtin_coro_size. This patch tries to emit all the corotine builtins
uniformally.
Some of the code used in StdLibraryFunctionsChecker is applicable to
other checkers, this is put into common functions. Errno related
parts of the checker are simplified and renamed. Documentations in
errno_modeling functions are updated.
This change makes it available to have more checkers that perform
modeling of some standard functions. These can set the errno state
with common functions and the bug report messages (note tags) can
look similar.
Reviewed By: steakhal, martong
Differential Revision: https://reviews.llvm.org/D131879
The main focus of this patch is to make ArgType::matchesType check for
possible default parameter promotions when the argType is not a pointer.
If so, no warning will be given for `int`, `unsigned int` types as
corresponding arguments to %hhd and %hd. However, the usage of %hhd
corresponding to short is relatively rare, and it is more likely to be a
misuse. This patch keeps the original behavior of clang like this as
much as possible, while making it more convenient to consider the
default arguments promotion.
Fixes https://github.com/llvm/llvm-project/issues/57102
Reviewed By: aaron.ballman, nickdesaulniers, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D132568
The untested option triggers an IgnoredGCCCompat warning while GCC reports an error.
We support a few -X{assembler,linker,...}. Having the Joined -X may make typos unnoticed.
https://reviews.llvm.org/rG6bbf51f3ed59ae37f0fec729f25af002111c9e74 from May removed Preprocessor::getPredefines() from Clang's API, presumably as a cleanup because this method is unused in the LLVM codebase.
However, it was/is used by a small number of third-party tools and is pretty harmless, so this patch adds it back and documents why it's here.
The issue was raised in https://github.com/llvm/llvm-project/issues/57483, it would be nice to be able to land it into Clang 15 as it breaks those third-party tools and we can't easily add it back in bug fix releases.
Reviewed By: brad.king, thieta
Differential Revision: https://reviews.llvm.org/D133044
Seeing the wrong instruction for this name in IR is confusing.
Most of the tests are not even checking a subsequent use of
the value, so I just deleted the over-specified CHECKs.
`MatchSwitch` currently takes in matchers and functions for the `Stmt` class.
This patch generalises the match switch utility (renamed to `ASTMatchSwitch`) to work for different AST node types by introducing a template argument which is the base type for the AST nodes that the match switch will handle.
A `CFGMatchSwitch` is introduced as a wrapper around multiple `ASTMatchSwitch`s for different base types. It works by unwrapping `CFGElement`s into their contained AST nodes and passing the nodes to the relevant `ASTMatchSwitch`. The `CFGMatchSwitch` currently only handles `CFGStmt` and `CFGInitializer`.
Reviewed By: gribozavr2, sgatev
Differential Revision: https://reviews.llvm.org/D131616
Attempt to fix the test failures observed in CI:
* Add Option dependency, which caused BUILD_SHARED_LIBS builds to fail
* Adapt tests that accidentally depended on the host platform: platforms
that don't use an integrated assembler (e.g. AIX) get a different set
of commands from the driver. Most dependency scanner tests can use
-fsyntax-only or -E instead of -c to avoid this, and in the rare case
we want to check -c specifically, set an explicit target so the
behaviour is independent of the host.
Original commit message follows.
---
Instead of trying to "fix" the original driver invocation by appending
arguments to it, split it into multiple commands, and for each -cc1
command use a CompilerInvocation to give precise control over the
invocation.
This change should make it easier to (in the future) canonicalize the
command-line (e.g. to improve hits in something like ccache), apply
optimizations, or start supporting multi-arch builds, which would
require different modules for each arch.
In the long run it may make sense to treat the TU commands as a
dependency graph, each with their own dependencies on modules or earlier
TU commands, but for now they are simply a list that is executed in
order, and the dependencies are simply duplicated. Since we currently
only support single-arch builds, there is no parallelism available in
the execution.
Differential Revision: https://reviews.llvm.org/D132405
`CXString createRef(StringRef String)` used to return an invalid string when invoked with some empty strings:
If a `StringRef` holds a non-nullptr pointer, for instance, pointing into contents of a larger string, and has a zero length, `createRef` previously returned the entire larger string, ignoring the fact that the actual string passed to it as a param is empty.
This was discovered when invoking `c-index-test` to dump the contents of documentation comments, in case the comment contains an empty HTML attribute, such as `src=""`.
Differential Revision: https://reviews.llvm.org/D133009
https://reviews.llvm.org/D131255 (82afc9b169)
began warning about conversion causing data loss for a single-bit
bit-field. However, after landing the changes, there were reports about
significant false positives from some code bases.
This alters the approach taken in that patch by introducing a new
warning group (-Wsingle-bit-bitfield-constant-conversion) which is
grouped under -Wbitfield-constant-conversion to allow users to
selectively disable the single-bit warning without losing the other
constant conversion warnings.
Differential Revision: https://reviews.llvm.org/D132851
While discussing diagnostic format strings with a GSoC mentee, it
became clear there was some confusion regarding how to use them.
Specifically, the documentation for %select caused confunsion because
it was using %select{}2 and talking about how the integer value must
be in the range [0..2], which made it seem like the positional argument
was actually specifying the range of acceptable values.
I clarified several of the examples similarly, moved some documentation
to a more appropriate place, and added some additional information to
the %s modifier to point out that %plural exists.
This fixes the following warning:
In file included from ../tools/clang/lib/Tooling/Transformer/Transformer.cpp:9:
../tools/clang/include/clang/Tooling/Transformer/Transformer.h: In instantiation of ‘llvm::Error clang::tooling::detail::populateMetadata(const clang::transformer::RewriteRuleWith<MetadataT>&, size_t, const clang::ast_matchers::MatchFinder::MatchResult&, clang::tooling::TransformerResult<T>&) [with T = void; size_t = long unsigned int]’:
../tools/clang/include/clang/Tooling/Transformer/Transformer.h:179:34: required from ‘void clang::tooling::detail::WithMetadataImpl<T>::onMatchImpl(const clang::ast_matchers::MatchFinder::MatchResult&) [with T = void]’
../tools/clang/include/clang/Tooling/Transformer/Transformer.h:156:8: required from here
../tools/clang/include/clang/Tooling/Transformer/Transformer.h:120:25: warning: parameter ‘SelectedCase’ set but not used [-Wunused-but-set-parameter]
120 | size_t SelectedCase,
| ~~~~~~~^~~~~~~~~~~~
The issue is fixed in GCC 10 and later, but this silences the noisy
warning in older versions. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85827
for more details about the bug.
Differential Revision: https://reviews.llvm.org/D132920
Previously, the transfer function `void transfer(const Stmt *, ...)` overriden by users is restricted to apply only on `CFGStmt`s and its contained `Stmt`.
By using a transfer function (`void transfer(const CFGElement *, ...)`) that takes a `CFGElement` as input, this patch extends user-defined analysis to all kinds of `CFGElement`. For example, users can now handle `CFGInitializer`s where `CXXCtorInitializer` AST nodes are contained.
Reviewed By: gribozavr2, sgatev
Differential Revision: https://reviews.llvm.org/D131614
This was showing up in our internal crash collector. I have no idea how
to test it out though, open for suggestions if there are easy paths but
otherwise I'd move forward with the patch.
Differential Revision: https://reviews.llvm.org/D132918
If the style wraps control statement braces, the opening braces
should be inserted after the trailing comments if present.
Fixes#57419.
Differential Revision: https://reviews.llvm.org/D132905
We get some standard C++ module things done in clang15.x. But we lack a
user documentation for it. The implementation of standard C++ modules
share a big part of codes with clang modules. But they have very
different semantics and user interfaces, so I think it is necessary to
add a document for Standard C++ modules. Previously, there were also
some people ask the document for standard C++ Modules and I couldn't
offer that time.
Reviewed By: iains, Mordante, h-vetinari, ruoso, dblaikie, JohelEGP,
aaronmondal
Differential Revision: https://reviews.llvm.org/D131388
This reverts commit 33162a81d4.
This change breaks the usage of module maps with modules disabled, such
as for layering checking via `-fmodules-decluse`.
Regression test added.
In Sema::CheckCompletedCXXClass(...) It used a lambda CheckForDefaultedFunction
the CXXMethodDecl passed to CheckForDefaultedFunction may not be a special
member function and so before attempting to apply functions that only apply to
special member functions it needs to check. It fails to do this before calling
DefineDefaultedFunction(...). This PR adds that check and test to verify we no
longer crash.
This fixes https://github.com/llvm/llvm-project/issues/57431
Differential Revision: https://reviews.llvm.org/D132906
Instead of trying to "fix" the original driver invocation by appending
arguments to it, split it into multiple commands, and for each -cc1
command use a CompilerInvocation to give precise control over the
invocation.
This change should make it easier to (in the future) canonicalize the
command-line (e.g. to improve hits in something like ccache), apply
optimizations, or start supporting multi-arch builds, which would
require different modules for each arch.
In the long run it may make sense to treat the TU commands as a
dependency graph, each with their own dependencies on modules or earlier
TU commands, but for now they are simply a list that is executed in
order, and the dependencies are simply duplicated. Since we currently
only support single-arch builds, there is no parallelism available in
the execution.
Differential Revision: https://reviews.llvm.org/D132405
The Darwin module has specified [no_undeclared_includes] for at least five years now, there's no need to hard code it in the compiler.
Reviewed By: ributzka, Bigcheese
Differential Revision: https://reviews.llvm.org/D132971
This document describes the basic usage and implementation details for
HLSL entry functions in Clang.
Reviewed By: python3kgae
Differential Revision: https://reviews.llvm.org/D132672
When checking parameter packs for expansion, instead of basing the diagnostic for
length mismatch for outer parameters only on the known number of expansions,
we should also analyze SubstTemplateTypeParmPackType and SubstNonTypeTemplateParmPackExpr
for unexpanded packs, so we can emit a diagnostic pointing to a concrete
outer parameter.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D128095
Summary:
Some of code in the patch are contributed by David Tenty.
1. We currently only check driver Wl options and don't check for the plain -b, -Xlinker or other options which get passed through to the linker when we decide whether to run llvm-nm --export-symbols, so we may run it in situations where we wouldn't if the user had used the equivalent -Wl, prefixed options. If we run the export list utility when the user has specified an export list, we could export more symbols than they intended.
2. Add a new functionality to allow redirecting the stdin, stdout, stderr of individual Jobs, if redirects are set for the Job use them, otherwise fall back to the global Compilation redirects if any.
Reviewers: David Tenty, Fangrui Song, Steven Wan
Differential Revision: https://reviews.llvm.org/D119147
The test to check if an array was a FAM in the context of array bound checking
and strict-flex-arrays=1 was inverted.
As a by product, improve test coverage.
Differential Revision: https://reviews.llvm.org/D132853
This patch has the following changes:
(1) Handling of internal linkage functions (static functions)
Static functions in FDO have a prefix of source file name, while they do not
have one in SampleFDO. Current implementation does not handle this and we are
not updating the profile for static functions. This patch fixes this.
(2) Handling of -funique-internal-linakge-symbols
Again this is for the internal linkage functions. Option
-funique-internal-linakge-symbols can now be applied to both FDO and SampleFDO
compilation. When it is used, it demangles internal linkage function names and
adds a hash value as the postfix.
When both SampleFDO and FDO profiles use this option, or both
not use this option, changes in (1) should handle this.
Here we also handle when the SampleFDO profile using this option while FDO
profile not using this option, or vice versa.
There is one case where this patch won't work: If one of the profiles used
mangled name and the other does not. For example, if the SampleFDO profile
uses clang c-compiler and without -funique-internal-linakge-symbols, while
the FDO profile uses -funique-internal-linakge-symbols. The SampleFDO profile
contains unmangled names while the FDO profile contains mangled names. If
both profiles use c++ compiler, this won't happen. We think this use case
is rare and does not justify the effort to fix.
Differential Revision: https://reviews.llvm.org/D132600
To have finer control of IR uwtable attribute generation. For target code generation,
IR nounwind and uwtable may have some interaction. However, for frontend, there are
no semantic interactions so the this new `nouwtable` is marked "SimpleHandler = 1".
Differential Revision: https://reviews.llvm.org/D132592
`report_fatal_error` is overloaded on `StringRef` and `Twine &`, therefore passing a `std::string` argument leads to ambiguity as it is convertible to either type.
Reviewed By: gribozavr2, sgatev
Differential Revision: https://reviews.llvm.org/D132745
The rule IDs are not stable, so this uses a regex for the rule ids
instead of concrete values. It also moves the CHECK lines below the
code so that it's easier to modify the test in the future. It also
breaks the CHECK lines into multiple lines to improve the performance
of the test and aid in debugging failures. Finally, it adds a comment
to the top of the test explaining that things are still rather fragile.
The method is now wrapped by clang_getUnqualifiedType.
A declaration for clang_getUnqualifiedType was added to
clang-c/Index.h to expose it to user of the library.
An implementation for clang_getUnqualifiedType was introduced in
CXType.cpp that wraps the equivalent method of the underlying
QualType of a CXType.
An export symbol was added to libclang.map under the new version entry
LLVM_16.
A test was added to LibclangTest.cpp that tests the removal of
qualifiers for some CXTypes.
Differential Revision: https://reviews.llvm.org/D132749
There are two scenarios here:
1. Standalone flang build, where we use an installed clang-tblgen
binary. We need to use find_package() to find it.
2. Combined build of clang and flang, where we want to use the
path specified in CLANG_TABLEGEN_EXE during the clang build --
however, this variable was previously not exported.
The new implementation matches what is done for mlir-tblgen.
Differential Revision: https://reviews.llvm.org/D131475
Control Flow Guard is only supported on Windows target, therefore there
is no point to make it an accepted attribute for other targets.
Reviewed By: rnk, aaron.ballman
Differential Revision: https://reviews.llvm.org/D132661
When an l_brace is wrapped and the line above it ends with a
comment, the annotator adds ColumnLimit to the TotalLength of the
l_brace, so the actual column position of the l_brace must be
adjusted accordingly.
Fixes#57376.
Differential Revision: https://reviews.llvm.org/D132805
To align with many Linux distributions which configure GCC with
--enable-default-hash-style=gnu or binutils with --with-linker-hash-style=gnu.
ld.lld does not support changed default, so passing the option in the driver is
better.
Note: there was a bug that Debian specified both --hash-style=gnu and
--hash-style=both. Actually its GCC has defaulted to --hash-style=gnu since 2007.
The ArgumentPromotion pass uses Mem2Reg promotion at the end to cutting
down generated `alloca` instructions as well as meaningless `store`s and
this behavior can leave unused (dead) arguments. To eliminate the dead
arguments and therefore let the DeadCodeElimination remove becoming dead
inserted `GEP`s as well as `load`s and `cast`s in the callers, the
DeadArgumentElimination pass should be run after the ArgumentPromotion
one.
Differential Revision: https://reviews.llvm.org/D128830
In Parser::ParseUsingDeclaration(...) when we call ParseEnumSpecifier(...) it is
not calling SetTypeSpecError() on DS when it detects an error. That means that
DS is left set to TST_unspecified. When we then pass DS into
Sema::ActOnUsingEnumDeclaration(...) we hit an llvm_unreachable(...) since it
expects it to be one of three states TST_error, TST_enum or TST_typename.
This fixes https://github.com/llvm/llvm-project/issues/57347
Differential Revision: https://reviews.llvm.org/D132695
This patch replaces clamp idioms with std::clamp where the range is
obviously valid from the source code (that is, low <= high) to avoid
introducing undefined behavior.
If we run into a first usage or definition of a mangled name, and
there's a DeferredDecl that associated with it, we should remember it we
need to emit it later on.
Without this patch, clang-repl hits a JIT symbol not found error:
clang-repl> extern "C" int printf(const char *, ...);
clang-repl> auto l1 = []() { printf("ONE\n"); return 42; };
clang-repl> auto l2 = []() { printf("TWO\n"); return 17; };
clang-repl> auto r1 = l1();
ONE
clang-repl> auto r2 = l2();
TWO
clang-repl> auto r3 = l2();
JIT session error: Symbols not found: [ l2 ]
error: Failed to materialize symbols: { (main,
{ r3, orc_init_func.incr_module_5, $.incr_module_5.inits.0 }) }
Signed-off-by: Jun Zhang <jun@junz.org>
Differential Revision: https://reviews.llvm.org/D130831
Xcode 13's clang has them. For the included testcase, Xcode's clang
behaves like the implementation in this patch.
Availability.h in the macOS 12.0 SDK (part of Xcode 13, and the current
stable version of the macOS SDK) does something like:
#if defined(__has_builtin)
...
#if __has_builtin(__is_target_os)
#if __has_builtin(__is_target_environment)
#if __has_builtin(__is_target_variant_os)
#if __has_builtin(__is_target_variant_environment)
#if (... && ((__is_target_os(ios) && __is_target_environment(macabi)) || (__is_target_variant_os(ios) && __is_target_variant_environment(macabi))))
#define __OSX_AVAILABLE_STARTING(_osx, _ios) ...
#define __OSX_AVAILABLE_BUT_DEPRECATED(_osxIntro, _osxDep, _iosIntro, _iosDep) ...
#define __OSX_AVAILABLE_BUT_DEPRECATED_MSG(_osxIntro, _osxDep, _iosIntro, _iosDep, _msg) ...
So if __has_builtin(__is_target_variant_os) or
__has_builtin(__is_target_variant_environment) are false, these defines are not
defined.
Most of the time, this doesn't matter. But open-source clang currently fails
to commpile a file containing only `#include <Security/cssmtype.h>` when
building for catalyst by adding a `-target arm64-apple-ios13.1-macabi` triple,
due to those __OSX_AVAILABLE macros not being set correctly.
If a potential future SDK version were to include cssmtype.h transitively
from a common header such as `<Foundation/Foundation.h>`, then it would become
close to impossible to build Catalyst binaries with open-source clang.
To fix this for normal catalyst builds, it's only necessary that
__has_builtin() evaluates to true for these two built-ins -- the implementation
of them doesn't matter. But as a courtesy, a correct (at least on the test
cases I tried) implementation is provided. (This should also help people who
try to build zippered code, where having the correct implementation does
matter.)
Differential Revision: https://reviews.llvm.org/D132754
Summary:
A previous patch removed the use of the `OK` private variable in CUDA
which resulted in usused variable warnings. this was fixed in
f886f7e8ef but did not change the
constructor to accurately represent its removal. This patch removes it
from the interface entirely.
leaking in ARC mode
When ARC (automatic reference count) is enabled, (objective-c) block
objects are automatically retained and released thus they do not leak.
Without ARC, they still can leak from an expiring stack frame like
other stack variables.
With this commit, the static analyzer now puts a block object in an
"unknown" region if ARC is enabled because it is up to the
implementation to choose whether to put the object on stack initially
(then move to heap when needed) or in heap directly under ARC.
Therefore, the `StackAddrEscapeChecker` has no need to know
specifically about ARC at all and it will not report errors on objects
in "unknown" regions.
Reviewed By: NoQ (Artem Dergachev)
Differential Revision: https://reviews.llvm.org/D131009
Enables Clang to emit diagnostics in SARIF format when
`-fdiagnostics-format=sarif`. Adds a new DiagnosticConsumer named
SARIFDiagnosticPrinter and a new DiagnosticRenderer named SARIFDiagnostic
to constuct and emit a SARIF object containing the run's basic diagnostic info.
Reviewed By: cjdb, denik, aaron.ballman
Differential Revision: https://reviews.llvm.org/D131632
Recently OpenMP has transitioned to using the "new" driver which
primarily merges the device and host linking phases into a single
wrapper that handles both at the same time. This replaced a few tools
that were only used for OpenMP offloading, such as the
`clang-offload-wrapper` and `clang-nvlink-wrapper`. The new driver
carries some marked benefits compared to the old driver that is now
being deprecated. Things like device-side LTO, static library
support, and more compatible tooling. As such, we should be able to
completely deprecate the old driver, at least for OpenMP. The old driver
support will still exist for CUDA and HIP, although both of these can
currently be compiled on Linux with `--offload-new-driver` to use the new
method.
Note that this does not deprecate the `clang-offload-bundler`, although
it is unused by OpenMP now, it is still used by the HIP toolchain both
as their device binary format and object format.
When I proposed deprecating this code I heard some vendors voice
concernes about needing to update their code in their fork. They should
be able to just revert this commit if it lands.
Reviewed By: jdoerfert, MaskRay, ye-luo
Differential Revision: https://reviews.llvm.org/D130020
We run into a duplicate symbol error when instrumenting the rtti_proxies
generated as part of the relative vtables ABI with hwasan:
```
ld.lld: error: duplicate symbol: typeinfo for icu_71::UObject
(.rtti_proxy)
>>> defined at brkiter.cpp
>>>
arm64-hwasan-shared/obj/third_party/icu/source/common/libicuuc.brkiter.cpp.o:(typeinfo
for icu_71::UObject (.rtti_proxy))
>>> defined at locavailable.cpp
>>>
arm64-hwasan-shared/obj/third_party/icu/source/common/libicuuc.locavailable.cpp.o:(.data.rel.ro..L_ZTIN6icu_717UObjectE.rtti_proxy.hwasan+0xE00000000000000)
```
The issue here is that the hwasan alias carries over the visibility and
linkage of the original proxy, so we have duplicate external symbols
that participate in linking. Similar to D132425 we can just disable
hwasan for the proxies for now.
Differential Revision: https://reviews.llvm.org/D132691
Full context in
https://bugs.fuchsia.dev/p/fuchsia/issues/detail?id=107017.
Instrumenting hwasan with globals results in a linker error under the
relative vtables abi:
```
ld.lld: error:
libunwind.cpp:(.rodata..L_ZTVN9libunwind12UnwindCursorINS_17LocalAddressSpaceENS_15Registers_arm64EEE.hwasan+0x8):
relocation R_AARCH64_PLT32 out of range: 6845471433603167792 is not in
[-2147483648, 2147483647]; references
libunwind::AbstractUnwindCursor::~AbstractUnwindCursor()
>>> defined in
libunwind/src/CMakeFiles/unwind_shared.dir/libunwind.cpp.obj
```
This is because the tag is included in the vtable address when
calculating the offset between the vtable and virtual function. A
temporary solution until we can resolve this is to just disable hwasan
instrumentation on relative vtables specifically, which can be done in
the frontend.
Differential Revision: https://reviews.llvm.org/D132425
In Sema::LookupTemplateName(...) seeks to assert that the ObjectType is complete
or being defined. If the type is incomplete it will attempt to unconditionally
cast it to a TagType and not all incomplete types are a TagType. For example the
type could be void or it could be an IncompleteArray.
This change adds an additional check to confirm it is a TagType before attempting
to check if it is incomplete or being defined
Differential Revision: https://reviews.llvm.org/D132712
Put DXIL validation version into separate NamedMetadata to avoid update ModuleFlags.
Currently DXIL validation version is saved in ModuleFlags in clang codeGen.
Then in DirectX backend, the data will be extracted from ModuleFlags and cause rebuild of ModuleFlags.
This patch will build NamedMetadata for DXIL validation version and remove the code to rebuild ModuleFlags.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D130207
Clang crashes when encountering an `if consteval` statement.
This is the minimum fix not to crash.
The fix is consistent with the current behavior of if constexpr,
which does generate coverage data for the discarded branches.
This is of course not correct and a better solution is
needed for both if constexpr and if consteval.
See https://github.com/llvm/llvm-project/issues/54419.
Fixes#57377
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D132723
This addresses an accidental change in behavior from
41667a8b9b to get the bots back to green.
However, I think there's an issue with LLDB assuming it's valid to
enable support for keywords in language modes that don't support the
keyword (as other parts of Clang are not expecting to be able to do
that).
This should fix (and others):
https://lab.llvm.org/buildbot/#/builders/68/builds/38374
The patch diagnoses an identifier as a future keyword if it exists in a
future language mode, such as:
int restrict;
in C modes earlier than C99. We now give a warning to the user that
such an identifier is a future keyword. Handles keywords from C as well
as C++.
Differential Revision: https://reviews.llvm.org/D131683
The commit breaks the compiler when a function is used as a function
parameter (hm... for a function from the standard C library?):
```
static float strtof(char *, char *) {}
void a() { strtof(a, 0); }
```
This reverts commit 879f5118fc.
Closing https://github.com/llvm/llvm-project/issues/57339
The root cause for this issue is an pre-mature optimization to eliminate
the index for the final suspend point since we feel like we can judge
if a coroutine is suspended at the final suspend by if resume_fn_addr is
null. However this is not true if the coroutine exists via an exception
in promise.unhandled_exception(). According to
[dcl.fct.def.coroutine]p14:
> If the evaluation of the expression promise.unhandled_exception()
> exits via an exception, the coroutine is considered suspended at the
> final suspend point.
But from the perspective of the implementation, we can't set the coro
index to the final suspend point directly since it breaks the states.
To fix the issue, we block the optimization if we find there is any
unwind coro end, which indicates that it is possible that the coroutine
exists via an exception from promise.unhandled_exception().
Test Plan: folly
This patch implements P0848 in Clang.
During the instantiation of a C++ class, in `Sema::ActOnFields`, we evaluate constraints for all the SMFs and compare the constraints to compute the eligibility. We defer the computation of the type's [copy-]trivial bits from addedMember to the eligibility computation, like we did for destructors in D126194. `canPassInRegisters` is modified as well to better respect the ineligibility of functions.
Note: Because of the non-implementation of DR1734 and DR1496, I treat deleted member functions as 'eligible' for the purpose of [copy-]triviallity. This is unfortunate, but I couldn't think of a way to make this make sense otherwise.
Reviewed By: #clang-language-wg, cor3ntin, aaron.ballman
Differential Revision: https://reviews.llvm.org/D128619
Semantic parameters aren't passed as actual parameters, instead they are
populated from intrinsics which are generally lowered to reads from
dedicated hardware registers.
This change modifies clang CodeGen to emit the intrinsic calls and
populate the parameter's LValue with the result of the intrinsic call
for SV_GroupIndex.
The result of this is to make the actual passed argument ignored, which
will make it easy to clean up later in an IR pass.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D131203
The linker is supposed to detect when an object with /kernel is linked
with another object which is not compiled with /kernel. The linker
detects this by checking bit 30 in @feat.00.
* Factor module map and module file path functions out
* Use a secondary mapping to lookup module deps by ID instead of the
preprocessor module map.
* Sink DirectPrebuiltModularDeps into MDC.
Differential Revision: https://reviews.llvm.org/D132617
clang/lib/Basic/Targets/X86.h:293:8: warning: 'shouldEmitFloat16WithExcessPrecision' overrides a member function but is not marked 'override' [-Winconsistent-missing-override]
bool shouldEmitFloat16WithExcessPrecision() const {
^
clang/include/clang/Basic/TargetInfo.h:915:16: note: overridden virtual function is here
virtual bool shouldEmitFloat16WithExcessPrecision() const { return false; }
^
Prior to this patch when the analyzer encountered a non-POD 0 length array,
it still invoked the constructor for 1 element, which lead to false positives.
This patch makes sure that we no longer construct any elements when we see a
0 length array.
Differential Revision: https://reviews.llvm.org/D131501
The ArgumentPromotion pass uses Mem2Reg promotion at the end to cutting
down generated `alloca` instructions as well as meaningless `store`s and
this behavior can leave unused (dead) arguments. To eliminate the dead
arguments and therefore let the DeadCodeElimination remove becoming dead
inserted `GEP`s as well as `load`s and `cast`s in the callers, the
DeadArgumentElimination pass should be run after the ArgumentPromotion
one.
Differential Revision: https://reviews.llvm.org/D128830
The invocation is only ever used to serialize cc1 arguments from, so
instead serialize the arguments inside the dep scanner to simplify the
interface.
Differential Revision: https://reviews.llvm.org/D132616
ToolInvocation is useful even if you already have a -cc1 invocation,
since it provides a standard way to setup diagnostics, parse arguments,
and handoff to a ToolAction. So teach it to support -cc1 commands by
skipping the driver bits.
Differential Revision: https://reviews.llvm.org/D132615
The KCFI sanitizer, enabled with `-fsanitize=kcfi`, implements a
forward-edge control flow integrity scheme for indirect calls. It
uses a !kcfi_type metadata node to attach a type identifier for each
function and injects verification code before indirect calls.
Unlike the current CFI schemes implemented in LLVM, KCFI does not
require LTO, does not alter function references to point to a jump
table, and never breaks function address equality. KCFI is intended
to be used in low-level code, such as operating system kernels,
where the existing schemes can cause undue complications because
of the aforementioned properties. However, unlike the existing
schemes, KCFI is limited to validating only function pointers and is
not compatible with executable-only memory.
KCFI does not provide runtime support, but always traps when a
type mismatch is encountered. Users of the scheme are expected
to handle the trap. With `-fsanitize=kcfi`, Clang emits a `kcfi`
operand bundle to indirect calls, and LLVM lowers this to a
known architecture-specific sequence of instructions for each
callsite to make runtime patching easier for users who require this
functionality.
A KCFI type identifier is a 32-bit constant produced by taking the
lower half of xxHash64 from a C++ mangled typename. If a program
contains indirect calls to assembly functions, they must be
manually annotated with the expected type identifiers to prevent
errors. To make this easier, Clang generates a weak SHN_ABS
`__kcfi_typeid_<function>` symbol for each address-taken function
declaration, which can be used to annotate functions in assembly
as long as at least one C translation unit linked into the program
takes the function address. For example on AArch64, we might have
the following code:
```
.c:
int f(void);
int (*p)(void) = f;
p();
.s:
.4byte __kcfi_typeid_f
.global f
f:
...
```
Note that X86 uses a different preamble format for compatibility
with Linux kernel tooling. See the comments in
`X86AsmPrinter::emitKCFITypeId` for details.
As users of KCFI may need to locate trap locations for binary
validation and error handling, LLVM can additionally emit the
locations of traps to a `.kcfi_traps` section.
Similarly to other sanitizers, KCFI checking can be disabled for a
function with a `no_sanitize("kcfi")` function attribute.
Relands 67504c9549 with a fix for
32-bit builds.
Reviewed By: nickdesaulniers, kees, joaomoreira, MaskRay
Differential Revision: https://reviews.llvm.org/D119296
This patch adds a formatter for `std::coroutine_handle`, both for libc++
and libstdc++. For the type-erased `coroutine_handle<>`, it shows the
`resume` and `destroy` function pointers. For a non-type-erased
`coroutine_handle<promise_type>` it also shows the `promise` value.
With this change, executing the `v t` command on the example from
https://clang.llvm.org/docs/DebuggingCoroutines.html now outputs
```
(task) t = {
handle = coro frame = 0x55555555b2a0 {
resume = 0x0000555555555a10 (a.out`coro_task(int, int) at llvm-example.cpp:36)
destroy = 0x0000555555556090 (a.out`coro_task(int, int) at llvm-example.cpp:36)
}
}
```
instead of just
```
(task) t = {
handle = {
__handle_ = 0x55555555b2a0
}
}
```
Note, how the symbols for the `resume` and `destroy` function pointer
reveal which coroutine is stored inside the `std::coroutine_handle`.
A follow-up commit will use this fact to infer the coroutine's promise
type and the representation of its internal coroutine state based on
the `resume` and `destroy` pointers.
The same formatter is used for both libc++ and libstdc++. It would
also work for MSVC's standard library, however it is not registered
for MSVC, given that lldb does not provide pretty printers for other
MSVC types, either.
The formatter is in a newly added `Coroutines.{h,cpp}` file because there
does not seem to be an already existing place where we could share
formatters across libc++ and libstdc++. Also, I expect this code to grow
as we improve debugging experience for coroutines further.
**Testing**
* Added API test
Differential Revision: https://reviews.llvm.org/D132415
When Clang encounters `@import M.Private` during implicit build, it precompiles module `M` and looks through its submodules. If the `Private` submodule is not found, Clang assumes `@import M_Private`. In the dependency scanner, we don't capture the dependency on `M`, since it's not imported. It's an affecting module, though: compilation of the import statement will fail when implicit modules are disabled and `M` is not precompiled and explicitly provided. This patch fixes that.
Depends on D132430.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D132502
HLSL entry function parameters must have parameter annotations. This
allows appropriate intrinsic values to be populated into parameters
during code generation.
This does not handle entry function return values, which will be
handled in a subsequent commit because we don't currently support any
annotations that are valid for function returns.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D131625
The KCFI sanitizer, enabled with `-fsanitize=kcfi`, implements a
forward-edge control flow integrity scheme for indirect calls. It
uses a !kcfi_type metadata node to attach a type identifier for each
function and injects verification code before indirect calls.
Unlike the current CFI schemes implemented in LLVM, KCFI does not
require LTO, does not alter function references to point to a jump
table, and never breaks function address equality. KCFI is intended
to be used in low-level code, such as operating system kernels,
where the existing schemes can cause undue complications because
of the aforementioned properties. However, unlike the existing
schemes, KCFI is limited to validating only function pointers and is
not compatible with executable-only memory.
KCFI does not provide runtime support, but always traps when a
type mismatch is encountered. Users of the scheme are expected
to handle the trap. With `-fsanitize=kcfi`, Clang emits a `kcfi`
operand bundle to indirect calls, and LLVM lowers this to a
known architecture-specific sequence of instructions for each
callsite to make runtime patching easier for users who require this
functionality.
A KCFI type identifier is a 32-bit constant produced by taking the
lower half of xxHash64 from a C++ mangled typename. If a program
contains indirect calls to assembly functions, they must be
manually annotated with the expected type identifiers to prevent
errors. To make this easier, Clang generates a weak SHN_ABS
`__kcfi_typeid_<function>` symbol for each address-taken function
declaration, which can be used to annotate functions in assembly
as long as at least one C translation unit linked into the program
takes the function address. For example on AArch64, we might have
the following code:
```
.c:
int f(void);
int (*p)(void) = f;
p();
.s:
.4byte __kcfi_typeid_f
.global f
f:
...
```
Note that X86 uses a different preamble format for compatibility
with Linux kernel tooling. See the comments in
`X86AsmPrinter::emitKCFITypeId` for details.
As users of KCFI may need to locate trap locations for binary
validation and error handling, LLVM can additionally emit the
locations of traps to a `.kcfi_traps` section.
Similarly to other sanitizers, KCFI checking can be disabled for a
function with a `no_sanitize("kcfi")` function attribute.
Reviewed By: nickdesaulniers, kees, joaomoreira, MaskRay
Differential Revision: https://reviews.llvm.org/D119296
When compiling a module, its semantics and Clang's behavior are affected by other modules. These modules are typically the **imported** ones. However, during implicit build, some modules end up being compiled and read without being actually imported. This patch starts tracking such modules and serializing them into `.pcm` files. This enables the dependency scanner to construct explicit compilations that mimic implicit build.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D132430
We're seeing the following warnings with --rtlib=compiler-rt:
lld-link: warning: ignoring unknown argument '--as-needed'
lld-link: warning: ignoring unknown argument '-lunwind'
lld-link: warning: ignoring unknown argument '--no-as-needed'
MSVC doesn't use the unwind library, so just omit it.
Differential Revision: https://reviews.llvm.org/D132440
A simple sed doing these substitutions:
- `${LLVM_BINARY_DIR}/(\$\{CMAKE_CFG_INTDIR}/)?lib(${LLVM_LIBDIR_SUFFIX})?\>` -> `${LLVM_LIBRARY_DIR}`
- `${LLVM_BINARY_DIR}/(\$\{CMAKE_CFG_INTDIR}/)?bin\>` -> `${LLVM_TOOLS_BINARY_DIR}`
where `\>` means "word boundary".
The only manual modifications were reverting changes in
- `compiler-rt/cmake/Modules/CompilerRTUtils.cmake
- `runtimes/CMakeLists.txt`
because these were "entry points" where we wanted to tread carefully not not introduce a "loop" which would end with an undefined variable being expanded to nothing.
This hopefully increases readability overall, and also decreases the usages of `LLVM_LIBDIR_SUFFIX`, preparing us for D130586.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D132316
The new driver supports device-only compilation for the offloading
device. The way this is handlded is a little different from the old
offloading driver. The old driver would put all the outputs in the final
action list akin to a linker job. The new driver however generated these
in the middle of the host's job so we instead put them all in a single
offloading action. However, we only handled these kinds of offloading
actions correctly when there was only a single input. When we had
multiple inputs we would instead attempt to get the host job, which
didn't exist, and crash.
This patch simply adds some extra logic to generate the jobs for all
dependencies if there is not host action.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D132248
For the time being, we are still building libc++ and libc++abi's headers
during stage 2 builds. Encode that in the cache file so that CI jobs don't
have to manually specify LLVM_ENABLE_RUNTIMES when doing a stage 2 build.
Normally, passing -rtlib=platform overrides any earlier -rtlib
options, and overrides any hardcoded CLANG_DEFAULT_RTLIB option.
However, some targets, MSVC and Darwin, have custom logic for
disallowing specific -rtlib= option values; amend these checks for
allowing the -rtlib=platform option.
Differential Revision: https://reviews.llvm.org/D132444
The ArgumentPromotion pass uses Mem2Reg promotion at the end to cutting
down generated `alloca` instructions as well as meaningless `store`s and
this behavior can leave unused (dead) arguments. To eliminate the dead
arguments and therefore let the DeadCodeElimination remove becoming dead
inserted `GEP`s as well as `load`s and `cast`s in the callers, the
DeadArgumentElimination pass should be run after the ArgumentPromotion
one.
Differential Revision: https://reviews.llvm.org/D128830
This removes -O1 from the SVE ACLE intrinsics tests and replaces it with
-O0 and "opt -mem2reg -instcombine -tailcallelim". Instrcombine and
TailCallElim are only added to keep the differences smaller and can be
removed in a followup patches. The only remaining differences in the
tests are tbaa nodes not being emitted under -O0, and the removable of
some tailcall flags.
We're seeing the following warnings with --rtlib=compiler-rt:
lld-link: warning: ignoring unknown argument '--as-needed'
lld-link: warning: ignoring unknown argument '-lunwind'
lld-link: warning: ignoring unknown argument '--no-as-needed'
MSVC doesn't use the unwind library, so just omit it.
Differential Revision: https://reviews.llvm.org/D132440
The constructors of non-POD array elements are evaluated under
certain conditions. This patch makes sure that in such cases
we also evaluate the destructors.
Differential Revision: https://reviews.llvm.org/D130737
We build libcxx using LLVM_ENABLE_RUNTIMES during Stage2, which requires
cxx-headers to be part of LLVM_RUNTIME_DISTRIBUTION_COMPONENTS instead
of LLVM_DISTRIBUTION_COMPONENTS.
rdar://99028431
Differential Revision: https://reviews.llvm.org/D132488
"this" parameter of lambda if undef, notnull and differentiable.
So we need to pass something consistent.
Any alloca will work. It will be eliminated as unused later by optimizer.
Otherwise we generate code which Msan is expected to catch.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D132275
To support using Control Flow Guard with mingw-w64, Clang needs to
accept `__declspec(guard(nocf))` also for the GNU target. Since mingw
has `#define __declspec(a) __attribute__((a))` as built-in, the simplest
solution is to accept `__attribute__((guard(nocf)))` to be compatible with
MSVC and Clang's msvc target.
As a side effect, this also adds `[[clang::guard(nocf)]]` for C++.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D132302
The OpenMP device runtime needs to support the OpenMP standard. However
constructs like nested parallelism are very uncommon in real application
yet lead to complexity in the runtime that is sometimes difficult to
optimize out. As a stop-gap for performance we should supply an argument
that selectively disables this feature. This patch adds the
`-fopenmp-assume-no-nested-parallelism` argument which explicitly
disables the usee of nested parallelism in OpenMP.
Reviewed By: carlo.bertolli
Differential Revision: https://reviews.llvm.org/D132074
This patch implements P0848 in Clang.
During the instantiation of a C++ class, in `Sema::ActOnFields`, we evaluate constraints for all the SMFs and compare the constraints to compute the eligibility. We defer the computation of the type's [copy-]trivial bits from addedMember to the eligibility computation, like we did for destructors in D126194. `canPassInRegisters` is modified as well to better respect the ineligibility of functions.
Note: Because of the non-implementation of DR1734 and DR1496, I treat deleted member functions as 'eligible' for the purpose of [copy-]triviallity. This is unfortunate, but I couldn't think of a way to make this make sense otherwise.
Reviewed By: #clang-language-wg, cor3ntin, aaron.ballman
Differential Revision: https://reviews.llvm.org/D128619
This is to clarify that the macro __FLT_EVAL_METHOD__ is not pre-
defined like other preprocessor macros. It will not appear when
preprocessor macros are dumped.
Differential Revision: https://reviews.llvm.org/D124033
Since the patch missed release 15.x and will be included in release 16.x. Also, simplify related tests.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D132414
As proposed in D126215 (ffe7950ebc),
I'm dropping the `-analyzer-store` and
`-analyzer-opt-analyze-nested-blocks` clang frontend flags.
I'm also dropping the corresponding commandline handlers of `scanbuild`.
This behavior is planned to be part of `clang-16`.
Reviewed By: xazax.hun
Differential Revision: https://reviews.llvm.org/D132289
Dead store detection automatically checks that an expression is a
CXXConstructor and skips it because of potential side effects. In C++17,
with guaranteed copy elision, this check can fail because we actually
receive the implicit cast of a CXXConstructor.
Most checks in the dead store analysis were already stripping all casts
and parenthesis and those that weren't were either forgotten (like the
constructor) or would not suffer from it, so this patch proposes to
factorize the stripping.
It has an impact on where the dead store warning is reported in the case
of an explicit cast, from
auto a = static_cast<B>(A());
^~~~~~~~~~~~~~~~~~~
to
auto a = static_cast<B>(A());
^~~
which we think is an improvement.
Patch By: frederic-tingaud-sonarsource
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D126534
Move copying compiler arguments to a vector<string> and modifying
common module-related options into CompilerInvocation in preparation for
using some of them in more places and to avoid duplicating this code
accidentally in the future.
Differential Revision: https://reviews.llvm.org/D132419
Summary:
The buildbots are giving failures on the explicit move operations here.
Previously I had problems where not perfomring an explicit move would
cause problems with older compilers so we'll see if this works as
expected.
MSVC allows interpreting volatile loads and stores, when combined with
/volatile:iso, as having acquire/release semantics. MSVC also exposes a
define, _ISO_VOLATILE, which allows users to enquire if this feature is
enabled or disabled.
Putting "simulator" in the `-target` flag requires putting it in the
"environment" part of the triple, which is the 4th `-`-separated component.
Some places in the tests currently use "iossimulator" which puts it in the
OS field. The triple parsing code in llvm::Triple uses startswith("ios")
in parseOS(), so that successfully sets the OS to "iOS", and all these
triples use an intel arch, and iOS + intel triple implicitly make the
driver convert the environment to "simulator", so this happened to work --
but it led to the somewhat strange "simulator-simulator" in the diag
in the test.
No behavior change.
Differential Revision: https://reviews.llvm.org/D132399
I added this recently, but it looks like several tests very intentionally
check that `-mios-version-min=foo --target=x86_64-apple-ios` does simulator
builds. So we can't easily remove this hack, even though it makes little
sense in an arm mac world. (Here, you _have_ to say
`-mios-simulator-version-min=` or `--target=arm64-apple-ios-simulator`.)
The tests that check this:
Clang :: Driver/darwin-ld.c
Clang :: Driver/darwin-simulator-macro.c
Clang :: Driver/darwin-version.c
No behavior change.
Differential Revision: https://reviews.llvm.org/D132400
This commit reverts the following commits:
- 952f90b72b
- e6a0800532 (D132298)
- 176db3b3ab (D132324)
These commits caused CI instability and need to be reverted in order
to figure things out again. See the discussion in https://llvm.org/D132324
for more information.
Summary:
Some older compilers cannot automatically elide the returned vector of
unique pointers, causing build errors. This patch explicitly moves the
returned value instead which should solve the problem.
We use the `clang-offload-packager` too bundle many files into a single
binary format containing metadata. This is used for offloading
compilation which may contain multiple device binaries of different
types and architectures in a single file. We use this special binary
format to store these files along with some necessary metadata around
them. We use this format because of the difficulty of determining the
filesize of the various binary inputs that will be passed to the
offloading toolchain rather than engineering a solution for each input.
Previously we only support packaing many files into a single binary.
This patch adds support for doing the reverse by using the same
`--image=` syntax. To unpackage a binary we now present an input file
instead of an output.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D129507
Previously when I wrote this document, I felt the completed scripts was
lengthy, redundant and not easy to read. So I didn't add complete
examples in the previous commit.
However, in the recent discussion with @avogelsgesang, I found people
may not know how to use debugging scripts to improve their debugging
efficiency. So now, I feel like it is helpful to put the examples even
if they are a little bit long.
Test Plan: make docs-clang-html
Reviewed By: avogelsgesang
Differential Revision: https://reviews.llvm.org/D132451
A FriendDecl node can have a friend record type that owns a RecordDecl
object. This object is different than the one got from TypeSourceInfo
object of the FriendDecl. When building a ParentMapContext this owned
tag decaration has to be encountered to have the parent set for it.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D131685
With the initial support added, clang can compile `helloworld` C
to executable file for loongarch64. For example:
```
$ cat hello.c
int main() {
printf("Hello, world!\n");
return 0;
}
$ clang --target=loongarch64-unknown-linux-gnu --gcc-toolchain=xxx --sysroot=xxx hello.c
```
The output a.out can run within qemu or native machine. For example:
```
$ file ./a.out
./a.out: ELF 64-bit LSB pie executable, LoongArch, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-loongarch-lp64d.so.1, for GNU/Linux 5.19.0, with debug_info, not stripped
$ ./a.out
Hello, world!
```
Currently gcc toolchain and sysroot can be found here:
https://github.com/loongson/build-tools/releases/download/2022.08.11/loongarch64-clfs-5.1-cross-tools-gcc-glibc.tar.xz
Reference: https://github.com/loongson/LoongArch-Documentation
The last commit hash (main branch) is:
99016636af64d02dee05e39974d4c1e55875c45b
Note loongarch32 is not fully tested because there is no reference
gcc toolchain yet.
Differential Revision: https://reviews.llvm.org/D130255
For bootstrap builds (CLANG_ENABLE_BOOTSTRAP=ON) allow
arguments to be passed to the native tool used in CMake
for the stage2 step.
Can be used to pass extra arguments for enhanced versions
of build tools, e.g. distributed build options.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D131665
Since we have enabled the support for `_Float16` on SSE2, we can relax
the limitation for AVX512FP16 now. This helps for user to use AVX512FP16
mixed with unsupported versions, e.g., multiversioning.
Also fix lit fails due to missing const modifier. Found during this change.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D132342
This patch introduces new option `-eager-load-pcm` to `clang-scan-deps`, which controls whether the resulting command-lines will load PCM files eagerly (at the start of compilation) or lazily (when handling import directive). This patch also switches the default from eager to lazy.
To reduce the potential for churn in LIT tests in the future, this patch also removes redundant checks of command-line arguments and introduces new test `modules-dep-args.c` as a substitute.
Reviewed By: benlangmuir
Differential Revision: https://reviews.llvm.org/D132066
libc++ prior to LLVM 15 has a bug in it due to it excluding
`remove_reference_t` when `__remove_reference` is available as a
compiler built-in. This went unnoticed until D116203 because it wasn't
available in any compiler.
To work around this, we're renaming `__remove_reference` to
`__remove_reference_t`.
TEST=Tested locally, tested using emscripten
Fixes https://github.com/llvm/llvm-project/issues/55804
The lexing order is already bookkept in DelayedCXXInitPosition but we
were not using it based on the wrong assumption that inline variable is
unordered. This patch fixes it by ordering entries in llvm.global_ctors
by orders in DelayedCXXInitPosition.
for llvm.global_ctors entries without a lexing order, ordering them by
the insertion order.
(This *mostly* orders the template instantiation in
https://reviews.llvm.org/D126341 intuitively, minus one tweak for which I'll
submit a separate patch.)
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D127233
This keeps clang compatible with MSVC defines for the FP environment.
These defines are used by the CRT and other libraries to interrogate
what to expect. Perhaps most importantly, they feed into the definition
of float_t and double_t which may result in ODR violations between MSVC
and clang.
They were mapped as follows:
- /fp:except to --ftrapping-math
- /fp:except- to --fno-trapping-math
- /fp:strict to --fno-fast-math
- /fp:precise to --fno-fast-math
Let's map them as follows:
- /fp:except to --ffp-exception-behavior=strict
- /fp:except- to --ffp-exception-behavior=ignore
- /fp:strict to --ffp-model=strict
- /fp:precise to --ffp-model=ignore
I believe the changes to /fp:except are technically a no-op but it makes
the mapping a lot clearer. The changes for /fp:strict and /fp:precise are not
no-ops, they now match MSVC's behavior.
While we are here, also add support for /fp:contract by mapping it to
-ffp-contract=on.
This patch does the following:
- Consumes the PIC flags (fPIC/fPIE/fropi/frwpi etc) in flang-new.
tools::ParsePICArgs() in ToolChains/CommonArgs.cpp is used for this.
- Adds FC1Option to "-mrelocation-model", "-pic-level", and "-pic-is-pie"
command line options.
- Adds the above options to flang/Frontend/CodeGenOptions' data structure.
- Sets the relocation model in the target machine, and
- Sets module flags for the respective PIC/PIE type in LLVM IR.
I have tried my best to replicate how clang does things.
Differential Revision: https://reviews.llvm.org/D131533
Change-Id: I68fe64910be28147dc5617826641cea71b92d94d
In preparation for allowing the prefer_type list in the append_args clause,
use the OMPInteropInfo in the attribute for 'declare variant'.
This requires adding a new Argument kind to the attribute code. This change
adds a specific attribute to pass an array of OMPInteropInfo. It implements
new tablegen needed to handle the interop-type part of the structure. When
prefer_type is added, more work will be needed to dump, instantiate, and
serialize the PreferTypes field in OMPInteropInfo.
Differential Revision: https://reviews.llvm.org/D132270
Before this patch, open-source clang would consider
`-target x86_64-apple-darwin -mios-simulator-version-min=11.0` as
targeting the iOS simulator, due to the mios flag informing it
that we want to target iOS, and logic in the driver then realizing
that x86 iOS builds must be the simulator.
However, for `-target arm64-apple-darwin -mios-simulator-version-min=11.0`
that didn't work and clang thought that it's building for actual iOS,
and not for the simulator.
Due to this, building compiler-rt for arm64 iossim would lead to
all .o files in RTSanitizerCommonSymbolizer.iossim.dir being built
for iOS instead of for iOS simulator, and clang would ask ld64 to
link for iOS, but using the iPhoneSimulator sysroot. This would then
lead to many warnings from ld64 looking like:
ld: warning: building for iOS, but linking in .tbd file
(.../iPhoneSimulator.sdk/usr/lib/libc++abi.tbd) built for iOS Simulator
Worse, with ld64.lld, this diagnostic is currently an error instead
of a warning.
This patch makes it so that the presence of -mios-simulator-version-min=
now informs clang that we're building for simulator. That way, all the
.o files are built for simulator, the linker is informed that we're
building for simulator, and everything Just Works.
(Xcode's clang already behaves like this, so this makes open-source clang
match Xcode clang.)
We can now likely remove the hack to treat non-mac darwin x86 as
simulator, but doing that feels slightly risky, so I'm leaving that
for a follow-up patch.
(This patch is made necessary by the existence of arm64 macs.)
Differential Revision: https://reviews.llvm.org/D132258
It was originally left off thinking the paper only impacts the C
standard library, but Clang supports diagnostics for incorrect use of
a format specifier, so this paper has some frontend impacts as well.
This patch makes it possible for lambdas, implicit copy/move ctors
and structured bindings to handle non-POD multidimensional arrays.
Differential Revision: https://reviews.llvm.org/D131840
Prior to this patch we handled lambda captures based on their
initializer expression, which resulted in pattern matching. With
C++17 copy elision the initializer expression can be anything,
and this approach proved to be fragile and a source of crashes.
This patch removes pattern matching and only checks whether the
object is under construction or not.
Differential Revision: https://reviews.llvm.org/D131944
Adds
* `__add_lvalue_reference`
* `__add_pointer`
* `__add_rvalue_reference`
* `__decay`
* `__make_signed`
* `__make_unsigned`
* `__remove_all_extents`
* `__remove_extent`
* `__remove_const`
* `__remove_volatile`
* `__remove_cv`
* `__remove_pointer`
* `__remove_reference`
* `__remove_cvref`
These are all compiler built-in equivalents of the unary type traits
found in [[meta.trans]][1]. The compiler already has all of the
information it needs to answer these transformations, so we can skip
needing to make partial specialisations in standard library
implementations (we already do this for a lot of the query traits). This
will hopefully improve compile times, as we won't need use as much
memory in such a base part of the standard library.
[1]: http://wg21.link/meta.trans
Co-authored-by: zoecarver
Reviewed By: aaron.ballman, rsmith
Differential Revision: https://reviews.llvm.org/D116203
This has been officially deprecated since D112724, meaning the
deprecation warning is present in released 14 and 15.
This makes me think that now, shortly after the 15 release is branched,
is a good time to pull the trigger.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D132324
This adds a check for exported inline functions, that there is a definition in
the definition domain (which, in practice, can only be the module purview but
before any PMF starts) since the PMF definition domain cannot contain exports.
This is:
[dcl.inline]/7
If an inline function or variable that is attached to a named module is declared in
a definition domain, it shall be defined in that domain.
The patch also amends diagnostic output by excluding the PMF sub-module from the
set considered as sources of missing decls. There is no point in telling the user
that the import of a PMF object is missing - since such objects are never reachable
to an importer. We still show the definition (as unreachable), to help point out
this.
Differential Revision: https://reviews.llvm.org/D128328
Use this instead of `*_LIBDIR_SUFFIX`, from which it is computed.
This gets us ready for D130586, in which `*_LIBDIR_SUFFIX` is
deprecated.
Differential Revision: https://reviews.llvm.org/D132300
Adds a builtin that serves as an optimization hint to apply specific optimized
DAG mutations during scheduling. This also disables any other mutations or
clustering that may interfere with the desired pipeline. The first optimization
strategy that is added here is designed to improve the performance of small gemm
kernels on gfx90a.
Reviewed By: jrbyrnes
Differential Revision: https://reviews.llvm.org/D132079
Currently ExtractAPI only emits availability information for the
current platform. This makes it easy for clients to get all availability
information for a given symbol in one invocation as opposed to having to invoke
clang once per-platform and then merge the symbol-graphs.
Differential Revision: https://reviews.llvm.org/D130918
This reverts commit d483730d8c.
This allegedly breaks a significant part of facebooks internal build.
Reverting while we wait for them to provide a reproducer of this from
@wlei.
The hard float ABIs have a rule that if a flattened struct contains
either a single fp value, or an int+fp, or fp+fp then it may be passed
in a pair of registers (if sufficient GPRs+FPRs are available).
detectFPCCEligibleStruct and the helper it calls,
detectFPCCEligibleStructHelper examine the type of the argument/return
value to determine if it complies with the requirements for this ABI
rule.
As reported in bug #57084, this logic produces incorrect results for C++
structs that inherit from other structs. This is because only the fields
of the struct were examined, but enumerating RD->fields misses any
fields in inherited C++ structs. This patch corrects that issue by
adding appropriate logic to enumerate any included base structs.
Differential Revision: https://reviews.llvm.org/D131677
This patch adds a ProgramPointTag to the EpsilonPoint created
before we replay a call without inlining.
Differential Revision: https://reviews.llvm.org/D132246
The patch mainly focuses on the no warnings for -Wtautological-compare.
It work fine for the positive numbers but doesn't for the negative
numbers. This is because the warning explicitly checks for an
IntegerLiteral AST node, but -1 is represented by a UnaryOperator with
an IntegerLiteral sub-Expr.
Fixes#42918
Differential Revision: https://reviews.llvm.org/D130510
Implement negating and inverting values. Also implement
IntegralToBoolean casts so the operations are easier to test.
Differential Revision: https://reviews.llvm.org/D132098
Certain idioms are ignored by -Wunused in header files only.
The current "is a header" check assumes that if headers are the main file, we're
building a PCH or a module or something. However in tools we may be parsing the
header in its own right, but still want to treat it as a header.
Fixes https://github.com/clangd/vscode-clangd/issues/360
Differential Revision: https://reviews.llvm.org/D129642
This patch replaces svget, svset and svcreate aarch64 intrinsics for tuple
types with the generic llvm-ir intrinsics extract/insert vector
Differential Revision: https://reviews.llvm.org/D131547
Fix for the problem with displaying options `-fsyntax-only` in clang and flang-new in help
Fix https://github.com/llvm/llvm-project/issues/57033
Before:
``` $ clang -help | grep syntax
-objcmt-migrate-property-dot-syntax
Enable migration of setter/getter messages to property-dot syntax
```
After:
```
$ clang -help | grep syntax
-fsyntax-only Run the preprocessor, parser and semantic analysis stages
-objcmt-migrate-property-dot-syntax
Enable migration of setter/getter messages to property-dot syntax
```
Reviewed By: vzakhari, awarzynski, MaskRay, alexiprof
Differential Revision: https://reviews.llvm.org/D131808
The commit of af2d11b1d5 missed a case where
the value of a suggested module needed to be reset to nullptr. Fixed thus
and added a testcase to cover the circumstance.
Instead of complaining about default initialization, tell users that
constexpr variables need to be initialized by a constant expression.
Differential Revision: https://reviews.llvm.org/D131662
Owing to the large number of instantiations of this function, this small
change has a small but meaningful difference on the total size of
(especially a debug) build of clang at -O0:
```
FILE SIZE VM SIZE
-------------- --------------
+0.9% +96.9Ki +0.9% +96.9Ki .data.rel.ro
+0.7% +96.7Ki +0.7% +96.7Ki .rela.dyn
+0.0% +18.3Ki +0.0% +18.3Ki .rodata
+0.0% +324 [ = ] 0 [2 Others]
-0.2% -392 -0.2% -392 .gnu.version
-0.0% -441 [ = ] 0 .debug_abbrev
-0.1% -980 -0.1% -980 .gnu.hash
-0.2% -1.53Ki -0.2% -1.53Ki .hash
-0.2% -4.59Ki -0.2% -4.59Ki .dynsym
-0.1% -10.5Ki [ = ] 0 .debug_rnglists
-0.6% -59.0Ki -0.6% -59.0Ki .dynstr
-0.2% -191Ki [ = ] 0 .debug_str_offsets
-3.0% -233Ki -3.0% -233Ki .eh_frame_hdr
-0.7% -244Ki [ = ] 0 .debug_addr
-2.9% -699Ki [ = ] 0 .symtab
-0.6% -884Ki [ = ] 0 .debug_line
-3.0% -932Ki -3.0% -932Ki .eh_frame
-1.0% -1.48Mi -1.0% -1.48Mi .text
-0.6% -2.75Mi [ = ] 0 .debug_info
-7.3% -8.61Mi [ = ] 0 .strtab
-7.3% -17.2Mi [ = ] 0 .debug_str
-2.4% -33.0Mi -0.9% -2.47Mi TOTAL
```
If anyone's got other ideas for how to reduce this further - it's not
especially important, I just came across it while investigating a debug
info size regression, but thought it was interesting enough to poke
around at.
Currently, record arguments are always passed by reference by allocating
space for record values in the caller. This is less efficient for
small records which may take one or two registers. For example,
for x86_64 and aarch64, for a record size up to 16 bytes, the record
values can be passed by values directly on the registers.
This patch added BPF support of record argument with direct values
for up to 16 byte record size. If record size is 0, that record
will not take any register, which is the same behavior for x86_64
and aarch64. If the record size is greater than 16 bytes, the
record argument will be passed by reference.
Differential Revision: https://reviews.llvm.org/D132144
The 'init' clause allows an interop-modifier of prefer_type(list) and
and interop-types 'target' and 'targetsync'.
The 'append_args' clause uses an append-op that also includes
interop-types ('target' and 'targetsync') and will allow
a prefer_type list in the next OpenMP version.
This change adds a helper struct OMPInteropInfo and uses it in the parsing
of both the 'init' and 'append_args' clauses.
One OMPInteropInfo object represents the info in a single 'init' clause.
Since 'append_args' allows a variable number of interop items it will
require an array of OMPInteropInfo objects once that is supported.
Differential Revision: https://reviews.llvm.org/D132171
Using Max for both "PIC Level" and "PIE Level" is inconsistent. PIC imposes less
restriction while PIE imposes more restriction. The result generally
picks the more restrictive behavior: Min for PIC.
This choice matches `ld -r`: a non-pic object and a pic object merge into a
result which should be treated as non-pic.
To allow linking "PIC Level" using Error/Max from old bitcode files, upgrade
Error/Max to Min.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D130531
The previous implementation translated from names like sifive-7-series
to sifive-7-rv32 or sifive-7-rv64. This also required sifive-7-rv32
and sifive-7-rv64 to be valid CPU names. As those are not real
CPUs it doesn't make sense to accept them in -mcpu.
This patch does away with the translation and adds sifive-7-series
directly to RISCV.td. Removing sifive-7-rv32 and sifive-7-rv64.
sifive-7-series is only allowed in -mtune.
I've also added "rocket" to RISCV.td but have not removed rocket-rv32
or rocket-rv64.
To prevent -mcpu=sifive-7-series or -mcpu=rocket being used with llc,
I've added a Feature32Bit to all rv32 CPUs. And made it an error to
have an rv32 triple without Feature32Bit. sifive-7-series and rocket
do not have Feature32Bit or Feature64Bit set so the user would need
to provide -mattr=+32bit or -mattr=+64bit along with the -mcpu to
avoid the error.
SiFive no longer names their newer products with 3, 5, or 7 series.
Instead we have p200 series, x200 series, p500 series, and p600 series.
Following the previous behavior would require a sifive-p500-rv32 and
sifive-p500-rv64 in order to support -mtune=sifive-p500-series. There
is currently no p500 product, but it could start getting confusing if
there was in the future.
I'm open to hearing alternatives for how to achieve my main goal
of removing sifive-7-rv32/rv64 as a CPU name.
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D131708
The DXC driver tests don't really belong mixed in with the toolchain
tests. This pulls them out to their own file and moves the
SimpleDiagnosticConsumer into a header so it can be used by both DXC and
toolchain tests.
fast-forwarded.
Kevin Athey