egcs and altivec vector type

egcs and altivec vector type

[David Young]

Does egcs correctly generate code for the altivec vector and pixel types?
What is the status of this feature?
Is there a URL explaining the status or plan of this feature for egcs?

Your input is much appreciated!

Thanks A Bunch! David Young; VVI-DCS
dyoung@vvi.com

ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Doug Landauer]

The GCC 2.95 Caveats page (< http://egcs.cygnus.com/gcc-2.95/caveats.html >)
says
>
>  GCC 2.95 compiled C++ code is not binary compatible
>    with EGCS 1.1, EGCS 1.0.x or GCC 2.8.x.

Is there a more detailed description of what the known
incompatibilities are, and/or what C++ features might
trigger them, and/or whether there is a subset of C++ that
one might reasonably expect to work compatibly, say from
egcs 1.1 to gcc 2.95?


And is there anything describing likely C++ ABI changes in
near-future releases (2.9x for x > 5; and/or 3.0)?


  Thanks,
   -- Doug Landauer

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Alex Buell]

On Mon, 20 Sep 1999, Doug Landauer wrote:

> Is there a more detailed description of what the known
> incompatibilities are, and/or what C++ features might trigger them,
> and/or whether there is a subset of C++ that one might reasonably
> expect to work compatibly, say from egcs 1.1 to gcc 2.95?

I ran into this problem with my Linux system. As most of the libraries had
been compiled with egcs-1.0.3, egcs-1.1.1, egcs-1.1.2, and when I moved to
gcc-2.95.1, everything went to hell. :o( 

Solution was to recompile nearly everything. Fortunately, I've got ~600MB
sources on a CD so it was just a matter of rebuilding all the critical
libraries, and then fixing the rest as I find them. 

Cheers, 
Alex 
-- 

Legalise cannabis today!

http://www.tahallah.demon.co.uk - updated!

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Martin v. Loewis]

> I ran into this problem with my Linux system. As most of the libraries had
> been compiled with egcs-1.0.3, egcs-1.1.1, egcs-1.1.2, and when I moved to
> gcc-2.95.1, everything went to hell. :o( 

Could you qualify in more detail what exactly stopped working, and
perhaps even why?

Regards,
Martin

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Alex Buell]

On Mon, 20 Sep 1999, Martin v. Loewis wrote:

> > I ran into this problem with my Linux system. As most of the libraries had
> > been compiled with egcs-1.0.3, egcs-1.1.1, egcs-1.1.2, and when I moved to
> > gcc-2.95.1, everything went to hell. :o( 
> 
> Could you qualify in more detail what exactly stopped working, and
> perhaps even why?

It's a long story but if you're prepared to read on, then do so by all
means.

A while back I had LessTif 0.88.9 compiled and installed using
egcs-1.1.2. Soon after, I decided to install gcc-2.95.1 on the system,
LessTif 0.89.0 came out soon afterwards and I compiled and installed it. 

It was at that point that things took a strange turn, I noticed that some
of my Motif applications that were built using egcs-1.1.2 would exhibit
very strange behaviour (i.e coredumped at a particular place every time).
I thought I'd recompile the Motif applications but they still coredumped.
I also noticed that my favourite debugger (DDD - a motif-based debugger)
was crashing on start-up, figured out that the new binaries and the
LessTif libraries were in fact blowing up everytime they tried to make
calls into the X11R6 libraries (which had been compiled with egcs 4 months
ago!). I took X11 down and recompiled it all (taking the opportunity to
upgrade to 3.3.5 from 3.3.3 along the way), reinstalled. 

Bingo. That solved the coredump problems. 

I was told by someone else on the gcc mailing list that it was because
gcc-2.95.1 and the egcs range (1.0.3 -> 1.1.2) have different binary
conventions. Fun. 

Now when I come across an application that's acting strangely, I recompile
that and its associated libraries. That usually cures the problem. 

Unfortunately there's worse to come (not that I'm blaming the gcc people
for this, the kernel people should have known better than to use invalid
asm constructs!), don't think about compiling kernels with gcc-2.95.1
until the asm constructs are fixed, that will happen for 2.2.13. In fact
I've had several crashes already in the last two days. I just hope 2.2.13
will come out soon. 

Cheers, 
Alex 
-- 

Legalise cannabis today!

http://www.tahallah.demon.co.uk - updated!

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Martin v. Loewis]

> Is there a more detailed description of what the known
> incompatibilities are, and/or what C++ features might
> trigger them, and/or whether there is a subset of C++ that
> one might reasonably expect to work compatibly, say from
> egcs 1.1 to gcc 2.95?

I started collecting such information, but I don't know whether my
list is complete. If anybody has additions, please let me know:

