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: C++: STL 3.2

[Mark Mitchell]

>>>>> "Philipp" == Philipp Thomas <kthomas@gwdg.de> writes:

    Philipp> On Mon, 26 Apr 1999 12:04:22 -0700, you wrote:

    >> We worked very hard to make these "sloppy" so that the kinds of
    >> differences people don't care about didn't get flagged, unless
    >> you were in a "pedantic" mode.  Fun stuff, would be nice to
    >> have in GCC someday.

    Philipp> I agree that this sounds fun, but this task would be up
    Philipp> to the binutils folks, no ?

Not entirely.  You need cooperation both from the compiler and the
linker.  (In our implementation, a separate prelinker was run, so we
only needed help from the compiler.  In fact, we didn't even need that;
we just put stuff directly in the object-file after the compiler ran.) 
But, in GNU-land, it would make sense to have the compiler insert the
ODR records and have the linker check them.

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

Re: C++: STL 3.2

[Philipp Thomas]

On Mon, 26 Apr 1999 12:04:22 -0700, you wrote:

>We worked very hard to make these "sloppy" so that the kinds of
>differences people don't care about didn't get flagged, unless you
>were in a "pedantic" mode.  Fun stuff, would be nice to have in GCC
>someday.

I agree that this sounds fun, but this task would be up to the binutils folks,
no ?


Philipp Thomas

-- 
caffeine low .... brain halted

Re: C++: STL 3.2

[Mark Mitchell]

>>>>> "Mike" == Mike Stump <mrs@wrs.com> writes:

    Mike> Enforce?  This is called being binary incompatibly
    Mike> gratuitously.  I am not sure I am for this.  What if a poor
    Mike> sole is using it like a C compiler, and expects binary
    Mike> compatibility (reasonably so), and we brake it, net result,
    Mike> he isn't happy.  We never have done this, and I propose we
    Mike> never do.

I didn't mean for C, I meant for C++.  It's a bad thing to
"accidentally" allow code to link if it's not really
binary-compatible.  For example, we ideally old STL code wouldn't link
with new STL code; we know that the data structures are incompatible
so we don't want this to happen.  Better to find it at link-time than
at run-time.

At CenterLine, we actually built a system that would diagnose ODR
violations (which is essentially the problem here; the STL
incompatibility is not of of object-file format, object layout, or the
like, but rather of an incompatible change in a standard library).  At
link-time, the linker would complain about such things (like an inline
function used in two translation units with different definitions).

We worked very hard to make these "sloppy" so that the kinds of
differences people don't care about didn't get flagged, unless you
were in a "pedantic" mode.  Fun stuff, would be nice to have in GCC
someday.

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

Re: C++: STL 3.2

[Mike Stump]

> Date: Sat, 24 Apr 1999 23:14:34 -0700
> From: Mark Mitchell <mark@codesourcery.com>

> We've already got binary incompatibilities, I think.

Yes, usually there are.  Only if you methodically test it often and in
great detail, can one get binary compatibility.  In the absence of
such work, we generally get binary incompatibility.  Now, how good it
complete binary compatibility except for these random 3 things?
Usually, not good enough.  Net result, we generally never offer binary
compatibility, and just wanting it is not enough.

> It's probably safest just to say that 1.2 is not binary compatible
> with 1.1.x, and, if possible, *enforce* that.

Enforce?  This is called being binary incompatibly gratuitously.  I am
not sure I am for this.  What if a poor sole is using it like a C
compiler, and expects binary compatibility (reasonably so), and we
brake it, net result, he isn't happy.  We never have done this, and I
propose we never do.


Now, what should we do, ask folks that want binary compatibility for
there test results that prove existing compatibility, or failing that,
add in the new SGI stuff, and say that 1.2 isn't generally speaking
compatible.  If we go the later route, it is a shame that we haven't
been building and testing with all the new ABI breaking things, as we
then might as well turn them all on.

I'd be curious to hear what Brendan and Jason think, and if there are
any folks that have been testing binary compatibility and what they
have done.  I have seen little to no announcement of such work here,
as I recall.

