From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-451251-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 109154 invoked by alias); 7 Apr 2017 08:01:08 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 109136 invoked by uid 89); 7 Apr 2017 08:01:08 -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; Fri, 07 Apr 2017 08:01:06 +0000
Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254])	by mx2.suse.de (Postfix) with ESMTP id 80A75AC19;	Fri,  7 Apr 2017 08:01:05 +0000 (UTC)
Date: Fri, 07 Apr 2017 08:01:00 -0000
From: Richard Biener <rguenther@suse.de>
To: Florian Weimer <fweimer@redhat.com>
cc: Bernd Edlinger <bernd.edlinger@hotmail.de>,     Jakub Jelinek <jakub@redhat.com>, Jonathan Wakely <jwakely@redhat.com>,     GCC Patches <gcc-patches@gcc.gnu.org>, Jason Merrill <jason@redhat.com>,     Jeff Law <law@redhat.com>
Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671)
In-Reply-To: <59cad987-433b-dcb2-13d9-e23bb8d8912a@redhat.com>
Message-ID: <alpine.LSU.2.20.1704070958330.30715@zhemvz.fhfr.qr>
References: <AM4PR0701MB216292327A207737064C3CA3E40A0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <20170405160333.GR4425@redhat.com> <20170405160849.GV17461@tucnak> <AM4PR0701MB2162884DCF4538DC0FF5C2F1E40A0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <AM4PR0701MB21623337A5C0C1850D3DF4C7E40A0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <alpine.LSU.2.20.1704060925130.30715@zhemvz.fhfr.qr> <20170406075104.GA17461@tucnak> <alpine.LSU.2.20.1704060952480.30715@zhemvz.fhfr.qr> <AM4PR0701MB216235AC9FDCC6D5F8D7C96DE40D0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <7d17b3b7-2d38-6184-8bd6-eb9f96f87912@redhat.com> <AM4PR0701MB2162C4BFB925AF1D4368AD2CE40D0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <50936a77-870a-5156-1f5e-b1e0327498b6@redhat.com> <AM4PR0701MB2162B4A0AEF56BDEEC1247E0E40D0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <7FF41E4E-8C71-431D-A955-BED818241913@suse.de> <59cad987-433b-dcb2-13d9-e23bb8d8912a@redhat.com>
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/msg00350.txt.bz2

On Fri, 7 Apr 2017, Florian Weimer wrote:

> On 04/06/2017 09:16 PM, Richard Biener wrote:
> > On April 6, 2017 8:12:29 PM GMT+02:00, Bernd Edlinger
> > <bernd.edlinger@hotmail.de> 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.

The GCC middle-end supports it because C++ supports it and there is no
way for the C FE to tell the middle-end that this is not valid.

Richard.