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

[llvmlab-buildmaster at lab.llvm.org]

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/53

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

Buildslave for this Build: macpro1

Build Reason: scheduler
Build Source Stamp: 209986
Blamelist: alp,compnerd,dblaikie

BUILD FAILED: failed

sincerely,
 -The Buildbot


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

CHANGES:
File: test/CMakeLists.txt
On: smooshlab-project
At: Sat 31 May 2014 19:10:37
Changed By: alp
Comments: Don't add examples to the check-clang dependencies unless requested

The tests were correctly getting skipped but the targets still mistakenly got
built.Properties: 
  phase_id: r209983-t20140531_191237-b303



Files:
 lib/CodeGen/AsmPrinter/DwarfDebug.cpp
 lib/CodeGen/AsmPrinter/DwarfUnit.cpp
 test/DebugInfo/incorrect-variable-debugloc.ll
On: smooshlab-project
At: Sat 31 May 2014 20:50:37
Changed By: dblaikie
Comments: DebugInfo: Assert that DbgVariables have associated DIEs

This was previously committed in r209680 and reverted in r209683 after
it caused sanitizer builds to crash.

The issue seems to be that the DebugLoc associated with dbg.value IR
intrinsics isn't necessarily accurate. Instead, we duplicate the
DIVariables and add an InlinedAt field to them to record their
location.

We were using this InlinedAt field to compute the LexicalScope for the
variable, but not using it in the abstract DbgVariable construction and
mapping. This resulted in a formal parameter to the current concrete
function, correctly having no InlinedAt information, but incorrectly
having a DebugLoc that described an inlined location within the
function... thus an abstract DbgVariable was created for the variable,
but its DIE was never constructed (since the LexicalScope had no such
variable). This DbgVariable was silently ignored (by testing for a
non-null DIE on the abstract DbgVariable).

So, fix this by using the right scoping information when constructing
abstract DbgVariables.

In the long run, I suspect we want to undo the work that added this
second kind of location tracking and fix the places where the DebugLoc
propagation on the dbg.value intrinsic fails. This will shrink debug
info (by not duplicating DIVariables), make it more efficient (by not
having to construct new DIVariable metadata nodes to try to map back to
a single variable), and benefit all instructions.

But perhaps there are insurmountable issues with DebugLoc quality that
I'm unaware of... I just don't know how we can't /just keep the DebugLoc
from the dbg.declare to the dbg.values and never get this wrong/.

Some history context:

http://llvm.org/viewvc/llvm-project?view=revision&revision=135629
http://llvm.org/viewvc/llvm-project?view=revision&revision=137253Properties: 
  phase_id: r209984-t20140531_205237-b304



Files:
 lib/builtins/arm/bswapdi2.S
 lib/builtins/arm/bswapsi2.S
 lib/builtins/arm/clzdi2.S
 lib/builtins/arm/clzsi2.S
 lib/builtins/arm/divmodsi4.S
 lib/builtins/arm/divsi3.S
 lib/builtins/arm/modsi3.S
 lib/builtins/arm/udivmodsi4.S
 lib/builtins/arm/udivsi3.S
 lib/builtins/arm/umodsi3.S
 lib/builtins/x86_64/floatundidf.S
 lib/builtins/x86_64/floatundisf.S
 lib/builtins/x86_64/floatundixf.S
On: smooshlab-project
At: Sat 31 May 2014 21:16:37
Changed By: compnerd
Comments: compiler-rt: whitespace and uniformity for arm

Make the whitespace a bit more uniform in the various assembly routines.  This
also makes the assembly files a bit more uniform on the ARM side by explicitly
stating that it is using the unified syntax and that the contents of the code is
in the text section (or segment).  No functional change.Properties: 
  phase_id: r209986-t20140531_211837-b305



Files:
 lib/builtins/x86_64/floatundidf.S
 lib/builtins/x86_64/floatundisf.S
 lib/builtins/x86_64/floatundixf.S
On: smooshlab-project
At: Sat 31 May 2014 21:16:37
Changed By: compnerd
Comments: compiler-rt: prefer .rodata for non MachO targets

Place constants into .rdata if targeting ELF or COFF/PE.  This should be
functionally identical, however, the data would be placed into a different
section.  This is purely a cleanup change.Properties: 
  phase_id: r209986-t20140531_211837-b305



LOGS: