From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14147 invoked by alias); 4 Sep 2014 17:18:14 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 14134 invoked by uid 89); 4 Sep 2014 17:18:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f170.google.com Received: from mail-vc0-f170.google.com (HELO mail-vc0-f170.google.com) (209.85.220.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 04 Sep 2014 17:18:09 +0000 Received: by mail-vc0-f170.google.com with SMTP id la4so11144086vcb.29 for ; Thu, 04 Sep 2014 10:18:07 -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:date :message-id:subject:from:to:cc:content-type; bh=lo/bpP3HfKNHjr6TRqlGTZ4qn/RgqkPZm6wUCDdjYVU=; b=ciitRSBQDehBzWUfC1I+084542BjITLhCKKXzj3Xt8cVvsW0JO9mEK29PO3MrLaoBK jYmEKPGNaXQGnZSBNMEOvIfusPa2KOjdd95ikmYld2qNufrGSj2Lz+qjp6zuwkM+FpDi EekbPjoJATETuSxyN3U3cDZRYI4gGL6W60tevwubmuizu4peaMmZgq/3vFVi9KXkcY8x 6i7Tv56lQWQWH4A3DrunJmFzkk3sbKk6FsUV71ldeinP1SR6QipFE3QXFHr9j6Two4ZW gbiuyBFDWn4nvQc8VTcMkgdSknatQlCH5VZNXSm2wmTayKWgL6hkeEdiDm3PJ40VsOkD XYdg== X-Gm-Message-State: ALoCoQnB12++mlDRLTbRTGoHDg6ajQTTA19MgqgRtzKwrhEueSIJu2lK6wHrflmixlrjegnNOamT MIME-Version: 1.0 X-Received: by 10.220.80.207 with SMTP id u15mr2948189vck.72.1409851087157; Thu, 04 Sep 2014 10:18:07 -0700 (PDT) Received: by 10.52.94.37 with HTTP; Thu, 4 Sep 2014 10:18:06 -0700 (PDT) In-Reply-To: <5408988E.2060301@redhat.com> References: <5408988E.2060301@redhat.com> Date: Thu, 04 Sep 2014 17:18:00 -0000 Message-ID: Subject: Re: is portable aliasing possible in C++? From: Andy Webber To: Andrew Haley Cc: gcc-help@gcc.gnu.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2014-09/txt/msg00032.txt.bz2 On 9/4/14, Andrew Haley wrote: > On 09/04/2014 05:11 PM, Andy Webber wrote: >> Our goal is to avoid bugs caused by strict aliasing in our networking >> libraries. My question is how to guarantee that we're not violating >> the aliasing rules while also getting the most optimization. I've >> read through a ton of information about this online and in some gcc >> discussions, but I don't see a consensus. >> >> Memcpy always works, but is dependent on optimization to avoid copies. >> The union of values is guaranteed to work by C++11, but may involve >> copies. > > Is this a real worry? IME it makes copies when it needs to. > >> Each test works when built with -O3 on gcc-4.8.3, but I would like to >> standardize across compilers and versions. The optimization >> information generated by -fdump-tree-all is interesting here as it >> shows slightly different optimization for each case though >> reinterpret_cast and placement new generate identical code in the end. > > The "union trick" has always worked with GCC, and is now hallowed by > the standard. It's also easy to understand. It generates code as > efficient as all the other ways of doing it, AFAIAA. It's what we > have always recommended. > > Your test is nice. I suppose we could argue that this is a missed > optimization: > > union_copy(): > movl $2, %eax > cmpw $2, %ax > jne .L13 > > I don't know why we only generate code for one of the tests. > > Andrew. > > Thanks for responding. I appreciate any clarity that the gcc devs and standards experts can give here. I'm especially interested in the validity of the placement new approach. Your recommendation of going through unions causes some difficulty for us in terms of type abstraction. Specifically, receiving network bytes directly into a union with all possible message types present in the union is somewhat less flexible than determining the correct message type and doing a placement new to create essentially a memory overlay. Is placement new a suitable substitute for __may_alias__ in this specific example? Andy