| Summary: | Different definitions of _Rb_tree::{erase,_M_destroy_node} between C++98 and C++0x | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Jeffrey Yasskin <jyasskin> |
| Component: | libstdc++ | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gcc-bugs, redi, webrown.cpp |
| Priority: | P3 | ||
| Version: | 4.6.0 | ||
| Target Milestone: | 4.8.0 | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | ||
Definitely they are not, **no** binary compatibility between C++98 and C++0x. And I can tell you there are **many** more incompatibilities beyond this one which you noticed. Well, this specific snippet will work at some point, because we want to use namespace association for the C++0x containers. Of course no binary compatibility in general, C++0x and C++98 code will not be allowed in general to interoperate, for *many* reasons (just as an example std::list will be changed to have a constant time size in C++0x) The different definitions of erase have been mangled differently since GCC 4.8, by using the abi-tag. Gold still warns about _M_destroy_node, but that's harmless. Author: redi Date: Mon Aug 13 18:54:43 2018 New Revision: 263516 URL: https://gcc.gnu.org/viewcvs?rev=263516&root=gcc&view=rev Log: PR libstdc++/45093 avoid warnings for _M_destroy_node PR libstdc++/45093 * include/bits/stl_tree.h (_Rb_tree::_M_destroy_node(_Link_type)): Combine definitions to avoid --detect-odr-violations warning. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_tree.h |
Using gold for its --detect-odr-violations: $ cat test.cc #include <map> extern void foo(); int main() { foo(); std::map<int, int> m1; m1.insert(std::make_pair(1, 2)); m1.erase(m1.begin()); } $ cat test2.cc #include <map> void foo() { std::map<int, int> m1; m1.insert(std::make_pair(1, 2)); m1.erase(m1.begin()); } $ ~/opensource/gcc/trunk/install/bin/g++-4.6svn -g -c -std=c++98 test.cc $ ~/opensource/gcc/trunk/install/bin/g++-4.6svn -g -c -std=c++0x test2.cc $ ~/opensource/gcc/trunk/install/bin/g++-4.6svn -g -std=c++0x test2.o test.o -o test -Wl,--detect-odr-violations .../gcc/trunk/install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/ld: error: while linking test: symbol 'std::_Rb_tree<int, std::pair<int const, int>, std::_Select1st<std::pair<int const, int> >, std::less<int>, std::allocator<std::pair<int const, int> > >::_M_destroy_node(std::_Rb_tree_node<std::pair<int const, int> >*)' defined in multiple places (possible ODR violation): .../gcc/trunk/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_tree.h:385 from test.o .../gcc/trunk/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_tree.h:410 from test2.o .../gcc/trunk/install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/ld: error: while linking test: symbol 'std::_Rb_tree<int, std::pair<int const, int>, std::_Select1st<std::pair<int const, int> >, std::less<int>, std::allocator<std::pair<int const, int> > >::erase(std::_Rb_tree_iterator<std::pair<int const, int> >)' defined in multiple places (possible ODR violation): .../gcc/trunk/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_tree.h:1362 from test2.o .../gcc/trunk/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_tree.h:1398 from test.o collect2: ld returned 1 exit status $ _M_destroy_node() appears to only differ in whether some fields with trivial destructors get destroyed, but erase() is defined with different return types between the two versions. So, two questions: Are -std=c++98 and -std=c++0x supposed to be binary-compatible? Would you accept a patch to unify the two definitions?