gcc-4.9.1/gcc/config/rs6000/freebsd64.h vs. FreeBSD's powerpc (non-64) L"..." and wchar_t (other gcc ports too?)

[Mark Millard]

[The following may point to something that should be directed upstream for gcc 4.9+ (and possibly earlier?) and/or something for the port(s) to patch.]

Short version:

Looking at /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-4.9.1/gcc/config/rs6000/freebsd64.h shows:

> /* 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


The above is what controls the type that results for L". . ." notation no matter what the FreeBSD typedefs for wchar_t trace back to (int for powerpc and powerpc64).

For FreeBSD that long int should also be just int from what I can tell. Why? . . .

For it being long int: when trying WITH_LIB32= for buildworld with powerpc64-xtoolchain-gcc's powerpc64-gcc port (on a powerpc64 box, using WITHOUT_BOOT= ) this leads to the following in libedit:

> . . . parse.c:181:25: error: array of inappropriate type initialized from string constant
>                         const Char hex[] = STR("0123456789ABCDEF");
>                         ^

where STR(". . .") produces L". . ." and Char traces back to wchar_t (and back to int for the context).

I also got lots of warnings about incompatible pointer types when Char and STR(. . .) were in the mix for libedit. The ones that mention a type explicitly mention long int *.



I have not checked other processor families: I only have access to PowerMac based FreeBSD's so far.

I have not checked other gcc ports: Are gcc ports that are not explicitly used for system builds supposed to be well behaved for L". . ." notation vs. the FreeBSD wchar_t definition for C? If yes then they likely need the same sort of adjustment.



Details/evidence below: Ignore the following if the above is enough.

The evidence for what was installed for powerpc64-gcc (on the powerpc64 box) and what it will treat L". . ." as is:

> # /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc-4.9.1 -dM -E -m32 - < /dev/null | grep WCHAR
> #define __WCHAR_MAX__ 2147483647L
> #define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1)
> #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
> #define __WCHAR_TYPE__ long int
> #define __SIZEOF_WCHAR_T__ 4

The above does not match what gcc 4.2.1 uses for __WCHAR_TYPE__ or what -m64 uses for either gcc version. Those use int, like FreeBSD does.

The long int use seems to be from following gcc-4.9.1/gcc/config/rs6000/sysv4.h’s conventions for powerpc (non-64) instead of following freebsd-’s wchar_t being int for both powerpc and powerpc64:

> $ /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc-4.9.1 -dM -E -m32 - < /dev/null | sort | grep _CALL_
> #define _CALL_SYSV 1

> $ /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc-4.9.1 -dM -E -m64 - < /dev/null | sort | grep _CALL_
> #define _CALL_AIX 1
> #define _CALL_AIXDESC 1
> #define _CALL_ELF 1

In other words: gcc 4.9.1’s freebsd64.h incorrectly assumes that the call standard to follow drives the choice of underlying wchar_t type for FreeBSD.

The libedit/Makefile uses -DWIDECHAR and libedit/chartype.h defines for that case:

> #define Char                    wchar_t
> . . .
> #define STR(x)                  L ## x


Note: I had WITHOUT_BOOT= for the experimental buildworld. WITH_BOOT= has both some powerpc Makefile.inc problems (needing to use -Wl, appropriately) and also there seems to be a lack of bindings for various _restgpr_<?>_x compiler support routines so boot1.elf fails to link. So I skipped that via WITHOUT_BOOT= so I could see what WITH_LIB32= would do.

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