gcc-4.9.1/gcc/config/rs6000/freebsd64.h vs. FreeBSD's powerpc (non-64) L"..." and wchar_t (other gcc ports too?)
markmi at dsl-only.net
Sat Apr 11 23:59:00 UTC 2015
[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.]
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.
markmi at dsl-only.net
More information about the freebsd-ports