RE: Unreviewed 2.95.4 patches since April 1st

[David Korn <dkorn at pixelpower dot com>]

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

  VxWorks is different from other OS's, in that the C++ ABI is incorporated
into the OS.  To make 3.0 work with the existing vxworks series 5 OS
would require re-implementing the old style of name mangling and class
layout.  That seems a non-starter to me.

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

  It's not compatibility with 272 that I want, it is a compiler that
generates correct code for the operating system's calling conventions.

  272 generated correct code for vxworks, but broken code for EABI.  When
the EABI code generation was fixed, the VxWorks code generation was broken.
This breakage occurred because of the unexamined assumption that VxWorks
was an EABI compliant OS.  Although that may have been the intention, it
is not and never has been the case; the need for object level compatibility
has effectively frozen the OS's ABI design, and *to this day* VxWorks 
simply does not longword align floating point doubles.  The cpu has no
problem with this, the OS libraries have no problem with this, it's a 
pretty arbitrary design decision; why on earth shouldn't Gcc generate code
for it?

  I just want a compiler that generates code that is compatible with the
OS libraries.  272 did that; 2952 doesn't.  Gcc changed, the OS that it
supposedly generates code for remained the same.  Hence I reason that Gcc
is broken.

>>   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 clearly said 'powerpc-wrs-vxworks'.  To the best of my knowledge, the
other vxworks targets are OK out-of-the-box.

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

  I'm not sure I understand this.  There isn't a 2.95.4 release branch yet
(to the best of my knowledge), and I don't see what's unsuitable about my
patch for the 2.95.x mainline.  Or do you mean that a patch to the 2.95
series can only be accepted if it works for 3.0 main?  That would seem to
preclude ever fixing any problems in areas of code that have gone away 
since 2.95.x?  Can you elaborate on this paragraph for me, please?

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

  As I understand it, having already spoken to him, WRS is moving ahead
with a new version of their OS (vxworks 6, aka vxworks AE) that will 
run with a 2.96 descended compiler.  They are planning an updated 2.95
series compiler but are pressed for resources and may or may not be able
to devote the time and energy to preparing and submitting patches for the
FSF source tree.  That being the case, and people wanting to download the
sources and build it themselves, I can't see the terrible disadvantage
of fixing 2.95.4.

  If there was a bug in Solaris code generation, would you tell someone
who volunteered to fix it that they should wait for Sun to do so?

     DaveK
-- 
 All your base are belong to the Israeli army!  Oh, now they aren't again!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************