that says what why what we just asserted is wrong.

llvm-svn: 116333

deduction and the final substitution, but not while substituting the
explicit template arguments.  Fixes rdar://problem/8537391

llvm-svn: 116332

expanding the regular expression command.  So change the more stringent:

    self.expect(..., startstr = matching_string)

to:

    self.expect(..., substrs = [matched_string])

to pass the test.

llvm-svn: 116331

llvm-svn: 116330

argument deduction, make sure to check the correctness of deduced template
type arguments (which we had previously skipped) along with other
kinds of template arguments. This fixes part of PR6784, but we're
still swallowing the extension warning about unnamed/local template
arguments.

llvm-svn: 116327

has not yet been parsed, note that the default argument hasn't been
parsed and keep track of all of the instantiations of that function
parameter. When its default argument does get parsed, imbue the
instantiations with that default argument. Fixes PR8245.

llvm-svn: 116324

llvm-svn: 116323

llvm-svn: 116322

llvm-svn: 116321

Regular expression commands now print the command that results from expanding the regular expression command.

llvm-svn: 116320

llvm-svn: 116319

llvm-svn: 116318

llvm-svn: 116317

llvm-svn: 116316

shlib.

llvm-svn: 116315

The reg-reg copies were no longer being generated since copyPhysReg copies
physical registers only.

The loads and stores are not necessary - The TC constraint is imposed by the
TAILJMP and TCRETURN instructions, there should be no need for constrained loads
and stores.

llvm-svn: 116314

ARM instructions.

llvm-svn: 116313

llvm-svn: 116312

Manuel Klimek! Fixes PR7715.

llvm-svn: 116311

"-mattr=+vfp3" is specified. However, this will not work for hardware that
only supports 16 registers.  Add a new flag to support -"mattr=+vfp3,+d16".
Patch by Jan Voung!

llvm-svn: 116310

llvm-svn: 116309

llvm-svn: 116300

require them to have complete types.

llvm-svn: 116297

address that we've looked through.

Fixes compilation problems in tramp3d from earlier patch.

llvm-svn: 116296

function. It will inspect NAME and do the following:
- if the name contains '(' or starts with "-[" or "+[" then a full name search
  will happen to match full function names with args (C++ demangled names) or
  full objective C method prototypes.
- if the name contains "::" and no '(', then it is assumed to be a qualified
  function name that is in a namespace or class. For "foo::bar::baz" we will
  search for any functions with the basename or method name of "baz", then
  filter the results to only those that contain "foo::bar::baz". This allows
  setting breakpoint on C++ functions and methods without having to fully
  qualify all of the types that would appear in C++ mangled names.
- if the name contains ":" (not "::"), then NAME is assumed to be an ObjC
  selector.
_ otherwise, we assume just a plain function basename.

Now that "--name" is our "auto" mode, I introduced the new "--basename" option
("breakpoint set --basename NAME") to allow for function names that aren't 
methods or selectors, just basenames. This can also be used to ignore C++
namespaces and class hierarchies for class methods.

Fixed clang enumeration promotion types to be correct.

llvm-svn: 116293

llvm-svn: 116292

Made necessary edits to configure.ac and regenerated.

llvm-svn: 116291

being chopped up correctly). The DWARF plug-in also keeps a map of the ObjC
class names to selectors for easy parsing of all class selectors when we parse
the class type.

llvm-svn: 116290

llvm-svn: 116289

Patch by the "pax team"

llvm-svn: 116288

llvm-svn: 116287

The problem was that text files were open in text mode and Microsoft implementation of fread and write will try to do nasty line-feed conversion which make the line position no longer valid. The fix is to read and write files in binary mode.

llvm-svn: 116286

diagnostics produced by the driver itself. Previously, we were
allowing these to either be dropped or to slip through to stderr.

Fixes <rdar://problem/7595339>.

llvm-svn: 116285

llvm-svn: 116284

llvm-svn: 116283

llvm-svn: 116282

i.e. expressions with an internally-convenient type which should not be
appearing in generally valid, complete ASTs.

llvm-svn: 116281

llvm-svn: 116280

llvm-svn: 116279

llvm-svn: 116278