- STL was updated. In particular, the Allocator implementation was
  replaced, and renamed. As a result, all mangled names mentioning
  an allocator (i.e. more or less *all* instantiations of standard
  templates) are binary-incompatible with egcs 1.1. As STL continues
  to evolve in a binary-incompatible manner, such changes are likely
  in the future.
  A number of other STL classes changed as well. I stopped writing
  down the changes when I noticed the allocator thing; feel free to
  diff between 1.1 STL and 2.95 STL if you need more details.
- __start_cp_handler was introduced as part of libgcc, and the EH
  machinery. The old (i.e. 1.1) functions remain present, and it
  is ok to mix them with __start_cp_handler. It only means that you
  cannot link 2.95 object files with the 1.1 libgcc.a

Anything else should be compatible. As I said, I may be missing
things. Since people will continue to ask this question: If anybody
knows of any other incompatibility, *please* let me know.

As for compatibility with even older versions (egcs 1.0, gcc 2.8):
Forget it. I have no complete list, but the changes to make EH
thread-safe should break a large number of binaries; I believe STL was
updated between 1.0 and 1.1, as well.

> And is there anything describing likely C++ ABI changes in
> near-future releases (2.9x for x > 5; and/or 3.0)?

Well, it is very easy to find out what *currently* comprises the ABI
changes in gcc 2.96, under the -fnew-abi flag; see cp/decl2.c for a
details:
- The squangling mechanism will break link compatibility.
- honor-std breaks that as well, at least for std library things
  (primarily iostreams and STL)
- vtable-thunks are enabled on all platforms (under new ABI), with
  an important fix still missing (but coming up)
- the new ABI itself currently does the empty bases optimization,
  but different people have different ideas what else it could or
  should do.

If the above counts as "anything", I guess I'm done. It is difficult
to tell what changes exactly will be in the next compiler, especially
as I did not mention libstdc++ v3 so far. If we get that, about every
program using the std library will binary-break.

So it is a safe bet that one of the upcoming releases will be totally
incompatible with anything you are compiling right now. Exactly *when*
this will happen is open at this time; different people have different
views :-)

Hope this helps,
Martin

P.S. I didn't include any sales talk about how great the future will
be, and how important it is to give the new features to the users, and
that users should either accept that as a fact of life, or continue
with the compiler they got. I hope you'll understand all this, anyway,
and that I'm speaking for myself, not as a representative of somebody
or something.

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Martin v. Loewis]

> A while back I had LessTif 0.88.9 compiled and installed using
> egcs-1.1.2. ...
> I also noticed that my favourite debugger (DDD - a motif-based debugger)
> was crashing on start-up...
> I took X11 down and recompiled it all...
[...]
> I was told by someone else on the gcc mailing list that it was because
> gcc-2.95.1 and the egcs range (1.0.3 -> 1.1.2) have different binary
> conventions. Fun. 

These are all C applications, right? (at least X11, and Lesstif are -
not sure about DDD). There has been absolutely *no* change in the
binary convention for the C language (somebody correct me if I'm
wrong), so recompiling X11 would definitely not have the effect of
fixing ABI problems.

Perhaps I'm missing something, but it seems to me that your problems
must have been caused by something else (like a codegen bug that would
only show up in certain cases, and fixed by recompiling the libraries,
or a corruption of the library image on disk, fixed again by producing
a new image).

Regards,
Martin

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Alexandre Oliva]

On Sep 20, 1999, "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> wrote:

> These are all C applications, right? (at least X11, and Lesstif are -
> not sure about DDD)

Both lesstif and DDD make heavy use of C++.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Alex Buell]

On 20 Sep 1999, Alexandre Oliva wrote:

> On Sep 20, 1999, "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> wrote:
> 
> > These are all C applications, right? (at least X11, and Lesstif are -
> > not sure about DDD)
> 
> Both lesstif and DDD make heavy use of C++.

I recompiled LessTif and DDD, and it still coredumped in places.
Recompiling the X11 (heavily C based) libraries and programs cured the
problems. That's why I'm puzzled!

Cheers, 
Alex 
-- 

Legalise cannabis today!

http://www.tahallah.demon.co.uk - updated!

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Wolfram Gloger]

> Perhaps I'm missing something, but it seems to me that your problems
> must have been caused by something else (like a codegen bug that would
> only show up in certain cases, and fixed by recompiling the libraries,
> or a corruption of the library image on disk, fixed again by producing
> a new image).

I'm pretty sure that the upgrade from glibc-2.0 to 2.1 caused these
problems.  I, too, had to recompile my X11 libraries (not any C
applications though) when I made that upgrade.  It's mentioned in
glibc's release notes, I believe.

