http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673
--- 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.
