gcc HEAD moves line number directives -- gcc bug?

gcc HEAD moves line number directives -- gcc bug?

[Michael Elizabeth Chastain]

This looks like another bug in gcc HEAD.  If you guys agree, I'll
file a bug report against gcc.

Here is some source code from gdb.mi/until.c:

  /* 20 */ main ()
  /* 21 */ {
  /* 22 */   int a = 1;
  /* 23 */   foo ();
  /* 24 */   a += 2;
  /* 25 */   return 0;
  /* 26 */ }

Here is the assembly code, gcc 3.3.1 -gdwarf-2 -S,
native i686-pc-linux-gnu:

  .globl main
          .type main, @function
  main:
  .LFB5:
          .loc 1 21 0
          pushl %ebp
  .LCFI3:
          movl  %esp, %ebp
  .LCFI4:
          subl  $8, %esp
  .LCFI5:
          andl  $-16, %esp
          movl  $0, %eax
          subl  %eax, %esp
          .loc 1 22 0
  .LBB3:
          movl  $1, -4(%ebp)
          .loc 1 23 0
          call  foo
          .loc 1 24 0
          leal  -4(%ebp), %eax
          addl  $2, (%eax)
          .loc 1 25 0
          movl  $0, %eax
          .loc 1 26 0
          leave
          ret
  .LBE3:
  .LFE5:
          .size main, .-main

Here is the assembly code, gcc HEAD -gdwarf-2 -S,
native i686-pc-linux-gnu:

  .globl main
          .type main, @function
  main:
  .LFB5:
          .loc 1 21 0
          pushl %ebp
  .LCFI3:
          movl  %esp, %ebp
  .LCFI4:
          subl  $8, %esp
  .LCFI5:
          andl  $-16, %esp
          movl  $0, %eax
          subl  %eax, %esp
          .loc 1 22 0
          movl  $1, -4(%ebp)
          .loc 1 23 0
          call  foo
          leal  -4(%ebp), %eax
          .loc 1 24 0
          addl  $2, (%eax)
          .loc 1 25 0
          movl  $0, %eax
          .loc 1 26 0
          leave
          ret
  .LFE5:
          .size main, .-main

Look at the code near 'call foo'.  In gcc 3.3.1, the .loc lines
match the source code.  In gcc HEAD, the .loc line for line 24
has migrated.

Source code:

  /* 23 */   foo ();
  /* 24 */   a += 2;

gcc 3.3.1 output:

          .loc 1 23 0
          call  foo
          .loc 1 24 0
          leal  -4(%ebp), %eax
          addl  $2, (%eax)

gcc HEAD output:

          .loc 1 23 0
          call  foo
          leal  -4(%ebp), %eax          // this insn is part of line 24
          .loc 1 24 0                   // this moved!
          addl  $2, (%eax)

This happens with explicit "-O0" in the command line.

This causes some mild confusion with gdb.  Specifically, an 'until'
command on foo returns and says it is on line 24 with gcc 3.3.1,
but on line 23 with gcc HEAD.

I isolated the patch that caused this:

  http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00430.html
  Jan Hubicka - Line number handling in RTL reorganization

Do you think this is a bug in gcc?  I do, but I need to check here
before filing a bug report with gcc.

Michael C

Re: gcc HEAD moves line number directives -- gcc bug?

[Daniel Jacobowitz]

On Mon, Sep 01, 2003 at 01:13:55PM -0400, Michael Elizabeth Chastain wrote:
> Look at the code near 'call foo'.  In gcc 3.3.1, the .loc lines
> match the source code.  In gcc HEAD, the .loc line for line 24
> has migrated.
> 
> Source code:
> 
>   /* 23 */   foo ();
>   /* 24 */   a += 2;
> 
> gcc 3.3.1 output:
> 
>           .loc 1 23 0
>           call  foo
>           .loc 1 24 0
>           leal  -4(%ebp), %eax
>           addl  $2, (%eax)
> 
> gcc HEAD output:
> 
>           .loc 1 23 0
>           call  foo
>           leal  -4(%ebp), %eax          // this insn is part of line 24
>           .loc 1 24 0                   // this moved!
>           addl  $2, (%eax)
> 
> This happens with explicit "-O0" in the command line.
> 
> This causes some mild confusion with gdb.  Specifically, an 'until'
> command on foo returns and says it is on line 24 with gcc 3.3.1,
> but on line 23 with gcc HEAD.
> 
> I isolated the patch that caused this:
> 
>   http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00430.html
>   Jan Hubicka - Line number handling in RTL reorganization
> 
> Do you think this is a bug in gcc?  I do, but I need to check here
> before filing a bug report with gcc.

Maybe, maybe not... our testsuite certainly must accept returning to
both line 23 and 24.  There are a number of architecures where a
function call includes instructions after the return (stack adjustment,
$gp reload...).

Line 24 is the addl.  The leal is generated probably in reload; it's
not really part of any line, even though it was generated for line 24.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gcc HEAD moves line number directives -- gcc bug?

[Richard Henderson]

On Mon, Sep 01, 2003 at 11:28:32PM -0400, Michael Elizabeth Chastain wrote:
> Okay, then I won't file a gcc PR about the 'leal' insn moving up from line 24
> to line 23.  I'm still kinda wary and sensitive about it though.

Go ahead and do file it, and mark it low priority.  We might see
about marking new generated insns as "coming from" the insn for
which they are generated.


r~

Re: gcc HEAD moves line number directives -- gcc bug?

[Michael Elizabeth Chastain]

drow> our testsuite certainly must accept returning to
drow> both line 23 and 24.  There are a number of architecures where a
drow> function call includes instructions after the return (stack adjustment,
drow> $gp reload...).

I didn't think of that.  You are right.  This is a bug in the test
script, independent of whether the compiler has a bug too.

In fact, even on x86, a "call" instruction might or might not
be followed by "add %esp, $N" to pop a arguments.  We had a similar
bug in gdb.base/advance.exp earlier this year.  Mumble grep ...

  2003-02-01  Michael Chastain  <mec@shout.net>

        * gdb.base/advance.c (marker1): New marker function.
        * gdb.base/advance.exp: When the 'advance' command lands on the
        return breakpoint, it can legitimately stop on either the
        current line or the next line.  Accommodate both outcomes.
        * gdb.base/until.exp: Likewise.

So I will submit a patch to fix gdb.mi/mi*-until.exp.

> Line 24 is the addl.  The leal is generated probably in reload; it's
> not really part of any line, even though it was generated for line 24.

Okay, then I won't file a gcc PR about the 'leal' insn moving up from line 24
to line 23.  I'm still kinda wary and sensitive about it though.

There are about a dozen gdb regressions from gcc 3.3.1 to gcc HEAD
with -gdwarf-2, and a lot more with -gstabs+ due to gcc/12066.
I'll keep grinding them.

Thanks,

Michael C