Re: C++ ABI Issues

[David Edelsohn <dje at watson dot ibm dot com>]

	All compilers have bugs.  We already know of an ABI mistake in one
of the proprietary compilers which GCC did get right.  The issue is not
whose compiler is better or who has less bugs, it is how GCC addresses ABI
conformance problems, such as the one Mark discovered.

	We need to find a balance between internal GCC stability from
release to release and conformance to external standards.

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

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

	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.

David