[llvm-testresults] buildbot failure in lab.llvm.org on phase1 - sanity

[llvmlab-buildmaster at lab.llvm.org]

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

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

Buildslave for this Build: macpro1

Build Reason: scheduler
Build Source Stamp: 188165
Blamelist: chandlerc,rsandifo

BUILD FAILED: failed

sincerely,
 -The Buildbot


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

CHANGES:
File: utils/TableGen/AsmMatcherEmitter.cpp
On: http://10.1.1.2/svn/llvm-project
For: llvm
At: Mon 12 Aug 2013 03:46:33
Changed By: rsandifo
Comments: Stablize MCK_Reg ordering in AsmMatcherEmitter

clang bootstraps intermittently failed for me due a difference in
the MCK_Reg ordering in ARMGenAsmMatcher.inc.  E.g. in my latest
run the stage 1 and stage 3 versions were the same but the stage 2
one was different (though still functionally correct).  This meant
that the .o comparison failed.

MCK_Regs were assigned by iterating over a std::set< std::set<Record*> >,
and since std::set is sorted lexicographically, the order depended on the
order of the pointer values.  This patch replaces the pointer ordering
with LessRecordByID.
Properties: 




Files:
 autoconf/configure.ac
 cmake/config-ix.cmake
 configure
 include/llvm/Config/config.h.cmake
 include/llvm/Config/config.h.in
 lib/Support/Unix/Process.inc
On: http://10.1.1.2/svn/llvm-project
For: llvm
At: Mon 12 Aug 2013 03:46:33
Changed By: chandlerc
Comments: Remove all checking for the various terminfo headers (term.h and
curses.h). Finding these headers is next to impossible. For example, on
Debian systems libtinfo-dev provides the terminfo reading library we
want, but *not* term.h. For the header, you have to use libncurses-dev.
And libncursesw-dev provides a *different* term.h in a different
location!

These headers aren't worth it. We want two functions the signatures of
which are clearly spec'ed in sys-v and other documentation. Just declare
them ourselves and call them. This should fix some debian builders and
provide better support for "minimal" debian systems that do want color
autodetection.Properties: 




LOGS: