From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59021) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZujB5-0006ng-6H for qemu-devel@nongnu.org; Fri, 06 Nov 2015 10:43:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZujB1-0004tY-AX for qemu-devel@nongnu.org; Fri, 06 Nov 2015 10:43:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45397) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZujB1-0004tU-5J for qemu-devel@nongnu.org; Fri, 06 Nov 2015 10:43:43 -0500 References: <1446473134-4330-1-git-send-email-pbonzini@redhat.com> <563777D5.6050000@redhat.com> <5639DA14.3020507@twiddle.net> <5639E1C2.80902@redhat.com> <5639E691.4050203@twiddle.net> <563A968D.705@ilande.co.uk> <563B1D91.5010701@redhat.com> <563B1F65.5000603@twiddle.net> <563B206F.3020800@redhat.com> <563CC859.8090300@ilande.co.uk> From: Paolo Bonzini Message-ID: <563CCAA6.2000907@redhat.com> Date: Fri, 6 Nov 2015 16:43:34 +0100 MIME-Version: 1.0 In-Reply-To: <563CC859.8090300@ilande.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] target-sparc: fix 32-bit truncation in fpackfix List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Mark Cave-Ayland , Richard Henderson , Peter Maydell Cc: Blue Swirl , QEMU Developers On 06/11/2015 16:33, Mark Cave-Ayland wrote: >>> >> >>>> >>> /* Ugly code */ >>>> >>> int64_t scaled = (uint64_t)(int64_t)src << scale; >>> >> >>> >> You mean >>> >> >>> >> int64_t scaled = (int64_t)((uint64_t)src << scale); >> > >> > No, that also looks like a typo. >> > >> > I mean: >> > >> > - unnecessary cast to int64_t to get the sign extension while avoiding >> > the impression of a typo >> > >> > - cast to uint64_t to avoid overflow >> > >> > - the shift is done in the uint64_t type >> > >> > - finally there is an implicit cast to int64_t > I would say that Richard's version above is the most readable to me, > however from what you're saying this would cause the compiler to produce > much less efficient code? No, they should all be the same. Let's go with the "seems like a typo" version :) with a comment to say that no, it's not a typo. Paolo > If this is the case then I could live with your second choice ("Seems > like a typo") with an appropriate comment if this maintains the > efficiency of generated code whilst also having well-defined behaviour > between compilers. Out of interest has anyone tried these alternatives > on clang?