On Thu, 21 Nov 2013, Hans-Peter Nilsson wrote: > Oh right, gcc still doesn't remove target-introduced "manual" > alignment checks (when expanding atomic intrinsics), but at > least gcc makes sure it's aligned on stack, when options doesn't > say it's aligned. And a.c:plugh2 doesn't seem to perform an > atomic assignment, but just assignment through an > _Atomic-aligned stack temporary. Might be my C11-ignorance > showing.
It appears to me on x86_64 to produce an __atomic_store_4 to *x (in the GIMPLE dumps, what happens after that is a matter for the back end). Note that atomic variable initialization is *not* atomic (see 7.17.2.1 - in general ATOMIC_VAR_INIT needs using with the initializer, or the initialization needs to be carried out with atomic_init, though GCC doesn't require that). (In C11, the effect of a plain initialization without ATOMIC_VAR_INIT is I think that the initializer is evaluated for its side effects, but if the variable gets used as either rvalue or lvalue without one of the special forms of initialization being used first then the behavior is undefined. The idea is to support implementations with extra bits in atomic objects used for locking purposes.) So no atomic store to y is expected - although there are atomic loads from y. -- Joseph S. Myers jos...@codesourcery.com
