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

>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?

>>Can you elaborate on what, exactly, you expect from gcc developers in
>>the coming months? Would it be possible to explain, in detail, what
>>kinds of patches should go in, and apply this uniformly to all gcc
>>developers at all participating companies?  
>You seem to be implying that there might be some kind of favoritism 
>going on, or perhaps that I gave myself special dispensation.  I don't 
>think that's the case; in fact, I erred on the side of conservatism 
>until prodded by others.

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 like

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

As I've long been in favor of #4, and find the posturing required to do
releases based solely on dates a bit tiring, I'm in favor of this. 

May I suggest you add the ARM EABI bits to:

or is the GCC 4.0 projects page what should be used for #4?


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