> Ok, but the converse — if the general_operand is accessed by more > than one instruction, it is not safe — is correct, right?
In general, I'd agree, but the ISO spec talks about "sequence points" and there are times when you *can* access a volatile multiple times as long as the state is correct at the sequence point. GCC won't, for example, combine insns if it doesn't know if the combined insn follows the sequence point rules correctly. This is in 5.1.2.3 in the C99 spec but that caveat mostly applies to non-memory-mapped volatiles; memory-mapped ones are typically more strictly confined (6.7.3.6) (which is the origin of the -fstrict-volatile-bitfields patch). So, for example, if you had a volatile on the stack and a special stack-relative insn to modify it, you would "know" it would be safe to do so even if it doesn't meed 6.7.3.6. Or if you used atomics to guard a multi-access macro to make it volatile-safe.
