This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Target deprecation, round three
- From: Zack Weinberg <zack at codesourcery dot com>
- To: gcc at gcc dot gnu dot org
- Cc: Nick Burrett <nick dot burrett at btinternet dot com>, David Edelsohn <dje at watson dot ibm dot com>, Hans-Peter Nillson <hans-peter dot nilsson at axis dot com>, Carl Miller <chaz at energoncube dot net>, Rick Sustek <rsustek at cisco dot com>
- Date: Sun, 23 Feb 2003 21:47:43 -0800
- Subject: Target deprecation, round three
Let's try to get a final list for deprecations in the 3.3 release by
the end of the week. I once again have to apologize for dropping the
ball.
The majority of the targets on my "round two" list
(http://gcc.gnu.org/ml/gcc/2002-12/msg00702.html) went over without
comment. With a couple of exceptions I've dropped the targets which
someone spoke up in favor of; let's discuss the exceptions a bit more
carefully. (If your favorite target is still on the list, speak up!
If you did already, it means I lost your mail; my apologies, and
please remind me.)
I'm pushing back on the following:
i370-*-*
All respect to the people who continue working on this back end, but
they are doing so outside the official repository and have shown no
interest in merging their work back. Also, this is the same
architecture as the s390-*-* back end, which is actively maintained.
It would be better for the health of the compiler as a whole if that
back end were augmented to support the things that it currently
doesn't but the i370 back end does.
Note that this is the only back end which defines HOST_EBCDIC and
TARGET_EBCDIC. There is no difficulty in continuing to support
TARGET_EBCDIC - the s390 back end might plausibly want to use it in
the future - but supporting HOST_EBCDIC in conjunction with certain
features of C99 (which effectively require internal use of the ISO
10646 aka Unicode charset) would force us to make substantial
changes to the C front end that would leave it much harder to
maintain. (The short version is that character constants could not
be used anywhere.) Thus I would like to drop HOST_EBCDIC
permanently at the same time this target is removed. This does
*not* mean the compiler will be unable to accept input files encoded
in EBCDIC; it only means that it will itself need to be built in an
environment where the execution character set is a superset of ASCII.
alpha*-*-linux*libc1*
i?86-*-linux*libc1*
m68k-*-linux*libc1*
powerpc*-*-linux*libc1*
sparc-*-linux*libc1*
I received a couple of messages expressing continued interest in
some of these targets. I have no problem keeping those that are
actually used; however, I am not clear on which those are. Is it
just ix86, or are others in use too, and if so which ones?
arm*-*-aof*
This target is responsible for masses of #ifdefs all over the ARM
back end. Is it *really* necessary to continue using this rather
quirky assembler? Could you perhaps move to GAS and arm-elf
instead?
m68k-sun-sunos*
sparc-sun-sunos*
These targets are hosted systems with C libraries that predate C89,
which means they impose disproportionate maintenance burdens. They
have long since been EOLed by Sun. Please advise whether you really
need a 3.x GCC for these targets.
In addition to target deprecation, I would also like to propose the
removal of support for DWARF version 1. There are only two target
patterns that request DWARF 1 but not DWARF 2: mips-sni-sysv4, which
is already on the deprecation list, and arc-*-*, which I see no
intrinsic reason why it couldn't migrate to DWARF 2; it is already an
ELF target. Tangentially, my impression is that the ARC target itself
is still actively maintained, but I am not sure. Please speak up if
you have a current need for this target.
zw
Current list of targets to deprecate:
i370-*-*
i960-*-*
m88k-*-*
romp-*-*
alpha*-*-interix*
alpha*-*-linux*libc1*
arm*-*-aout*
arm*-*-aof*
arm*-*-conix*
arm*-*-oabi
strongarm-*-coff*
hppa1.0-*-osf*
hppa1.0-*-bsd*
hppa1.[01]-*-hpux[789]*
hppa*-*-hiux*
hppa*-*-lites*
hppa*-*-mpeix*
i?86-ncr-*
i?86-sequent-*
i?86-moss-*
i?86-*-netware
i?86-*-freebsd2*
i?86-*-netbsd*aout*
i?86-*-coff*
i?86-*-linux*aout*
i?86-*-linux*libc1
i?86-*-moss*
i?86-*-sysv3*
i?86-*-vsta
i?86-*-interix # not interix3
m68000-hp-bsd*
m68000-hp-hpux*
m68000-sun-sunos*
m68000-att-sysv*
m68k-atari-sysv*
m68k-motorola-sysv*
m68k-ncr-sysv*
m68k-plexus-sysv*
m68k-tti-*
m68k-crds-unos*
m68k-cbm-sysv*
m68k-ccur-rtu*
m68k-hp-bsd*
m68k-hp-hpux*
m68k-sun-mach*
m68k-sun-sunos*
m68k-*-linux*aout*
m68k-*-linux*libc1
m68k-*-psos*
mips*-*-ecoff*
mips-sni-sysv4
powerpc*-*-sysv* # the generic one only
powerpc*-*-linux*libc1
rs6000-ibm-aix[123]*
rs6000-bull-bosx
rs6000-*-mach*
sparc-*-aout*
sparc-*-netbsd*aout*
sparc-*-bsd*
sparc-*-chorusos*
sparc-*-linux*aout*
sparc-*-linux*libc1*
sparc-*-lynxos*
sparc-hal-solaris2*
sparc-*-sunos[34]*
sparclet-*-aout*
sparclite-*-coff*
sparclite-*-aout*
sparc86x-*-aout*
vax-*-bsd*
vax-*-sysv*
vax-*-netbsd*aout*
vax-*-vms*
- Follow-Ups:
- Re: Target deprecation, round three
- Re: Target deprecation, round three
- arc-*-* was Re: Target deprecation, round three
- Re: Target deprecation, round three
- Re: Target deprecation, round three
- Re: Target deprecation, round three
- Re: Target deprecation, round three
- Re: Target deprecation, round three
- Re: Target deprecation, round three
- Re: Target deprecation, round three