https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
John David Anglin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #17 from Jonathan Wakely ---
I think this should be fixed now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #16 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:e162b2ff52c5e20f6624ff6b66845fe573cef183
commit r14-9371-ge162b2ff52c5e20f6624ff6b66845fe573cef183
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #15 from dave.anglin at bell dot net ---
On 2024-03-01 5:42 p.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
>
> Jonathan Wakely changed:
>
> What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
Jonathan Wakely changed:
What|Removed |Added
Attachment #57540|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #13 from Jonathan Wakely ---
Ah yes, it still needs some rules_counter, just not using the lock-free alias:
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -705,6 +705,8 @@ namespace std::chrono
#endif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #12 from Jonathan Wakely ---
Ah yes, it still needs some rules_counter, just not using the lock-free alias:
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -705,6 +705,8 @@ namespace std::chrono
#endif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #11 from dave.anglin at bell dot net ---
On 2024-02-29 12:44 p.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
>
> --- Comment #10 from Jonathan Wakely ---
> This additional change should fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #10 from Jonathan Wakely ---
This additional change should fix that:
--- a/libstdc++-v3/src/c++20/tzdb.cc
+++ b/libstdc++-v3/src/c++20/tzdb.cc
@@ -643,6 +643,7 @@ namespace std::chrono
void unlock() { infos_mutex.unlock();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.3
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #9 from dave.anglin at bell dot net ---
On 2024-02-27 9:32 a.m., redi at gcc dot gnu.org wrote:
> Patch posted:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646619.html
Caused build error:
libtool: compile:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #8 from dave.anglin at bell dot net ---
On 2024-02-27 9:32 a.m., redi at gcc dot gnu.org wrote:
> Patch posted:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646619.html
Will test on hppa64-hp-hpux11.11 on my next build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #6 from dave.anglin at bell dot net ---
On 2024-02-26 7:22 a.m., redi at gcc dot gnu.org wrote:
> OK then I think we don't want these aliases to be defined at all (which means
> we cannot be fully C++20 conformant) and the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #5 from Jonathan Wakely ---
OK then I think we don't want these aliases to be defined at all (which means
we cannot be fully C++20 conformant) and the test should be xfailed or skipped.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #4 from dave.anglin at bell dot net ---
On 2024-02-26 5:54 a.m., redi at gcc dot gnu.org wrote:
> I assume the problem is that the ATOMIC_xxx_LOCK_FREE macros have value 1 not
> 2, so they're not unconditionally lock-free.
>
> Are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
Jonathan Wakely changed:
What|Removed |Added
Attachment #57539|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #2 from Jonathan Wakely ---
Created attachment 57539
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57539=edit
make lock-free aliases actually check for lock freedom
Maybe we want to do this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #1 from Jonathan Wakely ---
We define them as:
#ifdef __cpp_lib_atomic_lock_free_type_aliases
# ifdef _GLIBCXX_HAVE_PLATFORM_WAIT
using atomic_signed_lock_free
= atomic>;
using atomic_unsigned_lock_free
= atomic>;
#
19 matches
Mail list logo
