llvm-svn: 93190

llvm-svn: 93189

they redefine is a class-name but not a typedef-name, per C++0x
[dcl.typedef]p4. The code in the test was valid C++98 and is valid
C++0x, but an unintended consequence of DR56 made it ill-formed in
C++03 (which we were luck enough to implement). Fixes PR5455.

llvm-svn: 93188

Shorten up this testcase.

llvm-svn: 93187

(fixes radar 6948022)

llvm-svn: 93186

llvm-svn: 93185

This fixes PR5980.

llvm-svn: 93184

llvm-svn: 93183

llvm-svn: 93182

llvm-svn: 93181

loads are not in the default address space because the transformation discards src value info.

llvm-svn: 93180

add a fixme.

llvm-svn: 93179

function, be sure to adjust the resulting argument type to a pointer
(if necessary). Fixes PR5910 and PR5949.

llvm-svn: 93178

llvm-svn: 93177

llvm-svn: 93175

llvm-svn: 93174

for all visible conversion functions.

llvm-svn: 93173

llvm-svn: 93172

llvm-svn: 93171

documentation.

Patch by Dustin Laurence!

llvm-svn: 93170

llvm-svn: 93169

llvm-svn: 93168

convention. 

llvm-svn: 93167

templates. Previously, a little thinko in the code that replaced a
conversion function template with its redeclaration was causing some
very weird lookup behavior.

llvm-svn: 93166

llvm-svn: 93165

say either "array type" or "function type", whichever it is. No reason
to make the user guess.

llvm-svn: 93164

have a fix.

llvm-svn: 93163

(C++ [temp.mem]p5-6), which involves template argument deduction based
on the type named, e.g., given

  struct X { template<typename T> operator T*(); } x;

when we call

  x.operator int*();

we perform template argument deduction to determine that T=int. This
template argument deduction is needed for template specialization and
explicit instantiation, e.g.,

  template<> X::operator float*() { /* ... */ }

and when calling or otherwise naming a conversion function (as in the
first example). 

This fixes PR5742 and PR5762, although there's some remaining ugliness
that's causing out-of-line definitions of conversion function
templates to fail. I'll look into that separately.

llvm-svn: 93162

- getToken is modeled after StringRef::split but it can split on multiple
  separator chars and skips leading seperators.
- SplitString is a StringRef::split variant for more than 2 elements with the
  same behaviour as getToken.

llvm-svn: 93161

has an immediate with at least 32 bits of leading zeros, to avoid needing to
materialize that immediate in a register first.

FileCheckize, tidy, and extend a testcase to cover this case.

This fixes rdar://7527390.

llvm-svn: 93160

in a function. Fixes radar 7522803.

llvm-svn: 93159

new AsmPrinter. This is perhaps less elegant than describing them
in terms of MOV32r0 and subreg operations, but it allows the
current register to rematerialize them.

llvm-svn: 93158

llvm-svn: 93157

llvm-svn: 93156

single user. The _su forms are intended for non-top-level nodes.

llvm-svn: 93155

llvm-svn: 93154

"ASTContext::getTypeSize() / 8". Replace [u]int64_t variables with CharUnits
ones as appropriate. 

Also rename RawType, fromRaw(), and getRaw() in CharUnits to QuantityType, 
fromQuantity(), and getQuantity() for clarity.

llvm-svn: 93153

Select an OR with immediate as an ADD if the input bits are known zero. This allow the instruction to be 3address-fied if needed.

llvm-svn: 93152

Implement a feature (-vector-unaligned-mem) to allow targets to
ignore alignment requirements for SIMD memory operands.  This
is useful on architectures like the AMD 10h that do not trap on
unaligned references if a status bit is twiddled at startup time.

llvm-svn: 93151

llvm-svn: 93150