[Bug lto/48200] linking shared library with LTO results in different exported symbols

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #4 from Zeev Tarantov 2011-03-21 22:40:12 UTC --- I've constructed a trivial example, the bug did not reproduce in it. I've tried -save-temps and -Wl,--verbose but those did not reveal anything. I do not have a nicer testcase than com

[Bug lto/48200] linking shared library with LTO results in different exported symbols

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #3 from Zeev Tarantov 2011-03-21 18:26:46 UTC --- I am sorry but I don't know which parts are relevant. The source is GPL2, I just ran "make SHARED=yes CFLAGS="-fPIC -O2 -flto" lib/libpci.so.3.1.7" and then linked the SO a second time

[Bug lto/48200] linking shared library with LTO results in different exported symbols

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #2 from Zeev Tarantov 2011-03-21 18:18:26 UTC --- Created attachment 23740 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23740 sources, object files and two shared objects: one good, one bad (resulted from linking with LTO)

[Bug lto/48200] New: linking shared library with LTO results in different exported symbols

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 Summary: linking shared library with LTO results in different exported symbols Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug tree-optimization/46228] code produced for STL container is worse in 4.5.1 than in 4.4.5

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46228 --- Comment #16 from Zeev Tarantov 2010-11-11 00:42:57 UTC --- In http://gcc.gnu.org/viewcvs/trunk/gcc/doc/invoke.texi?r1=166555&r2=166554&pathrev=166555: +will be shared acroess multiple compilation units. The default value is 20. s/acroess/a

[Bug tree-optimization/46228] code produced for STL container is worse in 4.5.1 than in 4.4.5

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46228 --- Comment #9 from Zeev Tarantov 2010-10-30 20:05:57 UTC --- Using -fwhole-program I got sane code. But almost all programs that are not trivial cannot be compiled with -fwhole-program without LTO. At least on 4.5 branch LTO is not quite stable.

[Bug tree-optimization/46228] code produced for STL container is worse in 4.5.1 than in 4.4.5

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46228 --- Comment #6 from Zeev Tarantov 2010-10-29 23:44:49 UTC --- Setting -finline-limit high didn't produce different code. This function: 4007f8: 48 8b 77 10 mov0x10(%rdi),%rsi 4007fc: e9 c5 ff ff ff jmpq

[Bug tree-optimization/46228] New: code produced for STL container is worse in 4.5.1 than in 4.4.5

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46228 Summary: code produced for STL container is worse in 4.5.1 than in 4.4.5 Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Com