I see no evidence that there are any backwards compatibility problems
with `pure' C code due to gcc upgrades.

Regards,
Wolfram.

Re: egcs and altivec vector type

[David Edelsohn]

>>>>> David Young writes:

David> Does egcs correctly generate code for the altivec vector and pixel types?
David> What is the status of this feature?
David> Is there a URL explaining the status or plan of this feature for egcs?

	Apple apparently has a version of egcs-1.1.2 with AltiVec
functionality added available from an Apple website.  I have not received
any contact from Apple about a timetable for contributing that work back
to GCC.  Hopefully all of Apple's changes eventually will be incorporated
into the GCC public sources so that they do not need to maintain a
divergent branch and can utilize GCC development more rapidly.

David

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Alex Buell]

On 21 Sep 1999, Wolfram Gloger wrote:

> I'm pretty sure that the upgrade from glibc-2.0 to 2.1 caused these
> problems.  I, too, had to recompile my X11 libraries (not any C
> applications though) when I made that upgrade.  It's mentioned in
> glibc's release notes, I believe.

Been there, done that. Everything worked 100% prior to installing
gcc-2.95.1.
 
> I see no evidence that there are any backwards compatibility problems
> with `pure' C code due to gcc upgrades.

And the evidence is right here, rebuilding cured my problems. 

Cheers, 
Alex 
-- 

Legalise cannabis today!

http://www.tahallah.demon.co.uk - updated!

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Wolfram Gloger]

> On 21 Sep 1999, Wolfram Gloger wrote:
> 
> > I'm pretty sure that the upgrade from glibc-2.0 to 2.1 caused these
> > problems.  I, too, had to recompile my X11 libraries (not any C
> > applications though) when I made that upgrade.  It's mentioned in
> > glibc's release notes, I believe.
> 
> Been there, done that. Everything worked 100% prior to installing
> gcc-2.95.1.

I should have been more clear: The fact that the X11 libs had been
compiled against glibc-2.0 caused the compatibility problem.  Surely
this was the case for you too ?  These problems were subtle, it was
quite hard to notice them at all (I noticed only several months after
installing glibc-2.1).

> > I see no evidence that there are any backwards compatibility problems
> > with `pure' C code due to gcc upgrades.
> 
> And the evidence is right here, rebuilding cured my problems. 

Yes, rebuilding the X11 libraries against glibc-2.1 cured the
problems.  This sure looks like a change in glibc to me (as mentioned
in its release notes).  You could probably verify this by once again
recompiling X11 using an older compiler (this I would predict to
continue working) _or_ against glibc-2.0 (this I would predict to
fail).

Regards,
Wolfram.

Re: egcs and altivec vector type

[David Young]

David,

> I have not received
> any contact from Apple about a timetable for contributing that work back
> to GCC.  Hopefully all of Apple's changes eventually will be incorporated
> into the GCC public sources

Thank you for your information. I am aware of Apple's version, but we want  
the mainlined (GCC public sources) version with altivec code when available,  
if ever. How can I become informed when it is mainlined, going to be  
mainlined, or is being worked on (has been submitted by Apple)? Is there a  
URL for that or anyone that maintains that information?

Again, thanks for the excellent egcs!

Thanks A Bunch! David Young; VVI-DCS
dyoung@vvi.com

Re: egcs and altivec vector type

[Gerald Pfeifer]

On Wed, 22 Sep 1999, David Young wrote:
> How can I become informed when it is mainlined, going to be mainlined,
> or is being worked on (has been submitted by Apple)? Is there a URL
> for that or anyone that maintains that information?

If/when this is added to GCC (CVS sources) there will be an announcement
at the URL http://gcc.gnu.org . We always announce such stuff there...

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Alex Buell]

On 22 Sep 1999, Wolfram Gloger wrote:

> I should have been more clear: The fact that the X11 libs had been
> compiled against glibc-2.0 caused the compatibility problem.  Surely
> this was the case for you too ?  These problems were subtle, it was
> quite hard to notice them at all (I noticed only several months after
> installing glibc-2.1).

No, the X11 libraries had been compiled against glibc-2.1 a few months
ago. I did say everything worked perfectly before I used gcc-2.95.1 in
anger. Only my Motif applications started going bananas after I built &
installed LessTif. So there is evidence of a problem with gcc-2.95.1,
which went away when I recompiled most of the critical libraries. I'm sure
there's a few libraries hiding waiting to bite me on my arse. 

That doesn't really matter anyhow as everything seems to work just fine
(apart from a power cut a few hours ago) :-S

Cheers, 
Alex 
-- 

Legalise cannabis today!

http://www.tahallah.demon.co.uk - updated!

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Gerald Pfeifer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

On Tue, 21 Sep 1999, Martin v. Loewis wrote:
>> Is there a more detailed description of what the known
>> incompatibilities are, and/or what C++ features might
>> trigger them, and/or whether there is a subset of C++ that
>> one might reasonably expect to work compatibly, say from
>> egcs 1.1 to gcc 2.95?
> I started collecting such information, but I don't know whether my
> list is complete. If anybody has additions, please let me know:

Hi Martin,

I guess upon reading the Subject: and From: headers of this mail you
is already schwaning Ãœbles, right? (Sorry for the Germanism ;-) )

Wouldn't this make a great addition to our documentation on the web?

I am not yet completely sure where exactly to put that, but would you
be willing to contribute something in that direction?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Wolfram Gloger]

> Perhaps I'm missing something, but it seems to me that your problems
> must have been caused by something else (like a codegen bug that would
> only show up in certain cases, and fixed by recompiling the libraries,
> or a corruption of the library image on disk, fixed again by producing
> a new image).

I'm pretty sure that the upgrade from glibc-2.0 to 2.1 caused these
problems.  I, too, had to recompile my X11 libraries (not any C
applications though) when I made that upgrade.  It's mentioned in
glibc's release notes, I believe.

I see no evidence that there are any backwards compatibility problems
with `pure' C code due to gcc upgrades.

