From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17466 invoked by alias); 9 Jul 2007 15:30:52 -0000 Received: (qmail 17458 invoked by uid 22791); 9 Jul 2007 15:30:52 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.179) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 09 Jul 2007 15:30:45 +0000 Received: by py-out-1112.google.com with SMTP id a29so2297417pyi for ; Mon, 09 Jul 2007 08:30:42 -0700 (PDT) Received: by 10.65.224.11 with SMTP id b11mr4995302qbr.1183995042404; Mon, 09 Jul 2007 08:30:42 -0700 (PDT) Received: from scientist.local ( [68.179.81.66]) by mx.google.com with ESMTP id e15sm6896630qbe.2007.07.09.08.30.40 (version=SSLv3 cipher=RC4-MD5); Mon, 09 Jul 2007 08:30:41 -0700 (PDT) Message-ID: <46925495.9090305@gnu.org> Date: Mon, 09 Jul 2007 15:33:00 -0000 From: Paolo Bonzini User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Andrew Pinski CC: Eric Botcazou , gcc-patches@gcc.gnu.org, Mark Mitchell Subject: Re: PR/32004, tree-ssa caused in/out asm constraints to often need reloads References: <468CC82F.2060702@lu.unisi.ch> <200707090748.59581.ebotcazou@adacore.com> <469228F7.6020601@gnu.org> <200707091455.31718.ebotcazou@adacore.com> <469231B2.3010503@gnu.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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/msg00822.txt.bz2 > Just a latent bug showed up because the trunk and the branches > have large differences in the dataflow. I don't need any kind of defense because I *did* make a mistake in the testing and because this is *not* a latent bug. The backport was not as obvious as I had thought, so in retrospect what I should have done would have been to first submit a patch for 4.3 only, and then a patch for 4.2/4.1. I remember I had made the same mistake (not looking at the wrong logs, O:-) rather assuming that the same fix applied to two wildly different codebases) with a performance PR affecting 4.0 and 3.4 (I don't remember the PR number); in that case Eric also had suggested reverting on 3.4 and I did that exactly. In this case however this is a much worse bug (it is P1 for a reason, even if the testcase was not reported by a user), so I'm committing the additional fix which has been approved by Richard. Paolo