From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20103 invoked by alias); 7 Apr 2003 18:56: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 20079 invoked by uid 71); 7 Apr 2003 18:56:01 -0000 Date: Mon, 07 Apr 2003 18:56:00 -0000 Message-ID: <20030407185601.20077.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Wolfgang Bangerth Subject: c/10339 Reply-To: Wolfgang Bangerth X-SW-Source: 2003-04/txt/msg00294.txt.bz2 List-Id: The following reply was made to PR optimization/10339; it has been noted by GNATS. From: Wolfgang Bangerth To: ebotcazou@libertysurf.fr Cc: gcc-gnats@gcc.gnu.org Subject: c/10339 Date: Mon, 7 Apr 2003 13:52:25 -0500 (CDT) Hi Eric, as resident sparc optimization expert: would you mind taking a look at 10339, which is kind of a miscompilation on sparc? It would be nice if you could confirm/reject whether this is a regression also in 3.3 and mainline, since I don't have these branches on our sparc boxes. 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). What exactly goes wrong should be understandable from the audit trail. Thanks Wolfgang 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... ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ices.utexas.edu www: http://www.ices.utexas.edu/~bangerth/