llvm-svn: 182970

syntactic form in template instantiation. Previously, this blocked the
reversion and we ended up losing inner CXXBindTemporaryExprs (and thus
forgetting to call destructors!).

llvm-svn: 182969

llvm-svn: 182966

- should address Debian test errors due to not being able to 'ps' directly

llvm-svn: 182965

which diagnoses type mismatches of identical 
selectors declared in classes throughout.
// rdar://14007194

llvm-svn: 182964

...and make this work correctly in the current codebase.

After living on this for a while, it turns out to look very strange for
inlined functions that have only a single statement, and somewhat strange
for inlined functions in general (since they are still conceptually in the
middle of the path, and there is a function-entry path note).

It's worth noting that this only affects inlined functions; in the new
arrow generation algorithm, the top-level function still starts at the
first real statement in the function body, not the enclosing CompoundStmt.

This reverts r182078 / dbfa950abe0e55b173286a306ee620eff5f72ea.

llvm-svn: 182963

The testcase in PR16060 points out that while template arguments can
show that a type is not externally visible, the standards still says
they have external linkage.

In terms of our implementation, it means that we should merge just the
isExternallyVisible bit, not the formal linkage.

llvm-svn: 182962

Improve TestExitDuringStep to verify thread behaviour during step-over, step-in in addition to step-inst

Patch by Brian Minard!

llvm-svn: 182961

r182877 broke MCJIT tests on ARM and r182937 was working around another failure
by r182877.

This should make the ARM bots green.

llvm-svn: 182960

llvm-svn: 182959

llvm-svn: 182958

llvm-svn: 182957

llvm-svn: 182954

Upon encountering an object not of type string, LLDB will get the string representation of it (akin to calling str(X) in Python code) and use that as the summary to display

Feedback is welcome as to whether repr() should be used instead (but the argument for repr() better be highly persuasive :-)

llvm-svn: 182953

llvm-svn: 182952

Fix potential infinite loop when iterating over redeclarations of an ObjMethodDecl, resulting from invalid code.

Check for invalid decls in ObjCMethodDecl::getNextRedeclaration(); otherwise if we start from an invalid redeclaration
of an @implementation we would move to the @interface and not reach the original declaration again.

Fixes rdar://14024851

llvm-svn: 182951

llvm-svn: 182950

This removes the need for the missing SectionRef operator< workaround, and fixes
an IntervalMap assert about alignment on MSVC.

llvm-svn: 182949

It is okay to declare a block without an argument list: ^ {} or ^void {}.
In these cases, the BlockDecl's signature-as-written will just contain
the return type, rather than the entire function type. It is unclear if
this is intentional, but the analyzer shouldn't crash because of it.

<rdar://problem/14018351>

llvm-svn: 182948

Do not reuse the debug location of the return value's store if there is autorelease code to be emitted between store and return instructions. This is analoguous to what we do for lexical scope cleanups.

rdar://problem/13977888

llvm-svn: 182947

llvm-svn: 182946

Implement IEEE-754R 2008 nextUp/nextDown functions in the guise of the function APFloat::next(bool nextDown).

rdar://13852078

llvm-svn: 182945

llvm-svn: 182943

Using updated form of newFrontendActionFactory(), Transforms now automatically
measure, if requested, how long it takes to apply a MatchFinder to a source
file. Other per-transform overhead, e.g. applying replacements, is not
currently measured. This behaviour is disabled for now and soon will be
connected to a new command line arg.

llvm-svn: 182942

to detect scops in functions with no loops, use -polly-detect-scops-in-functions-without-loops

llvm-svn: 182941

llvm-svn: 182940

llvm-svn: 182939

- clarify that vectorizer.width only applies if the vectorizer decides to
  vectorize.

llvm-svn: 182938

This fixes the test on ARM. Looks like it was broken by r182877. Not
sure if this is a bug on fast isel on ARM, but this should help fix
the ARM bots.

llvm-svn: 182937

references.  What's more, they use this language extension in their
ATL header files (which come as part of MFC and the Win32 SDK).  This patch implements support for the Microsoft extension, and addresses PR13737.

llvm-svn: 182936

llvm-svn: 182935

Found by -Wdocumentation.

llvm-svn: 182934

The pattern the test originally checked for doesn't occur on other -mcpu
settings. On atom it's still there though slightly differently scheduled.

llvm-svn: 182933

This fixes:
/*
*
* something long going over the column limit.
*/

llvm-svn: 182932

on the LLDB 3.3 release.

Reviewed by: Greg Clayton and Bill Wendling

llvm-svn: 182931

llvm-svn: 182930

This test was failing on some hosts when an unexpected register was used for a
variable. This just extends the regexp to allow the new x86-64 registers.

llvm-svn: 182929

Instead of having a bunch of separate MOV8r0, MOV16r0, ... pseudo-instructions,
it's better to use a single MOV32r0 (which will expand to "xorl %reg, %reg")
and obtain other sizes with EXTRACT_SUBREG and SUBREG_TO_REG. The encoding is
smaller and partial register updates can sometimes be avoided.

Until recently, this sequence was a barrier to rematerialization though. That
should now be fixed so it's an appropriate time to make the change.

llvm-svn: 182928

llvm-svn: 182927

llvm-svn: 182926