public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* RE: HPUX C++ ABI
@ 2002-09-12 14:36 Jessica Han
  0 siblings, 0 replies; 31+ messages in thread
From: Jessica Han @ 2002-09-12 14:36 UTC (permalink / raw)
  To: gcc



>-----Original Message-----
>From: Jeff Law [mailto:law@porcupine.slc.redhat.com]
>Precisely what platform?  Is the PA or IA-64?  For the former, I'd be
>rather surprised if aCC with a G++-like ABI is in that widespread
>production use.  For the latter, it would seem to me that there may
>be alternate compilers one day.
It is on IA64 only. 

>My opinions are mixed here.  I'd love to see HP's compilers and GCC be
>ABI compatible -- that's a win for both HP and GCC.  But I'm not all
>that thrilled to see us installing hacks to work around bugs in HP's
>compiler.  I guess it would probably depend on how extensive 
>the changes
>are and whether or not HP will eventually fix their compiler.
>
>jeff
I only found about 3 places where I have to change g++ to make 
it compatible with aCC, they should all be small changes like 
the patch I just sent.  I also need an option in g++ to tell 
the compiler to use aCC runtime. 

----
Jessica Han
Open Source Tools 
Hewlett-Packard
(408) 447-6154 



^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 13:33 ` Jeff Law
@ 2002-09-13 10:31   ` Mark Mitchell
  0 siblings, 0 replies; 31+ messages in thread
From: Mark Mitchell @ 2002-09-13 10:31 UTC (permalink / raw)
  To: law; +Cc: gcc, jessica, sje



--On Thursday, September 12, 2002 02:32:08 PM -0600 Jeff Law 
<law@porcupine.slc.redhat.com> wrote:

> In message <26570000.1031852797@warlock.codesourcery.com>, Mark Mitchell
> writes :
>  >I've been talking to folks at HP about the C++ ABI in aCC.
>  >
>  >They implemented the C++ ABI in aCC using earlier versions of the ABI
>  >spec.  Due to changes in the spec, and a few mistakes, aCC doesn't
>  >match up with G++.  Because aCC is already in production use, they don't
>  >want to make changes to aCC.  But, they do want people to mix G++ and
>  >aCC objects.
> Precisely what platform?  Is the PA or IA-64?  For the former, I'd be
> rather surprised if aCC with a G++-like ABI is in that widespread
> production use.  For the latter, it would seem to me that there may
> be alternate compilers one day.

HPUX on IA-64.

> But I'm not all
> that thrilled to see us installing hacks to work around bugs in HP's
> compiler.

That's a somewhat unfair characterization.  Remember that the last
substantive change to the ABI spec happenned within the last few weeks;
there's no way they could have gotten it right a year ago.  For the
most part, these are not things that a user using only HP's compiler
would ever notice; they are simply incompatibilities with G++.

That said, I agree with your major concern: any changes need to be
circumspect; we do not want our C++ maintainers having to understand
six different ABI variants in order to make a change.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 12:08         ` David Edelsohn
@ 2002-09-13 10:15           ` Mark Mitchell
  0 siblings, 0 replies; 31+ messages in thread
From: Mark Mitchell @ 2002-09-13 10:15 UTC (permalink / raw)
  To: David Edelsohn; +Cc: gcc, jessica, sje

> 	Is it possible and/or productive to add infrastructure to the
> common part of the compiler to support target-specific control of these
> differences so that the bulk of the changes can be localized to the IA-64
> and/or PA target configurations?  Instead of calling the default layout or
> mangling function, it will call the aCC-compatible version?

There are lots of mechanisms that might be useful, and your suggestion
seems a good one.  Certainly, that would help to satisfy the caveats
I proposed, i.e., that we not endanger our main ABI.

For technical reasons, it's much easier to replace some bits than
others.  Writing a totally different name-mangling scheme would be
simple; there are only a few entry points into the mangler.  Writing
a totally different class-layout scheme would be hard.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 15:13 ` Stan Shebs
  2002-09-12 15:16   ` Matt Austern
  2002-09-12 21:28   ` Kumar Gala
@ 2002-09-13 10:15   ` Mark Mitchell
  2 siblings, 0 replies; 31+ messages in thread
From: Mark Mitchell @ 2002-09-13 10:15 UTC (permalink / raw)
  To: Stan Shebs; +Cc: gcc, jessica, sje

> Well, you'd be opening the door for those nut cases at Apple to want
> all of their nasty ABI hacks in FSF GCC too, and we have a way
> bigger installed base than HP :-)  Decloning of structors is just
> the tip of the iceberg, bwahahaha....

This is a valid objection.

I'm not sure how to balance the interest of FSF users on Apple/HP/etc.
vs. FSF users elsewhere, except that the FSF's position is that free
OS's matter more than other OS's.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-13  8:20         ` Daniel Berlin
@ 2002-09-13 10:08           ` Richard Henderson
  0 siblings, 0 replies; 31+ messages in thread
From: Richard Henderson @ 2002-09-13 10:08 UTC (permalink / raw)
  To: Daniel Berlin; +Cc: nathan, Kumar Gala, Stan Shebs, Mark Mitchell, gcc

On Fri, Sep 13, 2002 at 10:56:58AM -0400, Daniel Berlin wrote:
> We had to go through pain and suffering to fix ABI bugs as the spec 
> changed. We experienced a user backlash not unlike what they would
> experience, to do so.  All in the name of a multi-vendor C++ ABI standard.
> 
> If they have no plans to fully support that standard (IE change as the 
> spec changes), ...
> 
> Harsh, but that's how i feel.

That is *exactly* how I feel.


r~

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-13  3:37       ` Nathan Sidwell
  2002-09-13  4:09         ` Gabriel Dos Reis
@ 2002-09-13  8:20         ` Daniel Berlin
  2002-09-13 10:08           ` Richard Henderson
  1 sibling, 1 reply; 31+ messages in thread
From: Daniel Berlin @ 2002-09-13  8:20 UTC (permalink / raw)
  To: nathan; +Cc: Kumar Gala, Stan Shebs, Mark Mitchell, gcc


On Friday, September 13, 2002, at 05:53  AM, Nathan Sidwell wrote:

> Daniel Berlin wrote:
>>> Wear does the line get drawn ?
>>
>> At bug compatibility. These are *bugs* in aCC.
> (unless I misunderstand) HP have declared them features. In part
> because that's what the spec said at the time they implemented it.
> In one sense they are bugs, but as we know, that can be a fuzzy
> line. The C++ ABI on HP is what HP says it is. We have the choice of
> being compatible with it or not.
>
If this means they have no plans to fix it, then we should have no 
plans to be bug compatible with it.

We had to go through pain and suffering to fix ABI bugs as the spec 
changed.
We experienced a user backlash not unlike what they would experience, 
to do so.
All in the name of a multi-vendor C++ ABI standard.

If they have no plans to fully support that standard (IE change as the 
spec changes), ...

Harsh, but that's how i feel.

--Dan

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-13  3:37       ` Nathan Sidwell
@ 2002-09-13  4:09         ` Gabriel Dos Reis
  2002-09-13  8:20         ` Daniel Berlin
  1 sibling, 0 replies; 31+ messages in thread
From: Gabriel Dos Reis @ 2002-09-13  4:09 UTC (permalink / raw)
  To: nathan; +Cc: Daniel Berlin, Kumar Gala, Stan Shebs, Mark Mitchell, gcc

Nathan Sidwell <nathan@acm.org> writes:

| Daniel Berlin wrote:
| > > Wear does the line get drawn ?
| > 
| > At bug compatibility. These are *bugs* in aCC.
| (unless I misunderstand) HP have declared them features. 

Ahem, obviously, that depends on appropriate definitions of "bug" and
"feature".  Personally, I think they are bugs in aCC, but I understand
HP quelifying them as features.  Oh, well.

I'm not convinced that we should fix aCC bugs in GCC.  The right place
to do it is in aCC, IMHO.

I'm getting the impression that when it comes to put things like 
extensions or bug-compatibility patches in GCC, some vendors are more
favored than others.  That doesn't look fair to me.  I would love to
be prove wrong but, currently, that is the impression I have :-(

-- Gaby

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 21:36     ` Daniel Berlin
@ 2002-09-13  3:37       ` Nathan Sidwell
  2002-09-13  4:09         ` Gabriel Dos Reis
  2002-09-13  8:20         ` Daniel Berlin
  0 siblings, 2 replies; 31+ messages in thread
From: Nathan Sidwell @ 2002-09-13  3:37 UTC (permalink / raw)
  To: Daniel Berlin; +Cc: Kumar Gala, Stan Shebs, Mark Mitchell, gcc

Daniel Berlin wrote:
> > Wear does the line get drawn ?
> 
> At bug compatibility. These are *bugs* in aCC.
(unless I misunderstand) HP have declared them features. In part
because that's what the spec said at the time they implemented it.
In one sense they are bugs, but as we know, that can be a fuzzy
line. The C++ ABI on HP is what HP says it is. We have the choice of
being compatible with it or not.

The C structure layout is full of specific hacks to deal with
other non psABI conforming layouts (MS_BITFIELD_TYPE_MATTERS for
instance), and the C++ compiler has some hacks to be compatible with
other vendors interpretation of the C++ standard (-fms-extensions).
So there already is precedent for adding code to be compatible
with a vendors's compiler.

Personally, I'm inclined to be helpful to HP.

nathan

-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
           The voices in my head told me to say this
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 21:42       ` Daniel Berlin
@ 2002-09-12 21:59         ` Kumar Gala
  0 siblings, 0 replies; 31+ messages in thread
From: Kumar Gala @ 2002-09-12 21:59 UTC (permalink / raw)
  To: Daniel Berlin; +Cc: Matt Austern, Stan Shebs, Mark Mitchell, gcc

> All other compilers being exactly how many, out of the population of
> cross-platform compilers?
>
> I'm guessing 2 others.

While it is not tons, I do not think there are tons of PPC cross 
compilers.  However the following do:

MetroWerks CodeWarrior, WindRiver Diab, Green Hills, MetaWare which 
composes a large majority of the embedded compilers for PPC.

The only point I was trying to make is that if this was something that 
was going to require long term support in GCC then saying yes to it 
opens a can of worms in my eyes.

- kumar

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 21:33     ` Matt Austern
@ 2002-09-12 21:42       ` Daniel Berlin
  2002-09-12 21:59         ` Kumar Gala
  0 siblings, 1 reply; 31+ messages in thread
