On Fri, 26 Nov 2021 at 15:41, Martin Uecker <ma.uec...@gmail.com> wrote: > > Am Freitag, den 26.11.2021, 09:24 +0000 schrieb Jonathan Wakely: > > On Fri, 26 Nov 2021 at 09:00, Martin Uecker via Gcc <gcc@gcc.gnu.org> wrote: > > > Am Freitag, den 26.11.2021, 09:29 +0100 schrieb Eric Botcazou: > > > > > This is a silent and dangerous incorrect code generation issue. > > > > > > > > Let's avoid this kind of FUD, please, builtins are low-level devices and > > > > people must know what they are doing and be prepared for caveats. > > > > > > Sorry, I do not think this FUD. One needs to look at the assembly > > > and know *very specific* details about the platform and atomics > > > to understand that it does not work and silently (!) breaks on > > > GCC (and not clang) in very rare cases. This with no indication > > > about this in the documentation which clearly implies that > > > this works for "all types". > > > > It does. Two objects of type T are still the same type whether or not > > they are both aligned to sizeof(T). > > Yes, but only under special circumstances which are > not automatically fulfilled for all types.
Erm, two objects of type T are always the same type. My point is that the docs say "works for all types", not "works for all objects of all types". You are claiming the docs are misleading, I'm saying you're misreading them. They do not say "all objects of all types". > > > > > > If these functions are not meant to be used to exising > > > > > data, then at least the documentation needs to be changed > > > > > and include a big warning that this only happens to work > > > > > corectly if the data has sufficient alignment for the > > > > > specific architecture (which of course makes it impossible > > > > > to use this in a portable way). > > > > > > > > The last part of the sentence is again a blatant overstatement > > > > > > Then please explain how one is supposed to use in a portable way if > > > it sometimes work or not based on platform-specific alignment > > > properties. > > > > Either align your variable to its size, or don't use non-portable > > compiler built-ins, use _Atomic. > > > > If you want to be able to perform atomic operations on non-_Atomic > > objects portably, that seems like a useful addition to the C standard > > library (like std::atomic_ref in C++20). > > The problem is that atomic_ref also only works if the > alignment fulfills special requirements. So it can not > always be used on existing data structures. > > I think it would be helpful if a compiler supports this by > providing suitable builtins, which it could easily do. > > Since the existing builtins are already documented in a > way that implies that they allow exactly this, it would > be better and safer to just make this work. That's not what the docs say though.
