Bug 5271

Summary:	Wrong line number information with optimization
Product:	gcc	Reporter:	carlo
Component:	debug	Assignee:	Not yet assigned to anyone <unassigned>
Status:	RESOLVED FIXED
Severity:	normal	CC:	carlo, gcc-bugs
Priority:	P3
Version:	3.0.3
Target Milestone:	4.0.0
Host:		Target:
Build:		Known to work:
Known to fail:		Last reconfirmed:	2005-09-24 05:15:09
Bug Depends on:	19192
Bug Blocks:

Description carlo 2002-01-03 19:06:00 UTC

In relationship with optimisation (inlining)
the source file / line number information in
the debugging sections are wrong.  This is a
major problem when debugging code (being
given a wrong source file, it is impossible
to know where the location really is/was).

Release:
3.0.3

Environment:
any (i686-gnu-linux here)

How-To-Repeat:
See follow up: it is absolutely impossible
to paste things in this web interface using
mozilla.

Comment 1 carlo 2002-01-04 05:03:20 UTC

From: Carlo Wood <carlo@alinoe.com>
To: gcc-gnats@gcc.gnu.org
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: debug/5271: Wrong line number information.
Date: Fri, 4 Jan 2002 05:03:20 +0100

 How-To-Repeat:
 Call the following preprocessed file "bug.ii"
 
 # 14 "libcwd.tst/leak.cc"
 # 206 "../include/libcw/macro_AllocTag.h"
 __inline__
 int
 foo(int i)
 {
   i += 1234;
   return i;
 };
 # 19 "libcwd.tst/leak.cc"
 
 int main(void)
 {
   int t = foo(*new int);
   return t;
 }
 
 Next compile this file with a command like:
 
 ~/c++/libcw/src/libcwd/testsuite>/usr/local/gcc-3.0.3/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/cc1plus -fpreprocessed bug.ii -quiet -dumpbase leak.cc -gdwarf-2 -O -version -o bug.s
 GNU CPP version 3.0.3 (cpplib) (i386 Linux/ELF)
 GNU C++ version 3.0.3 (i686-pc-linux-gnu)
         compiled by GNU C version 3.0.3.
 
 This will result in a file bug.s that shows that
 the line number information is such that the call
 to 'new int' appears to be made in macro_AllocTag.h
 while obviously it is done in main() in leak.cc.
 
 main:
 .LFB1:
         .file 2 "libcwd.tst/leak.cc"
         .loc 2 21 0
         pushl   %ebp
 .LCFI0:
         movl    %esp, %ebp
 .LCFI1:
         subl    $8, %esp
 .LCFI2:
         andl    $-16, %esp
 .LBB2:
         .loc 2 22 0
         .file 3 "../include/libcw/macro_AllocTag.h"
         .loc 3 209 0
 .LBB3:
         subl    $12, %esp
         pushl   $4
 .LCFI3:
         call    _Znwj
         addl    $16, %esp
         .loc 3 210 0
         movl    (%eax), %eax
         addl    $1234, %eax
 .LBE3:
         .loc 2 23 0
 .LBE2:
         .loc 2 24 0
         movl    %ebp, %esp
         popl    %ebp
         ret
 
 Clearly, the line ".loc 3 209 0" should not be there.
  
 -- 
 Carlo Wood <carlo@alinoe.com>

Comment 2 Wolfgang Bangerth 2003-03-14 02:43:30 UTC

State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed, problem still exists in present mainline of
    today. The call to operator new happens before we jump into
    foo, but this is not reflected in the debug info. Needless
    to say that the problem goes away once we switch off
    optimization.
    
    W.

Comment 3 Andrew Pinski 2003-06-07 22:34:30 UTC

This is a dup of bug 4431 which is related to bug 10003.

*** This bug has been marked as a duplicate of 4431 ***

Comment 4 carlo 2003-09-20 15:21:55 UTC

Not a duplicate of 4431.

Comment 5 Carlo Wood 2003-10-07 22:51:41 UTC

*** Bug 4431 has been marked as a duplicate of this bug. ***

Comment 6 Andrew Pinski 2005-09-24 05:15:09 UTC

For the mainline and 4.0.0, the issue is really PR 19192.

Comment 7 Andrew Pinski 2005-12-28 06:18:06 UTC

Fixed in 4.0.0.