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:

My opinion:

* If the C4x stays, it will rot.

* If the C4x will be removed, you are substantially reducing
opportunities to fix it. As the C4x's QImode is different from all other
targets in GCC, this is equivalent to announcing "QImode!=8bits" dead in

We're just going to have disagree here. I didn't say that, and I don't have an opinion on it.

I guess you can claim that I implied that, but I didn't. In fact, I've explicitly repudiated the implication several times.

A problem is "important" to _you_ (FSF GCC leadership/maintainers) when
it is a "regression" according to _your_ definition. Your definition
doesn't necessarily match with ours nor with our (RTEMS) demands.

As a result of this, many of our problems appear not important to _you_,
so many of our problems end up being considered irrelevant and ignored
by you - We (RTEMS) are stuck in a vicious circle.

Yes, we've set ourselves particular priorities -- but we're not interfering with other people doing other things. I could put whatever I wanted in our release criteria, and it still wouldn't persuade me to fix C4x bugs. I just have no interest in that chip. Now, if a customer came along asking me for a C4x port, I'd be a busy little beaver fixing bugs.

It's not my/our fault that C4x isn't being maintained. It's not your fault either.

I.e. we typically trip bugs which seem "extraterrestrial" and "corner
cases" to "mainstream maintainers".

All in all, this is a completely different situation than that of
"mainstream GCC developers".

Exactly. That's why if you care about these things you're going to have to invest effort. I don't think that I/we have any particular responsibility to do anything -- accept that I do think the SC should accept and act on nominations for port maintainers. And maintainers should try to review patches to common code that are appropriately submitted.

It turns out that you may not have even understood what actually happened. At least, I didn't. All Kazu did was mark the target as obsolete. The bits are still there. You can still build it on the 4.0 branch and on the mainline. If someone steps up to maintain the port, it will live on. Otherwise, we'll remove it for 4.1.

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]