[Bug debug/96997] New: step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[Bug debug/96997] New: step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[alexis.jeandet at member dot fsf.org]

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

            Bug ID: 96997
           Summary: step over in gdb always stops in basic_string(const
                    _CharT* __s, const _Alloc& __a = _Alloc())
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: alexis.jeandet at member dot fsf.org
  Target Milestone: ---

Minimum code to reproduce the issue:

#include <iostream>
#include <string>


int main()
{
        std::cout << std::string{"str1"};
        std::cout << std::string{"str2"};
        return 0;
}

Stepping over will stop in basic_string ctor which is unexpected. This is
reproductible with G++ 10.2.1 and 10.2.0 (Fedora 32, 32 and Arch). 
On the same machine building with clang and debugging with gdb doesn't have
this issue.

g++9 and 8 works as expected.

[Bug debug/96997] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-09-09
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Confirmed:

$ gdb -quiet  -ex start -ex n -ex l -ex where  -ex n -ex l -ex where -ex n -ex
l -ex where -ex cont -ex quit  a.out
Reading symbols from a.out...
Temporary breakpoint 1 at 0x4011bf: file so.C, line 7.
Starting program: /tmp/a.out 

Temporary breakpoint 1, main () at so.C:7
7               std::cout << std::string{"str1"};
525           basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
520     #if __cpp_deduction_guides && ! defined
_GLIBCXX_DEFINING_STRING_INSTANTIATIONS
521           // _GLIBCXX_RESOLVE_LIB_DEFECTS
522           // 3076. basic_string CTAD ambiguity
523           template<typename = _RequireAllocator<_Alloc>>
524     #endif
525           basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
526           : _M_dataplus(_M_local_data(), __a)
527           { _M_construct(__s, __s ? __s + traits_type::length(__s) :
__s+npos); }
528
529           /**
#0  main () at /usr/include/c++/10/bits/basic_string.h:525
8               std::cout << std::string{"str2"};
3
4
5       int main()
6       {
7               std::cout << std::string{"str1"};
8               std::cout << std::string{"str2"};
9               return 0;
10      }
11
#0  main () at so.C:8
525           basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
520     #if __cpp_deduction_guides && ! defined
_GLIBCXX_DEFINING_STRING_INSTANTIATIONS
521           // _GLIBCXX_RESOLVE_LIB_DEFECTS
522           // 3076. basic_string CTAD ambiguity
523           template<typename = _RequireAllocator<_Alloc>>
524     #endif
525           basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
526           : _M_dataplus(_M_local_data(), __a)
527           { _M_construct(__s, __s ? __s + traits_type::length(__s) :
__s+npos); }
528
529           /**
#0  main () at /usr/include/c++/10/bits/basic_string.h:525
Continuing.
str1str2[Inferior 1 (process 2307959) exited normally]

Although the current frame is still main() the current location is shown as the
basic_string constructor.

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.3
                 CC|                            |vries at gcc dot gnu.org
           Priority|P3                          |P2
      Known to fail|                            |10.2.0
      Known to work|                            |7.5.0
            Summary|step over in gdb always     |[10/11 Regression] step
                   |stops in basic_string(const |over in gdb always stops in
                   |_CharT* __s, const _Alloc&  |basic_string(const _CharT*
                   |__a = _Alloc())             |__s, const _Alloc& __a =
                   |                            |_Alloc())

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
Line number info for main [4009d2,400ad2] with g++ 9.3.1:
...
CU: ./test.c:
File name                            Line number    Starting address    View   
Stmt
test.c                                         6            0x4009d2           
   x
test.c                                         7            0x4009db           
   x
test.c                                         7            0x4009fc           
   x
test.c                                         7            0x400a0d           
   x
test.c                                         8            0x400a25           
   x
test.c                                         8            0x400a46           
   x
test.c                                         8            0x400a57           
   x
test.c                                         9            0x400a6f           
   x
test.c                                         7            0x400a79           
   x
test.c                                         7            0x400a8a        
test.c                                         8            0x400aa4           
   x
test.c                                         8            0x400ab5        
test.c                                        10            0x400acc           
   x
...

Line number info for main [4009d6,400ad5] with g++ 10.2.1:
...
CU: ./test.c:
File name                            Line number    Starting address    View   
Stmt
test.c                                         6            0x4009d6           
   x
test.c                                         7            0x4009df           
   x
test.c                                         7            0x400a00        
test.c                                         7            0x400a11           
   x

/usr/include/c++/10/bits/basic_string.h:
basic_string.h                               525            0x400a1d           
   x

./test.c:[++]
test.c                                         8            0x400a29           
   x
test.c                                         8            0x400a4a        
test.c                                         8            0x400a5b           
   x

/usr/include/c++/10/bits/basic_string.h:
basic_string.h                               525            0x400a67           
   x

./test.c:[++]
test.c                                         9            0x400a73           
   x
test.c                                         7            0x400a7a           
   x

/usr/include/c++/10/bits/basic_string.h:
basic_string.h                               525            0x400a8b           
   x

./test.c:[++]
test.c                                         8            0x400aa5           
   x

/usr/include/c++/10/bits/basic_string.h:
basic_string.h                               525            0x400ab6           
   x

./test.c:[++]
test.c                                        10            0x400ad0           
   x
...

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
-fdump-tree-all-lineno with gcc-9:
...
main ()
{
  struct string D.36200;
  struct allocator D.36199;
  struct string D.36242;
  struct allocator D.36241;
  int D.39843;

  [test.c:7:27] std::allocator<char>::allocator ([test.c:7:27] &D.36199);
  [test.c:7:19] try
    {
      try
        {
          [test.c:7:27] std::__cxx11::basic_string<char>::basic_string
([test.c:7:27] &D.36200, [test.c:7:27] "str1", &D.36199);
          try
            {
              try
                {
                  [test.c:7:40] std::operator<< <char, std::char_traits<char>,
std::allocator<char> > ([test.c:7:40] &cout, [test.c:7:27] &D.36200);
                }
              finally
                {
                  [test.c:7:27] std::__cxx11::basic_string<char>::~basic_string
([test.c:7:27] &D.36200);
                }
            }
          finally
            {
              [test.c:7:27] D.36200 = {CLOBBER};
            }
        }
      finally
        {
          [test.c:7:27] std::allocator<char>::~allocator ([test.c:7:27]
&D.36199);
        }
    }
  finally
    {
      [test.c:7:27] D.36199 = {CLOBBER};
    }
  [test.c:8:27] std::allocator<char>::allocator ([test.c:8:27] &D.36241);
  [test.c:8:19] try
    {
      try
        {
          [test.c:8:27] std::__cxx11::basic_string<char>::basic_string
([test.c:8:27] &D.36242, [test.c:8:27] "str2", &D.36241);
          try
            {
              try
                {
                  [test.c:8:40] std::operator<< <char, std::char_traits<char>,
std::allocator<char> > ([test.c:8:40] &cout, [test.c:8:27] &D.36242);
                }
              finally
                {
                  [test.c:8:27] std::__cxx11::basic_string<char>::~basic_string
([test.c:8:27] &D.36242);
                }
            }
          finally
            {
              [test.c:8:27] D.36242 = {CLOBBER};
            }
        }
      finally
        {
          [test.c:8:27] std::allocator<char>::~allocator ([test.c:8:27]
&D.36241);
        }
    }
  finally
    {
      [test.c:8:27] D.36241 = {CLOBBER};
    }
  [test.c:9:16] D.39843 = 0;
  [test.c:9:16] return D.39843;
  [test.c:10:1] D.39843 = 0;
  [test.c:10:1] return D.39843;
}
...

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
-fdump-tree-all-lineno with gcc-10:
...
main ()
{
  struct string D.37010;
  struct allocator D.37009;
  struct string D.37052;
  struct allocator D.37051;
  int D.40670;

  [test.c:7:40] std::allocator<char>::allocator ([test.c:7:40] &D.37009);
  [test.c:7:19] try
    {
      try
        {
          [test.c:7:40] std::__cxx11::basic_string<char>::basic_string
([test.c:7:40] &D.37010
, [test.c:7:40] "str1", [/usr/include/c++/10/bits/basic_string.h:525:59]
&D.37009);
          try
            {
              try
                {
                  [test.c:7:40] std::operator<< <char, std::char_traits<char>,
std::allocator<
char> > ([test.c:7:40] &cout, [test.c:7:27] &D.37010);
                }
              finally
                {
                  [test.c:7:27] std::__cxx11::basic_string<char>::~basic_string
([test.c:7:27]
 &D.37010);
                }
            }
          finally
            {
              [test.c:7:27] D.37010 = {CLOBBER};
            }
        }
      finally
        {
          [/usr/include/c++/10/bits/basic_string.h:525:59]
std::allocator<char>::~allocator ([
/usr/include/c++/10/bits/basic_string.h:525:59] &D.37009);
        }
    }
  finally
    {
      [/usr/include/c++/10/bits/basic_string.h:525:59] D.37009 = {CLOBBER};
    }
  [test.c:8:40] std::allocator<char>::allocator ([test.c:8:40] &D.37051);
  [test.c:8:19] try
    {
      try
        {
          [test.c:8:40] std::__cxx11::basic_string<char>::basic_string
([test.c:8:40] &D.37052
, [test.c:8:40] "str2", [/usr/include/c++/10/bits/basic_string.h:525:59]
&D.37051);
          try
            {
              try
                {
                  [test.c:8:40] std::operator<< <char, std::char_traits<char>,
std::allocator<
char> > ([test.c:8:40] &cout, [test.c:8:27] &D.37052);
                }
              finally
                {
                  [test.c:8:27] std::__cxx11::basic_string<char>::~basic_string
([test.c:8:27]
 &D.37052);
                }
            }
          finally
            {
              [test.c:8:27] D.37052 = {CLOBBER};
            }
        }
      finally
        {
          [/usr/include/c++/10/bits/basic_string.h:525:59]
std::allocator<char>::~allocator ([
/usr/include/c++/10/bits/basic_string.h:525:59] &D.37051);
        }
    }
  finally
    {
      [/usr/include/c++/10/bits/basic_string.h:525:59] D.37051 = {CLOBBER};
    }
  [test.c:9:16] D.40670 = 0;
  [test.c:9:16] return D.40670;
  [test.c:10:1] D.40670 = 0;
  [test.c:10:1] return D.40670;
}
...

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |needs-bisection

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Now the question is whether/why we don't see any DW_TAG_inlined_subroutine
and why we inline anything at -O0 at all.  That said, the middle-end does not
perform any inlining but the C++ FE inserts

      finally
        {
          [/usr/include/c++/10/bits/basic_string.h:525:59]
std::allocator<char>::~allocator
([/usr/include/c++/10/bits/basic_string.h:525:59] &D.37009);
        }
    }
  finally
    {
      [/usr/include/c++/10/bits/basic_string.h:525:59] D.37009 = {CLOBBER};
    }

so somehow we leak the location of the dtor declaration to the GIMPLE stmt
created by the gimplifier.

Bisection is probably what is easiest to get us forward.

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It wouldn't solve the general problem, but I REALLY REALLY wish I could mark
the std::allocator constructors and destructors with something like
__attribute__((always_inline,artificial)) so they NEVER show up in the
debugger, but it doesn't work. They're completely uninteresting when debugging.

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection             |
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |ppalka at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Bisection points to r10-7718-gb256222910cfa4a9b2b477dff8954e51fdc36bb9

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The -fdump-tree-gimple-lineno changes between the previous revision and the
above one are:
--- pr96997.ii.005t.gimple_     2021-02-16 12:04:49.000000000 -0500
+++ pr96997.ii.005t.gimple      2021-02-16 12:05:28.000000000 -0500
@@ -6,12 +6,12 @@ main ()
   struct allocator D.36274;
   int D.39876;

-  [./example.cpp:7:27] std::allocator<char>::allocator ([./example.cpp:7:27]
&D.36232);
+  [./example.cpp:7:40] std::allocator<char>::allocator ([./example.cpp:7:40]
&D.36232);
   [./example.cpp:7:19] try
     {
       try
         {
-          [./example.cpp:7:27] std::__cxx11::basic_string<char>::basic_string
([./example.cpp:7:27] &D.36233, [./example.cpp:7:27] "str1", &D.36232);
+          [./example.cpp:7:40] std::__cxx11::basic_string<char>::basic_string
([./example.cpp:7:40] &D.36233, [./example.cpp:7:40] "str1",
[/opt/compiler-explorer/gcc-9.3.0/include/c++/9.3.0/bits/basic_string.h:525:59]
&D.36232);
           try
             {
               try
@@ -30,19 +30,19 @@ main ()
         }
       finally
         {
-          [./example.cpp:7:27] std::allocator<char>::~allocator
([./example.cpp:7:27] &D.36232);
+         
[/opt/compiler-explorer/gcc-9.3.0/include/c++/9.3.0/bits/basic_string.h:525:59]
std::allocator<char>::~allocator
([/opt/compiler-explorer/gcc-9.3.0/include/c++/9.3.0/bits/basic_string.h:525:59]
&D.36232);
         }
     }
   finally
     {
-      [./example.cpp:7:27] D.36232 = {CLOBBER};
+     
[/opt/compiler-explorer/gcc-9.3.0/include/c++/9.3.0/bits/basic_string.h:525:59]
D.36232 = {CLOBBER};
     }
twice (second time for example.cpp:8).

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
No differences in -fdump-tree-original-lineno dump, but it seems the original
dump doesn't really dump any locations for me.

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[ppalka at gcc dot gnu.org]

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

--- Comment #10 from Patrick Palka <ppalka at gcc dot gnu.org> ---
It looks like the problematic hunk from r10-7718 is

* tree.c (build_aggr_init_expr): Set the location of the AGGR_INIT_EXPR to that
of its initializer.

diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index
1d311b0fe61dc149772610e356fd81559ecdb438..8e4934c00093ec5f5627b52049394cbbca17d81f
100644 (file)
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -669,6 +669,9 @@ build_aggr_init_expr (tree type, tree init)
   else
     rval = init;

+  if (location_t loc = EXPR_LOCATION (init))
+    SET_EXPR_LOCATION (rval, loc);
+
   return rval;
 }

At the time I figured this change ought to be harmless since build_target_expr
does the same thing, and unfortunately didn't consider that it might impact
debug information generation.

Shall we just revert this hunk?  IIRC, its only purpose in this patch was to
improve the location of the "call to non-'constexpr'" diagnostic from
potential_constant_expression_1 for constexpr-nsdmi7b.C.  The only fallout of
reverting this hunk would be:

diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi7b.C
b/gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi7b.C                                
index 86d8ab4e759..ec10ddd2be8 100644                                           
--- a/gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi7b.C                            
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi7b.C                            
@@ -20,8 +20,8 @@ bar()                                                         
 {                                                                              
   A a = foo();                                                                 
   a.p->n = 5;                                                                  
-  return a; // { dg-error "non-.constexpr." }                                  
-}                                                                              
+  return a;                                                                    
+} // { dg-error "non-.constexpr." }                                            

 constexpr int                                                                  
 baz()

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'd say so, yes.

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:78a6d0e30d7950216dc0c5be5d65d0cbed13924c

commit r11-7263-g78a6d0e30d7950216dc0c5be5d65d0cbed13924c
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Feb 16 20:49:12 2021 -0500

    c++: Revert EXPR_LOCATION change to build_aggr_init_expr [PR96997]

    My change in r10-7718 to make build_aggr_init_expr set EXPR_LOCATION
    (mimicking build_target_expr) causes the debuginfo regression PR96997.
    Given that this change is mostly independent of the rest of the commit,
    and that the only fallout of reverting it is a less accurate error
    message location in a testcase introduced in the same commit, it seems
    the best way forward is to just revert this part of the commit.

    gcc/cp/ChangeLog:

            PR debug/96997
            PR c++/94034
            * tree.c (build_aggr_init_expr): Revert r10-7718 change.

    gcc/testsuite/ChangeLog:

            PR debug/96997
            PR c++/94034
            * g++.dg/cpp1y/constexpr-nsdmi7b.C:  Adjust expected location of
            "call to non-'constexpr' function" error message.

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:d7fa3fa5796a46deb308c8c38b247e290d97f1f6

commit r10-9372-gd7fa3fa5796a46deb308c8c38b247e290d97f1f6
Author: Patrick Palka <ppalka@redhat.com>
Date:   Wed Feb 17 09:55:42 2021 -0500

    c++: Revert EXPR_LOCATION change to build_aggr_init_expr [PR96997]

    My change in r10-7718 to make build_aggr_init_expr set EXPR_LOCATION
    (mimicking build_target_expr) causes the debuginfo regression PR96997.
    Given that this change is mostly independent of the rest of the commit,
    and that the only fallout of reverting it is a less accurate error
    message location in a testcase introduced in the same commit, it seems
    the best way forward is to just revert this part of the commit.

    gcc/cp/ChangeLog:

            PR debug/96997
            PR c++/94034
            * tree.c (build_aggr_init_expr): Revert r10-7718 change.

    gcc/testsuite/ChangeLog:

            PR debug/96997
            PR c++/94034
            * g++.dg/cpp1y/constexpr-nsdmi7b.C:  Adjust expected location of
            "call to non-'constexpr' function" error message.

    (cherry picked from commit 78a6d0e30d7950216dc0c5be5d65d0cbed13924c)

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #14 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed for GCC 10.3/11 by reverting the problematic part of the commit that
introduced this regression.

[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

https://gcc.gnu.org/g:063564ecbfc618cd019f86216a0224e144effae1

commit r14-6511-g063564ecbfc618cd019f86216a0224e144effae1
Author: Jason Merrill <jason@redhat.com>
Date:   Wed Dec 13 14:15:44 2023 -0500

    c++: TARGET_EXPR location in default arg [PR96997]

    My r14-6505-g52b4b7d7f5c7c0 change to copy the location in
    build_aggr_init_expr reopened PR96997; let's fix it properly this time, by
    clearing the location like we do for other trees.

            PR c++/96997

    gcc/cp/ChangeLog:

            * tree.cc (bot_manip): Check data.clear_location for TARGET_EXPR.

    gcc/testsuite/ChangeLog:

            * g++.dg/debug/cleanup2.C: New test.