From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-102979-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10659 invoked by alias); 20 Sep 2004 13:51:43 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
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
Received: (qmail 10642 invoked from network); 20 Sep 2004 13:51:42 -0000
Received: from unknown (HELO NUTMEG.CAM.ARTIMI.COM) (217.40.111.177)
  by sourceware.org with SMTP; 20 Sep 2004 13:51:42 -0000
Received: from mace ([192.168.1.25]) by NUTMEG.CAM.ARTIMI.COM with Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 20 Sep 2004 14:49:00 +0100
From: "Dave Korn" <dk@artimi.com>
To: <tm_gccmail@kloo.net>,
	"'Nathan Sidwell'" <nathan@codesourcery.com>
Cc: "'Jamie Lokier'" <jamie@shareable.org>,
	<gcc@gcc.gnu.org>
Subject: RE: A question about "memory" clobbers in asm
Date: Mon, 20 Sep 2004 15:16:00 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <Pine.LNX.4.21.0409192210390.10468-100000@mail.kloo.net>
Message-ID: <NUTMEG2yPQaDxKSiXPw000000ab@NUTMEG.CAM.ARTIMI.COM>
X-OriginalArrivalTime: 20 Sep 2004 13:49:00.0703 (UTC) FILETIME=[955B32F0:01C49F18]
X-SW-Source: 2004-09/txt/msg01166.txt.bz2

> -----Original Message-----
> From: gcc-owner On Behalf Of tm_gccmail
> Sent: 20 September 2004 06:30

> I've seen cases like this:
> 
> 	*ptr = 5;
> 
> 
> 	/* basically result = (*ptr == 5) */
> 	__asm__ volatile ("mov.l @%1,%0; mov #5,%2; cmp/eq %1,%2;
> 			   movt %0"
> 			   : "r" (result), "r" (temp)
> 			   : "r" (ptr));
> 
> 	
> 	if (!result) {
> 		...
> 	}
> 
> If the memory clobber is omitted, then the scheduler can move *ptr = 5
> AFTER the inline assembly fragment, which will result in the incorrect
> result.

  That should be considered a bug, shouldn't it?  I mean, the compiler knows
that ptr is an input to the asm, so it should no more move "*ptr = 5" to
after the asm than it should if there was a function call in the same
place...

   *ptr = 5;
   result = foo (ptr);
   if (!result) {
           ...
   }

  IMO it would be obviously invalid to move the assignment past the function
call in this case, and by analogy I don't think it should be valid in the
asm case either.  Is there something I'm not getting here?

[  In fact, even if foo didn't take ptr as an argument, it still shouldn't
be moving that assignment past the call to foo without having first done
some fairly hefty alias analysis.... ]

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....