From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30119 invoked by alias); 6 Apr 2017 17:48:22 -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 19930 invoked by uid 89); 6 Apr 2017 17:48:04 -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 17:48:02 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 862CA64F4; Thu, 6 Apr 2017 17:48:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 862CA64F4 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 862CA64F4 Received: from oldenburg.str.redhat.com (ovpn-116-43.ams2.redhat.com [10.36.116.43]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 020DF8C528; Thu, 6 Apr 2017 17:48:00 +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> <7d17b3b7-2d38-6184-8bd6-eb9f96f87912@redhat.com> Cc: Jonathan Wakely , GCC Patches , Jason Merrill , Jeff Law From: Florian Weimer Message-ID: <50936a77-870a-5156-1f5e-b1e0327498b6@redhat.com> Date: Thu, 06 Apr 2017 17:48: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/msg00318.txt.bz2 On 04/06/2017 07:39 PM, Bernd Edlinger wrote: > On 04/06/17 16:17, Florian Weimer wrote: >>> 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. >> > > but, do you agree that this is valid in C11? > > typedef char char_a[4]; > > int > main (void) > { > char_a a = {1,2,3,4}; > short *b = (short *) &a; > > b[1] = 0; > > if (a[0] == 1 && a[1] == 2 && a[2] == 3 && a[3] == 4) > abort(); > > exit(0); > } > > > all I want to do is replace "char" with a different type. Thanks a lot for posting a concrete example. The effective type of a[2] and [3] is char. The character type wildcard in 6.5(7) only applies to the type of the lvalue expression ysed for the access, not the effective type of the object being accessed. The type of the LHS of the assignment expression is short. So the access is undefined. Florian