[llvm-testresults] buildbot failure in lab.llvm.org on phase3 - tree health

Sat Jan 4 07:02:04 PST 2014

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

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

Buildslave for this Build: macpro1

Build Reason: scheduler
Build Source Stamp: 198478
Blamelist: adrian,akirtzidis,atrick,ctopper,jacksprat,jmolenda,kremenek,nico,rnk,rtrieu

BUILD FAILED: failed

sincerely,
 -The Buildbot

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

CHANGES:
File: utils/FileCheck/FileCheck.cpp
On: smooshlab-project
At: Fri 03 Jan 2014 13:56:47
Changed By: adrian
Comments: FileCheck: Print a nice error message for missing closing ']' in regex vars.Properties: 
  phase_id: r198450-t20140103_145703-b15275

Files:
 source/Plugins/Process/Utility/RegisterContextLLDB.cpp
 source/Plugins/Process/Utility/RegisterContextLLDB.h
 source/Plugins/Process/Utility/UnwindLLDB.cpp
On: smooshlab-project
At: Fri 03 Jan 2014 14:16:47
Changed By: jmolenda
Comments: Don't enforce ABI stack alignment rules on the sigtramp frame --
its stack frame is a constructed, fake thing that may not conform
correctly to these rules.  This fixes a problem where lldb couldn't
backtrace past an asynchronous signal handler (_sigtramp) frame on
a stack on Mac OS X.
<rdar://problem/15035673> 
Properties: 
  phase_id: r198450-t20140103_145703-b15275

File: Makefile.rules
On: smooshlab-project
At: Fri 03 Jan 2014 14:26:47
Changed By: jacksprat
Comments: [Mips]Work around MIPS linker issues exposed by commit r198087 until bug 18360 is resolvedProperties: 
  phase_id: r198450-t20140103_145703-b15275

Files:
 include/llvm/Support/Compiler.h
 lib/CodeGen/MachineBlockPlacement.cpp
 lib/Transforms/Scalar/SROA.cpp
On: smooshlab-project
At: Fri 03 Jan 2014 15:00:47
Changed By: nico
Comments: Add a LLVM_DUMP_METHOD macro.

The motivation is to mark dump methods as used in debug builds so that they can
be called from lldb, but to not do so in release builds so that they can be
dead-stripped.

There's lots of potential follow-up work suggested in the thread
"Should dump methods be LLVM_ATTRIBUTE_USED only in debug builds?" on cfe-dev,
but everyone seems to agreen on this subset.

Macro name chosen by fair coin toss.

Properties: 
  phase_id: r198465-t20140103_160247-b15279

Files:
 lib/CodeGen/CGDebugInfo.cpp
 lib/CodeGen/CGDebugInfo.h
 lib/CodeGen/CGStmt.cpp
 lib/CodeGen/CodeGenFunction.cpp
 lib/CodeGen/CodeGenFunction.h
 test/CodeGenCXX/linetable-cleanup.cpp
 test/CodeGenObjC/arc-linetable.m
On: smooshlab-project
At: Fri 03 Jan 2014 15:40:47
Changed By: adrian
Comments: Debug info: Ensure that the last stop point in a function is still within
the lexical block formed by the compound statement that is the function
body.

rdar://problem/15010825Properties: 
  phase_id: r198465-t20140103_160247-b15279

Files:
 include/clang/AST/VTableBuilder.h
 lib/AST/VTableBuilder.cpp
 lib/CodeGen/MicrosoftCXXABI.cpp
 test/CodeGenCXX/microsoft-abi-vbtables.cpp
On: smooshlab-project
At: Fri 03 Jan 2014 15:50:47
Changed By: rnk
Comments: [ms-cxxabi] Improve vbtable name mangling accuracy

Summary:
This makes us more compatible with MSVC 2012+ and fixes PR17748 where we
would give two tables the same name.

Rather than doing a fresh depth-first traversal of the inheritance graph
for every record's vbtables, now we memoize vbtable paths for each
record.  By doing memoization, we end up considering virtual bases of
subobjects that come later in the depth-first traversal.  Where
previously we would have ignored a virtual base that we'd already seen,
we now consider it for name mangling purposes without emitting a
duplicate vbtable for it.

Reviewers: majnemer

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2509Properties: 
  phase_id: r198465-t20140103_160247-b15279

File: include/llvm/IR/DataLayout.h
On: smooshlab-project
At: Fri 03 Jan 2014 16:00:47
Changed By: rnk
Comments: Fix MSVC warning about missing return in DataLayoutProperties: 
  phase_id: r198465-t20140103_160247-b15279

