| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Instead, use the location of the call to print the note.
llvm-svn: 181337
|
| |
|
|
|
|
|
|
|
|
|
| |
unnamed bitfields.
Unnamed bitfields won't have an explicit copy operation
in the AST, which breaks the strong form of the invariant.
rdar://13816940
llvm-svn: 181289
|
| |
|
|
|
|
| |
integers.
llvm-svn: 181287
|
| |
|
|
|
|
|
|
|
|
|
| |
FileID.
This fixes a crash due to SourceManager::getLocForEndOfFile() returning an off-by-one location
when the the FileID is for an empty file.
rdar://13803893
llvm-svn: 181285
|
| |
|
|
|
|
| |
call 'constexpr' assignment operators for a literal class type.
llvm-svn: 181284
|
| |
|
|
| |
llvm-svn: 181272
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- References to ObjC bit-field ivars are bit-field lvalues;
fixes rdar://13794269, which got me started down this.
- Introduce Expr::refersToBitField, switch a couple users to
it where semantically important, and comment the difference
between this and the existing API.
- Discourage Expr::getBitField by making it a bit longer and
less general-sounding.
- Lock down on const_casts of bit-field gl-values until we
hear back from the committee as to whether they're allowed.
llvm-svn: 181252
|
| |
|
|
|
|
| |
message.
llvm-svn: 181237
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This occurs because in C++11 the compound literal syntax can trigger a
constructor call via list-initialization. That is, "Point{x, y}" and
"(Point){x, y}" end up being equivalent. If this occurs, the inner
CXXConstructExpr will have already handled the object construction; the
CompoundLiteralExpr just needs to propagate that value forwards.
<rdar://problem/13804098>
llvm-svn: 181213
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, this compound literal expression (a GNU extension in C++):
(AggregateWithDtor){1, 2}
resulted in this AST:
`-CXXBindTemporaryExpr [...] 'struct Point' (CXXTemporary [...])
`-CompoundLiteralExpr [...] 'struct AggregateWithDtor'
`-CXXBindTemporaryExpr [...] 'struct AggregateWithDtor' (CXXTemporary [...])
`-InitListExpr [...] 'struct AggregateWithDtor'
|-IntegerLiteral [...] 'int' 1
`-IntegerLiteral [...] 'int' 2
Note the two CXXBindTemporaryExprs. The InitListExpr is really part of the
CompoundLiteralExpr, not an object in its own right. By introducing a new
entity initialization kind in Sema specifically for compound literals, we
avoid the treatment of the inner InitListExpr as a temporary.
`-CXXBindTemporaryExpr [...] 'struct Point' (CXXTemporary [...])
`-CompoundLiteralExpr [...] 'struct AggregateWithDtor'
`-InitListExpr [...] 'struct AggregateWithDtor'
|-IntegerLiteral [...] 'int' 1
`-IntegerLiteral [...] 'int' 2
llvm-svn: 181212
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch then adds all the usual platform-specific pieces for SystemZ:
driver support, basic target info, register names and constraints,
ABI info and vararg support. It also adds new tests to verify pre-defined
macros and inline asm, and updates a test for the minimum alignment change.
This version of the patch incorporates feedback from reviews by
Eric Christopher and John McCall. Thanks to all reviewers!
Patch by Richard Sandiford.
llvm-svn: 181211
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 181202
|
| |
|
|
| |
llvm-svn: 181199
|
| |
|
|
|
|
|
|
|
|
|
|
| |
__alignof__ of a field.
This problem can only happen in C++11.
Also do some petty optimizations.
rdar://13784901
llvm-svn: 181185
|
| |
|
|
| |
llvm-svn: 181184
|
| |
|
|
| |
llvm-svn: 181181
|
| |
|
|
|
|
| |
array from a string literal.
llvm-svn: 181174
|
| |
|
|
| |
llvm-svn: 181173
|
| |
|
|
|
|
|
| |
assignments in constant expressions. No significant functionality changes
(slight improvement to potential constant expression checking).
llvm-svn: 181170
|
| |
|
|
|
|
|
| |
This fixes pr14958. I will audit other calls to isExternCContext to see
if there are any similar bugs left.
llvm-svn: 181163
|
| |
|
|
| |
llvm-svn: 181159
|
| |
|
|
|
|
| |
hookup. For more information about safebuffers, see MSDN: http://msdn.microsoft.com/en-us/library/dd778695(v=vs.110).aspx
llvm-svn: 181123
|
| |
|
|
| |
llvm-svn: 181122
|
| |
|
|
|
|
| |
and specified the triple.
llvm-svn: 181115
|
| |
|
|
| |
llvm-svn: 181113
|
| |
|
|
|
|
|
| |
libgcc provides a __clear_cache intrinsic on AArch64, much like it
does on 32-bit ARM.
llvm-svn: 181111
|
| |
|
|
|
|
|
| |
Missing (somewhat ironically) is support for the new deduction rules
in lambda functions, plus PCH support for return type patching.
llvm-svn: 181108
|
| |
|
|
|
|
|
|
|
| |
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).
llvm-svn: 181107
|
| |
|
|
|
|
| |
diagnostic.
llvm-svn: 181103
|
| |
|
|
|
|
|
|
| |
- Sema tests added and CodeGen tests are pending
Differential Revision: http://llvm-reviews.chandlerc.com/D728
llvm-svn: 181101
|
| |
|
|
|
|
|
| |
conversion-type-id, in preparation for this becoming valid in c++1y mode.
No functionality change; small diagnostic improvement.
llvm-svn: 181089
|
| |
|
|
|
|
| |
context.
llvm-svn: 181076
|
| |
|
|
|
|
| |
Per discussion in cfe-commits, asserting may be a better way than introducing a special test flag.
llvm-svn: 181073
|
| |
|
|
|
|
| |
commands. // rdar://12381408
llvm-svn: 181071
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
llvm-svn: 181067
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 181056
|
| |
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 181048
|
| |
|
|
|
|
| |
it when visiting such subexpressions.
llvm-svn: 181046
|
| |
|
|
| |
llvm-svn: 181006
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 181004
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 181000
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 180997
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 180996
|
| |
|
|
|
|
| |
This reverts commit 180982.
llvm-svn: 180990
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 180985
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
llvm-svn: 180982
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 180976
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
llvm-svn: 180973
|
| |
|
|
| |
llvm-svn: 180972
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
llvm-svn: 180970
|