From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3682 invoked by alias); 2 Apr 2003 09:16:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 3668 invoked by uid 71); 2 Apr 2003 09:16:02 -0000 Date: Wed, 02 Apr 2003 09:16:00 -0000 Message-ID: <20030402091602.3667.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Jan Hubicka Subject: Re: optimization/10287: [3.2/3.4 regression] Loop/conditional store bug (ARM) Reply-To: Jan Hubicka X-SW-Source: 2003-04/txt/msg00061.txt.bz2 List-Id: The following reply was made to PR optimization/10287; it has been noted by GNATS. From: Jan Hubicka To: gcc-gnats@gcc.gnu.org, jh@suse.cz Cc: Subject: Re: optimization/10287: [3.2/3.4 regression] Loop/conditional store bug (ARM) Date: Wed, 2 Apr 2003 11:09:26 +0200 > On Tue, Apr 01, 2003 at 06:36:11PM -0000, drow@mvista.com wrote: > > > > >Number: 10287 > > >Category: optimization > > >Synopsis: [3.2/3.4 regression] Loop/conditional store bug (ARM) > > >Confidential: no > > >Severity: serious > > >Priority: medium > > >Responsible: unassigned > > >State: open > > >Class: sw-bug > > >Submitter-Id: net > > >Arrival-Date: Tue Apr 01 18:46:00 UTC 2003 > > >Closed-Date: > > >Last-Modified: > > >Originator: drow@mvista.com > > >Release: 3.2.2 (release), 3.4 CVS (2003-03-27) > > >Organization: > > >Environment: > > i686-pc-linux-gnu host, arm-linux target (or arm-elf, xscale-elf, et cetera) > > >Description: > > The attached test case aborts when compiled with -O2 for > > an ARM target. > > > > The diff between failing and succeeding binaries is: > > cmp ip, #0 > > - moveq r3, r1 > > - movne r3, lr > > str r1, [r5], #4 > > + strne lr, [r5], #4 > > subs ip, ip, #2 > > - str r3, [r5], #4 > > > > Note that the failing binary has an unconditional store > > of a conditional value. My guess is that something is > > not respecting post-increment when distinguishing between > > the two stores. > > > > > > This is a 3.2 and 3.4 regression; it worked in 2.95 and > > it works in 3.3. The bug was fixed in 3.3 and HEAD by: > > > > 2002-09-18 Richard Henderson > > > > * ifcvt.c (noce_process_if_block): Correctly detect X modified > > with INSN_B before COND_EARLIEST. Don't check A and B for > > modification in condition range. Reorder INSN_B for A==B properly. > > (if_convert): Iterate until no matches for a block. > > > > It was then broken again in HEAD by: > > Wed Jan 8 12:10:57 CET 2003 Jan Hubicka > > > > * i386.md (adddi3_carry_rex64, subdi3_carry_rex64): Name pattern. > > (addhi3_carry, addqi3_carry, subhi3_carry, subqi3_carry): New patterns. > > (add??cc): New expanders. > > * i386.c (expand_int_addcc): New function. > > * i386-protos.h (expand_int_addcc): Declare. > > > > * alias.c (memory_modified_1): New static function. > > (memory_modified): New static varaible. > > (memory_modified_in_insn_p): New global function. > > * rtl.h (memory_modified_in_insn_p): Declare. > > * rtlanal.c (modified_between_p, modified_in_p): Be smart about memory > > references. > > > > * expr.h (emit_conditional_add): Declare. > > I'm not sure, but I think that modified_between_p and modified_in_p are > going to have to have POST_INC (POST_DEC, PRE_INC, PRE_DEC) cases in > them for the above patch from Jan to be safe. Hmm, possibly. Is the "#4" enconding of auto increment? There is code to deal with the auto increments in alias.c and I think it is enought in this particular case. WIll try to dig into it. Honza > > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer