From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59102) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiZ83-0003qU-Tr for qemu-devel@nongnu.org; Sat, 03 Oct 2015 22:34:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZiZ7z-0006CO-Ri for qemu-devel@nongnu.org; Sat, 03 Oct 2015 22:34:23 -0400 Received: from mail-qg0-f48.google.com ([209.85.192.48]:35834) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiZ7z-0006CF-Oe for qemu-devel@nongnu.org; Sat, 03 Oct 2015 22:34:19 -0400 Received: by qgt47 with SMTP id 47so124466518qgt.2 for ; Sat, 03 Oct 2015 19:34:19 -0700 (PDT) Date: Sat, 3 Oct 2015 22:34:17 -0400 From: Kevin O'Connor Message-ID: <20151004023417.GA13062@morn.lan> References: <560C44F4.6030200@twiddle.net> <560D3A8B.4020603@redhat.com> <560D6857.1030501@redhat.com> <560D6DBD.9010305@redhat.com> <560D86BE.1050404@redhat.com> <560E41AC.2030706@redhat.com> <560E670D.9090105@redhat.com> <560E7384.9000901@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <560E7384.9000901@redhat.com> 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: Paolo Bonzini Cc: Peter Maydell , Richard Henderson , Laszlo Ersek , QEMU Developers , Eduardo Habkost On Fri, Oct 02, 2015 at 02:07:32PM +0200, Paolo Bonzini wrote: > On 02/10/2015 13:14, Laszlo Ersek wrote: > > On 10/02/15 10:34, Paolo Bonzini wrote: > >> On 01/10/2015 21:17, Laszlo Ersek wrote: > >>> - In the firmware, allocate an array of bytes, dynamically. This array > >>> will have no declared type. > >>> > >>> - Populate the array byte-wise, from fw_cfg. Because the stores happen > >>> through character-typed lvalues, they do not "imbue" the target > >>> object with any effective type, for further accesses that do not > >>> modify the value. (I.e., for further reads.) > >>> > >>> - Get a (uint8_t*) into the array somewhere, and cast it to > >>> (struct acpi_table_hdr *). Read fields through the cast pointer. > >>> Assuming no out-of-bounds situation (considering the entire > >>> pointed to acpi_table_hdr struct), and assuming no alignment > >>> violations for the fields (which is implementation-defined), these > >>> accesses will be fine. > >>> > >>> *However*. If in point 2 you populate the array with uint64_t accesses, > >>> that *does* imbue the array elements with an effective type that is > >>> binding for further read accesses. > >> > >> Then don't do it. Use memcpy from uint64_t to the array. > > > > It won't work; memcpy() propagates the effective type. > > Doh. I guess that's another "not in practice" case. Saying "memcpy to > {,u}int8_t doesn't propagate the effective type" would probably go to > great lengths towards fixing this. Just to be pedantic, uint8_t/int8_t are not the same as 'char' wrt aliasing rules. (The standard defines writes to a char array/pointer as being allowed to alias with other types, but does not say that about int8_t.) Gcc currently treats them as the same; I actually tried to get gcc to change that a few months ago: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110#c13 FWIW, I think the aliasing rules allow for very useful optimizations and I wouldn't want to turn them off for programs where performance is important. The test case in the bug link above (which the gcc developers thankfully did address!) is a good example of the utility of alias detection. This function: void func(struct s2 *p) { p->p1->f2 = 9; p->p1->f2 = 10; } can't be optimized without -fstrict-aliasing. Indeed, even if the code was changed to p->p1->f3 = 11; p->p1->f4 = 12; then gcc would still need to reload p->p1 after every store. That's just silly. -Kevin