Regards,
Wolfram.

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Alex Buell]

On 20 Sep 1999, Alexandre Oliva wrote:

> On Sep 20, 1999, "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> wrote:
> 
> > These are all C applications, right? (at least X11, and Lesstif are -
> > not sure about DDD)
> 
> Both lesstif and DDD make heavy use of C++.

I recompiled LessTif and DDD, and it still coredumped in places.
Recompiling the X11 (heavily C based) libraries and programs cured the
problems. That's why I'm puzzled!

Cheers, 
Alex 
-- 

Legalise cannabis today!

http://www.tahallah.demon.co.uk - updated!

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Alex Buell]

On 22 Sep 1999, Wolfram Gloger wrote:

> I should have been more clear: The fact that the X11 libs had been
> compiled against glibc-2.0 caused the compatibility problem.  Surely
> this was the case for you too ?  These problems were subtle, it was
> quite hard to notice them at all (I noticed only several months after
> installing glibc-2.1).

No, the X11 libraries had been compiled against glibc-2.1 a few months
ago. I did say everything worked perfectly before I used gcc-2.95.1 in
anger. Only my Motif applications started going bananas after I built &
installed LessTif. So there is evidence of a problem with gcc-2.95.1,
which went away when I recompiled most of the critical libraries. I'm sure
there's a few libraries hiding waiting to bite me on my arse. 

That doesn't really matter anyhow as everything seems to work just fine
(apart from a power cut a few hours ago) :-S

Cheers, 
Alex 
-- 

Legalise cannabis today!

http://www.tahallah.demon.co.uk - updated!

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Alexandre Oliva]

On Sep 20, 1999, "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> wrote:

> These are all C applications, right? (at least X11, and Lesstif are -
> not sure about DDD)

Both lesstif and DDD make heavy use of C++.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

Re: egcs and altivec vector type

[David Edelsohn]

>>>>> David Young writes:

David> Does egcs correctly generate code for the altivec vector and pixel types?
David> What is the status of this feature?
David> Is there a URL explaining the status or plan of this feature for egcs?

	Apple apparently has a version of egcs-1.1.2 with AltiVec
functionality added available from an Apple website.  I have not received
any contact from Apple about a timetable for contributing that work back
to GCC.  Hopefully all of Apple's changes eventually will be incorporated
into the GCC public sources so that they do not need to maintain a
divergent branch and can utilize GCC development more rapidly.

David

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Martin v. Loewis]

> A while back I had LessTif 0.88.9 compiled and installed using
> egcs-1.1.2. ...
> I also noticed that my favourite debugger (DDD - a motif-based debugger)
> was crashing on start-up...
> I took X11 down and recompiled it all...
[...]
> I was told by someone else on the gcc mailing list that it was because
> gcc-2.95.1 and the egcs range (1.0.3 -> 1.1.2) have different binary
> conventions. Fun. 

These are all C applications, right? (at least X11, and Lesstif are -
not sure about DDD). There has been absolutely *no* change in the
binary convention for the C language (somebody correct me if I'm
wrong), so recompiling X11 would definitely not have the effect of
fixing ABI problems.

Perhaps I'm missing something, but it seems to me that your problems
must have been caused by something else (like a codegen bug that would
only show up in certain cases, and fixed by recompiling the libraries,
or a corruption of the library image on disk, fixed again by producing
a new image).

Regards,
Martin

