From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11299 invoked by alias); 14 Jul 2011 16:04:59 -0000 Received: (qmail 11291 invoked by uid 22791); 14 Jul 2011 16:04:59 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 Jul 2011 16:04:40 +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 (8.14.4/8.14.4) with ESMTP id p6EG3fh7029922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Jul 2011 12:03:41 -0400 Received: from anchor.twiddle.net (vpn-226-34.phx2.redhat.com [10.3.226.34]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p6EG3eP4031190; Thu, 14 Jul 2011 12:03:40 -0400 Message-ID: <4E1F135C.8080705@redhat.com> Date: Thu, 14 Jul 2011 16:11:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bernd Schmidt CC: GCC Patches , Eric Botcazou , Steve Ellcey , "Vladimir N. Makarov" Subject: Re: Correct fix for scheduler bug PR11320 References: <4E1EBEFE.3080002@codesourcery.com> In-Reply-To: <4E1EBEFE.3080002@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2011-07/txt/msg01174.txt.bz2 On 07/14/2011 03:03 AM, Bernd Schmidt wrote: > +++ gcc/config/ia64/ia64.c (working copy) > @@ -1047,7 +1047,7 @@ > tmp = gen_rtx_PLUS (Pmode, tmp, pic_offset_table_rtx); > emit_insn (gen_rtx_SET (VOIDmode, dest, tmp)); > > - tmp = gen_rtx_LO_SUM (Pmode, dest, src); > + tmp = gen_rtx_LO_SUM (Pmode, gen_rtx_MEM (Pmode, dest), src); And the bug stems from ... what? Is this bug still fixed if you change this to gen_const_mem? This is a load from the .got. It's constant memory, and it's always present. There's nowhere in the function that we cannot move this load (assuming the address is computed properly) where this load will fail. It's difficult to tell if your raw gen_rtx_MEM with no aliasing info doesn't just paper over a problem by preventing it from being moved. r~