This is the mail archive of the
mailing list for the GCC project.
Re: Obsoleting c4x last minute for 4.0
- From: Daniel Jacobowitz <drow at false dot org>
- To: Paul Schlie <schlie at comcast dot net>
- Cc: Kazu Hirata <kazu at cs dot umass dot edu>, gcc at gcc dot gnu dot org, mark at codesourcery dot com,m dot hayes at elec dot canterbury dot ac dot nz,Richard Sandiford <rsandifo at redhat dot com>
- Date: Tue, 5 Apr 2005 16:26:11 -0400
- Subject: Re: Obsoleting c4x last minute for 4.0
- References: <BE785197.9B64email@example.com>
On Tue, Apr 05, 2005 at 02:30:47PM -0400, Paul Schlie wrote:
> > Kazu Hirata <kazu at cs dot umass dot edu> wrote:
> > I would like to propose that the c4x port be obsoleted for 4.0.
> > c4x-*
> > tic4x-*
> > The primary reason is that the port doesn't build.
> > Richard Sandiford's recent patch allows us to go further during the
> > build process, but the port still does not build.
> Although personally believe the port's use of a 32-bit QI mode is odd
> (and should be enabled by GCC to be defined as SI mode without QI/HI modes
> being required, where correspondingly BITS_PER_UNIT should being presumed
> to represent just the minimum alignment required by the port not
> necessarily the width of QI mode which should likely be defined as the
> width of the target's byte separately), it would still be nice to see GCC
> cleaned to enable the port to build as it stresses the few remaining
> assumptions scattered though out the source which should be eliminated.
This is a bogus reason to preserve the port; it should be preserved iff
it works, is maintained, and is used. It's failing #1 at least.
If you want these restrictions fixed, presumably you have some interest
in some port that cares about them. Contribute that port, and maybe a
usable simulator for them, and then people can fix what breaks - and