Re: C++: STL 3.2

[Mark Mitchell]

>>>>> "Philipp" == Philipp Thomas <kthomas@gwdg.de> writes:

    Philipp> On Mon, 26 Apr 1999 12:04:22 -0700, you wrote:

    >> We worked very hard to make these "sloppy" so that the kinds of
    >> differences people don't care about didn't get flagged, unless
    >> you were in a "pedantic" mode.  Fun stuff, would be nice to
    >> have in GCC someday.

    Philipp> I agree that this sounds fun, but this task would be up
    Philipp> to the binutils folks, no ?

Not entirely.  You need cooperation both from the compiler and the
linker.  (In our implementation, a separate prelinker was run, so we
only needed help from the compiler.  In fact, we didn't even need that;
we just put stuff directly in the object-file after the compiler ran.) 
But, in GNU-land, it would make sense to have the compiler insert the
ODR records and have the linker check them.

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

Re: C++: STL 3.2

[Philipp Thomas]

On Mon, 26 Apr 1999 12:04:22 -0700, you wrote:

>We worked very hard to make these "sloppy" so that the kinds of
>differences people don't care about didn't get flagged, unless you
>were in a "pedantic" mode.  Fun stuff, would be nice to have in GCC
>someday.

I agree that this sounds fun, but this task would be up to the binutils folks,
no ?


Philipp Thomas

-- 
caffeine low .... brain halted

Re: C++: STL 3.2

[Mark Mitchell]

>>>>> "Mike" == Mike Stump <mrs@wrs.com> writes:

    Mike> Enforce?  This is called being binary incompatibly
    Mike> gratuitously.  I am not sure I am for this.  What if a poor
    Mike> sole is using it like a C compiler, and expects binary
    Mike> compatibility (reasonably so), and we brake it, net result,
    Mike> he isn't happy.  We never have done this, and I propose we
    Mike> never do.

I didn't mean for C, I meant for C++.  It's a bad thing to
"accidentally" allow code to link if it's not really
binary-compatible.  For example, we ideally old STL code wouldn't link
with new STL code; we know that the data structures are incompatible
so we don't want this to happen.  Better to find it at link-time than
at run-time.

At CenterLine, we actually built a system that would diagnose ODR
violations (which is essentially the problem here; the STL
incompatibility is not of of object-file format, object layout, or the
like, but rather of an incompatible change in a standard library).  At
link-time, the linker would complain about such things (like an inline
function used in two translation units with different definitions).

We worked very hard to make these "sloppy" so that the kinds of
differences people don't care about didn't get flagged, unless you
were in a "pedantic" mode.  Fun stuff, would be nice to have in GCC
someday.

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

Re: C++: STL 3.2

[Mike Stump]

> Date: Sat, 24 Apr 1999 23:14:34 -0700
> From: Mark Mitchell <mark@codesourcery.com>

> We've already got binary incompatibilities, I think.

Yes, usually there are.  Only if you methodically test it often and in
great detail, can one get binary compatibility.  In the absence of
such work, we generally get binary incompatibility.  Now, how good it
complete binary compatibility except for these random 3 things?
Usually, not good enough.  Net result, we generally never offer binary
compatibility, and just wanting it is not enough.

> It's probably safest just to say that 1.2 is not binary compatible
> with 1.1.x, and, if possible, *enforce* that.

Enforce?  This is called being binary incompatibly gratuitously.  I am
not sure I am for this.  What if a poor sole is using it like a C
compiler, and expects binary compatibility (reasonably so), and we
brake it, net result, he isn't happy.  We never have done this, and I
propose we never do.


Now, what should we do, ask folks that want binary compatibility for
there test results that prove existing compatibility, or failing that,
add in the new SGI stuff, and say that 1.2 isn't generally speaking
compatible.  If we go the later route, it is a shame that we haven't
been building and testing with all the new ABI breaking things, as we
then might as well turn them all on.

I'd be curious to hear what Brendan and Jason think, and if there are
any folks that have been testing binary compatibility and what they
have done.  I have seen little to no announcement of such work here,
as I recall.