Summary: | [C++11] Linkage errors with lambdas | ||
---|---|---|---|
Product: | gcc | Reporter: | Daniel Krügler <daniel.kruegler> |
Component: | c++ | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | c++-lambda, link-failure |
Priority: | P3 | ||
Version: | 4.8.0 | ||
Target Milestone: | 4.7.3 | ||
Host: | Target: | ||
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | 2012-12-15 00:00:00 | |
Bug Depends on: | |||
Bug Blocks: | 54367 |
Description
Daniel Krügler
2012-12-15 17:10:42 UTC
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. |