[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems

redi at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Jun 15 15:38:00 GMT 2012


--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-06-15 15:37:34 UTC ---
(In reply to comment #3)
> (In reply to comment #1)
> > There's no point differentiating the gnu variants, they don't have any ABI
> > impact.
> They don't have any ABI impact that we know of at the present time in this
> present generation of GCCs. As a debug aid that's likely to be there from now
> on and forever, who's to say about the future.

The GCC maintainers are to say.

> Better to cover all bases now
> I'd say, just in case.

There's no point adding (and maintaining) yet another feature to handle
hypothetical differences which *by*design* should not happen.

Far more relevant than c++11 vs gnu++11 is -fabi-version=n, which your scheme
doesn't cover.

> > This could (and probably should) be done in the library because the output of
> > G++ is ABI compatible, it's only standard library components that are not.
> There are no shortage of third party libraries which enable special new stuff
> when compiled with GNU additions turned on.

Not GCC's problem, and no different to libraries which enable new things when
-fno-rtti or -fno-exceptions is used

> Also, the ISO C++ standard is quite clear that ABI between C++03 and C++11
> compiled code is not guaranteed in the case where C++11 libraries/shared
> objects are linked into a C++03 compiled program. Indeed, really an error ought
> to be thrown if this happens for safety's sake, a warning as a minimum.

[citation needed]  ;)

The standard says nothing about "libraries/shared objects"

It's entirely possible to use G++ to build 100% ABI compatible applications
using a mixture of -std=c++98 and -std=c++11 objects, if you don't use the
parts of the standard library that are incompatible.  A mandatory or warning
would cause problems for anyone doing that.

More information about the Gcc-bugs mailing list