[Bug c++/60372] New: incorrect destruction order for function parameter objects

[Bug c++/60372] New: incorrect destruction order for function parameter objects

[jens.maurer at gmx dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60372

            Bug ID: 60372
           Summary: incorrect destruction order for function parameter
                    objects
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jens.maurer at gmx dot net

Parameter objects are not destroyed when the called function returns, but later
(too late).  The C++ standard says in 5.2.2p4 [expr.call]:
"... The lifetime of a parameter ends when the function in which it is defined
returns. ..."

However, the following program shows that "S" is destroyed too late, after the
call to h():

#include <stdio.h>

struct S {
  S(int) { printf("S(int)\n"); }
  ~S() { printf("~S\n"); }
};

void f(S) { printf("f(S)\n"); }
void h() { printf("h()\n"); }

int main()
{
  f({0}), h();
}

> g++ -Wall -Wextra -std=c++11 -pedantic func-destroy.cc 
> ./a.out
S(int)
f(S)
h()
~S

"S" should be destroyed before the call to h().  Note that no temporary is
involved (which would correctly be destroyed at the end of the
full-expression); the copy-list-initialization initializes the parameter
object.

[Bug c++/60372] incorrect destruction order for function parameter objects

[harald at gigawatt dot nl]

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

Harald van Dijk <harald at gigawatt dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at gigawatt dot nl

--- Comment #1 from Harald van Dijk <harald at gigawatt dot nl> ---
This has recently come up on StackOverflow twice, and perhaps it's useful to
mention here too that this is core language issue 1880
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1880), according
to which GCC's current behaviour is to be made valid.

[Bug c++/60372] incorrect destruction order for function parameter objects

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen <ville.voutilainen at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |SUSPENDED
   Last reconfirmed|                            |2014-12-08
                 CC|                            |ville.voutilainen at gmail dot com
     Ever confirmed|0                           |1

--- Comment #2 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
Let's suspend the bug while the Core issue is in progress, then.

[Bug c++/60372] [DR1880] incorrect destruction order for function parameter objects

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1880

Section: 7.6.1.3  [expr.call]     Status: CD4     Submitter: Hubert Tong    
Date: 2014-02-25
[Adopted at the June, 2016 meeting as part of paper P0135R1.]

According to 7.6.1.3 [expr.call] paragraph 4,

The lifetime of a parameter ends when the function in which it is defined
returns. The initialization and destruction of each parameter occurs within the
context of the calling function.
This presumably means that the destruction of the parameter object occurs
before the end of the full-expression, unlike temporaries. This is not what
current implementations do, however. It is not clear that a change to treat
parameter objects like temporaries, to match existing practice, would be an
improvement, however, as it would result in ABI breakage for implementations
that destroy parameters in the called function.

See also issue 1935 for a related question regarding the handling of arguments
to a placement allocation function and placement deallocation function.

Notes from the June, 2014 meeting:

WG decided to make it ****unspecified**** whether parameter objects are
destroyed immediately following the call or ****at the end of the
full-expression to which the call belongs***. This approach also resolves issue
1935.