https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #29 from Marc Glisse ---
Note that __is_bitwise_relocatable is specialized to true for deque, so we are
not super consistent here ;-)
The original patch used is_trivially_move_constructible, IIRC I changed it to
is_trivial so the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #28 from Dan Stahlke ---
Thank you. That makes sense. I had asked about it here:
https://stackoverflow.com/questions/59690019 I was directed to this thread,
and linked back to the SO thread you provided.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #27 from Jonathan Wakely ---
> if constexpr (!is_trivial_v)
> if (is_default_constructible_v<_Tp> && (__OPTIMIZE__+0))
That would need to be 'if constexpr'
I'll stop now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #26 from Jonathan Wakely ---
Or maybe that should be:
template
struct __is_bitwise_relocatable
: is_trivially_copyable<_Tp> { };
...
if constexpr (!is_trivial_v)
if (is_default_constructible_v<_Tp>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #25 from Jonathan Wakely ---
I think that's the answer, yes (although I haven't refreshed my memory of the
issues completely). A call to memmove does not begin the lifetime of any
objects at the destination address.
For types that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #24 from Marc Glisse ---
Something like that, yes. Essentially, I used trivial because I was convinced
it was safe in that case, not because it looked like the perfect condition. If
someone can convincingly argue for a weaker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #23 from Arthur O'Dwyer ---
@Dan Stahlke: I believe
https://stackoverflow.com/questions/47464819/uninitialized-copy-memcpy-memmove-optimization
answers your question. Or, if it doesn't, then Marc or someone should consider
posting an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
Dan Stahlke changed:
What|Removed |Added
CC||dan at stahlke dot org
--- Comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #21 from Marc Glisse ---
Author: glisse
Date: Sat Apr 27 14:09:20 2019
New Revision: 270624
URL: https://gcc.gnu.org/viewcvs?rev=270624=gcc=rev
Log:
Use __restrict for __relocate_object_a
2019-04-27 Marc Glisse
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #20 from Marc Glisse ---
TODO: specify __restrict on the arguments of __relocate_object_a. Since one is
initialized and not the other, it should be safe to assume that they are
disjoint, and it helps optimize move+destroy, for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #19 from Arthur O'Dwyer ---
Awesome! Thank you! :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #18 from Marc Glisse ---
Author: glisse
Date: Tue Feb 5 09:33:36 2019
New Revision: 268532
URL: https://gcc.gnu.org/viewcvs?rev=268532=gcc=rev
Log:
Rename __is_trivially_relocatable to __is_bitwise_relocatable.
2019-02-05 Marc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #17 from Arthur O'Dwyer ---
(In reply to Marc Glisse from comment #16)
> (In reply to Arthur O'Dwyer from comment #15)
> > @Marc, it only now occurs to me that if libstdc++ uses
> > `__is_trivially_relocatable` as its userspace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #16 from Marc Glisse ---
(In reply to Arthur O'Dwyer from comment #15)
> @Marc, it only now occurs to me that if libstdc++ uses
> `__is_trivially_relocatable` as its userspace type-trait name, then GCC
> won't be able to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #15 from Arthur O'Dwyer ---
@Marc, it only now occurs to me that if libstdc++ uses
`__is_trivially_relocatable` as its userspace type-trait name, then GCC won't
be able to use `__is_trivially_relocatable(T)` as the name of its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #14 from Marc Glisse ---
(In reply to Arthur O'Dwyer from comment #13)
> Re https://gcc.gnu.org/viewcvs?rev=266386=gcc=rev — awesome, but
> I'm curious: Why `deque` before `vector`?
> I mean are you planning eventually to add the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #13 from Arthur O'Dwyer ---
Re https://gcc.gnu.org/viewcvs?rev=266386=gcc=rev — awesome, but I'm
curious: Why `deque` before `vector`?
I mean are you planning eventually to add the specializations of
`__is_trivially_relocatable` for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #12 from Marc Glisse ---
Author: glisse
Date: Thu Nov 22 18:10:05 2018
New Revision: 266386
URL: https://gcc.gnu.org/viewcvs?rev=266386=gcc=rev
Log:
Improve relocation
2018-11-22 Marc Glisse
PR libstdc++/87106
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #11 from Marc Glisse ---
(In reply to Arthur O'Dwyer from comment #10)
> Here's the commit where I trivially-relocatable-ized `std::deque`. 34 lines
> added, 18 more lines changed. There's some duplication, but it's not
> literally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #10 from Arthur O'Dwyer ---
> Still better than duplicating the whole class IMO.
The `optional` example in P1144R0 Appendix B looks scarier than I should have.
For one thing, I omitted all the boring user-facing API of `optional`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #9 from Marc Glisse ---
I was looking into using relocation in std::swap. For a type like deque (if we
ignore the swap overload), using memcpy is really worth it. For a more simple
type like int, using memcpy loses type information,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #8 from Marc Glisse ---
(In reply to Arthur O'Dwyer from comment #7)
> 2) the conditionally trivial stuff is not very convenient, it seems to
> involve a lot of code duplication. People regularly suggest attributes of the
> form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #7 from Arthur O'Dwyer ---
> std::string is not trivially relocatable in libstdc++
This is surprising news to me! Just goes to show that we would benefit from an
accurate detection mechanism and type trait. :)
> so I won't waste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #6 from Marc Glisse ---
Re-reading P1144R0 (those are not necessarily comments on the paper, just what
comes to mind for gcc):
1) yes, an automatic detection mechanism would be nice, and an attribute makes
sense.
2) the conditionally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #5 from Marc Glisse ---
(In reply to Arthur O'Dwyer from comment #4)
> Have you seen my libc++ patch on the same topic as yours?
>
> https://quuxplusone.github.io/blog/2018/07/18/announcing-trivially-
> relocatable/
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #3 from Marc Glisse ---
Author: glisse
Date: Thu Oct 25 13:03:13 2018
New Revision: 265485
URL: https://gcc.gnu.org/viewcvs?rev=265485=gcc=rev
Log:
Relocation (= move+destroy)
2018-10-25 Marc Glisse
PR libstdc++/87106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
Marc Glisse changed:
What|Removed |Added
Attachment #44638|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #1 from Marc Glisse ---
Created attachment 44638
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44638=edit
proof of concept patch (diff -w)
Trying to get an idea of how things could look like. I know
29 matches
Mail list logo
