https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110000
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Using always_inline on everything is simply wrong: GCC will refuse to inline
some functions and the user gets an error that they cannot avoid. There's no
command-line option or pragma that can be used to compile the code anyway, it's
just un-compilable.
I don't really understand the aim here. You're trying to avoid the user's
program ever containing a symbol generated from any libc++ code? So that they
can't ever have a dependency on those symbols, and the definitions can change?
Honestly, the cure seems worse than the disease.
Just because code is inlined, it doesn't mean it's immune from ABI
incompatibilities (it avoids some kinds of problems, but doesn't help with
others).
And if all libc++ functions have an abi_tag courtesy of the HIDE_FROM_ABI
macro, why does it matter whether explicit instantiations include them anyway?
Your include/__config says:
The symbol is given an ABI tag that changes with each version of libc++. This
ensures
that no ODR violation can arise from mixing two TUs compiled with different
versions
of libc++ where we would have changed the definition of a symbol. If the
symbols shared
the same name, the ODR would require that their definitions be token-by-token
equivalent,
which basically prevents us from being able to make any change to any function
in our
headers.
Again, the cure seems worse than the disease.
Your compiler and/or linker and/or dynamic loader can define what happens here,
so the ODR violation doesn't lead to nasal demons. If your definitions are not
token-by-token identical then what happens in practice is that you get two
definitions emitted in different TUs and the linker picks one. There's no
actual UB here. Applying this to every single function in the library just in
case you want to change it some day seems like major overkill.
But on the topic of this enhancement request, I don't see why functions should
be excluded from explicit instantiation if they're already abi-tagged. Do you
want to be able to change these functions in ABI-incompatible ways between
major revisions of the library?
