* 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).