This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: HPUX C++ ABI


On 12-Sep-2002, 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?  This seems to unfairly
> prefer one set of compiler vendors over another.

It's not arbitrarily preferring one set of compiler vendors over another.
The extent to which such ABI-related patches would be accepted is directly
proportional to the size and complexity of those patches.
Small, simple patches are OK.  Big or complex patches are not.
Since the criteria are the same for all vendors, I think it is fair,
even though the end result may mean a benefit for only one vendor.

> 	Why can't HP's aCC compiler have a -compat-g++ switch?  This is
> not asking HP to change their ABI, this is asking HP to have a separate
> compatibility mode in aCC if they want to interoperate with G++.

That would require HP to ship two different versions of all their
libraries, one compiled with -compat-g++ and one without.
Furthermore, third-party library vendors would also need to ship
two different versions of their libraries for HPUX.

In other words, you are asking them to have two ABIs.
The cost of having two ABIs rather than one is very high.

If you ask that, then they will almost certainly NOT ship HPUX with
two ABIs.  Instead they'd be better off shipping HPUX with a version of
GCC that has their patches applied.  So they would end up maintaining
these patches in their own GCC repository.  (Either that, or abandon the goal
of GCC compatibility.)

But if HP are going to be maintaining these patches in their own GCC
repository, and the patches are needed to get a version of GCC that
is compatible with HP's C++ compiler and HP's version of GCC, and the
patches are relatively small and simple, then I don't see any reason
why they shouldn't go in the main GCC repository.  It would provide a
useful feature in FSF GCC (compatibility with HPUX C++), it would save HP
a lot of work, it would save GCC developers and users on HP a lot of work,
and the cost would be low.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]