This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: BZ#13926: Add __bswap_64 for non-GCC compilers


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]