RE: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os

[Weddington, Eric]

> -----Original Message-----
> From: Mark Litwack [mailto:address@hidden 
> Sent: Friday, May 16, 2008 11:25 AM
> To: Weddington, Eric
> Cc: address@hidden
> Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorrect Code with -Os
> 
> 
> Are you saying your construct above protects "// code" in
> all cases?  Or is "// code" still subject to being
> re-ordered to outside of the protection if there are no
> dependencies?

I doubt that it's totally safe, though in practice I have never seen the
compiler reorder a construct like that.
 
> If ATOMIC_BLOCK() is *the* way to do it, perhaps the docs
> could be improved a little by emphasizing the use of
> ATOMIC_BLOCK() as a necessity rather than as a convenience.
> 

I'll go a step further: Is there any reason to NOT include the memory
barrier in the interrupt macros? Would that even work? 

Like this,

# define sei()  __asm__ __volatile__ ("sei" ::: "memory")
# define cli()  __asm__ __volatile__ ("cli" ::: "memory")

Eric