This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: HPUX C++ ABI
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Kumar Gala <kumar dot gala at motorola dot com>
- Cc: Stan Shebs <shebs at apple dot com>,Mark Mitchell <mark at codesourcery dot com>, <gcc at gcc dot gnu dot org>
- Date: Fri, 13 Sep 2002 00:33:11 -0400 (EDT)
- Subject: Re: HPUX C++ ABI
On Thu, 12 Sep 2002, Kumar Gala wrote:
> > But speaking seriously, we Appleites deal with corporate pressure
> > to support various hacks by maintaining our own version of GCC and
> > taking on all the costs that go with that, so I'm wondering why it
> > is that HP can't do the same. While I personally don't have a problem
> > doing a little favor for HP, it's going to be really tricky to avoid
> > charges of favoritism and bias later on if, say, some Apple feature is
> > shot down.
>
> I have to agree that this is very slippery slope. What stops from
> extend this to programming models like the AltiVec PIM. Currently GCC
> supports its own variant of the PIM while all other compilers that
> implement the specified PIM.
>
> While making GCC support the AltiVec PIM may introduce code into places
> that are required only to support the PIM, it would be more generally
> useful to the user base.
>
> Apple obviously ships a modified GCC that supports the spec'd PIM. I
> would be really nice if users could have code that worked under Linux
> as well as Mac OS X.
>
> Wear does the line get drawn ?
At bug compatibility. These are *bugs* in aCC.
Implementing the altivec PIM is a *feature* (arguably ;P).
There is also a related specific issue that has been relatively
ignored (IE most messages haven't mentioned it) so far in the case of aCC.
It's important to know whether aCC will be fixed, and when.
If it will not, I don't think we should even consider it.
If they aren't going to fully support the multivendor ABI standard, why should we help
them out?
Make no mistake, this helps HP more than GCC.
If it's already going to be fixed in the next version, then we should
consider doing it as a good will gesture, with the intent of removing
support when the bugs are fixed in aCC, or at some fixed point in time (as
a contingency in case this version never happens).
In other words, this is *not* a slippery slope, unless you try to
generalize the issue. This is a very specific request for bug
compatibility. Not a general request for a random feature.