From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103781 invoked by alias); 7 Apr 2017 06:56:25 -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 103765 invoked by uid 89); 7 Apr 2017 06:56:24 -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=H*MI:sk:7FF41E4, H*i:sk:7FF41E4, Hx-languages-length:888, H*f:sk:7FF41E4 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; Fri, 07 Apr 2017 06:56:23 +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 A201E7E9DF; Fri, 7 Apr 2017 06:56:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A201E7E9DF 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 A201E7E9DF Received: from oldenburg.str.redhat.com (ovpn-116-71.ams2.redhat.com [10.36.116.71]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3C4C38E756; Fri, 7 Apr 2017 06:56:22 +0000 (UTC) Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671) To: Richard Biener , Bernd Edlinger , Jakub Jelinek References: <20170405160333.GR4425@redhat.com> <20170405160849.GV17461@tucnak> <20170406075104.GA17461@tucnak> <7d17b3b7-2d38-6184-8bd6-eb9f96f87912@redhat.com> <50936a77-870a-5156-1f5e-b1e0327498b6@redhat.com> <7FF41E4E-8C71-431D-A955-BED818241913@suse.de> Cc: Jonathan Wakely , GCC Patches , Jason Merrill , Jeff Law From: Florian Weimer Message-ID: <59cad987-433b-dcb2-13d9-e23bb8d8912a@redhat.com> Date: Fri, 07 Apr 2017 06:56: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: <7FF41E4E-8C71-431D-A955-BED818241913@suse.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00346.txt.bz2 On 04/06/2017 09:16 PM, Richard Biener wrote: > On April 6, 2017 8:12:29 PM GMT+02:00, Bernd Edlinger wrote: >> But isn't the effective type changed by the assignment b[1] = 0; >> as described in 6.5(6): >> "If a value is stored into an object having no declared type through an >> lvalue having a type that is not a character type, then the type of the >> lvalue becomes the effective type of the object for that access and for >> subsequent accesses that do not modify the stored value." > > Yes. I think the example is valid. At least GCCs memory model makes it so. As far as I understand the standard, C does not permit changing the effective type of an object if it has a declared type (at least not without a union). If GCC supports it, that's an undocumented GCC extension. Thanks, Florian