From: Daniel Berlin @ 2002-09-12 21:42 UTC (permalink / raw)
  To: Matt Austern; +Cc: Kumar Gala, Stan Shebs, Mark Mitchell, gcc



On Thu, 12 Sep 2002, Matt Austern wrote:

> On Thursday, September 12, 2002, at 09:19 PM, 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.

All other compilers being exactly how many, out of the population of 
cross-platform compilers?

I'm guessing 2 others.

You make it seem like their are *tons* of altivec PIM implementing 
compilers, and GCC is just the one exception.

> >
> > 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.
> 
> We'd be completely in favor of that, of course.
And if they want it, they can use the generic vector infrastructure, and 
not worry about the Altivec PIM at all.

In fact, they'll get code that works on x86 too.
What a deal!

--Dan

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 21:28   ` Kumar Gala
  2002-09-12 21:33     ` Matt Austern
@ 2002-09-12 21:36     ` Daniel Berlin
  2002-09-13  3:37       ` Nathan Sidwell
  1 sibling, 1 reply; 31+ messages in thread
From: Daniel Berlin @ 2002-09-12 21:36 UTC (permalink / raw)
  To: Kumar Gala; +Cc: Stan Shebs, Mark Mitchell, gcc



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.


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 21:28   ` Kumar Gala
@ 2002-09-12 21:33     ` Matt Austern
  2002-09-12 21:42       ` Daniel Berlin
  2002-09-12 21:36     ` Daniel Berlin
  1 sibling, 1 reply; 31+ messages in thread
From: Matt Austern @ 2002-09-12 21:33 UTC (permalink / raw)
  To: Kumar Gala; +Cc: Stan Shebs, Mark Mitchell, gcc

On Thursday, September 12, 2002, at 09:19 PM, 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.

We'd be completely in favor of that, of course.

			--Matt

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 15:13 ` Stan Shebs
  2002-09-12 15:16   ` Matt Austern
@ 2002-09-12 21:28   ` Kumar Gala
  2002-09-12 21:33     ` Matt Austern
  2002-09-12 21:36     ` Daniel Berlin
  2002-09-13 10:15   ` Mark Mitchell
  2 siblings, 2 replies; 31+ messages in thread
From: Kumar Gala @ 2002-09-12 21:28 UTC (permalink / raw)
  To: Stan Shebs; +Cc: Mark Mitchell, gcc

> 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 ?

- kumar

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
@ 2002-09-12 18:33 Benjamin Kosnik
  0 siblings, 0 replies; 31+ messages in thread
From: Benjamin Kosnik @ 2002-09-12 18:33 UTC (permalink / raw)
  To: gcc

> What do others think?

I think there should be some plan aimed at converging the HP C++ ABI and
the GNU C++ ABI. Then both ABI's could be well-described by some
external, vendor-neutral standard, which I thought was the whole point
of the IA64 C++ ABI. How HP and the gcc community should best update and
version their C++ ABI is still up in the air, and not convered by any
document or standard.

The alternative, suggested as death by a thousand HP-specific ABI hacks
for HPUX on IA64, increasingly seems to be a bad idea. This approach
seems best suited as small patches in their own tree: merging these
fixes into the GCC repository gives them no incentive to fix the
underlying issues in the HP compiler. There are already too many
HP-specific hacks in the runtime, for instance. I'm less and less
interested in putting more in.

-benjamin

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 15:16   ` Matt Austern
@ 2002-09-12 15:33     ` Stan Shebs
  0 siblings, 0 replies; 31+ messages in thread
