From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25812 invoked by alias); 28 Sep 2016 11:14:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 25795 invoked by uid 89); 28 Sep 2016 11:14:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=unions, transfer X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-wm0-f43.google.com Received: from mail-wm0-f43.google.com (HELO mail-wm0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Sep 2016 11:14:15 +0000 Received: by mail-wm0-f43.google.com with SMTP id b130so65388082wmc.0; Wed, 28 Sep 2016 04:14:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yk/+a8yjR3XSeqnKwLSJ7mlaaRToh8aPIcedHeWWHrg=; b=bY6gy2bYdo/6bSkzIikBDHLNVhZRrr/GuXs8keQawf2N2pi2jJWxqJhfQZj5TH2MOm MVAMpFkzVQfcOB3/A7kcxBmgsespi41ICBBr44wDBvkwCfTPl9ufUbmlZmgIrH3NBiJ9 lCYDRLT1eB7Yb2ACh3wBsQx1PH/mie37aA1tCRBMDzpN77bfBIHPjPwb/Z9hAOh22I4f A4SYyn+gYY8ORP+60XYkloT8ENBbp9q0533puhVgmmtOIBTt3haurtCiwxKdXyE5pL6u cIyhuY866yWzIwzzyZV9rkiVe6ICfFEDy1L+SHp84vLRaRhIlcuQi2BsjycM//Ue6DZT 7Ijg== X-Gm-Message-State: AA6/9RlRYXgajbjdm5qTs3aRspKk+97wpzOII36lxyTNohGVD6gP/tGZjrINZRCfGrQ0ey9BCk/zmmgPE6oMXg== X-Received: by 10.28.73.138 with SMTP id w132mr7370452wma.92.1475061253737; Wed, 28 Sep 2016 04:14:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.155.210 with HTTP; Wed, 28 Sep 2016 04:14:06 -0700 (PDT) In-Reply-To: <20160928105732.GA7817@redhat.com> References: <20160928105732.GA7817@redhat.com> From: Richard Biener Date: Wed, 28 Sep 2016 11:17:00 -0000 Message-ID: Subject: Re: [PATCH] libstdc++/77686 use may_alias for std::function storage To: Jonathan Wakely Cc: "libstdc++" , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg02111.txt.bz2 On Wed, Sep 28, 2016 at 12:57 PM, Jonathan Wakely wrote: > std::function::swap does swap(_M_functor, x._M_functor) which > exchanges the underlying bytes of the two _Any_data PODs using that > type's implicit assignment operator. However, unlike using placement > new to construct an object in the storage, simply memcpying the bytes > doesn't change the effective type of the storage, so alias analysis > decides it can't point to whatever we've tried to store in there. To clarify -- the implicit assingment operator for PODs (including unions) simply expands to an aggregate assignment which is subject to TBAA rules and thus in this case instantiates an effective type of _Any_data. Using memcpy would have worked as memcpy _does_ transfer the effective type of the storage. It wasn't points-to deciding things here but TBAA given automatic storage X with effective type T read via an lvalue of type _Any_data. > This attribute tells the middle-end to assume anything those bytes > could contain any type of object, which is exactly what we want. It tells the middle-end that accessing storage via a _pointer_ to such marked type may access storage with a dynamic type that is not compatible with the type. Details ;) Btw, I think the patch is correct. Richard. > PR libstdc++/77686 > * include/std/functional (_Any_data): Add may_alias attribute. > > Tested powerpc64le-linux, committing to trunk and gcc-6-branch. > > std::any doesn't have the same problem, because I defined an _Op_xfer > operation that uses placement new to copy the object into the > destination, so the dynamic type is changed correctly. I haven't > checked whether optional and variant might have similar problems in > any implicit copy/move operations working on POD storage. > >