| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 77012
|
|
|
|
|
|
|
| |
__attribute__((address_space(1))) struct {int arr[ 3 ]; } *p1;
... = p1->arr[2]; // load from address space 1
llvm-svn: 76717
|
|
|
|
|
|
|
|
|
| |
until Doug Gregor's Type smart pointer code lands (or more discussion occurs).
These methods just call the new Type::getAs<XXX> methods, so we still have
reduced implementation redundancy. Having explicit getAsXXXType() methods makes
it easier to set breakpoints in the debugger.
llvm-svn: 76193
|
|
|
|
|
|
| |
Type::getAsMemberPointerType(), Type::getAsTagType(), and Type::getAsRecordType() with their Type::getAs<XXX> equivalents.
llvm-svn: 76139
|
|
|
|
| |
llvm-svn: 75705
|
|
|
|
| |
llvm-svn: 75446
|
|
|
|
| |
llvm-svn: 75021
|
|
|
|
|
|
|
| |
when struct variables with GC'able members are copied into.
Will provide a test case later.
llvm-svn: 74984
|
|
|
|
|
|
|
| |
Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating".
Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit.
llvm-svn: 74506
|
|
|
|
|
|
| |
ternary operator.
llvm-svn: 72842
|
|
|
|
| |
llvm-svn: 72803
|
|
|
|
| |
llvm-svn: 72655
|
|
|
|
| |
llvm-svn: 72649
|
|
|
|
| |
llvm-svn: 72648
|
|
|
|
| |
llvm-svn: 72633
|
|
|
|
|
|
|
| |
any body can spot codegen bugs with volatile, or knows of any in the
bug database, let me know.
llvm-svn: 72572
|
|
|
|
|
|
|
| |
getUnqualifiedType() doesn't strip off all qualifiers for non-canonical
types.
llvm-svn: 72552
|
|
|
|
| |
llvm-svn: 72492
|
|
|
|
|
|
| |
exressions.
llvm-svn: 72479
|
|
|
|
|
|
| |
one else is tempted to copy the style, incorrectly.
llvm-svn: 72448
|
|
|
|
| |
llvm-svn: 72439
|
|
|
|
|
|
| |
we actually have a destination.
llvm-svn: 72429
|
|
|
|
| |
llvm-svn: 72353
|
|
|
|
| |
llvm-svn: 72352
|
|
|
|
|
|
| |
how to get the backend to know that the operation is volatile.
llvm-svn: 72348
|
|
|
|
| |
llvm-svn: 72347
|
|
|
|
|
|
| |
is still ignored.
llvm-svn: 72344
|
|
|
|
| |
llvm-svn: 72342
|
|
|
|
| |
llvm-svn: 72315
|
|
|
|
| |
llvm-svn: 72308
|
|
|
|
|
|
| |
Stub out VisitCXXExprWithTemporaries.
llvm-svn: 72103
|
|
|
|
| |
llvm-svn: 71937
|
|
|
|
| |
llvm-svn: 70785
|
|
|
|
| |
llvm-svn: 70067
|
|
|
|
| |
llvm-svn: 69747
|
|
|
|
|
|
|
|
|
|
|
|
| |
struct S {
S(int, int);
};
void f() {
S s(10, 10);
}
llvm-svn: 69330
|
|
|
|
|
|
| |
implies an all-zero bit pattern.
llvm-svn: 68994
|
|
|
|
|
|
| |
No functionality change (really).
llvm-svn: 68726
|
|
|
|
| |
llvm-svn: 67896
|
|
|
|
| |
llvm-svn: 67477
|
|
|
|
| |
llvm-svn: 67207
|
|
|
|
| |
llvm-svn: 65701
|
|
|
|
|
|
|
|
| |
copies with memcpy instead of memmove. This matches what GCC does and if it
causes a problem with a particular libc we can always fix it with a target
hook.
llvm-svn: 65699
|
|
|
|
| |
llvm-svn: 64961
|
|
|
|
|
|
| |
case on x86_64.
llvm-svn: 64333
|
|
|
|
|
|
| |
list that involves the GNU array-range designator extension
llvm-svn: 63327
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
represents an implicit value-initialization of a subobject of a
particular type. This replaces the (ab)use of CXXZeroValueInitExpr
within initializer lists for the "holes" that occur due to the use of
C99 designated initializers.
The new test case is currently XFAIL'd, because CodeGen's
ConstExprEmitter (in lib/CodeGen/CGExprConstant.cpp) needs to be
taught to value-initialize when it sees ImplicitValueInitExprs.
llvm-svn: 63317
|
|
|
|
|
|
| |
have to try to guess which member is being initialized.
llvm-svn: 63315
|
|
|
|
|
|
|
|
|
|
|
|
| |
initializers.
- We now initialize unions properly when a member other than the
first is named by a designated initializer.
- We now provide proper semantic analysis and code generation for
GNU array-range designators *except* that side effects will occur
more than once. We warn about this.
llvm-svn: 63253
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The approach I've taken in this patch is relatively straightforward,
although the code itself is non-trivial. Essentially, as we process
an initializer list we build up a fully-explicit representation of the
initializer list, where each of the subobject initializations occurs
in order. Designators serve to "fill in" subobject initializations in
a non-linear way. The fully-explicit representation makes initializer
lists (both with and without designators) easy to grok for codegen and
later semantic analyses. We keep the syntactic form of the initializer
list linked into the AST for those clients interested in exactly what
the user wrote.
Known limitations:
- Designating a member of a union that isn't the first member may
result in bogus initialization (we warn about this)
- GNU array-range designators are not supported (we warn about this)
llvm-svn: 63242
|