From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130935 invoked by alias); 6 Feb 2016 19:42:54 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 130924 invoked by uid 89); 6 Feb 2016 19:42:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=incorporating, Hx-languages-length:2153 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 06 Feb 2016 19:42:52 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id D0C778E222; Sat, 6 Feb 2016 19:42:50 +0000 (UTC) Received: from slagheap.utah.redhat.com (ovpn-113-84.phx2.redhat.com [10.3.113.84]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u16Jgoub023549; Sat, 6 Feb 2016 14:42:50 -0500 Subject: Re: [PATCH] PR rtl-optimization/64081: Enable RTL loop unrolling for duplicated exit blocks and back edges. To: David Edelsohn , Alexander Fomin References: <20160205134321.GA14773@msticlxl57.ims.intel.com> <56B505B5.8020106@redhat.com> Cc: Richard Biener , GCC Patches , Igor Zamyatin From: Jeff Law Message-ID: <56B64CB9.7060201@redhat.com> Date: Sat, 06 Feb 2016 19:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00471.txt.bz2 On 02/06/2016 12:08 PM, David Edelsohn wrote: >> Normally I'd say that if it was approved before, then it's still good to go >> since there haven't been major conceptual changes in this code since the >> patch was originally written and now. >> >> However, in this instance the patch had been reported to cause problems on >> AIX, problems that we can't reproduce now -- which makes me want to be more >> cautious. Was it a problem with the patch, or some other latent issue -- we >> don't know at this point. >> >> So I think the way to go is to apply this patch on top of r219827 where it >> caused the AIX failure. Then bootstrap on aix and determine the root cause >> of of the AIX bootstrap failure. If it's this patch, then update the patch >> as needed. If the patch is just exposing a latent bug elsewhere, we should >> evaluate whether or not that latent but has been fixed or not before >> applying this fix to the trunk. >> >> It's considerably more work, but ISTM it's the right thing to do. > > I'm on the fence about this patch. I definitely don't think that it > should be merged for GCC 6. > > If the patch were to be proposed during Stage 1 for GCC 7 and had not > caused bootstrap problems for AIX, no one would have any question. > > The problem is we don't know if the patch exposed a latent bug that > independently was fixed after the patch was reverted or if the patch > still contains a bug that has been rendered latent by another change. > > Another approach to track down the cause would be to bisect which > patch fixed the bootstrap failure if the patch had not been reverted. Yes, that would be a good approach as well. The concern here would be that without doing the root cause analysis, bisection may just find a patch which made the issue go latent. To be sure we still have to do some root cause analysis. Given this fixes a regression, I'm still open to incorporating the patch, but we've got to know what went wrong when the patch was previously applied and that whatever that problem was got fixed. Jeff