Switching the default for -fabi-version

Switching the default for -fabi-version

[Mark Mitchell]

Since nobody really objected to David Moore's suggestion that we make
-fabi-version=2 the default, I plan to change the default value of the
flag on the mainline in the next few days.

If you object, speak up now!

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: Switching the default for -fabi-version

[Joe Buck]

On Tue, Oct 21, 2003 at 04:24:38PM -0700, Mark Mitchell wrote:
> Since nobody really objected to David Moore's suggestion that we make
> -fabi-version=2 the default, I plan to change the default value of the
> flag on the mainline in the next few days.
> 
> If you object, speak up now!

No objection, though I am still curious as to whether this actually makes
a difference for any actual, widely used source code out there (that is,
does -Wabi report anything for real programs that aren't specially
constructed to tweak ABI bugs?  How often?)

Re: Switching the default for -fabi-version

[Mark Mitchell]

On Tue, 2003-10-21 at 16:32, Joe Buck wrote:
> On Tue, Oct 21, 2003 at 04:24:38PM -0700, Mark Mitchell wrote:
> > Since nobody really objected to David Moore's suggestion that we make
> > -fabi-version=2 the default, I plan to change the default value of the
> > flag on the mainline in the next few days.
> > 
> > If you object, speak up now!
> 
> No objection, though I am still curious as to whether this actually makes
> a difference for any actual, widely used source code out there (that is,
> does -Wabi report anything for real programs that aren't specially
> constructed to tweak ABI bugs?  How often?)

I've not got any very good evidence one way or the other.

Sorry,

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: Switching the default for -fabi-version

[Michael Matz]

Hi,

On Tue, 21 Oct 2003, Joe Buck wrote:

> No objection, though I am still curious as to whether this actually makes
> a difference for any actual, widely used source code out there

Okay someone tested KDE/Qt with -Wabi, and it spits about 300-500 warnings
per compilation unit (!).  A common one is about implicit virtual dtors
or something, because we have code in structure like:
   class Base { virtual ~Base() {} };
   class Derived: public Base { ... no ~Derived(); };

And each qpixmap gives an empty class warning:
 "contains empty classes which may cause base classes to be placed at
  different locations in a future version of GCC"

A thing stressing C++ quite a bit is aRts, which additionally often gives:
 "virtual base is not ABI-compliant and may change in a future version of
  GCC."

> (that is, does -Wabi report anything for real programs that aren't
> specially constructed to tweak ABI bugs?  How often?)

So, definitely yes.  I doubt though, that it matters, because we also link
against libstdc++ (of course), and hence the new compiler anyway means
full recompilation and lost of backward compatibility.  I hope that
somewhen this all becomes better, like with glibc ;-)


Ciao,
Michael.

Re: Switching the default for -fabi-version

[Allan Sandfeld]

On Wednesday 22 October 2003 15:02, Michael Matz wrote:
>
> So, definitely yes.  I doubt though, that it matters, because we also link
> against libstdc++ (of course), and hence the new compiler anyway means
> full recompilation and lost of backward compatibility.  I hope that
> somewhen this all becomes better, like with glibc ;-)
>
I really dont get the point of saying that libstdc++ differences gives a loss 
of backward compatibility. Isnt that what symbol versioning is for? 
I've never had problems with linking to two different versions of libstdc++ 
through shared libraries. It's inefficient but it works!

Keeping the ABI stable would for KDE mean that old plugins and shared 
libraries could still be used, they would just load an additional libstdc++.