From: Stan Shebs @ 2002-09-12 15:33 UTC (permalink / raw)
  To: Matt Austern; +Cc: Mark Mitchell, gcc, jessica, sje

Matt Austern wrote:

> On Thursday, September 12, 2002, at 03:11 PM, Stan Shebs 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.
>
>
> Alternatively, maybe the answer is that features like -fapple-kext
> really should go into the mainline tree.  It wouldn't change the ABI
> on any platform other than OS X, and it would be very helpful for
> us.
>             --Matt

QED. :-)  -fapple-kext is a really good example of something that
would be helpful for us, and a nightmare for everybody else, because
what it does is to emulate enough of the 2.95 ABI to let 2.95-compiled
C++-written drivers be usable from 3.x-compiled base classes in the
kernel (that's how we got binary compat for drivers from 10.1 to
10.2), all arrived at empirically by hacking until all the drivers
loaded.  No way to really test it unless you're an OS X driver wiz,
so it's not reasonable to ask all the GCC developers to keep this
functionality intact while working on the C++ frontend.

Stan


^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 15:13 ` Stan Shebs
@ 2002-09-12 15:16   ` Matt Austern
  2002-09-12 15:33     ` Stan Shebs
  2002-09-12 21:28   ` Kumar Gala
  2002-09-13 10:15   ` Mark Mitchell
  2 siblings, 1 reply; 31+ messages in thread
From: Matt Austern @ 2002-09-12 15:16 UTC (permalink / raw)
  To: Stan Shebs; +Cc: Mark Mitchell, gcc, jessica, sje

On Thursday, September 12, 2002, at 03:11 PM, Stan Shebs 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.

Alternatively, maybe the answer is that features like -fapple-kext
really should go into the mainline tree.  It wouldn't change the ABI
on any platform other than OS X, and it would be very helpful for
us.
			--Matt

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 10:48 Mark Mitchell
                   ` (5 preceding siblings ...)
  2002-09-12 15:08 ` Mike Stump
@ 2002-09-12 15:13 ` Stan Shebs
  2002-09-12 15:16   ` Matt Austern
                     ` (2 more replies)
  6 siblings, 3 replies; 31+ messages in thread
From: Stan Shebs @ 2002-09-12 15:13 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: gcc, jessica, sje

Mark Mitchell wrote:

> I've been talking to folks at HP about the C++ ABI in aCC.
>
> They implemented the C++ ABI in aCC using earlier versions of the ABI
> spec.  Due to changes in the spec, and a few mistakes, aCC doesn't
> match up with G++.  Because aCC is already in production use, they don't
> want to make changes to aCC.  But, they do want people to mix G++ and
> aCC objects.
>
> The solution HP is proposing is to make HPUX-only tweaks to the C++ ABI
> in G++ so that on HPUX G++ behaves like aCC.
>
> This is a big project, but nowhere near as big a project as (say)
> implementing Sun's C++ ABI in G++; aCC is an "almost-compliant"
> compiler in much the same way that G++ is.
>
> I believe we should accept these patches, with three caveats:
>
>  (1) We are convinced that they cannot possibly affect the ABI on
>      other platforms.
>
>  (2) We do not take responsibility for making sure they continue
>      to work; our responsibility is to maintain the main ABI.
>
>  (3) The patches do not so complicate the front end as to make us
>      nervous about our ability to understand what is going on.
>
> There is a slippery slope argument that "everyone else will want us to
> support there variant of the ABI too".  But, there is no everyone else;
> HP is the only vendor with an installed base that does not feel they
> can make changes to their ABI.

Well, you'd be opening the door for those nut cases at Apple to want
all of their nasty ABI hacks in FSF GCC too, and we have a way
bigger installed base than HP :-)  Decloning of structors is just
the tip of the iceberg, bwahahaha....

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.

Stan



^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 10:48 Mark Mitchell
                   ` (4 preceding siblings ...)
  2002-09-12 14:46 ` Richard Henderson
@ 2002-09-12 15:08 ` Mike Stump
  2002-09-12 15:13 ` Stan Shebs
  6 siblings, 0 replies; 31+ messages in thread
From: Mike Stump @ 2002-09-12 15:08 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: gcc, jessica, sje

On Thursday, September 12, 2002, at 10:46 AM, Mark Mitchell wrote:
> There is a slippery slope argument that "everyone else will want us to
> support there variant of the ABI too".  But, there is no everyone else;
> HP is the only vendor with an installed base that does not feel they
> can make changes to their ABI.

I don't think I buy this.  For example, tell us how Apple is 
uninterested in preserving the abi compatibility of C++ objects for 
kernel loadable extensions.  Can we add changes to gcc to make it 
compatible with something that is close?

