[Bug target/55981] std::atomic store is split in two smaller stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55981 Paul E. McKenney changed: What|Removed |Added CC||paulmck at linux dot ||vnet.ibm.com --- Comment #4 from Paul E. McKenney 2013-01-15 12:30:04 UTC --- (In reply to comment #2) > Btw, the same happens if atomic is replaced with "volatile unsigned long y" - > which does not violate the standard, but may be considered undesirable by > some. > I don't have a strong opinion about this. This really does need to be fixed in the "volatile unsigned long y" case, or device drivers storing constants to device registers will break. So please fix this for volatiles as well as atomics.
[Bug target/56028] Splitting a 64-bit volatile store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028 --- Comment #2 from Paul E. McKenney 2013-01-18 11:25:52 UTC --- (In reply to comment #1) > - Does language standard guarantee atomic store in this case [wikipedia says > "No." [1]]? The above example of device drivers storing constants to a device register declared as "volatile unsigned long y" does not require all of the attributes of an atomic store, for example, it does not require memory-fence instructions. > - Can a store to a volatile DImode location be implemented as two consecutive > SImode stores to adjacent location (this breaks stores of 64bit immediates to > MMIO 64bit registers)? See 1.9p8 of the C++11 standard, first bullet: "Access to volatile objects are evaluated strictly according to the rules of the abstract machine." >From what I can see, implementing a store to a volatile DImode location as two consecutive SImode stores to adjacent locations violates this aspect of the standard. Furthermore, to expand on your parenthesized statement above, gcc might not operate reliably if the device drivers in the kernel it is running on have their 64-bit immediate stores broken into pairs of 32-bit immediate stores. ;-) > [1] http://en.wikipedia.org/wiki/Volatile_variable#In_C_and_C.2B.2B
[Bug target/56028] Splitting a 64-bit volatile store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028 --- Comment #4 from Paul E. McKenney 2013-01-18 16:22:49 UTC --- (In reply to comment #3) > So, what are these "rules of the abstract machine", and why do they allow > non-atomic store of a large volatile aggregate (it is definitely not atomic, > right?), and require atomicity for volatile long? 5.17p3 and 5.17p4 do distinguish between non-aggregate and aggregate assignment: 5.17p3: "If the left operand is not of class type, the expression is implicitly converted (Clause 4) to the cv-unqualified type of the left operand." 5.17p4: "If the left operand is of class type, the class shall be complete. Assignment to objects of a class is defined by the copy/move assignment operator." Of course, the old-days possibility of systems with 8-bit busses limits how much the standard can say, but given that the system in question really can do a 64-bit store, volatile really should force a single store.
[Bug target/56028] Splitting a 64-bit volatile store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028 --- Comment #6 from Paul E. McKenney 2013-01-18 17:40:13 UTC --- The fact that a data-race-free program cannot observe the non-atomicity of a 64-bit store, though true, is beside the point. The plain fact is that hardware registers (for which volatile was intended) really do care about the size of the store. A pair of 32-bit stores does not necessarily mean the same thing to hardware as does a single 64-bit store. Given that C is intended to be used for device drivers, volatile stores of reasonably-sized basic types must be atomic, and on 64-bit systems, "reasonably-sized" very clearly includes 64-bit stores. So this bug really does need to be fixed.
[Bug target/56028] Splitting a 64-bit volatile store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56028 --- Comment #8 from Paul E. McKenney 2013-01-19 12:35:12 UTC --- Indeed, different hardware implementations can cause all sorts of mischief. Nevertheless, the compiler should not also provide mischief in these cases. In addition, as noted in comment 5, there is legacy software. I understand and completely support use of atomics when they are generally available (having assisted in their definition), but many projects will need to work with older compilers for quite some time to come. Therefore, volatile loads, which are only idiom available in these older compilers, needs to continue to provide the needed functionality. Again as noted in comment 5, volatile stores of reasonably-sized basic types must be atomic.
