RFC: Drop C++98 support for versioned namespace (i.e. unstable ABI mode)

RFC: Drop C++98 support for versioned namespace (i.e. unstable ABI mode)

[Jonathan Wakely]

Not something I plan to work on in the near future, but an idea worth sharing.

Before anybody panics, this does not affect the default configuration.
C++98 will still be supported. I'm only talking about the unstable ABI
build mode chosen when installing GCC, by
--enable-symvers=gnu-versioned-namespace. If you don't know what that
is, this RFC isn't something you need to worry about.

Currently there are some places where we can't define constructors,
assignment operators and destructors as defaulted, because it would
create an ABI incompatibility between C++98 (which can't use defaulted
members) and later standards.

That means that even for the unstable ABI (versioned namespace)
configuration, we are constrained by backwards compatibility (but
compat with older standards, not older GCC releases).

If we dropped C++98 support for the versioned namespace, it would open
up additional opportunities for improvements to the versioned
namespace mode.

As a specific example, std::allocator currently has a user-provided,
non-trivial default constructor. We can't define it as =default
because that doesn't work in C++98, and would make it trivial in
C++11, but still user-provided (and non-trivial) in C++98. We can't
make that change for the ABI stable mode anyway, because it would be
incompatible with older GCC releases. But we could do it for the
versioned namespace if we stopped supporting C++98.

Re: RFC: Drop C++98 support for versioned namespace (i.e. unstable ABI mode)

[Jonathan Wakely]

On Sat, 28 Aug 2021 at 11:48, Jonathan Wakely wrote:
>
> Not something I plan to work on in the near future, but an idea worth sharing.
>
> Before anybody panics, this does not affect the default configuration.
> C++98 will still be supported. I'm only talking about the unstable ABI
> build mode chosen when installing GCC, by
> --enable-symvers=gnu-versioned-namespace. If you don't know what that
> is, this RFC isn't something you need to worry about.
>
> Currently there are some places where we can't define constructors,
> assignment operators and destructors as defaulted, because it would
> create an ABI incompatibility between C++98 (which can't use defaulted
> members) and later standards.
>
> That means that even for the unstable ABI (versioned namespace)
> configuration, we are constrained by backwards compatibility (but
> compat with older standards, not older GCC releases).
>
> If we dropped C++98 support for the versioned namespace, it would open
> up additional opportunities for improvements to the versioned
> namespace mode.
>
> As a specific example, std::allocator currently has a user-provided,
> non-trivial default constructor. We can't define it as =default
> because that doesn't work in C++98, and would make it trivial in
> C++11, but still user-provided (and non-trivial) in C++98. We can't
> make that change for the ABI stable mode anyway, because it would be
> incompatible with older GCC releases. But we could do it for the
> versioned namespace if we stopped supporting C++98.

Maybe a more compelling example is that we could use
[[__no_unique_address__]] in _Rb_tree_compare to reduce the size of
std::map and std::set by alignof(void*) for the common case, see PR
102015. We can't do that because std::set and std::map need to compile
as C++98, and so can't use [[foo]] attributes, and there's no
__attribute__((__no_unique_address__)) alternative. So there's an
obvious improvement that would reduce object size from 48 bytes to 40
bytes, but we can't even do it for the ABI unstable mode because of
C++98 support.

I think anybody using the "I don't care about ABI compatibility, give
me the most optimized libstdc++ possible" mode but also expecting
C++98 support should reconsider their poor life choices.