This bug report refers to the discussion on
[bug #14616] definition of sei() in interrupts.h is faulty
<http://savannah.nongnu.org/bugs/?func=detailitem&item_id=14616>
and the according discussion thread on [avr-libc-dev]
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev/
The issue is the question if for the following test case gcc is allowed to
schedule or not allowed to schedule an asm volatile instruction (the text of
this comment continues after the test case). For clarity the actual asm
instructions have been replaced by comments illustrating the meaning:
/* Start of test case */
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
class class_with_volatile_data_structures
{
public:
void __attribute__ ((always_inline))
wait_for_event (uint16_t event)
{
while (getval_protected () != event)
;
};
private:
uint16_t
getval_protected (void)
{
uint16_t result;
asm volatile ("/* disable irq in cpu status */" : : );
result = class_local_data;
asm volatile ("/* enable irq */" : : );
return result;
}
volatile uint16_t class_local_data;
};
class_with_volatile_data_structures object;
void
wait_for_42 (void)
{
object.wait_for_event (42);
}
/* End of test case */
Compiler output reads for (buggy ?) avr-g++ (GCC) 4.0.0
_Z11wait_for_42v:
.L2:
/* #APP */
/* disable irq in cpu status */
/* enable irq */
/* #NOAPP */
lds r24,object
lds r25,(object)+1
sbiw r24,42
brne .L2
ret
and for avr-g++ (GCC) 4.0.1 20050624 (prerelease)
_Z11wait_for_42v:
.L2:
/* #APP */
/* disable irq in cpu status */
/* #NOAPP */
lds r24,object
lds r25,(object)+1
/* #APP */
/* enable irq */
/* #NOAPP */
sbiw r24,42
brne .L2
ret
. So for the more recent version the acess to the variable is protected and for
the original first 4.0.0 release not. If
asm volatile ("/* disable irq in cpu status */" : : : "memory");
is used, the variable access was protected for both compiler versions.
The important question for the avr-libc header files is now:
According the specification, what is guaranteed by gcc concerning volatile asm
statements? According to the spec
> The `volatile' keyword indicates that the instruction has important
> side-effects. GCC will not delete a volatile `asm' if it is reachable.
> (The instruction can still be deleted if GCC can prove that
> control-flow will never reach the location of the instruction.) In
> addition, GCC will not reschedule instructions across a volatile `asm'
> instruction.
, I'd like to assume that the "memory" clobbers should not be required.?
Bjoern
--
Summary: asm volatile instructions incorrectly scheduled.?
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P1
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bjoern dot m dot haase at web dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: present on i586-linux, x86_64-linux and i586 cygwin
GCC host triplet: present on i586-linux, x86_64-linux and i586 cygwin
GCC target triplet: avr-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24165
