[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)

2015-03-29 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 --- Comment #10 from Jan Hubicka --- I filled in binutils PR for extension of plugin API https://sourceware.org/bugzilla/show_bug.cgi?id=18178

[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)

2015-03-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 CC|

[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)

2015-03-22 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 --- Comment #8 from Jan Hubicka --- Created attachment 35100 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35100&action=edit partial patch Hi, this is a patch that adds necessary checks into resolution code. Basically if static linking is

[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)

2015-03-20 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 --- Comment #7 from Jan Hubicka --- I suppose proper fix is to make flag_incremental_linking and turn -r from Driver only. Then we could revisit individual optimizations that do rely on the fact that static linking will not be re-done.

[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)

2015-03-18 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 --- Comment #6 from Jan Hubicka --- (just to explain bit more - the main difference between static and dynamic linking here is that dynamic linking never remove any definition and thus you can dissolve comdat groups)

[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)

2015-03-18 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 --- Comment #5 from Jan Hubicka --- Well, the problem is that -r is the only case where we get LDPR_PREVAILING_DEF or IRONLY and the resulting symbol may be removed from the unit later. We would need a new LDPR_PREVAILING_DEF_FOR_NOW or something

[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)

2015-03-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #4 from Richard Biener

[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)

2015-02-01 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 --- Comment #3 from Jan Hubicka --- Hmm, interesting, I did not even think we support this ;) I am not sure how much it makes sense to do incremntal linking like this with LTO because this limits LTO to incremental link only (it would perhaps mak

[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)

2015-02-01 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug lto/64860] [5 Regression] multiple definition of typeinfo in 5.0 (4.9.2 works)

2015-01-29 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64860 Richard Biener changed: What|Removed |Added Keywords||lto, wrong-code Known to work|