This is the mail archive of the
mailing list for the GCC project.
Re: Backporting Patches to GCC 7
- From: Palmer Dabbelt <palmer at dabbelt dot com>
- To: richard dot guenther at gmail dot com
- Cc: jwakely dot gcc at gmail dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 10 May 2017 08:36:18 -0700 (PDT)
- Subject: Re: Backporting Patches to GCC 7
- Authentication-results: sourceware.org; auth=none
On Wed, 10 May 2017 01:35:11 PDT (-0700), email@example.com wrote:
> On Wed, May 10, 2017 at 2:31 AM, Palmer Dabbelt <firstname.lastname@example.org> wrote:
>> On Tue, 09 May 2017 01:50:42 PDT (-0700), email@example.com wrote:
>>> On Mon, May 8, 2017 at 10:00 PM, Jonathan Wakely <firstname.lastname@example.org> wrote:
>>>> On 5 May 2017 at 21:35, Palmer Dabbelt wrote:
>>>>> I just submitted two patches against trunk. I'd like to also have them on the
>>>>> 7 branch, so when 7.2 comes out we'll have them. These patches only touch the
>>>>> RISC-V backend, which I'm a maintainer of. Is there a branch maintainer I'm
>>>>> supposed to have sign off on the patches or am I meant to just decide on my own
>>>>> what I should commit?
>>>>> For reference, here's the patches
>>>>> 284b54c RISC-V: Add -mstrict-align option
>>>>> 70218e8 RISC-V: Unify indention in riscv.md
>>>> In general, backports that aren't fixing regressions or documentation
>>>> would need release managers approval. There's some leeway for target
>>>> maintainers of ports and other subsystems, for example I sometimes
>>>> make executive decisions about the C++ runtime libraries when the
>>>> backport only affects an isolated part of the library, or is clearly
>>>> safe and an obvious improvement. For bigger changes that aren't
>>>> regressions but I'd like to backport I still seek RM approval.
>>>> I would guess that for RISC-V which is new in 7.1, if you think the
>>>> backport is important and it doesn't affect other targets then it
>>>> should be OK.
>>>> Maybe one of the release managers can confirm that though.
>>> Generally all maintainers can also approve backports.
>> OK, thanks. Since the RISC-V port is so new I'd like to be a bit aggressive
>> about backporting our fixes. If this goes anything like binutils did, there's
>> going to be a handful of bug fixes that trickle in over the next few weeks as
>> more people start using the port now that there's a release. For example,
>> we've got a few patches in the pipeline that get our -mcmodel=medany working
>> passing the test suite.
>> Is it OK if I pretty much just backport everything RISC-V related to
>> gcc-7-branch, as long as it doesn't touch any other port? I can ping you about
>> each patch if you'd like.
> Backporting patches that just affect RISC-V (aka in gcc/config/riscv/) is fine.
> RISC-V is neither a primary nor secondary target so bugs (or failure to build)
> does not block doing releases from the branch so it's your responsibility to
> make sure the port stays healthy on the branch.