From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ecBf6-00032L-Iw for qemu-devel@nongnu.org; Thu, 18 Jan 2018 09:59:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ecBf2-0008GV-Ew for qemu-devel@nongnu.org; Thu, 18 Jan 2018 09:59:28 -0500 Received: from mail-qt0-x230.google.com ([2607:f8b0:400d:c0d::230]:41785) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ecBf2-0008G5-Am for qemu-devel@nongnu.org; Thu, 18 Jan 2018 09:59:24 -0500 Received: by mail-qt0-x230.google.com with SMTP id i1so14005635qtj.8 for ; Thu, 18 Jan 2018 06:59:24 -0800 (PST) Sender: =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= References: <20180109122252.17670-1-alex.bennee@linaro.org> <20180109122252.17670-11-alex.bennee@linaro.org> <1393deaf-c207-6055-1f7c-f7ae814cf2db@amsat.org> <87shb3nwkc.fsf@linaro.org> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Message-ID: <782d052d-f390-1a55-8a73-120753aa1472@amsat.org> Date: Thu, 18 Jan 2018 11:59:19 -0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose structures List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , Richard Henderson , =?UTF-8?Q?Alex_Benn=c3=a9e?= Cc: Francisco Iglesias , Laurent Vivier , QEMU Developers , Andrew Dutcher , bharata@linux.vnet.ibm.com, Aurelien Jarno On 01/18/2018 11:31 AM, Peter Maydell wrote: > On 18 January 2018 at 14:26, Philippe Mathieu-Daudé wrote: >> Le 18 janv. 2018 10:09 AM, "Alex Bennée" a écrit : >> Philippe Mathieu-Daudé writes: >>>> +typedef struct { >>>> + uint64_t frac : 64; >>> >>> I think this does not work on LLP64/IL32P64 model. >>> >>> Should we add a check in ./configure and refuse to build on IL32P64 >>> model? This would be safer IMHO. >>> >>>> + int exp : 32; >>>> + float_class cls : 8; >>>> + int : 23; >>>> + bool sign : 1; >>> >>> checking on "ISO/IEC 14882:1998" 9.6 Bit-fields: >>> >>> Alignment of bit-fields is implementation-defined. Bit-fields are packed >>> into some addressable allocation unit. [Note: bit-fields straddle >>> allocation units on some machines and not on others. Bit-fields are >>> assigned right-to-left on some machines, left-to-right on others. ] >>> >>> I'd still write it: >>> >>> int :23, sign :1; >>> >>>> +} decomposed_parts; >> >> I think rather than stuff it into bit fields we can just leave it up to >> the compiler? >> >> >> Yep, my only worry here is the IL32P64 model, if we care. > > I don't think we care much about IL32P64, but the code should > still work there, right? It doesn't actually make any assumptions > about bitfield layout. My comment was for a previous line: uint64_t frac : 64; I don't have enough compiler knowledge to be sure how this bitfield is interpreted by the compiler. I understood the standard as bitfields are for 'unsigned', and for IL32 we have sizeof(unsigned) = 32, so I wonder how a :64 bitfield ends (bits >= 32 silently truncated?). Richard do you have an idea? > > I think I agree that we shouldn't use bitfields here if we don't > need to, though. > > thanks > -- PMM >