This is the mail archive of the gcc-patches@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]

Re: Unreviewed 2.95.4 patches since April 1st


David Korn <dkorn@pixelpower.com> writes:

> >From: Bernd Schmidt [mailto:bernds@redhat.com]

> >If we don't support it in 3.0 and the mainline, it shouldn't go into 
> >2.95 either.
> 
>   I don't see why this follows.  3.0 simply cannot be made to work for the
> existing VxWorks operating system, and hence it is irrelevant.  There is
> a major difference between 2.95 and 3.0, caused by the new ABI; this
> means that the question of whether something is suitable for one does not
> necessarily relate to the question of whether it is suitable for the other.
> Further, 3.x is the line of future development; 2.95 still exists for 
> those who need backward compatibility - else why bother with it at all -
> and so the two different branches exist to serve different purposes.

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.

>   I forget who it was, but one of Geoff and David encouraged me to rework
> my patches for v3; this is impossible because of the ABI barrier, but
> doesn't seem to indicate a vehement unwillingness to have gcc work with
> the vxworks OS to me.
> 
>   At present, the compiler will not even build for the powerpc-wrs-vxworks
> target.  That's due to a problem in gen-params causing the build of
> libstdc++ to fail.  Even if this is fixed, or if you build the compiler with
> only C enabled, the code it produces is *incorrect* - it generates code that
> adheres to a different ABI than the VxWorks ABI.  We can argue semantics
> about whether it is a bug in the OS because it doesn't adhere to the EABI,
> or a bug in Gcc because it generates EABI code for a target that is not
> an EABI target, but that seems silly to me: as far as I'm concerned, an OS
> defines its own ABI and the mere fact that that ABI resembles or is based
> upon another does not make that OS broken simply because it does things
> differently.  So Gcc is broken because it does not comply with the OS's
> ABI.

Yes.  However, work on such major changes should go on in the
mainline, not the release branch.  All the argument you are making
here would apply equally well to the 3.0 release and to all future
releases.

>   If there has been a decision not to support the powerpc-wrs-vxworks
> target, it should be removed, not just left broken.  If it is not going to
> be removed, it should be fixed.  Just leaving broken code in the compiler
> and doing nothing about it is the worst of all possible worlds.

There are, unfortunately, lots of targets that don't work in GCC.
Clearly this is one of them.  If it's causing confusion, and you're
quite sure it can never work, we can take out support for this target
altogether.  Are you sure that _all_ vxworks targets don't work, not
just the one version that you're using?  I'm sure I've heard success
reports.

>   I let this drop over 2.95.3 because it was too close to the release date
> when I heard about it, and I understood your motivation to keep things
> simple and avoid unnecessary risks.  But it is still a bug fix and Gcc is
> still incorrect, and the much-needed bugfix release has now been done, and
> isn't it time to consider some slightly more ambitious goals ?  I really
> cannot understand, now the pressure is off, why you should be so set against
> the notion of fixing an old and bitrotten target.

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.

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

-- 
- Geoffrey Keating <geoffk@geoffk.org>


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