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