Age | Commit message (Collapse) | Author |
|
We've added the RS880 variant in the LLVM backend to represent an R600
GPU with no vertex cache, so we need to update the GPU mappings for
-mcpu.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181202 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181199 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
__alignof__ of a field.
This problem can only happen in C++11.
Also do some petty optimizations.
rdar://13784901
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181185 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181184 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181181 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
array from a string literal.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181174 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181173 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
assignments in constant expressions. No significant functionality changes
(slight improvement to potential constant expression checking).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181170 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This fixes pr14958. I will audit other calls to isExternCContext to see
if there are any similar bugs left.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181163 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181159 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
hookup. For more information about safebuffers, see MSDN: http://msdn.microsoft.com/en-us/library/dd778695(v=vs.110).aspx
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181123 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181122 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
and specified the triple.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181115 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181113 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
libgcc provides a __clear_cache intrinsic on AArch64, much like it
does on 32-bit ARM.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181111 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Missing (somewhat ironically) is support for the new deduction rules
in lambda functions, plus PCH support for return type patching.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181108 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to use. This makes very little difference right now (other than suppressing
follow-on errors in some cases), but will matter more once we support deduced
return types (we don't want expressions with undeduced return types in the
AST).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181107 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
diagnostic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181103 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Sema tests added and CodeGen tests are pending
Differential Revision: http://llvm-reviews.chandlerc.com/D728
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181101 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
conversion-type-id, in preparation for this becoming valid in c++1y mode.
No functionality change; small diagnostic improvement.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181089 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
context.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181076 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Per discussion in cfe-commits, asserting may be a better way than introducing a special test flag.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181073 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
commands. // rdar://12381408
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181071 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previously, we would clone the current diagnostic consumer to produce
a new diagnostic consumer to use when building a module. The problem
here is that we end up losing diagnostics for important diagnostic
consumers, such as serialized diagnostics (where we'd end up with two
diagnostic consumers writing the same output file). With forwarding,
the diagnostics from all of the different modules being built get
forwarded to the one serialized-diagnostic consumer and are emitted in
a sane way.
Fixes <rdar://problem/13663996>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181067 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Un-break the gdb buildbot.
- Use the debug location of the return expression for the cleanup code
if the return expression is trivially evaluatable, regardless of the
number of stop points in the function.
- Ensure that any EH code in the cleanup still gets the line number of
the closing } of the lexical scope.
- Added a testcase with EH in the cleanup.
rdar://problem/13442648
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181056 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Add serialization for captured statements and captured decls. Also add
a const_capture_iterator to CapturedStmt.
Test contributed by Wei Pan
Differential Revision: http://llvm-reviews.chandlerc.com/D727
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181048 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
it when visiting such subexpressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181046 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181006 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MSVC provides __wchar_t, either as an alias for the built-in wchar_t
type, or as a separate type depending on language (C vs C++) and flags
(-fno-wchar).
In -fms-extensions, Clang will simply accept __wchar_t as an alias for
whatever type is used for wide character literals. In -fms-compatibility, we
try to mimic MSVC's behavior by always making __wchar_t a builtin type.
This fixes PR15815.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181004 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a lambda.
Bug #1 is that CGF's CurFuncDecl was "stuck" at lambda invocation
functions. Fix that by generally improving getNonClosureContext
to look through lambdas and captured statements but only report
code contexts, which is generally what's wanted. Audit uses of
CurFuncDecl and getNonClosureAncestor for correctness.
Bug #2 is that lambdas weren't specially mapping 'self' when inside
an ObjC method. Fix that by removing the requirement for that
and using the normal EmitDeclRefLValue path in LoadObjCSelf.
rdar://13800041
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181000 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
FindLastStoreBRVisitor is responsible for finding where a particular region
gets its value; if the region is a VarRegion, it's possible that value was
assigned at initialization, i.e. at its DeclStmt. However, if a function is
called recursively, the same DeclStmt may be evaluated multiple times in
multiple stack frames. FindLastStoreBRVisitor was not taking this into
account and just picking the first one it saw.
<rdar://problem/13787723>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180997 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
There were actually two bugs here:
- if we decided to look for an interesting lvalue or call expression, we
wouldn't go find its node if we also knew we were at a (different) call.
- if we looked through one message send with a nil receiver, we thought we
were still looking at an argument to the original call.
Put together, this kept us from being able to track the right values, which
means sub-par diagnostics and worse false-positive suppression.
Noticed by inspection.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180996 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This reverts commit 180982.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180990 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Without any conversion, this is pretty straightforward. Most of the
fields can be zeros. The order is:
- field offset or pointer
- nonvirtual adjustment (for MI functions)
- vbptr offset (for unspecified)
- virtual adjustment offset (for virtual inheritance)
Differential Revision: http://llvm-reviews.chandlerc.com/D699
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180985 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Use the debug location of the return expression for the cleanup code
if the return expression is trivially evaluatable, regardless of the
number of stop points in the function.
- Ensure that any EH code in the cleanup still gets the line number of
the closing } of the lexical scope.
- Added a testcase with EH in the cleanup.
rdar://problem/13442648
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180982 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the actual parser and support arbitrary id-expressions.
We're actually basically set up to do arbitrary expressions here
if we wanted to.
Assembly operands permit things like A::x to be written regardless
of language mode, which forces us to embellish the evaluation
context logic somewhat. The logic here under template instantiation
is incorrect; we need to preserve the fact that an expression was
unevaluated. Of course, template instantiation in general is fishy
here because we have no way of delaying semantic analysis in the
MC parser. It's all just fishy.
I've also fixed the serialization of MS asm statements.
This commit depends on an LLVM commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180976 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
arguments as expressions.
This change partly addresses a heinous problem we have with the
parsing of attribute arguments that are a lone identifier. Previously,
we would end up parsing the 'align' attribute of this as an expression
"(Align)":
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align((Align)))) char storage[Size];
};
while this would parse as a "parameter name" 'Align':
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align(Align))) char storage[Size];
};
The code that handles the alignment attribute would completely ignore
the parameter name, so the while the first of these would do what's
expected, the second would silently be equivalent to
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align)) char storage[Size];
};
i.e., use the maximal alignment rather than the specified alignment.
Address this by sniffing the "Args" provided in the TableGen
description of attributes. If the first argument is "obviously"
something that should be treated as an expression (rather than an
identifier to be matched later), parse it as an expression.
Fixes <rdar://problem/13700933>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180973 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180972 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
arguments as expressions.
This change partly addresses a heinous problem we have with the
parsing of attribute arguments that are a lone identifier. Previously,
we would end up parsing the 'align' attribute of this as an expression
"(Align)":
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align((Align)))) char storage[Size];
};
while this would parse as a "parameter name" 'Align':
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align(Align))) char storage[Size];
};
The code that handles the alignment attribute would completely ignore
the parameter name, so the while the first of these would do what's
expected, the second would silently be equivalent to
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align)) char storage[Size];
};
i.e., use the maximal alignment rather than the specified alignment.
Address this by sniffing the "Args" provided in the TableGen
description of attributes. If the first argument is "obviously"
something that should be treated as an expression (rather than an
identifier to be matched later), parse it as an expression.
Fixes <rdar://problem/13700933>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180970 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
...and don't consider '0' to be a null pointer constant if it's the
initializer for a float!
Apparently null pointer constant evaluation looks through both
MaterializeTemporaryExpr and ImplicitCastExpr, so we have to be more
careful about types in the callers. For RegionStore this just means giving
up a little more; for ExprEngine this means handling the
MaterializeTemporaryExpr case explicitly.
Follow-up to r180894.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180944 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
After some discussion, it was decided to use the Itanium ABI for thread_local on
Darwin OS X platforms. This involved a couple of changes. First, we use
"_tlv_atexit" instead of "__cxa_thread_atexit". Secondly, the global variables
are marked with 'internal' linkage, because we want all access to be calls to
the Itanium-specific entry point, which has normal linkage.
<rdar://problem/13733006>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180941 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
initializer.
Fixes <rdar://problem/13712739>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180937 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
headers, speculatively load module maps.
The "magical" builtin headers are the headers we provide as part of
the C standard library, which typically comes from /usr/include. We
essentially merge our headers into that location (due to cyclic
dependencies). This change makes sure that, when header search finds
one of our builtin headers, we figure out which module it actually
lives in. This case is fairly rare; one ends up having to include one
of the few built-in C headers we provide before including anything
from /usr/include to trigger it. Fixes <rdar://problem/13787184>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180934 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
If there is cleanup code, the cleanup code gets the debug location of
the closing '}'. The subsequent ret IR-instruction does not get a
debug location. The return _expression_ will get the debug location
of the return statement.
If the function contains only a single, simple return statement,
the cleanup code may become the first breakpoint in the function.
In this case we set the debug location for the cleanup code
to the location of the return statement.
rdar://problem/13442648
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180932 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180925 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
with no comment of their own to inherit the
comment of their aliased type. // rdar://13752382
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180924 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This adds a test to make sure we define _WCHAR_T_DEFINED and
_NATIVE_WCHAR_T_DEFINED correctly in the preprocessor, and updates
stddef.h to set it when typedeffing wchar_t.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180918 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
__has_feature(cxx_thread_local) true when the target supports thread-local storage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180909 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It is unfortunate that we have to mark these exceptions in multiple places.
This was already in CallEvent. I suppose it does let us be more precise
about saying /which/ arguments have their retain counts invalidated -- the
connection's is still valid even though the context object's isn't -- but
we're not tracking the retain count of XPC objects anyway.
<rdar://problem/13783514>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180904 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previously, this was scattered across Environment (literal expressions),
ExprEngine (default arguments), and RegionStore (global constants). The
former special-cased several kinds of simple constant expressions, while
the latter two deferred to the AST's constant evaluator.
Now, these are all unified as SValBuilder::getConstantVal(). To keep
Environment fast, the special cases for simple constant expressions have
been left in, but the main benefits are that (a) unusual constants like
ObjCStringLiterals now work as default arguments and global constant
initializers, and (b) we're not duplicating code between ExprEngine and
RegionStore.
This actually caught a bug in our test suite, which is awesome: we stop
tracking allocated memory if it's passed as an argument along with some
kind of callback, but not if the callback is 0. We were testing this in
a case where the callback parameter had a default value, but that value
was 0. After this change, the analyzer now (correctly) flags that as a
leak!
<rdar://problem/13773117>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180894 91177308-0d34-0410-b5e6-96231b3b80d8
|