-fnew-abi and branching

-fnew-abi and branching

[Mark Mitchell]

Folks --

  In private email, Jason suggested that doing the -fnew-abi
development (i.e., the parts that belong to the compiler, not the bits
we discussed regarding libio) need not be done on a branch.
 
  In particular, Jason opined that it would be fine to leave the
compiler and libio out of sync on the mainline -- provided that only
without -fnew-abi everything continued to move smoothly.

  So, his suggestion was:

  o Leave libio alone.
  o Do -fnew-abi development on the mainline.

This will leave the mainline -fnew-abi compiler "broken" in that
programs using libio won't work correctly, but it will avoid
divergence in the compiler.  And, since -fnew-abi is an unsupported
option, there's really nothing for anyone to complain about.

  Are there any objections to this proposal? 

  (It's possible that Jeff suggested this in one of his emails as
well; it wasn't clear to me at the time.)

  If I don't hear objections in the next day or so, I'll merge the
changes from the branch into the mainline.

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

Re: -fnew-abi and branching

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Folks --
| 
|   In private email, Jason suggested that doing the -fnew-abi
| development (i.e., the parts that belong to the compiler, not the bits
| we discussed regarding libio) need not be done on a branch.
|  
|   In particular, Jason opined that it would be fine to leave the
| compiler and libio out of sync on the mainline -- provided that only
| without -fnew-abi everything continued to move smoothly.
| 
|   So, his suggestion was:
| 
|   o Leave libio alone.
|   o Do -fnew-abi development on the mainline.
| 
| This will leave the mainline -fnew-abi compiler "broken" in that
| programs using libio won't work correctly, but it will avoid
| divergence in the compiler.  And, since -fnew-abi is an unsupported
| option, there's really nothing for anyone to complain about.
| 
|   Are there any objections to this proposal? 
| 
|   (It's possible that Jeff suggested this in one of his emails as
| well; it wasn't clear to me at the time.)
| 
|   If I don't hear objections in the next day or so, I'll merge the
| changes from the branch into the mainline.

On libstdc++-v3, we recommend testing '-fnew-abi' and we're planning to
make it the default.  Unless I'm mistaken, the new ABI experiment means
"official libio" and "EGCS libio" would go out of sync.  Am I right?
If so, I'd like we come up with a solution that makes it possible for
us (on libstdc++-v3) to continue to test -fnew-abi on v-3 without
breaking everything. 

Thanks,

-- Gaby

Re: -fnew-abi and branching

[Mark Mitchell]

>>>>> "Gabriel" == Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr> writes:

    Gabriel> On libstdc++-v3, we recommend testing '-fnew-abi' and
    Gabriel> we're planning to make it the default.  Unless I'm
    Gabriel> mistaken, the new ABI experiment means "official libio"
    Gabriel> and "EGCS libio" would go out of sync.  Am I right?  If

No.  Nobody's going to touch libio.

But, since libio depends on C++ object layout, it will stop working
when the ABI changes.  Someone (presumably the glibc/libstdc++ people)
will have to work out how to adjust libio to work with the new ABI.
You might as well see the breakage as soon as possible. :-)

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

Re: -fnew-abi and branching

[Benjamin Kosnik]

> |   In private email, Jason suggested that doing the -fnew-abi
> | development (i.e., the parts that belong to the compiler, not the bits
> | we discussed regarding libio) need not be done on a branch.

I am also in favor of this.

> |   In particular, Jason opined that it would be fine to leave the
> | compiler and libio out of sync on the mainline -- provided that only
> | without -fnew-abi everything continued to move smoothly.

Will -fhonor-std still work? That's the flag that most concerns me, and I
suspect that it is not going to be affected. Since -fnew-abi turns on a
bunch of things, perhaps you can elaborate on what flags will and will not
work (ie, I suspect -fvtable-thunks will break, but that -fsquangle will
not really change due to the new ABI).
 

> | This will leave the mainline -fnew-abi compiler "broken" in that
> | programs using libio won't work correctly, but it will avoid
> | divergence in the compiler.  And, since -fnew-abi is an unsupported
> | option, there's really nothing for anyone to complain about.
> 
> On libstdc++-v3, we recommend testing '-fnew-abi' and we're planning to
> make it the default.  Unless I'm mistaken, the new ABI experiment means
> "official libio" and "EGCS libio" would go out of sync.  Am I right?
> If so, I'd like we come up with a solution that makes it possible for
> us (on libstdc++-v3) to continue to test -fnew-abi on v-3 without
> breaking everything. 

v3, glibc, and egcs all have different versions of libio anyway. Perhaps
we could take this opportunity to synch them? I'd rather do the
experimental work on libio in v3, with Uli's approval and help, then muck
around in the egcs version. 

Again, as long as -fsquangle -fhonor-std work, I don't think it's a big
deal. People can always use gcc-2.95.2. . . I don't see how this can be
helped.

-benjamin

Re: -fnew-abi and branching

[Jeffrey A Law]

  In message < Pine.LNX.4.10.9912290931120.18053-100000@fidel.cygnus.com >you wri
te:
  > > |   In private email, Jason suggested that doing the -fnew-abi
  > > | development (i.e., the parts that belong to the compiler, not the bits
  > > | we discussed regarding libio) need not be done on a branch.
  > 
  > I am also in favor of this.
Seems reasonable to me if it's easier for y'all.


  > > On libstdc++-v3, we recommend testing '-fnew-abi' and we're planning to
  > > make it the default.  Unless I'm mistaken, the new ABI experiment means
  > > "official libio" and "EGCS libio" would go out of sync.  Am I right?
  > > If so, I'd like we come up with a solution that makes it possible for
  > > us (on libstdc++-v3) to continue to test -fnew-abi on v-3 without
  > > breaking everything. 
  > 
  > v3, glibc, and egcs all have different versions of libio anyway. Perhaps
  > we could take this opportunity to synch them? I'd rather do the
  > experimental work on libio in v3, with Uli's approval and help, then muck
  > around in the egcs version. 
This definitely needs to be fixed and soon.  Based on previous experience
we do not want 3 divergent libio implementations.  In fact, I'm rather
disturbed to find that glibc & egcs have diverged -- that should not be
happening.

jeff

Re: -fnew-abi and branching

[Mark Mitchell]

>>>>> "Benjamin" == Benjamin Kosnik <bkoz@fidel.cygnus.com> writes:

    >> | In private email, Jason suggested that doing the -fnew-abi |
    >> development (i.e., the parts that belong to the compiler, not
    >> the bits | we discussed regarding libio) need not be done on a
    >> branch.

    Benjamin> I am also in favor of this.

Great.  Since Jeff has also approved this idea, I think we've got a
quorum.

    Benjamin> Will -fhonor-std still work? That's the flag that most

Yes.

    Benjamin> concerns me, and I suspect that it is not going to be
    Benjamin> affected. Since -fnew-abi turns on a bunch of things,
    Benjamin> perhaps you can elaborate on what flags will and will
    Benjamin> not work (ie, I suspect -fvtable-thunks will break, but
    Benjamin> that -fsquangle will not really change due to the new
    Benjamin> ABI).
 
Right.  Although the new ABI will specify a mangling scheme.  I
suspect that we'll just implement it "from scratch" since the current
mangling code is a disaster.  We really want to get the mangling
"right" according to the spec.  That means we can decide later whether
to support mangling, squangling, and the new scheme -- or just some
some subset of the three.

In the short run, location of vtbl pointers will change.  Location of
base classes will change.  Vtable layout will change.  Virtual base
pointers will be eliminated.

Then, some run-time library changes will occur -- but in the part of
the library that comes with EGCS.  Things like RTTI and
exception-handling.

    Benjamin> Again, as long as -fsquangle -fhonor-std work, I don't
    Benjamin> think it's a big deal. People can always use
    Benjamin> gcc-2.95.2. . . I don't see how this can be helped.

Me neither.  I'm glad you agree.

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

Re: -fnew-abi and branching

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

|     Benjamin> concerns me, and I suspect that it is not going to be
|     Benjamin> affected. Since -fnew-abi turns on a bunch of things,
|     Benjamin> perhaps you can elaborate on what flags will and will
|     Benjamin> not work (ie, I suspect -fvtable-thunks will break, but
|     Benjamin> that -fsquangle will not really change due to the new
|     Benjamin> ABI).
|  
| Right.  Although the new ABI will specify a mangling scheme.  I
| suspect that we'll just implement it "from scratch" since the current
| mangling code is a disaster.  We really want to get the mangling
| "right" according to the spec.  That means we can decide later whether
| to support mangling, squangling, and the new scheme -- or just some
| some subset of the three.
| 
| In the short run, location of vtbl pointers will change.  Location of
| base classes will change.  Vtable layout will change.  Virtual base
| pointers will be eliminated.
| 
| Then, some run-time library changes will occur -- but in the part of
| the library that comes with EGCS.  Things like RTTI and
| exception-handling.

OK with me.

Please, when you think that some "major" changes will affect some
run-time library (especially as far as v3 is concerned) could you ping
the libstdc++-v3 list?  This is for documentation purpose...

Thanks,

-- Gaby

Re: -fnew-abi and branching

[Tom Tromey]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

Mark> Right.  Although the new ABI will specify a mangling scheme.  I
Mark> suspect that we'll just implement it "from scratch" since the
Mark> current mangling code is a disaster.

This would be a good time to centralize the mangling code so that it
can be shared by C++ and Java.

Tom

Re: -fnew-abi and branching

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

|     Benjamin> concerns me, and I suspect that it is not going to be
|     Benjamin> affected. Since -fnew-abi turns on a bunch of things,
|     Benjamin> perhaps you can elaborate on what flags will and will
|     Benjamin> not work (ie, I suspect -fvtable-thunks will break, but
|     Benjamin> that -fsquangle will not really change due to the new
|     Benjamin> ABI).
|  
| Right.  Although the new ABI will specify a mangling scheme.  I
| suspect that we'll just implement it "from scratch" since the current
| mangling code is a disaster.  We really want to get the mangling
| "right" according to the spec.  That means we can decide later whether
| to support mangling, squangling, and the new scheme -- or just some
| some subset of the three.
| 
| In the short run, location of vtbl pointers will change.  Location of
| base classes will change.  Vtable layout will change.  Virtual base
| pointers will be eliminated.
| 
| Then, some run-time library changes will occur -- but in the part of
| the library that comes with EGCS.  Things like RTTI and
| exception-handling.

OK with me.

Please, when you think that some "major" changes will affect some
run-time library (especially as far as v3 is concerned) could you ping
the libstdc++-v3 list?  This is for documentation purpose...

Thanks,

-- Gaby

Re: -fnew-abi and branching

[Tom Tromey]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

Mark> Right.  Although the new ABI will specify a mangling scheme.  I
Mark> suspect that we'll just implement it "from scratch" since the
Mark> current mangling code is a disaster.

This would be a good time to centralize the mangling code so that it
can be shared by C++ and Java.

Tom

Re: -fnew-abi and branching

[Mark Mitchell]

>>>>> "Benjamin" == Benjamin Kosnik <bkoz@fidel.cygnus.com> writes:

    >> | In private email, Jason suggested that doing the -fnew-abi |
    >> development (i.e., the parts that belong to the compiler, not
    >> the bits | we discussed regarding libio) need not be done on a
    >> branch.

    Benjamin> I am also in favor of this.

Great.  Since Jeff has also approved this idea, I think we've got a
quorum.

    Benjamin> Will -fhonor-std still work? That's the flag that most

Yes.

    Benjamin> concerns me, and I suspect that it is not going to be
    Benjamin> affected. Since -fnew-abi turns on a bunch of things,
    Benjamin> perhaps you can elaborate on what flags will and will
    Benjamin> not work (ie, I suspect -fvtable-thunks will break, but
    Benjamin> that -fsquangle will not really change due to the new
    Benjamin> ABI).
 
Right.  Although the new ABI will specify a mangling scheme.  I
suspect that we'll just implement it "from scratch" since the current
mangling code is a disaster.  We really want to get the mangling
"right" according to the spec.  That means we can decide later whether
to support mangling, squangling, and the new scheme -- or just some
some subset of the three.

In the short run, location of vtbl pointers will change.  Location of
base classes will change.  Vtable layout will change.  Virtual base
pointers will be eliminated.

Then, some run-time library changes will occur -- but in the part of
the library that comes with EGCS.  Things like RTTI and
exception-handling.

    Benjamin> Again, as long as -fsquangle -fhonor-std work, I don't
    Benjamin> think it's a big deal. People can always use
    Benjamin> gcc-2.95.2. . . I don't see how this can be helped.

Me neither.  I'm glad you agree.

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

Re: -fnew-abi and branching

[Benjamin Kosnik]

> |   In private email, Jason suggested that doing the -fnew-abi
> | development (i.e., the parts that belong to the compiler, not the bits
> | we discussed regarding libio) need not be done on a branch.

I am also in favor of this.

> |   In particular, Jason opined that it would be fine to leave the
> | compiler and libio out of sync on the mainline -- provided that only
> | without -fnew-abi everything continued to move smoothly.

Will -fhonor-std still work? That's the flag that most concerns me, and I
suspect that it is not going to be affected. Since -fnew-abi turns on a
bunch of things, perhaps you can elaborate on what flags will and will not
work (ie, I suspect -fvtable-thunks will break, but that -fsquangle will
not really change due to the new ABI).
 

> | This will leave the mainline -fnew-abi compiler "broken" in that
> | programs using libio won't work correctly, but it will avoid
> | divergence in the compiler.  And, since -fnew-abi is an unsupported
> | option, there's really nothing for anyone to complain about.
> 
> On libstdc++-v3, we recommend testing '-fnew-abi' and we're planning to
> make it the default.  Unless I'm mistaken, the new ABI experiment means
> "official libio" and "EGCS libio" would go out of sync.  Am I right?
> If so, I'd like we come up with a solution that makes it possible for
> us (on libstdc++-v3) to continue to test -fnew-abi on v-3 without
> breaking everything. 

v3, glibc, and egcs all have different versions of libio anyway. Perhaps
we could take this opportunity to synch them? I'd rather do the
experimental work on libio in v3, with Uli's approval and help, then muck
around in the egcs version. 

Again, as long as -fsquangle -fhonor-std work, I don't think it's a big
deal. People can always use gcc-2.95.2. . . I don't see how this can be
helped.

-benjamin

Re: -fnew-abi and branching

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Folks --
| 
|   In private email, Jason suggested that doing the -fnew-abi
| development (i.e., the parts that belong to the compiler, not the bits
| we discussed regarding libio) need not be done on a branch.
|  
|   In particular, Jason opined that it would be fine to leave the
| compiler and libio out of sync on the mainline -- provided that only
| without -fnew-abi everything continued to move smoothly.
| 
|   So, his suggestion was:
| 
|   o Leave libio alone.
|   o Do -fnew-abi development on the mainline.
| 
| This will leave the mainline -fnew-abi compiler "broken" in that
| programs using libio won't work correctly, but it will avoid
| divergence in the compiler.  And, since -fnew-abi is an unsupported
| option, there's really nothing for anyone to complain about.
| 
|   Are there any objections to this proposal? 
| 
|   (It's possible that Jeff suggested this in one of his emails as
| well; it wasn't clear to me at the time.)
| 
|   If I don't hear objections in the next day or so, I'll merge the
| changes from the branch into the mainline.

On libstdc++-v3, we recommend testing '-fnew-abi' and we're planning to
make it the default.  Unless I'm mistaken, the new ABI experiment means
"official libio" and "EGCS libio" would go out of sync.  Am I right?
If so, I'd like we come up with a solution that makes it possible for
us (on libstdc++-v3) to continue to test -fnew-abi on v-3 without
breaking everything. 

Thanks,

-- Gaby

Re: -fnew-abi and branching

[Jeffrey A Law]

  In message < Pine.LNX.4.10.9912290931120.18053-100000@fidel.cygnus.com >you wri
te:
  > > |   In private email, Jason suggested that doing the -fnew-abi
  > > | development (i.e., the parts that belong to the compiler, not the bits
  > > | we discussed regarding libio) need not be done on a branch.
  > 
  > I am also in favor of this.
Seems reasonable to me if it's easier for y'all.


  > > On libstdc++-v3, we recommend testing '-fnew-abi' and we're planning to
  > > make it the default.  Unless I'm mistaken, the new ABI experiment means
  > > "official libio" and "EGCS libio" would go out of sync.  Am I right?
  > > If so, I'd like we come up with a solution that makes it possible for
  > > us (on libstdc++-v3) to continue to test -fnew-abi on v-3 without
  > > breaking everything. 
  > 
  > v3, glibc, and egcs all have different versions of libio anyway. Perhaps
  > we could take this opportunity to synch them? I'd rather do the
  > experimental work on libio in v3, with Uli's approval and help, then muck
  > around in the egcs version. 
This definitely needs to be fixed and soon.  Based on previous experience
we do not want 3 divergent libio implementations.  In fact, I'm rather
disturbed to find that glibc & egcs have diverged -- that should not be
happening.

jeff

-fnew-abi and branching

[Mark Mitchell]

Folks --

  In private email, Jason suggested that doing the -fnew-abi
development (i.e., the parts that belong to the compiler, not the bits
we discussed regarding libio) need not be done on a branch.
 
  In particular, Jason opined that it would be fine to leave the
compiler and libio out of sync on the mainline -- provided that only
without -fnew-abi everything continued to move smoothly.

  So, his suggestion was:

  o Leave libio alone.
  o Do -fnew-abi development on the mainline.

This will leave the mainline -fnew-abi compiler "broken" in that
programs using libio won't work correctly, but it will avoid
divergence in the compiler.  And, since -fnew-abi is an unsupported
option, there's really nothing for anyone to complain about.

  Are there any objections to this proposal? 

  (It's possible that Jeff suggested this in one of his emails as
well; it wasn't clear to me at the time.)

  If I don't hear objections in the next day or so, I'll merge the
changes from the branch into the mainline.

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

Re: -fnew-abi and branching

[Mark Mitchell]

>>>>> "Gabriel" == Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr> writes:

    Gabriel> On libstdc++-v3, we recommend testing '-fnew-abi' and
    Gabriel> we're planning to make it the default.  Unless I'm
    Gabriel> mistaken, the new ABI experiment means "official libio"
    Gabriel> and "EGCS libio" would go out of sync.  Am I right?  If

No.  Nobody's going to touch libio.

But, since libio depends on C++ object layout, it will stop working
when the ABI changes.  Someone (presumably the glibc/libstdc++ people)
will have to work out how to adjust libio to work with the new ABI.
You might as well see the breakage as soon as possible. :-)

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

Re: -fnew-abi and branching

[Phil Edwards]

[ sent just to gcc (times like this make me wish for working newsgroups :-) ]

> Right.  Although the new ABI will specify a mangling scheme.  I
> suspect that we'll just implement it "from scratch" since the current
> mangling code is a disaster.  We really want to get the mangling
> "right" according to the spec.  That means we can decide later whether
> to support mangling, squangling, and the new scheme -- or just some
> some subset of the three.

For those of us not intimately involved in the ABI issues, is there some
online resource (web or otherwise) describing the working spec?  I've tried
to reassure others that something like this is in the works, but for their
sake and my curiosity, some kind of reference point would be wonderful.


(If you reply to the list, please don't cc another copy to me.  Thanks!)
Phil

Re: -fnew-abi and branching

[Phil Edwards]

[ sent just to gcc (times like this make me wish for working newsgroups :-) ]

> Right.  Although the new ABI will specify a mangling scheme.  I
> suspect that we'll just implement it "from scratch" since the current
> mangling code is a disaster.  We really want to get the mangling
> "right" according to the spec.  That means we can decide later whether
> to support mangling, squangling, and the new scheme -- or just some
> some subset of the three.

For those of us not intimately involved in the ABI issues, is there some
online resource (web or otherwise) describing the working spec?  I've tried
to reassure others that something like this is in the works, but for their
sake and my curiosity, some kind of reference point would be wonderful.


(If you reply to the list, please don't cc another copy to me.  Thanks!)
Phil