[Mesa-dev] [PATCH 1/3] util: Cope with LONG_BIT not being defined on Windows.

[Jose Fonseca]

On 09/08/15 21:21, Roland Scheidegger wrote:
> Am 09.08.2015 um 20:08 schrieb Jose Fonseca:
>> On 09/08/15 17:47, Matt Turner wrote:
>>> On Sun, Aug 9, 2015 at 3:57 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
>>>> Neither MSVC nor MinGW defines LONG_BIT.  For MSVC this was not a
>>>> problem as
>>>> it doesn't define __x86_64__ macro (it's GCC specific.)
>>>>
>>>> However on Windows long type is guaranteed to be 32bits.
>>>>
>>>> Also add an #error, as GCC will just warn, not throw any error, when no
>>>> value is returned.
>>>>
>>>> Trivial.
>>>> ---
>>>>    src/util/rounding.h | 8 ++++++--
>>>>    1 file changed, 6 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/src/util/rounding.h b/src/util/rounding.h
>>>> index b0c9918..ec31b47 100644
>>>> --- a/src/util/rounding.h
>>>> +++ b/src/util/rounding.h
>>>> @@ -96,8 +96,10 @@ _mesa_lroundevenf(float x)
>>>>    #ifdef __x86_64__
>>>>    #if LONG_BIT == 64
>>>>       return _mm_cvtss_si64(_mm_load_ss(&x));
>>>> -#elif LONG_BIT == 32
>>>> +#elif LONG_BIT == 32 || defined(_WIN32)
>>>
>>> Not clear to me that you want to do this, since on x86-32 using SSE
>>> intrinsics will force a few memory transfers to and from the x87 FPU.
>>
>> Our Windows builds use SSE math for x86. (ie., -fpmath=sse for GCC, no
>> option required for MSVC, as it's the standard.)  So no x87 should be
>> ever used.
>>
>> (Probably it should make sense to use -msse2 and -fpmath=sse on all
>> 32bits x86.)
>>
>>>
>>>>       return _mm_cvtss_si32(_mm_load_ss(&x));
>>>> +#else
>>>> +#error "Unsupported or undefined LONG_BIT"
>>>
>>> MSVC... sigh.
>>
>> The problem was actually with MinGW, not MSVC.  As the commit
>> description said, MSVC was fine (because it doesn't define __x86_64__).
>>
>> AFAICT, LONG_BIT is not standard C.  So I don't think that MSVC or MinGW
>> is at fault.
>>
>> Jose
>
> Apparently it's not even always defined on linux...
> I wonder if soething like
> #if LONG_MAX == 0x7FFFFFFFL would be more portable...

Yes, that seems a good idea.

Jose