| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
While it is far from complete, it does fix the following <rdar://problem/5967199> clang on xcode: error: member reference is not to a structure or union
llvm-svn: 51719
|
| |
|
|
| |
llvm-svn: 51707
|
| |
|
|
|
|
| |
- #include ExprObjC.h in many places
llvm-svn: 51703
|
| |
|
|
| |
llvm-svn: 51689
|
| |
|
|
| |
llvm-svn: 51683
|
| |
|
|
|
|
| |
constant expressions.
llvm-svn: 51682
|
| |
|
|
|
|
|
| |
unsigned because it's possible (at least in theory) to have
have both positive and negative pointers pointing to the same object.
llvm-svn: 51681
|
| |
|
|
|
|
|
| |
in unions (we don't want to do the union-specific bitcast for
bit-fields).
llvm-svn: 51678
|
| |
|
|
|
|
| |
expressions.
llvm-svn: 51677
|
| |
|
|
|
|
| |
alignment and alignment attributes.
llvm-svn: 51676
|
| |
|
|
|
|
|
|
| |
emit incomplete types, because they crash llc, and always use the
logical location as the current location so we don't crash doing invalid
queries on CurLoc.
llvm-svn: 51675
|
| |
|
|
|
|
| |
This change makes clang generate the same thing as llvm-gcc.
llvm-svn: 51674
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
nothing fundamentally wrong with it. Emitting unpacked structs where
possible is more work for almost no practical benefit. We'll probably
want to fix it at some point anyway, but it's low priority.
The issue with long double in particular is that LLVM thinks an X86 long
double is 10 bytes, while clang considers it for all purposes to be
either 12 or 16 bytes, depending on the platform, even in a packed
struct.
llvm-svn: 51673
|
| |
|
|
| |
llvm-svn: 51672
|
| |
|
|
|
|
| |
from the rope. rdar://5952468
llvm-svn: 51651
|
| |
|
|
| |
llvm-svn: 51646
|
| |
|
|
| |
llvm-svn: 51645
|
| |
|
|
| |
llvm-svn: 51622
|
| |
|
|
|
|
| |
LDPLUSPLUS to g++ to ensure that C++ object files are linked with g++ instead of gcc.
llvm-svn: 51621
|
| |
|
|
| |
llvm-svn: 51620
|
| |
|
|
| |
llvm-svn: 51619
|
| |
|
|
| |
llvm-svn: 51618
|
| |
|
|
|
|
| |
__builtin_copysign.
llvm-svn: 51597
|
| |
|
|
| |
llvm-svn: 51596
|
| |
|
|
| |
llvm-svn: 51595
|
| |
|
|
|
|
| |
of extra warnings in the Python source.
llvm-svn: 51594
|
| |
|
|
| |
llvm-svn: 51587
|
| |
|
|
| |
llvm-svn: 51586
|
| |
|
|
| |
llvm-svn: 51585
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
encountered. Mixing up the decls is unintuitive, and confuses the AST
destruction code. Fixes PR2360.
Note that there is a need to look up the characteristics and
declarations of a function associated with a particular name or decl,
but the original swapping code doesn't solve it properly.
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-May/001644.html is one
suggestion for how to fix that.
llvm-svn: 51584
|
| |
|
|
|
|
|
| |
been used. In preparation for the fix to PR2360, but also a minor bug
in its own right.
llvm-svn: 51583
|
| |
|
|
| |
llvm-svn: 51580
|
| |
|
|
| |
llvm-svn: 51579
|
| |
|
|
|
|
| |
codegen of X86 long double.
llvm-svn: 51578
|
| |
|
|
|
|
|
|
|
|
| |
it fixes PR2204. Not too much to say about the implementation; it works
in a similar way to the vector size attribute.
At some point, we need to modify the targets to provide information
about the appropriate types.
llvm-svn: 51577
|
| |
|
|
|
|
|
|
|
| |
a few bugs, but I don't know of any in particular. This has good effects
besides cleanup, though: it also should make it easier to implement the
aligned and packed attributes, and also target-specific struct layouts,
because the code won't have to be duplicated in codegen.
llvm-svn: 51576
|
| |
|
|
| |
llvm-svn: 51575
|
| |
|
|
|
|
| |
happening.
llvm-svn: 51574
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
required for correctness in cases of copying a struct to itself or to
an overlapping struct (itself for cases like *a = *a, and overlapping
is possible with unions).
Hopefully, this won't end up being a perf issue; LLVM *should* be able
to optimize memmove to memcpy in a lot of cases, and for small copies
the generated code *should* be mostly comparable. (In reality, LLVM
is currently horrible at optimizing memmove, but that's a bug, not a
fundamental issue.)
gcc currently generates wrong code; that's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667.
llvm-svn: 51566
|
| |
|
|
|
|
|
|
| |
someone tries to make a bitfield volatile?).
Not sure how to write a test; any suggestions?
llvm-svn: 51558
|
| |
|
|
|
|
| |
with unnamed members.
llvm-svn: 51557
|
| |
|
|
|
|
| |
PR2151 (by not creating the empty implicit init list).
llvm-svn: 51556
|
| |
|
|
|
|
| |
double-report errors; fixes PR2362.
llvm-svn: 51555
|
| |
|
|
|
|
| |
test/Codegen/mandel.c on Solaris. :-)
llvm-svn: 51554
|
| |
|
|
|
|
| |
Also take care of freeing memory at the right places.
llvm-svn: 51553
|
| |
|
|
| |
llvm-svn: 51552
|
| |
|
|
|
|
| |
(originally reported in PR1682).
llvm-svn: 51551
|
| |
|
|
| |
llvm-svn: 51548
|
| |
|
|
| |
llvm-svn: 51547
|
| |
|
|
| |
llvm-svn: 51546
|