llvm-svn: 162982

llvm-svn: 162981

llvm-svn: 162980

llvm-svn: 162979

AnalysisManager, allowing the StringMap of configuration values to
be propagated.

llvm-svn: 162978

llvm-svn: 162977

function from Tooling.

llvm-svn: 162976

llvm-svn: 162975

explicitly visible in test cases which language variant is used.

llvm-svn: 162974

llvm-svn: 162973

Added command lists that can be executed on launch, stop, crash and exit. Added code to auto import the lldb module that we can use on many stand alone modules.

llvm-svn: 162972

llvm-svn: 162971

llvm-svn: 162970

TableGen-generated string matcher.

llvm-svn: 162969

Thumb2 instructions are mostly constrained to rGPR, not tGPR which is
for Thumb1.

rdar://problem/12203728

llvm-svn: 162968

llvm-svn: 162967

This reverts commit befc0f648c83f65e1f3567f2058c7c18b4bc3ad8 now that
plist-html diagnostics are working again.

llvm-svn: 162966

PathDiagnostics are actually profiled and uniqued independently of the
path on which the bug occurred. This is used to merge diagnostics that
refer to the same issue along different paths, as well as by the plist
diagnostics to reference files created by the HTML diagnostics.

However, there are two problems with the current implementation:

1) The bug description is included in the profile, but some
   PathDiagnosticConsumers prefer abbreviated descriptions and some
   prefer verbose descriptions. Fixed by including both descriptions in
   the PathDiagnostic objects and always using the verbose one in the profile.

2) The "minimal" path generation scheme provides extra information about
   which events came from macros that the "extensive" scheme does not.
   This resulted not only in different locations for the plist and HTML
   diagnostics, but also in diagnostics being uniqued in the plist output
   but not in the HTML output. Fixed by storing the "end path" location
   explicitly in the PathDiagnostic object, rather than trying to find the
   last piece of the path when the diagnostic is requested.

This should hopefully finish unsticking our internal buildbot.

llvm-svn: 162965

Basically, do the correct thing to fix the XML generation error, rather
than making it even worse by unilaterally dereferencing a null pointer.

llvm-svn: 162964

The assembly string for the VMOVPQIto64rr instruction incorrectly lacked the 'v'
prefix, resulting in mis-assembly of the vanilla movd instruction.

llvm-svn: 162963

(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call.  Fixes PR13195.

llvm-svn: 162962

the ConvertToMCInst() return void, rather then a bool.  Update all the cvt
functions as well.

llvm-svn: 162961

Take account of boolean vector contents when promoting a build vector from i1 to some other type.  rdar://problem/12210060

llvm-svn: 162960

method parameter types which are reference to an objective-C
pointer to object with no explicit ownership. // rdar://10907090

llvm-svn: 162959

llvm-svn: 162958

reanalyzed.

The policy on what to reanalyze should be in AnalysisConsumer with the
rest of visitation order logic.

There is no reason why ExprEngine needs to pass the Visited set to
CoreEngine, it can populate it itself.

llvm-svn: 162957

Teach the DAG combiner to turn chains of FADDs (x+x+x+x+...) into FMULs by constants.  This is only enabled in unsafe FP math mode, since it does not preserve rounding effects for all such constants.

llvm-svn: 162956

llvm-svn: 162955

llvm-svn: 162954

llvm-svn: 162953

llvm-svn: 162952

llvm-svn: 162951

There are two tests regressions that come from the fact that the Retain
Count checker does not cancel out inlining of ObjC methods.

llvm-svn: 162950

Thanks for catching this!

llvm-svn: 162949

llvm-svn: 162948

constructor not user provided (and, therefore, non-trivial). Fixes
<rdar://problem/11736429>.

llvm-svn: 162947

llvm-svn: 162946

llvm-svn: 162945

an 80-column violation in the generated code.  No functional change intended.

llvm-svn: 162944

./verify_api.py --library ./LLDB.framework/LLDB --api-regex lldb --arch x86_64 /Applications/Xcode.app/Contents/PlugIns/DebuggerLLDB.ideplugin/Contents/MacOS/DebuggerLLDB

So you specify a library with the "--library" option, then you specify an API regular expression that you want to match the executables against with "--api-regex <regex>", here we specify "lldb" to catch all undefined external API functions from the binary we want to test, then we specify the architectures to check with "--arch <arch>" (this can be specified more than once), and you give one or more executables.

llvm-svn: 162941