http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57437
Daniel Krügler <daniel.kruegler at googlemail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |daniel.kruegler@googlemail.
| |com
--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
I can confirm the problem for my mingw-64-bit system using gcc 4.9.0 20130519
(experimental).
A variation of the program:
//-------------------------------------------------
#include <vector>
#include <iostream>
int main()
{
std::vector<int> x{1, 2, 3};
auto y = [x] () mutable {
for (auto &i: x)
i++;
return x;
};
for (const auto &i : y()) {
std::cout << i << std::endl;
}
std::cout << "(1)" << std::endl;
for (const auto &i : y()) {
std::cout << i << std::endl;
}
std::cout << "(2)" << std::endl;
}
//-------------------------------------------------
produces the output:
2
3
4
(1)
(2)
I *think* the following is going on here: The actual closure member x is
(incorrectly) considered as a local variable during RVO analysis, therefore the
first invocation invokes the move constructor on that member with the effect of
leaving an empty vector x within the closure.
The behavior looks incorrect to me: Neither 12.8 p31 b1 nor p32 can be applied
here, because x is neither a variable with automatic storage duration nor a
function parameter. It is correct the 5.1.2 p10 says
"The identifier in a simple-capture is looked up using the usual rules for
unqualified name lookup (3.4.1); each such lookup shall find a variable with
automatic storage duration declared in the reaching scope of the local lambda
expression."
but this is an automatic variable *not* within the closure's function call
operator. And 5.1.2 p15
"For each entity captured by copy, an unnamed nonstatic data member is declared
in the closure type."
is clear that x is considered a data member within the closure and RVO shall
not be applied to it.
