From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9579 invoked by alias); 19 May 2014 19:32:52 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 9530 invoked by uid 48); 19 May 2014 19:32:49 -0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/61210] bootstrap failure with clang Date: Mon, 19 May 2014 19:32:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-05/txt/msg01656.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D61210 --- Comment #6 from Uro=C5=A1 Bizjak --- (In reply to David Binderman from comment #5) > I'll try again in a few days time. Richard S. is preparing a patch at [1], perhaps you can help to test it? [1] https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01519.html >>From gcc-bugs-return-451965-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon May 19 19:34:27 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 10961 invoked by alias); 19 May 2014 19:34:26 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 10927 invoked by uid 48); 19 May 2014 19:34:22 -0000 From: "dje at google dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/61237] New: gcc puts line number 11 ahead of line number 10 in function call in debug info Date: Mon, 19 May 2014 19:34:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: 4.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dje at google dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-05/txt/msg01657.txt.bz2 Content-length: 2311 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61237 Bug ID: 61237 Summary: gcc puts line number 11 ahead of line number 10 in function call in debug info Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: dje at google dot com I can imagine gcc's trying to be helpful here, but it's not working in this case (at least in IMHO). I want to set a breakpoint on line 10, but when I get there line 11 has already been executed, and by that time it's too late. [This example is stripped down from the original.] 1 int 2 foo (int a, int b) 3 { 4 return a + b; 5 } 6 7 int 8 main () 9 { 10 foo (1, 11 -foo (2, 3)); 12 return 0; 13 } $ gdb a.out (gdb) disas /m main Dump of assembler code for function main: 9 { 0x0000000000400484 <+0>: push %rbp 0x0000000000400485 <+1>: mov %rsp,%rbp 10 foo (1, 0x0000000000400497 <+19>: neg %eax 0x0000000000400499 <+21>: mov %eax,%esi 0x000000000040049b <+23>: mov $0x1,%edi 0x00000000004004a0 <+28>: callq 0x400470 11 -foo (2, 3)); 0x0000000000400488 <+4>: mov $0x3,%esi 0x000000000040048d <+9>: mov $0x2,%edi 0x0000000000400492 <+14>: callq 0x400470 12 return 0; 0x00000000004004a5 <+33>: mov $0x0,%eax 13 } 0x00000000004004aa <+38>: pop %rbp 0x00000000004004ab <+39>: retq End of assembler dump. gdb's attempt at making mixed disassembly output more readable isn't helpful either. The thing to note here is that line 11 appears before line 10 in the code. Technically, one can argue that that is correct I suppose. And if that is the answer, fine. I'm just filing this so that the answer is written down somewhere. I did spend 10 minutes trying to find an existing bug in the database (which feels like enough - I have to time out at some point), and I grepped for O0 in the "not a bug" page https://gcc.gnu.org/bugs/#nonbugs and didn't find anything. OTOH, if you want to agree this is a bug, fine by me. :-)