Re: C++ ABI Issues

[Joe Buck <Joe.Buck@synopsys.com>]

David Edelsohn writes:

> 	As was discussed during the GCC 3.2 transition, my personal
> opinion is that GCC needs a binary -fabi-correctly switch which defaults
> to *OFF*.  We maintain the GCC 3.2 ABI until a well-defined transition
> point in the future when the switch is changed to default to *ON*.

I would be satisfied with this approach, though we could probably come up
with a better choice of option names.  After all, we can never be certain
that we are correct.  All we can do is have two modes: 3.2 compatibility,
and 3.2 plus any ABI corrections found to date.

Maybe the flag should be -fabi-gcc-3.2 .  If true, we are compatible with
GCC 3.2; if false, we include as many bug fixes as we have to ABI conformance
at the time.  It would be true by default until we have reasonable
confidence that we've converged, and I think we need six months to achieve
such confidence, assuming that we do some rigorous testing in that time.

>  This
> allows GCC stability for the time being and interoperability with
> proprietary compilers outside the GNU/Linux and *BSD environments.
> Propritary compilers which run on GNU/Linux will probably have a GCC
> compatibility switch.

You are pretty much saying what I said; I suspect that we would only
differ on details of timing.

> 	The important points are that we make such a decision for GCC
> stability and we have a plan for eventually becoming conformant.  GCC 3.2
> may be a transient ABI, but it should not become a GNU/Linux
> counter-proposal to the C++ABI which it was trying to implement.  Also, we
> should develop a transition plan, as opposed to "we'll switch the option
> in some future release when it seems convenient."

To have a reasonable chance of catching nearly all the ABI bugs, we're
probably going to need at least six months.  What this will mean, assuming
that Red Hat 8, Debian, FreeBSD, and SuSE all adopt 3.2 is that 3.2 will
be a de-facto standard ABI.  The effect of this can be minimized if we
provide warnings at points where there is a known error in 3.2's ABI
conformance and encourage distributors to avoid such coding in any C++
libraries (if a "hit" does occur, it's easy to make it go away by adding a
dummy field that fills in the empty space in the base class's padding).
If this can be done, then an eventual switch to a compiler that does
correct ABI will not cause compatibility problems, because code that could
trigger compatibility problems would be avoided.

By the way, I'd be eager to hear from the decision-makers for the
distributions on what their opinions are on this one.  It's important
to achieve some consensus on this.

Next question is whether the ABI errors affect KDE (the largest collection
of free C++ library code that distributors will have to deal with).  Once
we have a patch that flags ABI violations, I'd appreciate it if some
volunteer will build KDE with it and report on whether we get any hits.

> 	We shouldn't make GCC arbitrarily compatible with Intel's
> compiler, and we aren't.  Similarly, we should not ask Intel or HP or any
> other proprietary compiler to be arbitrarily compatible with GCC.  It cuts
> both ways.  GCC should avoid any appearance of making arbitrary changes to
> standards and forcing others to play catch-up.

I don't disagree, but I don't want to rush out a correction.

Once we have consensus on how to proceed, I think that we should announce
the decision and any recommendations and publicize them widely.