The following program compiled with gcc 4.8.0 20121209 (experimental) and compiled with flags -Wall -std=c++11 -pedantic //---------------- template <class T> struct X { static void (*code) (); }; template <class T> void (*X<T>::code) () = []{}; // Line 7 struct Y { void (*code) () = []{} ; // Line 10 void operator()() { code(); } }; int main () { X<int>::code(); Y()(); } //---------------- gives two linkage errors: "|In function `Y::code::{lambda()#1}::operator void (*)()() const':| 10|undefined reference to `Y::code::{lambda()#1}::_FUN()'| |In function `X<int>::code::{lambda()#1}::operator void (*)()() const':| 7|undefined reference to `X<int>::code::{lambda()#1}::_FUN()'| " for the functions that should be defined for the corresponding uncaptured lambda expressions. It should be noted, that struct Z { static void (*code) (); }; void (*Z::code) () = []{}; int main () { Z::code(); } doesn't cause a similar linkage error, though.
Related to PR 55015.
As-is, at variance with PR 55015, this can't be a regression in mainline and 4.7.x, because 4.6.x didn't have non-static data member initializers. If Daniel can figure out something similar not-using NSDMI which worked in 4.6.x, it's much more likely to be fixed for 4.8.0.
(In reply to comment #2) Note that my first example is not related to NSDMIs, it occurs in a static data member initializer. The actual reason for understanding the possible reasons for such an error is because we stumbled across it in an - unfortunately very complex - production code. Backed with the reference to bug 55015 I try to check that with our actual code on Monday.
Oops, 4.6.x says that NSDMIs are needed for line 10 and rejects it, that misled me. Then, what can I say, probably the issue isn't a regression and it's only superficially similar to PR 55015 (which is already fixed)
To repeat: in order to, so to speak, raise the priority of this issue, we need a testcase which was accepted by 4.6.x (or 4.7.x): the testcase we have got isn't Ok for that, because 4.6.x rejects it immediately, that is at compile-time, line #10.
(In reply to comment #5) So will the following do that: //---------------- template <class T> struct X { static void (*code) (); }; template <class T> void (*X<T>::code) () = []{}; // Line 7 int main () { X<int>::code(); } //---------------- giving me "In function `X<int>::code::{lambda()#1}::operator void (*)()() const':| |7|undefined reference to `X<int>::code::{lambda()#1}::_FUN()'| " ?
(In reply to comment #3) I have now much confidence that our production code (based on GCC 4.7.2) fails due to bug 55015. Fortunately there is a known workaround for that one. To make resolving this issue here easier, I will split-off the GCC 4.6.x-only part as a separate issue.
Thanks Daniel for the new testcase in Comment #6. I'm afraid however we still don't have a regression, because the testcase compiles but doesn't link in 4.6.x too.
*** Bug 55720 has been marked as a duplicate of this bug. ***
Author: jason Date: Wed Feb 13 18:17:39 2013 New Revision: 196025 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196025 Log: PR c++/55710 * semantics.c (maybe_add_lambda_conv_op): Mark static thunk TREE_USED. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c
Author: jason Date: Fri Feb 15 18:31:52 2013 New Revision: 196086 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196086 Log: PR c++/55710 * semantics.c (maybe_add_lambda_conv_op): Mark static thunk TREE_USED. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv7.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/semantics.c
Thanks Jason! Fixed mainline and 4.7.3.