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
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
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 as the interface of the user code is
the same, it doesn't
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::system_error and everything
Hi,
On 06/18/2012 06:01 PM, Michael Matz wrote:
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 myste
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
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 again, at least on targets where that is
reasonably possible with sy
On Mon, Jun 18, 2012 at 3: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.
Indeed.
A related question is whether for GCC-4.8 we should still continue
to c
On 18 June 2012 08:52, Stephan Bergmann wrote:
> 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) th
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) t
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
> > the modes, there's basica
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 that an
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::string is ABI-incompatible between
>
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 that anyone would think that
>> lin
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
> linking things t
> It seems to be an inadvertent incompatibility caused by the
> interaction of a libstdc++ workaround for a bug and g++ behaviour that
> may not have been known to the libstdc++ devs, so not something that
> could have been prevented by making it a linker error, because noone
> knew it was even bro
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 06/14/2012 02:33 PM, 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.
Given that we have -fabi= to go along with the -std= options, ISTM that
we'd really be better off recording the
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 be avoided by making things
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 ABI incompatibility:
> htt
> 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
>> you're
>> lucky, you'll get a segf
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, instead of sometimes, arbitrar
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 ABI incompatibility:
> htt
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
http://gcc.gn
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 people can tell which librar
31 matches
Mail list logo
