]> git.ipfire.org Git - thirdparty/gcc.git/commit
PR libstdc++/51333 Define recursive_init_error constructor non-inline
authorJonathan Wakely <jwakely@redhat.com>
Mon, 2 Sep 2019 11:10:00 +0000 (12:10 +0100)
committerJonathan Wakely <redi@gcc.gnu.org>
Mon, 2 Sep 2019 11:10:00 +0000 (12:10 +0100)
commite78c5916125e96ec3ad27468b54fe7fa7cb65c50
tree20d0c7eec5aca918d811062e1bdd6f3ae9b0b7a4
parent9fb59c78376dd74a9aa41541b2599caef873b4e2
PR libstdc++/51333 Define recursive_init_error constructor non-inline

The recursive_init_error class is defined in a header, with an inline
constructor, but the definition of the vtable and destructor are not
exported from the shared library. With -fkeep-inline-functions the
constructor gets emitted in user code, and requires the (non-exported)
vtable. This fails to link.

As far as I can tell, the recursive_init_error class definition was
moved into <cxxabi.h> so it could be documented with Doxygen, not for
any technical reason. But now it's there (and documented), somebody
could be relying on it, by catching that type and possibly performing
derived-to-base conversions to the std::exception base class. So the
conservative fix is to leave the class definition in the header but make
the constructor non-inline. This still allows the type to be caught and
still defines its base class.

Backport from mainline
2019-07-29  Jonathan Wakely  <jwakely@redhat.com>

PR libstdc++/51333
* libsupc++/cxxabi.h (__gnu_cxx::recursive_init_error): Do not define
constructor inline.
* libsupc++/guard_error.cc (__gnu_cxx::recursive_init_error): Define
constructor.
* testsuite/18_support/51333.cc: New test.

From-SVN: r275309
libstdc++-v3/ChangeLog
libstdc++-v3/libsupc++/cxxabi.h
libstdc++-v3/libsupc++/guard_error.cc
libstdc++-v3/testsuite/18_support/51333.cc [new file with mode: 0644]