Re: egcs and altivec vector type

[Gerald Pfeifer]

On Wed, 22 Sep 1999, David Young wrote:
> How can I become informed when it is mainlined, going to be mainlined,
> or is being worked on (has been submitted by Apple)? Is there a URL
> for that or anyone that maintains that information?

If/when this is added to GCC (CVS sources) there will be an announcement
at the URL http://gcc.gnu.org . We always announce such stuff there...

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Alex Buell]

On 21 Sep 1999, Wolfram Gloger wrote:

> I'm pretty sure that the upgrade from glibc-2.0 to 2.1 caused these
> problems.  I, too, had to recompile my X11 libraries (not any C
> applications though) when I made that upgrade.  It's mentioned in
> glibc's release notes, I believe.

Been there, done that. Everything worked 100% prior to installing
gcc-2.95.1.
 
> I see no evidence that there are any backwards compatibility problems
> with `pure' C code due to gcc upgrades.

And the evidence is right here, rebuilding cured my problems. 

Cheers, 
Alex 
-- 

Legalise cannabis today!

http://www.tahallah.demon.co.uk - updated!

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Wolfram Gloger]

> On 21 Sep 1999, Wolfram Gloger wrote:
> 
> > I'm pretty sure that the upgrade from glibc-2.0 to 2.1 caused these
> > problems.  I, too, had to recompile my X11 libraries (not any C
> > applications though) when I made that upgrade.  It's mentioned in
> > glibc's release notes, I believe.
> 
> Been there, done that. Everything worked 100% prior to installing
> gcc-2.95.1.

I should have been more clear: The fact that the X11 libs had been
compiled against glibc-2.0 caused the compatibility problem.  Surely
this was the case for you too ?  These problems were subtle, it was
quite hard to notice them at all (I noticed only several months after
installing glibc-2.1).

> > I see no evidence that there are any backwards compatibility problems
> > with `pure' C code due to gcc upgrades.
> 
> And the evidence is right here, rebuilding cured my problems. 

Yes, rebuilding the X11 libraries against glibc-2.1 cured the
problems.  This sure looks like a change in glibc to me (as mentioned
in its release notes).  You could probably verify this by once again
recompiling X11 using an older compiler (this I would predict to
continue working) _or_ against glibc-2.0 (this I would predict to
fail).

Regards,
Wolfram.

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Martin v. Loewis]

> Is there a more detailed description of what the known
> incompatibilities are, and/or what C++ features might
> trigger them, and/or whether there is a subset of C++ that
> one might reasonably expect to work compatibly, say from
> egcs 1.1 to gcc 2.95?

I started collecting such information, but I don't know whether my
list is complete. If anybody has additions, please let me know:

- STL was updated. In particular, the Allocator implementation was
  replaced, and renamed. As a result, all mangled names mentioning
  an allocator (i.e. more or less *all* instantiations of standard
  templates) are binary-incompatible with egcs 1.1. As STL continues
  to evolve in a binary-incompatible manner, such changes are likely
  in the future.
  A number of other STL classes changed as well. I stopped writing
  down the changes when I noticed the allocator thing; feel free to
  diff between 1.1 STL and 2.95 STL if you need more details.
- __start_cp_handler was introduced as part of libgcc, and the EH
  machinery. The old (i.e. 1.1) functions remain present, and it
  is ok to mix them with __start_cp_handler. It only means that you
  cannot link 2.95 object files with the 1.1 libgcc.a

Anything else should be compatible. As I said, I may be missing
things. Since people will continue to ask this question: If anybody
knows of any other incompatibility, *please* let me know.

As for compatibility with even older versions (egcs 1.0, gcc 2.8):
Forget it. I have no complete list, but the changes to make EH
thread-safe should break a large number of binaries; I believe STL was
updated between 1.0 and 1.1, as well.

> And is there anything describing likely C++ ABI changes in
> near-future releases (2.9x for x > 5; and/or 3.0)?

Well, it is very easy to find out what *currently* comprises the ABI
changes in gcc 2.96, under the -fnew-abi flag; see cp/decl2.c for a
details:
- The squangling mechanism will break link compatibility.
- honor-std breaks that as well, at least for std library things
  (primarily iostreams and STL)
- vtable-thunks are enabled on all platforms (under new ABI), with
  an important fix still missing (but coming up)
- the new ABI itself currently does the empty bases optimization,
  but different people have different ideas what else it could or
  should do.

If the above counts as "anything", I guess I'm done. It is difficult
to tell what changes exactly will be in the next compiler, especially
as I did not mention libstdc++ v3 so far. If we get that, about every
program using the std library will binary-break.

