https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114388
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> In C++98 the const B& is an lvalue, and in C++11 the B&& is an xvalue which
> is a glvalue. Either way, it's correct to treat it as a glvalue of
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114393
--- Comment #1 from Jonathan Wakely ---
Created attachment 57736
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57736=edit
Gzipped preprocessed source
Bisecting ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114388
--- Comment #5 from Jonathan Wakely ---
Prior to DR 616 the expression (true ? WrapB().b : WrapD().d) was a prvalue of
type B, created by copying the B (or slicing the D when the condition is
false). As an rvalue, it wasn't evaluated. That's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114388
--- Comment #4 from Jonathan Wakely ---
This changed with r9-595-g955da5e5443724:
CWG 616, 1213 - value category of subobject references.
* tree.c (lvalue_kind): A reference to a subobject of a prvalue is
an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114384
--- Comment #4 from Jonathan Wakely ---
Libstdc++ uses the same effective-target keywords, but uses its own variables
to override the defaults:
# Allow v3_std_list to be set in configuration files, e.g., ~/.dejagnurc
if ![info exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114384
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Andrew Pinski from comment #0)
> > and even how to describe the above
> > would be very useful. Do we need 3 testcases, one for pre C++11, one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114384
--- Comment #2 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #0)
> While trying to understand how to use `{ target c++20 }` option to dg-do I
> noticed it is not documented in the internals manual (sourcebuild.texi)
> while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114368
--- Comment #1 from Jonathan Wakely ---
I don't see this on aarch64-unknown-linux-gnu or x86_64-pc-linux-gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114379
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-03-18
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|13.3|12.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72
--- Comment #5 from Jonathan Wakely ---
Fixed for 13.3 and 12.4 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112473
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114147
Jonathan Wakely changed:
What|Removed |Added
Summary|[11/12 Regression] tuple|[11 Regression] tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107376
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|13.0|12.4
--- Comment #5 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112089
--- Comment #6 from Jonathan Wakely ---
Backported for 13.3 and 12.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
--- Comment #19 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #17)
> Fixed for 13.3 and 14.1 so far ...
and 12.4 now too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #27 from Jonathan Wakely ---
Backported for 12.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86419
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|13.0|12.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109758
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|13.2|12.4
--- Comment #18 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110593
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|14.0|12.4
--- Comment #5 from Jonathan
|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
||rejects-valid
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113782
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
--- Comment #18 from Jonathan Wakely ---
(In reply to Kaz Kylheku from comment #15)
> In April 2020 I created a patch for the GNU C Preprocessor, with
> documentation, test cases and everything. I submitted it to the GCC Patches
> mailing list,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36587
--- Comment #17 from Jonathan Wakely ---
No, the nodiscard warnings must be silenced with a cast to void. They can't be
"stronger" than that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114367
--- Comment #3 from Jonathan Wakely ---
Yeah this needs to use construct_at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66034
--- Comment #2 from Jonathan Wakely ---
C++ coroutines are allocated on the heap though.
https://wg21.link/p0876 is more relevant here, but not approved yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114357
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
Jonathan Wakely changed:
What|Removed |Added
Known to work||12.1.0
Target Milestone|13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|12.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359
--- Comment #3 from Jonathan Wakely ---
This seems to fix it:
--- a/libstdc++-v3/include/bits/random.tcc
+++ b/libstdc++-v3/include/bits/random.tcc
@@ -1503,7 +1503,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// sqrt(pi / 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114359
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-03-16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114354
--- Comment #2 from Jonathan Wakely ---
Ah yes, thanks. It looks like I converted them to constraints for array support
with g:a2e0054e1d169984ec64d64145b71a88a9628537 but only for the pointer
conversions, I missed the delete expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114357
--- Comment #7 from Jonathan Wakely ---
Libstdc++ has to use some sneaky hacks to avoid destroying globals, we would
definitely use no_destroy if we had it.
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
We avoid repeating constructor constraints by deferring to the base class:
template
using
|1
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Last reconfirmed||2024-03-15
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 88322
Target Milestone: ---
The standard says:
template explicit shared_ptr(Y* p);
Constraints: When T is an array type, the expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100285
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114325
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114336
--- Comment #2 from Jonathan Wakely ---
I don't see how it can be critical, since it might just be 0 always, so it's
not a good idea to write code where that impl-defined value is critical.
For G++ the column number is the opening paren of
: documentation
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 88322
Target Milestone: ---
Similar to
https://gcc.gnu.org/onlinedocs/libstdc++/manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114325
--- Comment #2 from Jonathan Wakely ---
Indeed. Here's the fix:
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -4124,14 +4124,14 @@ namespace __format
__uval = make_unsigned_t<_Tp>(~__arg) +
for negative|gives incorrect results for
|numbers |negative numbers
Known to fail||14.0
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114316
--- Comment #1 from Jonathan Wakely ---
For a debug mode _Safe_iterator pair __valid_range uses this overload:
template
inline bool
__valid_range(const _Safe_iterator<_Iterator, _Sequence,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114316
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114311
--- Comment #3 from Jonathan Wakely ---
MSVC compiles it but Clang and EDG agree with GCC:
$ clang++ c.cc -std=c++2b
c.cc:12:22: error: non-type template argument is not a constant expression
return SymbolRefid_>{};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114309
--- Comment #10 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #6)
> Maybe it should have its own enable/disable and not tied to -Wattribute
> though.
Yes, -Wattributes is going to keep covering more and more different things
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114309
--- Comment #9 from Jonathan Wakely ---
(In reply to M Welinder from comment #0)
> The standard, quoted from
> https://en.cppreference.com/w/cpp/language/attributes/likely, clearly
> contemplates this case:
N.B. cppreference is not the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110565
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114298
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114279
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #15 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #14)
> Or maybe the testcase makes invalid assumptions and isn't really measuring
> what it thinks it's measuring?
e.g. maybe clock_getres says 100ns even though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #14 from Jonathan Wakely ---
Thanks!
So does that mean mingw-w64 fixed the issue by improving the resolution of
CLOCK_REALTIME?
In that case, this bug could be closed WORKSFORME.
Or maybe the testcase makes invalid assumptions and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307
--- Comment #9 from Jonathan Wakely ---
Ironically, writing a user-provided (and so non-trivial) copy constructor which
fixes up the self-referential pointer (or iterator, in your case) will restore
guaranteed elision, and that copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307
--- Comment #8 from Jonathan Wakely ---
I explained this in PR 109945 comment 25
There is no guaranteed copy elision for objects with a trivial copy constructor
and trivial (or deleted) destructor. The compiler is allowed to make temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> GetSystemTimePreciseAsFileTime gives UTC, so would need adjustment for leap
> seconds to turn it into a sys_time. That's doable though.
Doable, but it
at gcc dot gnu.org |redi at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2024-03-08
Status|UNCONFIRMED |ASSIGNED
--- Comment #2 from Jonathan Wakely ---
Fix:
--- a/libstdc++-v3/include/bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
--- Comment #6 from Jonathan Wakely ---
Actually the standard does support Howard's intended behaviour:
"If the parse fails to decode a valid date, is.setstate(ios_base::failbit) is
called and tp is not modified."
It says "date", not "time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> Is this still an issue in 2022?
>
> Using a mingw-w64 cross-compiler and running under Wine I get:
>
> CLOCK_REALTIME: 0,100
> CLOCK_MONOTONIC: 0,100
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #10 from Jonathan Wakely ---
GetSystemTimePreciseAsFileTime gives UTC, so would need adjustment for leap
seconds to turn it into a sys_time. That's doable though.
Alternatively, we could use it to implement a high performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110826
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-03-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114279
--- Comment #1 from Jonathan Wakely ---
It certainly does take leap seconds into account, as demonstrated by the output
example below the text you quoted, which is reproduced in the testsuite:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.3
--- Comment #7 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114260
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114103
--- Comment #17 from Jonathan Wakely ---
I think this should be fixed now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114265
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-03-07
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114260
Jonathan Wakely changed:
What|Removed |Added
CC||howard.hinnant at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244
--- Comment #5 from Jonathan Wakely ---
Yup, that's what I have in my local tree now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> Yup, the seconds part "00.002" is parsed using std::numpunct (in order to
Oops, std::num_get obviously.
> handle the locale's decimal point) and then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> and another duration_cast in chrono::from_stream for durations. That one
> could be used with either integral or floating-point reps.
Ah, but we're
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.
ent: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
We give surprising output for std::formatter>:
#include
#include
#include
using namespace std::chrono;
int main(){
auto sdays = std::chrono::sys_days(2024y/M
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
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This was changed by g:dfad48c6e89fcfed for PR 12875. This was also the subject
of PR 9423, but Benjamin argued there that opening the file counts as an I/O
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
>
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Last reconfirmed||2024-03-05
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.
|1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
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
201 - 300 of 22332 matches
Mail list logo