`Allan

Re: Switching the default for -fabi-version

[Michael Matz]

Hi,

On Wed, 22 Oct 2003, Allan Sandfeld wrote:

> I really dont get the point of saying that libstdc++ differences gives a loss
> of backward compatibility. Isnt that what symbol versioning is for?

Is that one maintained thoroughly?  I mean, even glibc sometimes forgets
to add this or that symbol for the right version.  I have the feeling that
libstdc++ has a more complex namespace.

> I've never had problems with linking to two different versions of libstdc++
> through shared libraries. It's inefficient but it works!

No problems with the double construction of the global iostream stuff?

> Keeping the ABI stable would for KDE mean that old plugins and shared
> libraries could still be used, they would just load an additional
> libstdc++.

Yes, and exactly that made problems in the past.  I have no idea if that
becomes better with the 3.3/3.4 combination, though.


Ciao,
Michael.

Re: Switching the default for -fabi-version

[law]

In message <Pine.LNX.4.44.0310221445510.16615-100000@wotan.suse.de>, Michael Ma
tz writes:
 >So, definitely yes.  I doubt though, that it matters, because we also link
 >against libstdc++ (of course), and hence the new compiler anyway means
 >full recompilation and lost of backward compatibility.  I hope that
 >somewhen this all becomes better, like with glibc ;-)
All true.  However, does KDE have a plug-in architecture?  If so, then it's
quite possible, even likely based on your data that revving up the ABI
will mean that you also have to rebuild all the plug-ins if you rebuild
KDE. 

Similarly for Mozilla (which worries me even more).

jeff

Re: Switching the default for -fabi-version

[Michael Matz]

Hi,

On Wed, 22 Oct 2003 law@redhat.com wrote:

> All true.  However, does KDE have a plug-in architecture?

Yes.

> If so, then it's quite possible, even likely based on your data that
> revving up the ABI will mean that you also have to rebuild all the
> plug-ins if you rebuild KDE.

Correct.  But like I said, as those plugins also link against libstdc++,
those anyway have to be recompiled to link against the new libstdc++,
because two libstdc++'s in one process image (the new one for the main
app, the old one through the plugin) are bound to break in funny ways.
The bad thing is, that even if one doesn't use much from libstdc++ (which
is the case for most of KDE) the fact that both are included already makes
it break, due to the static initializers.  It might mostly work, but not
for all cases.


Ciao,
Michael.

Re: Switching the default for -fabi-version

[Mark Mitchell]

On Wed, 2003-10-22 at 07:41, law@redhat.com wrote:
> In message <Pine.LNX.4.44.0310221445510.16615-100000@wotan.suse.de>, Michael Ma
> tz writes:
>  >So, definitely yes.  I doubt though, that it matters, because we also link
>  >against libstdc++ (of course), and hence the new compiler anyway means
>  >full recompilation and lost of backward compatibility.  I hope that
>  >somewhen this all becomes better, like with glibc ;-)
> All true.  However, does KDE have a plug-in architecture?  If so, then it's
> quite possible, even likely based on your data that revving up the ABI
> will mean that you also have to rebuild all the plug-ins if you rebuild
> KDE. 
> 
> Similarly for Mozilla (which worries me even more).

You should also be aware that -Wabi is very agressive.

In many cases, there is no way for the compiler to know for sure that
layouts will change.  It's often warning that things *may* change. 
"You've done something that might lead to classes derived from this
class changing."

I actually argued against -Wabi because I do not think there is a way to
build it that does not give huge numbers of false positives -- without
actually just compiling the same file with both ABIs and then
mechanically comparing the layouts/mangling/etc. of everything. 
Without extreme magic, all plug-ins are *also* linked against the
standard library, so revving the standard library version number is
going to force them to be recompiled anyhow.

And there are bugs that can only be fixed by going to -fabi-version=2. 
We're only talking about the *default* version of the ABI -- we're not
talking about removing -fabi-version=1.

--

Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: Switching the default for -fabi-version

[Mike Stump]

On Tuesday, October 21, 2003, at 04:24 PM, Mark Mitchell wrote:
> Since nobody really objected to David Moore's suggestion that we make
> -fabi-version=2 the default, I plan to change the default value of the
> flag on the mainline in the next few days.
>
> If you object, speak up now!

Wait a few days or so, then consider putting this on the announce list. 
  That way we pick up folks that would not otherwise read the minutia of 
day-to-day gcc development.  Plug in architectures, openoffice, GTK, Qt 
come to mind...

I don't expect anyone to object...  but I think it is good to 
communicate with users on important points like this.

Re: Switching the default for -fabi-version

[Mark Mitchell]

On Tue, 2003-10-21 at 16:44, Mike Stump wrote:
> On Tuesday, October 21, 2003, at 04:24 PM, Mark Mitchell wrote:
> > Since nobody really objected to David Moore's suggestion that we make
> > -fabi-version=2 the default, I plan to change the default value of the
> > flag on the mainline in the next few days.
> >
> > If you object, speak up now!
> 
> Wait a few days or so, then consider putting this on the announce list. 
>   That way we pick up folks that would not otherwise read the minutia of 
> day-to-day gcc development.  Plug in architectures, openoffice, GTK, Qt 
> come to mind...
> 
> I don't expect anyone to object...  but I think it is good to 
> communicate with users on important points like this.

Actually, I think that's not an appropriate use of the announce list.

The average announce reader wants to know when a new release is out so
they go download it.

Understanding what this change even means requires an in-depth knowledge
of compilers and C++.

"Hi.  We're planning to change the default C++ ABI in the next version
of G++.  You won't notice because (a) you'll have to recompile
everything anyhow to use the library that comes with the new G++, and
(b) this only affects weird corner-cases.  However, if you happen to
have no weird corner-cases and are going to try to use the new compiler
with the old library, you might care.

So, do you object?"

I think that, given that the only people likely to notice are people who
are operating way outside the mainstream of C++ development, this is not
a decision that needs to be pre-announced.  It should of course go in
the release notes.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: Switching the default for -fabi-version

[law]

In message <1066780170.26681.14.camel@doubledemon.codesourcery.com>, Mark Mitch
ell writes:
 >On Tue, 2003-10-21 at 16:44, Mike Stump wrote:
 >> On Tuesday, October 21, 2003, at 04:24 PM, Mark Mitchell wrote:
 >> > Since nobody really objected to David Moore's suggestion that we make
 >> > -fabi-version=2 the default, I plan to change the default value of the
 >> > flag on the mainline in the next few days.
 >> >
 >> > If you object, speak up now!
 >> 
 >> Wait a few days or so, then consider putting this on the announce list. 
 >>   That way we pick up folks that would not otherwise read the minutia of 
 >> day-to-day gcc development.  Plug in architectures, openoffice, GTK, Qt 
 >> come to mind...
 >> 
 >> I don't expect anyone to object...  but I think it is good to 
 >> communicate with users on important points like this.
 >
 >Actually, I think that's not an appropriate use of the announce list.
 >
 >The average announce reader wants to know when a new release is out so
 >they go download it.
 >
 >Understanding what this change even means requires an in-depth knowledge
 >of compilers and C++.
 >
 >"Hi.  We're planning to change the default C++ ABI in the next version
 >of G++.  You won't notice because (a) you'll have to recompile
 >everything anyhow to use the library that comes with the new G++, and
 >(b) this only affects weird corner-cases.  However, if you happen to
 >have no weird corner-cases and are going to try to use the new compiler
 >with the old library, you might care.
 >
 >So, do you object?"
 >
 >I think that, given that the only people likely to notice are people who
 >are operating way outside the mainstream of C++ development, this is not
 >a decision that needs to be pre-announced.  It should of course go in
 >the release notes.
Well, maybe someone with in depth knowledge of what ABI things
have changed should chime in at this point and indicate what
has actually changed :-)

That seems like critical information to be able to make an informed
decision.

jeff

Re: Switching the default for -fabi-version

[Mark Mitchell]

> Well, maybe someone with in depth knowledge of what ABI things
> have changed should chime in at this point and indicate what
> has actually changed :-)

The short answer is "in some classes, some fields will be at different
offsets".  But that sounds much more severe than it really is; the
longer answer is "in a few corner-case classes -- such as those with
lots of empty base classes, or those that have base classes that end
with bitfields -- the offsets of some virtual bases and/or fields might
change."

There are also a few places (involving complex templates) where the
mangled name of a function changed.
 
The descriptions of *what* changed aren't as important as the question
of *how much code* is affected.  And, when you bear in mind that the C++
runtime library is bumping its version number again, the answer is
"almost none".

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: Switching the default for -fabi-version

[law]

In message <1066788159.26681.21.camel@doubledemon.codesourcery.com>, Mark Mitch
ell writes:
 >The short answer is "in some classes, some fields will be at different
 >offsets".  But that sounds much more severe than it really is; the
 >longer answer is "in a few corner-case classes -- such as those with
 >lots of empty base classes, or those that have base classes that end
 >with bitfields -- the offsets of some virtual bases and/or fields might
 >change."
You might want to talk the Mozilla guys -- I've heard them say that they
heavily use empty base classes.  They might be able to do some testing
to see if their code is affected.  Does -Wabi catch the empty base class
changes?

 >There are also a few places (involving complex templates) where the
 >mangled name of a function changed.
Not sure who'd have the best real-world tests for this.  

Jeff

Re: Switching the default for -fabi-version

[Joe Buck]

On Tuesday, October 21, 2003, at 04:24 PM, Mark Mitchell wrote:
> > Since nobody really objected to David Moore's suggestion that we make
> > -fabi-version=2 the default, I plan to change the default value of the
> > flag on the mainline in the next few days.
> >
> > If you object, speak up now!
 
On Tue, Oct 21, 2003 at 04:44:37PM -0700, Mike Stump wrote:
> Wait a few days or so, then consider putting this on the announce list. 
>   That way we pick up folks that would not otherwise read the minutia of 
> day-to-day gcc development.  Plug in architectures, openoffice, GTK, Qt 
> come to mind...

We're only reversing the sense of a flag in CVS.  I don't see what the
purpose of "wait a few days" would be.

Certainly I'd like to see whether -Wabi reports any warnings when building
any of KDE (including Qt), the C++ parts of Gnome, OpenOffice, and Mozilla.
However, the KDE folks tell me that the first issue is getting 3.4 to
build KDE at all; there appear to be many problems with stray semicolons
that the new parser rejects.  (This begs the question of whether the
new parser's rejection of extra semicolons, even though technically correct,
is too pedantic).

Re: Switching the default for -fabi-version

[Mark Mitchell]

> Certainly I'd like to see whether -Wabi reports any warnings when building
> any of KDE (including Qt), the C++ parts of Gnome, OpenOffice, and Mozilla.
> However, the KDE folks tell me that the first issue is getting 3.4 to
> build KDE at all; there appear to be many problems with stray semicolons
> that the new parser rejects.  (This begs the question of whether the
> new parser's rejection of extra semicolons, even though technically correct,
> is too pedantic).

It only does that with -pedantic. :-)

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: Switching the default for -fabi-version

[Nathan Sidwell]

Mark Mitchell wrote:
> Since nobody really objected to David Moore's suggestion that we make
> -fabi-version=2 the default, I plan to change the default value of the
> flag on the mainline in the next few days.

Presumably ABI bugs discovered between now and 3.4's release can still be
fixed in -fabi-version=2 (and not begin a fabi-version=3).

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: Switching the default for -fabi-version

[Mark Mitchell]

On Wed, 2003-10-22 at 01:09, Nathan Sidwell wrote:
> Mark Mitchell wrote:
> > Since nobody really objected to David Moore's suggestion that we make
> > -fabi-version=2 the default, I plan to change the default value of the
> > flag on the mainline in the next few days.
> 
> Presumably ABI bugs discovered between now and 3.4's release can still be
> fixed in -fabi-version=2 (and not begin a fabi-version=3).

Indeed.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: Switching the default for -fabi-version

[Richard Guenther]

Joe Buck wrote:
>
>On Tue, Oct 21, 2003 at 04:24:38PM -0700, Mark Mitchell wrote:
>> Since nobody really objected to David Moore's suggestion that we make
>> -fabi-version=2 the default, I plan to change the default value of the
>> flag on the mainline in the next few days.
>>
>> If you object, speak up now!
>
>No objection, though I am still curious as to whether this actually makes
>a difference for any actual, widely used source code out there (that is,
>does -Wabi report anything for real programs that aren't specially
>constructed to tweak ABI bugs?  How often?)

Just throwing g++-3.4 with -Wabi at my POOMA based scientific code spits
out a lot of

warning: layout of classes derived from empty class
`XXX insert you favorite class here' may change in a future version of GCC

