http://sourceware.org/bugzilla/show_bug.cgi?id=14272
--- Comment #5 from Christopher Hite <Christopher.Hite at partner dot commerzbank.com> 2012-06-22 14:07:44 UTC --- I've found what part of the code causes this, just including this header only file causes the issue (boost_1_49_0). #include <boost/exception/detail/exception_ptr.hpp> The technique that seems to be at the heart of the matter is using templates to create global variables in a header only library. clone_impl<>'s deconstructor is referenced by this expression. shared_ptr<exception_detail::clone_base const>( new exception_detail::clone_impl<Exception>(c)) It is somehow lost by the LTO process. I have tried to reproduce the bug by chopping out chunks of the header, but it is very unstable. I get cases where A is ok, B is ok, but both together emit the error even though they're independent cases in switch. I tried to replicate the bug with some simple code. Insanely adding in that code even though it is a different namespace and never called makes the bug disappear! So the best I can give you to reproduce is this: #include <boost/exception/detail/exception_ptr.hpp> int main(){return 0;} Causes error g++ -m32 -O3 -g -I"/fs/tools/L4/boost_1_49_0" -flto -fuse-linker-plugin -rdynamic gcc_lto_bug_lthunk.cpp Doesn't cause error. g++ -m32 -O3 -g -I"/fs/tools/L4/boost_1_49_0" -flto -fuse-linker-plugin gcc_lto_bug_lthunk.cpp Interestingly -rdynamic seems to be involved too. I use it to help with backtrace(), though I'm not sure I need it. Is this good enough for someone to reproduce now? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils