llvm-svn: 189699

Fixed a bug where diassembling an instruction that had a prefix would cause LLVM to identify a 1-byte instruction, but then upon querying it for that 1-byte instruction would cause an undefined opcode.

llvm-svn: 189698

llvm-svn: 189697

Hopefully fixes the Android build.

Differential Revision: http://llvm-reviews.chandlerc.com/D1551

llvm-svn: 189696

llvm-svn: 189695

 - We do some nasty things w.r.t. installing or overriding signal handlers in
   order to improve our crash recovery support or interaction with crash
   reporting software, and those things are not necessarily appropriate when
   LLVM is being linked into a client application that has its own ideas about
   how to do things. This gives those clients a way to disable that handling at
   build time.

 - Currently, the code this guards is all Apple specific, but other platforms
   might have the same concerns so I went for a more generic configure
   name. Someone who is more familiar with library embedding on Windows can
   handle choosing which of the Windows/Signals.inc behaviors might make sense
   to go under this flag.

 - This also fixes the proper autoconf'ing of ENABLE_BACKTRACES. The code
   expects it to be undefined when disabled, but the autoconf check was just
   defining it to 0.

llvm-svn: 189694

Fixes PR17025.

llvm-svn: 189693

 - The lit builtin XFAIL handling is more restrictive than what we were
   previously using, and for now I'd rather keep the lit one restrictive.

llvm-svn: 189692

llvm-svn: 189691

has hard float, when you compile the mips32 code you have to make sure
that it knows to compile any mips32 routines as hard float. I need to clean
up the way mips16 hard float is specified but I need to first think through
all the details. Mips16 always has a form of soft float, the difference being
whether the underlying hardware has floating point. So it's not really
necessary to pass the -soft-float to llvm since soft-float is always true
for mips16 by virtue of the fact that it will not register floating point
registers. By using this fact, I can simplify the way this is all handled.

llvm-svn: 189690

Massive simplification of how replacements and file overrides are handled by
the migrator:
* Sources and headers are all treated the same.
* All replacements for a given translation unit are stored in the same
  TranslationUnitReplacements structure.
* Change tracking is updated only from main file; no need for
  propagating "is tracking" flag around.
* Transform base class no longer responsible for applying replacements.
  They are simply stored and main() looks after deduplication and
  application.
* Renamed -yaml-only to -serialize-replacements. Same restrictions apply:
  Can only request one transform. New restriction: formatting cannot also
  be turned on since it's basically a transform.
* If -serialize-replacements is requested, changes to files will not be
  applied on disk.
* Changed behaviour of function generating names for serialized
  replacements: Only the main source file goes into the name of the file
  since a file may contain changes for multiple different files.
* Updated HeaderReplacements LIT test for new serialization behaviour.
  * Replaced old test that ensures replacements are not serialized if
    -serialize-replacements is not provided. New version ensures changes
    are made directly to all files in the translation unit.
* Updated unit tests.
  * Due to major simplification of structures in FileOverrides.h, the
    FileOverridesTest is quite a bit simpler now.

Differential Revision: http://llvm-reviews.chandlerc.com/D1545

llvm-svn: 189689

This will never happen in the analyzed code code, but can happen for checkers
that over-eagerly dereference pointers without checking that it's safe.
UnknownVal is a harmless enough value to get back.

Fixes an issue added in r189590, caught by our internal buildbot.

llvm-svn: 189688

is_destructible for function types was mistakenly returning true instead of false.  This is true in both C++11 and C++1y, but has been clarified by the post C++11 LWG issue 2049.

llvm-svn: 189687

If error is already set then there's no reason to replace it with a
generic "<file> does not exist" message.

llvm-svn: 189686

Remove redundant or bug-prone LiveInterval APIs.

llvm-svn: 189685

llvm-svn: 189684

llvm-svn: 189683

specified NSUInteger as the followup typedef.
With this change, NS_OPTIONS is only inferred
based on looking up how enumerators are speficied
(if they her hexadecimal, power of 2, or have
 bitwise constant expressions).

llvm-svn: 189682

Updating autoconf files to reflect changes to directory structure

llvm-svn: 189681

A FreeBSD implementation of Host::FindProcesses was added in r189295.
Contrary to my earlier report of failing tests it seems all attach by
name tests now pass.

http://www.llvm.org/pr16699

llvm-svn: 189680

llvm.org/pr16684

llvm-svn: 189679

llvm-svn: 189678

Yet another chunk of fast-isel code.  This one handles various
conversions involving floating-point.  (It also includes some
miscellaneous handling throughout the back end for LWA_32 and LWAX_32
that should have been part of the load-store patch.)

llvm-svn: 189677

Reduce the number of symbols by changing how templates are instantiated per function bound in the registry.

Summary:
Reduce the number of symbols by changing how templates are instantiated per function bound in the registry.
This change reduces the number of sections in Registry.cpp.o by a little over 10%.

Reviewers: klimek

CC: cfe-commits, revane

Differential Revision: http://llvm-reviews.chandlerc.com/D1557

llvm-svn: 189676

llvm-svn: 189675

llvm-svn: 189674

llvm-svn: 189673

PR17026. Also avoid undefined shifts and shift amounts larger than 64 bits
(those are always undef because we can't represent integer types that large).

llvm-svn: 189672

clang-replace is likely to move to clang proper one day soon. To facilitate
that move, renaming files and directory structure layout to ease transition for
users of clang-replace and libclangReplace.

For now, functionality still exists in clang::replace namespace. Header guards
and file comments updated.

Differential Revision: http://llvm-reviews.chandlerc.com/D1548

llvm-svn: 189671

llvm-svn: 189670

Currently this is just the atom model with SSE4.2 enabled.

llvm-svn: 189669

http://www.llvm.org/pr16697

llvm-svn: 189668

A FreeBSD implementation of Host::FindProcesses was added in r189295.
Note that some tests still fail as the implementation returns a truncated
name for processes with long names.

http://www.llvm.org/pr16699

llvm-svn: 189667

On Linux there is no separate notion of a process (vs. a thread) for
ptrace(); each thread needs to be individually detached.  On FreeBSD
we have a separate process context, and we detach just it.

Review: http://llvm-reviews.chandlerc.com/D1418
llvm-svn: 189666

llvm-svn: 189665

llvm-svn: 189664

Almost by accident, clang-format seems to be able to format protocol
buffer definitions (https://code.google.com/p/protobuf/).

The only change is that a space is required between numeric constants
and opening square brackets (for default values). While this might in
theory be used for array subscripts (int val = 4[MyArray]), I have not
seen this pattern in practice much. If this is wrong, we can make this
smarter in the future.

llvm-svn: 189663

Before:
  namespace n {
  enum Type {
    One,
    Two, // missing };
    int i;
  } void g() {
  }

After:
  namespace n {
  enum Type {
    One,
    Two, // missing };
    int i;
  }
  void g() {}

llvm-svn: 189662

This never really worked. Even if we find and execute link.exe in the VS bin dir
this way, link.exe wouldn't find the DLLs it needs, libraries, etc.

It also causes trouble when the user has multiple versions of VS installed,
one of them is in the path, but this code finds the other one (PR17041).

Revert until we can fix this properly.

> Windows ToolChain: add VS bin dir to PogramPaths
>
> We have a lot of fancy logic to find Visual Studio, which is currently used
> to set the system header include paths.
>
> Use the same code to set the ProgramPaths, which is used for finding programs
> such as link.exe. Previously, Clang would just search PATH for link.exe,
> but now it should find it if it's able to find Visual Studio.

llvm-svn: 189661

llvm-svn: 189660