Also add some documentation.

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

llvm-svn: 188403

This replaces the old incomplete greylist functionality with an ABI
list, which can provide more detailed information about the ABI and
semantics of specific functions.  The pass treats every function in
the "uninstrumented" category in the ABI list file as conforming to
the "native" (i.e. unsanitized) ABI.  Unless the ABI list contains
additional categories for those functions, a call to one of those
functions will produce a warning message, as the labelling behaviour
of the function is unknown.  The other supported categories are
"functional", "discard" and "custom".

- "discard" -- This function does not write to (user-accessible) memory,
  and its return value is unlabelled.
- "functional" -- This function does not write to (user-accessible)
  memory, and the label of its return value is the union of the label of
  its arguments.
- "custom" -- Instead of calling the function, a custom wrapper __dfsw_F
  is called, where F is the name of the function.  This function may wrap
  the original function or provide its own implementation.

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

llvm-svn: 188402

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

llvm-svn: 188401

Otherwise it lists all files (e.g. shared libraries) that happen to be in the
same paths the GCC installations usually reside in.

On a x86_64 Debian 7 system with i386 multilibs.
before: clang -v 2>&1|wc -l
        3059
after:  clang -v 2>&1|wc -l
        10

llvm-svn: 188400

 - For whatever reason, we have a lot of test files with bogus unicode
   characters. This patch allows those scripts to still be parsed on Python3 by
   changing the parsing logic to work on binary files, and only require the
   actual script commands to be convertible to ascii.

 - This patch has been tweaked to now ensure that the command strings are not of
   unicode type on Python 2.6-7.

llvm-svn: 188398

This works around PR16830 in LLVM when self-hosting clang on Windows.

llvm-svn: 188397

llvm-svn: 188396

llvm-svn: 188395

For some reason doxygen doesn't seem to like the using namespace
clang::tooling in the source file and complaints about missing class
members.

Also fixed missing parameter documentation for TransformName in
SourceOverrides::applyReplacements().

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

llvm-svn: 188394

Patch by Matthias Braun!

llvm-svn: 188393

Patch by Matthias Braun!

llvm-svn: 188392

Patch by Matthias Braun!

llvm-svn: 188391

Patch by Matthias Braun!

llvm-svn: 188390

Patch by Matthias Braun!

llvm-svn: 188389

Patch by Matthias Braun!

llvm-svn: 188388

llvm-svn: 188387

llvm-svn: 188386

When determining if two different loads are from the same base address,
this patch allows one load to use a t2LDRi8 address mode and another to
use a t2LDRi12 address mode. The current implementation is very
conservative and this allows the case of differing Thumb2 byte loads to
be considered. Allowing these differing modes instead of forcing the exact
same opcode is useful for situations where one opcodes loads from a base
address+1 and a second opcode loads for a base address-1.

Patch by Daniel Stewart.

llvm-svn: 188385

 - Now fixed to ensure substitution value isn't of unicode type on Python 2.6-7.

llvm-svn: 188384

llvm-svn: 188383

llvm-svn: 188382

llvm-svn: 188381

llvm-svn: 188380

Revert r188376, "[lit] Support parsing scripts with inconsistent or invalid encodings.", this doesn't work yet for bots using the internal shell.

llvm-svn: 188379

llvm-svn: 188378

As Ben pointed out, GAS doesn't support this syntax so we should give at least
some warning that it might not be portable.

llvm-svn: 188377

 - For whatever reason, we have a lot of test files with bogus unicode
   characters. This patch allows those scripts to still be parsed on Python3 by
   changing the parsing logic to work on binary files, and only require the
   actual script commands to be convertible to ascii.

llvm-svn: 188376

llvm-svn: 188375

A missed clause in an error test added in r188371 caused any use of the
migrator requesting multiple transforms to fail.

llvm-svn: 188374

It caused "shell parser error" on win32 internal shell. ShParser doesn't expect unicode, but str.

llvm-svn: 188373

Somehow I forgot to test one of the error conditions I'd added.

llvm-svn: 188372

For use with -headers, -yaml-only will cause cpp11-migrate to not write header
changes to disk and instead write them as header change description files. This
option facilitiates upcoming functionality to properly support changing headers
as part of migration.

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

llvm-svn: 188371

It's useful to be able to write down floating-point numbers without having to
worry about what they'll be rounded to (as C99 discovered), this extends that
ability to the MC assembly parsers.

llvm-svn: 188370

This change moves everything depending on kernel headers (mostly ioctl types
and ids) into a separate source file. This will reduce the possibility of
header conflict on various platforms (most importantly, older glibc versions).

This change also removes 2 deprecated ioctls, and symbolic ids for other bunch
of ambiguous ioctls (i.e. same id is shared by ioctls with different memory
behavior).

llvm-svn: 188369

Found by -Wdocumentation.

llvm-svn: 188368

extremely subtle miscompilations (such as a load getting replaced with
the value stored *below* the load within a basic block) related to
promoting an alloca to an SSA value, there is the dim possibility that
you hit this. Please let me know if you won this unfortunate lottery.

The first half of mem2reg's core logic (as it is used both in the
standalone mem2reg pass and in SROA) builds up a mapping from
'Instruction *' to the index of that instruction within its basic block.
This allows quickly establishing which store dominate a particular load
even for large basic blocks. We cache this information throughout the
run of mem2reg over a function in order to amortize the cost of
computing it.

This is not in and of itself a strange pattern in LLVM. However, it
introduces a very important constraint: absolutely no instruction can be
deleted from the program without updating the mapping. Otherwise a newly
allocated instruction might get the same pointer address, and then end
up with a wrong index. Yes, LLVM routinely suffers from a *single
threaded* variant of the ABA problem. Most places in LLVM don't find
avoiding this an imposition because they don't both delete and create
new instructions iteratively, but mem2reg *loves* to do this... All the
time. Fortunately, the mem2reg code was really careful about updating
this cache to handle this eventuallity... except when it comes to the
debug declare intrinsic. Oops. The fix is to invalidate that pointer in
the cache when we delete it, the same as we do when deleting alloca
instructions and other instructions.

I've also caused the same bug in new code while working on a fix to
PR16867, so this seems to be a really unfortunate pattern. Hopefully in
subsequent patches the deletion of dead instructions can be consolidated
sufficiently to make it less likely that we'll see future occurences of
this bug.

Sorry for not having a test case, but I have literally no idea how to
reliably trigger this kind of thing. It may be single-threaded, but it
remains an ABA problem. It would require a really amazing number of
stars to align.

llvm-svn: 188367

llvm-svn: 188366

llvm-svn: 188365

llvm-svn: 188364

llvm-svn: 188363