because trying to access non-existent ParamVarDecls can crash. 
Testcase from the original source for PR2414.

llvm-svn: 51960

llvm-svn: 51958

(http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080602/063306.html).

llvm-svn: 51944

llvm-svn: 51847

Patch by David Chisnall.

llvm-svn: 51840

much closer to passing the gcc struct layout tests.

It might be possible to refactor this a bit, but I'm not sure there's 
actually enough common code for that to be useful.

To get the calling convention completely correct, a bit of 
platform-specific code is necessary even for x86-Linux. On x86-Linux, the
alignment of function parameters is extremely strange; as far as I can tell,
it's always 4 except for SSE vectors or structs containing SSE vectors.  I'm 
continuing to investigate this.

llvm-svn: 51839

llvm-svn: 51838

llvm-svn: 51837

llvm-svn: 51836

Implemented by David Chisnall!

llvm-svn: 51835

llvm-svn: 51826

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

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

- #include ExprObjC.h in many places

llvm-svn: 51703

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: 51619

llvm-svn: 51596

llvm-svn: 51595

llvm-svn: 51587

been used.  In preparation for the fix to PR2360, but also a minor bug 
in its own right.

llvm-svn: 51583

llvm-svn: 51579

codegen of X86 long double.

llvm-svn: 51578

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

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

Also take care of freeing memory at the right places.

llvm-svn: 51553

llvm::Type::isSingleValueType. Currently these two functions have
the same behavior, but soon isFirstClassType will return true for
struct and array types.

Clang may some day want to use of isFirstClassType for some of
these some day as an optimization, but it'll require some
consideration.

llvm-svn: 51446