This fixes a crash in MallocChecker for the situation when operator new (delete) is invoked via NTTP and makes the behavior of CallContext.getCalleeDecl(Expr) identical to CallEvent.getDecl().
Reviewed By: vsavchenko
Differential Revision: https://reviews.llvm.org/D103025
Given an invalid SourceLocation, translateSourceLocation will call
clang_getNullLocation, and then do nothing with the result. But
clang_getNullLocation has no side effects: it just constructs and
returns a null CXSourceLocation value.
Surely the intention was to //return// that null CXSourceLocation to
the caller, instead of throwing it away and pressing on anyway.
Reviewed By: miyuki
Differential Revision: https://reviews.llvm.org/D104442
This implements a more comprehensive fix than was done at D95409.
Instead of excluding just function pointer subobjects, we also
exclude any user-defined function pointer conversion operators.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D103855
The current naming scheme adds the `dfs$` prefix to all
DFSan-instrumented functions. This breaks mangling and prevents stack
trace printers and other tools from automatically demangling function
names.
This new naming scheme is mangling-compatible, with the `.dfsan`
suffix being a vendor-specific suffix:
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-structure
With this fix, demangling utils would work out-of-the-box.
Reviewed By: stephan.yichao.zhao
Differential Revision: https://reviews.llvm.org/D104494
Support -Wno-frame-larger-than (with no =) and make it properly
interoperate with -Wframe-larger-than. Reject -Wframe-larger-than with
no argument.
We continue to support Clang's old spelling, -Wframe-larger-than=, for
compatibility with existing users of that facility.
In passing, stop the driver from accepting and ignoring
-fwarn-stack-size and make it a cc1-only flag as intended.
When creating a PCH file the use of a temp file will be dictated by the
presence or absence of the -fno-temp-file flag. Creating a module file
will always use a temp file via the new ForceUseTemporary flag.
This fixes bug 50033.
Summary:
AIX does not support --as-needed linker options. Remove that option from
aix linker when -lunwind is needed.
For unwinder library, nothing special is needed because by default aix
linker has the as-needed effect for library that's an archive (which is
the case for libunwind on AIX).
Reviewed By: daltenty
Differential Revision: https://reviews.llvm.org/D104314
The library depends on Attributes.inc, so it has to depend on the intrinsics_gen target
Reviewed By: v.g.vassilev
Differential Revision: https://reviews.llvm.org/D104311
Fixed crash when doing pointer math on a void pointer.
Also, reworked test to use -verify rather than FileCheck.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D104424
Template parameters are created in ASTImporter with the translation unit as DeclContext.
The DeclContext is later updated (by the create function of template classes).
ASTImporterLookupTable was not updated after these changes of the DC. The patch
adds update of the DeclContext in ASTImporterLookupTable.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D103792
D66572 separated BugReport and BugReporter into basic and path sensitive
versions. As a result, checker silencing, which worked deep in the path
sensitive report generation facilities became specific to it. DeadStoresChecker,
for instance, despite being in the static analyzer, emits non-pathsensitive
reports, and was impossible to silence.
This patch moves the corresponding code before the call to the virtual function
generateDiagnosticForConsumerMap (which is overriden by the specific kinds of
bug reporters). Although we see bug reporting as relatively lightweight compared
to the analysis, this will get rid of several steps we used to throw away.
Quoting from D65379:
At a very high level, this consists of 3 steps:
For all BugReports in the same BugReportEquivClass, collect all their error
nodes in a set. With that set, create a new, trimmed ExplodedGraph whose leafs
are all error nodes.
Until a valid report is found, construct a bug path, which is yet another
ExplodedGraph, that is linear from a given error node to the root of the graph.
Run all visitors on the constructed bug path. If in this process the report got
invalidated, start over from step 2.
Checker silencing used to kick in after all of these. Now it does before any of
them :^)
Differential Revision: https://reviews.llvm.org/D102914
Change-Id: Ice42939304516f2bebd05a1ea19878b89c96a25d
This can be seen as a follow up to commit 0ee439b705,
that changed the second argument of __powidf2, __powisf2 and
__powitf2 in compiler-rt from si_int to int. That was to align with
how those runtimes are defined in libgcc.
One thing that seem to have been missing in that patch was to make
sure that the rest of LLVM also handle that the argument now depends
on the size of int (not using the si_int machine mode for 32-bit).
When using __builtin_powi for a target with 16-bit int clang crashed.
And when emitting libcalls to those rtlib functions, typically when
lowering @llvm.powi), the backend would always prepare the exponent
argument as an i32 which caused miscompiles when the rtlib was
compiled with 16-bit int.
The solution used here is to use an overloaded type for the second
argument in @llvm.powi. This way clang can use the "correct" type
when lowering __builtin_powi, and then later when emitting the libcall
it is assumed that the type used in @llvm.powi matches the rtlib
function.
One thing that needed some extra attention was that when vectorizing
calls several passes did not support that several arguments could
be overloaded in the intrinsics. This patch allows overload of a
scalar operand by adding hasVectorInstrinsicOverloadedScalarOpd, with
an entry for powi.
Differential Revision: https://reviews.llvm.org/D99439
Fixes PR50591.
When analyzing classes with members which have user-defined conversion
operators to builtin types, the defaulted comparison analyzer was
picking the member type instead of the type for the builtin operator
which was selected as the best match.
This could either result in wrong comparison category being selected,
or a crash when runtime checks are enabled.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D103760
This expands NRVO propagation for more cases:
Parse analysis improvement:
* Lambdas and Blocks with dependent return type can have their variables
marked as NRVO Candidates.
Variable instantiation improvements:
* Fixes crash when instantiating NRVO variables in Blocks.
* Functions, Lambdas, and Blocks which have auto return type have their
variables' NRVO status propagated. For Blocks with non-auto return type,
as a limitation, this propagation does not consider the actual return
type.
This also implements exclusion of VarDecls which are references to
dependent types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: Quuxplusone
Differential Revision: https://reviews.llvm.org/D99696
Currently, `access` doesn't recognize a dereferenced smart pointer. So,
`access(e, "field")` where `e = *x`, yields:
* `x->field`, for normal-pointer x,
* `(*x).field`, for smart-pointer x.
This patch normalizes handling of smart pointer to match normal pointer, when
the smart pointer type supports `->`.
Differential Revision: https://reviews.llvm.org/D104390
Currently, `hasUnaryOperand` fails for the overloaded `operator*`. This patch fixes the bug and
adds tests for this case.
Differential Revision: https://reviews.llvm.org/D104389
When using FileIndexRecord with macros, symbol references can be seen
out of source order, which was causing a regression to insert the
symbols into a vector. Instead, we now lazily sort the vector. The
impact is small on most code, but in very large files with many macro
references (M) near the beginning of the file followed by many decl
references (D) it was O(M*D). A particularly bad protobuf-generated
header was observed with a 100% regression in practice.
rdar://78628133
Currently, the implementation combines OOP and overloads, using a template to
tie the two together. In practice, this has proven confusing with no
benefits. This patch simplifies the code to use standard OOP design (a
collection of classes deriving from an interface).
Differential Revision: https://reviews.llvm.org/D104317
The new option will run the semantic checks and then dump the parse tree
and all the symbols. This is equivalent to running the driver twice,
once with `-fdebug-dump-parse-tree` and then with
the `-fdebug-dump-symbols` action flag.
Currently we wouldn't be able to achieve the same by simply running:
```
flang-new -fc1 -fdebug-dump-parse-tree -fdebug-dump-symbols <input-file>
```
That's because the new driver will only run one frontend action per
invocation (both of the flags used here are action flags). Diverging
from this design would lead to costly compromises and it's best avoided.
We may want to consider re-designing our debugging actions (and action
options) in the future so that there's more code re-use. For now, I'm
focusing on making sure that we support all the major cases requested by
our users.
Differential Revision: https://reviews.llvm.org/D104305
Moving the definition of the defineXLCompatMacros function from
the header file clang/lib/Basic/Targets/PPC.h to the source file
clang/lib/Basic/Targets/PPC.cpp.
Differential revision: https://reviews.llvm.org/D104125
Addition of this pass has been botched.
There is no particular reason why it had to be sold as an inseparable part
of new-pm transition. It was added when old-pm was still the default,
and very *very* few users were actually tracking new-pm,
so it's effects weren't measured.
Which means, some of the turnoil of the new-pm transition
are actually likely regressions due to this pass.
Likewise, there has been a number of post-commit feedback
(post new-pm switch), namely
* https://reviews.llvm.org/D37467#2787157 (regresses HW-loops)
* https://reviews.llvm.org/D37467#2787259 (should not be in middle-end, should run after LSR, not before)
* https://reviews.llvm.org/D95789 (an attempt to fix bad loop backedge metadata)
and in the half year past, the pass authors (google) still haven't found time to respond to any of that.
Hereby it is proposed to backout the pass from the pipeline,
until someone who cares about it can address the issues reported,
and properly start the process of adding a new pass into the pipeline,
with proper performance evaluation.
Furthermore, neither google nor facebook reports any perf changes
from this change, so i'm dropping the pass completely.
It can always be re-reverted should/if anyone want to pick it up again.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D104099
The initial scan occurring before the watcher is ready allows a race
condition where a change occurs before the initial scan completes.
Ensure that we wait for the watcher to begin executing the initial scan.
Addresses some feedback from Adrian McCarthy in post-commit review.
This has already been implemented in be2277fbf2 which adds
pragma fp support. This patch just adds test coverage for
regular fast-math flags (PR46165).
Need to capture locals in aligned clauses for the combined directives to
be fix the crash in the codegen.
Differential Revision: https://reviews.llvm.org/D104258
One interesting problem was discovered here. When we do interrupt
Tracker's track flow, we want to interrupt only it and not all the
other flows recursively.
Differential Revision: https://reviews.llvm.org/D103914
21c18d5a04
improved the detection of multiplication in function call argument lists,
but unintentionally regressed the handling of function type casts (there
were no tests covering those).
This patch improves the detection of function type casts and adds a few tests.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D104209
A lambda in a function template may be recursively instantiated. The recursive
lambda will cause a lambda function instantiated multiple times, one inside another.
The inner LocalInstantiationScope should not be marked as MergeWithParentScope
since it already has references to locals properly substituted, otherwise it causes
assertion due to the check for duplicate locals in merged LocalInstantiationScope.
Reviewed by: Richard Smith
Differential Revision: https://reviews.llvm.org/D98068
Added support for CXXRewrittenBinaryOperator as a condition in ranged
for loops. This is a new kind of expression, need to extend support for
C++20 constructs.
It fixes PR49970: range-based for compilation fails for libstdc++ vector
with -std=c++20.
Differential Revision: https://reviews.llvm.org/D104240
The parser code assumes building with C++ compiler and asserts when using clang (not clang++) on C file. I made the code dependent on input language. This shows up for amdgpu target.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D103899
This change caused build errors related to move-only __block variables,
see discussion on https://reviews.llvm.org/D99696
> This expands NRVO propagation for more cases:
>
> Parse analysis improvement:
> * Lambdas and Blocks with dependent return type can have their variables
> marked as NRVO Candidates.
>
> Variable instantiation improvements:
> * Fixes crash when instantiating NRVO variables in Blocks.
> * Functions, Lambdas, and Blocks which have auto return type have their
> variables' NRVO status propagated. For Blocks with non-auto return type,
> as a limitation, this propagation does not consider the actual return
> type.
>
> This also implements exclusion of VarDecls which are references to
> dependent types.
>
> Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
>
> Reviewed By: Quuxplusone
>
> Differential Revision: https://reviews.llvm.org/D99696
This also reverts the follow-on change which was hard to tease apart
form the one above:
> "[clang] Implement P2266 Simpler implicit move"
>
> This Implements [[http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2266r1.html|P2266 Simpler implicit move]].
>
> Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
>
> Reviewed By: Quuxplusone
>
> Differential Revision: https://reviews.llvm.org/D99005
This reverts commits 1e50c3d785 and
bf20631782.
The dependency scanning worker uses `std::move` to "reset" `DependencyOutputOptions` in the `CompilerInstance` that performs the implicit build. It's probably preferable to replace the object with value-initialized instance, rather than depending on the behavior of a moved-from object.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D104106
There's no need to pass `DependencyOutputOptions` to each call of `handleFileDependency`, since the options don't ever change.
This patch adds new `handleDependencyOutputOpts` method to the `DependencyConsumer` interface and the dependency scanner uses it to report the options only once.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D104104
The `sed` command ensures Windows-specific path separators (single and double backslashes) are replaced by forward slashes in the output file. FileCheck can continue using forward slashes in paths this way.
One of the goals of the dependency scanner is to generate command-lines that can be used to explicitly build modular dependencies of a translation unit. The only modifications to these command-lines should be for the purposes of explicit modular build.
However, the current version of dependency scanner leaks its implementation details into the command-lines.
The first problem is that the `clang-scan-deps` tool adjusts the original textual command-line (adding `-Eonly -M -MT <target> -sys-header-deps -Wno-error -o /dev/null `, removing `--serialize-diagnostics`) in order to set up the `DependencyScanning` library. This has been addressed in D103461, D104012, D104030, D104031, D104033. With these patches, the `DependencyScanning` library receives the unmodified `CompilerInvocation`, sets it up and uses it for the implicit modular build.
Finally, to prevent leaking the implementation details to the resulting command-lines, this patch generates them from the **original** unmodified `CompilerInvocation` rather than from the one that drives the implicit build.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D104036
The `clang-scan-deps` tests for the full output format were written under the assumption that most TUs/modules have the same context hash. This is no longer true, since we're changing the original compilation options. This patch updates the tests, which no longer conflate multiple context hashes into a single FileCheck variable.
Commit d8bab69ead updated the ClangScanDeps/modules.cpp test. The new `{{.*}}` regex is supposed to only match `modules_cdb_input.o`, `a.o` or `b.o`. However, due to non-determinism, this can sometimes also match `modules_cdb_input2.o`, causing match failure on the next line. This commit changes the regex to only match one of the three valid cases.
Buildbot failure: https://lab.llvm.org/buildbot/#/builders/109/builds/16675
This patch moves enabling system header deps from `clang-scan-deps` into the `DependencyScanning` library. This will make it easier to preserve semantics of the original TU command-line for modular dependencies (see D104036).
Reviewed By: arphaman
Differential Revision: https://reviews.llvm.org/D104033
This moves another piece of logic specific to `clang-scan-deps` into the `DependencyScanning` library. This makes it easier to check how the original command-line looked like in the library and will enable the library to stop inventing `-Wno-error` for modular dependencies (see D104036).
Reviewed By: arphaman
Differential Revision: https://reviews.llvm.org/D104031
The `clang-scan-deps` tool has some logic that parses and modifies the original Clang command-line. The goal is to setup `DependencyOutputOptions` by injecting `-M -MT <target>` and prevent the creation of output files.
This patch moves the logic into the `DependencyScanning` library, and uses the parsed `CompilerInvocation` instead of the raw command-line. The code simpler and can be used from the C++ API as well.
The `-o /dev/null` arguments are not necessary, since the `DependencyScanning` library only runs a preprocessing action, so there's no way it'll produce an actual object file.
Related: The `-M` argument implies `-w`, which would appear on the command-line of modular dependencies even though it was not on the original TU command line (see D104036).
Some related tests were updated.
Reviewed By: arphaman
Differential Revision: https://reviews.llvm.org/D104030
To prevent the creation of diagnostics file, `clang-scan-deps` strips the corresponding command-line argument. This behavior is useful even when using the C++ `DependencyScanner` library.
This patch transforms stripping of command-line in `clang-scan-deps` into stripping of `CompilerInvocation` in `DependencyScanning`.
AFAIK, the `clang-cl` driver doesn't even accept `--serialize-diagnostics`, so I've removed the test. (It would fail with an unknown command-line argument otherwise.)
Note: Since we're generating command-lines for modular dependencies from `CompilerInvocation`, the `--serialize-diagnostics` will be dropped. This was already happening in `clang-scan-deps` before this patch, but it will now happen also when using `DependencyScanning` library directly. This is resolved in D104036.
Reviewed By: dexonsmith, arphaman
Differential Revision: https://reviews.llvm.org/D104012
Update `setConstraint` to simplify existing equivalence classes when a
new constraint is added. In this patch we iterate over all existing
equivalence classes and constraints and try to simplfy them with
simplifySVal. This solves problematic cases where we have two symbols in
the tree, e.g.:
```
int test_rhs_further_constrained(int x, int y) {
if (x + y != 0)
return 0;
if (y != 0)
return 0;
clang_analyzer_eval(x + y == 0); // expected-warning{{TRUE}}
clang_analyzer_eval(y == 0); // expected-warning{{TRUE}}
return 0;
}
```
Differential Revision: https://reviews.llvm.org/D103314
When a translation unit uses a PCH and imports the same modules as the PCH, we'd prefer to resolve to those modules instead of inventing new modules and reporting them as modular dependencies. Since the PCH modules have already been built nudge the compiler to reuse them when deciding whether to build a new module and don't report them as regular modular dependencies.
Depends on D103524 & D103802.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D103526
The `PreprocessOnlyAction` doesn't support loading the AST file of a precompiled header. This is problematic for dependency scanning, since the `#include` manufactured for the PCH is treated as textual. This means the PCH contents get scanned with each TU, which is redundant. Moreover, dependencies of the PCH end up being considered dependency of the TU.
To handle AST file of PCH properly, this patch creates new `FrontendAction` that behaves the same way `PreprocessorOnlyAction` does, but treats the manufactured PCH `#include` as a normal compilation would (by not claiming it only uses a preprocessor and creating the default AST consumer).
The AST file is now reported as a file dependency of the TU.
Depends on D103519.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D103524
It's useful to be able to load explicitly-built PCH files into an implicit build (e.g. during dependency scanning). That's currently impossible, since the explicitly-built PCH has an empty modules cache path, while the current compilation has (and needs to have) a valid path, triggering an error in the `PCHValidator`.
This patch adds a preprocessor option and command-line flag that can be used to omit this check.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D103802
This patch stops adjusting the frontend action when `clang-scan-deps` is configured to use the full output format.
In a future patch, the dependency scanner needs to check whether the original compiler invocation builds a PCH. That's impossible when `-Eonly` et al. override `-emit-pch`.
The `-Eonly` flag is not needed - the dependency scanner explicitly sets up its own frontend action anyways.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D103461
At least LibreOffice has, for mainly historic reasons that would be hard to
change now, a class Any with an overloaded operator >>= that semantically does
not assign to the LHS but rather extracts into the (by-reference) RHS. Which
thus caused false positive -Wunused-but-set-parameter and
-Wunused-but-set-variable after those have been introduced recently.
This change is more conservative about the assumed semantics of overloaded
operators, excluding compound assignment operators but keeping plain operator =
ones. At least for LibreOffice, that strikes a good balance of not producing
false positives but still finding lots of true ones.
(The change to the BinaryOperator case in MaybeDecrementCount is necessary
because e.g. the template f4 test code in warn-unused-but-set-variables-cpp.cpp
turns the += into a BinaryOperator.)
Differential Revision: https://reviews.llvm.org/D103949
Ultimately the DirectoryWatcher is not ready until the notifier thread
is also active. Failure to wait for the notifier thread may result in
loss of events. While this is not catastrophic in practice, the tests
are sensitive to this as depending on the thread scheduler, the thread
may fail to being execution before the operations are completed by the
fixture. Running this in a tight loop shows no regressions locally as
previously, but this failure mode was been sighted once on a builder.
This patch addresses a performance issue I noticed when using clang-12 to compile projects of mine. Even though the files weren't too large (around 1k cpp), the compiler was taking more than a minute to compile the source file, much longer than either GCC or MSVC.
Using a profiler it turned out the issue was the isAnyDestructorNoReturn function in CXXRecordDecl. In particular it being recursive, recalculating the property for every invocation, for every field and base class. This showed up in tracebacks in the profiler.
This patch instead adds IsAnyDestructorNoReturn as a Field to the data inside of CXXRecord and updates when a new base class, destructor, or record field member is added.
After this patch the problematic file of mine went from a compile time of 81s, down to 12s.
The patch itself should not change any functionality, just improve performance.
Differential Revision: https://reviews.llvm.org/D104182
This reverts commit 0ec1cf13f2.
Restore the implementation with some minor tweaks:
- Use std::unique_ptr for the path instead of std::vector
* Stylistic improvement as the buffer is already heap allocated, this
just makes it clearer.
- Correct the notification buffer allocation size
* Memory usage fix: we were allocating 4x the computed size
- Correct the passing of the buffer size to RDC
* Memory usage fix: we were reporting 1/4th of the size
- Convert the operation event to auto-reset
* Bug Fix: we never reset the event
- Remove `FILE_NOTIFY_CHANGE_LAST_ACCESS` from RDC events
* Memory usage fix: we never needed this notification
- Fold events for the notification action
* Stylistic improvement to be clear how the events map
- Update comment
* Stylistic improvement to be clear what the RAII controls
- Fix the race condition that was uncovered previously
* We would return from the construction before the watcher thread
began execution. The test would then proceed to begin execution,
and we would miss the initial notifications. We now ensure that the
watcher thread is initialized before we return. This ensures that
we do not miss the initial notifications.
Running the test on a SSD was able to uncover the access pattern. This
now seems to pass reliably where it was previously flaky locally.
This expands NRVO propagation for more cases:
Parse analysis improvement:
* Lambdas and Blocks with dependent return type can have their variables
marked as NRVO Candidates.
Variable instantiation improvements:
* Fixes crash when instantiating NRVO variables in Blocks.
* Functions, Lambdas, and Blocks which have auto return type have their
variables' NRVO status propagated. For Blocks with non-auto return type,
as a limitation, this propagation does not consider the actual return
type.
This also implements exclusion of VarDecls which are references to
dependent types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: Quuxplusone
Differential Revision: https://reviews.llvm.org/D99696
Also:
- add driver test (fsanitize-use-after-return.c)
- add basic IR test (asan-use-after-return.cpp)
- (NFC) cleaned up logic for generating table of __asan_stack_malloc
depending on flag.
for issue: https://github.com/google/sanitizers/issues/1394
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D104076
Check applied to unbounded (incomplete) arrays and pointers to spot
cases where the computed address is beyond the largest possible
addressable extent of the array, based on the address space in which the
array is delcared, or which the pointer refers to.
Check helps to avoid cases of nonsense pointer math and array indexing
which could lead to linker failures or runtime exceptions. Of
particular interest when building for embedded systems with small
address spaces.
This is version 2 of this patch -- version 1 had some testing issues
due to a sign error in existing code. That error is corrected and
lit test for this chagne is extended to verify the fix.
Originally reviewed/accepted by: aaron.ballman
Original revision: https://reviews.llvm.org/D86796
Reviewed By: aaron.ballman, ebevhan
Differential Revision: https://reviews.llvm.org/D88174
Allow the usage of minor version 0, for hip versions
such as 4.0. Change the default values when performing
version checks.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D104062
This adds implementation information for N2607,
clarifies that C17 only resolved defect reports,
and adds -std= information for the different versions.
Check applied to unbounded (incomplete) arrays and pointers to spot
cases where the computed address is beyond the largest possible
addressable extent of the array, based on the address space in which the
array is delcared, or which the pointer refers to.
Check helps to avoid cases of nonsense pointer math and array indexing
which could lead to linker failures or runtime exceptions. Of
particular interest when building for embedded systems with small
address spaces.
This is version 2 of this patch -- version 1 had some testing issues
due to a sign error in existing code. That error is corrected and
lit test for this chagne is extended to verify the fix.
Originally reviewed/accepted by: aaron.ballman
Original revision: https://reviews.llvm.org/D86796
Reviewed By: aaron.ballman, ebevhan
Differential Revision: https://reviews.llvm.org/D88174
Adds the basic instrumentation needed for stack tagging.
Currently does not support stack short granules or TLS stack histories,
since a different code path is followed for the callback instrumentation
we use.
We may simply wait to support these two features until we switch to
a custom calling convention.
Patch By: xiangzhangllvm, morehouse
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D102901
Given `int foo, bar;`, TraverseAST reveals this tree:
TranslationUnitDecl
- foo
- bar
Before this patch, with the TraversalScope set to {foo}, TraverseAST yields:
foo
After this patch it yields:
TranslationUnitDecl
- foo
Also, TraverseDecl(TranslationUnitDecl) now respects the traversal scope.
---
The main effect of this today is that clang-tidy checks that match the
translationUnitDecl(), either in order to traverse it or check
parentage, should work.
Differential Revision: https://reviews.llvm.org/D104071
<string> is currently the highest impact header in a clang+llvm build:
https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html
One of the most common places this is being included is the APInt.h header, which needs it for an old toString() implementation that returns std::string - an inefficient method compared to the SmallString versions that it actually wraps.
This patch replaces these APInt/APSInt methods with a pair of llvm::toString() helpers inside StringExtras.h, adjusts users accordingly and removes the <string> from APInt.h - I was hoping that more of these users could be converted to use the SmallString methods, but it appears that most end up creating a std::string anyhow. I avoided trying to use the raw_ostream << operators as well as I didn't want to lose having the integer radix explicit in the code.
Differential Revision: https://reviews.llvm.org/D103888
Refactor to avoid assignment inside condition by using 'if
(init-decl)'. Also remove some unnecessary braces on a separate
if-nest.
Differential Revision: https://reviews.llvm.org/D104039
This fixes the prioritization of address spaces when choosing a
constructor, stopping them from being considered equally good,
which made the construction of types that could be constructed
by more than one of the constructors.
It does this by preferring the most specific address space,
which is decided by seeing if one of the address spaces is
a superset of the other, and preferring the other.
Fixes: PR50329
Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D102850
The previous implementation would accidentally still sort the individual
named imports, even if the module reference was in a clang-format off
block.
Differential Revision: https://reviews.llvm.org/D104101
Whenever Tracker spawns a visitor that needs to call tracker
back, we have to use TrackingBugReporterVisitor in order to maintain
all the hooks that the checker might've used.
Differential Revision: https://reviews.llvm.org/D103628
This component should not be used directly at this point and it is
simply an implementation detail, that's why StoreSiteFinder is
out of the header file.
Differential Revision: https://reviews.llvm.org/D103624
Additionally, this commit completely removes any uses of
FindLastStoreBRVisitor from the analyzer except for the
one in Tracker.
The next step is actually removing this class altogether
from the header file.
Differential Revision: https://reviews.llvm.org/D103618
This commit moves trackExpressionValue into the Tracker interface
as DefaultExpressionHandler. It still can be split into smaller
handlers, but that can be a future change.
Additionally, this commit doesn't remove the original trackExpressionValue
interface, so it's not too big. One of the next commits will address it.
Differential Revision: https://reviews.llvm.org/D103616
Tracking values through expressions and the stores is fundamental
for producing clear diagnostics. However, the main components
participating in this process, namely `trackExpressionValue` and
`FindLastStoreBRVisitor`, became pretty bloated. They have an
interesting dynamic between them (and some other visitors) that
one might call a "chain reaction". `trackExpressionValue` adds
`FindLastStoreBRVisitor`, and the latter calls `trackExpressionValue`.
Because of this design, individual checkers couldn't affect what's
going to happen somewhere in the middle of that chain. Whether they
want to produce a more informative note or keep the overall tracking
going by utilizing some of the domain expertise. This all lead to two
biggest problems that I see:
* Some checkers don't use it
This should probably never be the case for path-sensitive checks.
* Some checkers incorporated their logic directly into those
components
This doesn't make the maintenance easier, breaks multiple
architecture principles, and makes the code harder to read adn
understand, thus, increasing the probability of the first case.
This commit introduces a prototype for a new interface that will be
responsible for tracking. My main idea here was to make operations
that I want have as a checker developer easy to implement and hook
directly into the tracking process.
Differential Revision: https://reviews.llvm.org/D103605
Since 8866793b4e ("[OpenCL] Add OpenCL builtin test generator",
2021-06-09) there are two emitters in this file, so move the
file-level comment to the appropriate class.
-Wframe-larger-than= is an interesting warning; we can't know the frame
size until PrologueEpilogueInsertion (PEI); very late in the compilation
pipeline.
-Wframe-larger-than= was propagated through CC1 as an -mllvm flag, then
was a cl::opt in LLVM's PEI pass; this meant it was dropped during LTO
and needed to be re-specified via -plugin-opt.
Instead, make it part of the IR proper as a module level attribute,
similar to D103048. Introduce -fwarn-stack-size CC1 option.
Reviewed By: rsmith, qcolombet
Differential Revision: https://reviews.llvm.org/D103928
This expands NRVO propagation for more cases:
Parse analysis improvement:
* Lambdas and Blocks with dependent return type can have their variables
marked as NRVO Candidates.
Variable instantiation improvements:
* Fixes crash when instantiating NRVO variables in Blocks.
* Functions, Lambdas, and Blocks which have auto return type have their
variables' NRVO status propagated. For Blocks with non-auto return type,
as a limitation, this propagation does not consider the actual return
type.
This also implements exclusion of VarDecls which are references to
dependent types.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: Quuxplusone
Differential Revision: https://reviews.llvm.org/D99696
Implementation of the unroll directive introduced in OpenMP 5.1. Follows the approach from D76342 for the tile directive (i.e. AST-based, not using the OpenMPIRBuilder). Tries to use `llvm.loop.unroll.*` metadata where possible, but has to fall back to an AST representation of the outer loop if the partially unrolled generated loop is associated with another directive (because it needs to compute the number of iterations).
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D99459
This patch adds the command line options /permissive and /permissive- to clang-cl. These flags are used in MSVC to enable various /Zc language conformance options at once. In particular, /permissive is used to enable the various non standard behaviour of MSVC, while /permissive- is the opposite.
When either of two command lines are specified they are simply expanded to the various underlying /Zc options. In particular when /permissive is passed it currently expands to:
/Zc:twoPhase- (disable two phase lookup)
-fno-operator-names (disable C++ operator keywords)
/permissive- expands to the opposites of these flags + /Zc:strictStrings (/Zc:strictStrings- does not currently exist). In the future, if any more MSVC workarounds are ever added they can easily be added to the expansion. One is also able to override settings done by permissive. Specifying /permissive- /Zc:twoPhase- will apply the settings from permissive minus, but disables two phase lookup.
Motivation for this patch was mainly parity with MSVC as well as compatibility with Windows SDK headers. The /permissive page from MSVC documents various workarounds that have to be done for the Windows SDK headers [1], when MSVC is used with /permissive-. In these, Microsoft often recommends simply compiling with /permissive for the specified source files. Since some of these also apply to clang-cl (which acts like /permissive- by default mostly), and some are currently implemented as "hacks" within clang that I'd like to remove, adding /permissive and /permissive- to be in full parity with MSVC and Microsofts documentation made sense to me.
[1] https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=msvc-160#windows-header-issues
Differential Revision: https://reviews.llvm.org/D103773
When using the -fno-rtti option of the GCC style clang++, using typeid results in an error. The MSVC STL however kindly provides a define flag called _HAS_STATIC_RTTI, which either enables or disables uses of typeid throughout the STL. By default, if undefined, it is set to 1, enabling the use of typeid.
With this patch, _HAS_STATIC_RTTI is set to 0 when -fno-rtti is specified. This way various headers of the MSVC STL like functional can be consumed without compilation failures.
Differential Revision: https://reviews.llvm.org/D103771
This patch adds the command line option -foperator-names which acts as the opposite of -fno-operator-names. With this command line option it is possible to reenable C++ operator keywords on the command line if -fno-operator-names had previously been passed.
Differential Revision: https://reviews.llvm.org/D103749
This patch changes the ffp-model=precise to enables -ffp-contract=on
(previously -ffp-model=precise enabled -ffp-contract=fast). This is a
follow-up to Andy Kaylor's comments in the llvm-dev discussion
"Floating Point semantic modes". From the same email thread, I put
Andy's distillation of floating point options and floating point modes
into UsersManual.rst
Differential Revision: https://reviews.llvm.org/D74436
Clang will create a global value put in constant memory if an aggregate value
is declared firstprivate in the target device. The symbol name only uses the
name of the firstprivate variable, so symbol name conflicts will occur if the
variable is allowed to have different types through templates. An example of
this behvaiour is shown in https://godbolt.org/z/EsMjYh47n. This patch adds the
mangled type name to the symbol to avoid such naming conflicts. This fixes
https://bugs.llvm.org/show_bug.cgi?id=50642.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D103995
Before this change, CXXDefaultArgExpr would always have
ExprDependence::None. This can lead to issues when, for example, the
inner expression is RecoveryExpr and yet containsErrors() on the default
expression is false.
Differential Revision: https://reviews.llvm.org/D103982
Post-commit feedback for d69c4372bf says the output
may vary between pass managers. This is hopefully a
quick fix, but we might want to investigate how to
better solve this type of problem.
Add a test to verify OpenCL builtin declarations using
OpenCLBuiltins.td.
This test consists of parsing a 60k line generated input file. The
entire test takes about 60s with a debug build on a decent machine.
Admittedly this is not the fastest test, but doesn't seem excessive
compared to other tests in clang/test/Headers (with one of the tests
taking 85s for example).
RFC: https://lists.llvm.org/pipermail/cfe-dev/2021-April/067973.html
Differential Revision: https://reviews.llvm.org/D97869
This change implements new DAG notes GLOBAL_GET/GLOBAL_SET, and
lowering methods for load and stores of reference types from IR
globals. Once the lowering creates the new nodes, tablegen pattern
matches those and converts them to Wasm global.get/set.
Reviewed By: tlively
Differential Revision: https://reviews.llvm.org/D95425
Added --gpu-bundle-output to control bundling/unbundling output of HIP device compilation.
By default preprocessor expansion, llvm bitcode and assembly are unbundled, code objects are
bundled.
Reviewed by: Artem Belevich, Jan Svoboda
Differential Revision: https://reviews.llvm.org/D101630
1. There is no tests for mabi=ilp32e, and my patch covers that.
2. The tests in riscv-abi.c will show default ABI changes for special archs
in the future, especially the arch with the F but without the D extension.
3. The tests in riscv-arch.c will show default arch changes for abi=ilp32,
which is rv32imacfd currently, but it is better to be rv32imac.
And it is also better for abi=ilp32f defaults to arch=imacf.
Reviewed By: MaskRay, luismarques
Differential Revision: https://reviews.llvm.org/D103878
The MathExtras.h header is included purely for the countPopulation() method - by moving this into Sanitizers.cpp we can remove the use of this costly header.
We only ever use isPowerOf2() / countPopulation() inside asserts so this shouldn't have any performance effects on production code.
Differential Revision: https://reviews.llvm.org/D103953
Add a new clang-tblgen flag `-gen-clang-opencl-builtin-tests` that
generates a .cl file containing calls to every builtin function
defined in the .td input.
This patch does not add any use of the new flag yet, so the only way
to obtain a generated test file is through a manual invocation of
clang-tblgen. A test making use of this emitter will be added in a
followup commit.
Differential Revision: https://reviews.llvm.org/D97869
This completes the series implementing p1099, by adding the feature
macro and updating the web page.
Differential Revision: https://reviews.llvm.org/D102242
Clang checks whether the type given to va_arg will automatically cause
undefined behavior, but this check was issuing false positives for
enumerations in C++. The issue turned out to be because
typesAreCompatible() in C++ checks whether the types are *the same*, so
this uses custom logic if the type compatibility check fails.
This issue was found by a user on code like:
typedef enum {
CURLINFO_NONE,
CURLINFO_EFFECTIVE_URL,
CURLINFO_LASTONE = 60
} CURLINFO;
...
__builtin_va_arg(list, CURLINFO); // false positive warning
Given that C++ defers to C for the rules around va_arg, the behavior
should be the same in both C and C++ and not diagnose because int and
CURLINFO are "compatible enough" types for va_arg.
This is a follow up to the "rvalue-to-prvalue" rename at D103720.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Depends on D103720
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D103933
This renames the expression value categories from rvalue to prvalue,
keeping nomenclature consistent with C++11 onwards.
C++ has the most complicated taxonomy here, and every other language
only uses a subset of it, so it's less confusing to use the C++ names
consistently, and mentally remap to the C names when working on that
context (prvalue -> rvalue, no xvalues, etc).
Renames:
* VK_RValue -> VK_PRValue
* Expr::isRValue -> Expr::isPRValue
* SK_QualificationConversionRValue -> SK_QualificationConversionPRValue
* JSON AST Dumper Expression nodes value category: "rvalue" -> "prvalue"
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D103720
libc++ has issues when used with -fno-exceptions and vcruntime,
don't use it on Windows by default until we address those issues.
Differential Revision: https://reviews.llvm.org/D103941
The FileCheck lines in these files are auto-generated and complete,
so there's very little upside (less CHECK lines) from running
-instcombine on them and violating the expected test layering
(optimizer developers shouldn't have to be aware of clang tests).
Running opt passes like this makes it harder to make changes such as:
D93817
Disabling PIC globally also disabled PIC for runtimes which was
undesirable, manually override it.
Differential Revision: https://reviews.llvm.org/D103919
This patch https://reviews.llvm.org/D102876 caused some lit regressions on z/OS because tmp files were no longer being opened based on binary/text mode. This patch passes OpenFlags when creating tmp files so we can open files in different modes.
Reviewed By: amccarth
Differential Revision: https://reviews.llvm.org/D103806
This implements the 'using enum maybe-qualified-enum-tag ;' part of
1099. It introduces a new 'UsingEnumDecl', subclassed from
'BaseUsingDecl'. Much of the diff is the boilerplate needed to get the
new class set up.
There is one case where we accept ill-formed, but I believe this is
merely an extended case of an existing bug, so consider it
orthogonal. AFAICT in class-scope the c++20 rule is that no 2 using
decls can bring in the same target decl ([namespace.udecl]/8). But we
already accept:
struct A { enum { a }; };
struct B : A { using A::a; };
struct C : B { using A::a;
using B::a; }; // same enumerator
this patch permits mixtures of 'using enum Bob;' and 'using Bob::member;' in the same way.
Differential Revision: https://reviews.llvm.org/D102241
They are still unsupported, but at least this makes clang-cl not mistake
them for being filenames.
As pointed out in the bug, VS 16.10 now uses these flags in new projects
by default.
In the interests of disabling misc-no-recursion across LLVM (this seems
like a stylistic choice that is not consistent with LLVM's
style/development approach) this NFC preliminary change adjusts all the
.clang-tidy files to inherit from their parents as much as possible.
This change specifically preserves all the quirks of the current configs
in order to make it easier to review as NFC.
I validatad the change is NFC as follows:
for X in `cat ../files.txt`;
do
mkdir -p ../tmp/$(dirname $X)
touch $(dirname $X)/blaikie.cpp
clang-tidy -dump-config $(dirname $X)/blaikie.cpp > ../tmp/$(dirname $X)/after
rm $(dirname $X)/blaikie.cpp
done
(similarly for the "before" state, without this patch applied)
for X in `cat ../files.txt`;
do
echo $X
diff \
../tmp/$(dirname $X)/before \
<(cat ../tmp/$(dirname $X)/after \
| sed -e "s/,readability-identifier-naming\(.*\),-readability-identifier-naming/\1/" \
| sed -e "s/,-llvm-include-order\(.*\),llvm-include-order/\1/" \
| sed -e "s/,-misc-no-recursion\(.*\),misc-no-recursion/\1/" \
| sed -e "s/,-clang-diagnostic-\*\(.*\),clang-diagnostic-\*/\1/")
done
(using sed to strip some add/remove pairs to reduce the diff and make it easier to read)
The resulting report is:
.clang-tidy
clang/.clang-tidy
2c2
< Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming,-misc-no-recursion'
---
> Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-misc-no-recursion'
compiler-rt/.clang-tidy
2c2
< Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,-llvm-header-guard,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes'
---
> Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-llvm-header-guard'
flang/.clang-tidy
2c2
< Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,llvm-*,-llvm-include-order,misc-*,-misc-no-recursion,-misc-unused-parameters,-misc-non-private-member-variables-in-classes'
---
> Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-llvm-include-order,-misc-no-recursion'
flang/include/flang/Lower/.clang-tidy
flang/include/flang/Optimizer/.clang-tidy
flang/lib/Lower/.clang-tidy
flang/lib/Optimizer/.clang-tidy
lld/.clang-tidy
lldb/.clang-tidy
llvm/tools/split-file/.clang-tidy
mlir/.clang-tidy
The `clang/.clang-tidy` change is a no-op, disabling an option that was never enabled.
The compiler-rt and flang changes are no-op reorderings of the same flags.
(side note, the .clang-tidy file in parallel-libs is broken and crashes
clang-tidy because it uses "lowerCase" as the style instead of "lower_case" -
so I'll deal with that separately)
Differential Revision: https://reviews.llvm.org/D103842
vtbl itself is in default global address space. When clang emits
ctor, it gets a pointer to the vtbl field based on the this pointer,
then stores vtbl to the pointer.
Since this pointer can point to any address space (e.g. an object
created in stack), this pointer points to default address space, therefore
the pointer to vtbl field in this object should also be in default
address space.
Currently, clang incorrectly casts the pointer to vtbl field in this object
to global address space. This caused assertions in backend.
This patch fixes that by removing the incorrect addr space cast.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D103835
This adds support for p1099's 'using SCOPED_ENUM::MEMBER;'
functionality, bringing a member of an enumerator into the current
scope. The novel feature here, is that there need not be a class
hierarchical relationship between the current scope and the scope of
the SCOPED_ENUM. That's a new thing, the closest equivalent is a
typedef or alias declaration. But this means that
Sema::CheckUsingDeclQualifier needs adjustment. (a) one can't call it
until one knows the set of decls that are being referenced -- if
exactly one is an enumerator, we're in the new territory. Thus it
needs calling later in some cases. Also (b) there are two ways we hold
the set of such decls. During parsing (or instantiating a dependent
scope) we have a lookup result, and during instantiation we have a set
of shadow decls. Thus two optional arguments, at most one of which
should be non-null.
Differential Revision: https://reviews.llvm.org/D100276
Add the `memory_scope_all_devices` enum value, which is restricted to
OpenCL 3.0 or newer and the `__opencl_c_atomic_scope_all_devices`
feature. Also guard `memory_scope_all_svm_devices` accordingly, which
is already available in OpenCL 2.0.
The `__opencl_c_atomic_scope_all_devices` feature is header-only, so
set its define to 1 in `opencl-c-base.h`. This is done
unconditionally at the moment, as the mechanism for disabling
header-only options hasn't been decided yet.
This patch only adds a negative test for now. Ideally adding a CL3.0
run line to atomic-ops.cl should suffice as a positive test, but we
cannot do that yet until (at least) generic address spaces and program
scope variables are supported in OpenCL 3.0 mode.
Differential Revision: https://reviews.llvm.org/D103241
This fixes inconsistencies in the ms_abi.c testcase.
Also add a couple cases of missing double pointers in the windows part
of the testcase; the outcome of building that testcase on windows hasn't
changed, but the previous form of the test was imprecise (checking
for "%[[STRUCT_FOO]]*" when clang actually generates "%[[STRUCT_FOO]]**"),
which still used to match.
Ideally this would share code with the native Windows case, but
X86_64ABIInfo and WinX86_64ABIInfo aren't superclasses/subclasses of
each other so it's impractical, and the code to share currently only
consists of a couple lines.
Differential Revision: https://reviews.llvm.org/D103837
Summary: Replaced code on region cast with a function-wrapper SValBuilder::getCastedMemRegionVal. This is a next step of code refining due to suggestions in D103319.
Differential Revision: https://reviews.llvm.org/D103803
This implements support for using libc++ headers and library in the MSVC
toolchain. We only support libc++ that is a part of the toolchain, and
not headers installed elsewhere on the system.
Differential Revision: https://reviews.llvm.org/D101479
Complete support for fast8:
- amend shadow size and mapping in runtime
- remove fast16 mode and -dfsan-fast-16-labels flag
- remove legacy mode and make fast8 mode the default
- remove dfsan-fast-8-labels flag
- remove functions in dfsan interface only applicable to legacy
- remove legacy-related instrumentation code and tests
- update documentation.
Reviewed By: stephan.yichao.zhao, browneee
Differential Revision: https://reviews.llvm.org/D103745
So far, support for x86_64-linux-gnux32 has been handled by explicit
comparisons of Triple.getEnvironment() to GNUX32. This worked as long as
x86_64-linux-gnux32 was the only X32 environment to worry about, but we
now have x86_64-linux-muslx32 as well. To support this, this change adds
an isX32() function and uses it. It replaces all checks for GNUX32 or
MuslX32 by isX32(), except for the following:
- Triple::isGNUEnvironment() and Triple::isMusl() are supposed to treat
GNUX32 and MuslX32 differently.
- computeTargetTriple() needs to be able to transform triples to add or
remove X32 from the environment and needs to map GNU to GNUX32, and
Musl to MuslX32.
- getMultiarchTriple() completely lacks any Musl support and retains the
explicit check for GNUX32 as it can only return x86_64-linux-gnux32.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D103777
On x86_64 mingw, long doubles are always passed indirectly as
arguments (see an existing case in WinX86_64ABIInfo::classify);
generalize the existing code for reading varargs - any non-aggregate
type that is larger than 64 bits (which would be both long double
in mingw, and __int128) are passed indirectly too.
This makes reading varargs consistent with how they're passed,
fixing interop with both gcc and clang callers, for long double
and __int128.
Differential Revision: https://reviews.llvm.org/D103452
Refactored code of dependence processing and added new inoutset dependence type.
Compiler can set dependence flag to 0x8 when call __kmpc_omp_task_with_deps.
Size of type of the dependence flag changed from 1 to 4 bytes in clang.
All dependence flags library gets so far and corresponding dependence types:
1 - IN, 2 - OUT, 3 - INOUT, 4 - MUTEXINOUTSET, 8 - INOUTSET.
Differential Revision: https://reviews.llvm.org/D97085
This fixed PR#48894 for AArch64. The issue has been fixed for Arm in
https://reviews.llvm.org/D95872
The following rules apply to -Wa,-march with this change:
- Only compiler options apply to non assembly files
- Compiler and assembler options apply to assembly files
- For assembly files, we prefer the assembler option(s) if we have both kinds of option
- Of the options that apply (or are preferred), the last value wins (it's not additive)
Reviewed By: DavidSpickett, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D103184
If the memory object is scalable type, we do not know the exact size of
it at compile time. Set the size of lifetime marker to unknown if the
object is scalable one.
Differential Revision: https://reviews.llvm.org/D102822
Adding the `-init-only` option and corresponding frontend action to
generate a diagnostic.
`-init-only` vs `-test-io`:
`-init-only` ignores the input (it never calls the prescanner)
`-test-io` is similar to `-init-only`, but does read and print the input
without calling the prescanner.
This patch also adds a Driver test to check this action.
Reviewed By: awarzynski, AMDChirag
Differential Revision: https://reviews.llvm.org/D102849
This fixes a build breakage. I managed to attach this particular
change to the wrong diff in the stack when rebasing. And flubbed
testing :(
Differential Revision: https://reviews.llvm.org/D101777
This prepatch for using-enum breaks out the enum completion that that
will need from the existing scope completion logic.
Differential Revision: https://reviews.llvm.org/D102239
This is a pre-patch for adding using-enum support. It breaks out
the shadow decl handling of UsingDecl to a new intermediate base
class, BaseUsingDecl, altering the decl hierarchy to
def BaseUsing : DeclNode<Named, "", 1>;
def Using : DeclNode<BaseUsing>;
def UsingPack : DeclNode<Named>;
def UsingShadow : DeclNode<Named>;
def ConstructorUsingShadow : DeclNode<UsingShadow>;
Differential Revision: https://reviews.llvm.org/D101777
During code completion, lookupInDeclContext() calls
CodeCompletionDeclConsumer::FoundDecl(),which can mutate StoredDeclsMap,
over which lookupInDeclContext() iterates. This can lead to invalidation
of iterators and an assert()-crash.
Example code where this happens:
#include <list>
int main() {
std::list<int>;
std::^
}
with code completion on ^ with -std=c++20.
I do not have a repro case that does not need standard library.
This fix stores pointers to NamedDecls in a temporary vector, then
visits them outside of the main loop, when StoredDeclsMap iterators are
gone.
Differential Revision: https://reviews.llvm.org/D103472
Use llvm.experimental.vector.insert instead of storing into an alloca
when generating code for these intrinsics. This defers the codegen of
the generated vector to instruction selection, allowing existing
shufflevector style optimizations to apply.
Additionally, introduce a new target transform that can recognise fixed
predicate patterns in the svbool variants of these intrinsics.
Differential Revision: https://reviews.llvm.org/D103082
This diff adds testcase for the issue fixed in https://reviews.llvm.org/D77468
but regression test was not added in the diff. On Clang 9 it caused
crash in cland during code completion.
Test Plan: check-clang-unit
Differential Revision: https://reviews.llvm.org/D103722
This fixes PR49198: Wrong usage of __dso_handle in user code leads to
a compiler crash.
When Init is an address of the global itself, we need to track it
across RAUW. Otherwise the initializer can be destroyed if the global
is replaced.
Differential Revision: https://reviews.llvm.org/D101156
This fixes the missing address space on `this` in the implicit move
assignment operator.
The function called here is an abstraction around the lines that have
been removed which also sets the address space correctly.
This is copied from CopyConstructor, CopyAssignment and MoveConstructor,
all of which use this function, and now MoveAssignment does too.
Fixes: PR50259
Reviewed By: svenvh
Differential Revision: https://reviews.llvm.org/D103252
Multiple clauses are mutually exclusive. This patch refactors the functions that check for pairs of mutually exclusive clauses into a generalized function which also also accepts a list of clause types if which at most one can appear.
NFC patch extracted out of D99459 by request.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D103666
The current method getSingleClause requires an instance of OMPExecutableDirective to be called. Introduce a static version taking a list of clauses as argument instead that can be used during parsing/Sema before any OMPExecutableDirective has been created.
This is the same approach as taken for getClausesOfKind for getting more more than a single clause of a type which also has a method and static version. NFC patch extracted out of D99459 by request.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D103665
This patch fixes a Windows -EHa crash induced by previous commit 797ad70152.
The crash was caused by "LifetimeMarker" scope (with option -O2) that should not be considered as SEH Scope.
This change also turns off -fasync-exceptions by default under -EHa option for now.
Differential Revision: https://reviews.llvm.org/D103664#2799944
The following was found by a customer and is accepted by the other primary
C++ compilers, but fails to compile in Clang:
namespace sss {
double foo(int, double);
template <class T>
T foo(T); // note: target of using declaration
} // namespace sss
namespace oad {
void foo();
}
namespace oad {
using ::sss::foo;
}
namespace sss {
using oad::foo; // note: using declaration
}
namespace sss {
double foo(int, double) { return 0; }
template <class T>
T foo(T t) { // error: declaration conflicts with target of using
return t;
}
} // namespace sss
I believe the issue is that MergeFunctionDecl() was calling
checkUsingShadowRedecl() but only considering a FunctionDecl as a
possible shadow and not FunctionTemplateDecl. The changes in this patch
largely mirror how variable declarations were being handled by also
catching FunctionTemplateDecl.
Extend debug info handling by adding DWARF address space mapping for
SPIR, with corresponding test case.
Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D103097
Otherwise it is causing one of our build jobs to fail,
it is using "external" as directory, and NOT is
failing because "external" is found in ModuleID.
Differential Revision: https://reviews.llvm.org/D103658
Need to emit a call for __kmpc_cancel_barrier in the exit block for
__kmpc_cancel function call if cancellation of the parallel block is
requested.
Differential Revision: https://reviews.llvm.org/D103646
Patch allows using of constexpr vars evaluatable to constant calue to be
used in declare mapper construct.
Differential Revision: https://reviews.llvm.org/D103642
spack HIP device library is installed at amdgcn directory under llvm/clang
directory.
This patch fixes detection of HIP device library for spack.
Reviewed by: Artem Belevich, Harmen Stoppels
Differential Revision: https://reviews.llvm.org/D103281
When a project uses PCH with explicit modules, the build will look like this:
1. scan PCH dependencies
2. explicitly build PCH
3. scan TU dependencies
4. explicitly build TU
Step 2 produces an object file for the PCH, which the dependency scanner needs to read in step 3. This patch adds support for this.
The `clang-scan-deps` invocation in the attached test would fail without this change.
Depends on D103516.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D103519
This option is supported in `f18`, but not yet available in `flang-new`.
It is required in order to call `flang-new` from the `flang` bash
script.
Differential Revision: https://reviews.llvm.org/D103613
Dependency scanning currently performs an implicit build. When testing that Clang can build modules with the command-lines generated by `clang-scan-deps`, the actual compilation would overwrite artifacts created during the scan, which makes debugging harder than it should be and can lead to errors in multi-step builds.
To prevent this, this patch adds new flag to `clang-scan-deps` that allows developers to customize the directory to use when generating module map paths, instead of always using the module cache. Moreover, the explicit context hash in now part of the PCM path, which will be useful in D102488, where the context hash can change due to command-line pruning.
Reviewed By: Bigcheese
Differential Revision: https://reviews.llvm.org/D103516
ParmVarDecl is created with translation unit as the parent DeclContext
and later moved to the correct DeclContext. ASTImporterLookupTable
should be updated at this move.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D103231
This patch solves an error such as:
incompatible operand types ('vbool4_t' (aka '__rvv_bool4_t') and '__rvv_bool4_t')
when one of the value is a TypedefType of the other value in ?:.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D103603
Currently some amdgcn builtins are defined with long int type,
which causes invalid IR on Windows since long int is 32 bit
on Windows whereas these builtins have 64 bit arguments.
long long int type cannot be used since it is 128 bit in OpenCL.
This patch uses 64 bit int type instead of long int to define 64 bit int
arguments or return for amdgcn builtins.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D103563
A recent change (D99683) to support ThinLTO for HIP caused a regression
when compiling cuda code with -flto=thin -fwhole-program-vtables.
Specifically, we now get an error:
error: invalid argument '-fwhole-program-vtables' only allowed with '-flto'
This error is coming from the device offload cc1 action being set up for
the cuda compile, for which -flto=thin doesn't apply and gets dropped.
This is a regression, but points to a potential issue that was silently
occurring before the patch, details below.
Before D99683, the check for fwhole-program-vtables in the driver looked
like:
if (WholeProgramVTables) {
if (!D.isUsingLTO())
D.Diag(diag::err_drv_argument_only_allowed_with)
<< "-fwhole-program-vtables"
<< "-flto";
CmdArgs.push_back("-fwhole-program-vtables");
}
And D.isUsingLTO() returned true since we have -flto=thin. However,
because the cuda cc1 compile is doing device offloading, which didn't
support any LTO, there was other code that suppressed -flto* options
from being passed to the cc1 invocation. So the cc1 invocation silently
had -fwhole-program-vtables without any -flto*. This seems potentially
problematic, since if we had any virtual calls we would get type test
assume sequences without the corresponding LTO pass that handles them.
However, with the patch, which adds support for device offloading LTO
option -foffload-lto=thin, the code has changed so that we set a bool
IsUsingLTO based on either -flto* or -foffload-lto*, depending on
whether this is the device offloading action. For the device offload
action in our compile, since we don't have -foffload-lto, IsUsingLTO is
false, and the check for LTO with -fwhole-program-vtables now fails.
What we should do is only pass through -fwhole-program-vtables to the
cc1 invocation that has LTO enabled (either the device offload action
with -foffload-lto, or the non-device offload action with -flto), and
otherwise drop the -fwhole-program-vtables for the non-LTO action.
Then we should error only if we have -fwhole-program-vtables without any
-f*lto* options.
Differential Revision: https://reviews.llvm.org/D103579
Prior to this patch when you used `clang -module-file-info` clang would
delete the module on completion because the module was treated as an
output file.
This fixes the issue so you don't need to invoke cc1 directly to get
module file information.
Reviewed By: steven_wu, phosek
Differential Revision: https://reviews.llvm.org/D103547
Template args of outer types were not fully-qualified when calling getFullyQualifiedType() for inner types.
For simplicity the patch is a copy-paste of the same call from getFullyQualifiedType().
Reviewed at: https://reviews.llvm.org/D103039
This is a followup to D103422. The DenseMapInfo implementations for
ArrayRef and StringRef are moved into the ArrayRef.h and StringRef.h
headers, which means that these two headers no longer need to be
included by DenseMapInfo.h.
This required adding a few additional includes, as many files were
relying on various things pulled in by ArrayRef.h.
Differential Revision: https://reviews.llvm.org/D103491
This allows to set a different indent width for preprocessor statements.
Example:
#ifdef __linux_
# define FOO
#endif
int main(void)
{
return 0;
}
Differential Revision: https://reviews.llvm.org/D103286
This re-applies the old patch D27651, which was never landed, into the
latest "main" branch, without understanding the code. I just applied
the changes "mechanically" and made it compiling again.
This makes the right pointer alignment working as expected.
Fixes https://llvm.org/PR27353
For instance
const char* const* v1;
float const* v2;
SomeVeryLongType const& v3;
was formatted as
const char *const * v1;
float const * v2;
SomeVeryLongType const &v3;
This patch keep the *s or &s aligned to the right, next to their variable.
The above example is now formatted as
const char *const *v1;
float const *v2;
SomeVeryLongType const &v3;
It is a pity that this still does not work with clang-format in 2021,
even though there was a fix available in 2016. IMHO right pointer alignment
is the default case in C, because syntactically the pointer belongs to the
variable.
See
int* a, b, c; // wrong, just the 1st variable is a pointer
vs.
int *a, *b, *c; // right
Prominent example is the Linux kernel coding style.
Some styles argue the left pointer alignment is better and declaration
lists as shown above should be avoided. That's ok, as different projects
can use different styles, but this important style should work too.
I hope that somebody that has a better understanding about the code,
can take over this patch and land it into main.
For now I must maintain this fork to make it working for our projects.
Cheers,
Gerhard.
Differential Revision: https://reviews.llvm.org/D103245
The majority of all `addVisitor` callers follow the same pattern:
addVisitor(std::make_unique<SomeVisitor>(arg1, arg2, ...));
This patches introduces additional overload for `addVisitor` to simplify
that pattern:
addVisitor<SomeVisitor>(arg1, arg2, ...);
Differential Revision: https://reviews.llvm.org/D103457
Summary:
suggestPathToFileForDiagnostics is actively used in clangd for converting
an absolute path to a header file to a header name as it should be spelled
in the sources. Current approach converts absolute path to relative path.
This diff implements missing logic that makes a reverse lookup from the
relative path to the key in the header map that should be used in the sources.
Prerequisite diff: https://reviews.llvm.org/D103229
Test Plan: check-clang
Reviewers: dexonsmith, bruno, rsmith
Subscribers: cfe-commits
Tasks:
Tags: #clang
Differential Revision: https://reviews.llvm.org/D103142
incorrect std::string use. (Also remove redundant call to
RemoveFileOnSignal.)
Clang writes object files by first writing to a .tmp file and then
renaming to the final .obj name. On Windows, if a compile is killed
partway through the .tmp files don't get deleted.
Currently it seems like RemoveFileOnSignal takes care of deleting the
tmp files on Linux, but on Windows we need to call
setDeleteDisposition on tmp files so that they are deleted when
closed.
This patch switches to using TempFile to create the .tmp files we write
when creating object files, since it uses setDeleteDisposition on Windows.
This change applies to both Linux and Windows for consistency.
Differential Revision: https://reviews.llvm.org/D102876
This reverts commit 20797b129f.
The PreInits of a loop transformation (atm moment only tile) include the computation of the trip count. The trip count is needed by any loop-associated directives that consumes the transformation-generated loop. Hence, we must ensure that the PreInits of consumed loop transformations are emitted with the consuming directive.
This is done by addinging the inner loop transformation's PreInits to the outer loop-directive's PreInits. The outer loop-directive will consume the de-sugared AST such that the inner PreInits are not emitted twice. The PreInits of a loop transformation are still emitted directly if its generated loop(s) are not associated with another loop-associated directive.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D102180
Don't use vcruntime, this makes our toolchain more hermetic and avoids
some compiler errors we've encountered in compiler-rt.
Differential Revision: https://reviews.llvm.org/D103555
In the case where the device is an itanium target, and the host is a
windows target, we were getting the names wrong, since in the itanium
case we filter by lambda-signature.
The fix is to always filter by the signature rather than just on
non-windows builds. I considered doing the reverse (that is, checking
the aux-triple), but doing so would result in duplicate lambda mangling
numbers (from linux reusing the same number for different signatures).
This patch adds support for matching gtest's ASSERT_THAT, EXPECT_THAT, ON_CALL and EXPECT_CALL macros.
Reviewed By: ymandel, hokein
Differential Revision: https://reviews.llvm.org/D103195
This attribute applies to a using declaration, and permits importing a
declaration without knowing if that declaration exists. This is useful
for libc++ C wrapper headers that re-export declarations in std::, in
cases where the base C library doesn't provide all declarations.
This attribute was proposed in http://lists.llvm.org/pipermail/cfe-dev/2020-June/066038.html.
rdar://69313357
Differential Revision: https://reviews.llvm.org/D90188
Recently we added diagnosing ODR-use of host variables
in device functions, which includes ODR-use of const
host variables since they are not really emitted on
device side. This caused regressions since we used
to allow ODR-use of const host variables in device
functions.
This patch allows ODR-use of const variables in device
functions if the const variables can be statically initialized
and have an empty dtor. Such variables are marked with
implicit constant attrs and emitted on device side. This is
in line with what clang does for constexpr variables.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D103108
Currently clang and nvcc use c++14 as default std for C++.
gcc 11 even uses c++17 as default std for C++. However,
clang uses c++98 as default std for CUDA/HIP.
As c++14 has been well adopted and became default for
clang, it seems reasonable to use c++14 as default std
for CUDA/HIP.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D103221
Clang writes object files by first writing to a .tmp file and then
renaming to the final .obj name. On Windows, if a compile is killed
partway through the .tmp files don't get deleted.
Currently it seems like RemoveFileOnSignal takes care of deleting the
tmp files on Linux, but on Windows we need to call
setDeleteDisposition on tmp files so that they are deleted when
closed.
This patch switches to using TempFile to create the .tmp files we write
when creating object files, since it uses setDeleteDisposition on Windows.
This change applies to both Linux and Windows for consistency.
Differential Revision: https://reviews.llvm.org/D102876
All fuchsia targets will now use the relative-vtables ABI by default.
Also remove -fexperimental-relative-c++-abi-vtables from test RUNs targeting fuchsia.
Differential Revision: https://reviews.llvm.org/D102374
This addresses pr50497. The argument of a typeid expression is
unevaluated, *except* when it's a polymorphic type. We handle this by
parsing as unevaluated and then transforming to evaluated if we
discover it should have been an evaluated context.
We do the same in TreeTransform<Derived>::TransformCXXTypeidExpr,
entering unevaluated context before transforming and rebuilding the
typeid. But that's incorrect and can lead us to converting to
evaluated context twice -- and hitting an assert.
During normal template instantiation we're always cloning the
expression, but during generic lambda processing we do not necessarily
AlwaysRebuild, and end up with TransformDeclRefExpr unconditionally
calling MarkDeclRefReferenced around line 10226. That triggers the
assert.
// Mark it referenced in the new context regardless.
// FIXME: this is a bit instantiation-specific.
SemaRef.MarkDeclRefReferenced(E);
This patch makes 2 changes.
a) TreeTransform<Derived>::TransformCXXTypeidExpr only enters
unevaluated context if the typeid's operand is not a polymorphic
glvalue. If it is, it keeps the same evaluation context.
b) Sema::BuildCXXTypeId is altered to only transform to evaluated, if
the current context is unevaluated.
Differential Revision: https://reviews.llvm.org/D103258
Matheus Izvekov