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:28:42 -0700
- Subject: Re: HPUX C++ ABI
--On Thursday, September 12, 2002 02:15:10 PM -0400 David Edelsohn
<dje@watson.ibm.com> wrote:
Mark Mitchell writes:
Mark> There is a slippery slope argument that "everyone else will want us
to Mark> support there variant of the ABI too". But, there is no
everyone else; Mark> HP is the only vendor with an installed base that
does not feel they Mark> can make changes to their ABI.
I think this is a bad precedent unless we really want to open the
doors for compatibility patches from every other compiler vendor. Are we
going to allow patches of this type from compiler vendors who ABIs happen
to be similar to G++'s ABI, but not from others?
That is the point of my statement above; this hypothetical is uninteresting
because there are no such vendors -- and there aren't likely to be any in
the near future.
But, if there were (or come to be) other OS vendor compilers that almost
support the ABI, I would probably support being compatible with them too,
subject to the same caveats I gave for HP.
Why can't HP's aCC compiler have a -compat-g++ switch?
I definitely think that to be a good idea, but it's not the real point.
The point is that the aCC ABI is the vendor ABI on the platform; if
we want G++ to be able to work with C++ libraries on HPUX, we need to
do be compatible with aCC.
This situation is roughly analagous to an OS that almost -- but not
quite -- implements the C psABI for x86. Suppose, for example, that it
passed arguments in the wrong registers, but otherwise did things
according to the spec. We'd probably accept patches for compatibility
with that OS.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com