From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-451228-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 36111 invoked by alias); 6 Apr 2017 19:14:06 -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 35479 invoked by uid 89); 6 Apr 2017 19:14:05 -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_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 19:14:04 +0000
Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254])	by mx2.suse.de (Postfix) with ESMTP id 792CBAC30;	Thu,  6 Apr 2017 19:14:03 +0000 (UTC)
Date: Thu, 06 Apr 2017 19:14:00 -0000
User-Agent: K-9 Mail for Android
In-Reply-To: <AM4PR0701MB2162C4BFB925AF1D4368AD2CE40D0@AM4PR0701MB2162.eurprd07.prod.outlook.com>
References: <AM4PR0701MB216292327A207737064C3CA3E40A0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <6a5109d6-81fb-c36c-e525-b2ed984760dc@redhat.com> <21E940B5-C8C4-4A86-8C15-49A86547DD87@suse.de> <AM4PR0701MB2162D4E4FBF1612E05C35A0EE40A0@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671)
To: Bernd Edlinger <bernd.edlinger@hotmail.de>,Florian Weimer <fweimer@redhat.com>,Jakub Jelinek <jakub@redhat.com>
CC: Jonathan Wakely <jwakely@redhat.com>,GCC Patches <gcc-patches@gcc.gnu.org>,Jason Merrill <jason@redhat.com>,Jeff Law <law@redhat.com>
From: Richard Biener <rguenther@suse.de>
Message-ID: <0793C086-9DA4-4B21-9239-932916CAFF6B@suse.de>
X-SW-Source: 2017-04/txt/msg00327.txt.bz2

On April 6, 2017 7:39:14 PM GMT+02:00, Bernd Edlinger <bernd.edlinger@hotma=
il.de> 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 =3D {1,2,3,4};
>   short *b =3D (short *) &a;
>
>   b[1] =3D 0;
>
>   if (a[0] =3D=3D 1 && a[1] =3D=3D 2 && a[2] =3D=3D 3 && a[3] =3D=3D 4)
>     abort();
>
>   exit(0);
>}
>
>
>all I want to do is replace "char" with a different type.

Why?

Richard.

>Bernd.
>
>> 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