On 01/18/2018 11:31 AM, Peter Maydell wrote: > On 18 January 2018 at 14:26, Philippe Mathieu-Daudé <f4...@amsat.org> wrote: >> Le 18 janv. 2018 10:09 AM, "Alex Bennée" <alex.ben...@linaro.org> a écrit : >> Philippe Mathieu-Daudé <f4...@amsat.org> 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 >