and

warning: the mangled name of `typename T::AddResult_t operator-(const
DomainBase<T1>&, const DomainDelta<Dim, C>&) [with T =
DomainTraits<Interval<2> >, int Dim = 2, int C = 2]' will change in a
future version of GCC

and

warning: `VectorEngine<2, double, BinaryVectorOp<Vector<2, double, Full>,
Vector<2, double, Full>, OpAdd> >::op_m' contains empty classes which may
cause base classes to be placed at different locations in a future version
of GCC

and

warning: vtable layout for class `DistributedMapper<2>' may not be
ABI-compliant and may change in a future version of GCC due to implicit
virtual destructor

which are not very clear (may vs. will) and omitting of a reason (in case
of the second warning). So to say, if I can still specify -fabi-version=0
I'm happy with changing. But you could try to make sure you dont break
libstdc++ compatibility with this change?

Thanks,

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

Re: Switching the default for -fabi-version

[Mark Mitchell]

> which are not very clear (may vs. will) and omitting of a reason (in case
> of the second warning). So to say, if I can still specify -fabi-version=0
> I'm happy with changing. But you could try to make sure you dont break
> libstdc++ compatibility with this change?

This is the point everyone seems to be missing: libstdc++ compatibility
is *already* going to break in GCC 3.4.

And, what, really is the benefit of keeping the default compiler ABI
consistent with a previous version if the runtime library is going to
bump its major version number?

The only situation where the change I'm proposing would matter is when
you're using the new compiler with the old library.  That probably won't
work anyhow -- since, for example, the new parser probably can't handle
the old headers.

But, if, somehow, it would work without the change, it will also work
with the change -- provided you add -fabi-version=1 to your command
line.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: Switching the default for -fabi-version

[Richard Guenther]

On 22 Oct 2003, Mark Mitchell wrote:

>
> > which are not very clear (may vs. will) and omitting of a reason (in case
> > of the second warning). So to say, if I can still specify -fabi-version=0
> > I'm happy with changing. But you could try to make sure you dont break
> > libstdc++ compatibility with this change?
>
> This is the point everyone seems to be missing: libstdc++ compatibility
> is *already* going to break in GCC 3.4.

Ah, in this case its pointless arguing about a change in ABI (I think).
Just go ahead.

Thanks,

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

Re: Switching the default for -fabi-version

[Allan Sandfeld]

On Wednesday 22 October 2003 10:28, Mark Mitchell wrote:
> > which are not very clear (may vs. will) and omitting of a reason (in case
> > of the second warning). So to say, if I can still specify -fabi-version=0
> > I'm happy with changing. But you could try to make sure you dont break
> > libstdc++ compatibility with this change?
>
> This is the point everyone seems to be missing: libstdc++ compatibility
> is *already* going to break in GCC 3.4.
>
libstdc++ is always breaking, but will it be possible to compile libstdc++ 
with the old ABI (and possibly install both)?

I know distributers would love the keep the ABI stable.

`Allan

