Date: Sun, 6 Dec 2015 13:34:36 -0800 From: Mark Millard <markmi@dsl-only.net> To: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, freebsd-ports@freebsd.org Subject: powerpc64-gcc 5.2 vintages get L". . ." type wrong compared to Char for FreeBSD for lib32 compiling Message-ID: <867D2B14-766D-4104-9A77-C35992C357B8@dsl-only.net>
next in thread | raw e-mail | index | archive | help
[I picked the lists that I did because powerpc64-gcc is the external = toolchain created to allow modern powerpc64 builds.] For the powerpc64-gcc 5.2 vintages. . . (using my environment's path as = an example) = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.2.0/gcc/config= /rs6000/freebsd64.h has: > /* rs6000.h gets this wrong for FreeBSD. We use the GCC defaults = instead. */ > #undef WCHAR_TYPE > #define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") > #undef WCHAR_TYPE_SIZE > #define WCHAR_TYPE_SIZE 32 That type in quotes ends up being the base type for L". . ." notation, = for example. Probably the char notation as well (L'?'). For FreeBSD Char compatibility in a powerpc64 lib32 context that "long = int" should effectively instead be "int", making the conditional above = technically unnecessary. This blocks compiling lib32 source code that uses such notations as L". = . .": "long int" is not compatible with FreeBSD's Char in the powerpc64 = environment's 32 bit environment. Some compiler message are explicit = about the base types of pointers that result for the mismatches: that is = how I know that "long int" is in use for L". . ." and "int" is the other = base type involved. (Yes, freebsd64.h appears to be used for lib32, at least on powerpc64. = By contrast freebsd.h agrees for the WCHAR_TYPE_SIZE but only undef's = WCHAR_TYPE, presuming gcc defaults are correct for FreeBSD as far as the = type goes. It might need a more explicit type to be sure of a Char match = for that freebsd.h file's context.) The 4.9 vintages of powerpc64-gcc were messed up the same way, as was = noted at the time. =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?867D2B14-766D-4104-9A77-C35992C357B8>