[4.8 branch] PATCH: PR middle-end/53623: [4.7/4.8 Regression] sign extension is effectively split into two x86-64 instructions

[H.J. Lu]

On Mon, Feb 16, 2015 at 5:24 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Feb 16, 2015 at 5:18 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Mon, Feb 16, 2015 at 05:15:02AM -0800, H.J. Lu wrote:
>>> On Mon, Feb 16, 2015 at 4:30 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> > On Mon, Feb 16, 2015 at 1:35 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>>> >> On Sun, Feb 15, 2015 at 12:53:39PM -0800, H.J. Lu wrote:
>>> >>> This is a backport of the patch for PR middle-end/53623 plus all bug
>>> >>> fixes caused by it.  Tested on Linux/x86-32, Linux/x86-64 and x32.  OK
>>> >>> for 4.8 branch?
>>> >>
>>> >> What about PR64286 and PR63659, are you sure those aren't related?
>>> >> I mean, they are on the 4.9 branch and I don't see why they couldn't affect
>>> >> the 4.8 backport.
>>> >>
>>> >>         Jakub
>>> >
>>> > Fix for PR 63659 has been backported to 4.8 branch.  I will check if
>>> > fix for PR 64286 is needed.
>>> >
>>> > --
>>> > H.J.
>>>
>>> The fix for PR 64286 is an updated fix for PR 59754 which is caused by
>>> the fix for PR 53623.  But the testcase in the fix for PR 64286 doesn't
>>> fail on 4.8 branch + my backport of the fix for PR 53623 on Haswell.
>>> I suggest
>>>
>>> 1. We go without my current backport and backport the fix for PR 64286
>>> in a separate patch.  Or
>>> 2. We go without my backport minus the backport of the PR 59754
>>> fix and backport the fixes for PR 59754 plus PR 64286 in a separate patch
>>
>> I think keeping the branch broken is bad, even if we don't have a testcase
>> that really fails, pressumably the issue is just latent.
>> So I'd strongly prefer
>> 3. Add the PR64286 fix to the patch being tested and commit only when it as
>> whole is tested, as one commit.
>>

4.9 branch backport of  the PR64286 fix caused a regression on ARM64:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64286#c11

Should it be a concern for 4.8 backport?  Should we also backport r215205:

commit b71346c449d2b4a63985a39c4c092ecdfb37b5a0
Author: jiwang <jiwang@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Fri Sep 12 09:29:16 2014 +0000

    [Ree] Ensure inserted copy don't change the number of hard registers

    2014-09-12  Wilco Dijkstra  <wilco.dijkstra@arm.com>

      gcc/
        * ree.c (combine_reaching_defs): Ensure inserted copy don't change the
        number of hard registers.


    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215205
138bc75d-0d04-0410-961f-82ee72b054a4

to 4.8 and 4.9 branches?

> I will do that and restart the testing.
>
> BTW, PR 53623 was a missed optimization bug originally.  Now
> it turns out that it fixed a wrong code bug.  We are trying to extract
> a run-time testcase from PR 64941 for trunk and branches.
>
> Thanks.
>
> --
> H.J.



-- 
H.J.