From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16180 invoked by alias); 14 Jun 2008 18:54:21 -0000 Received: (qmail 16172 invoked by uid 22791); 14 Jun 2008 18:54:20 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 14 Jun 2008 18:53:53 +0000 Received: (qmail 22488 invoked from network); 14 Jun 2008 18:53:51 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Jun 2008 18:53:51 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.68) (envelope-from ) id 1K7asn-0000FB-V8 for gcc@gcc.gnu.org; Sat, 14 Jun 2008 18:53:49 +0000 Date: Sat, 14 Jun 2008 18:54:00 -0000 From: "Joseph S. Myers" To: gcc@gcc.gnu.org Subject: 4.4 deprecation proposals Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2008-06/txt/msg00324.txt.bz2 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 , 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 (patch submission: ) is plenty of deprecation warning. People were thinking it might be obsolete as of . 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 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