http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54801



             Bug #: 54801

           Summary: [c++11] static variables constructed with lambda

                    params inside member functions cause undefined errors

    Classification: Unclassified

           Product: gcc

           Version: 4.7.2

            Status: UNCONFIRMED

          Severity: normal

          Priority: P3

         Component: c++

        AssignedTo: unassig...@gcc.gnu.org

        ReportedBy: m...@godbolt.org





Created attachment 28346

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28346

Test C file exhibiting the issue



In the attached code, there is static method with a static variable whose

constructor takes a function pointer.  When a lambda is passed as the function

pointer, it seems the lambda's definition is dropped and the result is a

link-time error.



$ g++ -o test -std=c++0x test.cc

/tmp/ccpBFtG7.o: In function `Test::aFunc()::{lambda(int*)#1}::operator void

(*)(int*)() const':

test.cc:(.text._ZZN4Test5aFuncEvENKUlPiE_cvPFvS0_EEv[_ZZN4Test5aFuncEvENKUlPiE_cvPFvS0_EEv]+0x9):

undefined reference to `Test::aFunc()::{lambda(int*)#1}::_FUN(int*)'

collect2: error: ld returned 1 exit status



Making the variable non-static fixes the issue.  The same code in a free

function does not exhibit the problem.  Taking a std::function<void(int*)> as

the constructor parameter also cures the issue.  It seems to be something which

only throws away the lambda for static variables inside member functions.



More info:



g++ -v

Using built-in specs.

COLLECT_GCC=/site/apps/gcc-4.7.2-drw.patched.1/bin/g++

COLLECT_LTO_WRAPPER=/site/apps/gcc-4.7.2-drw.patched.1/libexec/gcc/x86_64-linux-gnu/4.7.2/lto-wrapper

Target: x86_64-linux-gnu

Configured with: ./configure --prefix /site/apps/gcc-4.7.2-drw.patched.1

--build=x86_64-linux-gnu --enable-clocale=gnu --enable-gold

--enable-languages=c,c++ --enable-ld=default --enable-libstdcxx-debug

--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto

--enable-plugin --enable-shared --enable-threads=posix --host=x86_64-linux-gnu

--target=x86_64-linux-gnu --with-pkgversion=DRW-internal-build

--with-plugin-ld=ld.gold --with-system-zlib

--with-gmp=/data/teamcity/work/sup-chietfbld02-002/8a981abc13d5c0c5/scratch/gcc/4.7.2/build/gmp-5.0.2

--with-mpfr=/data/teamcity/work/sup-chietfbld02-002/8a981abc13d5c0c5/scratch/gcc/4.7.2/build/mpfr-3.1.1

--with-mpc=/data/teamcity/work/sup-chietfbld02-002/8a981abc13d5c0c5/scratch/gcc/4.7.2/build/mpc-0.9

--with-libelf=/data/teamcity/work/sup-chietfbld02-002/8a981abc13d5c0c5/scratch/gcc/4.7.2/build/libelf-0.8.9

Thread model: posix

gcc version 4.7.2 (DRW-internal-build) 



This issue was discovered when attempting to register lambda functions as the

"cleanup function" for static thread-local stored information using

boost::thread_specific_ptr. However, the issue is reproducible in the attached

source file with no external includes.



This appears to be a regression in 4.7.2: gcc versions 4.7.1, 4.7.0, 4.6.3 and

4.5.3 compile the source without issue.

Reply via email to