type of the builtin when generating the function declaration for a builtin
library call.

llvm-svn: 90936

in objective-c++ mode without being too lenient.

llvm-svn: 90895

llvm-svn: 90884

llvm-svn: 90882

 - This fixes 2003-05-21-BitfieldHandling.

llvm-svn: 90876

llvm-svn: 90856

llvm-svn: 90854

llvm-svn: 90851

Template instantiation can re-use DeclRefExprs.

llvm-svn: 90848

llvm-svn: 90841

pointer.

llvm-svn: 90840

llvm-svn: 90832

llvm-svn: 90831

llvm-svn: 90825

or non-record aggregate members.

It might be worth spending some time to optimize this code (and the parallel
code for copy constructors) to memcpy in larger chunks, rather than copying
one member at a time.  Not sure exactly how beneficial that would be, but
it seems like could help for large classes with, for example, a vtable pointer
forcing the generation of a copy constructor.

llvm-svn: 90823

llvm-svn: 90822

llvm-svn: 90821

No need to add tail padding if the resulting LLVM struct type will have the same size as the final record size.

llvm-svn: 90820

(Yes, I do intend to commit some tests for this.)

llvm-svn: 90818

llvm-svn: 90817

llvm-svn: 90800

llvm-svn: 90799

llvm-svn: 90796

llvm-svn: 90794

llvm-svn: 90780

llvm-svn: 90778

llvm-svn: 90751

(although it does pass regression tests).

llvm-svn: 90747

more accurate.

llvm-svn: 90746

llvm-svn: 90745

llvm-svn: 90723

generation, and make sure we generate thunks when the function is defined
rather than when the vtable is defined.

llvm-svn: 90722

llvm-svn: 90711

llvm-svn: 90709

llvm-svn: 90689

llvm-svn: 90687

Pass the desired vtable linkage to GenerateVtable directly. Only call MaybeMarkVirtualImplicitMembersReferenced for non-inline functions.

llvm-svn: 90686

llvm-svn: 90684

Only emit the vtable definition if the class has a key function and we're emitting it, or if the class doesn't have a key function and we are emitting the complete constructor.

llvm-svn: 90681

llvm-svn: 90680