https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #17 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #15)
> --- a/libstdc++-v3/include/std/atomic
> +++ b/libstdc++-v3/include/std/atomic
> @@ -238,8 +238,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #16 from Jonathan Wakely ---
Alternatively, we could skip all the padding cope in compare_exchange for
C++11, since that was a C++20 change and not a DR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #15 from Jonathan Wakely ---
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -238,8 +238,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
constexpr atomic(_Tp __i) noexcept : _M_i(__i)
{
-#if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #14 from Jonathan Wakely ---
Because a constexpr function can't have an if statement in C++11.
But maybe we should just clear padding unconditionally for C++11.
||https://gcc.gnu.org/piperma
||il/gcc-patches/2024-May/650
||419.html
Keywords||patch
Assignee|unassigned at gcc dot gnu.org |redi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114147
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
Jonathan Wakely changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> Dup of Bug 102257, which might be what CWG 2586 says should happen, sadly.
Oops 2856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |14.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
--- Comment #2 from Jonathan Wakely ---
Only after the atomic wait/notify refactoring patches have landed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862
--- Comment #3 from Jonathan Wakely ---
I've opened https://cplusplus.github.io/LWG/issue4084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898
--- Comment #1 from Jonathan Wakely ---
Standalone testcase:
struct nullopt_t {
enum class Hidden { Token };
explicit constexpr nullopt_t(Hidden) noexcept { }
};
struct in_place_t {
explicit constexpr in_place_t() = default;
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80977
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114891
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114866
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-04-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862
--- Comment #2 from Jonathan Wakely ---
Libc++ has tests for "INF" (although only for long double, not float or
double), so it's apparently not accidental. The relevant code is:
if (floatfield == ios_base::fixed) {
if (uppercase)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863
--- Comment #2 from Jonathan Wakely ---
Maybe we could also make _M_localize more efficient for finite values by not
even attempting to use grouping for scientific format.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863
--- Comment #1 from Jonathan Wakely ---
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -1734,7 +1734,7 @@ namespace __format
}
#endif
- if (_M_spec._M_localized)
+ if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862
--- Comment #1 from Jonathan Wakely ---
Actually I think we're doing exactly what the standard requires:
ios_base::fmtflags __fltfield = __flags & ios_base::floatfield;
...
// [22.2.2.2.2] Table 58
if (__fltfield ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114862
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
at gcc dot gnu.org |redi at gcc dot gnu.org
Last reconfirmed||2024-04-26
Status|UNCONFIRMED |ASSIGNED
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94753
--- Comment #4 from Jonathan Wakely ---
Maybe I've misunderstood you, but the feature test macros for C++11 features
should definitely be defined for C++11.
They're not "system-specific" or "GCC-specific".
Just because they weren't in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114838
--- Comment #1 from Jonathan Wakely ---
It's guarded with _GLIBCXX_HAS_GTHREADS which is defined by configure when
__GTHREADS_CXX0X is defined by , which for gthr-win32.h means:
#if _WIN32_WINNT >= 0x0600
#define __GTHREAD_HAS_COND 1
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
Jonathan Wakely changed:
What|Removed |Added
Attachment #58015|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
Jonathan Wakely changed:
What|Removed |Added
Attachment #58014|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #7)
> Created attachment 58014 [details]
> Make std::pair relocatable and simplify __relocate_a
>
> Does this help?
Oh hang on, that patch is wrong. I'll fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #7 from Jonathan Wakely ---
Created attachment 58014
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58014=edit
Make std::pair relocatable and simplify __relocate_a
Does this help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #5 from Jonathan Wakely ---
If the problem is simply that the __restrict qualifiers are not present because
we go through the generic function taking iterators, then we can just add:
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #4 from Jonathan Wakely ---
(In reply to Jan Hubicka from comment #2)
> --- a/libstdc++-v3/include/bits/stl_uninitialized.h
> +++ b/libstdc++-v3/include/bits/stl_uninitialized.h
> @@ -1130,7 +1130,58 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #3 from Jonathan Wakely ---
(In reply to Jan Hubicka from comment #2)
> This seems to do the trick, but for some reason I get memmove
What's the second overload for, and why does it depend on _GLIBCXX_HOSTED?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114821
--- Comment #1 from Jonathan Wakely ---
Using memcpy on any std::pair is undefined behaviour because it's not trivially
copyable.
That's not because it has a copy constructor, its copy constructor is defaulted
and so trivial if the data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99934
Jonathan Wakely changed:
What|Removed |Added
CC||pshevchuk at pshevchuk dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114806
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114806
--- Comment #1 from Jonathan Wakely ---
*** Bug 114805 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114805
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #10 from Jonathan Wakely ---
N.B. If you're going to do any more profiling + optimizing of std::vector,
please do it with -std=gnu++20 so that everything is constexpr. Otherwise
you're only testing C++17 which is the last version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #9 from Jonathan Wakely ---
Another solution is just to use __builtin_expect or [[likely]] or [[unlikely]]
at the call site. That wouldn't need any compiler changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #7 from Jonathan Wakely ---
I think we might want to add __attribute__((cold)) to std::vector functions
that are now implicitly inline due to the addition of `constexpr`. We probably
don't want to use noinline as that's too strong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114770
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
ty: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
int main()
{
(void) std::chrono::locate_zone("Asia/Chungking");
}
With the latest tzdata (version 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114758
--- Comment #2 from Jonathan Wakely ---
It's just yet another occurrence of false positive -Wstringop-overflow
warnings, it has nothing to do with vector being special.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> With __val = 9223372036854775808LL __sign = -1LL
Oops, that should be __val = 9223372036854775808ULL and __sign = -1
i.e.
int main()
{
unsigned long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57585
--- Comment #4 from Jonathan Wakely ---
Created attachment 57961
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57961=edit
Add --enable-clocale=ieee_1003.1-2008
This is an initial prototype of a new clocale model.
The wide string info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114050
--- Comment #13 from Jonathan Wakely ---
-fexcess-precision does affect constants.
With -fexcess-precision=standard, assignments and casts discard excess
precision which may otherwise be present in arithmetic expressions and
constants. With
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114742
--- Comment #2 from Jonathan Wakely ---
Mathias noted that still fails with -mcpu=power7
Checking for _ARCH_PWR8 or __POWER8_VECTOR__ instead works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114742
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57585
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> Separately, it would be good to provide a libintl-based implementation of
> std::messages, for targets where that's not part of glibc.
Although the POSIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114740
--- Comment #1 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=41495
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> N.B. messages_base::catalog is required to be a typedef for int, although
> there is an open issue which would allow intptr_t to be used instead:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57585
--- Comment #2 from Jonathan Wakely ---
Separately, it would be good to provide a libintl-based implementation of
std::messages, for targets where that's not part of glibc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749
Bug 106749 depends on bug 113386, which changed state.
Bug 113386 Summary: [C++23] std::pair comparison operators should be
transparent, but are not in libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113386
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
Jonathan Wakely changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114721
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-04-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #9 from Jonathan Wakely ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649260.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #6 from Jonathan Wakely ---
r14-739-gc62e945492afbb incorrectly added them to GLIBCXX_3.4.32 which should
have been frozen after 13.1 but it looks like I thought it was a new version
for 13.2/14.0
Then I must have thought 13.2 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #5 from Jonathan Wakely ---
The *shouldn't* have been added there though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #4 from Jonathan Wakely ---
This were added by r13-7320-g0d5a359140503d which is in 13.2 :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
--- Comment #1 from Jonathan Wakely ---
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -2521,9 +2521,12 @@ GLIBCXX_3.4.31 {
GLIBCXX_3.4.32 {
_ZSt21ios_base_library_initv;
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624
--- Comment #6 from Jonathan Wakely ---
It's also a mostly-harmless ABI change for C++17 down, because the underlying
type without -fshort-enums changes from implicitly being chosen as unsigned
int, to explicitly being specified as int.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89624
--- Comment #5 from Jonathan Wakely ---
I think we should just do this:
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -77,7 +77,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
inline constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114680
--- Comment #2 from Jonathan Wakely ---
There's line 685 too
void
_M_set_options(__pool_base::_Tune __t)
{ __policy_type::_S_get_pool()._M_set_options(__t); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114680
--- Comment #1 from Jonathan Wakely ---
I doubt anybody uses that code anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #8 from Jonathan Wakely ---
Thanks. I hope we'll end up auto-generating a file like that from
../gcc/cp/cxxapi-data.csv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
--- Comment #24 from Jonathan Wakely ---
> * testsuite/30_threads/jthread/95989.cc: New test.
This testcase fails on FreeBSD 14:
Starting program:
/home/gcc/build/x86_64-unknown-freebsd14.0/libstdc++-v3/testsuite/95989.exe
[New
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114675
--- Comment #3 from Jonathan Wakely ---
Yeah I looked for a dup too, as I'm sure this has been reported before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #13 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #11)
> *** Bug 112745 has been marked as a duplicate of this bug. ***
And as suggested in Bug 112745, either lld should Just Work or GCC should work
around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114675
--- Comment #1 from Jonathan Wakely ---
A complete testcase that actually compiles:
struct A { };
struct C { C(const A&); };
struct B { B(const C&); };
struct everything {
everything() : a(), b(c), c(a) { }
A a;
B b;
C c;
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #10 from Jonathan Wakely ---
If --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld is required then it
needs to be documented at https://gcc.gnu.org/install/specific.html#x-x-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #23 from Jonathan Wakely ---
Re https://github.com/cplusplus/draft/issues/6922
It can't possibly mean that the returned time zone *needs* to be the same as
the C library, because that's impossible in general, because the C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #22 from Jonathan Wakely ---
I do still consider it incorrect.
But what I mean re libc++ is that *even ignoring* the general problems with
using TZ, *their implementation* of using TZ isn't even correct. If the
intention is to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #20 from Jonathan Wakely ---
(In reply to Harald van Dijk from comment #18)
> (In reply to Jonathan Wakely from comment #16)
> > ... incorrectly though?
>
> Given that you have expressed your view that *any* attempt at using TZ is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #19 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #16)
> I would expect TZ=:Europe/London to work according to POSIX,
Well, POSIX says ":characters" is implementation-defined, but for Glibc it
looks up an IANA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #17 from Jonathan Wakely ---
And "Factory" isn't a valid POSIX zone, so remove that one from the list. So if
I'm reading it correctly, some European zones and the US zones can be used in
$TZ with libc++ but most IANA zones won't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #16 from Jonathan Wakely ---
(In reply to Harald van Dijk from comment #14)
> (In reply to Jonathan Wakely from comment #8)
> > None of libstdc++, LLVM libc++, MSVC STL or the
> > date/tz.h reference implementation uses $TZ for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #15 from Jonathan Wakely ---
(In reply to Hristo Venev from comment #13)
> > $TZ allows you to override it per-process (and even change it during the
> > lifetime of a process by using setenv and tzset). We don't support that for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114633
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #12 from Jonathan Wakely ---
(In reply to Hristo Venev from comment #9)
> I stumbled upon this comment in the library you linked:
>
> https://github.com/HowardHinnant/date/blob/
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #8 from Jonathan Wakely ---
Yes, if an application assumes that chrono::current_zone matches $TZ, that's a
bug in the application. None of libstdc++, LLVM libc++, MSVC STL or the
date/tz.h reference implementation uses $TZ for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #5 from Jonathan Wakely ---
The libc time zone doesn't necessarily correspond to anything in the IANA
database anyway. If you use a POSIX time zone definition like TZ="abc4abd" then
libc will use that to generate a custom time zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #3 from Jonathan Wakely ---
What does "quite a bit completely useless" mean? current_zone() tells you what
/etc/localtime is set to. So it's as useless as /etc/localtime, no more and no
less.
Did you read the messages I linked to?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #1 from Jonathan Wakely ---
Ignoring $TZ is a feature, not a bug.
See https://gcc.gnu.org/pipermail/libstdc++/2023-May/055928.html and the
replies, including https://gcc.gnu.org/pipermail/libstdc++/2023-May/055933.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114615
--- Comment #3 from Jonathan Wakely ---
The dumb part is that __n here comes from wcslen(__s2), so the compiler is able
to track that __s2 is only two bytes, but not capable of tracking that __n ==
0.
Specifically, __n is (__s2 + wcslen(__s2))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114615
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114633
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53341
--- Comment #3 from Jonathan Wakely ---
Bisections indicates it was fixed by this commit:
commit ead84f73b0a0f39ea39aa0329b6da83e4a9e6e02 [r0-116315-gead84f73b0a0f3]
Author: Jan Hubicka
Date: Fri Apr 20 15:09:11 2012
lto-symtab.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84568
--- Comment #16 from Jonathan Wakely ---
It's a shame the fix happened after the inferior shared_ptr implementation was
frozen into libstdc++ though :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11196
Jonathan Wakely changed:
What|Removed |Added
CC||zwuis at outlook dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114602
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114585
--- Comment #2 from Jonathan Wakely ---
The bug reporting guidelines you were asked to read say to try
-fsanitize=undefined and if you'd done that you'd have seen errors:
https://godbolt.org/z/bscj8q9rr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
Jonathan Wakely changed:
What|Removed |Added
Summary|std::basic_istream::ignore |[11/12/13/14 Regression]
101 - 200 of 22420 matches
Mail list logo
