Re: GCC libatomic ABI specification draft
Szabolcs Nagy wrote: > On 20/12/16 13:26, Ulrich Weigand wrote: > > I may have missed the context of the discussion, but just on the > > specific ISA question here: both Power and z not only have the > > 16-byte CAS (or load-and-reserve/store-conditional), but they also both > > have specific 16-byte atomic load and store instructions (lpq/stpq > > on z, lq/stq on Power). > > > > Those are available on any system supporting z/Architecture (z900 and up), > > and on any Power system supporting the V2.07 ISA (POWER8 and up). GCC > > does in fact use those instructions to implement atomic operations on > > 16-byte data types on those machines. > > that's a bug. > > at least i don't see how gcc makes sure the libatomic > calls can interoperate with inlined atomics. Hmm, interesting. On z, there is no issue with ISA levels, since *all* 64-bit platforms support the 16-byte atomics (and on non-64-bit platforms, 16-byte data types are not supported at all). However, there still seems to be a problem, but this time related to alignment issues. We do have the 16-byte atomic instructions, but they only work on 16-byte aligned data. This is a problem in particular since the default alignment of 16-byte data types is still 8 bytes on our platform (since the ABI only guarantees 8-byte stack alignment). That's why the libatomic configure check thinks it cannot use the atomic instructions when building on z, and generates code that uses the separate lock. However, *if* a particular object can be proven by the compiler to be 16-byte aligned, it will emit the inline atomic instruction. This means there is indeed a bug if that same object is also operated on via the library routine. Andreas suggested that the best way to fix this would be to add a runtime alignment check to the libatomic routines and also use the atomic instructions in the library whenever the object actually happens to be correctly aligned. It seems that this should indeed fix the problem (and also use the most efficient way in all cases). Not sure about Power -- adding David and Segher on CC ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
Re: GCC libatomic ABI specification draft
On Thu, Dec 22, 2016 at 03:28:56PM +0100, Ulrich Weigand wrote: > However, there still seems to be a problem, but this time related to > alignment issues. We do have the 16-byte atomic instructions, but they > only work on 16-byte aligned data. This is a problem in particular > since the default alignment of 16-byte data types is still 8 bytes > on our platform (since the ABI only guarantees 8-byte stack alignment). > > That's why the libatomic configure check thinks it cannot use the > atomic instructions when building on z, and generates code that uses > the separate lock. However, *if* a particular object can be proven > by the compiler to be 16-byte aligned, it will emit the inline > atomic instruction. This means there is indeed a bug if that same > object is also operated on via the library routine. > > Andreas suggested that the best way to fix this would be to add a > runtime alignment check to the libatomic routines and also use the > atomic instructions in the library whenever the object actually > happens to be correctly aligned. It seems that this should indeed > fix the problem (and also use the most efficient way in all cases). > > > Not sure about Power -- adding David and Segher on CC ... We do not always have all atomic instructions. Not all processors have all, and it depends on the compiler flags used which are used. How would libatomic know what compiler flags are used to compile the program it is linked to? Sounds like a job for multilibs? Segher
gcc-6-20161222 is now available
Snapshot gcc-6-20161222 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20161222/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 243898 You'll find: gcc-6-20161222.tar.bz2 Complete GCC MD5=fb34da93d136920afbfcf5a555e9afd3 SHA1=167709c559d0656463f47e47a841921dae2d9ab9 Diffs from 6-20161215 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
