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

On 06.12.15 22:34, Mark Millard wrote:
> [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.

I'll take care.

Andreas