So it is a safe bet that one of the upcoming releases will be totally
incompatible with anything you are compiling right now. Exactly *when*
this will happen is open at this time; different people have different
views :-)

Hope this helps,
Martin

P.S. I didn't include any sales talk about how great the future will
be, and how important it is to give the new features to the users, and
that users should either accept that as a fact of life, or continue
with the compiler they got. I hope you'll understand all this, anyway,
and that I'm speaking for myself, not as a representative of somebody
or something.

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Alex Buell]

On Mon, 20 Sep 1999, Martin v. Loewis wrote:

> > I ran into this problem with my Linux system. As most of the libraries had
> > been compiled with egcs-1.0.3, egcs-1.1.1, egcs-1.1.2, and when I moved to
> > gcc-2.95.1, everything went to hell. :o( 
> 
> Could you qualify in more detail what exactly stopped working, and
> perhaps even why?

It's a long story but if you're prepared to read on, then do so by all
means.

A while back I had LessTif 0.88.9 compiled and installed using
egcs-1.1.2. Soon after, I decided to install gcc-2.95.1 on the system,
LessTif 0.89.0 came out soon afterwards and I compiled and installed it. 

It was at that point that things took a strange turn, I noticed that some
of my Motif applications that were built using egcs-1.1.2 would exhibit
very strange behaviour (i.e coredumped at a particular place every time).
I thought I'd recompile the Motif applications but they still coredumped.
I also noticed that my favourite debugger (DDD - a motif-based debugger)
was crashing on start-up, figured out that the new binaries and the
LessTif libraries were in fact blowing up everytime they tried to make
calls into the X11R6 libraries (which had been compiled with egcs 4 months
ago!). I took X11 down and recompiled it all (taking the opportunity to
upgrade to 3.3.5 from 3.3.3 along the way), reinstalled. 

Bingo. That solved the coredump problems. 

I was told by someone else on the gcc mailing list that it was because
gcc-2.95.1 and the egcs range (1.0.3 -> 1.1.2) have different binary
conventions. Fun. 

Now when I come across an application that's acting strangely, I recompile
that and its associated libraries. That usually cures the problem. 

Unfortunately there's worse to come (not that I'm blaming the gcc people
for this, the kernel people should have known better than to use invalid
asm constructs!), don't think about compiling kernels with gcc-2.95.1
until the asm constructs are fixed, that will happen for 2.2.13. In fact
I've had several crashes already in the last two days. I just hope 2.2.13
will come out soon. 

Cheers, 
Alex 
-- 

Legalise cannabis today!

http://www.tahallah.demon.co.uk - updated!

egcs and altivec vector type

[David Young]

Does egcs correctly generate code for the altivec vector and pixel types?
What is the status of this feature?
Is there a URL explaining the status or plan of this feature for egcs?

Your input is much appreciated!

Thanks A Bunch! David Young; VVI-DCS
dyoung@vvi.com

ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Doug Landauer]

The GCC 2.95 Caveats page (< http://egcs.cygnus.com/gcc-2.95/caveats.html >)
says
>
>  GCC 2.95 compiled C++ code is not binary compatible
>    with EGCS 1.1, EGCS 1.0.x or GCC 2.8.x.

Is there a more detailed description of what the known
incompatibilities are, and/or what C++ features might
trigger them, and/or whether there is a subset of C++ that
one might reasonably expect to work compatibly, say from
egcs 1.1 to gcc 2.95?


And is there anything describing likely C++ ABI changes in
near-future releases (2.9x for x > 5; and/or 3.0)?


  Thanks,
   -- Doug Landauer

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Alex Buell]

On Mon, 20 Sep 1999, Doug Landauer wrote:

> Is there a more detailed description of what the known
> incompatibilities are, and/or what C++ features might trigger them,
> and/or whether there is a subset of C++ that one might reasonably
> expect to work compatibly, say from egcs 1.1 to gcc 2.95?

I ran into this problem with my Linux system. As most of the libraries had
been compiled with egcs-1.0.3, egcs-1.1.1, egcs-1.1.2, and when I moved to
gcc-2.95.1, everything went to hell. :o( 

Solution was to recompile nearly everything. Fortunately, I've got ~600MB
sources on a CD so it was just a matter of rebuilding all the critical
libraries, and then fixing the rest as I find them. 

Cheers, 
Alex 
-- 

Legalise cannabis today!

http://www.tahallah.demon.co.uk - updated!

Re: egcs and altivec vector type

[David Young]

David,

> I have not received
> any contact from Apple about a timetable for contributing that work back
> to GCC.  Hopefully all of Apple's changes eventually will be incorporated
> into the GCC public sources

Thank you for your information. I am aware of Apple's version, but we want  
the mainlined (GCC public sources) version with altivec code when available,  
if ever. How can I become informed when it is mainlined, going to be  
mainlined, or is being worked on (has been submitted by Apple)? Is there a  
URL for that or anyone that maintains that information?

Again, thanks for the excellent egcs!

Thanks A Bunch! David Young; VVI-DCS
dyoung@vvi.com

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Martin v. Loewis]

