4.4 deprecation proposals

4.4 deprecation proposals

[Joseph S. Myers]

We need to consider what targets and other features, if any, to
deprecate or remove in GCC 4.4.

I previously suggested the deprecation or removal of protoize and
fixproto <http://gcc.gnu.org/ml/gcc/2008-05/msg00286.html>, without
any comments or objections being made, and have now disabled fixproto
for almost all targets that were using it.  The following targets
remain using fixproto: hppa[12]*-*-hpux10*, mips-sgi-irix[56]*,
pdp11-*-bsd, rs6000-ibm-aix4.[12]* | powerpc-ibm-aix4.[12]*.  I
propose that we deprecate "all targets using fixproto" for 4.4.  That
is, some time before 4.4 branches any of these targets still using
fixproto would be placed on the deprecation list, and removal from it
would require stopping a target from using fixproto (for example,
making fixincludes add all necessary prototypes applicable to the
target being undeprecated, or simply removing the use of fixproto if
no such prototypes need to be added).  fixproto could be removed from
trunk either when the targets are added to the deprecation list, or
when deprecated targets are removed after 4.4.0 is released.  (Note
that hppa[12]*-*-hpux10* has had 4.4 test results posted, so would not
be a deprecation candidate on the basis of being unused, and it
appears some patches have been tested on IRIX although no 4.4 test
results have been posted.)

For protoize, I propose that we do one of the following:

* Deprecate it in the 4.4 release notes (without any configure changes
  to make people use --enable-obsolete if building it, just
  documenting it as deprecated), and remove from trunk after 4.4.0 is
  released.

* Remove from trunk before 4.4 branches, on the basis that it having
  been disabled by default since
  <http://gcc.gnu.org/ml/gcc-patches/1999-10n/msg00451.html> (patch
  submission:
  <http://gcc.gnu.org/ml/gcc-patches/1999-09n/msg00164.html>) is
  plenty of deprecation warning.  People were thinking it might be
  obsolete as of
  <http://gcc.gnu.org/ml/gcc-patches/1999-08n/msg00636.html>.

I request further comment on which of these approaches to take.

In either case, removal of support for protoize would be accompanied
by removal of support for installing the SYSCALLS.c.X file that it
uses; any externally maintained distribution would need to maintain
this and any other required files itself.  (Given that there do appear
from Google Code Search to be a few external users of the -aux-info
option, I do not propose removing it along with protoize.  We might
however consider deprecating and removing it in future, especially if
any system is implemented for exporting more structured information
about programs being compiled from GCC.)

As for target CPU deprecations, the IRA transition strategy
<http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01812.html> indicates
the way forward.  With the plan to remove the old RA, each target will
need an IRA_COVER_CLASSES definition added to continue to work.  If
someone is willing to add this for a target, verify that the target
works with it added and fix any problems found, that will serve as
evidence that the target is still maintained (on the basis I used for
the 4.3 deprecations that either a test results posting or a patch
mentioned as testing on a target indicated it was not obsolete).  If
not, the target will not work anyway.  Thus, I propose that at the
point when the old register allocator is removed, any unconverted CPU
targets are added to the deprecation list, with removal requiring
conversion of a target to IRA.

It remains to consider the question of deprecations of target OSes or
(CPU, OS) pairs.  My only proposal here is to deprecate the generic
a.out and COFF targets where there is a corresponding ELF target; no
4.4 test results have been posted for any such targets.  The targets
affected would be:

arm-*-coff*
armel-*-coff*
h8300-*-* (generic meaning COFF only - other h8300 would remain)
i[34567]86-*-aout*
i[34567]86-*-coff*
m68k-*-aout*
m68k-*-coff*
sh-*-* (generic meaning COFF only - other sh would remain)

Where there is a catch-all -*-* meaning COFF, it could also be changed
to meaning ELF instead of removing the catch-all case.

People may of course wish to propose other OSes, individual targets or
other features for deprecation in 4.4.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: 4.4 deprecation proposals

[Manuel López-Ibáñez]

