[llvm-testresults] buildbot failure in lab.llvm.org on phase2 - living

Tue Jun 17 23:02:23 PDT 2014

The Buildbot has detected a new failure on builder phase2 - living while building lab.llvm.org.
Full details are available at:
 http://lab.llvm.org:8013/builders/phase2%20-%20living/builds/218

Buildbot URL: http://lab.llvm.org:8013/

Buildslave for this Build: macpro1

Build Reason: scheduler
Build Source Stamp: 211137
Blamelist: benlangmuir,echristo,fjahanian,ghoflehner,hans,jingham,louis,rikka,tnowicki

BUILD FAILED: failed

sincerely,
 -The Buildbot

================================================================================

CHANGES:
File: External/SPEC/CINT2006/403.gcc/Makefile
On: smooshlab-project
At: Tue 17 Jun 2014 15:26:37
Changed By: ghoflehner
Comments: Added LDFLAGS in Makefile for 403.gcc. rdar://17277963Properties: 
  phase_id: r211128-t20140617_153110-b987

File: lib/Frontend/CompilerInstance.cpp
On: smooshlab-project
At: Tue 17 Jun 2014 15:46:37
Changed By: benlangmuir
Comments: Retry building modules that were compiled by other instances and are out-of-date

When another clang instance builds a module, it may still be considered
"out of date" for the current instance in a couple of cases*.  This
patch prevents us from giving spurious errors when compilers race to
build a module by allowing the module load to fail when the pcm was
built by a different compiler instance.

* Cases where a module can be out of date despite just having been
built:

1) There are different -I paths between invocations that result in
finding a different module map file for some dependent module. This is
not an error, and should never be diagnosed.

<rdar://problem/16843887>

2) There are file system races where the headers making up a module are
touched or moved. Although this can sometimes mean trouble, diagnosing
it only during a build-race is worse than useless and we cannot detect
this in general.  It is more robust to just rebuild.  This was causing
spurious issues in some setups where only the modtime of headers was
bumped during a build.

<rdar://problem/16157638>Properties: 
  phase_id: r211129-t20140617_154837-b988

Files:
 lib/Target/X86/X86FastISel.cpp
 test/CodeGen/X86/x86-64-static-relo-movl.ll
 test/DebugInfo/X86/debug-loc-asan.ll
On: smooshlab-project
At: Tue 17 Jun 2014 16:36:37
Changed By: louis
Comments: Allow X86FastIsel to cope with 64 bit absolute relocations

This patch is a follow up to r211040 & r211052. Rather than bailing out of fast
isel this patch will generate an alternate instruction (movabsq) instead of the
leaq. While this will always have enough room to handle the 64 bit displacment
it is generally over kill for internal symbols (most displacements will be
within 32 bits) but since we have no way of communicating the code model to the
the assmebler in order to avoid flagging an absolute leal/leaq as illegal when
using a symbolic displacement.Properties: 
  phase_id: r211130-t20140617_163837-b989

File: Makefile.rules
On: smooshlab-project
At: Tue 17 Jun 2014 16:40:37
Changed By: echristo
Comments: Add the coverage cflags to the link step as well to make sure
that we link in the support libraries.Properties: 
  phase_id: r211131-t20140617_164850-b990

Files:
 lib/Sema/ScopeInfo.cpp
 lib/Sema/SemaExprObjC.cpp
 lib/Sema/SemaPseudoObject.cpp
 test/SemaObjC/iboutlet.m
On: smooshlab-project
At: Tue 17 Jun 2014 16:46:37
Changed By: fjahanian
Comments: Objective-C ARC. Do not warn about properties with both
IBOutlet and weak attributes when accessed being
unpredictably set to nil because usage of such properties
are always single threaded and its ivar cannot be set
to nil asynchronously. // rdar://15885642 
Properties: 
  phase_id: r211133-t20140617_165940-b991

File: lib/Sema/SemaLookup.cpp
On: smooshlab-project
At: Tue 17 Jun 2014 16:50:37
Changed By: rikka
Comments: Remove an unused argument from checkCorrectionVisibility.Properties: 
  phase_id: r211133-t20140617_165940-b991

File: lib/Sema/SemaLookup.cpp
On: smooshlab-project
At: Tue 17 Jun 2014 17:00:37
Changed By: rikka
Comments: Fix the caller of checkCorrectionVisibility too.

That's what I get for hurredly splitting the small change out of a much
bigger change that had moved where checkCorrectionVisibility was being
called.Properties: 
  phase_id: r211134-t20140617_170237-b992

Files:
 docs/LanguageExtensions.rst
 docs/ReleaseNotes.rst
 include/clang/Basic/Attr.td
 include/clang/Basic/AttrDocs.td
On: smooshlab-project
At: Tue 17 Jun 2014 18:00:37
Changed By: tnowicki
Comments: Documentation for #pragma clang loop directive and options vectorize and interleave.

Reviewed by: Aaron Ballman and Dmitri Gribenko
Properties: 
  phase_id: r211135-t20140617_180237-b993

Files:
 include/lldb/Breakpoint/BreakpointSite.h
 source/Breakpoint/BreakpointSite.cpp
On: smooshlab-project
At: Tue 17 Jun 2014 18:16:37
Changed By: jingham
Comments: Add locking around the m_owners collection in the breakpoint site.  If we are in the middle of "BreakpointLocation::ShouldStop" we don't
want other commands (like "break disable") to mutate the owners of this breakpoint out from under us.

<rdar://problem/17255589>
Properties: 
  phase_id: r211136-t20140617_181837-b994

Files:
 lib/Sema/SemaTemplateInstantiateDecl.cpp
 test/CodeGenCXX/microsoft-abi-static-initializers.cpp
On: smooshlab-project
At: Tue 17 Jun 2014 18:30:37
Changed By: hans
Comments: Fix bug in code for avoiding dynamic initialization of dllimport globals

When instantiating dllimport variables with dynamic initializers, don't
bail out of Sema::InstantiateVariableInitializer without calling
PopExpressionEvaluationContext().

This was causing a stale object to stay on the ExprEvalContexts stack,
causing subsequent calls to getCurrentMangleNumberContext() to fail,
resulting in incorrect numbering of static locals (and probably other
broken things).Properties: 
  phase_id: r211137-t20140617_183238-b995

LOGS: