https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99277
--- Comment #23 from Thomas Rodgers ---
(In reply to Thiago Macieira from comment #21)
> I understand that. I don't think it's a reason to repeat the policy, though.
>
> Anyway, I don't have any new arguments than when we discussed this two year
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99277
--- Comment #16 from Thomas Rodgers ---
(In reply to Thiago Macieira from comment #15)
> > > 5) std::barrier implementation also uses a type that futex(2) can't
> > > handle
>
> > barrier still uses a 1-byte enum for the atomic waits.
>
> Tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103934
Thomas Rodgers changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 103934, which changed state.
Bug 103934 Summary: std::atomic_flag: multiple C++20 functions missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103934
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
Thomas Rodgers changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
--- Comment #4 from Thomas Rodgers ---
(In reply to Jiang An from comment #3)
> > is_nothrow_invocable_v shall be true.
>
> If implementation divergence is not intendedly permitted, I don't think it
> makes much sense to introduce UB in this wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #25 from Thomas Rodgers ---
(In reply to Mkkt Bkkt from comment #24)
> (In reply to Thomas Rodgers from comment #22)
> > Your example of '100+ core' systems especially on NUMA is certainly a valid
> > one. I would ask, at what point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #22 from Thomas Rodgers ---
(In reply to Mkkt Bkkt from comment #20)
> My main concern with this optimization it's not zero-overhead.
>
> It's not necessary when we expect we have some waiters, in that case it just
> additional sync
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #21 from Thomas Rodgers ---
(In reply to Mkkt Bkkt from comment #16)
> > it with sarcasm
>
> I started with sarcasm because you restart this thread with some doubtful
> benchmarks without code for them.
>
> I think it's very disres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #17 from Thomas Rodgers ---
Created attachment 53638
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53638&action=edit
benchmark main.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #11 from Thomas Rodgers ---
(In reply to Mkkt Bkkt from comment #9)
> Why do you think you smarter than msvc stl, libc++, boost::atomic developers?
>
> Maybe it's about your "I"?
I should ignore this (see jwakely's response), but -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #6 from Thomas Rodgers ---
(In reply to Mkkt Bkkt from comment #5)
> Single reason why I want to use atomic::wait/notify is cross platform api
> for futex, wait/wake on address, ulock, etc
> Not because I need YOU decide instead of m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
--- Comment #3 from Thomas Rodgers ---
Since this latter point has come up before, I want to additionally note that
the optimization to use an atomic count of waiters per-waiter pool bucket means
that a call to notify_one/notify_all is roughly 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106772
Thomas Rodgers changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936
Thomas Rodgers changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106183
Thomas Rodgers changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102994
Thomas Rodgers changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100806
Thomas Rodgers changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102994
--- Comment #14 from Thomas Rodgers ---
Created attachment 52420
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52420&action=edit
Make notify_one/notify_all non-const
I submitted this patch to the list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
--- Comment #20 from Thomas Rodgers ---
(In reply to Jakub Jelinek from comment #17)
...
> I don't remember the std::bit_cast case right now, OpenMP atomics are about
Not sure if this is what you are talking about (frankly most of this is well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104442
Thomas Rodgers changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104442
--- Comment #4 from Thomas Rodgers ---
(In reply to Jonathan Wakely from comment #3)
> Tom submitted
> https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590050.html already,
> which is slightly different.
The primary difference was changi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104442
Thomas Rodgers changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102994
Thomas Rodgers changed:
What|Removed |Added
Status|REOPENED|SUSPENDED
--- Comment #11 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102994
--- Comment #7 from Thomas Rodgers ---
(In reply to Óscar Fuentes from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > (In reply to Óscar Fuentes from comment #4)
> > > The fix is wrong. It changes atomic_notify_one and atomic_no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 102074, which changed state.
Bug 102074 Summary: include/bits/atomic_timed_wait.h:215: possible missing
return ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102074
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102074
Thomas Rodgers changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102377
--- Comment #2 from Thomas Rodgers ---
(In reply to Jonathan Wakely from comment #1)
> The reason we don't see it in every test is that this one uses:
>
> // { dg-options "-Wsystem-headers -Wnarrowing" }
>
> But I think the warning is pointing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #11 from Thomas Rodgers ---
(In reply to Jonathan Wakely from comment #10)
> http://eel.is/c++draft/atomics#ref.generic.general-3.sentence-2
>
> "While any atomic_ref instances exist that reference the *ptr object, all
> accesses t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #5 from Thomas Rodgers ---
(In reply to Florian Weimer from comment #4)
> I think it's a test bug:
>
> std::atomic_ref a{ aa };
>
> std::thread t([&]
> {
> a.store(bb);
> a.notify_one();
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #3 from Thomas Rodgers ---
This appears to be the test case itself.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101274
--- Comment #6 from Thomas Rodgers ---
It does raise an issue which I'm going to follow up on separately on the SG1
(concurrency and parallelism study group) mailing list.
While it is indeed the case that standard says you can't count on determ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101274
--- Comment #4 from Thomas Rodgers ---
I did some more reading of
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4878.pdf and it would
seem that you are not even guaranteed a deterministic ordering of the
application of binary_op on th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101274
Thomas Rodgers changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228
Thomas Rodgers changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rodgertq at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100806
--- Comment #2 from Thomas Rodgers ---
I have confirmed that this is new issue, not related to PR100334.
When there are waiting threads and the semaphore attempts to release one of
the waiting threads, the FUTEX_WAKE syscall's return indicates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100889
Thomas Rodgers changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100889
Thomas Rodgers changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100806
Thomas Rodgers changed:
What|Removed |Added
Last reconfirmed||2021-05-28
Assignee|unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
Thomas Rodgers changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
Thomas Rodgers changed:
What|Removed |Added
Keywords||patch
--- Comment #8 from Thomas Rodge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
Thomas Rodgers changed:
What|Removed |Added
Status|WAITING |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
Thomas Rodgers changed:
What|Removed |Added
Status|ASSIGNED|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
Thomas Rodgers changed:
What|Removed |Added
Attachment #50728|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
--- Comment #6 from Thomas Rodgers ---
Created attachment 50728
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50728&action=edit
Fix wrong thread getting notification
I am testing this patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
Thomas Rodgers changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334
--- Comment #4 from Thomas Rodgers ---
This analysis is likely correct, except for -
"- protect from spurious wakeups in __waiter_pool::_M_do_wait by rechecking if
the value has changed from old, if not then wait again"
An earlier version of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100164
--- Comment #16 from Thomas Rodgers ---
The _M_try_acquire() change should be on master and gcc-11 now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100164
--- Comment #15 from Thomas Rodgers ---
>From the most recent patch -
+_GLIBCXX_ALWAYS_INLINE bool
+_M_try_acquire() noexcept
+{
+ for (;;)
+ {
+ auto __err = sem_trywait(&_M_semaphore);
+ if (__err && (er
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100164
Thomas Rodgers changed:
What|Removed |Added
Attachment #50643|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100164
--- Comment #7 from Thomas Rodgers ---
Created attachment 50645
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50645&action=edit
Disable on unsupported targets
Let's try this with the right patch attached this time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100164
--- Comment #4 from Thomas Rodgers ---
It would appear that I cannot log into either of the AIX machines in the
compile farm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100164
--- Comment #3 from Thomas Rodgers ---
Created attachment 50643
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50643&action=edit
Disable on unsupported targets
This patch is probably not the most elegant way to do this, it probably shoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100164
Thomas Rodgers changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rodgertq at gcc dot
gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97936
--- Comment #16 from Thomas Rodgers ---
I believe it is addressed in the most recent patch I have submitted for the
atomic wait/notify, barriers, latches, semaphores functionality.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98034
Thomas Rodgers changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97719
Bug ID: 97719
Summary: "Implement C++20 features for " changed
behavior of istreambuf_iterator
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
57 matches
Mail list logo