2008/6/14 Joseph S. Myers <joseph@codesourcery.com>:
> We need to consider what targets and other features, if any, to
> deprecate or remove in GCC 4.4.
>
> I previously suggested the deprecation or removal of protoize and
> fixproto <http://gcc.gnu.org/ml/gcc/2008-05/msg00286.html>, without

If we remove protoize, we could probably remove the
Wtraditional-conversion option, since its only use seems to be related
to protoize: http://gcc.gnu.org/onlinedocs/gcc/Protoize-Caveats.html

That would remove half of convert_arguments (c-typeck.c) and we will
have one less flag!

If a C maintainer agrees, I volunteer to write the patch.

Cheers,

Manuel.

Re: 4.4 deprecation proposals

[DJ Delorie]

"Joseph S. Myers" <joseph@codesourcery.com> writes:
> i[34567]86-*-coff*

DJGPP is ix86-coff - how would this deprecation affect djgpp?

Re: 4.4 deprecation proposals

[Joseph S. Myers]

On Sun, 15 Jun 2008, DJ Delorie wrote:

> "Joseph S. Myers" <joseph@codesourcery.com> writes:
> > i[34567]86-*-coff*
> 
> DJGPP is ix86-coff - how would this deprecation affect djgpp?

I thought DJGPP was i[34567]86-pc-msdosdjgpp*.  I do not think having 
generic CPU-*-OBJFMT triplets that really refer to a particular OS is a 
good idea.  It's only certain generic triplets I'm proposing to deprecate.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: 4.4 deprecation proposals

[DJ Delorie]

> I thought DJGPP was i[34567]86-pc-msdosdjgpp*.  I do not think
> having generic CPU-*-OBJFMT triplets that really refer to a
> particular OS is a good idea.  It's only certain generic triplets
> I'm proposing to deprecate.

DJGPP is ix86-pc-msdosdjgpp, yes.  However, it's based on the
ix86-coff code (djgpp is coff-based) but not 100% binary compatible
(mostly due to the dos stub, but also due to preprocessor defines,
libraries, etc).

Likewise, Cygwin and MinGW are based on the ix86-coff code but with PE
stubs and support for DLLs and such.

Re: 4.4 deprecation proposals

[Ian Lance Taylor]

DJ Delorie <dj@redhat.com> writes:

>> I thought DJGPP was i[34567]86-pc-msdosdjgpp*.  I do not think
>> having generic CPU-*-OBJFMT triplets that really refer to a
>> particular OS is a good idea.  It's only certain generic triplets
>> I'm proposing to deprecate.
>
> DJGPP is ix86-pc-msdosdjgpp, yes.  However, it's based on the
> ix86-coff code (djgpp is coff-based) but not 100% binary compatible
> (mostly due to the dos stub, but also due to preprocessor defines,
> libraries, etc).
>
> Likewise, Cygwin and MinGW are based on the ix86-coff code but with PE
> stubs and support for DLLs and such.

My understanding is that Joseph is just talking about removing the
entries in config.gcc.  He is not talking about removing the support
in the code, except perhaps for cases where there is no longer any
entry in config.gcc which requires that support.

Ian

Re: 4.4 deprecation proposals

[Joseph S. Myers]

On Sun, 15 Jun 2008, Ian Lance Taylor wrote:

> My understanding is that Joseph is just talking about removing the
> entries in config.gcc.  He is not talking about removing the support
> in the code, except perhaps for cases where there is no longer any
> entry in config.gcc which requires that support.

Correct (libgcc/config.host, target patterns in testcases etc. are also 
covered).  Files in config/ are only removed when no configuration uses 
them.  If a file is removed while still being used by another target, 
that's a mistake and the file should be restored; if a file (formerly used 
by some targets) remains while no target uses it, that's also a mistake 
and it should be removed.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: 4.4 deprecation proposals

[Ben Elliston]

On Sat, 2008-06-14 at 18:53 +0000, Joseph S. Myers wrote:

> m68k-*-aout*
> m68k-*-coff*

These would be fine with me; there has been no interest in these targets
in binutils-land for some time.

Ben