Re: Unreviewed 2.95.4 patches since April 1st

[Mike Stump <mrs at windriver dot com>]

> To: David Korn <dkorn@pixelpower.com>
> CC: gcc-patches@gcc.gnu.org, mrs@windriver.com
> From: Geoff Keating <geoffk@geoffk.org>
> Date: 24 Apr 2001 09:48:24 -0700

> To be precise, 2.95.3 exists for those who need backwards
> compatibility with the 2.95 series.  It does not exist for those who
> need backwards compatibility with, say, 2.7.2.

Actually, gcc 2.95.3 exists to be ABI compatible with the vendor C
compiler.  If gcc 2.95 or 2.95.1 had a bug and was not compatible with
the vendor C compiler, then it isn't necessarily wrong to make
2.95.[34] be compatible with it.  But, as we like to say, you already
knew this.  What's really going to cook your noodle is would you have
broken the vase if I had told, oh, wait, never mind.

If you want to argue it is wrong, I think we'll need a better
argument.  My first order response is, of course it is wrong (under
the assumption there is a testcase that is valid C that doesn't do the
right thing when linked on the OS).

Further, future incompatible changes should be done now in their
entirety, so that some platforms that can turn them on sooner, can.  I
could have introduced the eabi fixes in my last major release, but it
went out with lack of perfect eabi compatibility.  Waiting for a major
Linux release is nice, but, the world isn't all Linux.

> I'm sure Bernd wouldn't mind fixing it, the problem is that patches
> to release branches should also go into the mainline and be tested
> there for some time before going onto a release branch, and your
> patch has not been submitted in a form suitable for going into the
> mainline.

Agreed.  The 3.0 abi incompatibilities for C++ have zero bearing on C
abi compatibilities, and don't relieve gcc from offering vendor C abi
compatibility.  All work to make gcc C abi compatibility with a vendor
compiler can and should go in the mainline.  If they are clean/safe
and don't adversely risk other platforms, then they should be
considered for a release branch.

> > Perhaps we should invite the SC to adjudicate a decision about
> > what to do with this target?

> Why not ask Mike Stump?  He's from WRS and ought to know what the
> status of vxworks support is.

Here's my take; if gcc can be made to better support the ABI as used
by the vendor compiler, then it is not necessarily wrong to do that.
For a good first order approximation, I think it is reasonable to be
ABI compliant with a vendor C compiler.  If someone wants to argue
otherwise, the burden falls on them to explain the rejection and
surmount the obvious objections.

I don't know why the steering committee would need to say anything
about such a trivial matter.  I don't know why I would either, for
that matter.  You can consider David competent to represent vxworks
ppc C abi interests (until I find out otherwise :-)).  Certainly he
has shown more than an order of magnitude more interest than other
folks, and I include myself in that group.

I think we should take it as a given that we want to support vxworks,
and that we wish to the C abi compatible with the vendor compiler.  We
rule out C++ abi compatibility for obvious reasons.  When a stable C++
abi comes out in 3.0, I'll see about getting that into the vendor abi,
and with luck, gcc will be able to achieve abi compatibility with it.

If I missed ansering an important question that I can help with, let
me know.  I feel like I must have missed something.