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
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-binutils