[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #7)
> > It's not required to fix the simple case of a legacy binary using a new
> > libstdc++.so but it breaks other cases.
> 
> None that are not broken right now?

Well with the case of a legacy shared lib and a new main(), currently the
shared lib won't catch the exception but main will. It's arguably more broken
if main doesn't catch it and terminates with an unhandled exception.

> Anyway, what would happen if __throw_ios_failure would throw a
> 
> struct ios_failure : ios_base::failure, ios_base::failure[c++11]
> 
> class (with both sub-classes properly initialized)?

Bug 66145 comment 23.

> 
> If I do
> 
>   catch (ios_base::failure[c++11] &e)

You can't use the ABI tag in the name like this.

>    {
>      throw e;
>    }
> 
> does it re-throw the original exception type?

No, "throw e;" throws a new exception object. If you just do "throw;" it
re-throws the original exception.

>  Can I catch
> that ios_failure class at all this way?

I'm not sure what "this way" refers to.