This is the mail archive of the
mailing list for the GCC project.
Re: please clarify criteria for gcc-4.0.0 patches
Benjamin Kosnik wrote:
I expect that depends on who you ask. :-)
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?
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.
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.
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.
In addition, from your answer to the above, it looks likeI 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.
4) new features as required to meet feature goals for the release.