This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: inline assembly question (memory side-effects)
- From: Andrew Haley <aph at redhat dot com>
- To: Till Straumann <strauman at slac dot stanford dot edu>
- Cc: gcc at gcc dot gnu dot org, "rtems-users at rtems dot org" <rtems-users at rtems dot org>
- Date: Mon, 12 May 2008 11:32:18 +0100
- Subject: Re: inline assembly question (memory side-effects)
- References: <4825FCD4.3070604@slac.stanford.edu>
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.