[Bug c++/61402] New: [C++1y] Init-capture with side effect not working for some types

[Bug c++/61402] New: [C++1y] Init-capture with side effect not working for some types

[thibaut.lutz at googlemail dot com]

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

            Bug ID: 61402
           Summary: [C++1y] Init-capture with side effect not working for
                    some types
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: thibaut.lutz at googlemail dot com

Lambda functions with an init-capture for which the initializer has a side
effect is not always taken into account.

The example below defines a lambda with an init-capture, which increments a
variable in the initalizer, and invoke the lambda immediately with the same
variable as a parameter. The body of the lambda prints the value of the
captured value and its parameters, which should be identical.

Expected result: The captured value and the parameter should have the same
value, since the instantiation of the lambda should be evaluated before its
invocation.

Actual results: for some types (at least bool and char), the increment inside
the init-capture is partially evaluated: the captured value is correct but the
side effect is gone. Other types are working as expected.

Tested with: gcc 4.9.0 and 4.8.1

Code:
--8<----8<----8<----8<----8<----8<--
#include <iostream>

template<typename T>
void foo(T t) {
  using namespace std;
  // print the original argument
  cout << endl << "par t = " << t << endl;

  { // lambda function declaration and invocation 
    // capture argument by-copy after pre-increment 
    [ i = ++t ]
    // take one parameter
    (T v)
    {
      // print captured value and argument
      cout << "cap i = ++t = " << i << endl
           << "arg v = " << v << endl;
    }
    // invocation with the new value of the argument
    (t);
  }
}

int main(){
  foo(3.14f); // works OK
  foo(0);     // works OK
  foo('a');   // fails!
  foo(false); // fails!
}
--8<----8<----8<----8<----8<----8<--

Program output:
par t = 3.14
cap i = ++t = 4.14
arg v = 4.14

par t = 0
cap i = ++t = 1
arg v = 1

par t = a
cap i = ++t = b
arg v = a

par t = 0
cap i = ++t = 1
arg v = 0

For the last two types (char and bool), we observe v == t instead of v == i.

[Bug c++/61402] [C++1y] Init-capture with side effect not working for some types

[thibaut.lutz at googlemail dot com]

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

--- Comment #1 from Thibaut LUTZ <thibaut.lutz at googlemail dot com> ---
I forgot to add that separating declaration and invocation seems to solve the
problem: 

--8<----8<----8<----8<----8<----8<--
#include <iostream>

template<typename T>
void foo(T t) {
  using namespace std;
  cout << endl << "par t = " << t << endl;
  auto test = [ i = ++t ](T v) {
      cout << "cap i = ++t = " << i << endl
           << "arg v = " << v << endl;
  };
  test(t);
}

int main(){
  foo(3.14f); // works OK
  foo(0);     // works OK
  foo('a');   // works OK
  foo(false); // works OK
}
--8<----8<----8<----8<----8<----8<--

[Bug c++/61402] [C++1y] Init-capture with side effect not working for some types

[richard-gccbugzilla at metafoo dot co.uk]

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

Richard Smith <richard-gccbugzilla at metafoo dot co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |richard-gccbugzilla@metafoo
                   |                            |.co.uk

--- Comment #2 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk> ---
Your testcase has undefined behavior:

  [ i = ++t ]
  /*...*/
  (t);

The increment and load of 't' are unsequenced.

[Bug c++/61402] [5 Regression][C++1y] Init-capture with side effect not working for some types

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-11-25
            Summary|[C++1y] Init-capture with   |[5 Regression][C++1y]
                   |side effect not working for |Init-capture with side
                   |some types                  |effect not working for some
                   |                            |types
     Ever confirmed|0                           |1

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Thanks. Mainline currently crashes on both testcases. And of course it would be
nice to have a warning for this, like clang.

[Bug c++/61402] [5 Regression][C++1y] Init-capture with side effect not working for some types

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Fri Dec 12 16:43:16 2014
New Revision: 218680

URL: https://gcc.gnu.org/viewcvs?rev=218680&root=gcc&view=rev
Log:
    PR c++/61402
    * lambda.c (add_capture): Don't pass a dependent type to
    variably_modified_type_p.

Added:
    trunk/gcc/testsuite/g++.dg/cpp1y/lambda-init11.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/lambda.c

[Bug c++/61402] -Wsequence-point doesn't notice unsequenced lambda init and function argument

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org
            Summary|[5 Regression][C++1y]       |-Wsequence-point doesn't
                   |Init-capture with side      |notice unsequenced lambda
                   |effect not working for some |init and function argument
                   |types                       |

--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
Updating summary.