On Monday, 1 March 2021 14:31:09 PST Ville Voutilainen wrote:
> On Tue, 2 Mar 2021 at 00:21, Thiago Macieira
wrote:
> > But the code I posted, if people are careful to use write like I did,
> > would
> > allow us to have the experimental "we're not sure this is right"
> > implementation of
On Tue, 2 Mar 2021 at 00:21, Thiago Macieira wrote:
> But the code I posted, if people are careful to use write like I did, would
> allow us to have the experimental "we're not sure this is right"
> implementation of atomic waits, latches, barriers and semaphores right now.
The code assumes
On Monday, 1 March 2021 14:04:34 PST Ville Voutilainen wrote:
> Well, this would be different. What I'm suggesting is not quite that;
> for any *new* facility, we'd make sure
> that its draft macro and the final IS macro are different, but the
> minimum value is the first draft version,
> not
On Mon, 1 Mar 2021 at 23:54, Thiago Macieira wrote:
> But your suggestion does work. We don't need to apply them to all macros, only
> those that are new in a given version, like __cpp_lib_atomic_wait or
> __cpp_lib_latch in this case. Alternatively, implementations can set the macro
> to a given
On Monday, 1 March 2021 12:35:05 PST Ville Voutilainen wrote:
> I can't make the above code work, in any reasonable manner, because
> it's doing feature detection incorrectly. :)
> What I can imagine doing, however, is this:
>
> 1) a published IS always bumps feature-macro values (this won't help
On Mon, 1 Mar 2021 at 21:44, Thiago Macieira wrote:
> But you can see someone doing:
>
> #if __cplusplus >= 202002L && __has_include()
> # include
> #else
> # error "Please upgrade your compiler & standard library"
> #endif
>
> and using in their inline code. And as you say, if they then mix
On Monday, 1 March 2021 10:12:35 PST Ville Voutilainen wrote:
> I do have a question about the intent/concern here, regardless of what
> your patch technically
> does. The ABI break _is_ your concern, and the "heisenbugs" you were
> worried about would
> in fact be caused by the ABI break? So if
On 2021-03-01 10:06, Thiago Macieira wrote:
On Monday, 1 March 2021 09:38:58 PST Thomas Rodgers wrote: And
_M_phase, despite being non-atomic, is never accessed without the
atomic_ref, aside from the constructor. Both arrive() and wait() start
off by
creating the atomic_ref.
If it's
On Mon, 1 Mar 2021 at 20:09, Thiago Macieira via Libstdc++
wrote:
>
> On Sunday, 28 February 2021 07:05:47 PST Hans-Peter Nilsson wrote:
> > On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
> > > ints can be used in futexes. chars can't.
> >
> > Shouldn't that be an atomic type instead
On Monday, 1 March 2021 09:38:58 PST Thomas Rodgers wrote:
> > And _M_phase, despite being non-atomic, is never accessed without the
> > atomic_ref, aside from the constructor. Both arrive() and wait() start
> > off by
> > creating the atomic_ref.
>
> If it's non-atomic, then how is wait()
Botched replying to the list, sending again
On 2021-03-01 09:38, Thomas Rodgers wrote:
On 2021-03-01 09:24, Thiago Macieira via Libstdc++ wrote:
On Sunday, 28 February 2021 07:05:47 PST Hans-Peter Nilsson wrote: On
Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote: ints can be
used in
On 2021-03-01 09:24, Thiago Macieira via Libstdc++ wrote:
On Sunday, 28 February 2021 07:05:47 PST Hans-Peter Nilsson wrote: On
Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote: ints can be
used in futexes. chars can't.
Shouldn't that be an atomic type instead of a bare int then?
On Sunday, 28 February 2021 07:05:47 PST Hans-Peter Nilsson wrote:
> On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
> > ints can be used in futexes. chars can't.
>
> Shouldn't that be an atomic type instead of a bare int then?
There are a couple of atomic_refs:
using
On 2021-02-28 07:05, Hans-Peter Nilsson wrote:
On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
ints can be used in futexes. chars can't.
Shouldn't that be an atomic type instead of a bare int then?
It's an atomic_ref.
---
libstdc++-v3/include/std/barrier | 21
On Fri, 26 Feb 2021, Thiago Macieira via Gcc-patches wrote:
> ints can be used in futexes. chars can't.
Shouldn't that be an atomic type instead of a bare int then?
> ---
> libstdc++-v3/include/std/barrier | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff
ints can be used in futexes. chars can't.
---
libstdc++-v3/include/std/barrier | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/libstdc++-v3/include/std/barrier b/libstdc++-v3/include/std/barrier
index e09212dfcb9..ae058bd3dc3 100644
---
16 matches
Mail list logo
