This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: HPUX C++ ABI
- From: Mark Mitchell <mark at codesourcery dot com>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, "jessica at cup dot hp dot com" <jessica at cup dot hp dot com>, "sje at cup dot hp dot com" <sje at cup dot hp dot com>
- Date: Thu, 12 Sep 2002 11:50:35 -0700
- Subject: Re: HPUX C++ ABI
--On Thursday, September 12, 2002 02:40:59 PM -0400 David Edelsohn
<dje@watson.ibm.com> wrote:
Mark Mitchell writes:
Mark> That is the point of my statement above; this hypothetical is
uninteresting Mark> because there are no such vendors -- and there aren't
likely to be any in Mark> the near future.
You stripped out an important sentence of my response in your
quote:
"This seems to unfairly prefer one set of compiler vendors over another."
It is unfair to say that GCC will make this accomodation only for
the C++ ABI and only for a vendor whose own C++ ABI happens to be similar
to G++'s ABI. Defining the rules so that it only encompasses this one
case creates a bias in GCC development.
Implementing some very different ABI (such as the aCC ABI on HPPA, or
the G++ ABI before 3.0) would be very hard to do in a way that does not
add significant complexity to the compiler. I believe that such a change
would pose serious risks to our primary ABI.
That said, if you can implement Sun's ABI, or EDG's ABI, or IBM's ABI
in G++ in a way that doesn't pose those problems, I think that would be
just fine. Just because I think it's impossible doesn't it make it so;
maybe there is something clever you could do to make it safe and simple.
I agree with your sentence, except for the "unfair". It's not unfair
to take into account the effects of proposed patches on the
maintainability and stability of the compiler.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com