This is the mail archive of the gcc-patches@gcc.gnu.org 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,AVR,trunk,4.7] PR52461: Fix RAMPZ clobbering and RAMP* in epilogue


On Mon, Mar 5, 2012 at 6:15 PM, Georg-Johann Lay <avr@gjlay.de> wrote:
> Richard Guenther wrote:
>> On Mon, Mar 5, 2012 at 4:56 PM, Georg-Johann Lay <avr@gjlay.de> wrote:
>>> Richard Guenther wrote:
>>>> On Mon, Mar 5, 2012 at 4:25 PM, Georg-Johann Lay <avr@gjlay.de> wrote:
>>>>> Richard Guenther wrote:
>>>>>
>>>>>> All commits to the 4.7 branch need explicit release manager approval. ?AVR
>>>>>> isn't primary/secondary so please do not change anything before is
>>>>>> released 4.7.0 for it.
>>>>>>
>>>>>> Thanks,
>>>>>> Richard.
>>>>> What is the exact procedure in that case?
>>>>> Wait until approve from release manager in that case?
>>>>> Who is the release manager, and should I CC for such changes?
>>>>> Or just hope the patch is not overseen.
>>>> The exact procedure is to do bugfixing during stage3/4, for release blockers
>>>> that pop up after a release candidate is created (like now), CC a release
>>>> manager (Jakub, me, Joseph) for patches that you like to get in even
>>>> though the branch is frozen. ?Usually only bugs that prevent basic functionality
>>>> (like building a target) can be fixed at this point, for everything
>>>> else you have
>>>> to wait until after 4.7.0 is released and the branch opens again for regression
>>>> fixes.
>>>>
>>>> Richard.
>>> I was not aware that the 4.7.0 branch is completely frozen for the next 3
>>> weeks; I thought the usual rules for backporting patches do apply...
>>
>> No they don't. ?How would you expect that testing a release candidate would
>> work if we put in any not strictly necessary changes? ?That would make a
>> release candidate quite pointless.
>>
>>> The patch changes only in libgcc/config/avr and gcc/config/avr
>>>
>>> The patch does not fix a blocker in the sense that without it avr cannot be
>>> built, but the changes are essential.
>>
>> Surely not so essential as that they cannot be put in place to make the 4.7.1
>> release then.
>
> Okay.
>
> In that case I'd like to add a note to the caveats section in wwwdocs
>
> ./gcc-4.7/changes.html
>
> that the avr-gcc 4.7.0 is not intended for public consumption and because of
> developer shortage at least 4.7.1 should be used.

Completely unusable?  It looks like it only affects a subset of all devices:
"To read from flash on devices with more than 64KiB of flash"

It sounds like a random wrong-code bug, which do happen.

There is just a timeframe where random fixes are not good.

Was 4.6.3 "intended for public consumption"?

Be reasonable.
Richard.


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