https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88081
--- Comment #5 from Jan Hubicka ---
Hmm, then it is probably just masking the real problem. I will take a look
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88081
--- Comment #4 from Martin Liška ---
Ah, sorry, I misunderstood. Got fixed on trunk in your r266315.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88081
--- Comment #3 from Jan Hubicka ---
For me it works in trunk, so it would be nice to know when it went away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88081
--- Comment #2 from Martin Liška ---
I see the bug as old one:
4.9.4 (d3191480f376c780)(03 Aug 2016 05:07): [took: 1.910s] result: FAILED
(1)
2.ii:9:7: warning: type of ‘_ZTVN10__cxxabiv117__class_type_infoE’ does not
match original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88081
--- Comment #1 from Jan Hubicka ---
The checks that we do replace definition by non-defition in symbol merging.
=Would be possible to bisect this? GCC 8 produces:
_ZTVN10__cxxabiv117__class_type_infoE/1 (_ZTVN10__cxxabiv117__class_type_infoE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88081
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88081
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|2018-11-19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88081
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2018-11-19
Known to work|
