From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-154407-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 5706 invoked by alias); 4 Jun 2009 09:48:55 -0000
Received: (qmail 5696 invoked by uid 22791); 4 Jun 2009 09:48:54 -0000
X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mail-fx0-f222.google.com (HELO mail-fx0-f222.google.com) (209.85.220.222)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 04 Jun 2009 09:48:48 +0000
Received: by fxm22 with SMTP id 22so692910fxm.8         for <gcc@gcc.gnu.org>; Thu, 04 Jun 2009 02:48:45 -0700 (PDT)
Received: by 10.103.224.2 with SMTP id b2mr1227197mur.30.1244108925673;         Thu, 04 Jun 2009 02:48:45 -0700 (PDT)
Received: from ?192.168.2.99? (cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62])         by mx.google.com with ESMTPS id s10sm9434211mue.38.2009.06.04.02.48.44         (version=SSLv3 cipher=RC4-MD5);         Thu, 04 Jun 2009 02:48:45 -0700 (PDT)
Message-ID: <4A279B46.6020600@gmail.com>
Date: Thu, 04 Jun 2009 09:48:00 -0000
From: Dave Korn <dave.korn.cygwin@googlemail.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Dave Korn <dave.korn.cygwin@googlemail.com>
CC: Andrew Haley <aph@redhat.com>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: [4.3] Invalid code or invalid optimisation?
References: <4A2728AA.3010205@gmail.com> <4A27857D.50708@redhat.com> <4A279526.8090905@gmail.com>
In-Reply-To: <4A279526.8090905@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2009-06/txt/msg00061.txt.bz2

Dave Korn wrote:
> Andrew Haley wrote:

>>  Volatile stores only block other
>> volatile stores: they don't block *all* stores.  If you really want a complete
>> memory barrier, which in a mutex you surely do, then you're going to have to
>> clobber memory.
> 
>   Ah.  That suggests that HEAD is in fact _missing_ an optimisation that 4.3
> gets right.  Maybe I should file a PR after all.

  It also suggests that the register motion is fairly gratuitous, I think.

	movl	%eax, -12(%ebp)	 # tmp79, ret
	movl	-12(%ebp), %eax	 # ret, D.2120

  Given that ret is a local variable that goes immediately out of scope, I
can't see any reason to update the stack slot.  I can prevent this happening
by declaring the temporary as 'register __typeof (*t) ret __asm ("%eax");' but
doesn't this mean we're missing a trick here between some combination of
regalloc, copyprop and dead-store elimination?

    cheers,
      DaveK