[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #16 from Marc Glisse glisse at gcc dot gnu.org --- I am now getting an abi_check failure on x86_64-linux-gnu on a -O0 -g build because of this symbol. Is it expected? 1 incompatible symbols 0 _ZNKSt9type_infoeqERKS_ std::type_info::operator==(std::type_info const) const version status: incompatible GLIBCXX_3.4 type: function status: added
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com --- It is not expected of course, but I'm traveling, I cannot look into it now, I have no idea why is the symbol exported, is the macro we added for ARM misbehaving somehow for Linux? I can't imagine how since the operator is defined inline on targeta like Linux and the macro should be false.
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #18 from Paolo Carlini paolo.carlini at oracle dot com --- In other terms, I don't see how !__GXX_TYPEINFO_EQUALITY_INLINE may end up being true on x86_64-linux given the beginning of abi/pre/gnu.ver
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #19 from Paolo Carlini paolo.carlini at oracle dot com --- As far as I can see the macros at the beginning of gnu.ver do not work as they normally do in C/C++ code because __GXX_WEAK__ remains undefined. For now I'm simply going to revert the whole thing, cleanup and fix for this, I don't have enough time to get into the details of the issue.
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #20 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Sat Jun 28 15:53:30 2014 New Revision: 212104 URL: https://gcc.gnu.org/viewcvs?rev=212104root=gccview=rev Log: 2014-06-28 Paolo Carlini paolo.carl...@oracle.com Revert: 2014-06-18 Paolo Carlini paolo.carl...@oracle.com Ramana Radhakrishnan ramana.radhakrish...@arm.com PR libstdc++/61536 * config/abi/pre/gnu.ver: Adjust for out of line comparisons. 2014-06-08 Paolo Carlini paolo.carl...@oracle.com * config/abi/pre/gnu.ver: Tighten some patterns; tidy. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com --- Excellent, that version is very safe. Are you willing to commit it? Otherwise, I don't know when I can do it, maybe only Sunday. If you do that, you may want to also add, after the first comment: // By default follow the old inline rules to avoid ABI changes. something like: // (logic copied from libsupc++/typeinfo (libstdc++/61536)). otherwise the patch is ready to go in.
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #14 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Author: ramana Date: Wed Jun 18 09:44:15 2014 New Revision: 211774 URL: https://gcc.gnu.org/viewcvs?rev=211774root=gccview=rev Log: Fix libstdc++/61536 - Export out of line typeinfo comparison operators 2014-06-18 Paolo Carlini paolo.carl...@oracle.com Ramana Radhakrishnan ramana.radhakrish...@arm.com PR libstdc++/61536 * config/abi/pre/gnu.ver: Adjust for out of line comparisons. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Fixed now.
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo at gcc dot gnu.org | Component|tree-optimization |libstdc++ Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Pretty sure it's my change because typeinfo::before and typeinfo::operator== are special on some targets and I couldn't notice on x86-linux: #if !__GXX_TYPEINFO_EQUALITY_INLINE // In old abi, or when weak symbols are not supported, there can // be multiple instances of a type_info object for one // type. Uniqueness must use the _name value, not object address. bool before(const type_info __arg) const _GLIBCXX_NOEXCEPT; bool operator==(const type_info __arg) const _GLIBCXX_NOEXCEPT; however, I can get to this only next week, I'm traveling now, thus, if you like, feel free to revert for now my commit and close this bug.
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- By the way, it would be useful if you could confirm the analysis, thus run nm on your runtime .so and double check that those two symbols are there, but t, instead of T.
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #3) By the way, it would be useful if you could confirm the analysis, thus run nm on your runtime .so and double check that those two symbols are there, but t, instead of T. It certainly looks like your change broke it and I was trying to tighten the symbol regexps rather than reverting your changes completely but didn't fully succeed yet. (In reply to Paolo Carlini from comment #3) By the way, it would be useful if you could confirm the analysis, thus run nm on your runtime .so and double check that those two symbols are there, but t, instead of T. An nm comparison showed the difference of one symbol on libstdc++.so _ZNKSt9type_info6beforeERKS_ Sounds pretty much like that's the issue. If you're ok, I'm happy to currently just revert your change and we can deal with this later ?
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks. Before reverting the whole thing, please see if something like the patchlet I'm going to attach works for you. It should.
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Created attachment 32955 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32955action=edit Draft
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #7 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #6) Created attachment 32955 [details] Draft I see other failures that include operator std::type_info::operator!= , so I'll see how to extend this if it fixes the basic issues. ZNKSt9type_infone* (In reply to Paolo Carlini from comment #6) Created attachment 32955 [details] Draft
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|NEW CC|hubicka at gcc dot gnu.org | --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Uhmm, we aren't actually checking the arm-linux ABI in libstc++/config, thus if you are missing operator!=, which is inline for all targets (and not exported for all the targets for which we check the ABI), I'm afraid all the bets are off: before my changes you may have relied on *any* inline symbol, elsewhere too. I would then recommend reverting for now my changes and closing this bug. Thanks.
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- Well, up to you really: maybe operator!= is special for you because it just thinly wraps operator== which is exported for you. If adding back *only* that additional export under the macro works, all your tests are fine, it would be great. Otherwise, just revert. Sorry again for the breakage.
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #10 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #9) Well, up to you really: maybe operator!= is special for you because it just thinly wraps operator== which is exported for you. If adding back *only* that additional export under the macro works, all your tests are fine, it would be great. Otherwise, just revert. Sorry again for the breakage. I'll play with it and see what else comes out of it. thanks for the prompt response and the help here. Ramana
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #2) Pretty sure it's my change because typeinfo::before and typeinfo::operator== are special on some targets and I couldn't notice on x86-linux: #if !__GXX_TYPEINFO_EQUALITY_INLINE // In old abi, or when weak symbols are not supported, there can // be multiple instances of a type_info object for one // type. Uniqueness must use the _name value, not object address. bool before(const type_info __arg) const _GLIBCXX_NOEXCEPT; bool operator==(const type_info __arg) const _GLIBCXX_NOEXCEPT; Doh ! And the comment above that actually refers to ARM EABI systems which includes Linux. however, I can get to this only next week, I'm traveling now, thus, if you like, feel free to revert for now my commit and close this bug.
[Bug libstdc++/61536] [4.10 regression] g++ and libstdc++ regressions on arm-none-linux-gnueabihf with missing typeinfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61536 --- Comment #12 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #9) Well, up to you really: maybe operator!= is special for you because it just thinly wraps operator== which is exported for you. If adding back *only* that additional export under the macro works, all your tests are fine, it would be great. Otherwise, just revert. Sorry again for the breakage. Hmm, looks like the patchlet might be enough to do the trick. It looks like I misread the logs. Apologies, the link time failure was actually with == in In function `std::type_info::operator!=(std::type_info const) const': /work/gcc/libstdc++-v3/testsuite/18_support/type_info/hash_code.cc:51: undefined reference to `std::type_info::operator==(std::type_info const) const' Looks like it fixes my issue on ARM. regards Ramana
