C++: STL 3.2

C++: STL 3.2

[Gerald Pfeifer]

STL 3.2 has been release yesterday:
  http://www.sgi.com/Technology/STL/whats_new.html

This missed the "Feature freeze date" by one day, but -- considering the
relatively long life of our release branches and the usually high quality
of SGI STL releases -- may I suggest that we merge that in for 1.2?

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

egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Martin v. Loewis]

> STL 3.2 has been release yesterday:
>   http://www.sgi.com/Technology/STL/whats_new.html

This raises another issue: What is the official position on binary
compatibility between egcs 1.2 and earlier versions, when it comes to
C++?

So far, I have identified two areas:
- STL is incompatible. The allocators all changed, resulting in a different
  default argument to any reasonable standard template, thus breaking
  all mangled names.
- Some changes to exception handling. g++ now emits __start_cp_handler,
  which is not supported in egcs 1.1 libgcc. So, linking 1.2 compiled
  objects with 1.1 doesn't work.

I see a number of options:

a) Leave everything as-is, claiming no compatibility.
b) Leave everything as-is, claiming limited compatibility (like:
   no use of STL, always link with 1.2). If such claim is made,
   it should be valid.
c) Claim stronger compatibility, and make changes to support that
   stronger compat.
d) Claim no compatibility, and activate some new-abi stuff. Squangling
   and the empty bases come to mind, honor-std should wait for the new
   libstdc++.

If people are in favour of a), I'd like to know what's wrong with d).

Regards,
Martin

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Chip Salzenberg]

According to Martin v. Loewis:
> a) Leave everything as-is, claiming no compatibility.
> b) Leave everything as-is, claiming limited compatibility (like:
>    no use of STL, always link with 1.2). If such claim is made,
>    it should be valid.
> c) Claim stronger compatibility, and make changes to support that
>    stronger compat.
> d) Claim no compatibility, and activate some new-abi stuff. Squangling
>    and the empty bases come to mind, honor-std should wait for the new
>    libstdc++.

I vote for (c), for whatever a non-volunteer vote is worth.  Breaking
the ABI is a serious step, and should be done all at once.

... Unless, of course, libstdc++ is going to take too long.
-- 
Chip Salzenberg      - a.k.a. -      <chip@perlsupport.com>
      "When do you work?"   "Whenever I'm not busy."

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Martin v. Loewis]

> > c) Claim stronger compatibility, and make changes to support that
> >    stronger compat.

[...]

> I vote for (c), for whatever a non-volunteer vote is worth.  Breaking
> the ABI is a serious step, and should be done all at once.

Thanks for the input. For the STL incompatibilities, I guess achieving
binary compatibility with 1.1 would be a major project. 


For the libgcc changes, I don't understand exactly what the changes
were, and what kind of compatibility is possible. A command line flag
could activate the old code, if it is still there.

Regards,
Martin

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Chip Salzenberg]

According to Martin v. Loewis:
> For the STL incompatibilities, I guess achieving binary
> compatibility with 1.1 would be a major project.

Yeah, that's not particularly worth trying, IMO.
-- 
Chip Salzenberg      - a.k.a. -      <chip@perlsupport.com>
      "When do you work?"   "Whenever I'm not busy."

Re: C++: STL 3.2

[Jeffrey A Law]

  In message < Pine.GSO.4.10.9904231640040.22202-100000@markab.dbai.tuwien.ac.at
>you write:
  > STL 3.2 has been release yesterday:
  >   http://www.sgi.com/Technology/STL/whats_new.html
  > 
  > This missed the "Feature freeze date" by one day, but -- considering the
  > relatively long life of our release branches and the usually high quality
  > of SGI STL releases -- may I suggest that we merge that in for 1.2?
I'd like either Jason or Mark to make the final decision on this.  I won't
object because it missed the cut-off by one date given the cycle times for
our major releases.

However, I would like to see a summary of what binary compatibility problems we
are likely to have if we update.

jeff

Re: C++: STL 3.2

[Mark Mitchell]

