On Fri, Dec 2, 2011 at 9:26 AM, Dave Korn <dave.korn.cyg...@gmail.com> wrote: > On 01/12/2011 21:40, Georg-Johann Lay wrote: > >> It's not unusual because: >> >> * It's not unusual to write down SFRs as violatile memory like >> (*((volatile unsigned int*) 0x1234)) or as a cast to a composite >> that reflects the SFRs bit(field)s. >> >> * It's not unusual that microcontrollers can access specific parts >> of memory -- in particular I/O -- with special instructions. > > Great. Now I'm going to be hearing Tom Jones in my head for the rest of the > day! :) > > (ObTopic: Andrew H's definition of volatile is completely right AIUI and the > case reported by Peter B is definitely a very bad bug. Volatile operations > are externally visible and must be executed in source-code order.)
My case was probably a flaw in my machine description. Like many microcontrollers (including AVR), the msp430 maps peripherals as volatile memory references, and supports instructions that operate directly on that memory. The original msp430 back-end did a dirty trick with special predicates that temporarily set the global "volatile_ok" flag in order to trick gcc into generating acceptable code (combining a sequence of load/modify/store insns into a single RMW insn); I found that to be untrustworthy and replaced it with peepholes. Richard's comment that moving unrelated volatiles around each other is acceptable to core gcc, if not C, may have enabled the issue I saw, but as far as I'm concerned it was a bug in my stuff, even if I was confused enough to think for a while it might be technically allowed. Peter > > cheers, > DaveK >
