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=108846
--- Comment #26 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:8ec265c1464dec74f98e6914cd164af5090a39ff
commit r12-10250-g8ec265c1464dec74f98e6914cd164af5090a39ff
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #25 from Jonathan Wakely ---
... and non-empty types, I'm just saying that's the obvious case that proves
it's possible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #24 from Jonathan Wakely ---
(In reply to Arthur O'Dwyer from comment #23)
> - There may be padding in the middle of an object, and I'm not confident
> that the Standard actually forbids it from being used. Of course your
> approach
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #23 from Arthur O'Dwyer ---
(In reply to Jonathan Wakely from comment #22)
>
> Richi suggested that we could avoid these runtime branches (which hurt
> optimization, see PR 109445) if we knew how many bytes of tail padding there
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #22 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #16)
> const ptrdiff_t _Num = __last - __first;
> - if (_Num)
> + if (__builtin_expect(_Num > 1, true))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #21 from Jonathan Wakely ---
Indeed it should.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #20 from Giuseppe D'Angelo ---
Thanks for the patch!
Should ranges_algobase.h also be similarly changed? There's a memmove in its
copy/move code as well:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #19 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:822a11a1e642e0abe92a996e7033a5066905a447
commit r13-6372-g822a11a1e642e0abe92a996e7033a5066905a447
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #18 from Jonathan Wakely ---
Created attachment 54537
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54537=edit
libstdc++: Do not use memmove for 1-element ranges [PR108846]
This is a more complete patch that passes Arthur's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
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=108846
--- Comment #17 from Jonathan Wakely ---
We need to change the arguments too, as that specialization takes a const _Tp*
as the input range.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #16 from Jonathan Wakely ---
Ah gotcha.
So then something like this (untested):
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -422,16 +422,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #15 from Giuseppe D'Angelo ---
That's not what I meant; a type can be trivial(ly copyable) and move-only.
Here's a modification of Arthur's example:
// move-only
struct B {
B(int i, short j) : i(i), j(j) {}
B(B &&) =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #14 from Jonathan Wakely ---
s/move an lvalue or rvalue/assign from an lvalue or rvalue/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #13 from Jonathan Wakely ---
That specialization is only used for trivial types, so moving is equivalent to
copying (otherwise we couldn't use memmove anyway). So it doesn't make any
difference whether you move an lvalue or rvalue,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #12 from Giuseppe D'Angelo ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Giuseppe D'Angelo from comment #5)
> > https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #11 from Arthur O'Dwyer ---
(In reply to Jonathan Wakely from comment #10)
> std::move(x,y,z) and std::copy(z,y,z) use the same underlying
> implementation, so it does have the same issue, but will be fixed by the
> same change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #10 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #7)
> I suspect std::move has the same issue too. The ability to use memmove with
> trivial copyable subobjects ...
std::move(x,y,z) and std::copy(z,y,z) use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #9 from Jonathan Wakely ---
(In reply to Giuseppe D'Angelo from comment #5)
> https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/
> stl_algobase.h#L417-L437
>
> Is the extent of the fix just to add another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #7 from Andrew Pinski ---
I suspect std::move has the same issue too. The ability to use memmove with
trivial copyable subobjects ...
22 matches
Mail list logo