File: source/Plugins/Process/Utility/RegisterContextLLDB.cpp
On: smooshlab-project
At: Fri 03 Jan 2014 17:46:47
Changed By: jmolenda
Comments: Use Address::SetLoadAddress() instead of SectionLoadList::ResolveLoadAddress().
The former will set the Address object's offset to the load address value if
it is not present in any section; the latter will only set the Address object
if the load addr is contained in one of its sections.
<rdar://problem/15135987> 
Properties: 
  phase_id: r198469-t20140103_174847-b15280

Files:
 lib/Sema/AnalysisBasedWarnings.cpp
 test/SemaCXX/warn-infinite-recursion.cpp
On: smooshlab-project
At: Fri 03 Jan 2014 18:06:47
Changed By: rtrieu
Comments: Ignore qualified templated functions for -Winfinite-recursion.  This treats
functions like Foo<5>::run() the same way as run<5>() for this warning.
Properties: 
  phase_id: r198470-t20140103_180850-b15281

Files:
 lib/Sema/SemaExpr.cpp
 test/Sema/ext_vector_casts.c
On: smooshlab-project
At: Fri 03 Jan 2014 19:40:47
Changed By: akirtzidis
Comments: [Sema] When checking if a bitcast is appropriate between vector types, take into
consideration the num-of-elements*width-of-element width.

Disallow casts when such width is not equal between the vector types otherwise
we may end up with an invalid LLVM bitcast.

rdar://15722308.Properties: 
  phase_id: r198474-t20140103_194247-b15282

Files:
 lib/Target/X86/X86InstrControl.td
 utils/TableGen/X86RecognizableInstr.cpp
On: smooshlab-project
At: Fri 03 Jan 2014 21:16:47
Changed By: ctopper
Comments: Remove JMP64pcrel32 (jmpq ). There are no tests for it. I'm pretty sure it won't be emitted correctly since it was set to NoImm. And I can't prove that gas accepts 'jmpq' with an immediate either. Remove the special case for it from the disassembler table generator.Properties: 
  phase_id: r198475-t20140103_211847-b15283

Files:
 lib/StaticAnalyzer/Checkers/CMakeLists.txt
 lib/StaticAnalyzer/Checkers/Checkers.td
 lib/StaticAnalyzer/Checkers/IdempotentOperationChecker.cpp
 test/Analysis/dead-stores.c
 test/Analysis/idempotent-operations-limited-loops.c
 test/Analysis/idempotent-operations.c
 test/Analysis/idempotent-operations.cpp
 test/Analysis/idempotent-operations.m
 test/Analysis/misc-ps-region-store.m
 test/Analysis/misc-ps.m
 test/Analysis/null-deref-ps.c
 test/Analysis/uninit-vals-ps-region.m
On: smooshlab-project
At: Fri 03 Jan 2014 22:00:47
Changed By: kremenek
Comments: [analyzer] Remove IdempotentOperations checker.

This checker has not been updated to work with interprocedural analysis,
and actually contains both logical correctness issues but also
memory bugs.  We can resuscitate it from version control once there
is focused interest in making it a real viable checker again.Properties: 
  phase_id: r198478-t20140103_220247-b15284

File: include/llvm/Analysis/ScalarEvolution.h
On: smooshlab-project
At: Fri 03 Jan 2014 22:00:47
Changed By: atrick
Comments: whitespaceProperties: 
  phase_id: r198478-t20140103_220247-b15284

Files:
 include/llvm/Analysis/ScalarEvolution.h
 lib/Transforms/Utils/LoopSimplify.cpp
 test/Transforms/LoopSimplify/ashr-crash.ll
On: smooshlab-project
At: Fri 03 Jan 2014 22:00:47
Changed By: atrick
Comments: Fix PR18361: Invalidate LoopDispositions after LoopSimplify hoists things.

getSCEV for an ashr instruction creates an intermediate zext
expression when it truncates its operand.

The operand is initially inside the loop, so the narrow zext
expression has a non-loop-invariant loop disposition.

LoopSimplify then runs on an outer loop, hoists the ashr operand, and
properly invalidate the SCEVs that are mapped to value.

The SCEV expression for the ashr is now an AddRec with the hoisted
value as the now loop-invariant start value.

The LoopDisposition of this wide value was properly invalidated during
LoopSimplify.

However, if we later get the ashr SCEV again, we again try to create
the intermediate zext expression. We get the same SCEV that we did
earlier, and it is still cached because it was never mapped to a
Value. When we try to create a new AddRec we abort because we're using
the old non-loop-invariant LoopDisposition.

I don't have a solution for this other than to clear LoopDisposition
when LoopSimplify hoists things.

I think the long-term strategy should be to perform LoopSimplify on
all loops before computing SCEV and before running any loop opts on
individual loops. It's possible we may want to rerun LoopSimplify on
individual loops, but it should rarely do anything, so rarely require
invalidating SCEV.Properties: 
  phase_id: r198478-t20140103_220247-b15284

LOGS: