Summary: The frontend debuginfo tests should not invoke llvm passes which includes add-discriminators that will change the debug info generated by FE.
Reviewers: dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D14848
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253686 91177308-0d34-0410-b5e6-96231b3b80d8
The patch expanded the flag *at the end*, breaking invocations like:
clang-cl /W4 -Wno-unused-parameter
Reverting for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253678 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
MACRO(> );
After:
MACRO(>);
Not overly important, but easy and good for symmetry reasons :-).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253669 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support of #pragma vtordisp inside functions in attempt to improve compatibility. Microsoft compiler appears to save the stack of vtordisp modes on entry of struct methods' bodies and restore it on exit (method-local vtordisp).
Differential Revision: http://reviews.llvm.org/D14467
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253650 91177308-0d34-0410-b5e6-96231b3b80d8
The analyzer currently reports dead store false positives when a local variable
is captured by reference in a C++ lambda.
For example:
int local = 0; auto lambda = [&local]() {
local++;
};
local = 7; // False Positive: Value stored to 'local' is never read
lambda();
In this case, the assignment setting `local` to 7 is not a dead store because
the called lambda will later read that assigned value.
This commit silences this source of false positives by treating locals captured
by reference in C++ lambdas as escaped, similarly to how the DeadStoresChecker
deals with locals whose address is taken.
rdar://problem/22165179
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253630 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This code is a bit undesirable, but it gets clang to work with the autoconf and cmake-built libclang_rt.profile libraries.
Reviewers: bogner
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D14847
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253625 91177308-0d34-0410-b5e6-96231b3b80d8
Also address a typo from a prior patch that performed a similar fix during Parsing of default non-type template arguments. I left the RAII ExpressionEvaluationContext variable Name as Unevaluated though we had switched the context to ConstantEvaluated.
There should be no functionality change here - since when expression evaluation context is popped off, for the most part these two contexts currently behave similarly in regards to lambda diagnostics and odr-use tracking.
Like its parsing counterpart, this patch presages the advent of constexpr lambda patches...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253590 91177308-0d34-0410-b5e6-96231b3b80d8
driving a canonical difference between that and an unqualified
type is a really bad idea when both are valid. Instead, remember
that it was there in a non-canonical way, then look for that in
the one place we really care about it: block captures. The net
effect closely resembles the behavior of a decl attribute, except
still closely following ARC's standard qualifier parsing rules.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253534 91177308-0d34-0410-b5e6-96231b3b80d8
to start at the offset of the first ivar instead of the rounded-up
end of the superclass. The latter could include a large amount of
tail padding because of a highly-aligned ivar, and subclass ivars
can be laid out within that.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253533 91177308-0d34-0410-b5e6-96231b3b80d8
Conversions between unrelated pointer types (e.g. char * and void *) involve
bitcasts which were not properly modeled in case of static initializers. The
patch fixes this problem.
The problem was originally spotted by Artem Dergachev. Patched by Yuri Gribov!
Differential Revision: http://reviews.llvm.org/D14652
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253532 91177308-0d34-0410-b5e6-96231b3b80d8
In the Microsoft ABI, the vftable is laid out in the order in the
declaration order of the entities defined within it.
Obviously, only virtual methods end up in the vftable but they will be
placed into the table at the same position as the first entity with the
same name.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253523 91177308-0d34-0410-b5e6-96231b3b80d8
The conversion from QuantityType to the (temporary) IntegerAlignment class
was ambiguous.
For now add in explicit conversion to unsigned to satisfy the clang-x86_64-debian-fast bot.
I'll remove the explicit conversion when I remove the IntegerAlignment class.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253519 91177308-0d34-0410-b5e6-96231b3b80d8
Since we don't check functions in dependent contexts, we should skip blocks
in those contexts as well. This avoids an assertion failure when the
DeadStoresChecker attempts to evaluate an array subscript expression with
a dependent name type.
rdar://problem/23564220
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253516 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow on from a similar LLVM commit: r253511.
Note, this was reviewed (and more details are in) http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html
These intrinsics currently have an explicit alignment argument which is
required to be a constant integer. It represents the alignment of the
source and dest, and so must be the minimum of those.
This change allows source and dest to each have their own alignments
by using the alignment attribute on their arguments. The alignment
argument itself is removed.
The only code change to clang is hidden in CGBuilder.h which now passes
both dest and source alignment to IRBuilder, instead of taking the minimum of
dest and source alignments.
Reviewed by Hal Finkel.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253512 91177308-0d34-0410-b5e6-96231b3b80d8
We created a malformed TemplateSpecializationType: it was dependent but
had a RecordType as it's canonical type. This would lead getAs to
crash. r249090 worked around this but we should fix this for real by
providing a more appropriate template specialization type as the
canonical type.
This fixes PR24246.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253495 91177308-0d34-0410-b5e6-96231b3b80d8
This provides both a more uniform interface and makes libclang behave like
clang tooling wrt relative paths against argv[0]. This is necessary for
finding paths to a c++ standard library relative to a clang binary given
in a compilation database. It can also be used to find paths relative to
libclang.so if the full path to it is passed in.
Differential Revision: http://reviews.llvm.org/D14695
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253466 91177308-0d34-0410-b5e6-96231b3b80d8
Some expected attributes appear to be incorrect after
optimizations are run and llvm will strip them. Use -O0
so that llvm will not have a chance to remove them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253458 91177308-0d34-0410-b5e6-96231b3b80d8
Chris Bieneman