From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80665 invoked by alias); 6 Apr 2017 15:05:45 -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 80034 invoked by uid 89); 6 Apr 2017 15:05:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1130 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Apr 2017 15:05:44 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2F8ADC05491E; Thu, 6 Apr 2017 15:05:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2F8ADC05491E Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2F8ADC05491E Received: from tucnak.zalov.cz (ovpn-116-72.ams2.redhat.com [10.36.116.72]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C37839D4A2; Thu, 6 Apr 2017 15:05:43 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v36F5eqn029454; Thu, 6 Apr 2017 17:05:41 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v36F5cE1029453; Thu, 6 Apr 2017 17:05:38 +0200 Date: Thu, 06 Apr 2017 15:05:00 -0000 From: Jakub Jelinek To: Florian Weimer Cc: Jonathan Wakely , Richard Biener , Bernd Edlinger , GCC Patches , Jason Merrill , Jeff Law Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671) Message-ID: <20170406150538.GG17461@tucnak> Reply-To: Jakub Jelinek References: <20170406075104.GA17461@tucnak> <7d17b3b7-2d38-6184-8bd6-eb9f96f87912@redhat.com> <20170406144326.GT4425@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00305.txt.bz2 On Thu, Apr 06, 2017 at 04:51:01PM +0200, Florian Weimer wrote: > On 04/06/2017 04:43 PM, Jonathan Wakely wrote: > > On 06/04/17 16:23 +0200, Richard Biener wrote: > > > On Thu, 6 Apr 2017, Florian Weimer wrote: > > > > > > > On 04/06/2017 04:11 PM, Bernd Edlinger wrote: > > > > > > > > > I think it is not too complicated to done in the C++ FE. > > > > > The FE looks for array of std::byte and unsigned char, > > > > > and sets the attribute when the final type is constructed. > > > > > > > > > > What I am trying to do is just extend the semantic of may_alias > > > > > a bit, and then have the C++ FE use it in the way it has to. > > > > > > > > We also need this for some POSIX and Linux kernel interfaces. A > > > > C++-only > > > > solution would not help with that. > > > > > > Example(s)? > > > > sockaddr_storage comes to mind. > > Right. The kernel also has many APIs which return multiple variable-length > data blocks, such as getdents64, and many more interfaces in combination The kernel uses -fno-strict-aliasing I think, so it doesn't care. Jakub