From owner-freebsd-toolchain@FreeBSD.ORG Sat Apr 11 23:59:00 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3558448A for ; Sat, 11 Apr 2015 23:59:00 +0000 (UTC) Received: from asp.reflexion.net (outbound-242.asp.reflexion.net [69.84.129.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA6C699C for ; Sat, 11 Apr 2015 23:58:59 +0000 (UTC) Received: (qmail 31574 invoked from network); 11 Apr 2015 23:58:51 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 11 Apr 2015 23:58:51 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Sat, 11 Apr 2015 19:58:51 -0400 (EDT) Received: (qmail 22263 invoked from network); 11 Apr 2015 23:58:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Apr 2015 23:58:51 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id E3A151C43BC; Sat, 11 Apr 2015 16:58:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: gcc-4.9.1/gcc/config/rs6000/freebsd64.h vs. FreeBSD's powerpc (non-64) L"..." and wchar_t (other gcc ports too?) From: Mark Millard In-Reply-To: <5B228278-A967-46D4-8F56-08E47008D009@dsl-only.net> Date: Sat, 11 Apr 2015 16:58:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3734A273-6178-4AF5-B066-DEEB6CFC7F1C@dsl-only.net> References: <5B228278-A967-46D4-8F56-08E47008D009@dsl-only.net> To: freebsd-ports@freebsd.org, Warner Losh , Baptiste Daroussin X-Mailer: Apple Mail (2.2098) Cc: freebsd-toolchain@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2015 23:59:00 -0000 [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