https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 5 Apr 2018, rguenther at suse dot de wrote: > 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... So you'd have a new internal composite type which you'd associate with a typeinfo refering to some custom __cxxabiv1::__mab_class_type_info you'd then implement the special filtering on? (mab aka multiple ambiguous bases) The internal type could the still look like it was just multiple-inherited from the two exception types? That would leave the rest of the EH personality alone and thus not affect runtime of other exception type propagation.