>>>>> "Jeffrey" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

    Jeffrey>   In message
    Jeffrey> < Pine.GSO.4.10.9904231640040.22202-100000@markab.dbai.tuwien.ac.at
    >> you write: STL 3.2 has been release yesterday:
    >> http://www.sgi.com/Technology/STL/whats_new.html
    >> 
    >> This missed the "Feature freeze date" by one day, but --
    >> considering the relatively long life of our release branches
    >> and the usually high quality of SGI STL releases -- may I
    >> suggest that we merge that in for 1.2?

    Jeffrey> I'd like either Jason or Mark to make the final decision
    Jeffrey> on this.  I won't object because it missed the cut-off by
    Jeffrey> one date given the cycle times for our major releases.

My casual opinion is that we probably ought to take the new release,
but leave out the <limits> and <valarray> bits, since <limits> appears
to be SGI-specific, and <valarray> is not what the v3 people are
using, and introducing the SGI version now will give us more
incompatibilities in the future.

    Jeffrey> However, I would like to see a summary of what binary
    Jeffrey> compatibility problems we are likely to have if we
    Jeffrey> update.

We've already got binary incompatibilities, I think. We updated to
3.11 on 1998-09-02, and activated some new features in the STL on
1998-09-03.  That means that if we didn't break link compatibility we
should probably hope we did: even if things link they may or may not
work correctly with code using 1.1.x era STL code.  (It looks to me
like we branched 1.1.x on 1998-06-27, right?)

It *may be* that the 3.11 update in our current sources didn't break
anything, but I don't think we can know that without a careful audit
of what changed.  It's probably safest just to say that 1.2 is not
binary compatible with 1.1.x, and, if possible, *enforce* that.

But, Jason is probably better able to make this kind of policy
decision than I.

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

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Mark Mitchell]

>>>>> "Martin" == Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

    Martin> a) Leave everything as-is, claiming no compatibility.  b)
    Martin> Leave everything as-is, claiming limited compatibility
    Martin> (like: no use of STL, always link with 1.2). If such claim
    Martin> is made, it should be valid.  c) Claim stronger
    Martin> compatibility, and make changes to support that stronger
    Martin> compat.  d) Claim no compatibility, and activate some
    Martin> new-abi stuff. Squangling and the empty bases come to
    Martin> mind, honor-std should wait for the new libstdc++.

    Martin> If people are in favour of a), I'd like to know what's
    Martin> wrong with d).

I think I'm in favor of a).  Your argument for d), given that, is
cute, but a little simplistic.  In particular, the changes you're
proposing just aren't heavily tested and we're at feature-freeze time.
I do think squanling works (I use it on a MIPS machine all the time),
but it just hasn't received the kind of abuse that our default options
have.

Your argument is, perhaps, a better argument for turning on -fnew-abi
by default *after we branch*, IMO.

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

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Gerald Pfeifer]

On Sat, 24 Apr 1999, Mark Mitchell wrote:
>> If people are in favour of a), I'd like to know what's
>> wrong with d).
> I think I'm in favor of a).  Your argument for d), given that, is
> cute, but a little simplistic.  In particular, the changes you're
> proposing just aren't heavily tested and we're at feature-freeze time.
> I do think squanling works (I use it on a MIPS machine all the time),
> but it just hasn't received the kind of abuse that our default options
> have.

I have been regularily using squangling on FreeBSD/386 2.2.7 and 3.1, on
sparc-sun-solaris2.6, and also on alpha-dec-osf4.0, for rather serious
C++ work, without any problem ever.

Considering that
 o a significant amount of bug reports we receive these days concern
   broken assemblers (Sun, DEC,...) that cannot cope with C++/STL long
   symbol names, and
 o (indirectly) requiring GNU as makes egcs more expensive, for the likes
   of Kaveh and myself, who use guest and/or limited accounts for testing,
I would prefer d) iff we will break compatibility anyway.

While our (local) policy for system compilers is rather cautious in
general, we consider squangling stable enough for deployment and have
been patching our installations accordingly for egcs 1.1.x.

