https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61636
--- Comment #26 from Adam Butcher <abutcher at gcc dot gnu.org> ---
(In reply to Nathan Sidwell from comment #25)
> Fixed. We capture this if we find at least one non-static member function.
> This agrees with Clang's implementation, after discussion with Richard Smith.
>
Nice. Your [much cleaner] patch sorts out the starred case above too. With
GCC master (7.0.0 20170119) with your patch the results are:
auto l0 = [&](auto z) { f (z); }; // C:8 G:1 G':8 G'':8
auto l1 = [&](auto) { f (2.4); }; // C:8 G:1 G':8 G'':1 * fixed :)
auto l2 = [&](auto) { O::x (2.4); }; // C:8 G:1 G':1 G'':1
auto l3 = [&](auto) { N::y (2.4); }; // C:1 G:1 G':1 G'':1
auto l4 = [&](auto) { }; // C:1 G:1 G':1 G'':1
auto l5 = [&](int z) { f (z); }; // C:8 G:8 G':8 G'':8
auto l6 = [&](int) { f (2.4); }; // C:8 G:1 G':1 G'':1
auto l7 = [&](int) { O::x (2.4); }; // C:8 G:1 G':1 G'':1
auto l8 = [&](int) { N::y (2.4); }; // C:1 G:1 G':1 G'':1
auto l9 = [&](int) { }; // C:1 G:1 G':1 G'':1
with closure sizes indicated for C = Clang RELEASE_391/final, G = GCC prior to
fix, G' = GCC with my old patch, G'' = latest GCC with your patch.
It's interesting you reference Clang's implementation though as, judging by the
results of the above test, Clang is capturing 'this' far more often than it
should be; even in cases where a enclosed class member is not referenced at all
(in extreme cases the referenced fn is a static member function of a completely
different class). And even stranger, Clang appears to behave the same for
monomorphic lambdas too. Not sure what's going on there.
