On Fri, 26 Nov 2021 at 16:58, Gabriel Ravier <gabrav...@gmail.com> wrote: > > > On 11/26/21 16:48, Jonathan Wakely via Gcc wrote: > > 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". > The problem is that it's extremely easy to misinterpret, and as such it > is very likely someone who is not paying attention to the very precise > details of the docs and at the exact things they aren't saying, and then > guessing correctly what exactly they meant to say that they aren't > saying, will make a misinterpretation and assume the atomic operations > work on all valid objects, and not only "properly aligned ones" in an > architecture-dependent way that seemingly cannot be determined portably > (libstdc++ just makes sure it's at least as large as sizeof(T), but > that's not necessarily stable, now is it ?). Here, even after making a > through reading and remembering that you can have `alignof(T) < > sizeof(T)`, you have to take a wild guess at whether the fact any > information about this has been omitted means it isn't supported or > means it is supported. > >>>>>> 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. > It is what they *imply*, though, and if you're wondering whether most > people would think so, I can tell you right now I have gone and asked > ~10 people about whether they thought, based on the `__atomic` > documentation (i.e. the > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html web > page), that these builtins would require some kind of alignment or > something like that, and they all thought that it would not (well, some > brought up unaligned objects below `alignof(T)`, but that's just not a > valid object of that type, so it doesn't matter much), whereas the bug > report certainly seems to indicate it can require it in some situations > where `alignof(T) < sizeof(T)`.
And we've already agreed that there is a documentation bug earlier in this thread, and I already confirmed PR 96159 as a documentation bug.
