This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: A question about "memory" clobbers in asm


> -----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....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]