* Re: [PATCH][RFC] Gimplify unit-at-a-time (again) [not found] ` <alpine.LNX.2.00.0907171249040.16347@zhemvz.fhfr.qr> @ 2009-07-20 11:41 ` Andrew Haley 2009-07-20 11:48 ` Andrew Haley 0 siblings, 1 reply; 2+ messages in thread From: Andrew Haley @ 2009-07-20 11:41 UTC (permalink / raw) To: Richard Guenther; +Cc: Jan Hubicka, GCC Development 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. ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH][RFC] Gimplify unit-at-a-time (again) 2009-07-20 11:41 ` [PATCH][RFC] Gimplify unit-at-a-time (again) Andrew Haley @ 2009-07-20 11:48 ` Andrew Haley 0 siblings, 0 replies; 2+ messages in thread From: Andrew Haley @ 2009-07-20 11:48 UTC (permalink / raw) To: Richard Guenther; +Cc: Jan Hubicka, GCC Development Andrew Haley wrote: > 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. I don't think it is a FE issue, since 4.5.0 20090629 does it right: StackTrace2$Inner.doCrash(java.lang.Object)void: .LFB2: .cfi_startproc .cfi_personality 0x3,__gcj_personality_v0 .LVL2: subq $8, %rsp .LCFI2: .cfi_def_cfa_offset 16 .LBB13: .loc 1 33 0 movq (%rsi), %rax movq %rsi, %rdi .LVL3: call *40(%rax) .LVL4: .LBE13: .loc 1 34 0 addq $8, %rsp .LCFI3: .cfi_def_cfa_offset 8 ret .cfi_endproc There seems to have been some kind of regression with location lists since 20090629. Andrew. ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-07-20 11:48 UTC | newest] Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <alpine.LNX.2.00.0907061525300.16347@zhemvz.fhfr.qr> [not found] ` <4A5F39F4.6010104@redhat.com> [not found] ` <20090716143520.GD17552@atrey.karlin.mff.cuni.cz> [not found] ` <4A5F3DEC.7090207@redhat.com> [not found] ` <alpine.LNX.2.00.0907171249040.16347@zhemvz.fhfr.qr> 2009-07-20 11:41 ` [PATCH][RFC] Gimplify unit-at-a-time (again) Andrew Haley 2009-07-20 11:48 ` Andrew Haley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).