This is the mail archive of the
mailing list for the libstdc++ project.
Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Jason Merrill <jason at redhat dot com>, gcc at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Fri, 13 Jan 2012 09:34:40 -0800
- Subject: Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]
- References: <4F0769D4.email@example.com> <4F0C4BB7.firstname.lastname@example.org> <20120112111646.42c5fc0c@shotwell> <Pine.LNX.email@example.com>
> I think that's a bad idea; having too many ways to configure things
> will cause undue confusion.
Seems like the train has already left the station WRT gcc configure
options. If you feel this is a real issue, then it could be solved the
same way that thread support was solved, by adding a "Thread Model"
category to gcc -v.
Having one way to do this is better than every vendor doing their own
mods. FYI, libstdc++ practice has already diverged: google is using
__versa_string, for instance.
A canonical method for doing the ABI switch seems entirely appropriate.
IMHO the earlier we can start experiments the better the eventual
switch will be.
That said, sentiment seems to be that this is something that should wait
for 4.8. I'll wait for the Stage 1 window to open and try to post an
> But if someone really wants that and
> really knows what they are doing, it may be possible for them to do
> something with --with-specs.
Doubtful. I don't see any way of doing this without configure-time
hacking in addition to compile-link time hacking via specs.
Note the last libstdc++ transition mandated separate sources in the
> (C deliberately has not been moved to gnu99 as default because we
> don't have a -Wc90-c99-compat or similar option to warn about things
> different between C90 and C99, so anyone using -pedantic to warn
> about things outside C90 wouldn't be able just to use -pedantic
> -Wc90-c99-compat with a gnu99 default, they'd have to set the
> standard back to gnu89 as well. Given such an option - which should
> generate warnings, not pedwarns, for the cases that are presently
> pedwarn-if-pedantic-if-C90 (and a few other cases), changing the
> default to gnu99 would make sense - in Stage 1.)
Nice points. I've filed an enhancement request to track this issue.