Summary:
Migrate callers to print().
dump() should be useful to downstreams and third parties as a debugging
aid. Everyone trips up on this and creates confusing output.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50661
llvm-svn: 339810
Summary:
In r335809, Petr Hosek lays out support for what he calls the multiarch
runtimes layout. This new way of laying out the directories for runtime
libraries is workable for all platforms. Petr did some of the common
infrastructure and made it work for Linux and Fuscia. This patch is a
cleanup to the Darwin and MachO drivers to serve as a step toward
supporting it in Darwin.
This patch does primarily two things:
(1) Changes the APIs for how the Darwin driver refers to compiler-rt
libraries to use the component names, similar to how Linux and Fuscia do
(2) Removes some legacy functionality for supporting macOS versions
before 10.6. This functionality is effectively dead code because in
r339277, the support was removed from compiler-rt for generating the 10.4
runtime support library, and Xcode 10 (currently in beta) removes
libgcc_s.10.4 and libgcc_s.10.5 from the macOS SDK.
With this patch landed a subsequent patch can modify
MachO::AddLinkRuntimeLib to support the multiarch runtimes layout.
Worth noting: None of the removed functionality was actually covered in
the test suite. So no test case updates are required.
Reviewers: phosek, bruno, arphaman
Reviewed By: phosek, arphaman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50618
llvm-svn: 339807
The compiler may produce unexpected error messages/crashes when declare
target variables were used. Patch fixes problems with the declarations
marked as declare target to or link.
llvm-svn: 339805
The bit-fields of `Type` have enough space for
the `unsigned NumExpansions` of `PackExpansionType`
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D50711
llvm-svn: 339789
Type has enough space for two members of
TemplateSpecializationType. Mechanical patch.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D50643
llvm-svn: 339787
The tests `CodeGen/aapcs[64]-align.cc` are not run since files with a `.cc`
suffix aren't recognisze as tests. This patch renames the above two files to
`.cpp`.
Differential Revision: https://reviews.llvm.org/D46013
Comitting as obvious.
llvm-svn: 339766
Some versions of gcc, especially when invoked through ccache (-E), can have
trouble with raw string literals inside macros. This moves the string out of
the macro.
llvm-svn: 339759
Once CFG-side support for argument construction contexts landed in r338436,
the analyzer could make use of them to evaluate argument constructors properly.
When evaluated as calls, constructors of arguments now use the variable region
of the parameter as their target. The corresponding stack frame does not yet
exist when the parameter is constructed, and this stack frame is created
eagerly.
Construction of functions whose body is unavailable and of virtual functions
is not yet supported. Part of the reason is the analyzer doesn't consistently
use canonical declarations o identify the function in these cases, and every
re-declaration or potential override comes with its own set of parameter
declarations. Also it is less important because if the function is not
inlined, there's usually no benefit in inlining the argument constructor.
Differential Revision: https://reviews.llvm.org/D49443
llvm-svn: 339745
This related to the code as first checked in in r266292 ([ASTImporter]
Implement some expression-related AST node import., 2016-04-14).
llvm-svn: 339731
Summary:
A CXXBindTemporaryExpr can appear inside an ImplicitCastExpr, and was
not ignored previously.
Fixes the case reported in PR37327.
Reviewers: rsmith, dblaikie, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50666
llvm-svn: 339730
CXXTemporaryObjectExpr is a sub-class of CXXConstructExpr. If it has arguments
that are structures passed by value, their respective constructors need to be
handled by providing a ConstructionContext, like for regular function calls and
for regular constructors.
Differential Revision: https://reviews.llvm.org/D50487
llvm-svn: 339727
Summary:
Another piece of my ongoing to work for prefer-vector-width.
min-legal-vector-width will eventually be used by the X86 backend to know whether it needs to make 512 bits type legal when prefer-vector-width=256. If the user used inline assembly that passed in/out a 512-bit register, we need to make sure 512 bits are considered legal. Otherwise we'll get an assert failure when we try to wire up the inline assembly to the rest of the code.
This patch just checks the LLVM IR types to see if they are vectors and then updates the attribute based on their total width. I'm not sure if this is the best way to do this or if there's any subtlety I might have missed. So if anyone has other opinions on how to do this I'm open to suggestions.
Reviewers: chandlerc, rsmith, rnk
Reviewed By: rnk
Subscribers: eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D50678
llvm-svn: 339721
Summary:
Darwin support does not appear to be used as evidenced by the fact that
the runtime has never supported non-trivial programs.
Reviewers: pcc, kubamracek
Reviewed By: pcc
Subscribers: cfe-commits, kcc
Differential Revision: https://reviews.llvm.org/D50724
llvm-svn: 339720
information is then discarded with a warning to the user that we don't
support it.
This patch gets us one step closer by getting the info down into the
AST in most cases.
Reviewed by: rsmith
Differential Revision: https://reviews.llvm.org/D49865
llvm-svn: 339693
Summary:
This probably fixes PR35277, though there may be other sources of
nondeterminism (this was the only case of iterating over a DenseMap).
It's difficult to provide a test case for this, because it shows up only
on systems with ASLR enabled.
Reviewers: rjmccall
Reviewed By: rjmccall
Subscribers: bmwiedemann, mgrang, cfe-commits
Differential Revision: https://reviews.llvm.org/D50559
llvm-svn: 339668
This mangling is used only for outlined SEH finally blocks, which have
internal linkage.
This fixes the failure of CodeGenObjC/2007-04-03-ObjcEH.m on builds with
expensive checks enabled, on Windows. This test should probably be
specifying a triple: it currently picks up whatever the host environment
is using. Unfortunately, I have no idea what it is trying to test,
because it contains no comments and predates Clang having working
Objective-C IR generation.
llvm-svn: 339667
This confirms expectations for multiple values provided through the
driver when selecting specific modes and the order of appearance of
individual values for the `-fxray-modes=` flag.
This change just adds more test cases to an existing test file.
llvm-svn: 339662
Summary: This is the patch that lowers x86 intrinsics to native IR in order to enable optimizations.
Reviewers: craig.topper, spatel, RKSimon
Reviewed By: craig.topper
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D46892
llvm-svn: 339651
- Assuming strlcat is used with strlcpy we check as we can if the last argument does not equal os not larger than the buffer.
- Advising the proper usual pattern.
Reviewers: NoQ, george.karpenkov
Reviewed By: george.karpenkov
Differential Revision: https://reviews.llvm.org/D49722
llvm-svn: 339641
This breaks compiling atlwin.h in Chromium. I'm sure the code is invalid
in some way, but we put a lot of work into accepting it, and I'm sure
rejecting it was not an intended consequence of this refactoring. :)
llvm-svn: 339638
Current testing setup for analyzer tests with Z3 is rather inconvenient:
There's no way to run the analyzer tests separately (I use
LIT_FILTER=Analysis ninja check-clang, but a direct target is nicer).
When Clang is built with Z3 support, there's no way to *not* run tests
with Z3 solver, and this is often desired, as tests with Z3 solver take
a very long time.
This patch introduces two extra targets:
- check-clang-analyzer
- check-clang-analyzer-z3
which solve those problems.
Differential Revision: https://reviews.llvm.org/D50594
llvm-svn: 339629
Specifically, AttributedType now tracks a regular attr::Kind rather than
having its own parallel Kind enumeration, and AttributedTypeLoc now
holds an Attr* instead of holding an ad-hoc collection of Attr fields.
Differential Revision: https://reviews.llvm.org/D50526
llvm-svn: 339623
Before this patch, FieldChainInfo used a spaghetti: it took care of way too many cases,
even though it was always meant as a lightweight wrapper around
ImmutableList<const FieldRegion *>.
This problem is solved by introducing a lightweight polymorphic wrapper around const
FieldRegion *, FieldNode. It is an interface that abstracts away special cases like
pointers/references, objects that need to be casted to another type for a proper note
messages.
Changes to FieldChainInfo:
* Now wraps ImmutableList<const FieldNode &>.
* Any pointer/reference related fields and methods were removed
* Got a new add method. This replaces it's former constructors as a way to create a
new FieldChainInfo objects with a new element.
Changes to FindUninitializedField:
* In order not to deal with dynamic memory management, when an uninitialized field is
found, the note message for it is constructed and is stored instead of a
FieldChainInfo object. (see doc around addFieldToUninits).
Some of the test files are changed too, from now on uninitialized pointees of references
always print "uninitialized pointee" instead of "uninitialized field" (which should've
really been like this from the beginning).
I also updated every comment according to these changes.
Differential Revision: https://reviews.llvm.org/D50506
llvm-svn: 339599
Multiversioned member functions inside of a template type were
not properly being emitted. The solution to this is to simply
ensure that their bodies are correctly evaluated/assigned during
template instantiation.
llvm-svn: 339597
In this patch, the following classes and functions have been moved to a header file:
FieldChainInfo
FindUninitializedFields
isPrimitiveType
This also meant that they moved from anonymous namespace to clang::ento.
Code related to pointer chasing now relies in its own file.
There's absolutely no functional change in this patch -- its literally just copy pasting.
Differential Revision: https://reviews.llvm.org/D50504
llvm-svn: 339595
Summary:
Fixes r339581 ("[SEMA] add more -Wfloat-conversion to
compound assigment analysis").
This test case was caught in postsubmit testing.
Reviewers: aaron.ballman, gkistanova
Reviewed By: aaron.ballman
Subscribers: cfe-commits, srhines
Differential Revision: https://reviews.llvm.org/D50647
llvm-svn: 339593
This patch is the first part of a series of patches to refactor UninitializedObjectChecker. The goal of this effort is to
Separate pointer chasing from the rest of the checker,
Increase readability and reliability,
Don't impact performance (too bad).
In this one, ImmutableList's factory is moved to FindUninitializedFields.
Differential Revision: https://reviews.llvm.org/D50503
llvm-svn: 339591
The current static_assert only checks that ObjCObjectTypeBitfields
fits into an unsigned. However it turns out that FunctionTypeBitfields
do not currently fits into an unsigned. Therefore the anonymous
union containing the bit-fields always use 8 bytes instead of 4.
This patch removes the lone misguided static_assert and systematically
checks the size of each bit-field.
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D50630
llvm-svn: 339582
Stephen Kelly