From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19245 invoked by alias); 9 Jul 2007 13:12:52 -0000 Received: (qmail 19237 invoked by uid 22791); 9 Jul 2007 13:12:52 -0000 X-Spam-Check-By: sourceware.org Received: from wa-out-1112.google.com (HELO wa-out-1112.google.com) (209.85.146.182) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 09 Jul 2007 13:12:48 +0000 Received: by wa-out-1112.google.com with SMTP id m16so1240951waf for ; Mon, 09 Jul 2007 06:12:46 -0700 (PDT) Received: by 10.114.179.1 with SMTP id b1mr3101982waf.1183986766204; Mon, 09 Jul 2007 06:12:46 -0700 (PDT) Received: by 10.114.203.9 with HTTP; Mon, 9 Jul 2007 06:12:46 -0700 (PDT) Message-ID: Date: Mon, 09 Jul 2007 13:23:00 -0000 From: "Andrew Pinski" To: "Paolo Bonzini" Subject: Re: PR/32004, tree-ssa caused in/out asm constraints to often need reloads Cc: "Eric Botcazou" , gcc-patches@gcc.gnu.org, "Mark Mitchell" In-Reply-To: <469231B2.3010503@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <468CC82F.2060702@lu.unisi.ch> <200707090748.59581.ebotcazou@adacore.com> <469228F7.6020601@gnu.org> <200707091455.31718.ebotcazou@adacore.com> <469231B2.3010503@gnu.org> X-IsSubscribed: yes 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 X-SW-Source: 2007-07/txt/msg00792.txt.bz2 On 7/9/07, Paolo Bonzini wrote: > If you want me to revert the patch on 4.1 and apply the combination in a > few days, after letting it stay on 4.2 for a while, I can do that. > Otherwise, I would very much prefer fixing PR21291/PR32004, which is as > bad a regression as the one I introduced. Of course, I'm not meaning > I'm *not* sorry to have introduced a regression. >>Now I get with RTL checking on: Just a quick note, it is not a requirement (as far as I know), that we need to turn on RTL checking to test backports of patches. Now I can see if this was an issue if the regression showed up with the default checking for that branch but the regression as far as I can tell only shows up with RTL checking turned on (which is not even on the trunk) so the policy of not requiring approval for backporting a regression fix (with a bootstrap/test) was not violated here as far as I can tell. Just a latent bug showed up because the trunk and the branches have large differences in the dataflow. -- Pinski