This is the mail archive of the
mailing list for the GCC project.
Re: [patch] config.gcc: Obsolete c4x.
- From: "Joel Sherrill <joel at OARcorp dot com>" <joel dot sherrill at OARcorp dot com>
- To: Ralf Corsepius <ralf dot corsepius at rtems dot org>
- Cc: Mark Mitchell <mark at codesourcery dot com>, Kazu Hirata <kazu at cs dot umass dot edu>,GCC Patches <gcc-patches at gcc dot gnu dot org>, m dot hayes at elec dot canterbury dot ac dot nz, Svein Seldal <Svein at dev dot seldal dot com>
- Date: Tue, 03 May 2005 08:25:29 -0500
- Subject: Re: [patch] config.gcc: Obsolete c4x.
- References: <firstname.lastname@example.org> <42702A83.email@example.com> <firstname.lastname@example.org>
- Reply-to: joel dot sherrill at OARcorp dot com
Svein..I cc'ed you since you might be interested in this.
If so, you are the most active c4x submitter I know of and
thought you might want to get involved in the gcc c4x port.
Ralf Corsepius wrote:
On Wed, 2005-04-27 at 17:12 -0700, Mark Mitchell wrote:
Kazu Hirata wrote:
Attached is a patch to obsolete c4x for both 4.0 and 4.1.
When we discuessed this issue a while ago, there was no interest in
c4x port for code generation purposes. There were some other
interests like using this port to ensure that we are not tied to
QImode == 8 bits.
This matches with my memory, but ...
1. I don't recall any consensus on abandoning QImode!=8bits.
AFAIK, the c4x is the only platform w/ QImode !=8bit in GCC, which
causes your patch to abandoning the only testing platform for such
Are you wanting to abandon QImode != 8bit? This, IMO would qualify as a
serious design defect in GCC (Admitted, we all know GCC has problems
related to this, but abandoning it and means loss of generality)
2. tic4x-gcc-3.4.x is buildable, tic4x-gcc-4.x had never built.
i.e. actually a regression has occurred sometime between 3.4.x and 4.0,
which had slipped through GCC-regression testing cracks.
To me, this is the crux of the matter. This port was buildable in the
last major release and it regressed.
I don't think we want to use the "it broke in a release, obsolete it"
rule. If we do, it won't take long before there are no targets or
languages left and gcc will be easy to maintain because there won't be
any code left. ;)
The sad relatity is that there is not an active maintainer for the c4x
but at the same time, this target got obsoleted too late in the release
process for what is really a regression from 3.4.x to 4.x which no one
wanted to fix.
Tested on i686-pc-linux-gnu. OK to apply?
IMHO: No, you are going too far.
.. As well I consider Mark to be going too far in "nodding off" this
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985