This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFC] Gimplify unit-at-a-time (again)


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]