Re: -fnew-abi and branching

[Benjamin Kosnik <bkoz at fidel dot cygnus dot com>]

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