[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/1523

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

Buildslave for this Build: macpro1

Build Reason: scheduler
Build Source Stamp: 212077
Blamelist: ghoflehner,zturner

BUILD FAILED: failed

sincerely,
 -The Buildbot


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

CHANGES:
Files:
 include/lldb/Host/msvc/Config.h
 source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
On: http://10.1.1.2/svn/llvm-project
For: lldb
At: Mon 30 Jun 2014 17:30:37
Changed By: zturner
Comments: Fix Windows build after llgs upstream.

With _HAS_EXCEPTIONS=0, Windows' version of <thread> will fail to
compile because it calls __uncaught_exception(), which is compiled
out due to _HAS_EXCEPTIONS=0.  This just creates a stub version
of __uncaught_exception() which always fails.Properties: 




Files:
 lib/Analysis/IPA/InlineCost.cpp
 test/Transforms/Inline/blockaddress.ll
On: http://10.1.1.2/svn/llvm-project
For: llvm
At: Mon 30 Jun 2014 17:30:37
Changed By: ghoflehner
Comments: Suppress inlining when the block address is taken

Inlining functions with block addresses can cause many problem and requires a
rich infrastructure to support including escape analysis.  At this point the
safest approach to address these problems is by blocking inlining from
happening.

Background:
There have been reports on Ruby segmentation faults triggered by inlining
functions with block addresses like

//Ruby code snippet
vm_exec_core() {
    finish_insn_seq_0 = &&INSN_LABEL_finish;
    INSN_LABEL_finish:
      ;
}

This kind of scenario can also happen when LLVM picks a subset of blocks for
inlining, which is the case with the actual code in the Ruby environment.

LLVM suppresses inlining for such functions when there is an indirect branch.
The attached patch does so even when there is no indirect branch.  Note that
user code like above would not make much sense: using the global for jumping
across function boundaries would be illegal.

Why was there a segfault:

In the snipped above the block with the label is recognized as dead So it is
eliminated. Instead of a block address the cloner stores a constant (sic!) into
the global resulting in the segfault (when the global is used in a goto).

Why had it worked in the past then:

By luck. In older versions vm_exec_core was also inlined but the label address
used was the block label address in vm_exec_core.  So the global jump ended up
in the original function rather than in the caller which accidentally happened
to work.

Test case ./tools/clang/test/CodeGen/indirect-goto.c will fail as a result
of this commit.

rdar://17245966

Properties: 




LOGS: