From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54568) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhw1L-0005bn-Iq for qemu-devel@nongnu.org; Fri, 02 Oct 2015 04:48:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zhw1I-0000Qe-DT for qemu-devel@nongnu.org; Fri, 02 Oct 2015 04:48:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zhw1I-0000QS-7Y for qemu-devel@nongnu.org; Fri, 02 Oct 2015 04:48:48 -0400 References: <1443558863-26132-1-git-send-email-ehabkost@redhat.com> <1443558863-26132-2-git-send-email-ehabkost@redhat.com> <560BE355.60901@redhat.com> <560C44F4.6030200@twiddle.net> <560D3A8B.4020603@redhat.com> <560D6857.1030501@redhat.com> <560D6DBD.9010305@redhat.com> <560D7E04.5020505@redhat.com> From: Paolo Bonzini Message-ID: <560E44EB.2070803@redhat.com> Date: Fri, 2 Oct 2015 10:48:43 +0200 MIME-Version: 1.0 In-Reply-To: <560D7E04.5020505@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/2] target-i386: Use 1UL for bit shift List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek , Peter Maydell , Richard Henderson Cc: Eduardo Habkost , QEMU Developers On 01/10/2015 20:40, Laszlo Ersek wrote: > > Also strict aliasing improves performance noticeably at least on some > > kind of code. The relaxation of strict aliasing that GCC does with > > unions would be a useful addition to the C standard, though. > > What do you mean under "relaxation of strict aliasing that GCC does wit= h > unions"? I believe I know how unions affect this (although for details > I'd obviously have to consult the standard :)), but what are the gcc > specific parts? I remembered wrong---it's not a relaxation of strict aliasing, it's defining what happens when a member of a union is accessed through a member of a different type. C89 makes that implementation-defined (3.3.2.3) and GCC defines the behavior the sane way: "the relevant bytes of the representation of the object are treated as an object of the type used for the access". C99 makes the other members "take unspecified values" (6.2.6.1). I have always thought this to be weaker than GCC's promise, but found out that a subsequent TR added a footnote to clarify that the desired behavior is the sane one too. C11 also has the same footnote, and no other change in this area. Paolo