llvm-svn: 175829

On x86-64 platforms, the small code model assumes that code will be loaded below the 2GB boundary.  With the static relocation model, the fact that the expression code is initially loaded (in the LLDB debugger address space) above that boundary causes problems.  Switching to the JITDefault code model causes the large code model to be used for 64-bit targets and small code model of 32-bit targets.

llvm-svn: 175828

for explicit member specializations.

llvm-svn: 175827

Post commit review feedback on r175812 from Jordan Rose.

llvm-svn: 175826

Post commit review feedback on r175812 from Jordan Rose.

llvm-svn: 175825

llvm-svn: 175824

llvm-svn: 175823

llvm-svn: 175822

pass. One of the callers of isKilled() can cope with overapproximation of kills
and the other can't, so I added a flag to indicate this.

In theory this could pessimize code slightly, but in practice most physical
register uses are kills, and most important kills of physical registers are the
only uses of that register prior to register allocation, so we can recognize
them as kills even without kill flags.

This is relevant because LiveIntervals gets rid of all kill flags.

llvm-svn: 175821

to lib/DebugInfo, with dumping in llvm-dwarfdump. This patch adds
initial ability to parse and dump CFA instructions contained in
entries.

To keep it manageable, the patch omits some more advanced capabilities
(accounted in TODOs):

* Parsing of instructions with BLOCK arguments (expression lists)
* Dumping of actual instruction arguments (currently only names are
dumped). This is quite tricky since the dumper has to effectively
"interpret" the instructions.

llvm-svn: 175820

After cleaning up the following type hierarchies:
  * TypeLoc: r175462
  * SVal: r175594
  * CFGElement: r175462
  * ProgramPoint: r175812
that all invoked undefined behavior by causing a derived copy construction of a
base object through an invalid cast (thus supporting code that relied on
casting temporaries that were direct base objects) Clang/LLVM is now clean of
casts of temporaries. So here's some fun SFINAE machinery (courtesy of Eli
Friedman, with some porting back from C++11 to LLVM's traits by me) to cause
compile-time failures if llvm::cast & friends are ever passed an rvalue.

This should avoid a repeat of anything even remotely like PR14321/r168124.

Thanks to Jordan Rose for the help with the various Static Analyzer related
hierarchies that needed cleaning up, Eli for the SFINAE, Richard Smith, John
McCall, Ted Kremenek, and Anna Zaks for their input/reviews/patience along the
way.

llvm-svn: 175819

Storing the load/store instructions with the values
and inspect them using Alias Analysis to make sure
they don't alias, since the GEP pointer operand doesn't
take the offset into account.

Trying hard to not add any extra cost to loads and stores
that don't overlap on global values, AA is *only* calculated
if all of the previous attempts failed.

Using biggest vector register size as the stride for the
vectorization access, as we're being conservative and
the cost model (which calculates the real vectorization
factor) is only run after the legalization phase.

We might re-think this relationship in the future, but
for now, I'd rather be safe than sorry.

llvm-svn: 175818

(found due to incoming improvements to llvm::cast machinery that will error on
this sort of mistake)

llvm-svn: 175817

llvm-svn: 175816

llvm-svn: 175815

now.

llvm-svn: 175814

in the compilation setup. Note that this doesn't currently
work for -no-integrated-as.

llvm-svn: 175813

See r175462 for another example/more details.

llvm-svn: 175812

llvm-svn: 175811

llvm-svn: 175810

llvm-svn: 175809

functions start at the line with the "{" character, whereas clang uses the first line
with source code. As such, this test case will only work with clang.

llvm-svn: 175808

llvm-svn: 175807

<rdar://problem/13254824>

llvm-svn: 175806

Fixes infinite loop in PR15220.

Patch by Philip Craig.

llvm-svn: 175805

llvm-svn: 175804

Was used during experiments, but another if-statements a few lines
before makes it (intentionally) useless.

llvm-svn: 175803

Along the way, improve a diagnostic for "previous declaration here" for implicit parameters.

Fixes <rdar://problem/13211384>.

llvm-svn: 175802

llvm-svn: 175801

This fixes llvm.org/PR15167.

Before:
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL()
    : AAAAAAAA(10), BBBBBBBBB(10) {
}
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL() : AAAAAAAA(10) {}

After:
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL()
    : AAAAAAAA(10), BBBBBBBBB(10) {}
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL() : AAAAAAAA(10) {}

llvm-svn: 175800

be set to zero that is what it was intended. Should improve performance of 
the data structure when clear is invoked frequently (both compile time and
memory usage).

llvm-svn: 175799

llvm-svn: 175798

llvm-svn: 175797

See r175462 for another example/more details.

llvm-svn: 175796

- generate-vers.pl has to be called by cmake to generate the version number
- parallel builds not yet supported; dependency on clang must be explicitly specified

Tested on Linux.
- Building on Mac will require code-signing logic to be implemented.
- Building on Windows will require OS-detection logic and some selective directory inclusion

Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir
who ported them to Linux!

llvm-svn: 175795

of its own target.

<rdar://problem/13121412>

llvm-svn: 175794

By Adrian Pranti.

llvm-svn: 175793

llvm-svn: 175792

llvm-svn: 175791

[scan-build] Add quotes around clang executable name to handle path withs spaces.  Fixes <rdar://problem/13254727>

llvm-svn: 175790