On Mon, Feb 16, 2015 at 5:24 AM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Mon, Feb 16, 2015 at 5:18 AM, Jakub Jelinek <ja...@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.to...@gmail.com> wrote: >>> > On Mon, Feb 16, 2015 at 1:35 AM, Jakub Jelinek <ja...@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. >> > > I will do that and restart the testing. >
I tested it on x86-32, x86-64 and x32. There are no regressions. -- H.J.
