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: please clarify criteria for gcc-4.0.0 patches

Benjamin Kosnik wrote:

The patch you reference is in the same category: it is required for conformance to the ARM EABI. Personally, I am very ambivalent about these patches. I'd be just as happy to take them out again, if that would make people happier. In fact, when I posted a message a while back about Stage 3, I specifically indicated that language and architecture issues would be to some extent delegated to their respective maintainers. The COMDAT patch is not in this category, but the patch you reference is. If you believe that my patch is too risky for Stage 3 devleopment in V3, let me know, and I will remove it.

I don't have a technical problem with this ARM EABI patch per se, I'm just confused about what I should be checking in.

I guess ARM EABI work is considered a must-have feature for gcc-4.0.0?

I expect that depends on who you ask. :-)

We don't have many must-have features; in fact, at this point, the only one we've really got is Objective-C++, because the SC promised Zem a shot at integrating it. With my RM hat on, I certainly do not see ARM EABI as a must-have for GCC 4.0; if it's not done, we'll ship anyhow. However, I expect that the ARM maintainers will use the dispensation I've provided to back-end and language maintainers to accept EABI patches. That's up to them, though.

I still think you do a great job as chief cat herder! I'm just
confused as to what is a legitimate fix, and what is something that is
not appropriate for mainline, and hoping you'll help me come up with
some kind of more rigorous criteria that I can use as a guide.

From the development information, it seems like the changes allowed are
1) documentation patches
2) bug fixes
3) new ports

This seems sane to me.

Yes, that's correct -- except that for this release, we're doing an experimental process whereby backend and language maintainers have a little more leeway to accept patches that they think are very important, even if they don't quite fit in here.

In addition, from your answer to the above, it looks like

4) new features as required to meet feature goals for the release.

I don't think that's accurate. The projects list (based on the submissions that people provided) will be accepted if submitted before the deliver-by dates; otherwise, we'll do the release without those features. So far, it looks like people are working hard to hit the target dates, so I am encouraged.

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]