Now, compare the installed base of IA-64 HP systems to Apple systems, 
let me know what you find.  I don't claim to know the numbers, but I am 
curious as to what they are.

> What do others think?

Sounds like the same problem g++ will face, rev the abi to make g++ be 
compatible with the standard, or don't rev it because people want abi 
stability.  If you rev it, you loose, if you don't rev it, you loose.  
I'm not surprised that we are loosing now.  The game was rigged to be 
that way.  It is inescapable with current technology.

Now, having said all of that I guess my position is that I don't mind 
if it goes in, as gcc is all about being flexible and accommodating 
random abi conventions of all sorts.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 14:19 ` Jim Wilson
@ 2002-09-12 14:51   ` Janis Johnson
  0 siblings, 0 replies; 31+ messages in thread
From: Janis Johnson @ 2002-09-12 14:51 UTC (permalink / raw)
  To: Jim Wilson; +Cc: Mark Mitchell, gcc, jessica, sje

On Thu, Sep 12, 2002 at 05:19:37PM -0400, Jim Wilson wrote:
> >The solution HP is proposing is to make HPUX-only tweaks to the C++ ABI
> >in G++ so that on HPUX G++ behaves like aCC.
> 
> We would need a few documentation changes.  Right now, we have quite a few
> places that say we use the C++ ABI for all targets.  They would all have to
> be changed somehow to reflect the new situation which is we use the C++ ABI
> for all targets except those whose native ABI is close enough to the C++ ABI
> such that it is beneficial for gcc to be bug-compatible with the native
> compiler than to have strict C++ ABI compliance.  There is the last page of
> gcc/doc/compat.texi.  There is the release notes page of gcc-3.2.  There are
> probably other places.
> 
> We also have to finesse the fact that we stated that there would be no ABI
> changes after gcc-3.2 unless they were necessary to fix a C++ compilation
> problem.
> 
> Jim

I've made a few documentation changes about ABI issues and am keeping a
list of other things that should be documented.  Here's what I've got
currently, which now includes your comments above.

Janis


