[Bug gdb/18165] New: incorrect evaluation of copy constructor on return statement

[Bug gdb/18165] New: incorrect evaluation of copy constructor on return statement

[matei at cs dot toronto.edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=18165

            Bug ID: 18165
           Summary: incorrect evaluation of copy constructor on return
                    statement
           Product: gdb
           Version: 7.9
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: matei at cs dot toronto.edu

Created attachment 8207
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8207&action=edit
demonstrates bug

GDB incorrectly executes a copy constructor at the end of a function which
returns its result by value. This bug is new in 7.9, I checked 7.7.1 and 7.8.2
and they both work fine.

Compile with:
g++ -std=c++11 -O0 -g3 -ggdb -Wall -Wextra -pedantic a.cpp -o a

I tried:
gcc-4.9.2 and clang-3.5.0; same result.

Run gdb as follows:
gdb -q -ex 'file a' -ex 'b done' -ex 'r' -ex 'p _a' -ex 'p _a2' -ex 'p a()' -ex
q

With gdb-7.9, I see:
$1 = {_val = 15}
$2 = {_val = 15}
$3 = {_val = 0}

With gdb-7.8.2, I see:
$1 = {_val = 15}
$2 = {_val = 15}
$3 = {_val = 15}

Strangely enough, I noticed that commenting out the "= default" statement makes
the bug disappear. But having it there is valid code, so it should work.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/18165] incorrect evaluation of copy constructor on return statement

[matei at cs dot toronto.edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=18165

--- Comment #1 from Matei David <matei at cs dot toronto.edu> ---
Note that the struct printed by gdb-7.9 is not even default-constructed (that
would have a value field of 42, not 0).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/18165] incorrect evaluation of copy constructor on return statement

[sivachandra at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18165

Siva Chandra <sivachandra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sivachandra at gmail dot com

--- Comment #2 from Siva Chandra <sivachandra at gmail dot com> ---
I think the commit that makes you see it as a regression is this:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=82c48ac732edb0155288a93ef3dd39625ff2d2e1

What was happening before 7.9 is explained in the commit message. In your
example, there is the 'const' qualifier to the copy constructor argument.
Versions before 7.9 would not have treated that as a copy constructor and would
have used a calling convention suitable for trivial return values. Now, that
calling convention is correct for your example because the copy constructor is
declared 'default'. However, the older versions of GDB concluded that the class
was trivial by accident.

As far as I know, clang or gcc do not emit any sort of debug info to convey to
a debugger that the copy constructor has been 'default'ed. The 7.9 version sees
a user declared copy constructor, but does not know about it being declared
'default', and hence wrongly concludes that the class is non-trivial. It
consequently uses the calling convention suitable for non-trivial return values
and gives the wrong result.

As an experiment, you could try removing the 'const' qualifier to the copy
constructor arg with older versions of GDB. Their behavior should be similar to
the 7.9 behavior.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/18165] incorrect evaluation of copy constructor on return statement

[matei at cs dot toronto.edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=18165

Matei David <matei at cs dot toronto.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #8207|0                           |1
        is obsolete|                            |

--- Comment #3 from Matei David <matei at cs dot toronto.edu> ---
Created attachment 8212
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8212&action=edit
demonstrates bug in various versions of gdb

This code is incorrectly run by gdb pre&post 7.9, with different errors.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/18165] incorrect evaluation of copy constructor on return statement

[matei at cs dot toronto.edu]

https://sourceware.org/bugzilla/show_bug.cgi?id=18165

--- Comment #4 from Matei David <matei at cs dot toronto.edu> ---
So, if I understand correctly:
- For our purposes, copy constructors have 4 relevant properties:
 (1) user-defined or not
 (2) trivial or not
 (3) signature
 (4) call convention (is this different from 2?)
- The debug information is enough to infer (1)&(3) but not (2)&(4).
- GDB prior to 7.9 had a different bug, related to (3). With the new example, I
can see 7.8.2 crashing while trying to call a (user-defined, non-trivial,
const-ref) copy ctor.
- GDB 7.9 fixed that, but in the process caught another bug related to (2).
- In general, GDB needs (4) to execute a constructor call.
- The core issue is that the compiler gcc/clang does not provide (2)&(4) as
part of the debug information.

If that's right, who should be informed about this issue? Is it the gcc
developers? Or is the debug information part of some standard and gcc simply
implement that?

In the meantime, what would you suggest as workaround? I'd suspect that having
a non-const-ref copy constructor is usually the hardest change to implement. If
one really needs a const-ref copy ctor:
- if it is user-defined and explicit, 7.8.2 crashes while executing it
- if it is user-defined and defaulted, 7.9 executes it incorrectly
The only option seems to be to have it non-user-defined, i.e., implicit.
Reading this: http://en.cppreference.com/w/cpp/language/copy_constructor
To get an implicit copy ctor, one has to not have a user-defined move ctor or a
move asop. Furthermore, implicit copy ctor are deprecated in the presence of a
user-defined dtor or copy asop.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/18165] incorrect evaluation of copy constructor on return statement

[ssbssa at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18165

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.1
         Resolution|---                         |FIXED
                 CC|                            |ssbssa at sourceware dot org
             Status|NEW                         |RESOLVED

--- Comment #5 from Hannes Domani <ssbssa at sourceware dot org> ---
Fixed in current master, with this commit:
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=62bf63d74d54482d42e9d78890ebc0dd4675e23b

-- 
You are receiving this mail because:
You are on the CC list for the bug.