On Fri, 9 Jun 2023 at 10:03, Richard Biener <richard.guent...@gmail.com> wrote:
> On Thu, Jun 8, 2023 at 3:14 PM Jonathan Wakely via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: > > > > On Fri, 26 May 2023 at 10:58, Jonathan Wakely wrote: > > > > > > > > > > > On Wed, 24 May 2023 at 19:56, Jason Merrill via Libstdc++ < > > > libstd...@gcc.gnu.org> wrote: > > > > > >> Middle-end folks: any thoughts about how best to make the change > > >> described in > > >> the last paragraph below? > > >> > > >> Library folks: any thoughts on the changes to __cxa_call_terminate? > > >> > > > > > > I see no harm in exporting it (with the adjusted signature). The "looks > > > standard but isn't" name is a little unfortunate, but not a big deal. > > > > > > > Jason, do you have any objection to exporting __cxa_call_terminate for > GCC > > 13.2 as well, even though the FE won't use it? > > > > Currently both gcc-13 and trunk are at the same library version, > > libstdc++.so.6.0.32 > > > > But with this addition to trunk we need to bump that .32 to .33, meaning > > that gcc-13 and trunk diverge. If we want to backport any new symbols > from > > trunk to gcc-13 that gets trickier once they've diverged. > > But if you backport any new used symbol you have to bump the version > anyway. So why not bump now (on trunk)? > We've already bumped it once since 13.1, and until 13.2 is released we aren't committed to freezing the new version. I think we can add this __cxa_call_terminate symbol to the version currently used by 13.1.1 without problems. And if we want to backport another new symbol before 13.2, we can do that too (unless it would be too difficult for distros already shipping 13.1.1, but I don't think that applies in this case).
