powerpc64-gcc 5.2 vintages get L". . ." type wrong compared to Char for FreeBSD for lib32 compiling

[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.



===
Mark Millard
markmi at dsl-only.net