llvm-svn: 147027

Fix a case where Expr::isConstantInitializer would return true for an expression we can't support.  In a slightly amusing twist, the case in question was already in the clang regression tests marked as a valid construct.  <rdar://problem/10020074>

llvm-svn: 147026

llvm-svn: 147025

The patch and test case were originally written by Mans Rullgard.

llvm-svn: 147024

members of class templates so that their values can be used in ICEs. This
required reverting r105465, to get such instantiated members to be included in
serialized ASTs.

llvm-svn: 147023

case for DCLO and DCLZ.

llvm-svn: 147022

llvm-svn: 147021

on method declaration and definition if former is in
a system header. // rdar://10580333

llvm-svn: 147020

llvm-svn: 147019

llvm-svn: 147018

DSHD (Double Swap Halfwords within Doublewords). Add a pattern which replaces
64-bit bswap with a DSBH and DSHD pair.

llvm-svn: 147017

types that have been imported multiple times.

The discussion below uses this diagram:

ASTContext     A      B      C
Decl           Da     Db     Dc
ASTImporter    \-Iab-/\-Iac-/
               \-----Iac----/

When a Decl D is imported from ASTContext A to
ASTContext B, the ASTImporter Iab records the
pair <Da, Db> in a DenseMap.  That way, if Iab
ever encounters Da again (for example, as the
DeclContext for another Decl), it can use the
imported version.  This is not an optimization,
it is critical: if I import the field "st_dev"
as part of importing "struct stat," the field
must have DeclContext equal to the parent
structure or we end up with multiple different
Decls containing different parts of "struct
stat."  "struct stat" is imported once and
recorded in the DenseMap; then the ASTImporter
finds that same version when looking for the
DeclContext of "st_dev."

The bug arises when Db is imported into another
ASTContext C and ASTContext B goes away.  This
often occurs when LLDB produces result variables
for expressions.  Ibc is aware of the transport
of Db to Dc, but a brand new ASTImporter, Iac,
is responsible for completing Dc from its source
upon request.  That ASTImporter has no mappings,
so it will produce a clone of Dc when attempting
to import its children.  That means that type
completion operations on Dc will fail.

The solution is to create Iac as soon as Ibc
imports D from B to C, and inform Iac of the
mapping between Da and Dc.  This allows type
completion to happen correctly.

llvm-svn: 147016

instruction supported by mips32r2, and add a pattern which replaces bswap with
a ROTR and WSBH pair.
 
WSBW is removed since it is not an instruction the current architectures
support.

llvm-svn: 147015

llvm-svn: 147014

llvm-svn: 147013

llvm-svn: 147012

llvm-svn: 147011

the build bot in some cases.  The basic issue happens when a source module contains
both a "%foo" type and a "%foo.42" type.  It will see the later one, check to see if
the destination module contains a "%foo" type, and it will return true... because
both the source and destination modules are in the same LLVMContext.  We don't want
to map source types to other source types, so don't do the remapping if the mapped
type came from the source module.

Unfortunately, I've been unable to reduce a decent testcase for this, kc++ is 
pretty great that way.

llvm-svn: 147010

llvm-svn: 147009

nodes needed for multiplication. Add code for selecting 64-bit MULHS and MULHU
nodes.

llvm-svn: 147008

llvm-svn: 147007

reasonable-looking but ill-formed for-range statement of the form:

  for (expression : expression)

llvm-svn: 147006

llvm-svn: 147005

llvm-svn: 147004

llvm-svn: 147003

type is a pointer to const. (radar://10595327)

The regions corresponding to the pointer and reference arguments to
a function get invalidated by the calls since a function call can
possibly modify the pointed to data. With this change, we are not going
to invalidate the data if the argument is a pointer to const. This
change makes the analyzer more optimistic in reporting errors.
(Support for C, C++ and Obj C)

llvm-svn: 147002

only when the target ABI is N64.

llvm-svn: 147001

llvm-svn: 147000

MIPS64 can generate constant +0.0 with a single DMTC1 instruction. 

llvm-svn: 146999

in class method instead of crash. // rdar://10593227

llvm-svn: 146998

Use the spill slot alignment as well as the local variable alignment to
determine when the stack needs to be realigned. This works now that the
ARM target can always realign the stack by using a base pointer.

Still respect the ARMBaseRegisterInfo::canRealignStack() function
vetoing a realigned stack.  Don't use aligned spill code in that case.

llvm-svn: 146997

llvm-svn: 146996

llvm-svn: 146995

notify the AST deserialization listener so that the AST writer knows
that it can write the macro definition.

llvm-svn: 146994

llvm-svn: 146993

only when the target ABI is N64. 

llvm-svn: 146992

llvm-svn: 146990

llvm-svn: 146989

llvm-svn: 146988

llvm-svn: 146987