Just my 0.02 Groschen,
Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: C++: STL 3.2

[Martin v. Loewis]

> However, I would like to see a summary of what binary compatibility
> problems we are likely to have if we update.

Without looking into detail at the new STL, I think it is a safe guess
that egcs 1.2 will be binary-incompatible with 1.1 for programs using
STL. Our CVS version is already completely incompatible, and it likely
won't get better. The only drawback might be breaking compatibility
with current snapshots.

Regards,
Martin

Re: C++: STL 3.2

[Martin v. Loewis]

> It *may be* that the 3.11 update in our current sources didn't break
> anything, but I don't think we can know that without a careful audit
> of what changed.  It's probably safest just to say that 1.2 is not
> binary compatible with 1.1.x, and, if possible, *enforce* that.

For the CVS, I did a little testing and found that every container
gives a link error. For example, allocating a vector<int> object with
the development branch will emit a call to

_._t6vector2ZiZt9allocator1Z

In the 1.1 branch, the same object will require a call to

_._t6vector2ZiZt24__default_alloc_template2b1i0

Same goes for functions expecting vectors, etc.

Regards,
Martin

Re: C++: STL 3.2

[Gabriel Dos_Reis]

"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:

| > However, I would like to see a summary of what binary compatibility
| > problems we are likely to have if we update.
| 
| Without looking into detail at the new STL, I think it is a safe guess
| that egcs 1.2 will be binary-incompatible with 1.1 for programs using
| STL. Our CVS version is already completely incompatible, and it likely
| won't get better. The only drawback might be breaking compatibility
| with current snapshots.

If so, then I would favor option d). 

-- Gaby

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 > So far, I have identified two areas:
 > - STL is incompatible. The allocators all changed, resulting in a different
 >   default argument to any reasonable standard template, thus breaking
 >   all mangled names.

This is OK; so long as the data structures are similar enough the only harm
would be having two copies of the code in the executable.

 > - Some changes to exception handling. g++ now emits __start_cp_handler,
 >   which is not supported in egcs 1.1 libgcc. So, linking 1.2 compiled
 >   objects with 1.1 doesn't work.

But it is backward compatible.  I don't mind requiring people to use the
newest compiler to link mixed code.

 > a) Leave everything as-is, claiming no compatibility.

This is the way it has always been.  I think this is fine until the new ABI
is actually deployed, which should wait until it's finished -- and I'm
planning to do that this summer.

Jason

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Martin v. Loewis]

> This is OK; so long as the data structures are similar enough the only harm
> would be having two copies of the code in the executable.

It depends on the application. Consider

#include <vector>

extern void foo(vector<int>&);

int main()
{
  vector<int> s;
  foo(s);
}

If foo is implemented in a library, and the library was compiled with
1.1, it cannot be linked with egcs 1.2: The error message would say

