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 Earnshaw <rearnsha at arm dot com>
- To: Richard Guenther <richard dot guenther at gmail 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, 07 Dec 2011 13:32:57 +0000
- 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>
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.
R.