rev: 211358 https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg00821.html rev: 211354 https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg00803.html Test suite differences in g++ , libstdc++ with link time failures that look like FAIL: g++.dg/opt/typeinfo1.C -std=gnu++1y (test for excess errors) Excess errors: typeinfo1.C:(.text+0x18): undefined reference to `std::type_info::operator==(std::type_info const&) const' typeinfo1.C:(.text.startup+0x20): undefined reference to `std::type_info::operator==(std::type_info const&) const' typeinfo1.C:(.text.startup+0x44): undefined reference to `std::type_info::operator==(std::type_info const&) const'
Linkage for this passes if --static is given on the command line which indicates this must be related to r211355-211357.
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.
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.
(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 ?
Thanks. Before reverting the whole thing, please see if something like the patchlet I'm going to attach works for you. It should.
Created attachment 32955 [details] Draft
(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
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.
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.
(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
(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.
(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
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.
Author: ramana Date: Wed Jun 18 09:44:15 2014 New Revision: 211774 URL: https://gcc.gnu.org/viewcvs?rev=211774&root=gcc&view=rev Log: Fix libstdc++/61536 - Export out of line typeinfo comparison operators 2014-06-18 Paolo Carlini <paolo.carlini@oracle.com> Ramana Radhakrishnan <ramana.radhakrishnan@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
Fixed now.
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
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.
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
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.
Author: paolo Date: Sat Jun 28 15:53:30 2014 New Revision: 212104 URL: https://gcc.gnu.org/viewcvs?rev=212104&root=gcc&view=rev Log: 2014-06-28 Paolo Carlini <paolo.carlini@oracle.com> Revert: 2014-06-18 Paolo Carlini <paolo.carlini@oracle.com> Ramana Radhakrishnan <ramana.radhakrishnan@arm.com> PR libstdc++/61536 * config/abi/pre/gnu.ver: Adjust for out of line comparisons. 2014-06-08 Paolo Carlini <paolo.carlini@oracle.com> * config/abi/pre/gnu.ver: Tighten some patterns; tidy. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver