This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] config.gcc: Obsolete c4x.
Ralf Corsepius wrote:
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.
I've taken a position on obsoleting C4X, but I've not taken one on the
QImode issue. To equate the two is unfair. Will QImode != 8 bits rot
without C4X? Probably, yes. But, it was rotting anyhow. Did
obsoleting this port make it rot faster? Maybe, but only marginally --
as evidenced by the fact that nobody was using the C4X port. The bottom
line is that non 8-bit QImode is going to rot unless someone actively
maintains a port that needs it.
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?
C4x was hardly an effective testing platform: it didn't work. And if
there are no other ports, then non 8-bit QImode is not a terribly
important thing to test. Are you about to contribute and maintain a
port that uses this functionality? If so, great. If not, what exactly
are we worried about? And how was keeping C4x around, but not
buildable, going to help solve whatever problem it is that we're
concerned about?
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").
As Joseph has said, this statement is simply not true.
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.
If those platforms are not maintained for long periods of time, then,
yes, they'll probably be obsolete. 68K and SPARC are certainly not in
the category, and there seems to be a lot of AVR activity as well. I
don't know about h8xxx.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304