On 27/03/16 06:57, Michael Clark wrote: > GCC, Clang folk, any ideas on why there is a stack spill for a > volatile register argument passed in esi? Does volatile force the > argument to have storage allocated on the stack? Is this a corner > case in the C standard? This argument in the x86_64 calling > convention only has a register, so technically it can’t change > outside the control of the C "virtual machine” so volatile has a > vague meaning here.
"volatile" doesn't really mean very much, formally speaking. Sure, the standard says "accesses to volatile objects are evaluated strictly according to the rules of the abstract machine," but nowhere is it specified exactly what constitutes an access. (To be precise, "what constitutes an access to an object that has volatile-qualified type is implementation-defined.") So, we have to fall back to tradition. Traditionally, all volatile objects are allocated stack slots and all accesses to them are memory accesses. This is consistent behaviour, and has been for a long time. It is also extremely useful when debugging optimized code. > volatile for scalar function arguments seems to mean: “make this > volatile and subject to change outside of the compiler” rather than > being a qualifier for its storage (which is a register). No, arguments are not necessarily stored in registers: they're passed in registers, but after function entry function they're just auto variables and are stored wherever the compiler likes. Andrew.