From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25213 invoked by alias); 30 Mar 2003 21:16:01 -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 25199 invoked by uid 71); 30 Mar 2003 21:16:01 -0000 Date: Sun, 30 Mar 2003 21:17:00 -0000 Message-ID: <20030330211601.25198.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Eric Botcazou Subject: Re: target/10222: Wrong code with -mcpu=ultrasparc using gcc 3.2.2 Reply-To: Eric Botcazou X-SW-Source: 2003-03/txt/msg02072.txt.bz2 List-Id: The following reply was made to PR target/10222; it has been noted by GNATS. From: Eric Botcazou To: kostis@csd.uu.se Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org Subject: Re: target/10222: Wrong code with -mcpu=ultrasparc using gcc 3.2.2 Date: Sun, 30 Mar 2003 23:05:22 +0200 > The attached file contains a very small and simple function extracted from > a big application. The code produced by -03 is correct. Yes, but only by chance. > The code produced using -03 -mcpu=ultrasparc is wrong and causes the > application to go into an infinite loop. Well, the code is wrong according to your expectations, but right according to the C standard (more precisely, gcc is allowed to produce this code in this situation). > From what I can see, the problem is partly caused by the fact that the > code lies about types when it appends elements to the free list. My guess > is that -mcpu=ultrasparc triggers a scheduling pass, which assumes one > store cannot affect another load, since they are of different types. I can > pass -fno-strict-aliasing to gcc to work around that, but arguably this is > unsatisfactory for various reasons Right. Your code violates the ISO C aliasing rules: void reclaim_del_ret_list(struct subgoal_frame *sg_frame) { struct Answer_List_Node *x, *y; x = sg_frame->compl_stack_ptr->del_ret_list; while (x) { y = x; 1 x = x->link; 2 *(void**)y = smALN.struct_lists.dealloc; smALN.struct_lists.dealloc = y; } } The compiler is allowed to assume that load #1 and store #2 are independent since they are made through pointers of different types. So the first scheduling pass transforms the code into: while (x) { y = x; 2 *(void**)y = smALN.struct_lists.dealloc; 1 x = x->link; smALN.struct_lists.dealloc = y; } hence the infinite loop. > 1. What I naively expect from -mcpu=ultrasparc is to > perform target specific code generation; not to affect > the alias analysis which is used. -mcpu doesn't modify the alias analysis, but it affects scheduling. The default scheduling is simply less aggressive than the ultrasparc scheduling, in that it doesn't reorder the insns to the same extent. > 2. This behaviour is not something that happened with > previous versions of gcc (e.g. 2.95.x) and gcc 3.2 > on x86 with -mcpu=pentiumpro does not exhibit such > behaviour. -fstrict-aliasing was not enabled by default at -O2 for gcc 2.95.x. As for the behaviour on x86, it's again by chance, another scheduling could give the same infinite loop. The solution is really the one you have proposed: to compile with -fno-strict-aliasing. -- Eric Botcazou