https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
--- Comment #12 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:7ed561f63e7955df4d194669998176df5ef47803
commit r15-4475-g7ed561f63e7955df4d194669998176df5ef47803
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
--- Comment #11 from Jonathan Wakely ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665537.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
--- Comment #10 from Alfredo Correa ---
Wow, that was fast! Great! (I wasn't optimistic, to be honest.)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
--- Comment #9 from Jonathan Wakely ---
It will be fixed in the next few days anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
--- Comment #8 from Alfredo Correa ---
FWIIW, this is the origin of the problem,
https://gitlab.com/correaa/boost-multi#broadcast-infinite-views, implementing
an iterator type that supports stride == 0.
This doesn't form a proper random access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
Alfredo Correa changed:
What|Removed |Added
CC||alfredo.correa at gmail dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
--- Comment #6 from Jonathan Wakely ---
If the compile wants to vectorize the loop, knowing there are N iterations
helps. Using first != last as the condition isn't necessarily just a pointer
comparison for arbitrary random access iterators, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
--- Comment #5 from Arthur O'Dwyer ---
> Yes, so that std::copy_n benefits from the same memmove optimization as
> std::copy.
Right, I'm not objecting to the memmove optimization, just to the current
codebase's approach of "slightly pessimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> We could just use while (__first != __last) instead, but that would remove a
> very intentional "optimization" that's explicitly mentioned in a comment:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
--- Comment #3 from Jonathan Wakely ---
(In reply to Arthur O'Dwyer from comment #0)
> But if you compile with `-std=c++20 -ULESS`, you get more verbose codegen:
> first a call to `It::operator+(int)`, then a call to `It::operator-(It)`,
> and t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
--- Comment #2 from Jiang An ---
Oh, UB seems still introduced by [iterator.requirements.general]/12
(https://eel.is/c++draft/iterator.requirements.general#12).
> The result of the application of library functions to invalid ranges is
> undefin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #1 from Jian
14 matches
Mail list logo
