Re: C++: STL 3.2

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]

>>>>> "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 and egcs 1.2

[Jason Merrill]

I would guess that the data structures are actually still compatible,
except where the names have changed, in which case we don't need to do
anything.

I'm in favor of updating to 3.2 and including Gaby's valarray, but it's
actually Ulrich's call.

Jason

Re: C++: STL 3.2 and egcs 1.2

[Mark Mitchell]

>>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes:

    Jason> I would guess that the data structures are actually still
    Jason> compatible, except where the names have changed, in which
    Jason> case we don't need to do anything.

Aren't the allocators different?  But aren't they still called
std::allocator?  Oh, well, we'll let Ulrich sort it out...

-- 
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]

>>>>> "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

[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 and egcs 1.2

[Jason Merrill]

I would guess that the data structures are actually still compatible,
except where the names have changed, in which case we don't need to do
anything.

I'm in favor of updating to 3.2 and including Gaby's valarray, but it's
actually Ulrich's call.

Jason

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 and egcs 1.2

[Mark Mitchell]

>>>>> "Jason" == Jason Merrill <jason@cygnus.com> writes:

    Jason> I would guess that the data structures are actually still
    Jason> compatible, except where the names have changed, in which
    Jason> case we don't need to do anything.

Aren't the allocators different?  But aren't they still called
std::allocator?  Oh, well, we'll let Ulrich sort it out...

-- 
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

[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

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: 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

[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

[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

[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

[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: 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

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/