On Thu, Oct 31, 2013 at 01:32:19PM +, Iyer, Balaji V wrote:
> > It is not just about not including 3, but also the []s in configure.ac were
> > eaten by
> > m4. In any case, shouldn't you fix also config/generic?
> >
>
> I am in the process of fixing config/generic. I also replaced [456] wi
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Thursday, October 31, 2013 3:46 AM
> To: Iyer, Balaji V
> Cc: Gerald Pfeifer; Jeff Law; gcc@gcc.gnu.org
> Subject: Re: [PATCH] RE: libcilkrts/runtime/config/generic/cilk-abi-vla.c
> f
On Thu, Oct 31, 2013 at 03:21:14AM +, Iyer, Balaji V wrote:
> It is because of this line:
>
> i[456]86-*-*)
> config_dir="x86"
> ;;
>
> It should include a 3 too. My bad sorry. I have fixed it. Attached, please
> find a patch. It is committed as obvious.
It is not just about not i
> -Original Message-
> From: Gerald Pfeifer [mailto:ger...@pfeifer.com]
> Sent: Wednesday, October 30, 2013 9:39 PM
> To: Iyer, Balaji V
> Cc: Jeff Law; gcc@gcc.gnu.org
> Subject: libcilkrts/runtime/config/generic/cilk-abi-vla.c failure (was:
> [PATCH,
> committed
aji!
Now my FreeBSD tester no longer shows this failure, but this:
/scratch2/tmp/gerald/gcc-HEAD/libcilkrts/runtime/config/generic/cilk-abi-vla.c:
In function \xe2\x80\x98__cilkrts_stack_free\xe2\x80\x99:
/scratch2/tmp/gerald/gcc-HEAD/libcilkrts/runtime/config/generic/cilk-abi-vla.c:1
06:28: err
unction pointers get bounds too.
>> If so, it might be good to state that explicitly.
>> I suppose they would be all-of-memory bounds though,
>> due to the lack of hardware support for checking them.
> My wording may seem ambiguous for function pointers but in ABI
> document
state that explicitly.
> I suppose they would be all-of-memory bounds though,
> due to the lack of hardware support for checking them.
My wording may seem ambiguous for function pointers but in ABI
document register classes description enumerates all types assigned to
each class. I think
Ilya Enkovich writes:
> - When we pass (return) pointer on register, we use the next
> available bound register to pass (return) bounds
>From the wording, it seems function pointers get bounds too.
If so, it might be good to state that explicitly.
I suppose they would be all-of-memory bounds th
Hi,
Here is a patch to extend x86-64 psABI to support MPX [1].
A short description of changes:
- There are 4 bound registers (bnd0-bnd3) added; all of them are caller-save
- When we pass (return) pointer on register, we use the next
available bound register to pass (return) bounds
- If there i
On 01/22/2013 07:42 PM, Cary Coutant wrote:
I believe we required an explicit attribute on the forward declaration
in such a case.
The question is, what do we want to do for a user type that, say, has a
std::string field. Rejecting the program would be non-conforming, but
otherwise we're lik
>> Normally, the version identifier is applied to a type. It then
>> propagates to any declaration using that type, whether it's another
>> type or function or variable. For struct/union/class types, if any
>> member or base class has an attached version identifier (excluding
>> static data members
On 01/10/2013 08:58 PM, Cary Coutant wrote:
Normally, the version identifier is applied to a type. It then
propagates to any declaration using that type, whether it's another
type or function or variable. For struct/union/class types, if any
member or base class has an attached version identifier
> We had a useful discussion about C++11 ABI issues at the GNU Tools
> Cauldron (http://gcc.gnu.org/wiki/cauldron2012). The approach will be
> shaped over time, but the general idea is as follows.
>
> We will modify g++ to support a type attribute indicating the version
> of the
On 14 December 2012 21:58, Jonathan Wakely wrote:
> Gerald did ask me to update the libstdc++ docs but I didn't (and I'm
> still not sure what the consensus was regarding which link to use.)
Actually the right fix for the libstdc++ docs seems pretty obvious,
I'll do it tomorrow.
On 14 December 2012 21:51, Joe Buck wrote:
> Richard Henderson writes:
>> On
>> http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
>> we have a stale link to
>> http://www.codesourcery.com/public/cxx-abi/abi.html
>
>>What's the new canonical l
Richard Henderson writes:
> On
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
> we have a stale link to
> http://www.codesourcery.com/public/cxx-abi/abi.html
>What's the new canonical location for this document?
Looks like CodeSourcery is being assimilated into
On
http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
we have a stale link to
http://www.codesourcery.com/public/cxx-abi/abi.html
What's the new canonical location for this document?
r~
kage name
of a class like
struct Wrap { std::string s; };
so we would need some way to cause the name decoration to propagate to
other containing/derived classes.
I raised this issue on the ABI list, and someone pointed out to me that
incomplete classes make quiet propagation impossible; a
On Mon, Oct 22, 2012 at 10:15 AM, Gregory Nietsky wrote:
>
> In using 4.7.2 and am working on extending our distro to have
> x86/x86_64/x32/arm
>
> Ive yanked the H.Lu patch to add --with-abi support from trunk and am
> extending it to
> have a default 32bit ABI we have ni
In using 4.7.2 and am working on extending our distro to have
x86/x86_64/x32/arm
Ive yanked the H.Lu patch to add --with-abi support from trunk and am
extending it to
have a default 32bit ABI we have nicknamed this the LOTR compiler [One
compiler to compile them all] [for the i386 at least
On Sun, Aug 26, 2012 at 11:55 AM, Ian Lance Taylor wrote:
> On Sun, Aug 26, 2012 at 3:43 AM, Gerald Pfeifer wrote:
>> On Tue, 7 Aug 2012, Ian Lance Taylor wrote:
>>> The official link at http://codesourcery.com/cxx-abi/ (note trailing
>>> slash) still work
g
> Subject: Re: [wwwdocs] Update links to C++ ABI
>
> On Sun, 26 Aug 2012, Ian Lance Taylor wrote:
> >> It used to be http://sourcery.mentor.com/public/cxx-abi/ as of
> >> lately, and now redirects to http://mentorembedded.github.com/cxx-
> abi/ .
> >>
> >&g
On Sun, 26 Aug 2012, Ian Lance Taylor wrote:
>> It used to be http://sourcery.mentor.com/public/cxx-abi/ as of lately,
>> and now redirects to http://mentorembedded.github.com/cxx-abi/ .
>>
>> I went ahead and updated all our references per the patch below.
> I don
On Sun, Aug 26, 2012 at 3:43 AM, Gerald Pfeifer wrote:
> On Tue, 7 Aug 2012, Ian Lance Taylor wrote:
>> The official link at http://codesourcery.com/cxx-abi/ (note trailing
>> slash) still works.
>
> It used to be http://sourcery.mentor.com/public/cxx-abi/ as of lately,
&
On Tue, 7 Aug 2012, Ian Lance Taylor wrote:
> The official link at http://codesourcery.com/cxx-abi/ (note trailing
> slash) still works.
It used to be http://sourcery.mentor.com/public/cxx-abi/ as of lately,
and now redirects to http://mentorembedded.github.com/cxx-abi/ .
I went ahe
s of std::ios_failure.
>
> I don't know if adding move semantics to iostream classes can be done
> without ABI changes (I haven't looked into it.)
I've just remembered that std::reverse_iterator has been in need of an
ABI change for years now, see LWG DR 198 and PR 51823.
e attribute to make it a different type with the "_cxx11" tag.)
I think there are some changes needed to the hierarchy of exception
classes, to add std::system_error as a base class of std::ios_failure.
I don't know if adding move semantics to iostream classes can be done
without ABI changes (I haven't looked into it.)
On Wed, Jul 11, 2012 at 02:47:37PM +0200, Michael Matz wrote:
> On Wed, 11 Jul 2012, Ian Lance Taylor wrote:
>
> > We will modify g++ to support a type attribute indicating the version of
> > the type, as a string. This type attribute will be inherited by any
> > other type that uses it, as a c
On Wed, Jul 11, 2012 at 6:18 AM, Ian Lance Taylor wrote:
> My version of Cary's notes (I just wrote this on my Google+ stream):
>
> We had a useful discussion about C++11 ABI issues at the GNU Tools
> Cauldron (http://gcc.gnu.org/wiki/cauldron2012). The approach will be
> s
Hi,
On Wed, 11 Jul 2012, Ian Lance Taylor wrote:
> We will modify g++ to support a type attribute indicating the version of
> the type, as a string. This type attribute will be inherited by any
> other type that uses it, as a class/struct member or via inheritance.
> Type attributes will be
My version of Cary's notes (I just wrote this on my Google+ stream):
We had a useful discussion about C++11 ABI issues at the GNU Tools
Cauldron (http://gcc.gnu.org/wiki/cauldron2012). The approach will be
shaped over time, but the general idea is as follows.
We will modify g++ to supp
string & list changes
- function w/ string arg
- classes w/ string members
- global variables
- link c++98 & c++0x together
- link existing c++98 .o & new c++-x .o
- link at runtime c++98 .so & new c++0x .so
HP: attribute on type propagates to:
- function (params or return type)
- structs w/ mem
On 07/04/2012 09:41 AM, Richard Guenther wrote:
Btw, why use a bitmask? Isn't it enough to have a single number, viewed
as an ABI suffix?
Well, I think the question is whether we want to create a mechanism
which is only useful for libstdc++ versioning or one which is useful for
ABI ch
On Wed, 4 Jul 2012, Michael Matz wrote:
> It will by the way not break unnoticed: interfaces using the problematic
> types would be mangled differently, and hence c++98 code would silently
... would _not_ silently ...
> be resolved to a c++11 variant expecting a different layout.
sa if they are using any of the changed
>> interfaces for interoperability. Passing pointers to such objects still
>> would work and break unnoticed.
>
> But it's the best we can possibly do _if_ we want to conform to c++11 in
> the v6 ABI. IMHO we want to, so we have to at
g pointers to such objects still
> would work and break unnoticed.
But it's the best we can possibly do _if_ we want to conform to c++11 in
the v6 ABI. IMHO we want to, so we have to at least make 98/11 code
coexist in the same process image, which means mangling changes. That the
using max) to all classes related
> to that class somehow (having class with the attribute as data member, or
> pointer/reference to it, etc., recursively) and all mangled names
> referencing those use some mangling extension (letter + the bitmask or
> version level somehow encoded) inside of the
angled names
referencing those use some mangling extension (letter + the bitmask or
version level somehow encoded) inside of the mangled names.
We could reserve a couple of bits for libstdc++, and pick one of the bits
for C++11 ABI incompatible changes, say std::list (_List_Impl in it?) would
get th
On Tue, Jul 3, 2012 at 1:02 PM, Paolo Carlini wrote:
> Hi,
>
>
> On 07/03/2012 09:18 PM, Jason Merrill wrote:
>>
>> 2) Object layout changes to std::list and std::basic_string. For these
>> types, there is no way to both retain backward compatibility with older
>> C++98 code and conform to the C+
On 07/03/2012 03:18 PM, Jason Merrill wrote:
It seems that ELF symbol versioning could be useful for this purpose. If
we were to extend the visibility attribute to also handle symbol
versions, that could handle a lot of issues. If Wrap uses the GLIBCXX_4
version of string, then Wrap would also be
would only affect
classes that derive from std::time_get in a multiple inheritance
context. But to be safe we could bump the time_get ABI as well as the
others.
Jason
On 07/03/2012 03:59 PM, Jonathan Wakely wrote:
Returning a std::pair by value from a function causes problems if the
caller and callee don't use the same -std setting,
http://gcc.gnu.org/PR53657 and three or four other PRs.
Right, that's because the changes to pair changed its interface. This
2012/7/3 Paolo Carlini :
> On 07/03/2012 10:10 PM, Daniel Krügler wrote:
>>
>> Isn't there a similar problem with the long long related additions of
>> virtual function to IO/localization as in std::num_get and std::num_put?
>
> Probably not, because, if I understand correctly what you are saying,
On 07/03/2012 10:10 PM, Daniel Krügler wrote:
Isn't there a similar problem with the long long related additions of
virtual function to IO/localization as in std::num_get and std::num_put?
Probably not, because, if I understand correctly what you are saying, we
have long long overloads in C++98
2012/7/3 Paolo Carlini :
> Hi,
>
> On 07/03/2012 09:18 PM, Jason Merrill wrote:
>>
>> 2) Object layout changes to std::list and std::basic_string. For these
>> types, there is no way to both retain backward compatibility with older
>> C++98 code and conform to the C++11 standard. The best we can
Hi,
On 07/03/2012 09:18 PM, Jason Merrill wrote:
2) Object layout changes to std::list and std::basic_string. For
these types, there is no way to both retain backward compatibility
with older C++98 code and conform to the C++11 standard. The best we
can hope for is to allow old code to coexi
On 3 July 2012 20:36, Jason Merrill wrote:
> On 06/18/2012 04:46 AM, Jonathan Wakely wrote:
>>
>> The problems arise when user code that uses the "inline-only" code is
>> linked to other user-code that has a different definition of that
>> inline-only code.
>
>
> What problems arise then? As long
it doesn't matter which definition of the inline-only code is
used.
On 06/18/2012 06:14 AM, Gabriel Dos Reis wrote:
A related question is whether for GCC-4.8 we should still continue
to claim that C++11 is only experimental? That is at which point are
My hope is to nail down the ABI enou
ary a marker about the ABI version which then would be
used by the linker to warn or error out. This vague idea goes of course
well beyond our specific needs for the C++98 conforming std::list vs the
C++11 conforming version of it.
Yup. I've floated this idea as well. Some kind of note sectio
There seem to be two areas of concern with compatibility between the
C++98 and C++11 ABIs:
1) Changes to member function return types, as with std::complex. For
these, the two functions could coexist except that they are mangled the
same way. So I propose that we introduce a mechanism to cha
Hi,
On Mon, 2 Jul 2012, Jeff Law wrote:
> On 07/02/2012 11:53 AM, Paolo Carlini wrote:
> >
> > I also want to mention (I don't think somebody did already in the
> > thread) that at some point, with Jason too, we discussed the idea of
> > adding to each binar
On 07/02/2012 11:53 AM, Paolo Carlini wrote:
I also want to mention (I don't think somebody did already in the
thread) that at some point, with Jason too, we discussed the idea of
adding to each binary a marker about the ABI version which then would be
used by the linker to warn or erro
should be ABI
compatible (modulo bugs), the addition of the _M_size member
to std::_List_base::_List_impl makes libraries using
std::list in headers incompatible
This is pretty nasty for LibreOffice (and no doubt others). We
can, and
often do depend on rather a number of system C
uldn't link to C++03's std::list.
>
> That means that C++03 std::list cannot interface with C++11 std::list
> even within the v6 ABI, right?
Right.
> That sounds not very much better
> than the broken ABI we have right now (unless you suggest people
> that want the C
On Mon, Jul 2, 2012 at 7:00 PM, Jonathan Wakely wrote:
> On 2 July 2012 17:43, Jeff Law wrote:
>> On 07/02/2012 10:26 AM, Michael Meeks wrote:
>>>
>>>
>>> On Thu, 2012-06-14 at 15:14 +0200, Matthias Klose wrote:
>>>>
>>>> While PR536
On 2 July 2012 17:43, Jeff Law wrote:
> On 07/02/2012 10:26 AM, Michael Meeks wrote:
>>
>>
>> On Thu, 2012-06-14 at 15:14 +0200, Matthias Klose wrote:
>>>
>>> While PR53646 claims that c++98 and c++11 should be ABI
>>> compatible (modulo bugs
On 07/02/2012 10:26 AM, Michael Meeks wrote:
On Thu, 2012-06-14 at 15:14 +0200, Matthias Klose wrote:
While PR53646 claims that c++98 and c++11 should be ABI
compatible (modulo bugs), the addition of the _M_size member
to std::_List_base::_List_impl makes libraries using
std::list in headers
On Thu, 2012-06-14 at 15:14 +0200, Matthias Klose wrote:
> While PR53646 claims that c++98 and c++11 should be ABI
> compatible (modulo bugs), the addition of the _M_size member
> to std::_List_base::_List_impl makes libraries using
> std::list in headers incompatible
Th
On 06/18/12, Paolo Carlini wrote:
>
> ... I suppose that for 4.8.0 we really want to bump the ABI, for many other
> reasons too, and be done with it.
>
> Paolo.
Would this bump include everything? Such as rebasing std::ios_base::failure
from std::exception to std::s
(it's used
also by , etc). For C++11, the last week I may have envisaged
switching only the internals, without changing the exports, but
then it would not be able to interoperate with , thus it would
not lead to a consistent C++11 library. I suppose that for 4.8.0 we
really want to bump th
Hi,
On Mon, 18 Jun 2012, Gabriel Dos Reis wrote:
> Jeff, please note that the path that Michael took from what was said
> ealier (in particular the quote he provided in his message) and the
> conclusion of "enthusiasm for soname bump" is still a mystery.
The quoted part suggested switching std
On 06/18/2012 07:16 AM, Gabriel Dos Reis wrote:
On Mon, Jun 18, 2012 at 7:55 AM, Jeff Law wrote:
On 06/16/2012 12:46 PM, Michael Matz wrote:
A soname change for a basic system library is a _major_ PITA and should be
avoided even at large costs. In that light: do you have a plan of action
o
On Mon, Jun 18, 2012 at 7:55 AM, Jeff Law wrote:
> On 06/16/2012 12:46 PM, Michael Matz wrote:
>>>
>>>
>> A soname change for a basic system library is a _major_ PITA and should be
>> avoided even at large costs. In that light: do you have a plan of action
>> of how to never change the soname aga
usable by the library to control its ABI/API would be worthwhile if a
soname bump can be avoided.
Agreed.
It's probably worth noting that at least some of the desire to bump the
soname expressed to me was to enable moving forward from
-fabi-version=2. I don't think we've seen any via
d still continue
to claim that C++11 is only experimental? That is at which point are
we going to stop claiming that? Is it just a cover for not having to
decide anything ABI-wise? If so, I think we can just say that and
drop the "experimental" disclaimer.
(we don't fully impleme
issue seriously while:
>> a) there exist serious ABI incompatibilities between the modes.
>> b) there is essentially no notice to users about the problem (and lots of
>> users already brokenly compiling in C++11 mode!)
>> c) there are no recommendations or plans for how users
On 06/15/2012 10:12 PM, James Y Knight wrote:
Whether or not this particular incompatibility was intended or not, the
point remains. You cannot say that GCC devs are taking the C++11 binary
incompatibility issue seriously while:
a) there exist serious ABI incompatibilities between the modes.
b
I have no plan for willful obstruction in solving this recurring and
really annoying
problem that trips up users again and again, under all kinds of
reasons (both perceived
or constructed.)
Hi,
On Fri, 15 Jun 2012, Gabriel Dos Reis wrote:
> On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight wrote:
>
> > IMO, at the /very least/, libstdc++ should go ahead and change std::string
> > to be the new implementation. Once std::string is ABI-incompatible between
>
On 15/06/12 21:45, Gabriel Dos Reis wrote:
On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight wrote:
IMO, at the /very least/, libstdc++ should go ahead and change std::string
to be the new implementation. Once std::string is ABI-incompatible between
the modes, there's basically no chance
On Fri, Jun 15, 2012 at 4:23 PM, Gabriel Paubert wrote:
> Does this basically mean that compiling C++ code with GCC4.7 will be playing
> Russian roulette?
I don't think so. Let's make sure we do not overstate the case and we keep
things in perspective and accurate.
-- Gaby
On 15 June 2012 22:23, Gabriel Paubert wrote:
>
> Does this basically mean that compiling C++ code with GCC4.7 will be playing
> Russian roulette?
No.
If you don't use -std=c++11 then there's absolutely no problem
whatsoever. If you do use it, use it consistently.
Hi,
> Does this basically mean that compiling C++ code with GCC4.7 will be playing
> Russian roulette?
I don't know, I see pretty extreme statements around, which lately (maybe
because I'm getting older? ;) I do my best to avoid. In any case, 4.7.1 is
already out, whatever we do as regards to
On Fri, Jun 15, 2012 at 10:52:27PM +0200, Paolo Carlini wrote:
> Hi,
>
> > On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight wrote:
> >
> >> IMO, at the /very least/, libstdc++ should go ahead and change std::string
> >> to be the new implementation. Once std
Hi,
> On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight wrote:
>
>> IMO, at the /very least/, libstdc++ should go ahead and change std::string
>> to be the new implementation. Once std::string is ABI-incompatible between
>> the modes, there's basically no chance
On Fri, Jun 15, 2012 at 3:12 PM, James Y Knight wrote:
> IMO, at the /very least/, libstdc++ should go ahead and change std::string
> to be the new implementation. Once std::string is ABI-incompatible between
> the modes, there's basically no chance that anyone would think that
&g
oint remains. You cannot say that GCC devs are taking the C++11 binary
incompatibility issue seriously while:
a) there exist serious ABI incompatibilities between the modes.
b) there is essentially no notice to users about the problem (and lots of
users already brokenly compiling in C++1
On Thu, Jun 14, 2012 at 10:33:11PM +0200, Paweł Sikora wrote:
> from the others side, someone can use -frecord-gcc-switches to detect mixed
> '-std=...'
> after final linking and report error in such cases.
I don't think -frecord-gcc-switches is useful for that, unless you always
specify explicit
On 14 June 2012 14:14, Matthias Klose wrote:
> So what could be done for a distribution?
>
> - For this particular issue, ask upstreams to work around this
> particular incompatibility. This might work better, if the
> upstream sits "closer" to the distribution, but doesn't seem
> to be a g
On 06/14/2012 06:14 AM, Matthias Klose wrote:
While PR53646 claims that c++98 and c++11 should be ABI
compatible (modulo bugs), the addition of the _M_size member
to std::_List_base::_List_impl makes libraries using
std::list in headers incompatible, when built in c++98 and
c++11 mode.
So it
r off recording the ABI information in its own
section rather than pull it out of the options section and that doing so
should be the default rather than contingent on user options.
We'd then want some linker support to warn/error when attempts to
mix-n-match are made.
jeff
On Thursday 31 of May 2012 22:58:32 Jonathan Wakely wrote:
> On 31 May 2012 22:39, Jonathan Wakely wrote:
> > On 31 May 2012 22:35, James Y Knight wrote:
> >> I understand that the ABI changes generally cannot be avoided, but a lot
> >> of pain for a lot of people could
On 31 May 2012 22:35, James Y Knight wrote:
> You've missed at least one ABI incompatibility in GCC 4.7 and later, as
> demonstrated in real life by (at least) libboost_python, and distilled
> into this test case.
>
> At least these bug reports are probably caused by this
While PR53646 claims that c++98 and c++11 should be ABI
compatible (modulo bugs), the addition of the _M_size member
to std::_List_base::_List_impl makes libraries using
std::list in headers incompatible, when built in c++98 and
c++11 mode. Currently seen in libsigc++ (Signal Framework
for C
> On 31 May 2012 22:35, James Y Knight wrote:
>> I understand that the ABI changes generally cannot be avoided, but a lot
>> of pain for a lot of people could be avoided by making things fail
>> obviously with a link error, instead of sometimes, arbitrarily, if
>> yo
On 31 May 2012 22:39, Jonathan Wakely wrote:
> On 31 May 2012 22:35, James Y Knight wrote:
>> I understand that the ABI changes generally cannot be avoided, but a lot
>> of pain for a lot of people could be avoided by making things fail
>> obviously with a link error,
On 31 May 2012 22:35, James Y Knight wrote:
> You've missed at least one ABI incompatibility in GCC 4.7 and later, as
> demonstrated in real life by (at least) libboost_python, and distilled
> into this test case.
>
> At least these bug reports are probably caused by this
You've missed at least one ABI incompatibility in GCC 4.7 and later, as
demonstrated in real life by (at least) libboost_python, and distilled
into this test case.
At least these bug reports are probably caused by this ABI incompatibility:
https://svn.boost.org/trac/boost/ticket/6919
I've posted this to http://gcc.gnu.org/wiki/Cxx11AbiCompatibility. I
would greatly appreciate any corrections or improvements.
On Tue, May 22, 2012 at 9:04 AM, Jeffrey Yasskin wrote:
> I've put together the following description of C++98/11 ABI
> (in)compatibility, so peopl
I've put together the following description of C++98/11 ABI
(in)compatibility, so people can tell which libraries need to be
recompiled. This is useful when you've bought a library that didn't
come with source code, and you're trying to figure out if you need to
buy a new v
> > Note that one of the objectives of this email is to try and get
> > maintainers from thinking there is going to be "a perfect time" to
> > switch. Development history tells us there will always be more
> > changes. We've been sitting on ABI-brea
On 13 January 2012 17:45, Benjamin Kosnik wrote:
>
> Note that one of the objectives of this email is to try and get
> maintainers from thinking there is going to be "a perfect time" to
> switch. Development history tells us there will always be more changes.
> We'v
> My concern is specifically about options for changing the default
> language version, not options for changing the libstdc++ ABI. More
> generally, about configure options affecting the semantics of code
> passed to GCC, as opposed to non-semantic configure options such as
&g
; to
switch. Development history tells us there will always be more changes.
We've been sitting on ABI-breaking changes since 2003.
So, the smart thing to do is to plan a transition. and to allow
testing in an easy and reproducible manner beforehand. The more time
the better.
-benjamin
On Fri, 13 Jan 2012, Benjamin Kosnik wrote:
> A canonical method for doing the ABI switch seems entirely appropriate.
My concern is specifically about options for changing the default language
version, not options for changing the libstdc++ ABI. More generally,
about configure opti
+ versioned namespaces + other container changes.
That's why I'd like to have a configure option.
> My completely unfounded prediction is that many G++ users will move to
> C++11 a lot quicker than the C community moved to C99.
Here's hoping!
> As an aside, how do you fe
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.
IM
On 12 January 2012 21:03, Jason Merrill wrote:
> On 01/12/2012 03:17 PM, Jonathan Wakely wrote:
>>
>> And if we are going to do that, shouldn't it be ASAP? Otherwise we'll
>> not be able to change anything significant in .so.7 once it's
>> available in 4.7 and we'll have to create a .so.8 for more
On 01/12/2012 03:17 PM, Jonathan Wakely wrote:
And if we are going to do that, shouldn't it be ASAP? Otherwise we'll
not be able to change anything significant in .so.7 once it's
available in 4.7 and we'll have to create a .so.8 for more changes..
Wait, what? Are you planning to move to .so.7
On 01/12/2012 02:16 PM, Benjamin Kosnik wrote:
As it turns out, the mangling changes don't really impact the explicit
instantiations compiled in to libstdc++.so. So, it seems possible to say
Right, so people can use -fabi-version=0 and still use the installed
libstdc++.
I think a compelling
301 - 400 of 809 matches
Mail list logo
