This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [google] Backport r171347 and r181549 from trunk (strict volatile bitfield) (issue5434084)
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Richard Earnshaw <rearnsha at arm dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Doug Kwan <dougkwan at google dot com>, "reply at codereview dot appspotmail dot com" <reply at codereview dot appspotmail dot com>, "dnovillo at google dot com" <dnovillo at google dot com>, "jingyu at google dot com" <jingyu at google dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 7 Dec 2011 15:00:07 +0100
- Subject: Re: [google] Backport r171347 and r181549 from trunk (strict volatile bitfield) (issue5434084)
- References: <20111130015953.5621C205C5@atree.mtv.corp.google.com> <20111207123412.GA1957@tyan-ft48-01.lab.bos.redhat.com> <CAFiYyc0pRuLiLpinMvn3TUQbKKyCfQmqgM-xhoi-eTxQUtAFHg@mail.gmail.com> <4EDF6B09.6030602@arm.com>
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.
>