https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99979
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-04-08
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99985
Jonathan Wakely changed:
What|Removed |Added
Summary|[11 Regression] |[10/11 Regression]
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99985
--- Comment #2 from Jonathan Wakely ---
Aside: is there a good reason those packages use -std=c++11? Did they just add
it ten years ago to enable "new" C++ features? Because now they're *disabling*
features by not using the compiler's default -st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99985
--- Comment #4 from Jonathan Wakely ---
We can still make it short circuit (and so not instantiate class templates
unnecessarily) like this:
#if __cplusplus <= 201402L
return __and_<__bool_constant<_No_realloc>,
is_not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Bug ID: 5
Summary: [11 Regression] FAIL:
17_intro/headers/c++1998/49745.cc with -std=gnu++20
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96029
--- Comment #10 from Jonathan Wakely ---
See Bug 99983
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99983
--- Comment #11 from Jonathan Wakely ---
This should fix it:
--- a/libstdc++-v3/include/bits/hashtable.h
+++ b/libstdc++-v3/include/bits/hashtable.h
@@ -1319,8 +1319,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_H1, _H2, _Hash, _RehashPo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99983
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #12 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99985
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
Bug 2 depends on bug 99985, which changed state.
Bug 99985 Summary: [9/10/11 Regression] bits/hashtable.h:483:9: error: body of
‘constexpr’ function ... not a return-statement since
g:1cbba49e3417d9b0661e70301d6fb7a7f52fd360
https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99983
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546
--- Comment #23 from Jonathan Wakely ---
The other improvement we could make for C++20 is to replace in
with smaller pieces, as it doesn't need the definition
of std::streambuf_iterator:
--- a/libstdc++-v3/include/bits/ranges_algobase.h
+++ b/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99983
--- Comment #18 from Jonathan Wakely ---
(In reply to Maxim Kuvyrkov from comment #3)
> It appears to be
> ===
> commit 1c4e8a96cd695c03ff85299bf2392476feae99bb
> Author: François Dumont
> Date: Mon Jan 20 19:15:43 2020 +0100
>
> libstdc++: Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15
--- Comment #1 from Jonathan Wakely ---
Because it's declared as:
extern __inline int
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
_rdrand64_step (unsigned long long *__P)
The artificial attribute prevents taking the add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18
--- Comment #1 from Jonathan Wakely ---
Dup of bug 96733?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-04-10
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100020
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100020
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100044
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100044
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057
--- Comment #24 from Jonathan Wakely ---
(In reply to cqwrteur from comment #16)
> d:\cross_toolchains\x86_64-elf\x86_64-elf\include\c++\11.0.1\bit:37:10:
> fatal error: ext/numeric_traits.h: No such file or directory
>37 | #include
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100060
Bug ID: 100060
Summary: [10/11 Regression] freestanding header includes
non-freestanding
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Keywords: rejects-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057
--- Comment #25 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #24)
> This is a regression, please report a separate bug about this part.
Reported as Bug 100060, fix already written (because when you report a clear,
focused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100060
Jonathan Wakely changed:
What|Removed |Added
Known to work||9.3.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100060
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Ev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100057
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100065
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99846
--- Comment #5 from Jonathan Wakely ---
We can reduce this further:
#include
#include
struct Value;
using Array = std::list;
using Variant = std::variant;
struct Value : Variant {};
int main()
{
Value left;
Value right;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99846
--- Comment #6 from Jonathan Wakely ---
Oops, sorry, I meant to paste this as the further reduced version:
#include
struct Value;
using Array = std::list;
struct Value : Array {};
int main()
{
Value left;
Value right;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97121
--- Comment #2 from Jonathan Wakely ---
Fixed on trunk by r11-5866
c++: Fix defaulted <=> fallback to < and == [PR96299]
I thought I had implemented P1186R3, but apparently I didn't read it
closely
enough to understand the point of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97216
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97121
Jonathan Wakely changed:
What|Removed |Added
CC||GCCBugzilla at DRHouck dot me
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97216
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> It is ill-formed, because operator<=> can't return bool.
And that's because <=> has to say if one operand is greater, equal, or less
than the other. A bool c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99086
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97121
Jonathan Wakely changed:
What|Removed |Added
CC||crillion at tiscali dot it
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92416
Jonathan Wakely changed:
What|Removed |Added
Keywords|ice-on-invalid-code |FIXME
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100060
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99846
--- Comment #9 from Jonathan Wakely ---
This still means that comparisons on Value objects use the comparison operators
from the Variant base, and those comparisons depend on the alternative types in
the variant. One of those is list, and compari
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99846
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402
Jonathan Wakely changed:
What|Removed |Added
Summary|[10/11 Regression] |[10 Regression] std::copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070
--- Comment #1 from Jonathan Wakely ---
We want to do the same thing in insert and assign too. And in std::deque.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070
--- Comment #2 from Jonathan Wakely ---
This is a partial solution:
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -654,6 +654,19 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
const allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070
--- Comment #3 from Jonathan Wakely ---
So I think there is a *lot* work needed throughout the library to solve the
general problem that the existing container code uses C++17 iterator categories
and C++17 std::algos (not ranges::algos).
We mig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99402
--- Comment #12 from Jonathan Wakely ---
François fixed it. I just pasted the info here that didn't get automatically
added by the commit hooks, for some reason.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99081
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-04-14
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82283
--- Comment #11 from Jonathan Wakely ---
(In reply to Robert Dumitru from comment #10)
> I think https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99081 is also relating
> to this.
A similar issue, but I think the code for parsing these initializes i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070
--- Comment #4 from Jonathan Wakely ---
Barry suggested out-of-band that we could change std::__iterator_category to
determine the result based on the C++20 iterator concepts. That looks
promising.
std::distance dispatches on the result of std:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070
--- Comment #5 from Jonathan Wakely ---
If there is code that cares, we could always add std::__cpp17_iterator_category
for the cases where we really care about the traditional category (or where
we're forwarding the result of *i to user code wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070
--- Comment #6 from Jonathan Wakely ---
I'm not sure we should make std::__iterator_category just return
std::__detail::__iter_concept, because that has a fallback of
random_access_iterator_tag and I keep forgetting why that is. And I don't thin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070
--- Comment #7 from Jonathan Wakely ---
Note to self/Patrick:
Measure whether it helps to specialize transform_view's iterator so that when
_Base_iter is __normal_iterator we unwrap it and store a raw pointer.
Also, I suspect the indirections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91179
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88566
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657
--- Comment #4 from Jonathan Wakely ---
For completeness, here's a testcase which fails on sparc64-unknown-linux-gnu
when compiled using gcc -m32 eh.C -lsupc++
#include
int main()
{
std::make_exception_ptr(1);
}
/usr/bin/ld:
/home/jwakely/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657
Jonathan Wakely changed:
What|Removed |Added
Summary|[9/10/11 Regression]|[9/10 Regression]
|l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100117
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100128
--- Comment #1 from Jonathan Wakely ---
(In reply to Travis Downs from comment #0)
> Evidently, the behavior and definitions exposed by these headers should not
> depend on the order of include. I suspect there are other cases besides the
> __NO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100128
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> Glibc should probably act as though __NO_CTYPE is implicitly defined by
> __cplusplus, so that the effect is independent of the order of includes.
Or it sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #19 from Jonathan Wakely ---
Why is that needed? It says the location is something like:
In member function ‘info& info::operator=(const info&)’,
or:
In copy constructor ‘info::info(const info&)’,
If that isn't explicitly defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100133
Jonathan Wakely changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #4 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100140
--- Comment #2 from Jonathan Wakely ---
(In reply to Jignesh from comment #0)
> I am reproducing the comment posted there which gives entire details
> required for bug tracking and resolving. Unfortunately, no developers are
> responding to my m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99058
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98319
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99077
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100140
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97570
--- Comment #7 from Jonathan Wakely ---
Fixed for 8.5, 9.4 and 10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91057
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100140
Jonathan Wakely changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100147
--- Comment #1 from Jonathan Wakely ---
It's obviously safe for self-assignment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77711
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53281
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|NEW
Target Milestone|11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98985
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100146
--- Comment #3 from Jonathan Wakely ---
No, because std::from_chars still depends on uselocale, and needs to allocate
memory (which can fail, yielding an error code that isn't permitted by the
standard).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98725
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98731
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|redi at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60921
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93151
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80676
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93456
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|redi at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70692
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|redi at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93770
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|redi at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97570
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87308
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94749
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71367
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68792
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|redi at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|redi at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91371
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81380
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57272
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88125
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|redi at gcc dot
201 - 300 of 7031 matches
Mail list logo
