This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] config.gcc: Obsolete c4x.
- From: Ralf Corsepius <ralf dot corsepius at rtems dot org>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: 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, Joel Sherrill <joel dot sherrill at OARcorp dot com>
- Date: Tue, 03 May 2005 18:36:25 +0200
- Subject: Re: [patch] config.gcc: Obsolete c4x.
- References: <20050427.153641.46220426.kazu@cs.umass.edu> <42702A83.4090906@codesourcery.com> <1115113560.24385.452.camel@mccallum.corsepiu.local> <42779D95.6090705@codesourcery.com>
On Tue, 2005-05-03 at 08:49 -0700, Mark Mitchell wrote:
> Ralf Corsepius wrote:
>
> > 1. I don't recall any consensus on abandoning QImode!=8bits.
>
> I don't think this issue is relevant in terms of considering whether or
> not to obsolete the C4X port. Whether or not QImode is always 8 bits is
> a fine debate, but it's a separate debate. I certainly was not taking a
> position on that debate in approving the obsoletion request.
You have "sanctioned/approved" the patch, so you are establishing facts,
and thereby are taking a position.
> Independent of the size of QImode, I think that everyone agrees that
> supporting targets with > 8-bit minimum addressable units is a useful thing.
And how do you want to test it? Is there any other target in GCC but the
c4x, which applies QImode != 8bits?
To me, it's primarily the QImode aspect which makes the c4x interesting
for testing portability of SW. The port may be generating invalid code,
it may be defect, but ...
> > 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.
>
> Yes, and that is evidence that the platform is indeed obsolete.
May-be, may-be not, a matter of perspective.
I am inclined to consider the actual cause to be flaws in GCC's
regression testing and regression fixing policy.
I really don't know what broke the c4x, but I know that GCC's regression
processing policy is ignoring problems on "non-primary target" ("It's
not a regression, because it's not a primary target, therefore you are
closed out from fixing anything on during most stages of development").
> Nobody was willing to invest in making it work in GCC 4.0.
And? So what?
There are other targets in a similar position as the c4x, e.g. currently
the m68k, the avr, the h8xxx or (at certain stages throughout 3.x->4.0
development) the sparc.
Ralf