PR libstdc++/51333 Define recursive_init_error constructor non-inline
commit50c2df93a6a450228b75901fad7e20cd2e7a8ee7
authorJonathan Wakely <jwakely@redhat.com>
Mon, 29 Jul 2019 14:27:19 +0000 (29 15:27 +0100)
committerJonathan Wakely <redi@gcc.gnu.org>
Mon, 29 Jul 2019 14:27:19 +0000 (29 15:27 +0100)
tree81c6660b7e989411cd2d0e87e10131e089614cfd
parent390c0dd61dc36a6eca8262b9814aa00e1bba5483
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. User code can no longer construct objects
of that type, but that's not something we need to support.

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: r273878
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]