Re: [avr-libc-dev] Re: bug #22163 (atomic not working as expected inC++)

[David Brown]

On 09/06/2010 22:52, Joerg Wunsch wrote:
> As David Brown wrote:
>
> > Eric suggested making "some_temp_variable" volatile, which is the
> > traditional way to enforce ordering in C programming.  Strictly
> > speaking, you don't have to make it volatile - it's enough to make
> > sure it is in memory if cli() and sei() have memory blocks.
>
> Yes, but again: forcing the variable into memory is a pessimization.
> It's not required for the job, but something like that is currently
> the only way to force the compiler into doing what the programmer
> intended.

Pretending to use the variable in an assembly statement should also 
work, with no extra code generated.  The syntax is slightly ugly, but it 
could be wrapped in a macro:

#define forceGenerate(x) asm volatile("" :: "r" (x))

I can't think of any way to automate this with changes to the cli() 
macro, but that's not surprising as the C language doesn't have the 
relevant concepts.

If you have a code snippet that shows this sort of re-ordering, it would 
be nice to try it with the above macro and see if it fixes the problem.


> (suggested language extension)
>
> > I'm not sure there is any way to give a solid definition of the
> > semantics of "volatile" here.  And I suspect that you'll have
> > /slightly/ more difficulty getting this into mainline gcc than for
> > other extensions such as 0b binary constants...
>
> Yeah, sure.  No, this won't be me to implement it...