Follow-up Comment #5, bug #14616 (project avr-libc):
The unfortunate thing is, that using volatile is not enough. Even if it works
for your extremely simple test case: I am having a more complex test case
example in my application code, where it does *not* work because gcc reorders
the statements. And so as I understand the specification of gcc's inline asm
statement, gcc has completely the right to reorder the statements as long as
we do not communicate the possible side effects.
I am convinced that You as well will be unhappy with the present
implementation if you discover one day that code segments that used to work
perfectly do no longer work because you had inserted a completely unrelated
line of code somewhere in the application: A line of code that makes gcc
consider it to be useful to reorder the code!
FYI: I had started with code like
{
uint8_t temp = SREG;
asm volatile ("cli" : :);
volatile_declared_uint16_t_var_in_memory = value;
SREG = temp;
}
Here gcc had reordered it such that it would read
{
uint8_t temp = SREG;
asm volatile ("cli" : :);
SREG = temp;
volatile_declared_uint16_t_var_in_memory = value;
}
I then tried to use brute force by doing
{
asm volatile ("cli" : :);
volatile_declared_uint16_t_var_in_memory = value;
asm volatile ("sei" : :);
}
and also this ended up at reordered like
{
asm volatile ("cli" : :);
asm volatile ("sei" : :);
volatile_declared_uint16_t_var_in_memory = value;
}
. Only when adding the "memory" clobbers to the spec. I obtained true
protection. And IMO adding the clobbers *is* correct since indeed the sei
instruction *has* possible unpredictable side effects on the memory, like in
my case where the IRQ did write the variable!
All this is what draws me to the conclusion that the present macros are *not*
safe. IMO one must not make the mistake to derive from the fact that simple
test cases work that it works all the time :-(.
Bjoern.