https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119953
--- Comment #7 from Jonathan Wakely ---
bad: r15-2208-gd1b25543f93c26
good: r15-2170-g7db47f7b915c5f
still running ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119953
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-06-04
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120529
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-06-04
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120548
--- Comment #3 from Jonathan Wakely ---
So the fix needs to also check for a leading ' ' as the sign character:
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -2398,9 +2398,16 @@ namespace __format
const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120548
--- Comment #2 from Jonathan Wakely ---
It's also wrong for:
format(std::locale("en_GB.UTF-8"), "{:+L}", 123.45) == "+,123.45"
format(std::locale("en_GB.UTF-8"), "{: L}", 123.45) == " ,123.45"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120548
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=120548
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 104928, which changed state.
Bug 104928 Summary: std::counting_semaphore on Linux can sleep forever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120527
--- Comment #7 from Jonathan Wakely ---
Maybe we should default to the portable fallback but allow users (or packagers
like macports) to select the faster impl at configure time if compat isn't
needed.
I'll have a quick look at what would be n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119953
--- Comment #2 from Jonathan Wakely ---
Apparently nobody is testing this target often enough to catch regressions :-(
I was able to build for msp430 before GCC 15, so I'll bisect to find when it
broke.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120527
--- Comment #4 from Jonathan Wakely ---
Also the fact that libc++ is using those APIs probably means they can't be
removed now.
Does the same version of libstdc++.dylib need to work for both cases?
There's already a generic implementation in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120527
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> Darwin provides __ulock_wait and __ulock_wake which should be sufficient to
> implement the internals needed for efficient std::atomic::wait and
> std::atom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120527
--- Comment #1 from Jonathan Wakely ---
And as noted at https://shift.click/blog/futex-like-apis/ ...
OpenBSD has a futex syscall so might be able to reuse the linux code:
https://man.openbsd.org/futex
FreeBSD has _umtx_op with similar functio
++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: iains at gcc dot gnu.org
Target Milestone: ---
Target: *-*-darwin*
Darwin provides __ulock_wait and __ulock_wake which should be sufficient to
implement the internals needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120514
--- Comment #6 from Jonathan Wakely ---
That would make sense, you were using something like:
$prefix/lib/gcc/x86_64-pc-linux-gnu/16.0.0/include-fixed/pthread.h
from an older build of GCC trunk, which was installed in Fedora 41 and so used
the o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120514
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #15 from Jonathan Wakely ---
Thanks for the fixes, uses the new built-ins since
r16-1077-gb32bf304793047
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119089
Jonathan Wakely changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120514
--- Comment #3 from Jonathan Wakely ---
This is just Bug 119089 again, which is not a gcc bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
--- Comment #18 from Jonathan W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120512
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #12 from Jonathan Wakely ---
These were working before, but fail after r16-1054
static_assert( __is_destructible(int&) );
static_assert( __is_destructible(int&&) );
static_assert( __is_destructible(int(&)[1]) );
static_assert( __is_
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
Given this code to be compiled with -std=c++20:
struct A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #8 from Jonathan Wakely ---
And for this type but I haven't figured out why:
#include
static_assert( __is_destructible(std::error_category) );
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #7 from Jonathan Wakely ---
The new built-in seems wrong for function types:
static_assert( not __is_destructible(int()) );
static_assert( not __is_nothrow_destructible(int()) );
static_assert( not __is_trivially_destructible(int())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120481
--- Comment #6 from Jonathan Wakely ---
Ah yes, I thought hh_mm_ss handled times >24h differently, but I misremembered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120481
--- Comment #4 from Jonathan Wakely ---
"However, if a flag refers to a “time of day” (e.g., %H, %I, %p, etc.), then a
specialization of duration is interpreted as the time of day elapsed since
midnight."
I think it's fine for the output to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120504
--- Comment #6 from Jonathan Wakely ---
They often are, because users like to set them to mean "this is a blocker for
my work" and that has no bearing on how important it is for GCC. Only Priority
really matters for GCC, because that's documente
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120504
--- Comment #4 from Jonathan Wakely ---
I assume it's the type_build_dtor_call call that causes the problem, and
probably removing lines 238-245 in semantics.cc would fix it.
But Jason might know how to preserve the new check without the unwan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120504
--- Comment #3 from Jonathan Wakely ---
Importance isn't actually a field, it's the combination of Priority and
Severity. And severity is pretty much ignored, and priority is set according to
clear rules, so I see no harm in assuming that the RM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
--- Comment #6 from Jonathan Wakely ---
This regressed the following testcase:
struct X;
template
struct default_delete
{
void operator()(T*) { static_assert(sizeof(T), "type is not incomplete"); }
};
template>
struct unique_ptr
{
~unique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400
--- Comment #18 from Jonathan Wakely ---
for ac_prog in gm4 gnum4 m4
do
# Extract the first word of "$ac_prog", so it can be a program name with
args.
set dummy $ac_prog; ac_word=$2
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #11)
> So you can't use designated initializers with that type in C++.
This is true for *most* POSIX structs, because POSIX does not guarantee the
order of membe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498
--- Comment #11 from Jonathan Wakely ---
.sa_handler is not a real member of the struct, it's a macro referring to a
nested member.
So you can't use designated initializers with that type in C++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498
--- Comment #8 from Jonathan Wakely ---
And "expected primary-expression before '.' token" because that syntax for
initializing a member of a subobject isn't valid at all in C++.
So you're not initializing 'sa.u' and that's why you get an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498
--- Comment #9 from Jonathan Wakely ---
The correct way to do it is to provide an initializer for sa.u, and that
initializer can initialize .sa_handler i.e.
struct sa sa = {.sa_flags = 0, .u = {.sa_handler = 0} };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498
--- Comment #7 from Jonathan Wakely ---
What isn't helpful about them? It tells you exactly what is wrong with the
code:
"either all initializer clauses should be designated or none of them should be"
GCC didn't decide this is an error, the C+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
--- Comment #17 from Jonathan Wakely ---
Using _S_do_try_acquire as the predicate for __atomic_wait_address is wrong,
because it can fail for two reasons: __old == 0, meaning we can't acquire the
semaphore and need to do an atomic wait, or becau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
Jonathan Wakely changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
--- Comment #16 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 104928, which changed state.
Bug 104928 Summary: std::counting_semaphore on Linux can sleep forever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 104928, which changed state.
Bug 104928 Summary: std::counting_semaphore on Linux can sleep forever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115955
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> Yes, this is a known limitation that will get fixed with the planned
> refactoring of atomic::wait.
The function that maps an address to a mutex has been mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 118395, which changed state.
Bug 118395 Summary: Constructor of std::barrier is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118395
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974
Jonathan Wakely changed:
What|Removed |Added
Summary|std::barrier accepts|[DR 3898] std::barrier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 118494, which changed state.
Bug 118494 Summary: std::counting_semaphore should work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118494
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98749
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118494
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118395
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Jonathan Wakely changed:
What|Removed |Added
Summary|[12/13/14/15/16 Regression] |[12/13/14/15 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 110854, which changed state.
Bug 110854 Summary: constructor of std::counting_semaphore is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110854
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110854
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
--- Comment #15 from Jonathan Wakely ---
I suppose another way to resolve this would be to just mark that function
[[__gnu__::__always_inline__]].
That would require no config changes at all, we could do it unconditionally.
Or we could do:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107527
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108859
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2023-02-20 00:00:00 |2025-5-29
--- Comment #1 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|12.5|16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120458
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120467
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-05-29
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104454
--- Comment #6 from Jonathan Wakely ---
See also https://lists.gnu.org/archive/html/bug-make/2025-05/msg2.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120465
--- Comment #3 from Jonathan Wakely ---
(In reply to Eligor Kadaf from comment #0)
> However, it seems that in libstdc++ implementation of std::flat_map it's
> value_type is std::tuple.
No, the predicate is just called on the elements of a zip_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120465
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104454
--- Comment #5 from Jonathan Wakely ---
I did try this:
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -164,6 +164,21 @@ fs::canonical(const path& p, error_code& ec)
path result;
#ifdef _GLIBCXX_FILESYSTEM_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104454
--- Comment #4 from Jonathan Wakely ---
Actually that's wrong because path("foo/bar/..").lexically_normal() is just
"foo" which ignores whether foo/bar is a symlink to somewhere else.
I think the right fix is to just not define _GLIBCXX_USE_REA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104454
--- Comment #3 from Jonathan Wakely ---
This fixes the FAIL for 27_io/filesystem/operations/weakly_canonical.cc
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -162,7 +162,7 @@ fs::path
fs::canonical(const path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104454
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120460
--- Comment #3 from Jonathan Wakely ---
i.e. maybe this warning should ignore whether it's in a system header or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120460
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2025-05-28
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120432
--- Comment #6 from Jonathan Wakely ---
Please don't waste time on the volatile question. What does it mean to lookup a
volatile value that could change at any moment? What is the library even
supposed to do with a volatile int& there, read it a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120458
--- Comment #1 from Jonathan Wakely ---
Clang compiles this, and I think MSVC does, but EDG doesn't (but EDG also
doesn't accept that identifier for a variable name, at least with the default
options).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2022-11-10 00:00:00 |2025-5-28
--- Comment #3 from Jonatha
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 103524
Target Milestone: ---
I think this should be valid in C++20:
export module 汉字;
$ g++ -std=c++20 c.cc -fmodules
./c.cc:1:8: fatal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
--- Comment #14 from Jonathan Wakely ---
Created attachment 61536
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61536&action=edit
Add abi tag to system_clock::to_time_t
Here's a new patch, which includes a test to verify that the abi_tag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
--- Comment #12 from Jonathan Wakely ---
Also, I don't think we need the abi tag from from_time_t, because the mangled
name of that function already depends on the type of time_t. The problem with
to_time_t is that the mangled name does not depen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400
--- Comment #11 from Jonathan Wakely ---
(In reply to Francois-Xavier Coudert from comment #10)
> I'd rather have a script like libgfortran/regenerate.sh, that calls m4 and
> updates the tree. Then maintainers know that, if they changed any m4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120428
--- Comment #15 from Jonathan Wakely ---
(In reply to Hongtao Liu from comment #13)
> The inner loop is not completely unrolled since std::copy is lowered to
> __builtin_memmove instead of __builtin_memcpy
std::copy allows the end of the output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400
--- Comment #5 from Jonathan Wakely ---
Aside: FX, please use --author when committing somebody else's patch, so that
the Author: field in git and the generated ChangeLog are correct.
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 106749
Target Milestone: ---
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2655r3.html
I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120367
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
--- Comment #11 from Jonathan Wakely ---
My first thought was that -D_TIME_BITS=64 requires _FILE_OFFSET_BITS=64 to be
set too, but glibc will give an #error if it's not set. So libstdc++ does not
need to worry about users incorrectly using -D_TI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120428
--- Comment #8 from Jonathan Wakely ---
(In reply to Shawn Xu from comment #0)
> On x86-64 with avx512, PR115444 caused the following code to vectorize
> sub-optimally:
What made you blame PR115444 for this? Did you actually bisect it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100586
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120428
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #6)
> The regression was caused by
> r15-3078-g6ea25c041964bf63014fcf7bb68fb1f5a0a4e123
I bisected to this commit using the code in comment 2. It looks like the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120428
Jonathan Wakely changed:
What|Removed |Added
Component|libstdc++ |tree-optimization
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120428
--- Comment #7 from Jonathan Wakely ---
This was backported as r14-10608-g27dc1533b6dfc4 and r13-8987-gaea374238cec1a
and r12-10682-gb4bc34db3f2948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120428
Jonathan Wakely changed:
What|Removed |Added
Known to fail||14.3.0, 15.1.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120428
--- Comment #4 from Jonathan Wakely ---
The library code should be exactly equivalent, except for being slightly
simpler (one level of function call has been inlined into its caller now) and
doing:
ptr += n;
return ptr;
instead of:
retu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111250
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
|--- |12.5
Known to fail||15.1.0, 7.5.0
Priority|P3 |P4
Severity|normal |minor
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Summary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
--- Comment #8 from Jonathan Wakely ---
(In reply to Richard Biener from comment #2)
> clang 19 says
>
> > clang-19 t.C -S -std=c++20
> t.C:4:11: error: no viable overloaded '-='
> 4 | __tmp -= __n
> | ~ ^ ~~~
> t.C:4:17:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120325
--- Comment #3 from Jonathan Wakely ---
I've added a note about this to
https://gcc.gnu.org/gcc-15/porting_to.html#cxx20-iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119427
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|14.4|15.2
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
--- Comment #14 from Jonathan Wakely ---
I've added a note to the bottom of
https://gcc.gnu.org/gcc-14/porting_to.html#cxx20-iterators which links to
https://gcc.gnu.org/gcc-15/porting_to.html#cxx20-iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
--- Comment #10 from Jonathan Wakely ---
There's a one-line fix:
[[nodiscard]] constexpr friend difference_type operator-(const
TransformIterator& x, const TransformIterator& y)
+ requires std::sized_sentinel_for
{
return x.it - y.it;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
--- Comment #12 from Jonathan Wakely ---
Upstream already replaced their transform view with std::views::transform so
probably aren't going to be interested in the patch:
https://github.com/openMSX/openMSX/commit/e4aa15cbfdfb3e1b94ae7e787f2be0f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
Jonathan Wakely changed:
What|Removed |Added
Known to fail|14.3.0, 15.1.1 |
--- Comment #9 from Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407
--- Comment #4 from Jonathan Wakely ---
(In reply to Daniel Starke from comment #0)
> Compiling the following C++ code for mingw-w64 using `-O2 -s -static`
> creates a 896 KiB executable instead of 119 KiB since git commit
> releases/gcc-12.2.0-
1 - 100 of 7710 matches
Mail list logo
