>> In ticket #10800, initially I thought problems with the byteswap >> implementations was related to calling conventions, however, digging >> deeper and after some clarification by tqh, it's obviously not the >> case. >> >> It was also suggested to use GCC builtins to replace the existing >> byteswap functions, and I have the beginnings of a patch: >> >> https://dev.haiku-os.org/attachment/ticket/10800/0001-Replace-arch-dependent-integer-byteswap-routines-wit.patch >> >> Is this the right place to do this? > > > Yep, looks good. I'd also replace the implementation of the __swap_int*() by > a call the the respective built-in (i.e. replace the per-arch assembly > implementation by a generic one). We can eventually even drop the non-gcc 2 > ones. > > I guess the float and double versions can be mapped to the int versions as > well with some casting. > > >> Is it sufficient to assume this >> will be okay on all our platforms, or do we still want the builtins >> abstracted? If so, can that be done without losing the ability to > >> inline them? > > I don't think we need an abstraction. Only for BeOS binary compatibility we > the function definitions. At least according to the gcc 4.8.2 documentation > [1], the built-ins are available on all architectures. At a first glance, > gcc 2.95.3 doesn't seem to provide them, though [2]. Yes, I tried building gcc2h image, and it failed with undefined references to the builtins. So in terms of ABI, do the __swap_xyz() functions only need to be preserved when compiling with gcc2? I.e. other builds it will be inlined, and __swap_xyz() won't be part of the ABI? i.e. like in https://dev.haiku-os.org/attachment/ticket/10800/0001-Use-GCC-builtins-for-byte-swapping.-Fixes-10800.patch It would then also be safe to completely remove the external definitions for the non-x86 architectures as well, correct? Jessica