This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
(916) 791-8304

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]