<div dir="ltr">Any implicit move assignment operator is a no-op on self-move so long as all bases and members have no-op self-move assignments. The builtin types are trivially no-op on self-move, and MSVC's STL types all have no-op self-moves. So, if all of the user-defined move assignments are no-ops, then all implicit ones are no-ops.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 14, 2014 at 6:09 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Do they generate ones that no-op on self-move? Or did they fix their<br>
stable_sort (& other algorithms) so as not to rely on self-move?<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Aug 14, 2014 at 5:58 PM, David Majnemer<br>
<<a href="mailto:david.majnemer@gmail.com">david.majnemer@gmail.com</a>> wrote:<br>
> On Thu, Aug 14, 2014 at 3:27 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, Aug 14, 2014 at 2:42 PM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
>> > On Tue, Aug 12, 2014 at 3:29 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Tue, Aug 12, 2014 at 3:01 PM, Reid Kleckner <<a href="mailto:reid@kleckner.net">reid@kleckner.net</a>><br>
>> >> wrote:<br>
>> >> > Author: rnk<br>
>> >> > Date: Tue Aug 12 17:01:39 2014<br>
>> >> > New Revision: 215478<br>
>> >> ><br>
>> >> > URL: <a href="http://llvm.org/viewvc/llvm-project?rev=215478&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=215478&view=rev</a><br>
>> >> > Log:<br>
>> >> > APInt: Make self-move-assignment a no-op to fix stage3 clang-cl<br>
>> >> ><br>
>> >> > It's not clear what the semantics of a self-move should be.  The<br>
>> >> > consensus appears to be that a self-move should leave the object in a<br>
>> >> > moved-from state, which is what our existing move assignment operator<br>
>> >> > does.<br>
>> >> ><br>
>> >> > However, the MSVC 2013 STL will perform self-moves in some cases.  In<br>
>> >> > particular, when doing a std::stable_sort of an already sorted APSInt<br>
>> >> > vector of an appropriate size, one of the merge steps will self-move<br>
>> >> > half of the elements.<br>
>> >> ><br>
>> >> > We don't notice this when building with MSVC, because MSVC will not<br>
>> >> > synthesize the move assignment operator for APSInt.  Presumably<br>
>> >><br>
>> >> I'm assuming you're going to look into this a bit further, though?<br>
>> >> (other than just 'presumably') both to understand when/how long we<br>
>> >> need this workaround in place, and whether we need to do anything to<br>
>> >> Clang for MSVC compatibility here?<br>
>> ><br>
>> ><br>
>> > David Majnemer says that VS 2013 can't generate implicit move<br>
>> > assignments at<br>
>> > all, so I just gave up too early and rationalized it.<br>
>><br>
>> Oh, right, yes.<br>
>><br>
>> ><br>
>> >><br>
>> >> > MSVC<br>
>> >> > does this because APInt, the base class, has user-declared special<br>
>> >> > members that implicitly delete move special members.  Instead, MSVC<br>
>> >> > selects the copy-assign operator, which defends against<br>
>> >> > self-assignment.<br>
>> >> > Clang, on the other hand, selects the move-assign operator, and we<br>
>> >> > get<br>
>> >> > garbage APInts.<br>
>> >><br>
>> >> I'm curious how Clang synthesizes a move assignment operator if the<br>
>> >> base class's move assignment is implicitly deleted. Any idea what's<br>
>> >> going on there?<br>
>> ><br>
>> ><br>
>> > The base class (APInt) has a user-defined move assignment, which is the<br>
>> > one<br>
>> > that I'm modifying here. We reach it in Clang through an implicit APSInt<br>
>> > move assignment, but MSVC doesn't generate that and doesn't reach it.<br>
>><br>
>> Yep, that all makes sense.<br>
>><br>
>> Reckon we need to disable generation of implicit move members in MSVC<br>
>> compatibility mode?<br>
><br>
><br>
> Both the November 2013 CTP and VS "14" generate move members; personally, I<br>
> think our behavior here is fine.<br>
><br>
>><br>
>> _______________________________________________<br>
>> llvm-commits mailing list<br>
>> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
><br>
><br>
</div></div></blockquote></div><br></div>