[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