Date: Sat, 11 Apr 2015 16:58:50 -0700 From: Mark Millard <markmi@dsl-only.net> To: freebsd-ports@freebsd.org, Warner Losh <imp@bsdimp.com>, Baptiste Daroussin <bapt@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: gcc-4.9.1/gcc/config/rs6000/freebsd64.h vs. FreeBSD's powerpc (non-64) L"..." and wchar_t (other gcc ports too?) Message-ID: <3734A273-6178-4AF5-B066-DEEB6CFC7F1C@dsl-only.net> In-Reply-To: <5B228278-A967-46D4-8F56-08E47008D009@dsl-only.net> References: <5B228278-A967-46D4-8F56-08E47008D009@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[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=3D for buildworld with =
powerpc64-xtoolchain-gcc's powerpc64-gcc port (on a powerpc64 box, using =
WITHOUT_BOOT=3D ) this leads to the following in libedit:
> . . . parse.c:181:25: error: array of inappropriate type initialized =
from string constant
> const Char hex[] =3D 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=E2=80=99s conventions for powerpc =
(non-64) instead of following freebsd-=E2=80=99s 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=E2=80=99s 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=3D for the experimental buildworld. WITH_BOOT=3D =
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=3D so I could see what WITH_LIB32=3D =
would do.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3734A273-6178-4AF5-B066-DEEB6CFC7F1C>