[Bug 206588] devel/powerpc64-gcc: on amd64 this builds as targeting little endian in some respects as indicated by the macros it defines; more
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Mon Jan 25 00:42:53 UTC 2016
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206588
Bug ID: 206588
Summary: devel/powerpc64-gcc: on amd64 this builds as targeting
little endian in some respects as indicated by the
macros it defines; more
Product: Ports & Packages
Version: Latest
Hardware: ppc
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: Individual Port(s)
Assignee: bapt at FreeBSD.org
Reporter: markmi at dsl-only.net
Assignee: bapt at FreeBSD.org
Flags: maintainer-feedback?(bapt at FreeBSD.org)
I used the following program and compiler command line options to dump macro
definitions from devel/powerpc64-gcc and discovered some nasty ones:
LITTLE_ENDIAN usage on amd64 despite targeting a big endian powerpc64.
Differing __NO_STRICT_ALIGNMENT status and __GCC_HAVE_DWARF2_CFI_ASM status as
well. The details follow.
# more with_libc++__config.cpp
#include <__config>
int main(void)
{ return 0; }
used via:
/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -std=c++11 -I/usr/include
-I/usr/include/c++/v1/ -dM -E func.cpp | sort > ~/powerpc64-gcc_52_macros.txt
on a native powerpc64 (Powermac G5) context and on a amd64 context (inside
Virtual Box on Mac OS X). The "<"'s below are from the G5 context and the ">"
below are from the amd64 context.
There is also a related __NO_STRICT_ALIGNMENT difference and a
__GCC_HAVE_DWARF2_CFI_ASM difference.
# diff /media/root/powerpc64_gcc_52_macros.txt ~/powerpc64_gcc_52_macros.txt |
more
16c16
< #define _BYTE_ORDER _BIG_ENDIAN
---
> #define _BYTE_ORDER _LITTLE_ENDIAN
27c27
< #define _LIBCPP_BIG_ENDIAN 1
---
> #define _LIBCPP_BIG_ENDIAN 0
60c60
< #define _LIBCPP_LITTLE_ENDIAN 0
---
> #define _LIBCPP_LITTLE_ENDIAN 1
84,85c84,85
< #define _QUAD_HIGHWORD 0
< #define _QUAD_LOWWORD 1
---
> #define _QUAD_HIGHWORD 1
> #define _QUAD_LOWWORD 0
200d199
< #define __GCC_HAVE_DWARF2_CFI_ASM 1
289a289
> #define __NO_STRICT_ALIGNMENT
391,396c391,396
< #define __bswap16(x) ((__uint16_t)(__is_constant(x) ? __bswap16_const(x) :
__bswap16_var(x)))
< #define __bswap16_const(x) ((((__uint16_t)(x) >> 8) & 0xff) |
(((__uint16_t)(x) << 8) & 0xff00))
< #define __bswap32(x) (__is_constant(x) ? __bswap32_const(x) :
__bswap32_var(x))
< #define __bswap32_const(x) ((((__uint32_t)(x) >> 24) & 0xff) |
(((__uint32_t)(x) >> 8) & 0xff00) | (((__uint32_t)(x)<< 8) & 0xff0000) |
(((__uint32_t)(x) << 24) & 0xff000000))
< #define __bswap64(x) (__is_constant(x) ? __bswap64_const(x) :
__bswap64_var(x))
< #define __bswap64_const(x) ((((__uint64_t)(x) >> 56) & 0xff) |
(((__uint64_t)(x) >> 40) & 0xff00) | (((__uint64_t)(x) >> 24) & 0xff0000) |
(((__uint64_t)(x) >> 8) & 0xff000000) | (((__uint64_t)(x) << 8) &
((__uint64_t)0xff << 32)) | (((__uint64_t)(x) << 24) & ((__uint64_t)0xff <<
40)) | (((__uint64_t)(x) << 40) & ((__uint64_t)0xff << 48)) | (((__uint64_t)(x)
<< 56) & ((__uint64_t)0xff << 56)))
---
> #define __bswap16(x) ((__uint16_t)(__builtin_constant_p(x) ? __bswap16_gen((__uint16_t)(x)) : __bswap16_var(x)))
> #define __bswap16_gen(x) (__uint16_t)((x) << 8 | (x) >> 8)
> #define __bswap32(x) (__builtin_constant_p(x) ? __bswap32_gen((__uint32_t)(x)) : __bswap32_var(x))
> #define __bswap32_gen(x) (((__uint32_t)__bswap16((x) & 0xffff) << 16) | __bswap16((x) >> 16))
> #define __bswap64(x) (__builtin_constant_p(x) ? __bswap64_gen((__uint64_t)(x)) : __bswap64_var(x))
> #define __bswap64_gen(x) (((__uint64_t)__bswap32((x) & 0xffffffff) << 32) | __bswap32((x) >> 32))
459,460c459,460
< #define __htonl(x) ((__uint32_t)(x))
< #define __htons(x) ((__uint16_t)(x))
---
> #define __htonl(x) __bswap32(x)
> #define __htons(x) __bswap16(x)
462d461
< #define __is_constant(x) __builtin_constant_p(x)
473,474c472,473
< #define __ntohl(x) ((__uint32_t)(x))
< #define __ntohs(x) ((__uint16_t)(x))
---
> #define __ntohl(x) __bswap32(x)
> #define __ntohs(x) __bswap16(x)
517,519c516,518
< #define be16toh(x) ((uint16_t)(x))
< #define be32toh(x) ((uint32_t)(x))
< #define be64toh(x) ((uint64_t)(x))
---
> #define be16toh(x) bswap16((x))
> #define be32toh(x) bswap32((x))
> #define be64toh(x) bswap64((x))
523,531c522,530
< #define htobe16(x) ((uint16_t)(x))
< #define htobe32(x) ((uint32_t)(x))
< #define htobe64(x) ((uint64_t)(x))
< #define htole16(x) bswap16((x))
< #define htole32(x) bswap32((x))
< #define htole64(x) bswap64((x))
< #define le16toh(x) bswap16((x))
< #define le32toh(x) bswap32((x))
< #define le64toh(x) bswap64((x))
---
> #define htobe16(x) bswap16((x))
> #define htobe32(x) bswap32((x))
> #define htobe64(x) bswap64((x))
> #define htole16(x) ((uint16_t)(x))
> #define htole32(x) ((uint32_t)(x))
> #define htole64(x) ((uint64_t)(x))
> #define le16toh(x) ((uint16_t)(x))
> #define le32toh(x) ((uint32_t)(x))
> #define le64toh(x) ((uint64_t)(x))
In both contexts devel/powerpc64-gcc was built via "portmaster -DK" sorts of
activity.
(FYI: For powerpc64 native 6 file names/placements are messed up relative to
staging and need to be moved/copied to the expected names/placements. Then
portmaster -CDK can be used to finish it off.)
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-ports-bugs
mailing list