This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/29609] New: [regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug
- From: "debian-gcc at lists dot debian dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 26 Oct 2006 21:46:19 -0000
- Subject: [Bug debug/29609] New: [regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
[forwarded from http://bugs.debian.org/395057]
In the following sample code, gcc does not create enough
debugging information to let gdb break in lines 27, 30, 33, 36.
This makes debugging the main() function extremely painful.
This is a regression from gcc 2.95 and gcc 3.3, both of which
let gdb set a breakpoint on those lines.
The ability to debug such code is very important to me, since
I usually write my C functions with some cleanup code
after a 'failure' label in the style below.
[comment from Daniel Jacobowitz: Yes, this was a GDB bug earlier in the day.
He's right. I think it's jump threading, or something like that, running even
at -O0; seems like it shouldn't, for this reason.]
int f1(void) /* this "succeeds", i.e. returns 1 */
{
return 1;
}
int f2(void) /* this "succeeds", i.e. returns 1 */
{
return 1;
}
int f3(void) /* this "fails", i.e. returns 0 */
{
return 0;
}
int f4(void) /* this "succeeds", i.e. returns 1 */
{
return 1;
}
int main(int argc, char *argv[])
{
int c;
if (!f1())
goto failure;
if (!f2())
goto failure;
if (!f3())
goto failure;
if (!f4())
goto failure;
success:
return 0;
failure:
return 1;
}
--
Summary: [regression] Even with -O0 -g gcc optimizes a goto away
and I cannot debug
Product: gcc
Version: 3.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609