From owner-freebsd-ppc@freebsd.org Mon Jan 25 01:43:44 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 280617240 for ; Mon, 25 Jan 2016 01:43:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (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 DEC89667 for ; Mon, 25 Jan 2016 01:43:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15535 invoked from network); 25 Jan 2016 01:43:53 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 25 Jan 2016 01:43:53 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 24 Jan 2016 20:43:38 -0500 (EST) Received: (qmail 15213 invoked from network); 25 Jan 2016 01:43:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 25 Jan 2016 01:43:38 -0000 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-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C448F1C43ED; Sun, 24 Jan 2016 17:43:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: powerpc64-gcc unable to compile clang 3.8.0 from clang380-import -r294609 via buildworld [correction] From: Mark Millard In-Reply-To: <7B4DCD0C-8EE5-4A58-9A11-40C2C4570733@dsl-only.net> Date: Sun, 24 Jan 2016 17:43:40 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <67523280-9F20-4638-BF24-1BFAE8583805@dsl-only.net> <5B511209-F26D-4788-B80B-E0328963C263@FreeBSD.org> <582B67B0-25F4-40BE-A92F-D4818DCB9F97@dsl-only.net> <6BA37DD4-3F58-438B-B1E0-7312389B576D@dsl-only.net> <693CD1BD-6F32-47A5-B399-701219F5A6DA@FreeBSD.org> <7B4DCD0C-8EE5-4A58-9A11-40C2C4570733@dsl-only.net> To: Dimitry Andric X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 01:43:44 -0000 Looks like I screwed up by thinking that one of my tests had neither of = _LIBCPP_HAS_NO_TRAILING_RETURN nor _LIBCPP_HAS_NO_RVALUE_REFERENCES = defined when in fact _LIBCPP_HAS_NO_TRAILING_RETURN was still defined = (making _LIBCPP_HAS_NO_RVALUE_REFERENCES irrelevant). Other forms of checking if __GXX_EXPERIMENTAL_CXX0X__ is defined or not = when -std=3Dc++11 is used have all shown that it is defined for the g++ = vintages in question. (SOME_GCC_CMD -std=3Dc++11 -dM -E - < /dev/null = can not be used: an actual source code file name is required on the = command line to get an actual C++ compile even when -std=3Dc++11 is = specified. The - < /dev/null use reverts to a C compile with a message = about doing so.) So I'm running a buildworld to cross-check but I now expect that you = [Dimitry] are correct that my > -#ifndef __GXX_EXPERIMENTAL_CXX0X__ > +#if !defined(__GXX_EXPERIMENTAL_CXX0X__) && __cplusplus < 201103L was not and is not needed. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-24, at 12:39 PM, Mark Millard wrote: On 2016-Jan-24, at 9:20 AM, Dimitry Andric wrote: >=20 > On 24 Jan 2016, at 12:20, Mark Millard wrote: >>=20 >> My current trial powerpc64-gcc based buildworld is well past where it = stopped before (in a clang 3.8.0 part of the build). What I changed in = libc++ was just a little of __config: >=20 > It appears upstream has done approximately the same thing here: > http://llvm.org/viewvc/llvm-project?view=3Drevision&revision=3D255585 >=20 >=20 >> # svnlite diff /usr/src/contrib/libc++/include/__config >> Index: /usr/src/contrib/libc++/include/__config >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/contrib/libc++/include/__config (revision 294609) >> +++ /usr/src/contrib/libc++/include/__config (working copy) >> @@ -432,13 +432,15 @@ >> // No version of GCC supports relaxed constexpr rules >> #define _LIBCPP_HAS_NO_CXX14_CONSTEXPR >> // GCC 5 will support variable templates >> +#if !defined(__cpp_variable_templates) || __cpp_variable_templates < = 201304L >> #define _LIBCPP_HAS_NO_VARIABLE_TEMPLATES >> +#endif >>=20 >> #define _NOEXCEPT throw() >> #define _NOEXCEPT_(x) >> #define _NOEXCEPT_OR_FALSE(x) false >>=20 >> -#ifndef __GXX_EXPERIMENTAL_CXX0X__ >> +#if !defined(__GXX_EXPERIMENTAL_CXX0X__) && __cplusplus < 201103L >=20 > Except for this change. Why was this needed? -r255585 (and later) upstream still has (quoted extractions from file = showing more context): > #elif defined(__GNUC__) . . . > #define _NOEXCEPT throw() > #define _NOEXCEPT_(x) > #define _NOEXCEPT_OR_FALSE(x) false >=20 > #ifndef __GXX_EXPERIMENTAL_CXX0X__ >=20 > #define _LIBCPP_HAS_NO_ADVANCED_SFINAE > #define _LIBCPP_HAS_NO_DECLTYPE > #define _LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS > #define _LIBCPP_HAS_NO_DELETED_FUNCTIONS > #define _LIBCPP_HAS_NO_NULLPTR > #define _LIBCPP_HAS_NO_STATIC_ASSERT > #define _LIBCPP_HAS_NO_UNICODE_CHARS > #define _LIBCPP_HAS_NO_VARIADICS > #define _LIBCPP_HAS_NO_RVALUE_REFERENCES > #define _LIBCPP_HAS_NO_ALWAYS_INLINE_VARIADICS > #define _LIBCPP_HAS_NO_STRONG_ENUMS >=20 > #else // __GXX_EXPERIMENTAL_CXX0X__ . . . In modern times for -std=3Dc++11 this turns off the 11 or so features by = defining the 11 or so macros. This is because -std=3Dc++11 in = powerpc64-gcc is no longer classfied as experimental (experimental = before 5.1, not 5.1 and later if I what I read is correct). Those = disabled things are no longer experimental and = __GXX_EXPERIMENTAL_CXX0X__ no longer determines their status in = sufficiently modern g++'s. And it appears that clang/llvm is gradually doing things that add more = dependence on having enabled c++11 features, such as now getting the = error that I originally showed. Without such a __config change powerpc64-gcc will not compile the 3.8.0 = source: I tried before changing it. (_LIBCPP_HAS_NO_TRAILING_RETURN also = needs to not be defined to avoid the specific error that I showed. It is = not just _LIBCPP_HAS_NO_RVALUE_REFERENCES that matters.) I picked the __cplusplus version check based on using boost's = long-established version check (1.57.0-1.60.0 of boost) but using = 201103L makes sense from the language definition point of view as well. The specific error that I originally showed traced back to std::begin(. = . .) and std::end(. . .) getting old definitions because of the = conditional logic in that was engaged by 2 of the mistaken = disables overall (more quoted extractions, this time from ): . . . > #if !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && = !defined(_LIBCPP_HAS_NO_TRAILING_RETURN) . . . Modern std::begin and std::end definitions (and more) . . . > #else // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && = !defined(_LIBCPP_HAS_NO_TRAILING_RETURN) . . . Old std::begin and std::end definitions . . . > #endif // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && = !defined(_LIBCPP_HAS_NO_TRAILING_RETURN) . . . Other notes: It looks like -r255585 upstream also added to the logic for = _LIBCPP_HAS_NO_CONSTEXPR and has: > // constexpr was added to GCC in 4.6. > #if _GNUC_VER < 406 > #define _LIBCPP_HAS_NO_CONSTEXPR > // Can only use constexpr in c++11 mode. > #elif !defined(__GXX_EXPERIMENTAL_CXX0X__) && __cplusplus < 201103L > #define _LIBCPP_HAS_NO_CONSTEXPR > #endif that I did not that way. There are also versions: -r257707 2016-Jan-13 -r257629 2016-Jan-13 (marked as "Update version to 3.9") -r257422 2016-Jan-11 -r257368 2016-Jan-11 -r256652 2015-Dec-30 -r256325 2015-Dec-23 -r255868 2015-Dec-15 -r255683 2015-Dec-15 -r255585 2015-Dec-14 (the one that you identified) But I did not try to pick a point from this history of changes at all = and so may have missed other things that would be appropriate beyond the = issue that I was trying to address. I may well be the only one that cares if powerpc64-gcc (or analogous = ???-gcc's) can buildworld for clang380-import before it is merged into = 11.0-CURRENT. Since I've been able to rebuild (non-LIB32) I'm not stuck = if you leave things as they are for now. If __config is not changed now, I'll try to be a cross check on = remembering the issue later so that 11.0-CURRENT can continue to build = (non-LIB32) with powerpc64-gcc. (I do not have any hardware context for = other ???-gcc xtoolchain use but all should track powerpc64-gcc on the = issue as far as I know.) =3D=3D=3D Mark Millard markmi at dsl-only.net