PATCH: Add bits/byteswap-16.h and use GCC builtin 32/64-bit bswap

[Mike Frysinger]

On Tuesday 24 April 2012 07:19:56 Andreas Jaeger wrote:
> On Tuesday, April 24, 2012 11:31:57 Chung-Lin Tang wrote:
> > On 2012/4/7 03:40 AM, H.J. Lu wrote:
> > > 2012-04-06  H.J. Lu  <hongjiu.lu@intel.com>
> > > 
> > > 	* bits/byteswap.h (__bswap_16): Removed.
> > > 	Include <bits/byteswap-16.h> to get __bswap_16.
> > > 	(__bswap_32): Use __builtin_bswap32 for GCC >= 4.2.
> > > 	(__bswap_64): Use __builtin_bswap64 for GCC >= 4.2.
> > > 	* bits/byteswap-16.h: New file.
> > 
> > For SH, this triggered a build fail, due to those inline C functions
> > being added to a assembly file (the SH strlen.S use of endian.h) after a
> > complex include sequence.
> > 
> > Of course, there's nothing wrong with those __bswap* functions. It seems
> > that string/endian.h includes a bunch of stuff not usable anyways for
> > assembler, so here's trivial patch to correct this.
> > 
> > 2012-04-24  Chung-Lin Tang  <cltang@codesourcery.com>
> > 
> > 	* string/endian.h: Add !__ASSEMBLER__ condition for including
> > 	conversion interfaces.
> 
> I wonder whether that's the right approach at all, I see this done only in
> <bits/errno.h> and <features.h>.
> 
> I suggest to solve this differently for sh.
> Currently you do:
> #if __BYTE_ORDER == __BIG_ENDIAN
> 
> Looking at sysdeps/sh/bits/endian.h, can't you use instead:
> #ifndef __LITTLE_ENDIAN__

i think this is a step backwards.  the point of endian.h is to normalize all 
the random ugliness of interpreting gcc defines to the consistent interface:
	__BYTE_ORDER == __LITTLE_ENDIAN
	__BYTE_ORDER == __BIG_ENDIAN

but now we have to inline endian.h logic in assembly files ?  i think it makes 
more sense to make endian.h usable from assembly like Chung-Lin proposed.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20120427/0274b4fb/attachment.sig>