https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 5 Apr 2018, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222 > > --- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> --- > Seems simpler to just define: > > struct __dual_ios_failure { > __dual_ios_failure(std::string s, error_code e) : new_(s, e), old_(s) { } > ios::failure[abi:cxx11] new_; > ios::failure old_; > }; > > and make __throw_ios_failure() throw one of that type, and make the EH runtime > do the necessary adjustments to make this work: > > __dual_ios_failure * p1; > > try { > try { > try { > throw __dual_ios_failure("", {}); > } catch (__dual_ios_failure& e1) { > p1 = &e1; > throw; > } > } catch (ios::failure[abi:cxx11]& e2) { > assert( &e2 == &p1->new_ ); > throw; > } > } catch (ios::failure& e3) { > assert( &e3 == &p1->old_ ); > } > > i.e. if the catch handler is one of the ios::failure types and the actual > thrown exception is __dual_ios_failure then catch the member instead of the > object itself. The "throw;" would re-throw the original object of type > __dual_abi_failure, so the next handler would be able to perform the same > checks and adjustments. > > This would only require magic in the EH catch routines, not a new way to > declare base classes. True. Given the issue of declaring the __dual_ios_failure type - as you said, you can't write it that way - it's probably going to be a builtin type? In which case "massaging" the typeinfo data to make the code in the EH catchers less special might be easier. Not sure, I'm not at all familiar with these areas of GCC internals. Whatever it takes, it would be nice to fix this in a way not breaking pre-GCC7 nor GCC7-and-later code...
