[llvm-testresults] buildbot failure in smooshlab on clang-i386-darwin9
Chris Lattner
clattner at apple.com
Fri Apr 30 18:45:21 PDT 2010
It. Fixed in r102825 by fixing the two clang tests.
On Apr 30, 2010, at 6:37 PM, daniel_dunbar at apple.com wrote:
> The Buildbot has detected a new failure of clang-i386-darwin9 on smooshlab.
> Full details are available at:
> http://smooshlab.apple.com:8010/builders/clang-i386-darwin9/builds/8239
>
> Buildbot URL: http://smooshlab.apple.com:8010/
>
> Buildslave for this Build: smoosh-15.apple.com
>
> Build Reason:
> Build Source Stamp: 102823
> Blamelist: lattner
>
> BUILD FAILED: failed test-clang
>
> sincerely,
> -The Buildbot
>
>
> ================================================================================
>
> CHANGES:
> Files:
> lib/Analysis/IPA/CallGraphSCCPass.cpp
> lib/Transforms/Utils/InlineFunction.cpp
> test/Transforms/Inline/devirtualize.ll
> At: Fri 30 Apr 2010 18:20:46
> Changed By: lattner
> Comments: Implement rdar://6295824 and PR6724 with two tiny changes
> that can have a big effect :). The first is to enable the
> iterative SCC passmanager juice that kicks in when the
> scc passmgr detects that a function pass has devirtualized
> a call. In this case, it will rerun all the passes it
> manages on the SCC, up to the iteration count limit (4). This
> is useful because a function pass may devirualize a call, and
> we want the inliner to inline it, or pruneeh to infer stuff
> about it, etc.
>
> The second patch is to add *all* call sites to the
> DevirtualizedCalls list the inliner uses. This list is
> about to get renamed, but the jist of this is that the
> inliner now reconsiders *all* inlined call sites as candidates
> for further inlining. The intuition is this that in cases
> like this:
>
> f() { g(1); } g(int x) { h(x); }
>
> We analyze this bottom up, and may decide that it isn't
> profitable to inline H into G. Next step, we decide that it is
> profitable to inline G into F, and do so, which means that F
> now calls H. Even though the call from G -> H may not have been
> profitable to inline, the call from F -> H may be (in this case
> because a constant allows folding etc).
>
> In my spot checks, this doesn't have a big impact on code. For
> example, the LLC output for 252.eon grew from 0.02% (from
> 317252 to 317308) and 176.gcc actually shrunk by .3% (from 1525612
> to 1520964 bytes). 252.eon never iterated in the SCC Passmgr,
> 176.gcc iterated at most 1 time.
>
> Properties:
>
>
>
>
> LOGS:
> Last 10 lines of 'stdio':
> ********************
> Failing Tests (2):
> Clang :: CodeGenCXX/member-function-pointer-calls.cpp
> Clang :: CodeGenCXX/member-initializers.cpp
>
> Expected Passes : 2201
> Expected Failures : 21
> Unexpected Failures: 2
> make[1]: *** [all] Error 1
> make: *** [test] Error 2
>
> Last 10 lines of 'fail':
> Clang :: CodeGenCXX/member-function-pointer-calls.cpp
> Clang :: CodeGenCXX/member-initializers.cpp
>
> Last 10 lines of 'xfail':
> Clang :: CodeGenCXX/conversion-function.cpp
> Clang :: FixIt/fixit-errors.c
> Clang :: FixIt/fixit-pmem.cpp
> Clang :: FixIt/typo.m
> Clang :: PCH/changed-files.c
> Clang :: PCH/pr4489.c
> Clang :: PCH/source-manager-stack.c
> Clang :: SemaCXX/rval-references-xfail.cpp
> Clang :: SemaObjCXX/overload.mm
> Clang :: SemaTemplate/instantiate-function-1.mm
>
> Last 10 lines of 'member-function-pointer-calls.cpp':
> <stdin>:47:22: note: scanning from here
> define i32 @_Z2g1v() nounwind readnone {
> ^
> <stdin>:57:16: note: possible intended match here
> define linkonce_odr i32 @_ZN1A3vf1Ev(%struct.A* nocapture %this) nounwind readnone align 2 {
> ^
> --
>
> ********************
>
>
> Last 10 lines of 'member-initializers.cpp':
> <stdin>:19:30: note: scanning from here
> define i32 @_Z1fv() nounwind readnone {
> ^
> <stdin>:29:16: note: possible intended match here
> define linkonce_odr i32 @_ZN1B1fEv(%struct.B* nocapture %this) nounwind readnone align 2 {
> ^
> --
>
> ********************
>
>
More information about the llvm-testresults
mailing list