/tmp/ccKWdaaa.o(.text+0x4e): undefined reference to `foo(vector<int, allocator<int> > &)

which *will* confuse people who are certain that they implemented foo
Of course, they implemented 
foo(vector<int, __default_alloc_template<true, 0> > &)
instead.

> But it is backward compatible.  I don't mind requiring people to use
> the newest compiler to link mixed code.

Ok. So 1.2 is backwards-compatible in the sense that you can link 1.1
libraries into 1.2 applications, right? (Unless they use STL).

Regards,
Martin

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 >> This is OK; so long as the data structures are similar enough the only
 >> harm would be having two copies of the code in the executable.

 > It depends on the application. Consider

 > extern void foo(vector<int>&);

Ah, yes.

 >> But it is backward compatible.  I don't mind requiring people to use
 >> the newest compiler to link mixed code.

 > Ok. So 1.2 is backwards-compatible in the sense that you can link 1.1
 > libraries into 1.2 applications, right? (Unless they use STL).

Right.

Jason

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Chip Salzenberg]

According to Martin v. Loewis:
> For the STL incompatibilities, I guess achieving binary
> compatibility with 1.1 would be a major project.

Yeah, that's not particularly worth trying, IMO.
-- 
Chip Salzenberg      - a.k.a. -      <chip@perlsupport.com>
      "When do you work?"   "Whenever I'm not busy."

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Chip Salzenberg]

According to Martin v. Loewis:
> a) Leave everything as-is, claiming no compatibility.
> b) Leave everything as-is, claiming limited compatibility (like:
>    no use of STL, always link with 1.2). If such claim is made,
>    it should be valid.
> c) Claim stronger compatibility, and make changes to support that
>    stronger compat.
> d) Claim no compatibility, and activate some new-abi stuff. Squangling
>    and the empty bases come to mind, honor-std should wait for the new
>    libstdc++.

I vote for (c), for whatever a non-volunteer vote is worth.  Breaking
the ABI is a serious step, and should be done all at once.

... Unless, of course, libstdc++ is going to take too long.
-- 
Chip Salzenberg      - a.k.a. -      <chip@perlsupport.com>
      "When do you work?"   "Whenever I'm not busy."

Re: C++: STL 3.2

[Martin v. Loewis]

> However, I would like to see a summary of what binary compatibility
> problems we are likely to have if we update.

Without looking into detail at the new STL, I think it is a safe guess
that egcs 1.2 will be binary-incompatible with 1.1 for programs using
STL. Our CVS version is already completely incompatible, and it likely
won't get better. The only drawback might be breaking compatibility
with current snapshots.

Regards,
Martin

egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Martin v. Loewis]

> STL 3.2 has been release yesterday:
>   http://www.sgi.com/Technology/STL/whats_new.html

This raises another issue: What is the official position on binary
compatibility between egcs 1.2 and earlier versions, when it comes to
C++?

So far, I have identified two areas:
- STL is incompatible. The allocators all changed, resulting in a different
  default argument to any reasonable standard template, thus breaking
  all mangled names.
- Some changes to exception handling. g++ now emits __start_cp_handler,
  which is not supported in egcs 1.1 libgcc. So, linking 1.2 compiled
  objects with 1.1 doesn't work.

I see a number of options:

a) Leave everything as-is, claiming no compatibility.
b) Leave everything as-is, claiming limited compatibility (like:
   no use of STL, always link with 1.2). If such claim is made,
   it should be valid.
c) Claim stronger compatibility, and make changes to support that
   stronger compat.
d) Claim no compatibility, and activate some new-abi stuff. Squangling
   and the empty bases come to mind, honor-std should wait for the new
   libstdc++.

If people are in favour of a), I'd like to know what's wrong with d).

Regards,
Martin

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 >> This is OK; so long as the data structures are similar enough the only
 >> harm would be having two copies of the code in the executable.

 > It depends on the application. Consider

 > extern void foo(vector<int>&);

Ah, yes.

 >> But it is backward compatible.  I don't mind requiring people to use
 >> the newest compiler to link mixed code.

 > Ok. So 1.2 is backwards-compatible in the sense that you can link 1.1
 > libraries into 1.2 applications, right? (Unless they use STL).

Right.

Jason

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Martin v. Loewis]

> > c) Claim stronger compatibility, and make changes to support that
> >    stronger compat.

[...]

> I vote for (c), for whatever a non-volunteer vote is worth.  Breaking
> the ABI is a serious step, and should be done all at once.

Thanks for the input. For the STL incompatibilities, I guess achieving
binary compatibility with 1.1 would be a major project. 


For the libgcc changes, I don't understand exactly what the changes
were, and what kind of compatibility is possible. A command line flag
could activate the old code, if it is still there.

Regards,
Martin

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Mark Mitchell]

>>>>> "Martin" == Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

    Martin> a) Leave everything as-is, claiming no compatibility.  b)
    Martin> Leave everything as-is, claiming limited compatibility
    Martin> (like: no use of STL, always link with 1.2). If such claim
    Martin> is made, it should be valid.  c) Claim stronger
    Martin> compatibility, and make changes to support that stronger
    Martin> compat.  d) Claim no compatibility, and activate some
    Martin> new-abi stuff. Squangling and the empty bases come to
    Martin> mind, honor-std should wait for the new libstdc++.

    Martin> If people are in favour of a), I'd like to know what's
    Martin> wrong with d).

I think I'm in favor of a).  Your argument for d), given that, is
cute, but a little simplistic.  In particular, the changes you're
proposing just aren't heavily tested and we're at feature-freeze time.
I do think squanling works (I use it on a MIPS machine all the time),
but it just hasn't received the kind of abuse that our default options
have.

Your argument is, perhaps, a better argument for turning on -fnew-abi
by default *after we branch*, IMO.

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

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Martin v. Loewis]

> This is OK; so long as the data structures are similar enough the only harm
> would be having two copies of the code in the executable.

It depends on the application. Consider

#include <vector>

extern void foo(vector<int>&);

int main()
{
  vector<int> s;
  foo(s);
}

If foo is implemented in a library, and the library was compiled with
1.1, it cannot be linked with egcs 1.2: The error message would say

/tmp/ccKWdaaa.o(.text+0x4e): undefined reference to `foo(vector<int, allocator<int> > &)

