From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 0C0573858C66; Wed,  2 Nov 2022 11:58:42 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0C0573858C66
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1667390325;
	bh=WX19qZDfqkQijRnjAEH04LNODf9RC4SuFJX6zzjeATE=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=HsBdcFdE1aNK9ZptCKhbeI6mk0EsouAKkq0XFOwlHW/DrSgjMeWGNaizQwA2xOhN9
	 F+kV4c5hw10Ov5hTnsmaLa+zDxyjeFUAcz4V0ZHEvY2Feqo976bVt9gbYYrUrW/8Ml
	 U+0fBSPB4PWr6sc01XYqMZbE4pgcABwn7XQKa034=
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/107504] Debugger jumps back to structured binding
 declaration
Date: Wed, 02 Nov 2022 11:58:41 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: wrong-debug
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
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: <bug-107504-4-7AYd6ZlviL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107504-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107504-4@http.gcc.gnu.org/bugzilla/>
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
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107504

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'm also seeing similar jumps back and forth in the debugger for the bodies=
 of
lambda expressions, where the debugger keeps jumping back to the capture li=
st
of the lambda:


$ cat lambda.cc=20
int main(int argc, char**)
{
  int x =3D 1;
  auto f =3D [&x, &argc](const char* i) {
    i +=3D x;
    i -=3D argc;
    i +=3D argc - x;
    return i;
  };
  f("          ");
}
$ g++ -g lambda.cc -o lambda
$ gdb -q -ex start -ex 'py [gdb.execute("step") for n in range(14)]' ./lamb=
da
Reading symbols from ./lambda...
Temporary breakpoint 1 at 0x40117a: file lambda.cc, line 3.
Starting program: /tmp/lambda=20
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, main (argc=3D1) at lambda.cc:3
3         int x =3D 1;
9         };
10        f("          ");
operator() (__closure=3D0x7fffffffda60, i=3D0x402004 "          ") at lambd=
a.cc:5
5           i +=3D x;
4         auto f =3D [&x, &argc](const char* i) {
5           i +=3D x;
6           i -=3D argc;
4         auto f =3D [&x, &argc](const char* i) {
6           i -=3D argc;
7           i +=3D argc - x;
4         auto f =3D [&x, &argc](const char* i) {
7           i +=3D argc - x;
4         auto f =3D [&x, &argc](const char* i) {
7           i +=3D argc - x;
8           return i;

We keep returning to line 4 (the capture) every time the captured variiable=
 is
odr-used.=