From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32883 invoked by alias); 6 Apr 2017 07:23:29 -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 30873 invoked by uid 89); 6 Apr 2017 07:23:28 -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_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Apr 2017 07:23:27 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id B157DAC1D; Thu, 6 Apr 2017 07:23:26 +0000 (UTC) Date: Thu, 06 Apr 2017 07:23:00 -0000 From: Richard Biener To: Jason Merrill cc: Bernd Edlinger , Jakub Jelinek , GCC Patches , Marc Glisse , Jonathan Wakely , Jeff Law Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671) In-Reply-To: Message-ID: References: <20170405132832.GS17461@tucnak> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2017-04/txt/msg00262.txt.bz2 On Wed, 5 Apr 2017, Jason Merrill wrote: > On Wed, Apr 5, 2017 at 1:41 PM, Bernd Edlinger > wrote: > > On 04/05/17 17:20, Richard Biener wrote: > >>> Also, wonder if you need to mark all types containing such arrays, > >>> if you couldn't just set that flag in C++ on unsigned char/std::byte > >>> arrays (and on anything with that attribute), have that imply alias set > >>> 0 on it and then let the rest of alias machinery handle aggregate types > >>> containing such fields. > >> > >> Yes, I expected it to work like this (didn't look at the patch yet). > > My impression is that this is how GCC 6 worked, but GCC 7 decides to > ignore alias set 0 members. Is that right? Yes, in GCC 6 an access via an aggregate type that had an alias-set zero member was using alias-set zero. So we'd re-instantiate that behavior for aggregates containing a type marked with the proposed new flag. > > I want to allow *only* what the C++ standard requires or what Jason says > > of course :), and not a single bit more, because it suppresses otherwise > > correct optimizations. > > > > So a struct with a std::byte member is not alias_set 0, > > only the std::byte itself is, but an array of std::byte > > is itself typeless_storage, and makes the whole structure > > also typeless_storage > > Well, only the array member, not the whole structure, but it may make > sense for GCC to treat the whole structure as such internally. Yes, it's the easiest way to implement the required behavior. But I wouldn't document it that way but clearly state that only the marked member behaves so but that for the purpose of accesses via a container type the standards access rules apply as if the member is accessed with a character type. Richard.