https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244
--- Comment #1 from Jonathan Wakely ---
Yup, the seconds part "00.002" is parsed using std::numpunct (in order to
handle the locale's decimal point) and then converted to milliseconds using
duration_cast:
auto& __ng =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
--- Comment #5 from Jonathan Wakely ---
>using __format::_ChronoParts;
>auto __need = _ChronoParts::_Year | _ChronoParts::_Month
> - | _ChronoParts::_Day | _ChronoParts::_TimeOfDay;
> + |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106851
--- Comment #6 from Jonathan Wakely ---
Excellent! Thanks for the fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114260
Bug ID: 114260
Summary: std::formatter> formats as the previous day
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
--- Comment #4 from Jonathan Wakely ---
This has revealed another bug in some of the from_stream overloads, due to
Clock::from_sys / Clock::from_utc sometimes returning a higher precision value
than the input argument (due to using the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114256
Bug ID: 114256
Summary: std::filebuf::setbuf does nothing if the file is open
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114245
Jonathan Wakely changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106851
--- Comment #4 from Jonathan Wakely ---
I tried doing it this way instead
namespace std {
export using std::vector;
namespace pmr {
export using std::vector;
}
}
but that didn't work, nothing got exported. But maybe that will be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #12 from Jonathan Wakely ---
(In reply to Dimitry Andric from comment #10)
> Note there are other issues with poisoned identifiers, so I'll ask again: is
> a non-bootstrapped build even supposed to work, and officially supported, or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #21 from Jonathan Wakely ---
(In reply to g.peterhoff from comment #19)
> * You were probably wondering why I wrote "if (std::isinf(x) | std::isinf(y)
> | std::isinf(z))", for example. This is intentional. The problem is that gcc
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
--- Comment #3 from Jonathan Wakely ---
So this would fix it:
--- a/libstdc++-v3/include/bits/chrono_io.h
+++ b/libstdc++-v3/include/bits/chrono_io.h
@@ -2826,7 +2826,9 @@ namespace __detail
__offset = &__off;
using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
--- Comment #1 from Jonathan Wakely ---
I think the problem is that I just have some generic logic that assumes all
sys_time specializations are a date time, and so require both a date and a
time. But obviously for sys_days we only need a date.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-03-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307
--- Comment #5 from Jonathan Wakely ---
return EnumeratorRange(Enumerator(std::views::single(Intersection(;
This creates a temporary Intersection object, then copies that into a
single_view object. Then that is copied into an Enumerator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
Jonathan Wakely changed:
What|Removed |Added
CC||jlame646 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114237
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114237
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106390
--- Comment #6 from Jonathan Wakely ---
Related work: http://thradams.com/cake/ownership.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114223
--- Comment #3 from Jonathan Wakely ---
(In reply to Дилян Палаузов from comment #0)
> I want to create a treeless-copy of the git://gcc.gnu.org/git/gcc.git .
N.B. you could have just used https://github.com/gcc-mirror/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841
--- Comment #12 from Jonathan Wakely ---
There's no problem with pair, it's basic_string that fails.
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=113841
--- Comment #10 from Jonathan Wakely ---
This one's much harder to fix:
#include
template
struct Alloc
{
using value_type = T;
Alloc(int) { }
template Alloc(const Alloc&) { }
T* allocate(std::size_t n) { return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #33 from Jonathan Wakely ---
This is now https://cplusplus.github.io/CWG/issues/2868.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84414
--- Comment #8 from Jonathan Wakely ---
This is now https://cplusplus.github.io/CWG/issues/2868.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114147
--- Comment #7 from Jonathan Wakely ---
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/646989.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #12 from Jonathan Wakely ---
(In reply to g.peterhoff from comment #11)
> Would this be a good implementation for hypot3 in cmath?
Thanks for the suggestion!
> #define GCC_UNLIKELY(x) __builtin_expect(x, 0)
> #define GCC_LIKELY(x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114181
--- Comment #14 from Jonathan Wakely ---
Libc headers define lots of macros, we don't #undef them in C++ headers unless
they use the name of a function defined by the C++ library (because C++ says
its library functions must be real functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
Jonathan Wakely changed:
What|Removed |Added
Summary|[11/12/13 Regression] |[11/12 Regression] std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114152
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114147
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
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=114153
--- Comment #4 from Jonathan Wakely ---
Created attachment 57577
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57577=edit
Check for <=>
Something like this (but it's also needed for std::greater and std::less_equal)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101228
--- Comment #16 from Jonathan Wakely ---
Maybe we could do something like this:
--- a/libstdc++-v3/include/pstl/parallel_backend_tbb.h
+++ b/libstdc++-v3/include/pstl/parallel_backend_tbb.h
@@ -15,6 +15,11 @@
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114153
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> Without looking at the code, we probably just need to check if the type has
> a usable operator<=>.
>
> We check it out had
Sorry, phone typos.
"We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114153
--- Comment #2 from Jonathan Wakely ---
Without looking at the code, we probably just need to check if the type has a
usable operator<=>.
We check it out had a usable operator< which worked fine in C++17, but in C++20
x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114152
--- Comment #3 from Jonathan Wakely ---
I can take care of it this time, since I think I can figure out how to fix it
just from your detailed report :-) and I've already written a testcase:
// { dg-do compile { target c++20 } }
// PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114152
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114152
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114147
Jonathan Wakely changed:
What|Removed |Added
Known to work|14.0|
Summary|[11/12/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114149
Bug ID: 114149
Summary: lexicographical_compare should use memcmp for C++20
contiguous iterators as well as pointers
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
Jonathan Wakely changed:
What|Removed |Added
Summary|std::map with std::vector |[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114147
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-02-28
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106851
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=114135
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
--- Comment #11 from Jonathan Wakely ---
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -1824,11 +1824,14 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
}
#if __cpp_lib_three_way_comparison
- // Iter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
--- Comment #10 from Jonathan Wakely ---
Oh I already defined a __is_memcmp_ordered_with trait, which does the same-size
check. I think that's what should be used here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
--- Comment #8 from Jonathan Wakely ---
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -1824,8 +1824,9 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
}
#if __cpp_lib_three_way_comparison
- // Iter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
--- Comment #7 from Jonathan Wakely ---
Ohhh, I forgot I did that, sorry!
Yeah, the memcmp code wasn't updated to match the different behaviour of
__is_byte_iter for BE.
We can't use memcmp if the sizes are different. We don't want to use the
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=114131
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-02-27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114129
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
--- Comment #5 from Jonathan Wakely ---
But it's guarded by:
if constexpr (__is_byte_iter<_InputIter1>)
if constexpr (__is_byte_iter<_InputIter2>)
This condition is only supposed to be true when sizeof(*__first1) == 1 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114118
--- Comment #2 from Jonathan Wakely ---
I don't think we want to enable all the functions etc. because those
aren't expected to be present before C++23. But the types like _Float32 are
already present, and that seems fine. I just think we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114118
Bug ID: 114118
Summary: std::is_floating_point<_Float32> and
__is_floating<_Float32> are false in C++20 and older
Product: gcc
Version: 14.0
Status: UNCONFIRMED
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=114110
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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>;
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114104
--- Comment #3 from Jonathan Wakely ---
I don't care whether GCC synthesizes an operator!= that inherits the nodiscard
attribute, or it generates a discarded bool using the built-in !, but there
needs to be a warning either way.
Currently a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114104
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114104
Bug ID: 114104
Summary: nodiscard not diagnosed on synthesized operator!=
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98520
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2021-01-07 00:00:00 |2024-2-25
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114088
--- Comment #4 from Jonathan Wakely ---
(In reply to Xi Ruoyao from comment #2)
> But __builtin_strlen *does* get optimized when the input is a string
> literal.
But so does strlen, because GCC knows about it. That's my point.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114088
--- Comment #1 from Jonathan Wakely ---
GCC built-ins like __builtin_strlen just wrap a libc function. __builtin_wcslen
would generally just be a call to wcslen, which doesn't give you much. I assume
what you want is to recognize wcslen and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114085
Jonathan Wakely changed:
What|Removed |Added
Component|libstdc++ |rtl-optimization
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
Jonathan Wakely changed:
What|Removed |Added
CC||macro at orcam dot me.uk
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #4 from Jonathan Wakely ---
You could have checked this very easily using -fsanitize=undefined just like it
asks you to at https://gcc.gnu.org/bugs/ and at the top of the page when you
created this bug.
dst is 512-bit aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #9 from Jonathan Wakely ---
See the first item at https://gcc.gnu.org/gcc-13/changes.html#cxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #7 from Jonathan Wakely ---
And the first item at https://gcc.gnu.org/bugs/#nonbugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #17 from Jonathan Wakely ---
Or just:
template
__enable_if_t::value>
nexttoward(_Tp, long double) = delete;
So that it is present for C++11 and so works when _Float32 and _Float64 names
are used instead of the C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #16 from Jonathan Wakely ---
We could also just add:
#if __cplusplus > 202002L
template
void
nexttoward(_Tp, long double) = delete;
#endif
The existing overloads would be preferred for float, double, long double and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #15 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #13)
> Then I wonder what was the reason for the final LWG3790 revision, the middle
> proposed resolution seems to be much more readable and understandable where
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #15 from Jonathan Wakely ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #14)
> Further research has uncovered some interesting facts:
>
> * Neither the SysV SPARC psABI (3rd Edition, 1996) nor the original i386
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113782
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #10 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #8)
> So, do we need to define those and std::unreachable (); in their bodies or
> something similar?
No, it needs to be ill-formed to call them, which is already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-02-20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107745
--- Comment #8 from Jonathan Wakely ---
(In reply to Xi Ruoyao from comment #6)
> (In reply to Sebastian "spaetz" Spaeth from comment #5)
> > I fully understand that nobody wants to invest time into fixing this. What
> > would be nice though,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #32 from Jonathan Wakely ---
[basic.stc.general] says global == is implementation-defined if global is an
invalid pointer value, not just unspecified. GCC could define it to be
unspecified, or UB, and even say "it's UB just in this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84414
--- Comment #7 from Jonathan Wakely ---
(In reply to Richard Smith from comment #2)
> In fact, I think the *only* problem here is that the above rule does not
> allow the caller and the callee to observe the objects having the same
> address.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #28 from Jonathan Wakely ---
What I tried to say in comment 26 is that we're allowed to always make the
extra copy, which means that global is an invalid pointer, so the program has
UB.
I think the only flaw in that reasoning is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #26 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #25)
> However, [class.temporary] p3 explicitly allows the compiler to create a
> temporary object when returning a class with a trivial copy constructor and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109945
--- Comment #25 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #9)
> struct Widget {
> int i;
> int a[4];
> };
> Widget *global = 0;
> Widget make2() { Widget w; w.i = 1; global = return w; }
> void g() { global->i =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779
--- Comment #12 from Jonathan Wakely ---
Then the maintainers or users of those targets should consider contributing a
fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66416
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113981
--- Comment #2 from Jonathan Wakely ---
With -O0 or -fsanitize-trap=return you get a trap. With -fsanitize=return you
get a UBsan error. With -O3 you asked the compiler to optimize the heck out of
a function with undefined behaviour, what do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113961
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113060
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113931
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113931
--- Comment #3 from Jonathan Wakely ---
Oh but I did rerun that one and still missed the FAIL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113931
Jonathan Wakely changed:
What|Removed |Added
Component|other |libstdc++
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99546
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2022-09-20 00:00:00 |2024-2-15
--- Comment #8 from
401 - 500 of 6616 matches
Mail list logo