which *will* confuse people who are certain that they implemented foo
Of course, they implemented 
foo(vector<int, __default_alloc_template<true, 0> > &)
instead.

> But it is backward compatible.  I don't mind requiring people to use
> the newest compiler to link mixed code.

Ok. So 1.2 is backwards-compatible in the sense that you can link 1.1
libraries into 1.2 applications, right? (Unless they use STL).

Regards,
Martin

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Jason Merrill]

>>>>> Martin v Loewis <martin@mira.isdn.cs.tu-berlin.de> writes:

 > So far, I have identified two areas:
 > - STL is incompatible. The allocators all changed, resulting in a different
 >   default argument to any reasonable standard template, thus breaking
 >   all mangled names.

This is OK; so long as the data structures are similar enough the only harm
would be having two copies of the code in the executable.

 > - Some changes to exception handling. g++ now emits __start_cp_handler,
 >   which is not supported in egcs 1.1 libgcc. So, linking 1.2 compiled
 >   objects with 1.1 doesn't work.

But it is backward compatible.  I don't mind requiring people to use the
newest compiler to link mixed code.

 > a) Leave everything as-is, claiming no compatibility.

This is the way it has always been.  I think this is fine until the new ABI
is actually deployed, which should wait until it's finished -- and I'm
planning to do that this summer.

Jason

C++: STL 3.2

[Gerald Pfeifer]

STL 3.2 has been release yesterday:
  http://www.sgi.com/Technology/STL/whats_new.html

This missed the "Feature freeze date" by one day, but -- considering the
relatively long life of our release branches and the usually high quality
of SGI STL releases -- may I suggest that we merge that in for 1.2?

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

Re: C++: STL 3.2

[Martin v. Loewis]

> It *may be* that the 3.11 update in our current sources didn't break
> anything, but I don't think we can know that without a careful audit
> of what changed.  It's probably safest just to say that 1.2 is not
> binary compatible with 1.1.x, and, if possible, *enforce* that.

For the CVS, I did a little testing and found that every container
gives a link error. For example, allocating a vector<int> object with
the development branch will emit a call to

_._t6vector2ZiZt9allocator1Z

In the 1.1 branch, the same object will require a call to

_._t6vector2ZiZt24__default_alloc_template2b1i0

Same goes for functions expecting vectors, etc.

Regards,
Martin

Re: C++: STL 3.2

[Jeffrey A Law]

  In message < Pine.GSO.4.10.9904231640040.22202-100000@markab.dbai.tuwien.ac.at
>you write:
  > STL 3.2 has been release yesterday:
  >   http://www.sgi.com/Technology/STL/whats_new.html
  > 
  > This missed the "Feature freeze date" by one day, but -- considering the
  > relatively long life of our release branches and the usually high quality
  > of SGI STL releases -- may I suggest that we merge that in for 1.2?
