Richard Guenther wrote: > On Thu, 16 Jul 2009, Andrew Haley wrote: > >> Jan Hubicka wrote: >>>> Running target unix/ >>>> FAIL: StackTrace2 output - source compiled test >>>> FAIL: StackTrace2 -findirect-dispatch output - source compiled test >>>> FAIL: StackTrace2 -O3 output - source compiled test >>>> FAIL: StackTrace2 -O3 -findirect-dispatch output - source compiled test >>> If I remember right, we had problems with this testcase in the pass too, >>> since it relies on middle end not inlining function but the functions is not >>> marked such? >> I don't think we mark them as inlinable. Are you saying that we have to mark >> them as *not* inlinable? >> >> Richard, can you let me see the log of this test? > > The log is > > Trace length = 4 > StackTrace2$Inner.doCrash:FAIL - expected 33, got: 34, in file > StackTrace2.java > StackTrace2$Inner.foo:OK > StackTrace2.a:OK > StackTrace2.main:OK > PASS: StackTrace2 execution - source compiled test > FAIL: StackTrace2 output - source compiled test > > foo is inlined into a which is inlined into main during early inlining. > During main inlining we inline some more, but the function names > in the dumps are not very useful for the Java FE so I couldn't figure > out what was inlined (some calls that were only called once).
OK, I've had a look, and I can see what the problem is, and it's not really to do with inlining. The problem seems more to do with location lists. Here's StackTrace2$Inner.doCrash: 31 public void doCrash(Object o) 32 { 33 o.toString(); 34 } but we generate this: .LBB13: .loc 1 34 0 movq (%rsi), %rax movq %rsi, %rdi .LVL3: call *40(%rax) .LVL4: Note the off-by-one error on the line number: all of the statement at Line 33 is marked in the debuginfo as being at Line 34. This may well be a bug in the front end. In any case, although it's a QOI problem, it's not critical and arguably not even wrong. Andrew.