Re: Switching the default for -fabi-version

[Gabriel Dos Reis]

Allan Sandfeld <linux@sneulv.dk> writes:

| On Wednesday 22 October 2003 10:28, Mark Mitchell wrote:
| > > which are not very clear (may vs. will) and omitting of a reason (in case
| > > of the second warning). So to say, if I can still specify -fabi-version=0
| > > I'm happy with changing. But you could try to make sure you dont break
| > > libstdc++ compatibility with this change?
| >
| > This is the point everyone seems to be missing: libstdc++ compatibility
| > is *already* going to break in GCC 3.4.
| >
| libstdc++ is always breaking, but will it be possible to compile libstdc++ 
| with the old ABI (and possibly install both)?

You can compile with -fabi-version, but you have to keep in fore that
libstdc++ has bumped its version.

What you cannot do with the new parser is use it to compile past
versions of libstdc++.


I'm under the impression that each time "ABI version" come up, people
get nervous, without actually looking at the nature of the things being
changed.

-- Gaby

Re: Switching the default for -fabi-version

[law]

In message <1066811338.4002.6.camel@minax.codesourcery.com>, Mark Mitchell writ
es:
 >
 >> which are not very clear (may vs. will) and omitting of a reason (in case
 >> of the second warning). So to say, if I can still specify -fabi-version=0
 >> I'm happy with changing. But you could try to make sure you dont break
 >> libstdc++ compatibility with this change?
 >
 >This is the point everyone seems to be missing: libstdc++ compatibility
 >is *already* going to break in GCC 3.4.
