HPUX C++ ABI

[Mark Mitchell]

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?

[Daniel Jacobowitz]

Post by Mark Mitchell
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.
(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.

[Fergus Henderson]

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.

[David Edelsohn]

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

[Jeff Law]

Post by Mark Mitchell
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

[Mark Mitchell]

--On Thursday, September 12, 2002 02:32:08 PM -0600 Jeff Law

Post by Jeff Law

Post by Mark Mitchell
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.

Post by Jeff Law
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.

[Jim Wilson]

Post by Mark Mitchell
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

[Janis Johnson]

Post by Jim Wilson

Post by Mark Mitchell
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

[Jessica Han]

-----Original Message-----
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
[phone]

[Richard Henderson]

Post by Mark Mitchell
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~

[Mike Stump]

Post by Mark Mitchell
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.

Post by Mark Mitchell
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.

[Stan Shebs]

Post by Mark Mitchell
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.
(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

[Matt Austern]

Post by Stan Shebs
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

[Stan Shebs]

Post by Matt Austern

Post by Stan Shebs
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

[Kumar Gala]

Post by Stan Shebs
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

[Matt Austern]

Post by Kumar Gala

Post by Stan Shebs
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

[Daniel Berlin]

Post by Matt Austern

Post by Kumar Gala

Post by Stan Shebs
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.

Post by Matt Austern

Post by Kumar Gala
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

[Kumar Gala]

Post by Daniel Berlin
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

[Daniel Berlin]

Post by Kumar Gala

Post by Stan Shebs
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.

[Nathan Sidwell]

Post by Daniel Berlin

Post by Kumar Gala
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

[Gabriel Dos Reis]

Nathan Sidwell <***@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

[Daniel Berlin]

Post by Nathan Sidwell

Post by Daniel Berlin

Post by Kumar Gala
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

[Richard Henderson]

Post by Daniel Berlin
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~

[Mark Mitchell]

Post by Stan Shebs
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.

[Benjamin Kosnik]

Post by Mark Mitchell
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