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

Fix some strict-aliasing warnings by using Stmt* instead of Expr* in 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