i386 machine/endian.h
I've been playing around with lang/icc a bit, and find it quite vexing that machine/endian.h has macros that are ifdef'd around __GNUC__. The intel compiler does not like the macros, partly because they are split across multiple lines and possibly for other reasons. It seems to me that making a header actually _require_ gcc-isms is something that the FreeBSD team should be working away from... Would it not be possible to put make some more generic macros available as well? I'm sure it's not the only instance of similar issues, but making one header less gcc-dependent is a step in the right direction is it not? WNM -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 machine/endian.h
On Sun, 22 Sep 2002, Wesley Morgan wrote: I've been playing around with lang/icc a bit, and find it quite vexing that machine/endian.h has macros that are ifdef'd around __GNUC__. The intel compiler does not like the macros, partly because they are split across multiple lines and possibly for other reasons. The Intel compiler shouldn't see these macros, so it should emit calls to the corresponding library functions. The macros work correctly with Tendra because it doesn't see them. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 machine/endian.h
As far as I can tell there are no __bswap* macros in the libraries; they are defined as bswap*. Whatever should be happening, the network byte swapping functions are creeping in using the __hton* and __ntoh* macros. These are pulling in the __bswap* functions that are of course undefined. Unless I'm doing something completely wrong here... Just dropping in icc to replace gcc/g++. On Mon, 23 Sep 2002, Bruce Evans wrote: On Sun, 22 Sep 2002, Wesley Morgan wrote: I've been playing around with lang/icc a bit, and find it quite vexing that machine/endian.h has macros that are ifdef'd around __GNUC__. The intel compiler does not like the macros, partly because they are split across multiple lines and possibly for other reasons. The Intel compiler shouldn't see these macros, so it should emit calls to the corresponding library functions. The macros work correctly with Tendra because it doesn't see them. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 machine/endian.h
Wesley Morgan [EMAIL PROTECTED] writes: I've been playing around with lang/icc a bit, and find it quite vexing that machine/endian.h has macros that are ifdef'd around __GNUC__. The intel compiler does not like the macros, partly because they are split across multiple lines and possibly for other reasons. It seems to me that making a header actually _require_ gcc-isms is something that the FreeBSD team should be working away from... Would it not be possible to put make some more generic macros available as well? I'm sure it's not the only instance of similar issues, but making one header less gcc-dependent is a step in the right direction is it not? This was my fault. I wasn't paying attention closely to issues with other compilers. I've had the attached patch in my local tree for some time, but haven't had a chance to test it with ICC. Can you confirm it fixes the issues you're seeing? Best regards, Mike Barcroft Be careful not to define GCC-specific optimizations in the non-GCC case. Index: endian.h === RCS file: /work/repo/src/sys/i386/include/endian.h,v retrieving revision 1.34 diff -u -r1.34 endian.h --- endian.h21 Aug 2002 16:19:58 - 1.34 +++ endian.h22 Aug 2002 00:29:19 - @@ -117,11 +117,18 @@ return (__byte_swap_word(_x)); } -#endif /* __GNUC__ */ - #define__htonl(x) __bswap32(x) #define__htons(x) __bswap16(x) #define__ntohl(x) __bswap32(x) #define__ntohs(x) __bswap16(x) + +#else /* !__GNUC__ */ + +#undef htonl +#undef htons +#undef ntohl +#undef ntohl + +#endif /* __GNUC__ */ #endif /* !_MACHINE_ENDIAN_H_ */
Re: i386 machine/endian.h
Mike Barcroft [EMAIL PROTECTED] writes: Wesley Morgan [EMAIL PROTECTED] writes: I've been playing around with lang/icc a bit, and find it quite vexing that machine/endian.h has macros that are ifdef'd around __GNUC__. The intel compiler does not like the macros, partly because they are split across multiple lines and possibly for other reasons. It seems to me that making a header actually _require_ gcc-isms is something that the FreeBSD team should be working away from... Would it not be possible to put make some more generic macros available as well? I'm sure it's not the only instance of similar issues, but making one header less gcc-dependent is a step in the right direction is it not? This was my fault. I wasn't paying attention closely to issues with other compilers. I've had the attached patch in my local tree for some time, but haven't had a chance to test it with ICC. Can you confirm it fixes the issues you're seeing? I thought about this a little bit more, and the previous patch won't do anything unless two headers call machine/endian.h. A new patch which is much more likely to work is attached. Can you try this one instead? Best regards, Mike Barcroft Be careful not to define GCC-specific optimizations in the non-GCC case. Index: endian.h === RCS file: /work/repo/src/sys/i386/include/endian.h,v retrieving revision 1.34 diff -u -r1.34 endian.h --- endian.h21 Aug 2002 16:19:58 - 1.34 +++ endian.h23 Sep 2002 01:58:16 - @@ -117,11 +117,20 @@ return (__byte_swap_word(_x)); } -#endif /* __GNUC__ */ - #define__htonl(x) __bswap32(x) #define__htons(x) __bswap16(x) #define__ntohl(x) __bswap32(x) #define__ntohs(x) __bswap16(x) + +#else /* !__GNUC__ */ + +/* + * No optimizations are available for this compiler. Fall back to + * non-optimized functions by defining the constant usually used to prevent + * redefinition. + */ +#define_BYTEORDER_FUNC_DEFINED + +#endif /* __GNUC__ */ #endif /* !_MACHINE_ENDIAN_H_ */
Re: i386 machine/endian.h
On Sun, Sep 22, 2002 at 09:57:57PM -0400, Mike Barcroft wrote: Mike Barcroft [EMAIL PROTECTED] writes: Wesley Morgan [EMAIL PROTECTED] writes: I've been playing around with lang/icc a bit, and find it quite vexing that machine/endian.h has macros that are ifdef'd around __GNUC__. The intel compiler does not like the macros, partly because they are split across multiple lines and possibly for other reasons. It seems to me that making a header actually _require_ gcc-isms is something that the FreeBSD team should be working away from... Would it not be possible to put make some more generic macros available as well? I'm sure it's not the only instance of similar issues, but making one header less gcc-dependent is a step in the right direction is it not? This was my fault. I wasn't paying attention closely to issues with other compilers. I've had the attached patch in my local tree for some time, but haven't had a chance to test it with ICC. Can you confirm it fixes the issues you're seeing? I thought about this a little bit more, and the previous patch won't do anything unless two headers call machine/endian.h. A new patch which is much more likely to work is attached. Can you try this one instead? Works fine, please commit. Best regards, Mike Barcroft Be careful not to define GCC-specific optimizations in the non-GCC case. Index: endian.h === RCS file: /work/repo/src/sys/i386/include/endian.h,v retrieving revision 1.34 diff -u -r1.34 endian.h --- endian.h 21 Aug 2002 16:19:58 - 1.34 +++ endian.h 23 Sep 2002 01:58:16 - @@ -117,11 +117,20 @@ return (__byte_swap_word(_x)); } -#endif /* __GNUC__ */ - #define __htonl(x) __bswap32(x) #define __htons(x) __bswap16(x) #define __ntohl(x) __bswap32(x) #define __ntohs(x) __bswap16(x) + +#else /* !__GNUC__ */ + +/* + * No optimizations are available for this compiler. Fall back to + * non-optimized functions by defining the constant usually used to prevent + * redefinition. + */ +#define _BYTEORDER_FUNC_DEFINED + +#endif /* __GNUC__ */ #endif /* !_MACHINE_ENDIAN_H_ */ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 machine/endian.h
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: On Sun, Sep 22, 2002 at 09:57:57PM -0400, Mike Barcroft wrote: Mike Barcroft [EMAIL PROTECTED] writes: This was my fault. I wasn't paying attention closely to issues with other compilers. I've had the attached patch in my local tree for some time, but haven't had a chance to test it with ICC. Can you confirm it fixes the issues you're seeing? I thought about this a little bit more, and the previous patch won't do anything unless two headers call machine/endian.h. A new patch which is much more likely to work is attached. Can you try this one instead? Works fine, please commit. Done. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
