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: inline assembly question (memory side-effects)


Till Straumann wrote:

> What is the proper way to tell gcc that a
> inline assembly statement either modifies
> a particular area of memory or needs it
> to be updated/in-sync because the assembly
> reads from it.
> 
> E.g., assume I have a
> 
> struct blah {
>    int sum;
>  ...
> };
> 
> which is accessed by my assembly code.
> 
> int my_chksum(struct blah *blah_p)
> {
>   blah_p->sum = 0;
>   /* assembly code computes checksum, writes to blah_p->sum */
>   asm volatile("..."::"b"(blah_p));
>   return blah_p->sum;
> }
> 
> How can I tell gcc that the object *blah_p
> is accessed (read and/or written to) by the
> asm (without declaring the object volatile or
> using a general "memory" clobber).
> (If I don't take any measures then gcc won't know
> that blah_p->sum is modified by the assembly and
> will optimize the load operation away and return
> always 0)
> 
> A while ago (see this thread
> http://gcc.gnu.org/ml/gcc/2008-03/msg00976.html)
> I was told that simply adding the affected
> memory area in question as memory ('m') output-
> or input-operands is not appropriate -- note that
> this is in contradiction to what the gcc info page
> suggests (section about 'extended asm':

Thia was pretty well explained in http://gcc.gnu.org/ml/gcc/2008-03/msg01084.html
This is arguably a bug in gcc. 

However, you are making this unduly hard for yourself, since the checksum
is in a register, then written to memory, then read from memoty again.

Andrew.


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