But as you know, not everyone uses libstdc++ ;-)  

 >And, what, really is the benefit of keeping the default compiler ABI
 >consistent with a previous version if the runtime library is going to
 >bump its major version number?
The ability to build plug-ins for popular packages such as Mozilla.

The ability to interoperate with existing C++ runtimes that may not be
libstdc++.

 >The only situation where the change I'm proposing would matter is when
 >you're using the new compiler with the old library.  That probably won't
 >work anyhow -- since, for example, the new parser probably can't handle
 >the old headers.
I wasn't aware of this.

 >But, if, somehow, it would work without the change, it will also work
 >with the change -- provided you add -fabi-version=1 to your command
 >line.
That may ultimately be the answer.  Bump up and allow folks who need it
to explicitly ask for the old ABI.  

jeff

Re: Switching the default for -fabi-version

[Gabriel Dos Reis]

law@redhat.com writes:

| In message <1066811338.4002.6.camel@minax.codesourcery.com>, Mark Mitchell writ
| es:
|  >
|  >> which are not very clear (may vs. will) and omitting of a reason (in case
|  >> of the second warning). So to say, if I can still specify -fabi-version=0
|  >> I'm happy with changing. But you could try to make sure you dont break
|  >> libstdc++ compatibility with this change?
|  >
|  >This is the point everyone seems to be missing: libstdc++ compatibility
|  >is *already* going to break in GCC 3.4.
| But as you know, not everyone uses libstdc++ ;-)  

