Re: [patch] config.gcc: Obsolete c4x.

[Mark Mitchell <mark at codesourcery dot com>]

Ralf Corsepius wrote:
> > I've taken a position on obsoleting C4X, but I've not taken one on the 
> > QImode issue.  To equate the two is unfair.
>  
> I disagree.

I don't know where to go from here.  I guess we just disagree.

Fundamentally, we can just give the stock answer: if you care about C4x 
support, then you can maintain the C4x port or pay someone to do so. 
Otherwise, it will rot.  To some extent, obsoleting the port may 
accelerate its demise -- but certainly, if someone wants to resurrect 
the port, they can step forward and do so.  Anyone sufficiently 
motivated to actually maintain the port can certainly invest the initial 
effort to do the resurrecton.

> > 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?
>
> Code clarity in RTEMS, newlib and applications.

Code clarity in these applications is dependent on GCC having a port 
with QImode != 8 bits?  Or a port with CHAR_BITS != 8?

> > > 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.
>
>
> This does not match with my experience.
>
> I have been frequently been facing situations, where PRs had been
> postponed and ignored just because the target being affected is "not a
> primary target" or "will not be fixed, because it is not a regression".

These issues apply to whether or not we consider a bug important for a 
release.  It has nothing to do with whether or not you can fix the bug, 
except that the latter criterion might prevent a bug from being fixed on 
a release branch.

> Just check bugzilla for my name and you'll find several PR pending
> unfixed because of this. Some have fixes attached, some even are
> trivially fixable ... 

Then, apparently none of the maintainers considered it worthwhile to 
review and/or apply the fixes.  Again, if you care about C4x, you're 
going to need to find a maintainer for it.  Speaking as a maintainer, 
with a lot of demands on my time, I probably would never review a C4x 
patch -- it's just not relevant to me.

> > and SPARC are certainly not in the category,
>
> The sparc was broken for all non-unix target throughout the whole
> gcc-3.x series - gcc-4.0.0 is the first gcc since (IIRC) 3.2 which able
> to build RTEMS for the sparc.

Well, "broken" is a pretty strong statement, seeing as we've built SPARC 
Solaris compilers throughout that entire period.  I don't doubt that 
there were bugs.  Fundamentally, though, building compilers that work 
for RTEMS isn't any FSF volunteer's responsibility.  Of course, fixing 
regressions *is* a responsibility, and if you posted analysis showing 
who broke SPARC and they didn't fix it, then that's a problem.  But, 
it's still a different problem than obsoleting C4x.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304