On Wed, 26 Aug 2026, Jakub Jelinek wrote: > Hi! > > The https://wg21.link/P2414R12 paper says that atomic operations on > pointers and reads/stores from/to volatile pointers behave as if > there is an intermediate cast to uintptr_t. > I believe GCC implements it like that since forever. > __sync_*/__atomic_* type-generic builtins if they are lowered to the > particular byte size builtin result in casts to uintptr_t and back > and the changed memory itself is treated as volatile modification, > so in GIMPLE no optimizations that would optimize say points-to > through atomics are possible, I believe we treat it as a pointer escaping > to global state and pointer coming from possibly global state afterwards. > When the atomic builtins are lowered, it is RTL with MEM/v and so treated > as volatile loads/stores/RMWs. > And volatile memory loads/stores/RMWs both in GENERIC, GIMPLE and RTL are > IMHO again treated as something escaping to global state and then something > being read from global state. > > Do you agree we can close https://gcc.gnu.org/PR125835 and apply > following patch to wwwdocs?
I'm not sure, this seems to again be related to provenance? At least "One way to produce a prospective pointer is to cast a valid pointer to uintptr_t and then cast it back to the same pointer type." does not work in GCC. And I don't see why storing a pointer in a atomic<T *> or in volatile storage should be any special. So yes, a 'volatile T *' pointer object has unknown provenance (points-to). But a _Atomic T * need not, IMO, that it currently is would be an implementation detail (one I'd like to fix, for points-to at least). I do not understand why the paper wants std::atomic<T *> to produce a "prospective pointer", and specifically only that. Why not memcpy? Aka void *p; memcpy (p, <source>, sizeof (void *)); Richard. > diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html > index 7acf6920..2fc1c6a6 100644 > --- a/htdocs/projects/cxx-status.html > +++ b/htdocs/projects/cxx-status.html > @@ -146,7 +146,7 @@ > <tr> > <td>Pointer lifetime-end zap proposed solutions</td> > <td><a href="https://wg21.link/P2414R12";>P2414R12</a> (<a > href="./cxx-dr-status.html">DR</a>)</td> > - <td class="unsupported"> <a > href="https://gcc.gnu.org/PR125835";>No</a></td> > + <td class="supported"> Yes</td> > <td></td> > </tr> > <tr> > > > Jakub > > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Jochen Jaser, Andrew McDonald, Abhinav Puri; (HRB 36809, AG Nuernberg)