:-)

[...]

|  >The only situation where the change I'm proposing would matter is when
|  >you're using the new compiler with the old library.  That probably won't
|  >work anyhow -- since, for example, the new parser probably can't handle
|  >the old headers.
| I wasn't aware of this.

This is mostly related to name lookup issue and parsing errors.
While working on the parser, Mark made many corrections to the
headers.

The name lookup business can lead to different functions being called.

|  >But, if, somehow, it would work without the change, it will also work
|  >with the change -- provided you add -fabi-version=1 to your command
|  >line.
| That may ultimately be the answer.  Bump up and allow folks who need it
| to explicitly ask for the old ABI.  

yes.  I think that option has always been available since the last
3.1.1 -> 3.2 psychodram.

-- Gaby

Re: Switching the default for -fabi-version

[Mark Mitchell]

On Wed, 2003-10-22 at 07:49, law@redhat.com wrote:
> In message <1066811338.4002.6.camel@minax.codesourcery.com>, Mark Mitchell writ
> es:
>  >
>  >> which are not very clear (may vs. will) and omitting of a reason (in case
>  >> of the second warning). So to say, if I can still specify -fabi-version=0
>  >> I'm happy with changing. But you could try to make sure you dont break
>  >> libstdc++ compatibility with this change?
>  >
>  >This is the point everyone seems to be missing: libstdc++ compatibility
>  >is *already* going to break in GCC 3.4.

