atomic_load
It would be great if somebody could take a look at PR96159. It seems we do not do atomic accesses correctly when the alignment is insufficient for a lockfree access, but I think we should fall back to a library call in this case (as clang does). This is very unfortunate as it is an important functionality to be able to do atomic accesses on non-atomic types and it seems there is no way to achieve this. Also documentation and various descriptions of the atomic functions imply that this is expected to work. But maybe I am missing something and the generated code is indeed safe. Martin
Re: atomic_load
* Martin Uecker via Gcc: > It would be great if somebody could take a look at > PR96159. > > It seems we do not do atomic accesses correctly > when the alignment is insufficient for a lockfree > access, but I think we should fall back to a > library call in this case (as clang does). > > This is very unfortunate as it is an important > functionality to be able to do atomic accesses > on non-atomic types and it seems there is no way > to achieve this. GCC should probably warn about this, and ensure that objects declared _Atomic have increased alignment. But adding run-time checks to all atomic accesses does not make sense. We want to move user code away from bespoke atomics implementations, and this would be contrary to that goal. Thanks, Florian
Re: atomic_load
Am Sonntag, den 07.11.2021, 10:24 +0100 schrieb Florian Weimer: > * Martin Uecker via Gcc: > > > It would be great if somebody could take a look at > > PR96159. > > > > It seems we do not do atomic accesses correctly > > when the alignment is insufficient for a lockfree > > access, but I think we should fall back to a > > library call in this case (as clang does). > > > > This is very unfortunate as it is an important > > functionality to be able to do atomic accesses > > on non-atomic types and it seems there is no way > > to achieve this. > > GCC should probably warn about this, and ensure that objects declared > _Atomic have increased alignment. But adding run-time checks to all > atomic accesses does not make sense. We want to move user code away > from bespoke atomics implementations, and this would be contrary to that > goal. You do not build trust in your API if you silently create incorrect code. If the alignment is sufficient as guaranteed by the type, clang also does not use a run-time check. Martin
gcc-12-20211107 is now available
Snapshot gcc-12-20211107 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20211107/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 962ff7d2849e1fa6a1fe0535aa2dec5c2b9a32a6 You'll find: gcc-12-20211107.tar.xz Complete GCC SHA256=62ba58b3c1871a3a71b68f21ec9648dd524b6409f86917a46c2bf1f9ed568c82 SHA1=4500615f647af8150848fa389938eea6dcd6cf5a Diffs from 12-20211031 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 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.