> I ran into this problem with my Linux system. As most of the libraries had
> been compiled with egcs-1.0.3, egcs-1.1.1, egcs-1.1.2, and when I moved to
> gcc-2.95.1, everything went to hell. :o( 

Could you qualify in more detail what exactly stopped working, and
perhaps even why?

Regards,
Martin

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Gerald Pfeifer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

On Tue, 21 Sep 1999, Martin v. Loewis wrote:
>> Is there a more detailed description of what the known
>> incompatibilities are, and/or what C++ features might
>> trigger them, and/or whether there is a subset of C++ that
>> one might reasonably expect to work compatibly, say from
>> egcs 1.1 to gcc 2.95?
> I started collecting such information, but I don't know whether my
> list is complete. If anybody has additions, please let me know:

Hi Martin,

I guess upon reading the Subject: and From: headers of this mail you
is already schwaning Ãœbles, right? (Sorry for the Germanism ;-) )

Wouldn't this make a great addition to our documentation on the web?

I am not yet completely sure where exactly to put that, but would you
be willing to contribute something in that direction?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Martin v. Loewis]

> I am not yet completely sure where exactly to put that, but would you
> be willing to contribute something in that direction?

I think last time we discussed that, there was some kind of agreement
*not* to document the ABI differences. Instead, the "official" party
line is that there is no compatibility whatsoever between major
compiler versions, and any reports to the contrary are pure luck.

People who *really* need this kind of information can ask on the list,
or they can even search the mailing list archive now.

Regards,
Martin

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Martin v. Loewis]

> I am not yet completely sure where exactly to put that, but would you
> be willing to contribute something in that direction?

I think last time we discussed that, there was some kind of agreement
*not* to document the ABI differences. Instead, the "official" party
line is that there is no compatibility whatsoever between major
compiler versions, and any reports to the contrary are pure luck.

People who *really* need this kind of information can ask on the list,
or they can even search the mailing list archive now.

Regards,
Martin

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Mark Mitchell]

>>>>> "Gerald" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

    Gerald> Concerning squangling, I have been testing this on regular
    Gerald> base on sparc-sun-solaris2.6 i386-unknown-freebsdelf3.x
    Gerald> and sometimes also alphaev56-dec-osf4.0d
    Gerald> i386-pc-solaris2.7 without any problems during the last 12
    Gerald> months.

And I on sgi-mips-irix6.5.  Of course, although we don't actually
claim link-compatibility, most new code does link OK with most old
code.  Turning on -fnew-abi will break this in a rather drastic sort
of way. 

In some sense, this is similar to the -fstrict-aliasing debate; should
we strive to preserve compatibility where we can, even if that's not
everywhere, or should we (aggressively) break such compatibility in
the name of progress?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Mike Stump]

> Date: Fri, 8 Oct 1999 19:28:20 +0200
> From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>

> I think last time we discussed that, there was some kind of
> agreement *not* to document the ABI differences. Instead, the
> "official" party line is that there is no compatibility whatsoever
> between major compiler versions, and any reports to the contrary are
> pure luck.  [ the context for this was c++ (I hope) ]

Since we have now proven that we can't maintain compatibility, I think
it would be wise to turn on -fnew-abi features that are near stable,
so that we can finish testing and stabilizing them for the next major
release.  For example -fsquangle is an excellent example.

Jason, any plans to start turning this type of stuff on?

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Martin v. Loewis]

> I believe there is one major difference: The (reported) problems related
> to -fstrict-aliasing do not show up immediately during compiliation, while
> an ABI change immediately will show up during linking.

Well, the "empty base class optimization" is not linkage-safe: linking
code compiled with and without it will result in crashes or other
strange behaviour. Therefore, activating that must be combined with
activating other ABI changes that do result in linkage errors (such as
squangling, or vtable thunks).

Regards,
Martin

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Gerald Pfeifer]

On Fri, 8 Oct 1999, Mike Stump wrote:
> Since we have now proven that we can't maintain compatibility, I think
> it would be wise to turn on -fnew-abi features that are near stable,
> so that we can finish testing and stabilizing them for the next major
> release.  For example -fsquangle is an excellent example.

Actually this was my very first thought after reading Martin's reply! ;-)

Not wanting to break binary compatibility has always been the killer
argument against enabling -fnew-abi or -fsquangle, even though the latter,
for example, would have made the life of a lot of folks much easier.

