$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --enable-languages=c,c++ --disable-multilib --prefix=/usr/local/gcc-trunk Thread model: posix gcc version 10.0.0 20190517 (experimental) (GCC) $ gdb -v GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git Copyright (C) 2018 Free Software Foundation, Inc. $ cat small.c int c() { int b = 1; f: if (b) { short g[1]; for (; b < 0;) { goto f; return 0; // line 9 } return 0; } else ; return 0; } void main() { c(); } $ gcc -O0 -g small.c; gdb -batch -x cmds a.out Breakpoint 1 at 0x40049b: file small.c, line 9. Breakpoint 1, c () at small.c:11 11 return 0; g = {64} b = 1 Kill the program being debugged? (y or n) [answered Y; input not from terminal] $ cat cmds b 9 r info locals kill q ========================================================================= We set breakpoint at line 9 "b 9" in cmds. Line #9 is never executed. Thus, the expected behavior should be exit normally. However, it stopped at line 11. We are not set breakpoint in line 11. Thus, I was wondering this is a bug in gdb.
The reason is that somehow the only stmt with line 9 prevailing is one not originally having it: <bb 6> : [t.c:11:14] D.1918 = 0; [t.c:11:14] // predicted unlikely by early return (on trees) predictor. [t.c:9:11] g = {CLOBBER}; goto <bb 8>; [INV] <bb 7> : [t.c:14:10] D.1918 = 0; <bb 8> : <L8>: return D.1918; so the return stmt will end up inheriting it if we are "lucky". try-finally lowering assigns the location, possibly simply taking the location of the last stmt from the "throw".
(In reply to Richard Biener from comment #1) > The reason is that somehow the only stmt with line 9 prevailing is one > not originally having it: > > <bb 6> : > [t.c:11:14] D.1918 = 0; > [t.c:11:14] // predicted unlikely by early return (on trees) predictor. > [t.c:9:11] g = {CLOBBER}; > goto <bb 8>; [INV] > > <bb 7> : > [t.c:14:10] D.1918 = 0; > > <bb 8> : > <L8>: > return D.1918; > > so the return stmt will end up inheriting it if we are "lucky". try-finally > lowering assigns the location, possibly simply taking the location of the > last stmt from the "throw". Thanks for the explanation. Thus, I was wondering that this bug should be marked as "invalid"
I think it is a genuine bug