This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][RFC] Gimplify unit-at-a-time (again)
- From: Andrew Haley <aph at redhat dot com>
- To: Richard Guenther <rguenther at suse dot de>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 20 Jul 2009 12:41:06 +0100
- Subject: Re: [PATCH][RFC] Gimplify unit-at-a-time (again)
- References: <alpine.LNX.firstname.lastname@example.org> <4A5F39F4.email@example.com> <20090716143520.GD17552@atrey.karlin.mff.cuni.cz> <4A5F3DEC.firstname.lastname@example.org> <alpine.LNX.email@example.com>
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
> 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
31 public void doCrash(Object o)
but we generate this:
.loc 1 34 0
movq (%rsi), %rax
movq %rsi, %rdi
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.