| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Implemented by David Chisnall!
llvm-svn: 51835
|
| |
|
|
|
|
|
|
|
|
| |
interface types on the RHS.
This eliminates a bogus warning identified in the test below.
This fixes <rdar://problem/5968256> clang on xcode: error: incompatible type initializing 'NSObject<XCSelectionSource> *', expected 'id<NSObject,XCSelectionSource>'
llvm-svn: 51832
|
| |
|
|
|
|
|
|
| |
This fixes a bogus error.
<rdar://problem/5967036> clang on xcode: error: incompatible operand types ('id<DTOutputStreams>' and 'DTFilterOutputStream *')
llvm-svn: 51828
|
| |
|
|
| |
llvm-svn: 51826
|
| |
|
|
|
|
|
|
|
|
|
| |
TranslationUnit object instead of an ASTContext. By default it calls
Initialize(ASTConstext& Context) (to match with the current interface used by
most ASTConsumers).
Modified the ObjC-Rewriter to use InitializeTU, and to tell the TranslationUnit
to not free its Decls. This is a workaround for: <rdar://problem/5966749>
llvm-svn: 51825
|
| |
|
|
| |
llvm-svn: 51809
|
| |
|
|
|
|
| |
writable. Added a FIXME for another day.
llvm-svn: 51800
|
| |
|
|
|
|
| |
types so that they end up the correct size.
llvm-svn: 51787
|
| |
|
|
|
|
|
|
|
|
|
|
| |
this does is reconstruct the type for structs and arrays if the type
wouldn't be compatible otherwise.
The assertion about packing in the struct type reconstruction code
sucks, but I don't see any obvious way to fix it. Maybe we need a general
utility method to take a list of types and alignments and try to construct an
unpacked type if possible?
llvm-svn: 51785
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
associated declaration. This is a prerequisite to handling
general union initializations; for example, an array of unions involving
pointers has to be turned into a struct because the elements can have
incompatible types.
I refactored the code a bit to make it more readable; now, the logic for
definitions is all in EmitGlobalVarInit.
The second parameter for GetAddrOfGlobalVar is now dead; I'll remove it
separately.
By itself, this patch should not cause any visible changes.
llvm-svn: 51783
|
| |
|
|
|
|
|
|
|
|
| |
required by the standard (the standard doesn't know anything about
implicit casts).
Disallow pointers cast to non-integral arithmetic types as constant
expressions. This was previously allowed by accident.
llvm-svn: 51779
|
| |
|
|
| |
llvm-svn: 51778
|
| |
|
|
|
|
| |
VariableArrayType, EnumConstantDecl, and VarDecl.
llvm-svn: 51772
|
| |
|
|
|
|
| |
of elements.
llvm-svn: 51769
|
| |
|
|
|
|
| |
This fixes a crash on the included testcase (found in NetHack).
llvm-svn: 51767
|
| |
|
|
| |
llvm-svn: 51765
|
| |
|
|
| |
llvm-svn: 51764
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
bit-field initialization; ugly code, X86-only, but it works, at least
for basic stuff. Separates/adds union initialization; currently disabled,
though, because the struct/array code needs modifications to support
elements of the wrong type.
Fixes PR2381 and PR2309 with the bit-field initialization. And NetHack
compiles and appears to work with a few tweaks (to work around the lack
of transparent_union support, and clang being a bit strict about
conflicting declarations).
llvm-svn: 51763
|
| |
|
|
|
|
|
|
|
|
| |
and union codepaths and fixes some minor bugs.
I'm reasonably confident this is accurate, at least for X86. I'll
correct any bugs as I find them; I haven't found any for a while,
though.
llvm-svn: 51762
|
| |
|
|
|
|
| |
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: 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: 51645
|
| |
|
|
| |
llvm-svn: 51622
|
| |
|
|
| |
llvm-svn: 51619
|
| |
|
|
| |
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
|