llvm-svn: 102468

llvm-svn: 102467

visible. Fixes the remaining two failures in Boost.ScopeExit.

llvm-svn: 102466

llvm-svn: 102465

function types.

This could potentially have unexpected side-effects, so look here if there are
new regressions.

llvm-svn: 102464

llvm-svn: 102463

keep track of whether we need to zero-initialize storage prior to
calling its constructor. Previously, we were only tracking this when
implicitly constructing the object (a CXXConstructExpr).

Fixes Boost's value-initialization tests, which means that the
Boost.Config library now passes all of its tests.

llvm-svn: 102461

llvm-svn: 102459

llvm-svn: 102456

- Catch more further dag combine opportunities as result of operand promotion, e.g. (i32 anyext (i16 trunc (i32 x))) -> (i32 x)

llvm-svn: 102455

Identify when a lexical scope is split in to multiple instruction ranges. Emit such ranges using DW_AT_ranges.
This patch fixes bug (PR6894) introduced by previous version of this patch.

llvm-svn: 102454

llvm-svn: 102453

we were relying on checking for abstract class types when an array
type was actually used to declare a variable, parameter, etc. However,
we need to check when the construct the array for, e.g., SFINAE
purposes (see DR337). Fixes problems with Boost's is_abstract type
trait. 

llvm-svn: 102452

UnresolvedLookupExpr and UnresolvedMemberExpr by substituting the
naming class we computed when building the expression in the
template...

... which we didn't always do correctly. Teach
UnresolvedMemberExpr::getNamingClass() all about the new 
representation of injected-class-names in templates, so	that it	can
return a naming	class that is the current instantiation.

Also, when decomposing a template-id into its template name and its
arguments, be sure to set the naming class on the LookupResult
structure. 

Fixes PR6947 the right way.

llvm-svn: 102448

llvm-svn: 102447

from AST, consider ivar array of objects
(per Doug's comment).

llvm-svn: 102446

llvm-svn: 102445

tag of the same name, compare the lookup contexts rather than the
actual contexts. Fixes PR6923.

llvm-svn: 102437

variables. Fixes PR6948.

llvm-svn: 102436

mysterious Elrood on IRC.

llvm-svn: 102435

expressions, be sure to set the naming class of the LookupResult
structure. Fixes PR6947.

llvm-svn: 102434

llvm-svn: 102432

llvm-svn: 102431

This works around stack corruption / crashes resulting from PR6944, and also
works around people who expect 'what works on my machine' to work everywhere
(GCC crashes in a number of cases on SPARC that should now work correctly with
clang).

llvm-svn: 102430

llvm-svn: 102429

should fix some "g++.dg-struct-layout-1" failures, 
rdar://7886017

llvm-svn: 102421

llvm-svn: 102420

llvm-svn: 102418

llvm-svn: 102417

of the dbg testsuite regressions.  I don't think this is
really the right fix; this change exposed an existing problem
upstream somewhere.

llvm-svn: 102410

with a qualifier referencing a different type.

llvm-svn: 102409

of a class template or class template partial specialization.  That is to
say, in
  template <class T> class A { ... };
or
  template <class T> class B<const T*> { ... };
make 'A<T>' and 'B<const T*>' sugar for the corresponding InjectedClassNameType
when written inside the appropriate context.  This allows us to track the
current instantiation appropriately even inside AST routines.  It also allows
us to compute a DeclContext for a type much more efficiently, at some extra
cost every time we write a template specialization (which can be optimized,
but I've left it simple in this patch).

llvm-svn: 102407

*not* declarations to *not* be placed in the "preserve" list.
<rdar://problem/7870735>

llvm-svn: 102405

in ISel fixed it.

llvm-svn: 102404

constructors or destructors, not used yet.

llvm-svn: 102403

add a version of createLowerInvokePass that allows the client
to specify whether it wants "expensive" or "cheap" lowering.

Patch by Alex Mac!

llvm-svn: 102402

llvm-svn: 102401

otherwise labels get incorrectly merged.  We handled this by emitting a 
".byte 0", but this isn't correct on thumb/arm targets where the text segment
needs to be a multiple of 2/4 bytes.  Handle this by emitting a noop.  This
is more gross than it should be because arm/ppc are not fully mc'ized yet.

This fixes rdar://7908505

llvm-svn: 102400

traps flowing through memory references, add some text to
better cover phi nodes and externally-visible side effects,
add an example of instructions being control-dependent
on a trap value, and reword some of the existing trap rules.

llvm-svn: 102399

llvm-svn: 102398