From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-15341-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 14016 invoked by alias); 1 Sep 2003 17:13:58 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 14005 invoked from network); 1 Sep 2003 17:13:56 -0000
Received: from unknown (HELO concert.shout.net) (204.253.184.25)
  by sources.redhat.com with SMTP; 1 Sep 2003 17:13:56 -0000
Received: from duracef.shout.net (duracef.shout.net [204.253.184.12])
	by concert.shout.net (8.12.9/8.12.9) with ESMTP id h81HDtrY013882
	for <gdb@sources.redhat.com>; Mon, 1 Sep 2003 12:13:55 -0500
Received: from duracef.shout.net (localhost [127.0.0.1])
	by duracef.shout.net (8.12.9/8.12.9) with ESMTP id h81HDtHK003771
	for <gdb@sources.redhat.com>; Mon, 1 Sep 2003 12:13:55 -0500
Received: (from mec@localhost)
	by duracef.shout.net (8.12.9/8.12.9/Submit) id h81HDtHx003770
	for gdb@sources.redhat.com; Mon, 1 Sep 2003 13:13:55 -0400
Date: Mon, 01 Sep 2003 17:13:00 -0000
From: Michael Elizabeth Chastain <mec@shout.net>
Message-Id: <200309011713.h81HDtHx003770@duracef.shout.net>
To: gdb@sources.redhat.com
Subject: gcc HEAD moves line number directives -- gcc bug?
X-SW-Source: 2003-09/txt/msg00004.txt.bz2

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