From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94294 invoked by alias); 6 Apr 2017 14:17:13 -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 93756 invoked by uid 89); 6 Apr 2017 14:17:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_1,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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 14:17:11 +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 545E46AADF; Thu, 6 Apr 2017 14:17:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 545E46AADF Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 545E46AADF Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 048ECA3D12; Thu, 6 Apr 2017 14:17:09 +0000 (UTC) Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671) To: Bernd Edlinger , Richard Biener , Jakub Jelinek References: <6a5109d6-81fb-c36c-e525-b2ed984760dc@redhat.com> <21E940B5-C8C4-4A86-8C15-49A86547DD87@suse.de> <20170405160333.GR4425@redhat.com> <20170405160849.GV17461@tucnak> <20170406075104.GA17461@tucnak> Cc: Jonathan Wakely , GCC Patches , Jason Merrill , Jeff Law From: Florian Weimer Message-ID: <7d17b3b7-2d38-6184-8bd6-eb9f96f87912@redhat.com> Date: Thu, 06 Apr 2017 14:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00296.txt.bz2 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. > Here is what I want to write in the doc: > > @item typeless_storage > @cindex @code{typeless_storage} type attribute > A type declared with this attribute behaves like a character type > with respect to aliasing semantics. > This is attribute is similar to the @code{may_alias} attribute, > except that it is not restricted to pointers. As Jakub pointed out, this is not what we need here. An object of type char does *not* have untyped storage. Accessing it as a different type is still undefined. The documentation says that the memory region is considered to by untyped, like a memory region returned by malloc (but obviously not with the implication that the memory region is separated from everything else). Thanks, Florian