llvm-svn: 187441

This is a follow up patch for r187390 to implement the parser for the
Windows-style command line. This should follow the rule as described
at http://msdn.microsoft.com/en-us/library/windows/desktop/17w5ykft(v=vs.85).aspx

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

llvm-svn: 187430

This will let us use getUniqueID instead of st_dev directly on clang.

llvm-svn: 187378

IEEE-754R 1.4 Exclusions states that IEEE-754R does not specify the
interpretation of the sign of NaNs. In order to remove an irrelevant
variable that most floating point implementations do not use,
standardize add, sub, mul, div, mod so that operating anything with
NaN always yields a positive NaN.

In a later commit I am going to update the APIs for creating NaNs so
that one can not even create a negative NaN.

llvm-svn: 187314

llvm-svn: 187286

Adds unit tests for it too.

Split BasicBlockUtils into an analysis-half and a transforms-half, and put the
analysis bits into a new Analysis/CFG.{h,cpp}. Promote isPotentiallyReachable
into llvm::isPotentiallyReachable and move it into Analysis/CFG.

llvm-svn: 187283

This reverts commit r187248. It broke many bots.

llvm-svn: 187254

Both GCC and LLVM will implicitly define __ppc__ and __powerpc__ for
all PowerPC targets, whether 32- or 64-bit.  They will both implicitly
define __ppc64__ and __powerpc64__ for 64-bit PowerPC targets, and not
for 32-bit targets.  We cannot be sure that all other possible
compilers used to compile Clang/LLVM define both __ppc__ and
__powerpc__, for example, so it is best to check for both when relying
on either inside the Clang/LLVM code base.

This patch makes sure we always check for both variants.  In addition,
it fixes one unnecessary check in lib/Target/PowerPC/PPCJITInfo.cpp.
(At least one of __ppc__ and __powerpc__ should always be defined when
compiling for a PowerPC target, no matter which compiler is used, so
testing for them is unnecessary.)

There are some places in the compiler that check for other variants,
like __POWERPC__ and _POWER, and I have left those in place.  There is
no need to add them elsewhere.  This seems to be in Apple-specific
code, and I won't take a chance on breaking it.

There is no intended change in behavior; thus, no test cases are
added.

llvm-svn: 187248

llvm-svn: 187124

    Similar to ARM change r182800, dynamic linker will read bits/addends from
    the original object rather than from the object that might have been patched
    previously. For the purpose of relocations for MCJIT stubs on MIPS, we
    internally use otherwise unused MIPS relocations.
    
    The change also enables MCJIT unit tests for MIPS (EL/BE), and the following
    two tests now pass:
    
    - MCJITTest.return_global and
    - MCJITTest.multiple_functions.
    
    These issues have been tracked as Bug 16250.

    Patch by Petar Jovanovic.

llvm-svn: 187019

Run in two different modes: with and without reopening the temporary file
between creating it and mapping it with MemoryBuffer.

llvm-svn: 186986

The main observation is that we never need both the filesize and the map size.
When mapping a slice of a file, it doesn't make sense to request a null
terminator and that would be the only case where the filesize would be used.

There are other cleanups that should be done in this area:

* A client should not have to pass the size (even an explicit -1) to say if
  it wants a null terminator or not, so we should probably swap the argument
  order.
* The default should be to not require a null terminator. Very few clients
  require this, but many end up asking for it just because it is the default.

llvm-svn: 186984

llvm-svn: 186887

Option aliases in option groups were previously disallowed by an assert.
As far as I can tell, there was no technical reason for this, and I would
like to be able to put cl.exe compatible options in their own group for Clang,
so let's change the assert.

llvm-svn: 186838

Previously, they were only built and run in the CMake build.

llvm-svn: 186756

llvm-svn: 186704

llvm-svn: 186676

The plan is to use it for clang and lld.

Major behavior changes:
- We can now parse UTF-16 files that have a byte order mark.
- PR16209: Don't drop backslashes on the floor if they don't escape
  anything.

The actual parsing loop was based on code from Clang's driver.cpp,
although it's been rewritten to track its state with control flow rather
than state variables.

Reviewers: hans

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

llvm-svn: 186587

llvm-svn: 186561

We don't want cast and dyn_cast to work on temporaries. They don't extend
lifetime like a direct bind to a reference would, so they can introduce
hard to find bugs.

I added tests to make sure we don't regress this. Thanks to Eli Friedman for
noticing this and for his suggestions on how to test it.

llvm-svn: 186559

There were a couple of different loops that were not handling
'.' correctly in APFloat::convertFromHexadecimalString; these mistakes
could lead to assertion failures and incorrect rounding for overlong
hex float literals.

Fixes PR16643.

llvm-svn: 186539

This centralizes the handling of O_BINARY and opens the way for hiding more
differences (like how open behaves with directories).

llvm-svn: 186447

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

llvm-svn: 186431

This is to support parsing UTF16 response files in LLVM/lib/Option for
lld and clang.

Reviewers: hans

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

llvm-svn: 186426

llvm-svn: 186375

llvm-svn: 186372

llvm-svn: 186264

It is failing with

YAMLTest.cpp:38:   instantiated from here
YAMLTraits.h:226: error: 'llvm::yaml::MappingTraits<<unnamed>::BinaryHolder>::mapping' is not a valid template argument for type 'void (*)(llvm::yaml::IO&, <unnamed>::BinaryHolder&)' because function 'static void llvm::yaml::MappingTraits<<unnamed>::BinaryHolder>::mapping(llvm::yaml::IO&, <unnamed>::BinaryHolder&)' has not external linkage

llvm-svn: 186245

llvm-svn: 186123

A special case list can now specify categories for specific globals,
which can be used to instruct an instrumentation pass to treat certain
functions or global variables in a specific way, such as by omitting
certain aspects of instrumentation while keeping others, or informing
the instrumentation pass that a specific uninstrumentable function
has certain semantics, thus allowing the pass to instrument callers
according to those semantics.

For example, AddressSanitizer now uses the "init" category instead of
global-init prefixes for globals whose initializers should not be
instrumented, but which in all other respects should be instrumented.

The motivating use case is DataFlowSanitizer, which will have a
number of different categories for uninstrumentable functions, such
as "functional" which specifies that a function has pure functional
semantics, or "discard" which indicates that a function's return
value should not be labelled.

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

llvm-svn: 185978

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

llvm-svn: 185977

Previously, it would simply output nothing, but it should output an
empty string `""`.

llvm-svn: 185894

llvm-svn: 185834

llvm-svn: 185730

llvm-svn: 185719

Use SmallVectorImpl::iterator/const_iterator instead of SmallVector to avoid specifying the vector size.

llvm-svn: 185606

llvm-svn: 185443

llvm-svn: 185421

rdar://14323230

llvm-svn: 185397

Thename says it's an i32*, but it was actually creating another i8*

llvm-svn: 185239