Ross Ridge wrote: > Segher Boessenkool writes: >> ... People are relying on this undocumented GCC behaviour already, >> and when things break, chaos ensues. > > GCC has introduced many changes over the years that have broken many > programs that have relied on undocumented or unspecified behaviour. > You won't find much sympathy for who people assume that GCC must behave > in some way where there is no requirement for it to do so. > >> If we change this to be documented behaviour, at least it is clear >> where the problem lies (namely, with the compiler), and things can be >> fixed easily. > > I don't think you'll find any support for imposing a requirement on GCC > that would always require it to use an "atomic" instruction when there > is alternative instruction or sequence of instructions that would be > faster and/or shorter. I think your best bet a long these lines would > be adding __sync_fetch() and __sync_store() builtins, but doing so would > be more difficult than a simple documentation change.
The proposed memory model partly described at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2338.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2492.html http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2176.html shows the way the C++ committee is moving. This involves explicit atomic operations. Andrew.
