[google] Backport r171347 and r181549 from trunk (strict volatile bitfield) (issue5434084)

[Richard Guenther]

On Wed, Dec 7, 2011 at 2:32 PM, Richard Earnshaw <rearnsha@arm.com> wrote:
> On 07/12/11 13:02, Richard Guenther wrote:
>> On Wed, Dec 7, 2011 at 1:34 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>>> On Tue, Nov 29, 2011 at 05:59:53PM -0800, Doug Kwan wrote:
>>>>     This is a backport for two upstream patches into our 4.6 branch.
>>>> I submitted the first patch by Julian a while ago for backport but
>>>> Richard Earnshaw pointed out a problem with the first patch.  The second
>>>> patch from Joey fixes that problem.  This was tested on x86 and ARM.
>>>
>>> Why hasn't this been proposed for upstream 4.6 instead?
>>> See PR51442.
>>
>> It's indeed annoying to see arm related backports only going to
>> vendor branches, not the last officially maintained GCC release
>> branch (4.6).  I keep getting local requests to include random
>> patches to our 4.6 build to make "arm work at all".  It seriously
>> seems like having arm-linux-gnueabi as a primary target is a lie to our users.
>>
>> Arm maintainers - please consider maintaining at least the current
>> release series and shift focus away from your vendor branches.
>>
>
> So this, to some extent seems to conflict with your rules for only fixing
> regressions.  This code has always been broken in one way or another,
> so technically this doesn't qualify for the 4.6 branch.
>
> I think we need clearer rules (on the web site, not in a mailing list post)
> that describes which patches are considered acceptable on the branch and
> which are not.

We generally accept wrong-code fixes (or rejects-valid) that are
low-risk.  Target maintainers have complete freedom for their
targets provided a fix is really target-only (we even accept new
ports or new ISAs on branches, well - in theory at least).

If a maintainer thinks backporting a fix is important he can always
defer to a release manager for a final decision.

What we generally do not want is new middle-end functionality.
And we generally raise the barrier for "low-risk" the more mature
a branch is.

As a general rule, if you'd point users to "use the arm-embedded
branch" for bugreports you get, then you are doing sth wrong.
If you say, "use the arm-embedded branch" to get smaller/faster
code - well, that's ok.  Pointing people to the latest official
release series (in this case 4.6.x) is also ok, we're keeping too
many branches active IMNSHO.

Richard.

> R.
>