| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ProgramState::assumeInBound() API is used by checkers to make an assumption
that a certain array index is within the array's bounds (i.e. is greater than or
equal to 0 and is less than the length of the array). When the type of the
index was unspecified by the caller, it assumed that the type is 'int', which
caused some indices and sizes to truncate during calculations.
Use ArrayIndexTy by default instead, which is used by the analyzer to represent
index types and is currently hardcoded to long long.
Patch by Bevin Hansson!
Differential Revision: https://reviews.llvm.org/D46944
llvm-svn: 335803
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r335795 adds copy elision information to CFG. This commit allows static analyzer
to elide elidable copy constructors by constructing the objects that were
previously subject to elidable copy directly in the target region of the copy.
The chain of elided constructors may potentially be indefinitely long. This
only happens when the object is being returned from a function which in turn is
returned from another function, etc.
NRVO is not supported yet.
Differential Revision: https://reviews.llvm.org/D47671
llvm-svn: 335800
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a temporary object is materialized and through that obtain lifetime that
is longer than the duration of the full-expression, it does not require a
temporary object destructor; it will be destroyed in a different manner.
Therefore it's not necessary to include CXXBindTemporaryExpr into the
construction context for such temporary in the CFG only to make clients
throw it away.
Differential Revision: https://reviews.llvm.org/D47667
llvm-svn: 335798
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an object's class provides no destructor, it's less important to
materialize that object properly because we don't have to model the destructor
correctly, so previously we skipped the support for these syntax patterns.
Additionally, fix support for construction contexts of "static temporaries"
(temporaries that are lifetime-extended by static references) because
it turned out that we only had tests for them without destructors, which caused
us to regress when we re-introduced the construction context for such
temporaries.
Differential Revision: https://reviews.llvm.org/D47658
llvm-svn: 335796
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before C++17 copy elision was optional, even if the elidable copy/move
constructor had arbitrary side effects. The elidable constructor is present
in the AST, but marked as elidable.
In these cases CFG now contains additional information that allows its clients
to figure out if a temporary object is only being constructed so that to pass
it to an elidable constructor. If so, it includes a reference to the elidable
constructor's construction context, so that the client could elide the
elidable constructor and construct the object directly at its final destination.
Differential Revision: https://reviews.llvm.org/D47616
llvm-svn: 335795
|
|
|
|
|
|
|
|
|
|
|
| |
conversions are only applied to operands of class type, and the second
standard conversion sequence is not applied.
When diagnosing an invalid builtin binary operator, talk about the
original types rather than the converted types. If these differ by a
user-defined conversion, tell the user what happened.
llvm-svn: 335781
|
|
|
|
|
|
|
|
|
|
|
| |
Using @import in framework headers inhibit the use of such headers
when not using modules, this is specially bad for headers that end
up in the SDK (or any other system framework). Add a warning to give
users some indication that this is discouraged.
rdar://problem/39192894
llvm-svn: 335780
|
|
|
|
|
|
|
|
| |
array subscript expression is an array prvalue.
Also apply DR1213 to vector prvalues for consistency.
llvm-svn: 335779
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
HIP should link the bitcodes with caller functions before callee functions. Also added lit test to check the ordering of the linked bitcodes is matches.
Reviewers: yaxunl, b-sumner
Reviewed By: yaxunl, b-sumner
Subscribers: cfe-commits, yaxunl, b-sumner, scchan
Differential Revision: https://reviews.llvm.org/D48667
llvm-svn: 335774
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Use oclc_daz_opt_on.amdgcn.bc bitcode when option fcuda-flush-denormal-to-zero is enabled, otherwise use oclc_daz_opt_off.amdgcn.bc bitcode. Added lit tests to verify that the correct bitcode is linked when -fcuda-flush-denormal-to-zero option is enabled or disabled.
Reviewers: yaxunl, scchan, b-sumner
Reviewed By: yaxunl, scchan, b-sumner
Subscribers: cfe-commits, yaxunl
Differential Revision: https://reviews.llvm.org/D48493
llvm-svn: 335765
|
|
|
|
|
|
|
|
|
|
| |
This matches the way NVCC does it. Doing module cleanup at global
destructor phase used to work, but is, apparently, too late for
the CUDA runtime in CUDA-9.2, which ends up crashing with double-free.
Differential Revision: https://reviews.llvm.org/D48613
llvm-svn: 335763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As brought up during the discussion of the DWARF5 accelerator tables,
there is currently no way to associate Objective-C methods with the
interface they belong to, other than the .apple_objc accelerator table.
After due consideration we came to the conclusion that it makes more
sense to follow Pavel's suggestion of just emitting this information in
the .debug_info section. One concern was that categories were
emitted in the .apple_names as well, but it turns out that LLDB doesn't
rely on the accelerator tables for this information.
This patch changes the codegen behavior to emit subprograms for
structure types, like we do for C++. This will result in the
DW_TAG_subprogram being nested as a child under its
DW_TAG_structure_type. This behavior is only enabled for DWARF5 and
later, so we can have a unique code path in LLDB with regards to
obtaining the class methods.
This was tested on the LLDB side and doesn't lead to a regression.
There's already code in place to deal with member functions in C++,
which deals with this transparently.
For more background please refer to the discussion on the mailing list:
http://lists.llvm.org/pipermail/llvm-dev/2018-June/123986.html
Differential revision: https://reviews.llvm.org/D48241
llvm-svn: 335757
|
|
|
|
|
|
|
|
| |
This broke a number of bots.
This reverts commit 5e1a89912d37a21c3b49ccf30600d7f498dffa9c.
llvm-svn: 335752
|
|
|
|
|
|
| |
name to match llvm.
llvm-svn: 335745
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add an extension point to allow registration of statically-linked Clang Static
Analyzer checkers that are not a part of the Clang tree. This extension point
employs the mechanism used when checkers are registered from dynamically loaded
plugins.
Reviewers: george.karpenkov, NoQ, xazax.hun, dcoughlin
Reviewed By: george.karpenkov
Subscribers: mgorny, mikhail.ramalho, rnkovacs, xazax.hun, szepet, a.sidorin, cfe-commits
Differential Revision: https://reviews.llvm.org/D45718
llvm-svn: 335740
|
|
|
|
|
|
|
|
|
| |
This patch reworks the support for dup NEON intrinsics as
described in D48439.
Differential Revision: https://reviews.llvm.org/D48440
llvm-svn: 335734
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With this patch when any `FunctionDecl` of a redeclaration chain is imported
then we bring in the whole declaration chain. This involves functions and
function template specializations. Also friend functions are affected. The
chain is imported as it is in the "from" tu, the order of the redeclarations
are kept. I also changed the lookup logic in order to find friends, but first
making them visible in their declaration context. We may have long
redeclaration chains if all TU contains the same prototype, but our
measurements shows no degradation in time of CTU analysis (Tmux, Xerces,
Bitcoin, Protobuf). Also, as further work we could squash redundant
prototypes, but first ensure that functionality is working properly; then
should we optimize.
This may seem like a huge patch, sorry about that. But, most of the changes are
new tests, changes in the production code is not that much. I also tried to
create a smaller patch which does not affect specializations, but that patch
failed to pass some of the `clang-import-test`s because there we import
function specializations. Also very importantly, we can't just change the
import of `FunctionDecl`s without changing the import of function template
specializations because they are handled as `FunctionDecl`s.
Reviewers: a.sidorin, r.stahl, xazax.hun, balazske, a_sidorin
Reviewed By: a_sidorin
Subscribers: labath, aprantl, a_sidorin, rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47532
Re-apply commit rC335480
llvm-svn: 335731
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: While at it, added a dump method to RangeSet.
Reviewers: george.karpenkov, NoQ
Reviewed By: george.karpenkov
Subscribers: xazax.hun, szepet, a.sidorin
Differential Revision: https://reviews.llvm.org/D48561
llvm-svn: 335726
|
|
|
|
| |
llvm-svn: 335702
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D44756
llvm-svn: 335701
|
|
|
|
|
|
|
|
|
|
| |
binary operator.
Factor out the checking for a comma within potential angle brackets and
also call it from contexts where we parse a comma-separated list of
arguments or initializers.
llvm-svn: 335699
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FreeBSD's mips64 builds O32 binaries for /usr/lib32 by default and
thus needs to be able to link O32 binaries which requires an explicit
linker emulation. Go ahead and list all the linker emulation variants
for MIPS so that any supported MIPS ABI binary can be linked by any
linker supporting MIPS.
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D48507
llvm-svn: 335691
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We track when we see a name-shaped expression followed by a '<' token
and parse the '<' as a comparison. Then:
* if we see a token sequence that cannot possibly be an expression but
can be a template argument (in particular, a type-id) that follows
either a ',' or the '<', diagnose that the '<' was supposed to start
a template argument list, and
* if we see '>()', diagnose that the '<' was supposed to start a
template argument list.
This only changes the diagnostic for error cases, and in practice
appears to catch the most common cases where a missing 'template'
keyword leads to parse errors within a template.
Differential Revision: https://reviews.llvm.org/D48571
llvm-svn: 335687
|
|
|
|
|
|
| |
Depends on r334313, which has been reverted in r335681.
llvm-svn: 335684
|
|
|
|
| |
llvm-svn: 335683
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of just saying "flag unused", we should tell the user that the
outliner isn't (at least officially) supported for some given architecture.
This adds a warning that will state something like
The 'blah' architecture does not support -moutline; flag ignored
when we call -moutline with the 'blah' architecture.
Since the outliner is still mostly an AArch64 thing, any architecture
other than AArch64 will emit this warning.
llvm-svn: 335672
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the current implementation, we run visitors until the fixed point is
reached.
That is, if a visitor adds another visitor, the currently processed path
is destroyed, all diagnostics is discarded, and it is regenerated again,
until it's no longer modified.
This pattern has a few negative implications:
- This loop does not even guarantee to terminate.
E.g. just imagine two visitors bouncing a diagnostics around.
- Performance-wise, e.g. for sqlite3 all visitors are being re-run at
least 10 times for some bugs.
We have already seen a few reports where it leads to timeouts.
- If we want to add more computationally intense visitors, this will
become worse.
- From architectural standpoint, the current layout requires copying
visitors, which is conceptually wrong, and can be annoying (e.g. no
unique_ptr on visitors allowed).
The proposed change is a much simpler architecture: the outer loop
processes nodes upwards, and whenever the visitor is added it only
processes current nodes and above, thus guaranteeing termination.
Differential Revision: https://reviews.llvm.org/D47856
llvm-svn: 335666
|
|
|
|
|
|
|
|
|
|
|
|
| |
FreeBSD defaults to mips3 for all MIPS ABIs with GCC as that is the
minimum MIPS architecture FreeBSD supports. Use mips3 for MIPS64 and
mips2 for MIPS32 to match.
Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D48499
llvm-svn: 335653
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NumTypos guard value ~0U doesn't prevent from creating new delayed typos. When
you create new delayed typos during typo correction, value ~0U wraps around to
0. When NumTypos is 0 we can miss some typos and treat an expression as it can
be typo-corrected. But if the expression is still invalid after correction, we
can get stuck in infinite loop trying to correct it.
Fix by not using value ~0U so that NumTypos correctly reflects the number of
typos.
rdar://problem/38642201
Reviewers: arphaman, majnemer, rsmith
Reviewed By: rsmith
Subscribers: rsmith, nicholas, cfe-commits
Differential Revision: https://reviews.llvm.org/D47341
llvm-svn: 335638
|
|
|
|
|
|
|
| |
Apparently we're now hitting an object file section limit on this
file with expensive checks enabled.
llvm-svn: 335636
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The hc.amdgcn.bc and hip.amdgcn.bc are removed in VDI build and no longer needed.
Reviewers: yaxunl
Reviewed By: yaxunl
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48455
llvm-svn: 335634
|
|
|
|
|
|
|
|
|
| |
Patch tries to make better analysis of the variables that should be
globalized. From now, instead of all parallel directives it will check
only distribute parallel .. directives and check only for
firstprivte/lastprivate variables if they must be globalized.
llvm-svn: 335632
|
|
|
|
| |
llvm-svn: 335630
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I am not sure anyone has tried to compile an application with sanitizers on
Android with `-static-libsan`, and a recent NDK, but it fails with:
```
.../i686-linux-android/bin/ld.gold: error: cannot find -lpthread
.../i686-linux-android/bin/ld.gold: error: cannot find -lrt
```
My understanding is that both are included in Bionic and as such are not needed,
and actually error out.
So remove the addition of those two in `linkSanitizerRuntimeDeps` when dealing
with Android, and update the tests.
I am unfamiliar with the evolution of the NDK and I am not sure if this has
always been the case or if this is somewhat of a recent evolution. I'll let
Android people chime in.
Reviewers: eugenis, pirama, srhines
Reviewed By: eugenis, srhines
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48570
llvm-svn: 335620
|
|
|
|
|
|
|
|
| |
NFCI.
Split the braces list initialization from the [] map operator to keep MSVC happy.
llvm-svn: 335614
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
At import of a record describing a template set its type to
InjectedClassNameType (instead of RecordType).
Reviewers: a.sidorin, martong, r.stahl
Reviewed By: a.sidorin, martong, r.stahl
Subscribers: a_sidorin, rnkovacs, martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D47450
Patch by Balazs Keri!
llvm-svn: 335600
|
|
|
|
|
|
|
|
| |
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48363
llvm-svn: 335595
|
|
|
|
|
|
|
| |
Log:
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/11390
llvm-svn: 335577
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the return type of an ObjC-style block literals is deduced, pick
the candidate type with the strictest nullability annotation applicable
to every other candidate.
This suppresses a UBSan false-positive in situations where a too-strict
nullability would be deduced, despite the fact that the returned value
would be implicitly cast to _Nullable.
rdar://41317163
llvm-svn: 335572
|
|
|
|
| |
llvm-svn: 335571
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similarly to CFI on virtual and indirect calls, this implementation
tries to use program type information to make the checks as precise
as possible. The basic way that it works is as follows, where `C`
is the name of the class being defined or the target of a call and
the function type is assumed to be `void()`.
For virtual calls:
- Attach type metadata to the addresses of function pointers in vtables
(not the functions themselves) of type `void (B::*)()` for each `B`
that is a recursive dynamic base class of `C`, including `C` itself.
This type metadata has an annotation that the type is for virtual
calls (to distinguish it from the non-virtual case).
- At the call site, check that the computed address of the function
pointer in the vtable has type `void (C::*)()`.
For non-virtual calls:
- Attach type metadata to each non-virtual member function whose address
can be taken with a member function pointer. The type of a function
in class `C` of type `void()` is each of the types `void (B::*)()`
where `B` is a most-base class of `C`. A most-base class of `C`
is defined as a recursive base class of `C`, including `C` itself,
that does not have any bases.
- At the call site, check that the function pointer has one of the types
`void (B::*)()` where `B` is a most-base class of `C`.
Differential Revision: https://reviews.llvm.org/D47567
llvm-svn: 335569
|
|
|
|
|
|
|
|
| |
implement the mask input argument using an 'and' IR instruction.
Additional IR is emitted to convert between scalar and vXi1 type to match the expected software inferface for the builtin that clang exposes.
llvm-svn: 335564
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ExprWithCleanups wraps full-expressions that require temporary destructors
and highlights the moment of time in which these destructors need to be called
(i.e., "at the end of the full-expression...").
Such expressions don't necessarily return an object; they may return anything,
including a null or undefined value.
When the analyzer tries to understand where the null or undefined value came
from in order to present better diagnostics to the user, it will now skip
any ExprWithCleanups it encounters and look into the expression itself.
Differential Revision: https://reviews.llvm.org/D48204
llvm-svn: 335559
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Conservative evaluation of a C++ method call would invalidate the object,
as long as the method is not const or the object has mutable fields.
When checking for mutable fields, we need to scan the type of the object on
which the method is called, which may be more specific than the type of the
object on which the method is defined, hence we look up the type from the
this-argument expression.
If arrow syntax or implicit-this syntax is used, this-argument expression
has pointer type, not record type, and lookup accidentally failed for that
reason. Obtain object type correctly.
Differential Revision: https://reviews.llvm.org/D48460
llvm-svn: 335555
|
|
|
|
|
|
|
| |
It's a bit cleaner to use `hasFlag` instead of nested ifs. This
just refactors the -moutline/-mno-outline logic to use that.
llvm-svn: 335549
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds an option -gsplit-dwarf=<arg>. LLVM can create .dwo files in the given directory
during the implicit ThinLTO link stage.
Reviewers: tejohnson, dblaikie, pcc
Reviewed By: pcc
Subscribers: steven_wu, aprantl, JDevlieghere, yunlian, probinson, mehdi_amini, inglorion, cfe-commits
Differential Revision: https://reviews.llvm.org/D44788
llvm-svn: 335546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Framework vendors usually layout their framework headers in the
following way:
Foo.framework/Headers -> "public" headers
Foo.framework/PrivateHeader -> "private" headers
Since both headers in both directories can be found with #import
<Foo/some-header.h>, it's easy to make mistakes and include headers in
Foo.framework/PrivateHeader from headers in Foo.framework/Headers, which
usually configures a layering violation on Darwin ecosystems. One of the
problem this causes is dep cycles when modules are used, since it's very
common for "private" modules to include from the "public" ones; adding
an edge the other way around will trigger cycles.
Add a warning to catch those cases such that:
./A.framework/Headers/A.h:1:10: warning: public framework header includes private framework header 'A/APriv.h'
#include <A/APriv.h>
^
rdar://problem/38712182
llvm-svn: 335542
|
|
|
|
|
|
|
| |
This reverts commit r335084 as requested by David Jones and
Eric Christopher because of differences of emitted warnings.
llvm-svn: 335516
|
|
|
|
|
|
|
|
|
|
| |
The WebAssembly backend in particular benefits from being
able to distinguish between varargs functions (...) and prototype-less
C functions.
Differential Revision: https://reviews.llvm.org/D48443
llvm-svn: 335510
|
|
|
|
|
|
|
|
|
|
|
|
| |
is passed
Pass -enable-linkonceodr-outlining by default when LTO is enabled.
The outliner shouldn't compete with any sort of linker deduplication
on linkonceodr functions when LTO is enabled. Therefore, this behaviour
should be the default.
llvm-svn: 335504
|