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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114770
Bug ID: 114770
Summary: std::chrono::locate_zone("Asia/Chungking") fails on
Debian Sid
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
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;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114692
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-04-11
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]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
--- Comment #3 from Jonathan Wakely ---
So maybe:
--- a/libstdc++-v3/src/c++98/istream.cc
+++ b/libstdc++-v3/src/c++98/istream.cc
@@ -112,7 +112,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
basic_istream::
ignore(streamsize __n, int_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
--- Comment #2 from Jonathan Wakely ---
On second thoughts, I don't think that fix is right.
istream::ignore takes an int_type for the delimiter, so passing it a char_type
with a negative value will confuse it. For example, str.ignore(n,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88607
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |9.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
--- Comment #8 from Jonathan Wakely ---
(In reply to Iain Sandoe from comment #7)
> So I am actually asking
> - if the extension actually has any useful meaning?
For non-darwin, yes, it requests the storage of two initializer lists to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114519
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
--- Comment #6 from Jonathan Wakely ---
Yes, I think it's an extension, added by r14-1500-g4d935f52b0d5c0
The question then is whether the attribute is supposed to be a non-binding
request or not.
If it's a non-binding request then the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114553
--- Comment #2 from Jonathan Wakely ---
(In reply to Toni Lammi from comment #0)
> The issue does not seem to be present in trunk.
It seems to be a change in inlining decisions on trunk, because the swap symbol
still isn't exported from the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114553
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> Further reduced:
Actually now that it's no longer a function template we don't even need to
instantiate it to trigger the error, so this is the minimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
--- Comment #3 from Jonathan Wakely ---
Further reduced:
void create(void* u) {
const void* const& r = ( (void)0, u );
}
void test_func() {
create(0);
}
The result of (0, u) is an lvalue of type void* which should then be converted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
--- Comment #2 from Jonathan Wakely ---
Reduced:
void* const NONE = nullptr; //Compiles
void beforeParam();
template
void create(U && u) noexcept {
const void* const& r = ( (void) beforeParam(), u );
}
void test_func() {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57573
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114561
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-04-02
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114536
--- Comment #5 from Jonathan Wakely ---
(In reply to Fedor Chelnokov from comment #2)
> May be just fail constant evaluation then instead of evaluating it to 0?
Hmm, yes, it should fail to produce a constant expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114536
--- Comment #4 from Jonathan Wakely ---
The padding bit has an indeterminate value. Because the result type is an
unsigned char, the indeterminate bit does not produce undefined behaviour, but
it's not allowed in a constant expression.
I don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114479
--- Comment #3 from Jonathan Wakely ---
[dcl.array] says that for T[N] the value "N specifies the array bound, i.e.,
the
number of elements in the array; N shall be greater than zero."
So T[0] is not a valid array type. And std::is_array has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
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=114519
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-03-28
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98842
--- Comment #7 from Jonathan Wakely ---
(In reply to GCC Commits from comment #3)
> Adding that constrain completely breaks std::optional comparisons,
> because it causes constraint recursion. To avoid that, an additional
> check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599
--- Comment #26 from Jonathan Wakely ---
What's bizarre about the PR 104606 case is that this fixes it:
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -1431,7 +1431,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599
--- Comment #25 from Jonathan Wakely ---
It looks like PR 104606 is another case.
#include
#include
#include
struct Value : public std::variant> { };
struct Comparator {
template
bool operator<=(const T )
{
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606
--- Comment #13 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > Just wild guess, perhaps the PR98842 changes between 11.1 and 11.2?
>
> That would mean it is a bug in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113663
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> But I think it would be best to fix it in the compiler, so that we always
> allow directly binding T&& or const T& to T, even if T is incomplete.
>
1 - 100 of 6450 matches
Mail list logo
