Introduce SourceManager::getDecomposedIncludedLoc, that returns the "included/expanded in" decomposed location of the given FileID.

The main benefit is to speed-up SourceManager::isBeforeInTranslationUnit which is common to query
the included/expanded location of the same FileID multiple times.

llvm-svn: 179435

llvm-svn: 179434

llvm-svn: 179433

llvm-svn: 179432

defines a Return Address register (e.g. lr on arm) but the RA register
hasn't been saved anywhere yet -- it is still in a live reg.
<rdar://problem/13503130> 

llvm-svn: 179431

local-extern redeclaration;  type refinements, default arguments,
etc. must all be locally scoped.

rdar://13535367

llvm-svn: 179430

 - We don't want to depend on the platforms stdint.h.

llvm-svn: 179429

llvm-svn: 179428

llvm-svn: 179427

llvm-svn: 179426

change intended.  Test case previously added in r178568.
Part of rdar://13611297

llvm-svn: 179425

semantics as __thread for now.

llvm-svn: 179424

llvm-svn: 179422

instructions.

llvm-svn: 179421

llvm-svn: 179420

implementation of C99's attempt to control the C++ standard. *sigh*


The C99 standard says that certain macros in <stdint.h>, such as SIZE_MAX,
should not be defined when the header is included in C++ mode, unless
__STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS are defined. The C++11 standard
says "Thanks, but no thanks" and C11 removed this rule, but various C library
implementations (such as glibc) follow C99 anyway.

g++ prior to 4.8 worked around the C99 / glibc behavior by defining
__STDC_*_MACROS in <cstdint>, which was incorrect, because <stdint.h> is
supposed to provide these macros too. g++ 4.8 works around it by defining
__STDC_*_MACROS in its builtin <stdint.h> header.

This change makes Clang act like g++ 4.8 in this regard: our <stdint.h> now
countermands any attempt by the C library to implement the undesired C99 rules,
by defining the __STDC_*_MACROS first. Unlike g++, we do this even in C++98
mode, since that was the intent of the C++ committee, matches the behavior
required in C11, and matches our built-in implementation of <stdint.h>.

llvm-svn: 179419

llvm-svn: 179418

Fixes PR15737.

llvm-svn: 179417

for variables in the new Materializer.  This is
much easier now that the ValueObject API is solid.

I still have to implement reading bytes into a
ValueObject, but committing what I have so far.

This code is not yet used, so there will be fixes
when I switch the expression parser over to use the
new Materializer.

llvm-svn: 179416

- use the TestCase option parsing
- dump output to stdout when no file is provided

llvm-svn: 179415

SLPVectorizer: add support for vectorization of diamond shaped trees. We now perform a preliminary traversal of the graph to collect values with multiple users and check where the users came from. 

llvm-svn: 179414

CostModel: increase the default cost of supported floating point operations from 1 to two. Fixed a few tests that changes because now the cost of one insert + a vector operation on two doubles is lower than two scalar operations on doubles.

llvm-svn: 179413

llvm-svn: 179412

<rdar://problem/13643854> Only emit ambiguous-expansion warnings when at least one of the macro definitions comes from a non-system header.

This slightly weakens the heuristic introduced in r178109.

llvm-svn: 179411

llvm-svn: 179410

patch by Veselov, Yuri <Yuri.Veselov@intel.com>.

llvm-svn: 179409

Ruben Van Boxem:  Turn islower_l and isupper_l into functions (instead of macros) on Windows only to quell a warning during libc++ building.

llvm-svn: 179408

when parsing MS-style inline assembly.  No functional change intended.

llvm-svn: 179407

We had been defining Neon intrinsics as "static" with always_inline attributes.
If you use them from an extern inline function, you get a warning, e.g.:

static function 'vadd_u8' is used in an inline function with external linkage

This change simply adds the inline keyword to avoid that warning.

llvm-svn: 179406

Made some fixes to the OperatingSystemPython class:
- If any thread dictionary contains any "core=N" key/value pairs then the threads obtained from the lldb_private::Process itself will be placed inside the ThreadMemory threads and will be used to get the information for a thread. 
- Cleaned up all the places where a thread inside a thread was causing problems

llvm-svn: 179405

llvm-svn: 179404

is a follow on to r179393 and r179399.  Test case to be added on
the clang side.
Part of rdar://13453209

llvm-svn: 179403

llvm-svn: 179402

llvm-svn: 179401

llvm-svn: 179400

is a follow on to r179393.  Test case to be added on the clang side.
Part of rdar://13453209

llvm-svn: 179399

According to the ARM reference manual, constant offsets are mandatory for pre-indexed addressing modes.
The MC disassembler was not obeying this when the offset is 0.
It was producing instructions like: str r0, [r1]!.
Correct syntax is: str r0, [r1, #0]!.

This change modifies the dumping of operands so that the offset is always printed, regardless of its value, when pre-indexed addressing mode is used.

Patch by Mihail Popa <Mihail.Popa@arm.com>

llvm-svn: 179398

Uses ConcRT and PPL on Windows.

llvm-svn: 179397

There are few cases where we can track the region, but cannot print the note,
which makes the testing limited. (Though, I’ve tested this manually by making
all regions non-printable.) Even though the applicability is limited now, the enhancement
will be more relevant as we start tracking more regions.

llvm-svn: 179396

llvm-svn: 179395