NeXt's -fno-constant-cfstrings - wip.

llvm-svn: 102189

input and output types when the smaller value isn't mentioned in the
asm string.  Extend this support from integers to also allowing 
fp values to be mismatched (if not mentioned in the asm string).

llvm-svn: 102188

permitted in C++ but not in C. Fixes PR6900. Clang can now handle all
of Boost.Lambda's regression tests.

llvm-svn: 102170

llvm-svn: 102168

  T::apply <U>::type

Fixes PR6899, although I want to dig a little deeper into the FIXME
for dependent template names that refer to operators.

llvm-svn: 102167

llvm-svn: 102160

llvm-svn: 102112

immediately narrowed the access size. Fix this (and previous case) by just
choosing a better access size up-front.

llvm-svn: 102068

we have to narrow the access side immediately (can happen with packed,
-fno-bitfield-type-align).

llvm-svn: 102067

llvm-svn: 102047

llvm-svn: 102046

IRgen: Rewrite bit-field access policy to not access data beyond the bounds of the structure, which we also now verify as part of the post-layout consistency checks.
 - This fixes some pedantic bugs with packed structures, as well as major problems with -fno-bitfield-type-align.

 - Fixes PR5591, PR5567, and all known -fno-bitfield-type-align issues.

 - Review appreciated.

llvm-svn: 102045

llvm-svn: 102044

in a throw expression.  Use EmitAnyExprToMem to emit the throw expression,
which magically elides the final copy-constructor call (which raises a new
strict-compliance bug, but baby steps).  Give __cxa_throw a destructor pointer
if the exception type has a non-trivial destructor.

llvm-svn: 102039

llvm-svn: 102033

exceeds the minimum ABI alignment.

llvm-svn: 102019

llvm-svn: 102015

non-bit-fields).

llvm-svn: 102014

llvm-svn: 102007

because EmitBranch actually clears the insert point.  This version
actually accomplishes what I initially wanted.

llvm-svn: 101998

(if there's a current block).  The chief advantage of doing this is that it
lets us pick blocks (e.g. EH blocks) to push to the end of the function so
that fallthrough happens consistently --- i.e. it gives us the flexibility
of ordering blocks as we please without having to change the order in which
we generate code.  There are standard (?) optimization passes which can do some
of that for us, but better to generate reasonable code to begin with.

llvm-svn: 101997

just to save the current insertion state!  This change significantly
simplifies the IR CFG in exceptions code.

llvm-svn: 101996

expressions, to improve source-location information, clarify the
actual receiver of the message, and pave the way for proper C++
support. The ObjCMessageExpr node represents four different kinds of
message sends in a single AST node:

  1) Send to a object instance described by an expression (e.g., [x method:5])
  2) Send to a class described by the class name (e.g., [NSString method:5])
  3) Send to a superclass class (e.g, [super method:5] in class method)
  4) Send to a superclass instance (e.g., [super method:5] in instance method)

Previously these four cases where tangled together. Now, they have
more distinct representations. Specific changes:

  1) Unchanged; the object instance is represented by an Expr*.

  2) Previously stored the ObjCInterfaceDecl* referring to the class
  receiving the message. Now stores a TypeSourceInfo* so that we know
  how the class was spelled. This both maintains typedef information
  and opens the door for more complicated C++ types (e.g., dependent
  types). There was an alternative, unused representation of these
  sends by naming the class via an IdentifierInfo *. In practice, we
  either had an ObjCInterfaceDecl *, from which we would get the
  IdentifierInfo *, or we fell into the case below...

  3) Previously represented by a class message whose IdentifierInfo *
  referred to "super". Sema and CodeGen would use isStr("super") to
  determine if they had a send to super. Now represented as a
  "class super" send, where we have both the location of the "super"
  keyword and the ObjCInterfaceDecl* of the superclass we're
  targetting (statically).

  4) Previously represented by an instance message whose receiver is a
  an ObjCSuperExpr, which Sema and CodeGen would check for via
  isa<ObjCSuperExpr>(). Now represented as an "instance super" send,
  where we have both the location of the "super" keyword and the
  ObjCInterfaceDecl* of the superclass we're targetting
  (statically). Note that ObjCSuperExpr only has one remaining use in
  the AST, which is for "super.prop" references.

The new representation of ObjCMessageExpr is 2 pointers smaller than
the old one, since it combines more storage. It also eliminates a leak
when we loaded message-send expressions from a precompiled header. The
representation also feels much cleaner to me; comments welcome!

This patch attempts to maintain the same semantics we previously had
with Objective-C message sends. In several places, there are massive
changes that boil down to simply replacing a nested-if structure such
as:

  if (message has a receiver expression) {
    // instance message
    if (isa<ObjCSuperExpr>(...)) {
     // send to super
    } else {
     // send to an object
   }
  } else {
    // class message
    if (name->isStr("super")) {
      // class send to super
    } else {
      // send to class
    }
  }

with a switch

  switch (E->getReceiverKind()) {
  case ObjCMessageExpr::SuperInstance: ...
  case ObjCMessageExpr::Instance: ...
  case ObjCMessageExpr::SuperClass: ...
  case ObjCMessageExpr::Class:...
  }

There are quite a few places (particularly in the checkers) where
send-to-super is effectively ignored. I've placed FIXMEs in most of
them, and attempted to address send-to-super in a reasonable way. This
could use some review.

llvm-svn: 101972

It is ok to have c++-ness inside extern "C" 
block. Fixes pr6644.

llvm-svn: 101948

llvm-svn: 101921

matches how we currently handle structs, and this correctly handles
-fno-bitfield-type-align.

llvm-svn: 101918

Fix a bug which triggered the assertion I added yesterday. Basically, when we initialize the vtable pointer for a virtual base, and there was another path from the most derived class to another base with the same class type, we would use the wrong base.

llvm-svn: 101911

llvm-svn: 101909

This mirror's Dan's patch for llvm-gcc in r97989, and
fixes the miscompilation in PR6525.  There is some contention
over whether this is the right thing to do, but it is the
conservative answer and demonstrably fixes a miscompilation.

llvm-svn: 101877

llvm-svn: 101872

Assert that the path from the derived to the base class in CodeGenFunction::GetAddressOfBaseClass is not ambiguous.

llvm-svn: 101869

function declaration, since it may end up being changed (e.g.,
"extern" can become "static" if a prior declaration was static). Patch
by Enea Zaffanella and Paolo Bolzoni.

llvm-svn: 101826

llvm-svn: 101815

llvm-svn: 101814

(related to radar 7866951).

llvm-svn: 101799

(related to PR6769).

llvm-svn: 101794

in for pre-snowleoprd (NeXt runtime). Fixes
radar 7866951

llvm-svn: 101791

llvm-svn: 101787

llvm-svn: 101786

llvm-svn: 101759