[Patch,AVR,trunk,4.7] PR52461: Fix RAMPZ clobbering and RAMP* in epilogue

[Georg-Johann Lay]

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.