> But as you know, not everyone uses libstdc++ ;-)  

Yes, I do know that -- but I wouldn't think that (with our GNU project
hats on) we should worry particularly hard about people using other
runtimes.

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: Switching the default for -fabi-version

[Florian Weimer]

Mark Mitchell wrote:

> This is the point everyone seems to be missing: libstdc++ compatibility
> is *already* going to break in GCC 3.4.

Can we fix the 386 breakage at the same time (if it's still there)?

Re: Switching the default for -fabi-version

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

Florian Weimer <fw@deneb.enyo.de> writes:

> Mark Mitchell wrote:
>
>> This is the point everyone seems to be missing: libstdc++ compatibility
>> is *already* going to break in GCC 3.4.
>
> Can we fix the 386 breakage at the same time (if it's still there)?

Which breakage exactly do you mean?

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Deutschherrnstr. 15-19, 90429 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Switching the default for -fabi-version

[Florian Weimer]

Andreas Jaeger wrote:

> >> This is the point everyone seems to be missing: libstdc++ compatibility
> >> is *already* going to break in GCC 3.4.
> >
> > Can we fix the 386 breakage at the same time (if it's still there)?
> 
> Which breakage exactly do you mean?

The C++ standard library used to use xaddl by default, which isn't
available on 386.

It was fixed in PR 7926, so it's up to the distributors if they want
to change the ABI to be 386-compatible or not, I guess.

Re: Switching the default for -fabi-version

[Zack Weinberg]

Florian Weimer <fw@deneb.enyo.de> writes:

> The C++ standard library used to use xaddl by default, which isn't
> available on 386.
>
> It was fixed in PR 7926, so it's up to the distributors if they want
> to change the ABI to be 386-compatible or not, I guess.

If I understand the situation correctly, there is an unavoidable
choice between being backward compatible with the i386, and being
genuinely thread safe on a multiprocessor machine.

Personally, I think the latter is preferable.

zw

Re: Switching the default for -fabi-version

[Benjamin Kosnik]

Mark, I think this is a great idea, and am in favor of this switch. 

I think sufficiently clever system integrators will be able to rig a
gcc-3.4 so that it is multi-abi: ie a gcc-3.4-fabi=2 with
libstdc++.so.6, and gcc-3.4-fabi=1 with libstdc++.so.5 (from the last
stable branch.) I believe this will be able to keep compatibility
with..... gcc-3.3.x.... and still allow newly-compiled code to take
advantage of the newer runtime ABI and bug-fixed compiler ABI.

best,
benjamin

Re: Switching the default for -fabi-version

[Mark Mitchell]

> I think sufficiently clever system integrators will be able to rig a
> gcc-3.4 so that it is multi-abi: 

Yes, that's what I expect too.  

Thanks,

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC

Re: Switching the default for -fabi-version

[Benjamin Kosnik]

> Certainly I'd like to see whether -Wabi reports any warnings when
> building any of KDE (including Qt), the C++ parts of Gnome, OpenOffice,
> and Mozilla. 

It doesn't matter, but libstdc++ gets errors with -Wabi. It looks like
POOMA, and KDE do as well. 

>However, the KDE folks tell me that the first issue is
> getting 3.4 to build KDE at all; there appear to be many problems with
> stray semicolons that the new parser rejects.

Missing semicolons in member class declarations also have different
warning messages, and locations. For people who have gotten used to the
old messages, a bit of re-training is necessary.

-benjamin