llvm-svn: 183264

llvm-svn: 183263

llvm-svn: 183262

llvm-svn: 183261

llvm-svn: 183260

llvm-svn: 183259

llvm-svn: 183258

Add some generic SchedWrites and assign resources for Swift and Cortex A9.

llvm-svn: 183257

An instruction with less than 3 inputs is trivially a fast immediate shift.

llvm-svn: 183256

Don't output data if we are supposed to ignore the record.

llvm-svn: 183255

Formatters for unsigned char* and const variant

llvm-svn: 183254

llvm-svn: 183253

llvm-svn: 183252

No functionality change, covered by the existing virtual base adjustment
tests.

llvm-svn: 183251

llvm-svn: 183250

llvm-svn: 183248

Accept mach-o files with bad segments. Many core files are not created correctly and we should still be able to glean any information we can from them.

llvm-svn: 183247

LLDB API versioning
This checkin makes the LLDB API versioned
We are starting at version 1.0 and will then revise and update the API from there
Further details:
 API versioning
---------------------------------

The LLDB API is versioned independently of the LLDB source base
Our API version numbers are composed of a major and a minor number

The major number means a complete and stable revision of the API. Major numbers are compatibility breakers
(i.e. when we change the API major number, there is no promise of compatibility with the previous major version
 and we are free to remove and/or change any APIs)
Minor numbers are a work-in-progress evolution of the API. APIs will not be removed or changed across minor versions
(minors do not break compatibility). However, we can deprecate APIs in minor versions or add new APIs in minor versions
A deprecated API is supposedly going to be removed in the next major version and will generate a warning if used
APIs we add in minor versions will not be removed (at least until the following major) but they might theoretically be deprecated
in a following minor version
Users are discouraged from using the LLDB version number to test for API features and should instead use the API version checking
as discussed below

 API version checking
---------------------------------

You can (optionally) sign into an API version checking feature
To do so you need to define three macros:
LLDB_API_CHECK_VERSIONING - define to any value (or no value)
LLDB_API_MAJOR_VERSION_WANTED - which major version of the LLDB API you are targeting
LLDB_API_MINOR_VERSION_WANTED - which minor version of the LLDB API you are targeting

If these macros exist - LLDB will enable version checking of the public API

If LLDB_API_MAJOR_VERSION is not equal to LLDB_API_MAJOR_VERSION_WANTED we will immediately halt your compilation with an error
This is by design, since we do not make any promise of compatibility across major versions - if you really want to test your luck, disable the versioning altogether

If the major version test passes, you have signed up for a specific minor version of the API
Whenever we add or deprecate an API in a minor version, we will mark it with either
LLDB_API_NEW_IN_DOT_x - this API is new in LLDB .x
LLDB_API_DEPRECATED_IN_DOT_x - this API is deprecated as of .x

If you are using an API new in DOT_x
 if LLDB_API_MINOR_VERSION_WANTED >= x then all is well, else you will get a compilation error
  This is meant to prevent you from using APIs that are newer than whatever LLDB you want to target

If you are using an API deprecated in DOT_x
 if LLDB_API_MINOR_VERSION_WANTED >= x then you will get a compilation warning, else all is well
 This is meant to let you know that you are using an API that is deprecated and might go away

 Caveats
---------------------------------

Version checking only works on clang on OSX - you will get an error if you try to enable it on any other OS/compiler
If you want to enable version checking on other platforms, you will need to define appropriate implementations for
LLDB_API_IMPL_DEPRECATED and LLDB_API_IMPL_TOONEW and any other infrastructure your compiler needs for this purpose

We have no deprecation-as-error mode

There is no support for API versioning in Python

We reserve to use macros whose names begin with LLDB_API_ and you should not use them in your source code as they might conflict
with present or future macro names we are using to implement versioning


