A reduction for an incomplete array type used to produce an assert
fail during codegen. Now it produces a diagnostic.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D48735
llvm-svn: 335911
Since r334468, we no longer always copy the libcxx headers by virtue of
their presence when cmake runs.
This makes some of the later stages (compiler-rt, and the bootstrapped
stages) depend on them being copied, via the cxx-headers target.
Differential Revision: https://reviews.llvm.org/D48700
llvm-svn: 335898
Remove _VPMergeHook from Darwin's automatically-exported symbol list for
PGO. As of r328987 this symbol is no longer weak.
An integration test in compiler-rt will follow.
rdar://41470205
llvm-svn: 335890
Summary:
This stops clang-format from touching raw string contents with unrecognized delimiters inside recognized functions.
Unrecognized delimiters signal that the string might be special.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48728
llvm-svn: 335876
Base GNU ld is pretty ancient and does not support --dynamic-list flag.
For conveniency, we can it automatically when compile with ubsan sanitizer flag.
Reviewers: dberris
Reviewed by: dberris
Differential Revision: https://reviews.llvm.org/D48574
llvm-svn: 335856
Old GCCs have an annoying bug where RVO disables the automatic
conversion to base for unique_ptr. Add a pessimizing std::move as a
workaround.
llvm-svn: 335854
ODRHash aims to provide Cross-TU stable hashing. Making clang::Type pointer
part of the hash connects (remotely) the ODRHash with the TU-specific
::Profile hasher.
r332281 exposed the issue by changing the way the ASTContext different
elaborated types if there is an owning tag. In that case, ODRHash stores two
different types in its TypeMap which yields false ODR violation in modules.
The current state of implementation shouldn't need the TypeMap concept
anymore. Rip it out.
Differential Revision: https://reviews.llvm.org/D48524
llvm-svn: 335853
Add handling of the begin() funcion of containers to the iterator checkers,
together with the pre- and postfix ++ and -- operators of the iterators. This
makes possible the checking of iterators dereferenced ahead of the begin of the
container.
Differential Revision: https://reviews.llvm.org/D32642
llvm-svn: 335835
If range [m .. n] is stored for symbolic expression A - B, then we can deduce the range for B - A which is [-n .. -m]. This is only true for signed types, unless the range is [0 .. 0].
Differential Revision: https://reviews.llvm.org/D35110
llvm-svn: 335814
Previously we were using default logic when building Linux runtimes
in Fuchsia toolchain, but that leads to various issues due to how
the CMake logic in compiler-rt for determining the platform support
is implemented. With this change, we will use explicit target for
every provided Linux sysroot.
Differential Revision: https://reviews.llvm.org/D48563
llvm-svn: 335812
The resource dir path used for the multiarch runtimes support is
constructed in a platform independent way and therefore will use
native path separators on each platform. We need to make sure that
the per target runtime directory test handles both to not fail
when the test is being executed on Windows.
llvm-svn: 335810
This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:
lib/clang/$version/lib/$os
Clang now allows runtimes to be installed to:
lib/clang/$version/$target/lib
This also includes libc++, libc++abi and libunwind; today those are
assumed to be in Clang library directory built for host, with the
new layout it is possible to install libc++, libc++abi and libunwind
into the runtime directory built for different targets.
The use of new layout is enabled by setting the
LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both
projects and runtimes layouts. The runtimes CMake build has been further
modified to use the new layout when building runtimes for multiple
targets.
Differential Revision: https://reviews.llvm.org/D45604
llvm-svn: 335809
checks across module boundaries. This was causing us to load constructor
definitions for all consumers of a module with a pending check.
(In one case we saw ~7% of total frontend time spent loading
constructors for this check.)
llvm-svn: 335807
declaration of the function that ends up in the primary definition of
the class.
... at least for class templates. This is necessary for us to be able to
track when an inline friend function has a definition that needs to be
(lazily) instantiated.
llvm-svn: 335805
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
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
Summary:
Setting UBSAN_OPTIONS=silence_unsigned_overflow=1 will silence all UIO
reports. This feature, combined with
-fsanitize-recover=unsigned-integer-overflow, is useful for providing
fuzzing signal without the excessive log output.
Helps with https://github.com/google/oss-fuzz/issues/910.
Reviewers: kcc, vsk
Reviewed By: vsk
Subscribers: vsk, kubamracek, Dor1s, llvm-commits
Differential Revision: https://reviews.llvm.org/D48660
llvm-svn: 335762
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
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
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
Now that the structure of Fuchsia SDK has been formalized, we no
longer need to pass all the different CFLAGS/LDFLAGS to the CMake
build separately, we can simply set the FUCHSIA_SDK variable and
derive all the necessary variables from that one inside the cache
file.
Differential Revision: https://reviews.llvm.org/D48564
llvm-svn: 335708
Joel E. Denny