[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
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