For API implementors:
If you need to add a new public API call, please remember to add the LLDB_API_NEW_IN_DOT_x marker in the header file
and when you are done with adding stuff, to also update LLDB_API_MINOR_VERSION
If you want to remove a function, deprecate it first, by using LLDB_API_DEPRECATED_IN_DOT_x
and when you are done with deprecating stuff, to also update LLDB_API_MINOR_VERSION
A new major version (LLDB_API_MAJOR_VERSION++) is your only chance to remove and/or change API calls
but is probably quite a big deal and you might want to consider deprecating the existing calls for a while
before doing your changes

A couple more caveats:
Currently, the lldb-tool does NOT use the version checking feature. It would be a nice future improvement to make it do that, once we have proper version checking on other OSs
APIs marked as deprecated by a comment in the source are still deprecated just that way. A good purpose for API 1.1 might be to deprecate them with appropriate markers

llvm-svn: 183244

llvm-svn: 183243

[libclang] When annotating tokens, don't override a property annotation with a getter/setter method annotation.

rdar://13764549

llvm-svn: 183242

IndVarSimplify is willing to move divide instructions outside of their
loop bodies if they are invariant of the loop.  However, it may not be
safe to expand them if we do not know if they can trap.

Instead, check to see if it is not safe to expand the instruction and
skip the expansion.

This fixes PR16041.

Testcase by Rafael Ávila de Espíndola.

llvm-svn: 183239

The ARM backend did not expect LDRBi12 to hold a constant pool operand.
Allow for LLVM to deal with the instruction similar to how it deals with
LDRi12.

This fixes PR16215.

llvm-svn: 183238

Consider the case where a SwitchStmt satisfied isAllEnumCasesCovered()
as well as having no cases at all (i.e. the enum it covers has no
enumerators).

In this case, we should add a successor to repair the CFG.

This fixes PR16212.

llvm-svn: 183237

Summary:
There's Lexer::getBufferStart(), and we need getBufferEnd() to access
the whole input buffer in clang::format::reformat. We don't want to
rely on the fact that the Lexer::BufferEnd always points to '\0', as there can
be embedded '\0's as well.

Reviewers: jordan_rose

Reviewed By: jordan_rose

CC: cfe-commits

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

llvm-svn: 183236

arrays of empty structs. // rdar://14053082
(also pr13062).

llvm-svn: 183234

- link libexecinfo (as libc is missing backtrace())
- enable FreeBSD-specific plugins

Patch by Ed Maste!

llvm-svn: 183233

Summary:
 Parser/Registry argument enhancements.
  - 2 argument support.
  - unsigned values support.

Reviewers: klimek

CC: cfe-commits, revane

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

llvm-svn: 183231

Specifying the load address for Darwin i386 dylibs was a performance
optimization for dyld that is not relevant for x86_64 or arm. We can just
remove this now.

llvm-svn: 183230

llvm-svn: 183229

llvm-svn: 183228

This enables changing clang-check to get extra arguments.

Patch by Pavel Labath.

llvm-svn: 183227

The problem this time seems to be a thinko. We were assuming that in the CFG

A
| \
|  B
| /
C

speculating the basic block B would cause only the phi value for the B->C edge
to be speculated. That is not true, the phi's are semantically in the edges, so
if the A->B->C path is taken, any code needed for A->C is not executed and we
have to consider it too when deciding to speculate B.

llvm-svn: 183226

llvm-svn: 183225

llvm-svn: 183224

llvm-svn: 183223

Template functions (and member functions of class templates) present the same
problem as inline functions. They need to be uniqued, so we need to assign
VisibleNoLinkage linkage to types defined in them.

llvm-svn: 183222

llvm-svn: 183221

Summary:
With this change, the user may safely call __asan_get_ownership()
from malloc/free hooks and assume it would return "true". If there is a
realloc/free race, free hook might be called twice, but I think it's acceptable,
as it's a data race and would later be reported anyway.

This change also fixes a bug when failing realloc incorrectly marked the
original memory as "quarantinned".

Reviewers: timurrrr, kcc, samsonov

Reviewed By: samsonov

CC: llvm-commits

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

llvm-svn: 183220

llvm-svn: 183219

llvm-svn: 183218