llvm-svn: 102483

llvm-svn: 102482

llvm-svn: 102481

of dependence and define trap values in terms of dependence, instead
of trying to cover the concept with a flurry of ad-hoc rules.

The dependence model isn't complete yet, but it's already much more
rigorous than the description it replaces.

llvm-svn: 102479

llvm-svn: 102478

llvm-svn: 102477

to not increase the alignment of globals with an assigned
alignment and section.

llvm-svn: 102476

it is not generally valid for targets to overalign
them when an alignment is specified.

llvm-svn: 102474

incomplete type.  Fixes PR6911.

llvm-svn: 102473

llvm-svn: 102472

llvm-svn: 102470

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