Concerning squangling, I have been testing this on regular base on
  sparc-sun-solaris2.6
  i386-unknown-freebsdelf3.x
and sometimes also
  alphaev56-dec-osf4.0d
  i386-pc-solaris2.7
without any problems during the last 12 months.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Gerald Pfeifer]

On Fri, 8 Oct 1999, Mark Mitchell wrote:
> Turning on -fnew-abi will break this in a rather drastic sort of way.
> 
> In some sense, this is similar to the -fstrict-aliasing debate; should
> we strive to preserve compatibility where we can, even if that's not
> everywhere, or should we (aggressively) break such compatibility in
> the name of progress?

I believe there is one major difference: The (reported) problems related
to -fstrict-aliasing do not show up immediately during compiliation, while
an ABI change immediately will show up during linking.

Also it has little potential breaking old and/or unmaintained packages,
the only thing that might cause troubles are libraries provided in binary
form only, but these probably already broke between each of egcs 1.0 and
egcs 1.1, egcs 1.1 and GCC 2.95, or GCC 2.8 and GCC 2.95.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Martin v. Loewis]

> I believe there is one major difference: The (reported) problems related
> to -fstrict-aliasing do not show up immediately during compiliation, while
> an ABI change immediately will show up during linking.

Well, the "empty base class optimization" is not linkage-safe: linking
code compiled with and without it will result in crashes or other
strange behaviour. Therefore, activating that must be combined with
activating other ABI changes that do result in linkage errors (such as
squangling, or vtable thunks).

Regards,
Martin

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Gerald Pfeifer]

On Fri, 8 Oct 1999, Mark Mitchell wrote:
> Turning on -fnew-abi will break this in a rather drastic sort of way.
> 
> In some sense, this is similar to the -fstrict-aliasing debate; should
> we strive to preserve compatibility where we can, even if that's not
> everywhere, or should we (aggressively) break such compatibility in
> the name of progress?

I believe there is one major difference: The (reported) problems related
to -fstrict-aliasing do not show up immediately during compiliation, while
an ABI change immediately will show up during linking.

Also it has little potential breaking old and/or unmaintained packages,
the only thing that might cause troubles are libraries provided in binary
form only, but these probably already broke between each of egcs 1.0 and
egcs 1.1, egcs 1.1 and GCC 2.95, or GCC 2.8 and GCC 2.95.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Mark Mitchell]

>>>>> "Gerald" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

    Gerald> Concerning squangling, I have been testing this on regular
    Gerald> base on sparc-sun-solaris2.6 i386-unknown-freebsdelf3.x
    Gerald> and sometimes also alphaev56-dec-osf4.0d
    Gerald> i386-pc-solaris2.7 without any problems during the last 12
    Gerald> months.

And I on sgi-mips-irix6.5.  Of course, although we don't actually
claim link-compatibility, most new code does link OK with most old
code.  Turning on -fnew-abi will break this in a rather drastic sort
of way. 

In some sense, this is similar to the -fstrict-aliasing debate; should
we strive to preserve compatibility where we can, even if that's not
everywhere, or should we (aggressively) break such compatibility in
the name of progress?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Gerald Pfeifer]

On Fri, 8 Oct 1999, Mike Stump wrote:
> Since we have now proven that we can't maintain compatibility, I think
> it would be wise to turn on -fnew-abi features that are near stable,
> so that we can finish testing and stabilizing them for the next major
> release.  For example -fsquangle is an excellent example.

Actually this was my very first thought after reading Martin's reply! ;-)

Not wanting to break binary compatibility has always been the killer
argument against enabling -fnew-abi or -fsquangle, even though the latter,
for example, would have made the life of a lot of folks much easier.

Concerning squangling, I have been testing this on regular base on
  sparc-sun-solaris2.6
  i386-unknown-freebsdelf3.x
and sometimes also
  alphaev56-dec-osf4.0d
  i386-pc-solaris2.7
without any problems during the last 12 months.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: ABI/compatibility details? (egcs -> gcc 2.95 -> future?)

[Mike Stump]

> Date: Fri, 8 Oct 1999 19:28:20 +0200
> From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>

> I think last time we discussed that, there was some kind of
> agreement *not* to document the ABI differences. Instead, the
> "official" party line is that there is no compatibility whatsoever
> between major compiler versions, and any reports to the contrary are
> pure luck.  [ the context for this was c++ (I hope) ]

Since we have now proven that we can't maintain compatibility, I think
it would be wise to turn on -fnew-abi features that are near stable,
so that we can finish testing and stabilizing them for the next major
release.  For example -fsquangle is an excellent example.

Jason, any plans to start turning this type of stuff on?