From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3544 invoked by alias); 16 Oct 2012 11:38:22 -0000 Received: (qmail 3530 invoked by uid 22791); 16 Oct 2012 11:38:21 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-pb0-f47.google.com (HELO mail-pb0-f47.google.com) (209.85.160.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 16 Oct 2012 11:38:17 +0000 Received: by mail-pb0-f47.google.com with SMTP id ro12so5931547pbb.20 for ; Tue, 16 Oct 2012 04:38:17 -0700 (PDT) Received: by 10.68.130.165 with SMTP id of5mr45748900pbb.113.1350387496967; Tue, 16 Oct 2012 04:38:16 -0700 (PDT) Received: from yakj.usersys.redhat.com (93-34-169-1.ip50.fastwebnet.it. [93.34.169.1]) by mx.google.com with ESMTPS id sz4sm10669006pbc.22.2012.10.16.04.38.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Oct 2012 04:38:15 -0700 (PDT) Message-ID: <507D4720.30208@gnu.org> Date: Tue, 16 Oct 2012 11:42:00 -0000 From: Paolo Bonzini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121009 Thunderbird/16.0 MIME-Version: 1.0 To: Steven Bosscher CC: Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: Fix twolf -funroll-loops -O3 miscompilation (a semi-latent web.c bug) References: <20121012194333.GA8987@kam.mff.cuni.cz> <20121012204433.GA10890@kam.mff.cuni.cz> <20121012211636.GC10890@kam.mff.cuni.cz> <507A6388.8080101@gnu.org> <507BBD75.50800@gnu.org> <507BC6FB.80909@gnu.org> <507C0DCE.4070208@gnu.org> 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: 2012-10/txt/msg01518.txt.bz2 Il 16/10/2012 12:35, Steven Bosscher ha scritto: > On Tue, Oct 16, 2012 at 12:15 PM, Steven Bosscher wrote: >> On Mon, Oct 15, 2012 at 3:26 PM, Steven Bosscher wrote: >>> On Mon, Oct 15, 2012 at 3:21 PM, Paolo Bonzini wrote: >>>> Il 15/10/2012 14:53, Steven Bosscher ha scritto: >>>>> I think I've shown above that we're all looking at the wrong pass... >>>> >>>> I think you have... so we want a patch like this? >>> >>> I don't think so. df_kill_notes is already supposed to take care of this. >> >> But it doesn't because if the SET_DEST of an insn is the same as the >> register dieing in the insn's REG_EQUAL note, the reg is live at the >> end of the insn and so the note stays: >> >> Breakpoint 2, df_kill_notes (insn=0x7ffff5e3e7e0, live=0x7fffffffda90) >> at ../../trunk/gcc/df-problems.c:2833 >> 2833 rtx *pprev = ®_NOTES (insn); >> 1: debug_rtx(insn) = (insn 79 50 52 8 (set (reg:DI 72 [ ivtmp.17D.1758 ]) >> (reg:DI 103 [ ivtmp.17D.1758 ])) -1 >> (expr_list:REG_DEAD (reg:DI 103 [ ivtmp.17D.1758 ]) >> (expr_list:REG_EQUAL (plus:DI (reg:DI 72 [ ivtmp.17D.1758 ]) >> (const_int 24 [0x18])) >> (nil)))) >> void >> (gdb) undisp 1 >> (gdb) p debug_bitmap(live) >> >> first = 0x1627200 current = 0x1627200 indx = 0 >> 0x1627200 next = (nil) prev = (nil) indx = 0 >> bits = { 6 7 16 20 72 82 85 87 } >> $2 = void >> (gdb) >> >> >> So GCC should be looking at whether the reg in the REG_EQUAL note is >> dead *before* the insn. >> >> Bottom line: This is a bug in df_kill_notes. Yep, and it could cause wrong code generation, couldn't it? Because the new (reg:DI 72) is obviously not equal to (plus:DI (reg:DI 72) (const_int 24)), but it could be propagated to subsequent insns. So I think this patch should be backported to all release branches after regstrapping. > I think this should fix it. Can't test it right now, so help > appreciated (Honza: hint hint! ;-) Ok after bootstrap, regtest and checking that it actually fixes the bug. Paolo