From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29970 invoked by alias); 26 Jul 2007 17:35:46 -0000 Received: (qmail 29958 invoked by uid 22791); 26 Jul 2007 17:35:46 -0000 X-Spam-Check-By: sourceware.org Received: from mail3.panix.com (HELO mail3.panix.com) (166.84.1.74) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Jul 2007 17:35:43 +0000 Received: from mailspool2.panix.com (mailspool2.panix.com [166.84.1.79]) by mail3.panix.com (Postfix) with ESMTP id 1C77013A7D7; Thu, 26 Jul 2007 13:35:37 -0400 (EDT) Received: from [192.168.1.60] (pool-70-104-131-212.nycmny.fios.verizon.net [70.104.131.212]) by mailspool2.panix.com (Postfix) with ESMTP id 5829E8CC402; Thu, 26 Jul 2007 13:35:37 -0400 (EDT) Message-ID: <46A8DB68.9060508@naturalbridge.com> Date: Thu, 26 Jul 2007 17:55:00 -0000 From: Kenneth Zadeck User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Seongbae_Park_=28=3F=3F=3F=2C_=3F=3F=3F=29=22?= CC: gcc-bugzilla@gcc.gnu.org, "Bonzini, Paolo" , gcc-patches Subject: Re: [Bug middle-end/32749] [4.3 regression]: gfortran.dg/auto_array_1.f90 References: <20070716232625.9422.qmail@sourceware.org> <46A88AB8.4000401@naturalbridge.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 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/msg01938.txt.bz2 Seongbae Park (???, ???) wrote: > On 7/26/07, Kenneth Zadeck wrote: >> This patch extends the fix in >> http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01557.html >> to handle the case of clobbers inside conditional calls. >> >> This problem caused the regression of gfortran.dg/matmul_3.f90 on the >> ia-64 in addition to the regression cited in this pr. >> >> Tested on ppc-32, ia-64 and x86-64. >> >> 2007-07-26 Kenneth Zadeck >> >> PR middle-end/32749 >> >> * df-problems.c (df_note_bb_compute): Handle case of clobber >> inside conditional call. >> >> ok to commit? > > This change is OK. > Though I wonder if we need to do similar checking > for the regular insn case below. No the checking is done in df_create_unused_note. The only reason you have to do it here is that you are not calling that. thanks kenny