From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30845 invoked by alias); 7 Apr 2003 19:26:00 -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 30830 invoked by uid 71); 7 Apr 2003 19:26:00 -0000 Date: Mon, 07 Apr 2003 19:26:00 -0000 Message-ID: <20030407192600.30829.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Eric Botcazou Subject: Re: c/10339 Reply-To: Eric Botcazou X-SW-Source: 2003-04/txt/msg00298.txt.bz2 List-Id: The following reply was made to PR optimization/10339; it has been noted by GNATS. From: Eric Botcazou To: Wolfgang Bangerth Cc: gcc-gnats@gcc.gnu.org Subject: Re: c/10339 Date: Mon, 7 Apr 2003 21:17:51 +0200 > You can see the problem by looking at the assembler output when using -O: > it calls memcmp with an argument 4 in %o2 (the "mov 4, %o2" happens _after_ > the call, but I think the instruction after the call is something like a > delay slot, so %o2 will be set at the time we get into memcmp). Yep, the insn has been put in a delay slot. > PS: Again, my interest is just to know whether this is a regression also > on 3.3 and mainline, but if you should want to fix it then... Does the same problem (if there is a problem) not happen on x86 too? -- Eric Botcazou