I'd like either Jason or Mark to make the final decision on this.  I won't
object because it missed the cut-off by one date given the cycle times for
our major releases.

However, I would like to see a summary of what binary compatibility problems we
are likely to have if we update.

jeff

Re: C++: STL 3.2

[Mark Mitchell]

>>>>> "Jeffrey" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

    Jeffrey>   In message
    Jeffrey> < Pine.GSO.4.10.9904231640040.22202-100000@markab.dbai.tuwien.ac.at
    >> you write: STL 3.2 has been release yesterday:
    >> http://www.sgi.com/Technology/STL/whats_new.html
    >> 
    >> This missed the "Feature freeze date" by one day, but --
    >> considering the relatively long life of our release branches
    >> and the usually high quality of SGI STL releases -- may I
    >> suggest that we merge that in for 1.2?

    Jeffrey> I'd like either Jason or Mark to make the final decision
    Jeffrey> on this.  I won't object because it missed the cut-off by
    Jeffrey> one date given the cycle times for our major releases.

My casual opinion is that we probably ought to take the new release,
but leave out the <limits> and <valarray> bits, since <limits> appears
to be SGI-specific, and <valarray> is not what the v3 people are
using, and introducing the SGI version now will give us more
incompatibilities in the future.

    Jeffrey> However, I would like to see a summary of what binary
    Jeffrey> compatibility problems we are likely to have if we
    Jeffrey> update.

We've already got binary incompatibilities, I think. We updated to
3.11 on 1998-09-02, and activated some new features in the STL on
1998-09-03.  That means that if we didn't break link compatibility we
should probably hope we did: even if things link they may or may not
work correctly with code using 1.1.x era STL code.  (It looks to me
like we branched 1.1.x on 1998-06-27, right?)

It *may be* that the 3.11 update in our current sources didn't break
anything, but I don't think we can know that without a careful audit
of what changed.  It's probably safest just to say that 1.2 is not
binary compatible with 1.1.x, and, if possible, *enforce* that.

But, Jason is probably better able to make this kind of policy
decision than I.

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

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Gerald Pfeifer]

On Sat, 24 Apr 1999, Mark Mitchell wrote:
>> If people are in favour of a), I'd like to know what's
>> wrong with d).
> I think I'm in favor of a).  Your argument for d), given that, is
> cute, but a little simplistic.  In particular, the changes you're
> proposing just aren't heavily tested and we're at feature-freeze time.
> I do think squanling works (I use it on a MIPS machine all the time),
> but it just hasn't received the kind of abuse that our default options
> have.

I have been regularily using squangling on FreeBSD/386 2.2.7 and 3.1, on
sparc-sun-solaris2.6, and also on alpha-dec-osf4.0, for rather serious
C++ work, without any problem ever.

Considering that
 o a significant amount of bug reports we receive these days concern
   broken assemblers (Sun, DEC,...) that cannot cope with C++/STL long
   symbol names, and
 o (indirectly) requiring GNU as makes egcs more expensive, for the likes
   of Kaveh and myself, who use guest and/or limited accounts for testing,
I would prefer d) iff we will break compatibility anyway.

While our (local) policy for system compilers is rather cautious in
general, we consider squangling stable enough for deployment and have
been patching our installations accordingly for egcs 1.1.x.

Just my 0.02 Groschen,
Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: C++: STL 3.2

[Gabriel Dos_Reis]

"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:

| > However, I would like to see a summary of what binary compatibility
| > problems we are likely to have if we update.
| 
| Without looking into detail at the new STL, I think it is a safe guess
| that egcs 1.2 will be binary-incompatible with 1.1 for programs using
| STL. Our CVS version is already completely incompatible, and it likely
| won't get better. The only drawback might be breaking compatibility
| with current snapshots.

If so, then I would favor option d). 

-- Gaby

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Ross Smith]

