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 lon
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&action=edit
Add --enable-clocale=ieee_1003.1-2008
This is an initial prototype of a new clocale model.
The wide string i
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 -fe
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 cat
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:
> http://op
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 1
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;
_ZNSt7__cxx1112basic_st
|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 memory_ord
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 LWP
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 whatever
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
i
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 foll
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 z
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 work
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 chron
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/
> 0e65940a7fbc4ed617a1ee111a60311eccbead9a/include/dat
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 chrono
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRME
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 a
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 Jonath
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 (lto_cgr
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
Status|UNCONFIR
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 __d
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, '\xff`)
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Last reconfirmed||2024-04-03
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Looks like I missed this one when it was filed.
The fix is:
--- a/libstdc++-v3/src/c++98
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
merg
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 sh
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 sha
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 repr
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
t
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() {
create(NONE)
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 ne
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]
|--- |14.0
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely ---
The library doesn't require it, an
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 that
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
#ifde
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 &rhs)
{
return t
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 10
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #12 from Jonathan Wakely ---
std::optional's spaceship operator currently looks like this:
template
requires (!__is_optional_v<_Up>)
&& three_way_comparable_with<_Tp, _Up>
constexpr compare_th
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.
> Otherwis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114498
--- Comment #2 from Jonathan Wakely ---
(In reply to Richard Biener from comment #1)
> I'd say deprecating them for a release aka hiding behind a
> -D_YES_I_WANT_TR1_HEADERS and otherwise issueing #error and then axing them
> should be OK.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067
--- Comment #7 from Jonathan Wakely ---
(In reply to Jason Merrill from comment #3)
> Hmm? but the standard says that a precondition for std::is_constructible is
> the type being complete, and we enforce that with a static_assert (since
> PR71579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
--- Comment #10 from Jonathan Wakely ---
Oh interestingly __is_constructible(Incomplete&&, Incomplete) is already
allowed, but __is_nothrow_constructible and __is_convertible give errors:
__is_nothrow_constructible(Incomplete&&, Incomplete)
:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
--- Comment #9 from Jonathan Wakely ---
The changes in
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1285r0.pdf mean that
it's only undefined if the result of is_constructible_v would change
were T completed. So there's no benefit to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
--- Comment #8 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Piotr Nycz from comment #0)
> > It looks that std library code start requiring this to pass:
> > std::is_nothrow_constructible...
>
> Indeed, t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
--- Comment #6 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #2)
> See https://wg21.link/cwg1228 this might be invalid code and GCC is correct
> in rejecting it.
So dup of PR 84849 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
--- Comment #5 from Jonathan Wakely ---
I think this is the same bug, reduced from Bug 100667 comment 1 (where it
wasn't related):
struct allocator_arg_t { explicit allocator_arg_t() = default; };
class string{};
class Foo{};
struct tuple
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
--- Comment #7 from Jonathan Wakely ---
(In reply to Viktor Ostashevskyi from comment #1)
> I have another example, but probably related:
No, this is a completely different problem. See Bug 102257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667
--- Comment #6 from Jonathan Wakely ---
(In reply to Piotr Nycz from comment #0)
> It looks that std library code start requiring this to pass:
> std::is_nothrow_constructible...
Indeed, that's what the standard requires (Clang and MSVC reject
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
We should decide whether we want to keep std::tr1::shared_ptr etc. forever.
Those headers are virtually unmaintained, and just increase testing burden.
They do provide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100381
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90745
--- Comment #8 from Jonathan Wakely ---
Replacing delctype(auto) on the cell::operator=(X&&) function (or constraining
that function to not be instantiated for non-assignable cells) will fix the
code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90745
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114477
--- Comment #7 from Jonathan Wakely ---
The notes say it was closed because you didn't want to work on it.
https://github.com/cplusplus/papers/issues/1726#issuecomment-2014094319
It sounds like the Ranges study group supported the direction. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114488
--- Comment #5 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #4)
> On the gcc-9 branch the first bad commit is r9-8623-g0296697cf9893d
Which was the backport of r11-122.
And as expected, the ICE began on gcc-10 with the gc
601 - 700 of 9180 matches
Mail list logo
