Re: [PATCH 2.95.3 - WITHDRAWN] Fix powerpc-wrs-vxworks eabi backw ards incompatibility.

[David Edelsohn <dje at watson dot ibm dot com>]

	Compatibility with gcc-2.7.2 is not just a VxWorks compatibility
mode.  This affects other vendors which released products based on
gcc-2.7.2, such as Cygnus (now Red Hat).

	The DFmode alignment issue was discussed among the GCC PowerPC
target maintainers, PowerPC developers, and others.  We agreed at the end
of the discussion (which extended over a year) to correct the
implementation of the ABI in the compiler and that vendors would shoulder
the responsibility of compatibility.  The developers affected by the
change were using vendor releases and not the GCC public sources.  The bug
created incompatibility with compilers and object files produced by others
which conform to the correct eABI.

	We can revisit this decision, but I am not confident that the
discussion would be useful.

	Free Software is exactly what gives you the ability to create and
disseminate patches to provide backward compatibility with gcc-2.7.2.  I
encourage you to make them widely available.  I encourage you and WRS and
Red Hat to work together on this compatibility functionality if it is
useful to any of you.  The patches are very helpful to a group of people,
but not every useful patch should be incorporated into the public GCC
sources. 

	Your patches for backward compatibility are NOT addressing a bug
in gcc-2.95, so your patches are not appropriate in a bug fix release.
The bug was in gcc-2.7.2, not gcc-2.95.  Most GCC developers used the
fixed version of the compiler in the development branch which is why this
problem primarily affected commercial vendors.  Backward compatibility is
a new feature.

	I would like to see the CALL_V4_SET_FP_ARGS patch separated out.
If the current implementation has a bug in its use of those macro names,
it should be fixed.  That part of the patch may fix a bug (at least a
documentation bug) in the current development sources.

	The next release of GCC will be gcc-3.0 which, as its major number
suggests, explicitly and intentionally breaks compatibility.  To me, that
is another strong motivation to avoid introducing backward compatibility
mode at this time.

	Maintaining and verifying a backward compatibility mode is a
maintenance burden.  I do not feel that it is good use of GCC developers
time to introduce backward compatibility for a five year old release at
this time.

David