https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118408
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to TC from comment #0)
> It may be too late to fix this though, but it's nice to at least have an
> issue to track it.
I think it might be OK to add the abi_tag("__cxx11") now.
It could cause problems for people using explicit instantiations of std::regex,
because which symbols are emitted by the explicit instantiation would change
when the explicit instantiation is compiled with the fixed GCC. But if you
don't use explicit instantiations, the effects would be:
- some programs consistently using the new ABI would get two identical
definitions of _Scanner member functions, but that just results in slightly
larger executables, the behaviour would be correct.
- programs consistently using the old ABI would be unaffected.
- programs using std::regex with both ABIs would no longer crash
If you use explicit instantiations, you would need to use the same version of
GCC for the explicit instantiation declarations and the definition. Maybe we
could emit the old symbols names (without the abi_tag) as weak aliases for the
new symbols (with the ABI tag). That way, if the program doesn't contain any
instantiations of the old (untagged) symbol name then the tagged symbols would
be found. I'm not confident this would be a safe hack though.
