llvm-svn: 169046

llvm-svn: 169045

The original patch removed a bunch of code that the SjLjEHPrepare pass placed
into the entry block if all of the landing pads were removed during the
CodeGenPrepare class. The more natural way of doing things is to run the CGP
*before* we run the SjLjEHPrepare pass.

Make it so!

llvm-svn: 169044

llvm-svn: 169043

module, provide a module import stack similar to what we would get for
an include stack, e.g.,

In module 'DependsOnModule' imported from build-fail-notes.m:4:
In module 'Module' imported from DependsOnModule.framework/Headers/DependsOnModule.h:1:
Inputs/Module.framework/Headers/Module.h:15:12: note: previous definition is here
@interface Module

<rdar://problem/12696425>

llvm-svn: 169042

llvm-svn: 169041

This causes llc to repeat the module compilation N times, making it
possible to get more accurate information from -time-passes when
compiling small modules.

llvm-svn: 169040

This avoids unidentified duplicates in the pass execution time report
when a pass runs more than once in the pass manager pipeline.

llvm-svn: 169039

llvm-svn: 169038

llvm-svn: 169037

llvm-svn: 169036

Readline & gdb have a bunch of code to handle older UNIX'es with other job control mechanisms.
I didn't try to replicate that.

llvm-svn: 169032

<rdar://problem/12676084> Dump the traceback when a Python error occurs in "command script import" and the exception is not an ImportError

llvm-svn: 169031

llvm-svn: 169030

llvm-svn: 169029

llvm-svn: 169028

files are loaded.

llvm-svn: 169027

llvm-svn: 169026

reviewed by Michael Ilseman <milseman@apple.com>

llvm-svn: 169025

Codegen was failing with an assertion because of unexpected vector
operands when legalizing the selection DAG for a MUL instruction.

The asserting code was legalizing multiplies for vectors of size 128
bits. It uses a custom lowering to try and detect cases where it can
use a VMULL instruction instead of a VMOVL + VMUL.  The code was
looking for input operands to the MUL that had been sign or zero
extended. If it found the extended operands it would drop the
sign/zero extension and use the original vector size as input to a
VMULL instruction.

The code assumed that the original input vector was 64 bits so that
after dropping the extension it would fit directly into a D register
and could be used as an operand of a VMULL instruction. The input
code that trigger the failure used a vector of <4 x i8> that was
sign extended to <4 x i32>. It was not safe to drop the sign
extension in this case because the original vector is only 32 bits
wide. The fix is to insert a sign extension for the vector to reach
the required 64 bit size. In this particular example, the vector would
need to be sign extented to a <4 x i16>.

llvm-svn: 169024

For "target create" you can now specify "--no-dependents" to not track down and add all dependent shared libraries. This can be handy when doing manual symbolication. Also added the "--symfile" or "-s" for short so you can specify a module and a stand alone debug info file:

(lldb) target create --symfile /tmp/a.dSYM /usr/bin/a

Added the "--symfile" option to the "target modules add" for the same reason. These all help with manualy symbolication and expose functionality that was previously only available through the public API layer.

llvm-svn: 169023

__list::ends_with_template was giving the wrong answer for empty lists.  And __parse_unnamed_type_name wasn't properly handling the list of paramters and was not safe against incorrectly mangled lambdas (running past last).

llvm-svn: 169022

building module 'Foo' imported from..." notes (the same we we provide
"In file included from..." notes) in the diagnostic, so that we know
how this module got included in the first place. This is part of
<rdar://problem/12696425>.

llvm-svn: 169021

llvm-svn: 169020

llvm-svn: 169019

llvm-svn: 169018

tsan: add __libc_memalign interceptor (used by dynamic loader to allocate tls for dlopen'ed modules)

llvm-svn: 169017

Remove the use of LPPassManager. We can remove LPM because we dont need to run any additional loop passes on the new vector loop.

llvm-svn: 169016

llvm-svn: 169015

llvm-svn: 169002

instead of 1 or true (?!)

llvm-svn: 169001

Patch by Edwin Vane.

llvm-svn: 169000

FIXME: Please add another RUN line if you would like to check also on ppc64.
llvm-svn: 168999

instruction (vmaddfp) to conform with IEEE to ensure the sign of a zero
result when resulting product is -0.0.

The -0.0 vector addend to vmaddfp is generated by a creating a vector
with full bits sets and then shifting each elements by 31-bits to the
left, resulting in a vector of 0x80000000 (or -0.0 as float).

The 'buildvec_canonicalize.ll' was adjusted to reflect this change and
the 'vec_mul.ll' was complemented with the float vector multiplication
test.

llvm-svn: 168998

llvm-svn: 168997

Rationale:
1) This was the name in the comment block. ;]
2) It matches Clang's __has_feature naming convention.
3) It matches other compiler-feature-test conventions.

Sorry for the noise. =]

I've also switch the comment block to use a \brief tag and not duplicate
the name.

llvm-svn: 168996

llvm-svn: 168995

llvm-svn: 168994

references from whether it supports an R-value reference *this. No
version of GCC today supports the latter, which breaks GCC C++11
compiles of LLVM and Clang now.

Also add doxygen comments clarifying what's going on here, and update
the usage in Optional. I'll update the usages in Clang next.

llvm-svn: 168993

llvm-svn: 168992