BZ#13926: Add __bswap_64 for non-GCC compilers

[H.J. Lu]

On Wed, Mar 28, 2012 at 11:12 AM, Andreas Jaeger <aj@suse.com> wrote:
> On 03/28/2012 07:05 PM, Jakub Jelinek wrote:
>>
>> On Wed, Mar 28, 2012 at 04:51:00PM +0200, Andreas Jaeger wrote:
>>>
>>> +#else
>>> +# define __bswap_constant_64(x) \
>>> +     ((((x)&  0xff00000000000000ul)>>  56)
>>>     \
>>> +      | (((x)&  0x00ff000000000000ul)>>   40)
>>>      \
>>> +      | (((x)&  0x0000ff0000000000ul)>>  24)
>>>     \
>>> +      | (((x)&  0x000000ff00000000ul)>>  8)
>>>      \
>>> +      | (((x)&  0x00000000ff000000ul)<<  8)
>>>      \
>>> +      | (((x)&  0x0000000000ff0000ul)<<  24)
>>>     \
>>> +      | (((x)&  0x000000000000ff00ul)<<  40)
>>>     \
>>> +      | (((x)&  0x00000000000000fful)<<  56))
>>>
>>> +
>>> +static __inline unsigned long long int
>>> +__bswap_64 (unsigned long long int __bsx)
>>> +{
>>> +  return __bswap_constant_64 (__bsx);
>>> +}
>>
>>
>> How do you know that the non-GCC compiler in question supports
>> unsigned long long type at all?  It is not a standard C89 type...
>> Why are you using ul rather than ull suffixed constants?
>
>
> This is copied from the s390 implementation - which I'll fix if we can agree
> on how to do it.
>
> right now the installed header strings/endian.h contains:
> #  define htobe64(x) __bswap_64 (x)
> #  define htole64(x) (x)
> #  define be64toh(x) __bswap_64 (x)
> #  define le64toh(x) (x)
>
> So, IMO we should have a definition for __bswap_64.
>
> Would the patch be ok if do the changes that Roland suggested and use ull
> instead (and fix the s390 version the same)?
>
> I do think we require already that a compiler supports "long long" - looking
> at the installed headers there are many places in installed headers that use
> long long already. But I found  __GLIBC_HAVE_LONG_LONG in <features.h>.
> Should I just guard the definition by this? What shall we do if it's false -
> just fail silently?
>

Please make it compatible with x32, where long is 32bit and long long is 64bit.

Thanks.

-- 
H.J.