From: Jason Merrill <jason@cygnus.com>
>
> >> But it is backward compatible.  I don't mind requiring people to use
> >> the newest compiler to link mixed code.
>
> > Ok. So 1.2 is backwards-compatible in the sense that you can link 1.1
> > libraries into 1.2 applications, right? (Unless they use STL).
>
>Right.

I'm not sure how much effort is being put into this issue, but there's
a question of perspective that you may wish to keep in mind. (I'm
offering it just as a suggestion. Not being a direct contributor to
EGCS, I'm under no illusions about having any right to an opinion :-) )

A lot of C++ programmers who learned the language in the days when the
ARM or Cfront was the definitive standard still tend to think of the
STL as something new and exotic, that only needs to be brought in
when something really advanced is needed. But those of us who have
picked up the new concepts that come with standard C++ tend to use a
different style, in which the STL is all-pervasive. I can't imagine
writing more than a handful of lines of C++, and certainly not even
the most trivial complete program, without using the STL.

What I'm saying is that, if you're going to the trouble of making EGCS
"backwards-compatible ... unless they use the STL", you may want to
reconsider whether it's worth the effort, because for anyone who uses
a modern style of C++, "it works unless you use the STL" is for all
practical purposes synonymous with "it doesn't work". If you need to
break compatibility on the STL (and I gather you do at this point),
you might as well take the opportunity to break anything else you have
an issue with as well.

--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
    "Perl is the Unix way. 500 million ways of doing the same thing,
    and 500 million monster egos all insisting on their way being
    the Proper way of doing it." -- David Parsons

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Martin v. Loewis]

> If you need to break compatibility on the STL (and I gather you do
> at this point), you might as well take the opportunity to break
> anything else you have an issue with as well.

This was my original view; it now appears that those changes I
suggested to make are not tested in the same way that snapshots are
exposed to real-world code. This would be the reason for not
activating them; it seems that everybody agrees that binary
backwards-compatibility is more or less lost since we updated STL.

Regards,
Martin

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Martin v. Loewis]

> If you need to break compatibility on the STL (and I gather you do
> at this point), you might as well take the opportunity to break
> anything else you have an issue with as well.

This was my original view; it now appears that those changes I
suggested to make are not tested in the same way that snapshots are
exposed to real-world code. This would be the reason for not
activating them; it seems that everybody agrees that binary
backwards-compatibility is more or less lost since we updated STL.

Regards,
Martin

Re: egcs 1.2 C++ ABI (Re: C++: STL 3.2)

[Ross Smith]

From: Jason Merrill <jason@cygnus.com>
>
> >> But it is backward compatible.  I don't mind requiring people to use
> >> the newest compiler to link mixed code.
>
> > Ok. So 1.2 is backwards-compatible in the sense that you can link 1.1
> > libraries into 1.2 applications, right? (Unless they use STL).
>
>Right.

I'm not sure how much effort is being put into this issue, but there's
a question of perspective that you may wish to keep in mind. (I'm
offering it just as a suggestion. Not being a direct contributor to
EGCS, I'm under no illusions about having any right to an opinion :-) )

A lot of C++ programmers who learned the language in the days when the
ARM or Cfront was the definitive standard still tend to think of the
STL as something new and exotic, that only needs to be brought in
when something really advanced is needed. But those of us who have
picked up the new concepts that come with standard C++ tend to use a
different style, in which the STL is all-pervasive. I can't imagine
writing more than a handful of lines of C++, and certainly not even
the most trivial complete program, without using the STL.

What I'm saying is that, if you're going to the trouble of making EGCS
"backwards-compatible ... unless they use the STL", you may want to
reconsider whether it's worth the effort, because for anyone who uses
a modern style of C++, "it works unless you use the STL" is for all
practical purposes synonymous with "it doesn't work". If you need to
break compatibility on the STL (and I gather you do at this point),
you might as well take the opportunity to break anything else you have
an issue with as well.

--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
    "Perl is the Unix way. 500 million ways of doing the same thing,
    and 500 million monster egos all insisting on their way being
    the Proper way of doing it." -- David Parsons