qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose struct


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-devel] [PATCH v2 10/20] fpu/softfloat: define decompose structures
Date: Thu, 18 Jan 2018 11:59:19 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]