GCC Manual

  Binary Compatibility (compat.texi)

    Standard C++ Library

      if two compilers conform to the same C++ ABI and their libraries
      conform to the same ABI for the Standard C++ Library, then
      objects produced by each set might be interoperable
      (depends on other factors, e.g., startup files; what else?)

      two compilers might conform to the same C++ ABI but come with
      libraries that do not conform to the same library ABI; a user can
      compile objects with both of those compilers as long as both use
      the header files for the Standard C++ Library that will be used

    C++ ABI; where used, where variants are used, where it's not used
    at all, conditions which warrant a change in the C++ ABI for a
    target (Jim Wilson, http://gcc.gnu.org/ml/gcc/2002-09/msg00497.html)

GCC Internals Manual

  Interfacing to GCC Output (interface.texi) (or elsewhere?)
    list of what's included in an ABI (issues that affect
    interoperability even when there is no formal ABI; see the "Things
    to Test" list in http://gcc.gnu.org/ml/gcc/2002-08/msg01251.html)

    release versioning (compiler stuff from Benjamin's libstdc++
    document)

    testing approaches for GCC ports that must be interoperable with
    other compilers:
      gdb tests
      ABI conformance test suite
      compile parts of an application with one compiler, parts with
        another; e.g. libraries for apps in GCC release criteria
      consistency.vlad

libstdc++-v3 Documentation
  ABI Policy and Guidelines (abi.txt)
    move compiler parts to GCC Manual or GCC Internals Manual

GCC Installation Instructions
  Configuration (install.texi)
    copy relevant information there from gcc-3.2/c++-abi.html

    general information about configuration options that affect ABI
    conformance/interoperability

  Host/Target specific installation notes for GCC (install.texi)
    copy relevant information there from gcc-3.2/c++-abi.html

GCC release criteria (gcc-3.3/criteria.html, when it exists)
  describe existing test suites for ABI conformance, compatibility,
  and interoperability

GCC release notes
  information about relevant ABI issues, or pointers to them

somewhere

  target-specific information about binary compatibility, ABI issues;
  could include information (that's not hopelessly out of date) from
  Interoperation section in trouble.texi, although "Trouble" doesn't
  seem to be the right place

  describe possible additional testing approaches for ABI conformance,
  compatibility, and interoperability (projects list?)

  Benjamin's list of updates required for a C++ ABI change

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 10:48 Mark Mitchell
                   ` (3 preceding siblings ...)
  2002-09-12 14:19 ` Jim Wilson
@ 2002-09-12 14:46 ` Richard Henderson
  2002-09-12 15:08 ` Mike Stump
  2002-09-12 15:13 ` Stan Shebs
  6 siblings, 0 replies; 31+ messages in thread
From: Richard Henderson @ 2002-09-12 14:46 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: gcc, jessica, sje

On Thu, Sep 12, 2002 at 10:46:37AM -0700, Mark Mitchell wrote:
> What do others think?

I'm not particularly thrilled about the idea.  If it it HP's intention
to retain their not-quite-abi compiance permanently, then I think this
does damage to the cross-vendor ABI as a whole.  I would urge them to
reconsider this stance.

I'm even less thrilled about the form of the last patch.  If the goal
is merely compatibility with HP's broken ABI, then there should _not_
be 100 random TARGET_FOO macros.


r~

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 10:48 Mark Mitchell
                   ` (2 preceding siblings ...)
  2002-09-12 13:33 ` Jeff Law
@ 2002-09-12 14:19 ` Jim Wilson
  2002-09-12 14:51   ` Janis Johnson
  2002-09-12 14:46 ` Richard Henderson
                   ` (2 subsequent siblings)
  6 siblings, 1 reply; 31+ messages in thread
From: Jim Wilson @ 2002-09-12 14:19 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: gcc, jessica, sje

>The solution HP is proposing is to make HPUX-only tweaks to the C++ ABI
>in G++ so that on HPUX G++ behaves like aCC.

We would need a few documentation changes.  Right now, we have quite a few
places that say we use the C++ ABI for all targets.  They would all have to
be changed somehow to reflect the new situation which is we use the C++ ABI
for all targets except those whose native ABI is close enough to the C++ ABI
such that it is beneficial for gcc to be bug-compatible with the native
compiler than to have strict C++ ABI compliance.  There is the last page of
gcc/doc/compat.texi.  There is the release notes page of gcc-3.2.  There are
probably other places.

We also have to finesse the fact that we stated that there would be no ABI
changes after gcc-3.2 unless they were necessary to fix a C++ compilation
problem.

Jim

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 10:48 Mark Mitchell
  2002-09-12 10:52 ` Daniel Jacobowitz
  2002-09-12 11:15 ` David Edelsohn
@ 2002-09-12 13:33 ` Jeff Law
  2002-09-13 10:31   ` Mark Mitchell
  2002-09-12 14:19 ` Jim Wilson
                   ` (3 subsequent siblings)
  6 siblings, 1 reply; 31+ messages in thread
From: Jeff Law @ 2002-09-12 13:33 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: gcc, jessica, sje

In message <26570000.1031852797@warlock.codesourcery.com>, Mark Mitchell writes
:
 >I've been talking to folks at HP about the C++ ABI in aCC.
 >
 >They implemented the C++ ABI in aCC using earlier versions of the ABI
 >spec.  Due to changes in the spec, and a few mistakes, aCC doesn't
 >match up with G++.  Because aCC is already in production use, they don't
 >want to make changes to aCC.  But, they do want people to mix G++ and
 >aCC objects.
Precisely what platform?  Is the PA or IA-64?  For the former, I'd be
rather surprised if aCC with a G++-like ABI is in that widespread
production use.  For the latter, it would seem to me that there may
be alternate compilers one day.

My opinions are mixed here.  I'd love to see HP's compilers and GCC be
ABI compatible -- that's a win for both HP and GCC.  But I'm not all
that thrilled to see us installing hacks to work around bugs in HP's
compiler.  I guess it would probably depend on how extensive the changes
are and whether or not HP will eventually fix their compiler.

jeff

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 11:52       ` Mark Mitchell
@ 2002-09-12 12:08         ` David Edelsohn
  2002-09-13 10:15           ` Mark Mitchell
  0 siblings, 1 reply; 31+ messages in thread
From: David Edelsohn @ 2002-09-12 12:08 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: gcc, jessica, sje

>>>>> Mark Mitchell writes:

Mark> Implementing some very different ABI (such as the aCC ABI on HPPA, or
Mark> the G++ ABI before 3.0) would be very hard to do in a way that does not
Mark> add significant complexity to the compiler.  I believe that such a change
Mark> would pose serious risks to our primary ABI.

	The focus of this discussion on the C++ ABI is overly restrictive.
This proposal sets a precedent for any "small" vendor-specific option for
any compatibility issue within the common part of the compiler.  Target
requirements have been handled with additional target hooks in the past.

	Is it possible and/or productive to add infrastructure to the
common part of the compiler to support target-specific control of these
differences so that the bulk of the changes can be localized to the IA-64
and/or PA target configurations?  Instead of calling the default layout or
mangling function, it will call the aCC-compatible version?

Thanks, David

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 11:41     ` David Edelsohn
@ 2002-09-12 11:52       ` Mark Mitchell
  2002-09-12 12:08         ` David Edelsohn
  0 siblings, 1 reply; 31+ messages in thread
From: Mark Mitchell @ 2002-09-12 11:52 UTC (permalink / raw)
  To: David Edelsohn; +Cc: gcc, jessica, sje



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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 11:38   ` Fergus Henderson
@ 2002-09-12 11:49     ` David Edelsohn
  0 siblings, 0 replies; 31+ messages in thread
From: David Edelsohn @ 2002-09-12 11:49 UTC (permalink / raw)
  To: Fergus Henderson; +Cc: Mark Mitchell, gcc, jessica, sje

>>>>> Fergus Henderson writes:

Fergus> The extent to which such ABI-related patches would be accepted is directly
Fergus> proportional to the size and complexity of those patches.
Fergus> Small, simple patches are OK.  Big or complex patches are not.

	Says who?

Fergus> It would provide a
Fergus> useful feature in FSF GCC (compatibility with HPUX C++), it would save HP
Fergus> a lot of work, it would save GCC developers and users on HP a lot of work,
Fergus> and the cost would be low.

	Why is this a useful feature in FSF GCC?  Why is promoting one
proprietary compiler over others appropriate for GCC?

	This is exactly my point: if GCC is going to help users on HP in
this way, it needs to be willing to help users on all platforms.  I am not
fundamentally opposed to the patch, but if this patch is accepted then it
is inappropriate to design criteria which makes this patch okay and
rejects other patches.

David

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 11:30   ` Mark Mitchell
@ 2002-09-12 11:41     ` David Edelsohn
  2002-09-12 11:52       ` Mark Mitchell
  0 siblings, 1 reply; 31+ messages in thread
From: David Edelsohn @ 2002-09-12 11:41 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: gcc, jessica, sje

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

David

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 11:15 ` David Edelsohn
  2002-09-12 11:30   ` Mark Mitchell
@ 2002-09-12 11:38   ` Fergus Henderson
  2002-09-12 11:49     ` David Edelsohn
  1 sibling, 1 reply; 31+ messages in thread
From: Fergus Henderson @ 2002-09-12 11:38 UTC (permalink / raw)
  To: David Edelsohn; +Cc: Mark Mitchell, gcc, jessica, sje

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.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 11:15 ` David Edelsohn
@ 2002-09-12 11:30   ` Mark Mitchell
  2002-09-12 11:41     ` David Edelsohn
  2002-09-12 11:38   ` Fergus Henderson
  1 sibling, 1 reply; 31+ messages in thread
From: Mark Mitchell @ 2002-09-12 11:30 UTC (permalink / raw)
  To: David Edelsohn; +Cc: gcc, jessica, sje



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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 10:48 Mark Mitchell
  2002-09-12 10:52 ` Daniel Jacobowitz
@ 2002-09-12 11:15 ` David Edelsohn
  2002-09-12 11:30   ` Mark Mitchell
  2002-09-12 11:38   ` Fergus Henderson
  2002-09-12 13:33 ` Jeff Law
                   ` (4 subsequent siblings)
  6 siblings, 2 replies; 31+ messages in thread
From: David Edelsohn @ 2002-09-12 11:15 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: gcc, jessica, sje

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

	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++.  The
burden should be on the vendor who wants to be compatible with G++, not on
G++ to be compatible with other, non-standard ABIs.

David

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: HPUX C++ ABI
  2002-09-12 10:48 Mark Mitchell
@ 2002-09-12 10:52 ` Daniel Jacobowitz
  2002-09-12 11:15 ` David Edelsohn
                   ` (5 subsequent siblings)
  6 siblings, 0 replies; 31+ messages in thread
From: Daniel Jacobowitz @ 2002-09-12 10:52 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: gcc, jessica, sje

On Thu, Sep 12, 2002 at 10:46:37AM -0700, Mark Mitchell wrote:
> I've been talking to folks at HP about the C++ ABI in aCC.
> 
> They implemented the C++ ABI in aCC using earlier versions of the ABI
> spec.  Due to changes in the spec, and a few mistakes, aCC doesn't
> match up with G++.  Because aCC is already in production use, they don't
> want to make changes to aCC.  But, they do want people to mix G++ and
> aCC objects.
> 
> The solution HP is proposing is to make HPUX-only tweaks to the C++ ABI
> in G++ so that on HPUX G++ behaves like aCC.
> 
> This is a big project, but nowhere near as big a project as (say)
> implementing Sun's C++ ABI in G++; aCC is an "almost-compliant"
> compiler in much the same way that G++ is.
> 
> I believe we should accept these patches, with three caveats:
> 
>  (1) We are convinced that they cannot possibly affect the ABI on
>      other platforms.
> 
>  (2) We do not take responsibility for making sure they continue
>      to work; our responsibility is to maintain the main ABI.
> 
>  (3) The patches do not so complicate the front end as to make us
>      nervous about our ability to understand what is going on.
> 
> There is a slippery slope argument that "everyone else will want us to
> support there variant of the ABI too".  But, there is no everyone else;
> HP is the only vendor with an installed base that does not feel they
> can make changes to their ABI.
> 
> Jessica, Steve, how close to think you are to achieving interoperability?
> (It doesn't seem to me that there's too much point in accepting patches
> for G++ to get closer to aCC unless you can get all the way; do you think
> you understand all the things you need to do in order to get g++ to match
> aCC?)
> 
> What do others think?

This sounds reasonable to me, but thinking about the last such patch I
saw from Jessica, I have a request - there should be a new switch (or
macro if you prefer) to control this bug-compatibility.  That makes it
much clearer to an observer why the code is there and what it
accomplishes, then if it is just keyed off the target macro as it was.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

^ permalink raw reply	[flat|nested] 31+ messages in thread

* HPUX C++ ABI
@ 2002-09-12 10:48 Mark Mitchell
  2002-09-12 10:52 ` Daniel Jacobowitz
                   ` (6 more replies)
  0 siblings, 7 replies; 31+ messages in thread
From: Mark Mitchell @ 2002-09-12 10:48 UTC (permalink / raw)
  To: gcc; +Cc: jessica, sje

I've been talking to folks at HP about the C++ ABI in aCC.

They implemented the C++ ABI in aCC using earlier versions of the ABI
spec.  Due to changes in the spec, and a few mistakes, aCC doesn't
match up with G++.  Because aCC is already in production use, they don't
want to make changes to aCC.  But, they do want people to mix G++ and
aCC objects.

The solution HP is proposing is to make HPUX-only tweaks to the C++ ABI
in G++ so that on HPUX G++ behaves like aCC.

This is a big project, but nowhere near as big a project as (say)
implementing Sun's C++ ABI in G++; aCC is an "almost-compliant"
compiler in much the same way that G++ is.

I believe we should accept these patches, with three caveats:

  (1) We are convinced that they cannot possibly affect the ABI on
      other platforms.

  (2) We do not take responsibility for making sure they continue
      to work; our responsibility is to maintain the main ABI.

  (3) The patches do not so complicate the front end as to make us
      nervous about our ability to understand what is going on.

There is a slippery slope argument that "everyone else will want us to
support there variant of the ABI too".  But, there is no everyone else;
HP is the only vendor with an installed base that does not feel they
can make changes to their ABI.

Jessica, Steve, how close to think you are to achieving interoperability?
(It doesn't seem to me that there's too much point in accepting patches
for G++ to get closer to aCC unless you can get all the way; do you think
you understand all the things you need to do in order to get g++ to match
aCC?)

What do others think?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2002-09-13 17:15 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-09-12 14:36 HPUX C++ ABI Jessica Han
  -- strict thread matches above, loose matches on Subject: below --
2002-09-12 18:33 Benjamin Kosnik
2002-09-12 10:48 Mark Mitchell
2002-09-12 10:52 ` Daniel Jacobowitz
2002-09-12 11:15 ` David Edelsohn
2002-09-12 11:30   ` Mark Mitchell
2002-09-12 11:41     ` David Edelsohn
2002-09-12 11:52       ` Mark Mitchell
2002-09-12 12:08         ` David Edelsohn
2002-09-13 10:15           ` Mark Mitchell
2002-09-12 11:38   ` Fergus Henderson
2002-09-12 11:49     ` David Edelsohn
2002-09-12 13:33 ` Jeff Law
2002-09-13 10:31   ` Mark Mitchell
2002-09-12 14:19 ` Jim Wilson
2002-09-12 14:51   ` Janis Johnson
2002-09-12 14:46 ` Richard Henderson
2002-09-12 15:08 ` Mike Stump
2002-09-12 15:13 ` Stan Shebs
2002-09-12 15:16   ` Matt Austern
2002-09-12 15:33     ` Stan Shebs
2002-09-12 21:28   ` Kumar Gala
2002-09-12 21:33     ` Matt Austern
2002-09-12 21:42       ` Daniel Berlin
2002-09-12 21:59         ` Kumar Gala
2002-09-12 21:36     ` Daniel Berlin
2002-09-13  3:37       ` Nathan Sidwell
2002-09-13  4:09         ` Gabriel Dos Reis
2002-09-13  8:20         ` Daniel Berlin
2002-09-13 10:08           ` Richard Henderson
2002-09-13 10:15   ` Mark Mitchell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).