[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #22 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:006783f4b165dff25aae3697920fcf547544 commit r11-8164-g006783f4b165dff25aae3697920fcf547544 Author: Jason Merrill Date: Tue Apr 13 16:18:54 2021 -0400 c++: debug location of variable cleanups [PR88742] PR49951 complained about the debugger jumping back to the declaration of a local variable when we run its destructor. That was fixed in 4.7, but broke again in 4.8. PR58123 fixed an inconsistency in the behavior, but not the jumping around. This patch addresses the issue by setting EXPR_LOCATION on a cleanup destructor call to the location of the closing brace of the compound-statement, or whatever token ends the scope of the variable. The change to cp_parser_compound_statement is so input_location is the } rather than the ; of the last substatement. gcc/cp/ChangeLog: PR c++/88742 PR c++/49951 PR c++/58123 * semantics.c (set_cleanup_locs): New. (do_poplevel): Call it. * parser.c (cp_parser_compound_statement): Consume the } before finish_compound_stmt. gcc/testsuite/ChangeLog: PR c++/88742 * g++.dg/debug/cleanup1.C: New test. * c-c++-common/Wimplicit-fallthrough-6.c: Adjust diagnostic line. * c-c++-common/Wimplicit-fallthrough-7.c: Likewise. * g++.dg/cpp2a/constexpr-dtor3.C: Likewise. * g++.dg/ext/constexpr-attr-cleanup1.C: Likewise. * g++.dg/tm/inherit2.C: Likewise. * g++.dg/tm/unsafe1.C: Likewise. * g++.dg/warn/Wimplicit-fallthrough-1.C: Likewise. * g++.dg/gcov/gcov-2.C: Adjust coverage counts.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #21 from asmwarrior asmwarrior at gmail dot com --- I just test the sample code in comment 20 with GCC 4.9.2, and I see this jumpy behaviour still exists, do we need to reopen this bug? Thanks.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951
--- Comment #19 from asmwarrior asmwarrior at gmail dot com ---
Hi, I see this bug happens at least in GCC 4.8.2 again. I'm using MinGW-Build
GCC 4.8.2 under Windows, and debug Codeblocks. I have a source code which have
something like:
void CompilerGCC::SetupEnvironment()
{
wxString currentPath;
}
But When I debug through lines using the step command, I see that the caret
still go back the the local variable definition of the line wxString
currentPath.
I tried the simple test code that Peter Thompson gives, but it works fine, So
it looks like this bug happens in a larger project not the simple one.
Currently I don't have much way to show you. When I see the disassembler code,
I see some call to destructor of wxString.
0x64B0CF81call 0x64b4f094 InfoWindow::Display(wxString const, wxString
const, unsigned int, unsigned int)
0x64B0CF86leaeax,[ebp-0x34]
0x64B0CF89movecx,eax
0x64B0CF8Bcall 0x64b5c090 wxString::~wxString()
0x64B0CF90leaeax,[ebp-0x38]
0x64B0CF93movecx,eax
0x64B0CF95call 0x64b5c090 wxString::~wxString()
0x64B0CF9Aleaeax,[ebp-0x30]
0x64B0CF9DmovDWORD PTR [esp],0x64b6bc70
0x64B0CFA4movecx,eax
When I run
info line *0x64B0CFDB
[debug]Line 801 of F:\cb_sf_git\trunk\src\plugins\compilergcc\compilergcc.cpp
starts at address 0x64b0cf9a CompilerGCC::SetupEnvironment()+3258 and ends at
0x64b0cfe0 CompilerGCC::SetupEnvironment()+3328.
[debug]F:\cb_sf_git\trunk\src\plugins\compilergcc\compilergcc.cpp:801:32074:beg:0x64b0cf9a
But it looks like this is not enough information I can show you, any suggest
how to see the incorrect line-code map? Thanks.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951
--- Comment #20 from asmwarrior asmwarrior at gmail dot com ---
Hi, all. After the conversation on GDB IRC with GDB developer Jan Kratochvil, a
simple test code supplied by Jan in his bug report on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58123#c0 can easily demonstrate
this issue in either GCC 4.8.2 or GCC 4.8.1.
class C {
public:
C() {}
~C() {}
int m() { return 0; }
};
/* 7 */ int main() {
/* 8 */ C a;
/* 9 */ C b;
/* 10 */ C c;
/* 11 */ return a.m() + b.m() + c.m();
/* 12 */ }
You will run next command back to line 10, and line 9 until go to the end of
the function main().
Note: the bug #58123 is another issue, Jan expected that the caret should go
back to line 8, but it is not.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||chihin.ko at oracle dot com --- Comment #18 from Andrew Pinski pinskia at gcc dot gnu.org 2012-12-22 04:00:07 UTC --- *** Bug 55785 has been marked as a duplicate of this bug. ***
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #15 from dodji at seketeli dot org dodji at seketeli dot org 2012-01-02 12:01:45 UTC --- It would be very helpful to get this into 4.6.3 too if it's safe Sure thing. I am currently testing the patch on 4.6. Thanks for the head-up.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #16 from Dodji Seketeli dodji at gcc dot gnu.org 2012-01-02 17:08:50 UTC --- Author: dodji Date: Mon Jan 2 17:08:45 2012 New Revision: 182807 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182807 Log: PR debug/49951 - jumpy stepping at end of scope in C++ gcc/cp/ PR debug/49951 * decl.c (cxx_maybe_build_cleanup): Don't set location of the call to the destructor. gcc/testsuite/ PR debug/49951 * g++.dg/gcov/gcov-2.C: Adjust. Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/decl.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/g++.dg/gcov/gcov-2.C
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #11 from Dodji Seketeli dodji at gcc dot gnu.org 2011-12-20 13:36:08 UTC --- Author: dodji Date: Tue Dec 20 13:36:04 2011 New Revision: 182532 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182532 Log: PR debug/49951 - jumpy stepping at end of scope in C++ gcc/cp/ PR debug/49951 * decl.c (cxx_maybe_build_cleanup): Don't set location of the call to the destructor. gcc/testsuite/ PR debug/49951 * g++.dg/gcov/gcov-2.C: Adjust. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/gcov/gcov-2.C
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Dodji Seketeli dodji at gcc dot gnu.org 2011-12-20 13:40:30 UTC --- This should be fixed in trunk (4.7).
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-20 13:49:28 UTC --- Thanks! It would be very helpful to get this into 4.6.3 too if it's safe
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #14 from asmwarrior asmwarrior at gmail dot com 2011-12-21 03:21:07 UTC --- Thanks for fix this bug, I hope some devs will backport this patch to 4.5/4.6 branches.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #8 from Dodji Seketeli dodji at gcc dot gnu.org 2011-12-03 18:23:38 UTC --- A candidate analysis and patch has been posted to http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00250.html for comments.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-12-03 19:03:54 UTC --- (In reply to comment #8) A candidate analysis and patch has been posted to http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00250.html for comments. What I don't understand is how, according to your analysis, this worked before revision 149722 and how that patch could possibly change the behavior.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951
--- Comment #10 from dodji at seketeli dot org dodji at seketeli dot org
2011-12-03 20:55:15 UTC ---
What I don't understand is how, according to your analysis, this
worked before revision 149722 and how that patch could possibly
change the behavior.
OK, you caught me. I admit I haven't really looked at that patch
before starting debugging this issue. So now I might have an
additional theory. :-)
I think that before the commit r149722, the call expression to the
destructor simply had no location. And that patch added a location to
it. So we didn't have the jumpy behaviour because we were ignoring
the presence of the call to the destructor, from a stepping point of
view.
Here is why I am thinking that.
The call to the destructor of m ends up being generated by
build_cxx_call, in cp/call.c. At the time of the patch, that function
started with:
tree
build_cxx_call (tree fn, int nargs, tree *argarray)
{
tree fndecl;
fn = build_call_a (fn, nargs, argarray);
...
}
So it was calling build_call_a, that the patch modified as:
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -362,7 +362,8 @@ build_call_a (tree function, int n, tree *argarray)
argarray[i], t);
}
- function = build_call_array (result_type, function, n, argarray);
+ function = build_call_array_loc (input_location,
+ result_type, function, n, argarray);
TREE_HAS_CONSTRUCTOR (function) = is_constructor;
TREE_NOTHROW (function) = nothrow;
See how the call to build_call_array got changed into a call
tobuild_call_array_loc.
The change that turned build_call_array into build_call_array_loc in
tree.c was:
tree
-build_call_array (tree return_type, tree fn, int nargs, const tree *args)
+build_call_array_loc (location_t loc, tree return_type, tree fn,
+ int nargs, const tree *args)
{
tree t;
int i;
@@ -8549,6 +8550,7 @@ build_call_array (tree return_type, tree fn, int
nargs, const tree *args)
for (i = 0; i nargs; i++)
CALL_EXPR_ARG (t, i) = args[i];
process_call_operands (t);
+ SET_EXPR_LOCATION (t, loc);
return t;
}
See how the patch adds a location to the resulting call expression
there. Without that, the previous build_call_array just had no
location, I think.
The change you had to do on gcc/testsuite/g++.dg/gcov/gcov-2.C doesn't
seem to argue against this theory:
@@ -20,7 +20,7 @@ private:
void foo()
{
- C c;/* count(1) */
+ C c;/* count(2) */
c.seti (1);/* count(1) */
}
Here we see that before the patch, there was only one call issued on
the line of C c; - and that was probably the call to the constructor.
After, there were two calls on that line, and I think that was the
call to the destructor that added up. Note that we didn't have any
call on the line of the closing '}', for instance.
Now I am thinking that maybe it would be best to have the call to the
destructor be on the last statement of the block, rather than on the
'}', if we'd have a location for that call at all.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|dodji at gcc dot gnu.org| AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org, ||redi at gcc dot gnu.org --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-29 19:02:30 UTC --- Manu, could you look at this? This is quite an annoying regression for C++
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-11-29 22:49:58 UTC --- (In reply to comment #6) Manu, could you look at this? This is quite an annoying regression for C++ After a couple of hours I gave up. I tried greping for build.*finally, finally, build_destructor, destructor. I tried breaking in gimplify_expr but I think it is already too late. I tried breaking in build_cleanup and build_delete but those functions get called too often, and I didn't see where the finally block is generated. If someone knows exactly where the finally block is generated in the C++ FE, please let me know, and I may give it another try in the future.
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #5 from asmwarrior asmwarrior at gmail dot com 2011-10-29 14:06:53 UTC --- Hi, all, I think this bug happened about more than one years, I have test in both gcc 4.5 and gcc 4.6.x under Windows. I have both post an issue in GDB maillist and GCC-help maillist. see: http://gcc.gnu.org/ml/gcc-help/2011-10/msg00239.html and http://sourceware.org/ml/gdb/2011-10/msg00209.html The GDB guys thoughts that this is a bug in GCC, and GCC emit wrong debug_line information. When I use GDB under Codeblocks, it will always do some extra jump to variable declaration, and quite unfriendly. asmwarrior ollydbg from codeblocks' forum
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-10 12:04:49 UTC --- Aldy?
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-04 08:42:45 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=149722
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.08.03 09:34:43
Target Milestone|--- |4.5.4
Summary|Debug stepping behavior |[4.5/4.6/4.7 Regression]
|regarding g++ Class |Debug stepping behavior
|destructor has changed for |regarding g++ Class
|the worse starting at gcc |destructor has changed for
|4.5.0 |the worse starting at gcc
||4.5.0
Ever Confirmed|0 |1
Known to fail||4.5.3, 4.6.1, 4.7.0
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-03
09:34:43 UTC ---
Confirmed.
The destruction is implemented via a try {} finally where the finally
block seems to get the source location of the construction of the
object rather than the source location of it going out of scope:
int main(int, char**) (int argc, char * * argv)
{
int D.2623;
[t.C : 19:5] {
int i;
struct MyClass m;
[t.C : 13:11] i = 1;
[t.C : 14:11] MyClass::MyClass ([t.C : 14] m);
[t.C : 19:5] try
{
[t.C : 16:3] if (i == 1) goto D.2620; else goto D.2621;
D.2620:
[t.C : 18:37] printf (Hello world %d\n, i);
goto D.2622;
D.2621:
D.2622:
}
finally
{
[t.C : 14:11] MyClass::~MyClass ([t.C : 14] m);
}
}
[t.C : 0:0] D.2623 = 0;
[t.C : 0:0] return D.2623;
}
With 4.4 we still had
int main(int, char**) (int argc, char * * argv)
{
int D.2628;
[t.C : 19] {
int i;
struct MyClass m;
[t.C : 13] i = 1;
[t.C : 14] __comp_ctor ([t.C : 14] m);
[t.C : 19] try
{
[t.C : 16] if (i == 1) goto D.2625; else goto D.2626;
D.2625:
[t.C : 18] printf (Hello world %d\n[0], i);
goto D.2627;
D.2626:
D.2627:
}
finally
{
[t.C : 19] __comp_dtor ([t.C : 19] m);
}
}
[t.C : 0] D.2628 = 0;
[t.C : 0] return D.2628;
}
So the finally block stmts inherit the try/finally location.
Might be a gimplification or frontend issue.
