in the near future.

llvm-svn: 103169

llvm-svn: 103168

this is generating correct but suboptimal (extra extend to double)
code for the float case.  Will investigate next.

llvm-svn: 103166

picking a more consistent pattern.

llvm-svn: 103142

function attributes like byval get applied to the function 
definition. This fixes PR7058 and makes i386 llvm/clang bootstrap 
pass all the same tests as x86-64 bootstrap for me (the llvmc 
tests still fail in both).

llvm-svn: 103131

of properties which are of C++ objects. Code Gen to follow
(Radar 7468090).

llvm-svn: 103123

reference type, make sure that the initializer we build is the
of the appropriate type for the *reference*, not for the thing that it
refers to. Fixes PR7050.

llvm-svn: 103115

destructors, place the __cxa_atexit call after the __cxa_guard_release
call, mimicking GCC/LLVM-GCC behavior. Noticed while debugging
something related.

llvm-svn: 103088

with no whitespace. This will allow statements to be referred to in
attribute TableGen files.

llvm-svn: 103087

whitespace which makes this patch unreadable. Will recommit without the
whitespace.

llvm-svn: 103086

implicitly-generated copy constructor. Previously, Sema would perform
some checking and instantiation to determine which copy constructors,
etc., would be called, then CodeGen would attempt to figure out which
copy constructor to call... but would get it wrong, or poke at an
uninstantiated default argument, or fail in other ways.

The new scheme is similar to what we now do for the implicit
copy-assignment operator, where Sema performs all of the semantic
analysis and builds specific ASTs that look similar to the ASTs we'd
get from explicitly writing the copy constructor, so that CodeGen need
only do a direct translation.

However, it's not quite that simple because one cannot explicit write
elementwise copy-construction of an array. So, I've extended
CXXBaseOrMemberInitializer to contain a list of indexing variables
used to copy-construct the elements. For example, if we have:

  struct A { A(const A&); };
  
  struct B {
    A array[2][3];
  };

then we generate an implicit copy assignment operator for B that looks
something like this:

  B::B(const B &other) : array[i0][i1](other.array[i0][i1]) { }

CodeGen will loop over the invented variables i0 and i1 to visit all
elements in the array, so that each element in the destination array
will be copy-constructed from the corresponding element in the source
array. Of course, if we're dealing with arrays of scalars or class
types with trivial copy-assignment operators, we just generate a
memcpy rather than a loop.

Fixes PR6928, PR5989, and PR6887. Boost.Regex now compiles and passes
all of its regression tests.

Conspicuously missing from this patch is handling for the exceptional
case, where we need to destruct those objects that we have
constructed. I'll address that case separately.

llvm-svn: 103079

llvm-svn: 103078

llvm-svn: 103077

llvm-svn: 103072

they're unreachable.  This matters because (if they're POD, or if this is C)
the scope containing the variable might be reachable even if the variable
isn't.  Fixes PR7044.

llvm-svn: 103052

llvm-svn: 103028

    typedef int functype(int, int);
    functype func;

also instantiate the synthesized function parameters for the resulting
function declaration. 

With this change, Boost.Wave builds and passes all of its regression
tests.

llvm-svn: 103025

(radar 7495203).

llvm-svn: 103022

not just the inner expression.  This is important if the expression has any
temporaries.  Fixes PR 7028.

Basically a symptom of really tragic method names.

llvm-svn: 102998

variabe. Blocks and their construction/destruction is
wip though. 

llvm-svn: 102985

variable.  Surprisingly, this does seem to be the right way to solve this.

llvm-svn: 102961

aggregate and the result of the aggregate is unused, bail out
early. Fixes PR7027.

llvm-svn: 102942

When computing the address of a virtual member function pointer, use the pointer width instead of hardcoding for 64-bit.

llvm-svn: 102921

llvm-svn: 102912

llvm-svn: 102891

llvm-svn: 102890

llvm-svn: 102889

llvm-svn: 102888

llvm-svn: 102887

llvm-svn: 102886

llvm-svn: 102885

llvm-svn: 102883

llvm-svn: 102882

llvm-svn: 102881

llvm-svn: 102880

llvm-svn: 102871

llvm-svn: 102870

llvm-svn: 102863

llvm-svn: 102862

assignment operators. 

Previously, Sema provided type-checking and template instantiation for
copy assignment operators, then CodeGen would synthesize the actual
body of the copy constructor. Unfortunately, the two were not in sync,
and CodeGen might pick a copy-assignment operator that is different
from what Sema chose, leading to strange failures, e.g., link-time
failures when CodeGen called a copy-assignment operator that was not
instantiation, run-time failures when copy-assignment operators were
overloaded for const/non-const references and the wrong one was
picked, and run-time failures when by-value copy-assignment operators
did not have their arguments properly copy-initialized.

This implementation synthesizes the implicitly-defined copy assignment
operator bodies in Sema, so that the resulting ASTs encode exactly
what CodeGen needs to do; there is no longer any special code in
CodeGen to synthesize copy-assignment operators. The synthesis of the
body is relatively simple, and we generate one of three different
kinds of copy statements for each base or member:

  - For a class subobject, call the appropriate copy-assignment
    operator, after overload resolution has determined what that is.
  - For an array of scalar types or an array of class types that have
    trivial copy assignment operators, construct a call to
    __builtin_memcpy.
  - For an array of class types with non-trivial copy assignment
    operators, synthesize a (possibly nested!) for loop whose inner
    statement calls the copy constructor.
  - For a scalar type, use built-in assignment.

This patch fixes at least a few tests cases in Boost.Spirit that were
failing because CodeGen picked the wrong copy-assignment operator
(leading to link-time failures), and I suspect a number of undiagnosed
problems will also go away with this change.

Some of the diagnostics we had previously have gotten worse with this
change, since we're going through generic code for our
type-checking. I will improve this in a subsequent patch.

llvm-svn: 102853