[llvm] r215478 - APInt: Make self-move-assignment a no-op to fix stage3 clang-cl

[Reid Kleckner]

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.


On Thu, Aug 14, 2014 at 6:09 PM, David Blaikie <dblaikie at gmail.com> wrote:

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