From owner-freebsd-ppc@freebsd.org Sun Jan 24 06:17:35 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 5A51FA8FEB0 for ; Sun, 24 Jan 2016 06:17:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (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 1FC5D1EE9 for ; Sun, 24 Jan 2016 06:17:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22422 invoked from network); 24 Jan 2016 06:17:39 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Jan 2016 06:17:39 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 24 Jan 2016 01:17:31 -0500 (EST) Received: (qmail 17070 invoked from network); 24 Jan 2016 06:17:30 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 24 Jan 2016 06:17:30 -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 7C94BB1E002; Sat, 23 Jan 2016 22:17:21 -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 From: Mark Millard In-Reply-To: <5B511209-F26D-4788-B80B-E0328963C263@FreeBSD.org> Date: Sat, 23 Jan 2016 22:17:27 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <582B67B0-25F4-40BE-A92F-D4818DCB9F97@dsl-only.net> References: <67523280-9F20-4638-BF24-1BFAE8583805@dsl-only.net> <5B511209-F26D-4788-B80B-E0328963C263@FreeBSD.org> 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: Sun, 24 Jan 2016 06:17:35 -0000 I found a (the?) overall smoking gun: for powerpc64-gcc FreeBSD's = /projects/clang380-import/contrib/libc++/include/__config is doing (for = example): #define _LIBCPP_HAS_NO_RVALUE_REFERENCES (and other out of date classifications) for gcc5 vintages, and possibly = for gcc49 and others as well. This in turn means that other parts of libc++ are not providing modern = definitions that modern enough gcc5 variations handle fine. Instead = libc++ provides old definitions that are incorrect/incomplete for c++11 = and later (despite use of -std=3Dc++11 on the command line). clang++ gets the modern definitions from libc++. So: Not a gcc problem, a libc++ problem. In the code that got the initial error report that I showed = /projects/clang380-import/contrib/libc++/include/__config was using old = definitions of std::begin(. . .) and std::end(. . .) for powerpc64-gcc = and when the modern definitions are used instead under powerpc64-gcc the = matching error report disappears. Part of this may be that __config is still always expecting for g++ that = __GXX_EXPERIMENTAL_CXX0X__ is defined if nearly any of the modern c++11 = or later features exist at all. At this point various things are not = experimental any more and -std=3Dc++11 features likely are not = considered experimental any more in more recent gcc5 and later vintages. This __GXX_EXPERIMENTAL_CXX0X__ use is still true of __config at llvm's = /libcxx/tags/RELEASE_380/rc1/include/__config and at llvm's = /libcxx/trunk/include/__config too (head of trunk for the file). Looking at the most recent content of FreeBSD's = /projects/clang380-import/contrib/libc++/include/__config shows: . . . #elif defined(__GNUC__) . . . . . . // GCC 5 will support variable templates #define _LIBCPP_HAS_NO_VARIABLE_TEMPLATES . . . #ifndef __GXX_EXPERIMENTAL_CXX0X__ . . . #define _LIBCPP_HAS_NO_RVALUE_REFERENCES . . . #else // __GXX_EXPERIMENTAL_CXX0X__ . . . #if _GNUC_VER < 403 #define _LIBCPP_HAS_NO_RVALUE_REFERENCES #endif . . . _LIBCPP_HAS_NO_RVALUE_REFERENCES being defined in turn causes = /projects/clang380-import/contrib/libc++/include/iterator to define = things like std::begin(. . .) in an old way, such as the following that = was involved in the initial error report that I got: > #else // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && = !defined(_LIBCPP_HAS_NO_TRAILING_RETURN) >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::iterator > begin(_Cp& __c) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::const_iterator > begin(const _Cp& __c) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::iterator > end(_Cp& __c) > { > return __c.end(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::const_iterator > end(const _Cp& __c) > { > return __c.end(); > } Manually forced replacement with modern source: > template > inline _LIBCPP_INLINE_VISIBILITY > auto > begin(_Cp& __c) -> decltype(__c.begin()) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > begin(const _Cp& __c) -> decltype(__c.begin()) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > end(_Cp& __c) -> decltype(__c.end()) > { > return __c.end(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > end(const _Cp& __c) -> decltype(__c.end()) > { > return __c.end(); > } eliminated the specific initial error report. (It is not a sufficient = workaround to build clang as far as I know.) The following code extracted from libc++ and simplified from the llvm = code that got the initial error that I showed can be used to experiment = with the definitions of std::begin(. . .) and std:end(. . .) for = powerpc64-gcc vs. clang++ via commands like: > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -std=3Dc++11 = -I/usr/include/c++/v1/ func.cpp vs. > clang++ -std=3Dc++11 -stdlib=3Dlibc++ func.cpp with func.cpp being . . . (llvm's head-of-trunk iterator still has the same #if . . . #else . . . = #endif structure) > #include <__config> >=20 > _LIBCPP_BEGIN_NAMESPACE_STD >=20 > #if !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && = !defined(_LIBCPP_HAS_NO_TRAILING_RETURN) >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > begin(_Cp& __c) -> decltype(__c.begin()) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > begin(const _Cp& __c) -> decltype(__c.begin()) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > end(_Cp& __c) -> decltype(__c.end()) > { > return __c.end(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > end(const _Cp& __c) -> decltype(__c.end()) > { > return __c.end(); > } >=20 > #else // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && = !defined(_LIBCPP_HAS_NO_TRAILING_RETURN) >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::iterator > begin(_Cp& __c) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::const_iterator > begin(const _Cp& __c) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::iterator > end(_Cp& __c) > { > return __c.end(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::const_iterator > end(const _Cp& __c) > { > return __c.end(); > } >=20 > #endif // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && = !defined(_LIBCPP_HAS_NO_TRAILING_RETURN) >=20 > _LIBCPP_END_NAMESPACE_STD >=20 > namespace ns { > template > class iterator_range { > IteratorT begin_iterator, end_iterator; >=20 > public: > iterator_range(IteratorT begin_iterator, IteratorT end_iterator) > : begin_iterator(begin_iterator), > end_iterator(end_iterator) {} >=20 > IteratorT begin() const { return begin_iterator; } > IteratorT end() const { return end_iterator; } > }; >=20 > template iterator_range make_range(T x, T y) { > return iterator_range(x, y); > } >=20 > template > auto test( ContainerTy &&C > ) -> decltype(make_range(std::begin(C), > std::end(C))) { > return make_range(std::begin(C), > std::end(C)); > } > }; >=20 > typedef int *const init_const_ptr; > typedef int *const *init_const_iterator; >=20 > int v; > init_const_ptr cvp =3D &v; > init_const_iterator pcpv =3D &cvp; >=20 > typedef ns::iterator_range init_const_range; >=20 > void f(void) { > for (auto *I : ns::test(init_const_range(pcpv,pcpv+1))) { > } > } >=20 > int main(void) > { return 0; } Commenting out inside one branch of the #if . . . #else . . . #endif = makes very clear if that part was in use or the other part. Switching = compilers switches which part is used in my testing. It also appears that = /projects/clang380-import/contrib/libc++/include/__config has not been = tracking various 3.8.0 changes. For example llvm's Log of = /libcxx/tags/RELEASE_380/rc1/include/__config shows that its 2015-Dec-14 = -r255585 version changed the _LIBCPP_HAS_NO_VARIABLE_TEMPLATES source = that I quoted earlier to instead be: > // GCC 5 will support variable templates > #if !defined(__cpp_variable_templates) || __cpp_variable_templates < = 201304L > #define _LIBCPP_HAS_NO_VARIABLE_TEMPLATES > #endif (increasing the support for modern g++'s a little bit). llvm's /libcxx/tags/RELEASE_380/rc1/include/__config is currently at = -r258234 (2016-Jan-19) with about 8 checkins between the 2 versions. Looking up /projects/clang380-import/contrib/libc++/include/iterator and = others show they date back being copies made on 2015-Dec-30 of vintages = from FreeBSD's 2015-Oct 3.7.0 materials as well. (For some files that = may well be current for all I know.) For all I know this status is deliberate for some reason. But it would = seem that to expect modern gcc vintages to be supported well for modern = libc++ uses probably has a necessary (but not sufficient) aspect of = tracking llvm's updates that add handling of more modern gcc vintages. Side note: One revision in llvm's /libcxx/tags/RELEASE_380/rc1/include/ that I ran = into that might be of note: -r257716 from 2016-Jan-13 says > Fix PR#25973 : 'basic_string::assign(InputIt, InputIt) doesn't provide = the strong exception safety guarantee'. This turned out to be a = pervasive problem in , which required a fair amount of rework. = Add in an optimization for when iterators provide noexcept = increment/comparison/assignment/dereference (which covers many of the = iterators in libc++). =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-23, at 7:08 AM, Dimitry Andric wrote: On 23 Jan 2016, at 12:25, Mark Millard wrote: >=20 > I tried a buildworld that included building clang and lldb based on = using powerpc64-xtoolchain-gcc/powerpc64-gcc as a cross compiler. It = failed, see below. This might indicate a more general gcc 5.x vs. clang = 3.8.0 source code mismatch. This was my first try. This could have been = true for some time. >=20 > --- CFG.o --- > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -isystem = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib = --sysroot=3D/usr/obj/xtoolchain/powerpc.po > werpc64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ = -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1 = -std=3Dgnu++11 = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/../lib/libc++ = --sysroot=3D/usr > /obj/xtoolchain/powerpc.powerpc64/usr/src/tmp = -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe = -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include = -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm > /tools/clang/include = -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/li= b/Analysis -I. = -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/../../lib/clan= g/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT = -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"powerpc64-unknown-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"powerpc64 > -unknown-freebsd11.0\" -DDEFAULT_SYSROOT=3D\"\" -MD -MP = -MF.depend.CFG.o -MTCFG.o -fstack-protector-strong = -Wno-error=3Dunused-function -Wno-error=3Denum-compare = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno- > error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered = -Wno-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes = -Wno-error=3Dinline -Wno-error=3Dunused-but-set-variable = -Wno-error=3Dunused-value -Wno-error=3Dstrict > -aliasing -Wno-error=3Daddress -std=3Dc++11 -fno-exceptions -fno-rtti = -c = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/= Analysis/CFG.cpp -o CFG.o > . . . > --- all_subdir_libclanganalysis --- > = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/= Analysis/CFG.cpp: In member function 'std::__1::unique_ptr = {anonymous}::CFGBuilder::buildCFG(const clang::Decl*, clang::Stmt*)': > = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/= Analysis/CFG.cpp:1046:45: error: no matching function for call to = 'reverse(clang::CXXConstructorDecl::init_const_range)' > for (auto *I : llvm::reverse(CD->inits())) { > ^ I just tried building clang 3.8.0 with gcc 5.3.0, but that went fine. However, by default gcc uses its own copy of libstdc++. The above error is most likely something caused by libc++ and gcc not playing well together. This kind of error is always hard to report upstream, since the gcc maintainers obviously do not care that much about libc++, while the libc++ maintainers do not care that much about gcc. :-) -Dimitry From owner-freebsd-ppc@freebsd.org Sun Jan 24 07:05:03 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 4D395A8EE04 for ; Sun, 24 Jan 2016 07:05:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (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 12AB413D2 for ; Sun, 24 Jan 2016 07:05:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20696 invoked from network); 24 Jan 2016 07:05:00 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 24 Jan 2016 07:05:00 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 24 Jan 2016 02:04:57 -0500 (EST) Received: (qmail 29431 invoked from network); 24 Jan 2016 07:04:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 24 Jan 2016 07:04:57 -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 1C122B1E001; Sat, 23 Jan 2016 23:04:54 -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 From: Mark Millard In-Reply-To: <582B67B0-25F4-40BE-A92F-D4818DCB9F97@dsl-only.net> Date: Sat, 23 Jan 2016 23:05:00 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain 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> 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: Sun, 24 Jan 2016 07:05:03 -0000 Modern boost (1.60.0) deals with the __GXX_EXPERIMENTAL_CXX0X__ = (-std=3Dc++0x) vs. -std=3Dc++11 issue this way in its = config/compiler/gcc.hpp : > #if defined(__GXX_EXPERIMENTAL_CXX0X__) || (__cplusplus >=3D 201103L) > # define BOOST_GCC_CXX11 > #endif then later checking BOOST_GCC_CXX11 (and other things) as needed instead = of directly testing __GXX_EXPERIMENTAL_CXX0X__ in those places.=20 This started in boost 1.57.0 (2014-Nov-3) when the then-most-recent gcc = "primary test compilers" for C++ language vintages were all gcc 4.9.1 = and the most recent for "additional test compilers" for GCC C++11/14 = were also 4.9.1 --other than Linux where "5.0 (experimental)" is listed = in the release notes but not for GCC with C++11/14. Should libc++ should be doing something similar that takes into account = when C++xy features are no longer experimental in g++? =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-23, at 10:17 PM, Mark Millard = wrote: I found a (the?) overall smoking gun: for powerpc64-gcc FreeBSD's = /projects/clang380-import/contrib/libc++/include/__config is doing (for = example): #define _LIBCPP_HAS_NO_RVALUE_REFERENCES (and other out of date classifications) for gcc5 vintages, and possibly = for gcc49 and others as well. This in turn means that other parts of libc++ are not providing modern = definitions that modern enough gcc5 variations handle fine. Instead = libc++ provides old definitions that are incorrect/incomplete for c++11 = and later (despite use of -std=3Dc++11 on the command line). clang++ gets the modern definitions from libc++. So: Not a gcc problem, a libc++ problem. In the code that got the initial error report that I showed = /projects/clang380-import/contrib/libc++/include/__config was using old = definitions of std::begin(. . .) and std::end(. . .) for powerpc64-gcc = and when the modern definitions are used instead under powerpc64-gcc the = matching error report disappears. Part of this may be that __config is still always expecting for g++ that = __GXX_EXPERIMENTAL_CXX0X__ is defined if nearly any of the modern c++11 = or later features exist at all. At this point various things are not = experimental any more and -std=3Dc++11 features likely are not = considered experimental any more in more recent gcc5 and later vintages. This __GXX_EXPERIMENTAL_CXX0X__ use is still true of __config at llvm's = /libcxx/tags/RELEASE_380/rc1/include/__config and at llvm's = /libcxx/trunk/include/__config too (head of trunk for the file). Looking at the most recent content of FreeBSD's = /projects/clang380-import/contrib/libc++/include/__config shows: . . . #elif defined(__GNUC__) . . . . . . // GCC 5 will support variable templates #define _LIBCPP_HAS_NO_VARIABLE_TEMPLATES . . . #ifndef __GXX_EXPERIMENTAL_CXX0X__ . . . #define _LIBCPP_HAS_NO_RVALUE_REFERENCES . . . #else // __GXX_EXPERIMENTAL_CXX0X__ . . . #if _GNUC_VER < 403 #define _LIBCPP_HAS_NO_RVALUE_REFERENCES #endif . . . _LIBCPP_HAS_NO_RVALUE_REFERENCES being defined in turn causes = /projects/clang380-import/contrib/libc++/include/iterator to define = things like std::begin(. . .) in an old way, such as the following that = was involved in the initial error report that I got: > #else // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && = !defined(_LIBCPP_HAS_NO_TRAILING_RETURN) >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::iterator > begin(_Cp& __c) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::const_iterator > begin(const _Cp& __c) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::iterator > end(_Cp& __c) > { > return __c.end(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::const_iterator > end(const _Cp& __c) > { > return __c.end(); > } Manually forced replacement with modern source: > template > inline _LIBCPP_INLINE_VISIBILITY > auto > begin(_Cp& __c) -> decltype(__c.begin()) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > begin(const _Cp& __c) -> decltype(__c.begin()) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > end(_Cp& __c) -> decltype(__c.end()) > { > return __c.end(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > end(const _Cp& __c) -> decltype(__c.end()) > { > return __c.end(); > } eliminated the specific initial error report. (It is not a sufficient = workaround to build clang as far as I know.) The following code extracted from libc++ and simplified from the llvm = code that got the initial error that I showed can be used to experiment = with the definitions of std::begin(. . .) and std:end(. . .) for = powerpc64-gcc vs. clang++ via commands like: > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -std=3Dc++11 = -I/usr/include/c++/v1/ func.cpp vs. > clang++ -std=3Dc++11 -stdlib=3Dlibc++ func.cpp with func.cpp being . . . (llvm's head-of-trunk iterator still has the same #if . . . #else . . . = #endif structure) > #include <__config> >=20 > _LIBCPP_BEGIN_NAMESPACE_STD >=20 > #if !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && = !defined(_LIBCPP_HAS_NO_TRAILING_RETURN) >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > begin(_Cp& __c) -> decltype(__c.begin()) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > begin(const _Cp& __c) -> decltype(__c.begin()) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > end(_Cp& __c) -> decltype(__c.end()) > { > return __c.end(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > end(const _Cp& __c) -> decltype(__c.end()) > { > return __c.end(); > } >=20 > #else // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && = !defined(_LIBCPP_HAS_NO_TRAILING_RETURN) >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::iterator > begin(_Cp& __c) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::const_iterator > begin(const _Cp& __c) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::iterator > end(_Cp& __c) > { > return __c.end(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::const_iterator > end(const _Cp& __c) > { > return __c.end(); > } >=20 > #endif // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && = !defined(_LIBCPP_HAS_NO_TRAILING_RETURN) >=20 > _LIBCPP_END_NAMESPACE_STD >=20 > namespace ns { > template > class iterator_range { > IteratorT begin_iterator, end_iterator; >=20 > public: > iterator_range(IteratorT begin_iterator, IteratorT end_iterator) > : begin_iterator(begin_iterator), > end_iterator(end_iterator) {} >=20 > IteratorT begin() const { return begin_iterator; } > IteratorT end() const { return end_iterator; } > }; >=20 > template iterator_range make_range(T x, T y) { > return iterator_range(x, y); > } >=20 > template > auto test( ContainerTy &&C > ) -> decltype(make_range(std::begin(C), > std::end(C))) { > return make_range(std::begin(C), > std::end(C)); > } > }; >=20 > typedef int *const init_const_ptr; > typedef int *const *init_const_iterator; >=20 > int v; > init_const_ptr cvp =3D &v; > init_const_iterator pcpv =3D &cvp; >=20 > typedef ns::iterator_range init_const_range; >=20 > void f(void) { > for (auto *I : ns::test(init_const_range(pcpv,pcpv+1))) { > } > } >=20 > int main(void) > { return 0; } Commenting out inside one branch of the #if . . . #else . . . #endif = makes very clear if that part was in use or the other part. Switching = compilers switches which part is used in my testing. It also appears that = /projects/clang380-import/contrib/libc++/include/__config has not been = tracking various 3.8.0 changes. For example llvm's Log of = /libcxx/tags/RELEASE_380/rc1/include/__config shows that its 2015-Dec-14 = -r255585 version changed the _LIBCPP_HAS_NO_VARIABLE_TEMPLATES source = that I quoted earlier to instead be: > // GCC 5 will support variable templates > #if !defined(__cpp_variable_templates) || __cpp_variable_templates < = 201304L > #define _LIBCPP_HAS_NO_VARIABLE_TEMPLATES > #endif (increasing the support for modern g++'s a little bit). llvm's /libcxx/tags/RELEASE_380/rc1/include/__config is currently at = -r258234 (2016-Jan-19) with about 8 checkins between the 2 versions. Looking up /projects/clang380-import/contrib/libc++/include/iterator and = others show they date back being copies made on 2015-Dec-30 of vintages = from FreeBSD's 2015-Oct 3.7.0 materials as well. (For some files that = may well be current for all I know.) For all I know this status is deliberate for some reason. But it would = seem that to expect modern gcc vintages to be supported well for modern = libc++ uses probably has a necessary (but not sufficient) aspect of = tracking llvm's updates that add handling of more modern gcc vintages. Side note: One revision in llvm's /libcxx/tags/RELEASE_380/rc1/include/ that I ran = into that might be of note: -r257716 from 2016-Jan-13 says > Fix PR#25973 : 'basic_string::assign(InputIt, InputIt) doesn't provide = the strong exception safety guarantee'. This turned out to be a = pervasive problem in , which required a fair amount of rework. = Add in an optimization for when iterators provide noexcept = increment/comparison/assignment/dereference (which covers many of the = iterators in libc++). =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-23, at 7:08 AM, Dimitry Andric wrote: On 23 Jan 2016, at 12:25, Mark Millard wrote: >=20 > I tried a buildworld that included building clang and lldb based on = using powerpc64-xtoolchain-gcc/powerpc64-gcc as a cross compiler. It = failed, see below. This might indicate a more general gcc 5.x vs. clang = 3.8.0 source code mismatch. This was my first try. This could have been = true for some time. >=20 > --- CFG.o --- > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -isystem = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib = --sysroot=3D/usr/obj/xtoolchain/powerpc.po > werpc64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ = -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1 = -std=3Dgnu++11 = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/../lib/libc++ = --sysroot=3D/usr > /obj/xtoolchain/powerpc.powerpc64/usr/src/tmp = -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe = -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include = -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm > /tools/clang/include = -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/li= b/Analysis -I. = -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/../../lib/clan= g/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT = -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"powerpc64-unknown-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"powerpc64 > -unknown-freebsd11.0\" -DDEFAULT_SYSROOT=3D\"\" -MD -MP = -MF.depend.CFG.o -MTCFG.o -fstack-protector-strong = -Wno-error=3Dunused-function -Wno-error=3Denum-compare = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno- > error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered = -Wno-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes = -Wno-error=3Dinline -Wno-error=3Dunused-but-set-variable = -Wno-error=3Dunused-value -Wno-error=3Dstrict > -aliasing -Wno-error=3Daddress -std=3Dc++11 -fno-exceptions -fno-rtti = -c = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/= Analysis/CFG.cpp -o CFG.o > . . . > --- all_subdir_libclanganalysis --- > = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/= Analysis/CFG.cpp: In member function 'std::__1::unique_ptr = {anonymous}::CFGBuilder::buildCFG(const clang::Decl*, clang::Stmt*)': > = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/= Analysis/CFG.cpp:1046:45: error: no matching function for call to = 'reverse(clang::CXXConstructorDecl::init_const_range)' > for (auto *I : llvm::reverse(CD->inits())) { > ^ I just tried building clang 3.8.0 with gcc 5.3.0, but that went fine. However, by default gcc uses its own copy of libstdc++. The above error is most likely something caused by libc++ and gcc not playing well together. This kind of error is always hard to report upstream, since the gcc maintainers obviously do not care that much about libc++, while the libc++ maintainers do not care that much about gcc. :-) -Dimitry From owner-freebsd-ppc@freebsd.org Sun Jan 24 11:20:33 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 C991D759B for ; Sun, 24 Jan 2016 11:20:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (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 8464F3D6 for ; Sun, 24 Jan 2016 11:20:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9727 invoked from network); 24 Jan 2016 11:20:43 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 24 Jan 2016 11:20:43 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 24 Jan 2016 06:20:35 -0500 (EST) Received: (qmail 12272 invoked from network); 24 Jan 2016 11:20:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 24 Jan 2016 11:20:34 -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 F1385B1E001; Sun, 24 Jan 2016 03:20:29 -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 From: Mark Millard In-Reply-To: Date: Sun, 24 Jan 2016 03:20:30 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <6BA37DD4-3F58-438B-B1E0-7312389B576D@dsl-only.net> References: <67523280-9F20-4638-BF24-1BFAE8583805@dsl-only.net> <5B511209-F26D-4788-B80B-E0328963C263@FreeBSD.org> <582B67B0-25F4-40BE-A92F-D4818DCB9F97@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: Sun, 24 Jan 2016 11:20:33 -0000 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: # svnlite diff /usr/src/contrib/libc++/include/__config=20 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 #define _NOEXCEPT throw() #define _NOEXCEPT_(x) #define _NOEXCEPT_OR_FALSE(x) false -#ifndef __GXX_EXPERIMENTAL_CXX0X__ +#if !defined(__GXX_EXPERIMENTAL_CXX0X__) && __cplusplus < 201103L #define _LIBCPP_HAS_NO_ADVANCED_SFINAE #define _LIBCPP_HAS_NO_DECLTYPE @@ -454,7 +456,10 @@ #else // __GXX_EXPERIMENTAL_CXX0X__ +#if _GNUC_VER < 404 #define _LIBCPP_HAS_NO_TRAILING_RETURN +#endif + #define _LIBCPP_HAS_NO_ALWAYS_INLINE_VARIADICS #if _GNUC_VER < 403 The _LIBCPP_HAS_NO_TRAILING_RETURN part also contributed to the specific = initial error that I showed, not just _LIBCPP_HAS_NO_RVALUE_REFERENCES: = both need to be undefined to allow teh modern/complete std::begin(. . = .) and std::end(. . .) definitions. But the above does far more than = avoid disabling just those two things --and I expect that such is = required otherwise more stopping points would be found. I included the more modern _LIBCPP_HAS_NO_VARIABLE_TEMPLATES logic that = I referenced earlier as already being in llvm's svn. Side note: I did find one reference indicating that = _LIBCPP_HAS_NO_ALWAYS_INLINE_VARIADICS is unused as of early 2013 --but = still defined. I also found a 2015-Dec-15 -r255686 that removed all its = defines from __config. But I left it alone for this workaround. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-23, at 11:05 PM, Mark Millard wrote: Modern boost (1.60.0) deals with the __GXX_EXPERIMENTAL_CXX0X__ = (-std=3Dc++0x) vs. -std=3Dc++11 issue this way in its = config/compiler/gcc.hpp : > #if defined(__GXX_EXPERIMENTAL_CXX0X__) || (__cplusplus >=3D 201103L) > # define BOOST_GCC_CXX11 > #endif then later checking BOOST_GCC_CXX11 (and other things) as needed instead = of directly testing __GXX_EXPERIMENTAL_CXX0X__ in those places.=20 This started in boost 1.57.0 (2014-Nov-3) when the then-most-recent gcc = "primary test compilers" for C++ language vintages were all gcc 4.9.1 = and the most recent for "additional test compilers" for GCC C++11/14 = were also 4.9.1 --other than Linux where "5.0 (experimental)" is listed = in the release notes but not for GCC with C++11/14. Should libc++ should be doing something similar that takes into account = when C++xy features are no longer experimental in g++? =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-23, at 10:17 PM, Mark Millard = wrote: I found a (the?) overall smoking gun: for powerpc64-gcc FreeBSD's = /projects/clang380-import/contrib/libc++/include/__config is doing (for = example): #define _LIBCPP_HAS_NO_RVALUE_REFERENCES (and other out of date classifications) for gcc5 vintages, and possibly = for gcc49 and others as well. This in turn means that other parts of libc++ are not providing modern = definitions that modern enough gcc5 variations handle fine. Instead = libc++ provides old definitions that are incorrect/incomplete for c++11 = and later (despite use of -std=3Dc++11 on the command line). clang++ gets the modern definitions from libc++. So: Not a gcc problem, a libc++ problem. In the code that got the initial error report that I showed = /projects/clang380-import/contrib/libc++/include/__config was using old = definitions of std::begin(. . .) and std::end(. . .) for powerpc64-gcc = and when the modern definitions are used instead under powerpc64-gcc the = matching error report disappears. Part of this may be that __config is still always expecting for g++ that = __GXX_EXPERIMENTAL_CXX0X__ is defined if nearly any of the modern c++11 = or later features exist at all. At this point various things are not = experimental any more and -std=3Dc++11 features likely are not = considered experimental any more in more recent gcc5 and later vintages. This __GXX_EXPERIMENTAL_CXX0X__ use is still true of __config at llvm's = /libcxx/tags/RELEASE_380/rc1/include/__config and at llvm's = /libcxx/trunk/include/__config too (head of trunk for the file). Looking at the most recent content of FreeBSD's = /projects/clang380-import/contrib/libc++/include/__config shows: . . . #elif defined(__GNUC__) . . . . . . // GCC 5 will support variable templates #define _LIBCPP_HAS_NO_VARIABLE_TEMPLATES . . . #ifndef __GXX_EXPERIMENTAL_CXX0X__ . . . #define _LIBCPP_HAS_NO_RVALUE_REFERENCES . . . #else // __GXX_EXPERIMENTAL_CXX0X__ . . . #if _GNUC_VER < 403 #define _LIBCPP_HAS_NO_RVALUE_REFERENCES #endif . . . _LIBCPP_HAS_NO_RVALUE_REFERENCES being defined in turn causes = /projects/clang380-import/contrib/libc++/include/iterator to define = things like std::begin(. . .) in an old way, such as the following that = was involved in the initial error report that I got: > #else // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && = !defined(_LIBCPP_HAS_NO_TRAILING_RETURN) >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::iterator > begin(_Cp& __c) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::const_iterator > begin(const _Cp& __c) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::iterator > end(_Cp& __c) > { > return __c.end(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::const_iterator > end(const _Cp& __c) > { > return __c.end(); > } Manually forced replacement with modern source: > template > inline _LIBCPP_INLINE_VISIBILITY > auto > begin(_Cp& __c) -> decltype(__c.begin()) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > begin(const _Cp& __c) -> decltype(__c.begin()) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > end(_Cp& __c) -> decltype(__c.end()) > { > return __c.end(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > end(const _Cp& __c) -> decltype(__c.end()) > { > return __c.end(); > } eliminated the specific initial error report. (It is not a sufficient = workaround to build clang as far as I know.) The following code extracted from libc++ and simplified from the llvm = code that got the initial error that I showed can be used to experiment = with the definitions of std::begin(. . .) and std:end(. . .) for = powerpc64-gcc vs. clang++ via commands like: > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -std=3Dc++11 = -I/usr/include/c++/v1/ func.cpp vs. > clang++ -std=3Dc++11 -stdlib=3Dlibc++ func.cpp with func.cpp being . . . (llvm's head-of-trunk iterator still has the same #if . . . #else . . . = #endif structure) > #include <__config> >=20 > _LIBCPP_BEGIN_NAMESPACE_STD >=20 > #if !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && = !defined(_LIBCPP_HAS_NO_TRAILING_RETURN) >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > begin(_Cp& __c) -> decltype(__c.begin()) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > begin(const _Cp& __c) -> decltype(__c.begin()) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > end(_Cp& __c) -> decltype(__c.end()) > { > return __c.end(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > auto > end(const _Cp& __c) -> decltype(__c.end()) > { > return __c.end(); > } >=20 > #else // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && = !defined(_LIBCPP_HAS_NO_TRAILING_RETURN) >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::iterator > begin(_Cp& __c) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::const_iterator > begin(const _Cp& __c) > { > return __c.begin(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::iterator > end(_Cp& __c) > { > return __c.end(); > } >=20 > template > inline _LIBCPP_INLINE_VISIBILITY > typename _Cp::const_iterator > end(const _Cp& __c) > { > return __c.end(); > } >=20 > #endif // !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) && = !defined(_LIBCPP_HAS_NO_TRAILING_RETURN) >=20 > _LIBCPP_END_NAMESPACE_STD >=20 > namespace ns { > template > class iterator_range { > IteratorT begin_iterator, end_iterator; >=20 > public: > iterator_range(IteratorT begin_iterator, IteratorT end_iterator) > : begin_iterator(begin_iterator), > end_iterator(end_iterator) {} >=20 > IteratorT begin() const { return begin_iterator; } > IteratorT end() const { return end_iterator; } > }; >=20 > template iterator_range make_range(T x, T y) { > return iterator_range(x, y); > } >=20 > template > auto test( ContainerTy &&C > ) -> decltype(make_range(std::begin(C), > std::end(C))) { > return make_range(std::begin(C), > std::end(C)); > } > }; >=20 > typedef int *const init_const_ptr; > typedef int *const *init_const_iterator; >=20 > int v; > init_const_ptr cvp =3D &v; > init_const_iterator pcpv =3D &cvp; >=20 > typedef ns::iterator_range init_const_range; >=20 > void f(void) { > for (auto *I : ns::test(init_const_range(pcpv,pcpv+1))) { > } > } >=20 > int main(void) > { return 0; } Commenting out inside one branch of the #if . . . #else . . . #endif = makes very clear if that part was in use or the other part. Switching = compilers switches which part is used in my testing. It also appears that = /projects/clang380-import/contrib/libc++/include/__config has not been = tracking various 3.8.0 changes. For example llvm's Log of = /libcxx/tags/RELEASE_380/rc1/include/__config shows that its 2015-Dec-14 = -r255585 version changed the _LIBCPP_HAS_NO_VARIABLE_TEMPLATES source = that I quoted earlier to instead be: > // GCC 5 will support variable templates > #if !defined(__cpp_variable_templates) || __cpp_variable_templates < = 201304L > #define _LIBCPP_HAS_NO_VARIABLE_TEMPLATES > #endif (increasing the support for modern g++'s a little bit). llvm's /libcxx/tags/RELEASE_380/rc1/include/__config is currently at = -r258234 (2016-Jan-19) with about 8 checkins between the 2 versions. Looking up /projects/clang380-import/contrib/libc++/include/iterator and = others show they date back being copies made on 2015-Dec-30 of vintages = from FreeBSD's 2015-Oct 3.7.0 materials as well. (For some files that = may well be current for all I know.) For all I know this status is deliberate for some reason. But it would = seem that to expect modern gcc vintages to be supported well for modern = libc++ uses probably has a necessary (but not sufficient) aspect of = tracking llvm's updates that add handling of more modern gcc vintages. Side note: One revision in llvm's /libcxx/tags/RELEASE_380/rc1/include/ that I ran = into that might be of note: -r257716 from 2016-Jan-13 says > Fix PR#25973 : 'basic_string::assign(InputIt, InputIt) doesn't provide = the strong exception safety guarantee'. This turned out to be a = pervasive problem in , which required a fair amount of rework. = Add in an optimization for when iterators provide noexcept = increment/comparison/assignment/dereference (which covers many of the = iterators in libc++). =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-23, at 7:08 AM, Dimitry Andric wrote: On 23 Jan 2016, at 12:25, Mark Millard wrote: >=20 > I tried a buildworld that included building clang and lldb based on = using powerpc64-xtoolchain-gcc/powerpc64-gcc as a cross compiler. It = failed, see below. This might indicate a more general gcc 5.x vs. clang = 3.8.0 source code mismatch. This was my first try. This could have been = true for some time. >=20 > --- CFG.o --- > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -isystem = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib = --sysroot=3D/usr/obj/xtoolchain/powerpc.po > werpc64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ = -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1 = -std=3Dgnu++11 = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/../lib/libc++ = --sysroot=3D/usr > /obj/xtoolchain/powerpc.powerpc64/usr/src/tmp = -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe = -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include = -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm > /tools/clang/include = -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/li= b/Analysis -I. = -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/../../lib/clan= g/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS = -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT = -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"powerpc64-unknown-freebsd11.0\" = -DLLVM_HOST_TRIPLE=3D\"powerpc64 > -unknown-freebsd11.0\" -DDEFAULT_SYSROOT=3D\"\" -MD -MP = -MF.depend.CFG.o -MTCFG.o -fstack-protector-strong = -Wno-error=3Dunused-function -Wno-error=3Denum-compare = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare -Wno- > error=3Duninitialized -Wno-error=3Darray-bounds -Wno-error=3Dclobbered = -Wno-error=3Dcast-align -Wno-error=3Dextra -Wno-error=3Dattributes = -Wno-error=3Dinline -Wno-error=3Dunused-but-set-variable = -Wno-error=3Dunused-value -Wno-error=3Dstrict > -aliasing -Wno-error=3Daddress -std=3Dc++11 -fno-exceptions -fno-rtti = -c = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/= Analysis/CFG.cpp -o CFG.o > . . . > --- all_subdir_libclanganalysis --- > = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/= Analysis/CFG.cpp: In member function 'std::__1::unique_ptr = {anonymous}::CFGBuilder::buildCFG(const clang::Decl*, clang::Stmt*)': > = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/= Analysis/CFG.cpp:1046:45: error: no matching function for call to = 'reverse(clang::CXXConstructorDecl::init_const_range)' > for (auto *I : llvm::reverse(CD->inits())) { > ^ I just tried building clang 3.8.0 with gcc 5.3.0, but that went fine. However, by default gcc uses its own copy of libstdc++. The above error is most likely something caused by libc++ and gcc not playing well together. This kind of error is always hard to report upstream, since the gcc maintainers obviously do not care that much about libc++, while the libc++ maintainers do not care that much about gcc. :-) -Dimitry From owner-freebsd-ppc@freebsd.org Sun Jan 24 17:20:43 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 C91B6A1D919; Sun, 24 Jan 2016 17:20:43 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8BAD7272; Sun, 24 Jan 2016 17:20:43 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::b004:16cd:40ee:ae68] (unknown [IPv6:2001:7b8:3a7:0:b004:16cd:40ee:ae68]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B1CCA3CA64; Sun, 24 Jan 2016 18:20:39 +0100 (CET) Subject: Re: powerpc64-gcc unable to compile clang 3.8.0 from clang380-import -r294609 via buildworld Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_474CEA44-0CCD-4425-AA4F-6B71D1585302"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <6BA37DD4-3F58-438B-B1E0-7312389B576D@dsl-only.net> Date: Sun, 24 Jan 2016 18:20:32 +0100 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Message-Id: <693CD1BD-6F32-47A5-B399-701219F5A6DA@FreeBSD.org> 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> To: Mark Millard X-Mailer: Apple Mail (2.3112) 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: Sun, 24 Jan 2016 17:20:44 -0000 --Apple-Mail=_474CEA44-0CCD-4425-AA4F-6B71D1585302 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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: It appears upstream has done approximately the same thing here: http://llvm.org/viewvc/llvm-project?view=3Drevision&revision=3D255585 > # 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 Except for this change. Why was this needed? >=20 > #define _LIBCPP_HAS_NO_ADVANCED_SFINAE > #define _LIBCPP_HAS_NO_DECLTYPE > @@ -454,7 +456,10 @@ >=20 > #else // __GXX_EXPERIMENTAL_CXX0X__ >=20 > +#if _GNUC_VER < 404 > #define _LIBCPP_HAS_NO_TRAILING_RETURN > +#endif > + > #define _LIBCPP_HAS_NO_ALWAYS_INLINE_VARIADICS Upstream put this in a different part, but semantically it means the same. Eventually I will just import a newer libc++ snapshot wholesale, or when the 3.8.0 version is released, but as I have enough on my plate for now, I will postpone it until clang 3.8.0 hits head. -Dimitry --Apple-Mail=_474CEA44-0CCD-4425-AA4F-6B71D1585302 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlalB+cACgkQsF6jCi4glqMKEQCgz9uxLIGfbWi5+fiDpAUm1u7t x+IAoJ8jbVs/78NVJKlzk5LB6wcEHPBp =drFM -----END PGP SIGNATURE----- --Apple-Mail=_474CEA44-0CCD-4425-AA4F-6B71D1585302-- From owner-freebsd-ppc@freebsd.org Sun Jan 24 20:40:01 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 9B9717119 for ; Sun, 24 Jan 2016 20:40:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (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 58D5010AC for ; Sun, 24 Jan 2016 20:40:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7208 invoked from network); 24 Jan 2016 20:40:11 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Jan 2016 20:40:11 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 24 Jan 2016 15:40:02 -0500 (EST) Received: (qmail 18165 invoked from network); 24 Jan 2016 20:40:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 24 Jan 2016 20:40:02 -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 586C41C43AE; Sun, 24 Jan 2016 12:39:55 -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 From: Mark Millard In-Reply-To: <693CD1BD-6F32-47A5-B399-701219F5A6DA@FreeBSD.org> Date: Sun, 24 Jan 2016 12:39:58 -0800 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <7B4DCD0C-8EE5-4A58-9A11-40C2C4570733@dsl-only.net> 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> 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: Sun, 24 Jan 2016 20:40:01 -0000 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 From owner-freebsd-ppc@freebsd.org Mon Jan 25 01:00:11 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 F093AA31340 for ; Mon, 25 Jan 2016 01:00:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (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 A7BE4616 for ; Mon, 25 Jan 2016 01:00:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10719 invoked from network); 25 Jan 2016 01:00:08 -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:00:08 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 24 Jan 2016 20:00:06 -0500 (EST) Received: (qmail 4867 invoked from network); 25 Jan 2016 01:00:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 25 Jan 2016 01:00:05 -0000 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 6E5021C43AE; Sun, 24 Jan 2016 17:00:04 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Bug 206588: devel/powerpc64-gcc on amd64 defines _LITTLE_ENDIAN, __NO_STRICT_ALIGNMENT, etc. Message-Id: <4C4E36E4-AE8C-4409-826A-4C4BE4980F00@dsl-only.net> Date: Sun, 24 Jan 2016 17:00:08 -0800 To: FreeBSD PowerPC ML , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) 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:00:12 -0000 I've submitted Bug 206588 from which the below is quoted (but is not all = the text). First I list my later comment then the beginning of the = description. > This is likely more an issue of not having a proper set of headers to = use with powerpc64-gcc when cross compiling from other architectures, = such as little endian ones. >=20 > It is still a cross compiler usage difficulty that is not handled or = documented. > I used the following program and compiler command line options to dump = macro definitions from devel/powerpc64-gcc and discovered some nasty = ones: LITTLE_ENDIAN usage on amd64 despite targeting a big endian = powerpc64. Differing __NO_STRICT_ALIGNMENT status and = __GCC_HAVE_DWARF2_CFI_ASM status as well. The details follow. >=20 > # more with_libc++__config.cpp=20 > #include <__config> > int main(void) > { return 0; } >=20 > used via: >=20 > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -std=3Dc++11 = -I/usr/include -I/usr/include/c++/v1/ -dM -E func.cpp | sort > = ~/powerpc64-gcc_52_macros.txt >=20 > on a native powerpc64 (Powermac G5) context and on a amd64 context = (inside Virtual Box on Mac OS X). The "<"'s below are from the G5 = context and the ">" below are from the amd64 context. >=20 > There is also a related __NO_STRICT_ALIGNMENT difference and a = __GCC_HAVE_DWARF2_CFI_ASM difference. >=20 > # diff /media/root/powerpc64_gcc_52_macros.txt = ~/powerpc64_gcc_52_macros.txt | more > 16c16 > < #define _BYTE_ORDER _BIG_ENDIAN > --- >=20 > > #define _BYTE_ORDER _LITTLE_ENDIAN >=20 > 27c27 > < #define _LIBCPP_BIG_ENDIAN 1 > --- >=20 > > #define _LIBCPP_BIG_ENDIAN 0 >=20 > 60c60 > < #define _LIBCPP_LITTLE_ENDIAN 0 > --- >=20 > > #define _LIBCPP_LITTLE_ENDIAN 1 >=20 > 84,85c84,85 > < #define _QUAD_HIGHWORD 0 > < #define _QUAD_LOWWORD 1 > --- >=20 > > #define _QUAD_HIGHWORD 1 > > #define _QUAD_LOWWORD 0 >=20 >=20 > 200d199 > < #define __GCC_HAVE_DWARF2_CFI_ASM 1 > 289a289 >=20 > > #define __NO_STRICT_ALIGNMENT=20 . . . =3D=3D=3D Mark Millard markmi at dsl-only.net 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 From owner-freebsd-ppc@freebsd.org Mon Jan 25 02:22:45 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 512777E8F for ; Mon, 25 Jan 2016 02:22:45 +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 075B31E7 for ; Mon, 25 Jan 2016 02:22:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21937 invoked from network); 25 Jan 2016 02:22:54 -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 02:22:54 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 24 Jan 2016 21:22:39 -0500 (EST) Received: (qmail 17352 invoked from network); 25 Jan 2016 02:22:39 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 25 Jan 2016 02:22:39 -0000 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 900221C43AE; Sun, 24 Jan 2016 18:22:37 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: native powerpc64-gcc and clang 3.7.1 on powerpc64: __BIGGEST_ALIGNMENT__ mismatch and a few more Message-Id: Date: Sun, 24 Jan 2016 18:22:42 -0800 To: FreeBSD PowerPC ML , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) 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 02:22:45 -0000 Intersting powerpc64-gcc's g++ (5.2) vs. clang++ (3.7.1) (all native on = powerpc64) macro differences for default conditions: > # more just_main.cpp=20 > int main(void) > { return 0; } > $ pkg which /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ was installed by = package powerpc64-gcc-5.2.0_1 > # /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -std=3Dc++11 -dM -E = just_main.cpp | sort > ~/powerpc64_gcc_52_macros.txt > # clang++ -std=3Dc++11 -dM -E just_main.cpp | sort > = ~/clang++371_macros.txt > # diff -U 100 ~/powerpc64_gcc_52_macros.txt ~/clang++371_macros.txt > --- /root/powerpc64_gcc_52_macros.txt 2016-01-24 17:51:51.333696000 = -0800 > +++ /root/clang++371_macros.txt 2016-01-24 17:49:34.592012000 -0800 . . . > -#define __BIGGEST_ALIGNMENT__ 16 > +#define __BIGGEST_ALIGNMENT__ 8 . . . > -#define __CHAR16_TYPE__ short unsigned int > +#define __CHAR16_TYPE__ unsigned short . . . > -#define __CMODEL_MEDIUM__ 1 . . . > -#define __GNUC__ 5 > -#define __GNUG__ 5 > -#define __GXX_ABI_VERSION 1009 . . . > +#define __GNUC__ 4 > +#define __GNUG__ 4 > +#define __GXX_ABI_VERSION 1002 . . . > +#define __NATURAL_ALIGNMENT__ 1 . . . > -#define __cpp_binary_literals 201304 . . . > -#define __cpp_runtime_arrays 198712 > -#define __cpp_rvalue_reference 200610 > +#define __cpp_rvalue_references 200610 . . . =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Wed Jan 27 02:45:12 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 3766BA6F0CC for ; Wed, 27 Jan 2016 02:45:12 +0000 (UTC) (envelope-from andy.silva@snscommunication.com) Received: from mailer238.gate85.rs.smtp.com (mailer238.gate85.rs.smtp.com [74.91.85.238]) (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 D6A491C03 for ; Wed, 27 Jan 2016 02:45:11 +0000 (UTC) (envelope-from andy.silva@snscommunication.com) X-MSFBL: eyJiIjoiNzRfOTFfODVfMjM4IiwiciI6ImZyZWVic2QtcHBjQGZyZWVic2Qub3Jn IiwiZyI6IlNuc3RlbGVjb21fZGVkaWNhdGVkX3Bvb2wifQ== Received: from [192.168.80.21] ([192.168.80.21:46219] helo=rs-ord-mta02-1.smtp.com) by rs-ord-mta04-3.smtp.com (envelope-from ) (ecelerity 4.1.0.46749 r(Core:4.1.0.4)) with ESMTP id D3/DC-12581-53F28A65; Wed, 27 Jan 2016 02:45:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=smtp.com; s=smtpcomcustomers; c=relaxed/simple; q=dns/txt; i=@smtp.com; t=1453862709; h=From:Subject:To:Date:MIME-Version:Content-Type; bh=wJqVV1lDKJI9azYNlOrlDBf56ZTmMbZm1UFB8YoaiZQ=; b=f+7IPkcUFnXpwcAK7BbNFNRk0FyP6IkQ+FZb6wp1fjPCP+lOja/aWQL7tg0U93Mt QSkTaUrH/B+c81COV32Wx14iBjE8tmLC2fPPtwYEhXWjQRT0m6d4mRTzYnEqd0Hz E2Bhfi/qDOMOD3CffgTs9VDpv0lEdHjZAIjbd/aN1WI=; Received: from [154.20.125.37] ([154.20.125.37:29733] helo=d154-20-125-37.bchsia.telus.net) by rs-ord-mta02-1.smtp.com (envelope-from ) (ecelerity 4.1.0.46749 r(Core:4.1.0.4)) with ESMTPA id B3/EC-15779-53F28A65; Wed, 27 Jan 2016 02:45:09 +0000 MIME-Version: 1.0 From: "Andy Silva" Reply-To: andy.silva@snscommunication.com To: freebsd-ppc@freebsd.org Subject: The C-RAN (Centralized Radio Access Network) Ecosystem: 2016 - 2030 - Opportunities, Challenges, Strategies & Forecasts. (Report) X-Mailer: Smart_Send_2_0_138 Date: Tue, 26 Jan 2016 18:45:03 -0800 Message-ID: <35924237919681859325241@Ankur> X-SMTPCOM-Spam-Policy: SMTP.com is a paid relay service. We do not tolerate UCE of any kind. Please report it ASAP to abuse@smtp.com X-SMTPCOM-Tracking-Number: 5ca3c122-f497-4aad-b919-4cca1664a590 X-SMTPCOM-Sender-ID: 6008902 Feedback-ID: 6008902:SMTPCOM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Wed, 27 Jan 2016 02:45:12 -0000 Hello=20 I wanted to bring to your attention the latest SNS Research report in which= you might be interested, " The C-RAN (Centralized Radio Access Network) Ec= osystem: 2016 =96 2030 =96 Opportunities, Challenges, Strategies & Forecast= s."=20 I believe this report will be highly applicable for you. If you would like = to see the report sample or have any questions, please let me know. =20 Report Information: Release Date: January 2016 Number of Pages: 250 Number of Tables and Figures: 80 Report Overview: Centralized RAN or C-RAN is an architectural shift in RAN (Radio Access Net= work) design, where the bulk of baseband processing is centralized and aggr= egated for a large number of distributed radio nodes. In comparison to stan= dalone clusters of base stations, C-RAN provides significant performance an= d economic benefits such as baseband pooling, enhanced coordination between= cells, virtualization, network extensibility, smaller deployment footprint= and reduced power consumption. Although Japan and South Korea continue to spearhead commercial C-RAN inves= tments, interest is also growing in other parts of the world. Mobile operat= ors such as China Mobile, Orange, Verizon and Sprint are already investing = in the technology.=20 SNS Research estimates that global investments on C-RAN architecture networ= ks will reach over $7 Billion by the end of 2016. The market is further exp= ected to grow at a CAGR of nearly 20% between 2016 and 2020. These investme= nts will include spending on RRHs (Remote Radio Heads), BBUs (Baseband Unit= s) and fronthaul transport networking gear. The =93C-RAN (Centralized Radio Access Network) Ecosystem: 2016 - 2030 =96 = Opportunities, Challenges, Strategies & Forecasts=94 report presents an in-= depth assessment of the C-RAN ecosystem including enabling technologies, ke= y trends, market drivers, challenges, standardization, regulatory landscape= , deployment models, operator case studies, opportunities, future roadmap,= value chain, ecosystem player profiles and strategies. The report also pre= sents forecasts for C-RAN infrastructure investments from 2016 till 2030. T= he forecasts cover 3 individual submarkets and 6 regions. The report comes with an associated Excel datasheet suite covering quantita= tive data from all numeric forecasts presented in the report. =20 Key Findings: The report has the following key findings: Expected to surpass $7 Billion in global spending by the end of 2016, C-RAN= is increasingly becoming the preferred approach to deploy future mobile ne= tworks for both macro and small cell coverage. The market is further expect= ed to grow at a CAGR of nearly 20% between 2016 and 2020. To alleviate stringent fronthaul requirements, an increasing number of C-RA= N solutions are now utilizing RRHs with baseband capabilities, allowing som= e intelligence (primarily Layer 1 and Layer 2) to be distributed among RRHs= , with Layer 3 functionality residing at centralized BBUs. The ongoing 5G race is expected to significantly boost C-RAN investments ov= er the coming years. SNS Research estimates that over $1 Billion of all C-R= AN architecture network investments will be directed towards 5G networks by= the end of 2020. At present, most virtualized Cloud RAN investments are limited to trials an= d demonstrations. However, by the end of 2020, we expect that virtualized B= BUs will account for over 6% of all C-RAN BBU investments. Topics Covered: The report covers the following topics: C-RAN ecosystem Market drivers and barriers Key architectural components (RRH, BBU and fronthaul) Competing RAN architectures including traditional macrocell base stations, = small cells and DAS (Distributed Antenna Systems) Key trends including baseband functional splitting, enterprise C-RAN, Cloud= RAN, MEC (Mobile Edge Computing) and RANaaS (RAN as a Service) Fronthaul networking technologies and interface options C-RAN deployment models and mobile operator case studies Regulatory landscape and standardization Industry roadmap and value chain Profiles and strategies of over 120 leading ecosystem players including ena= bling technology providers, radio equipment suppliers, BBU vendors, frontha= ul networking vendors and mobile operators Strategic recommendations for ecosystem players including C-RAN solution pr= oviders and mobile operators Market analysis and forecasts from 2016 till 2030 Historical Revenue & Forecast Segmentation: Market forecasts are provided for each of the following submarkets and thei= r subcategories: Air Interface Technology 3G & LTE 5G Submarkets RRH (Remote Radio Head) BBU (Baseband Unit) Fronthaul RRH Deployment Model Indoor Outdoor Fronthaul Technology Dedicated Fiber WDM (Wavelength Division Multiplexing) OTN (Optical Transport Network) PON (Passive Optical Network) Ethernet Microwave Millimeter Wave Regional Markets Asia Pacific Eastern Europe Middle East & Africa Latin & Central America North America Western Europe Key Questions Answered: The report provides answers to the following key questions: How big is the C-RAN opportunity=3F What trends, challenges and barriers are influencing its growth=3F How is the ecosystem evolving by segment and region=3F What will the market size be in 2020 and at what rate will it grow=3F Which submarkets will see the highest percentage of growth=3F How can C-RAN facilitate the management of interference and LTE-Advanced fe= atures such as CoMP (Coordinated Multi-Point)=3F What are the prospects of wireless fronthaul technologies=3F Is Ethernet a feasible solution for fronthaul networking=3F How big is the market for virtualized Cloud RAN networks=3F Who are the key market players and what are their strategies=3F What strategies should C-RAN solution providers and mobile operators adopt = to remain competitive=3F Report Pricing: Single User License: USD 2,500 Company Wide License: USD 3,500 Ordering Process: Please contact Andy Silva on andy.silva@snscommunication.com Provide the following information: 1. Report Title - 2. Report License - (Single User/Company Wide) 3. Name - 4. Email - 5. Job Title - 6. Company - 7. Invoice Address - Please contact me if you have any questions, or wish to purchase a copy. Ta= ble of contents and List of figures mentioned below for your better inside. I look forward to hearing from you. Kind Regards Andy Silva Marketing Executive Signals and Systems Telecom Reef Tower Jumeirah Lake Towers Sheikh Zayed Road Dubai, UAE =20 ___________________________________________________________________________= __________________________________________________________________________ =20 Table of Content =20 1.1 Executive Summary 1.2 Topics Covered 1.3 Historical Revenue & Forecast Segmentation 1.4 Key Questions Answered 1.5 Key Findings 1.6 Methodology 1.7 Target Audience 1.8 Companies & Organizations Mentioned =20 2 Chapter 2: An Overview of C-RAN 2.1 What is C-RAN=3F 2.1.1 Decoupling the Base Station 2.1.2 Brief History 2.2 Competing RAN Architectures 2.2.1 Traditional Macrocells 2.2.2 Small Cells 2.2.3 DAS (Distributed Antenna Systems) 2.3 Key Architectural Components for C-RAN 2.3.1 RRH (Remote Radio Head) 2.3.2 BBU (Baseband Unit) 2.3.3 Fronthaul 2.4 Baseband Functional Split Approaches 2.4.1 Fully Centralized Baseband Processing 2.4.2 Partially Centralized: RRH with L1 & L2 Baseband Capabilities 2.5 Fronthaul Interface Options 2.5.1 CPRI (Common Public Radio Interface) 2.5.2 OBSAI (Open Base Station Architecture Initiative) 2.5.3 ORI (Open Radio Interface) 2.5.4 Ethernet 2.6 Cloud RAN: Virtualizing C-RAN 2.6.1 Leveraging Commodity Technologies 2.6.2 Moving RAN to the Cloud 2.7 Market Growth Drivers 2.7.1 Capacity & Coverage Improvement: Addressing the Mobile Data Traffic T= sunami 2.7.2 Towards Greener RANs: Cost Efficiency & Energy Savings 2.7.3 Agile & Flexible Network Architecture 2.7.4 Enhanced Support for LTE-Advanced Features 2.7.5 The Benefits of Virtualization 2.7.6 Impact of 5G Rollouts 2.8 Market Barriers 2.8.1 Fronthaul Investments 2.8.2 Virtualization Challenges 2.8.3 Migration from Legacy Architectures =20 3 Chapter 3: Standardization & Regulatory Initiatives 3.1 3GPP (3rd Generation Partnership Project) 3.2 ETSI (European Telecommunications Standards Institute) 3.2.1 ORI for Fronthaul 3.2.2 NFV (Network Functions Virtualization) for Cloud RAN 3.2.3 MEC (Mobile Edge Computing) 3.3 NGMN (Next Generation Mobile Networks) Alliance 3.3.1 P-CRAN (Project Centralized RAN) 3.4 Small Cell Forum 3.4.1 Release 5.1: Small Cell Virtualization 3.5 MEF (Metro Ethernet Forum) 3.5.1 Ethernet Transport 3.6 IEEE (Institute of Electrical and Electronics Engineers) 3.6.1 IEEE 802.1CM: Time-Sensitive Networking for Fronthaul 3.6.2 IEEE P1904.3: Standard for RoE (Radio over Ethernet) Encapsulations a= nd Mappings 3.6.3 Other Standards & Work Groups 3.7 ITU (International Telecommunications Union) 3.7.1 Focus Group on IMT-2020 =20 4 Chapter 4: C-RAN Deployment Models & Case Studies 4.1 Deployment Models 4.1.1 Localized 4.1.2 Enterprise 4.1.3 Highly Centralized 4.1.4 Virtualized 4.2 Mobile Operator Case Studies 4.2.1 Am=E9rica M=F3vil Group 4.2.2 China Mobile 4.2.3 China Telecom 4.2.4 KT Corporation 4.2.5 LG Uplus 4.2.6 NTT DoCoMo 4.2.7 Orange 4.2.8 SK Telecom 4.2.9 SoftBank Mobile 4.2.10 Sprint 4.2.11 Telecom Italia 4.2.12 Telef=F3nica 4.2.13 Verizon Wireless 4.2.14 Vodafone Group =20 5 Chapter 5: C-RAN Industry Roadmap & Value Chain 5.1 Industry Roadmap 5.1.1 2016 =96 2020: Gaining Worldwide Traction 5.1.2 2020 =96 2025: The Cloud RAN Era - Moving Towards RAN Virtualization 5.1.3 2025 =96 2030: Continued Investments with 5G Network Rollouts 5.2 Value Chain 5.2.1 Enabling Technology Providers 5.2.2 Radio Equipment Suppliers 5.2.3 RAN Vendors 5.2.4 Fronthaul Networking Vendors 5.2.5 Mobile Operators 5.2.6 Test, Measurement & Performance Specialists =20 6 Chapter 6: Key Market Players 6.1 6WIND 6.2 Absolute Analysis 6.3 Accelink Technologies 6.4 ADLINK Technology 6.5 ADTRAN 6.6 ADVA Optical Networking 6.7 Advantech 6.8 Airspan Networks 6.9 Altiostar Networks 6.10 Amarisoft 6.11 Anritsu Corporation 6.12 Aquantia 6.13 ARM Holdings 6.14 Artemis Networks 6.15 Artesyn Embedded Technologies 6.16 Artiza Networks 6.17 ASOCS 6.18 ASTRI (Hong Kong Applied Science and Technology Research Institute) 6.19 Avago Technologies 6.20 Aviat Networks 6.21 Axxcelera Broadband Wireless (Moseley Associates) 6.22 BLiNQ Networks 6.23 Blu Wireless Technology 6.24 BluWan 6.25 BridgeWave Communications 6.26 Broadcom Corporation 6.27 Cambium Networks 6.28 Cavium 6.29 CBNL (Cambridge Broadband Networks Ltd.) 6.30 CCS (Cambridge Communication Systems) 6.31 Ceragon 6.32 Ciena Corporation 6.33 Cobham Wireless 6.34 Coherent Logix 6.35 Comcores ApS 6.36 CommAgility 6.37 CommScope 6.38 Coriant 6.39 Corning 6.40 Dali Wireless 6.41 Datang Mobile 6.42 DragonWave 6.43 eASIC Corporation 6.44 E-Band Communications (Moseley Associates) 6.45 EBlink 6.46 Eoptolink Technology 6.47 Ericsson 6.48 Exalt Communications 6.49 EXFO 6.50 Extreme Networks 6.51 FastBack Networks 6.52 Finisar Corporation 6.53 Fujitsu 6.54 GigaLight (Shenzhen Gigalight Technology Company) 6.55 GlobalFoundaries 6.56 HFR 6.57 HG Genuine 6.58 Hisense (Hisense Broadband Multimedia Technology) 6.59 Hitachi 6.60 Huawei 6.61 IDT (Integrated Device Technology) 6.62 IMEC International 6.63 Infinera 6.64 InnoLight Technology Corporation 6.65 Intel Corporation 6.66 InterDigital 6.67 Intracom Telecom 6.68 Ixia 6.69 JMA Wireless 6.70 JRC (Japan Radio Company) 6.71 Kathrein-Werke KG 6.72 Keysight Technologies 6.73 Kisan Telecom 6.74 KMW 6.75 Lattice Semiconductor 6.76 LightPointe Communications 6.77 Lumentum 6.78 Macom (M/A-COM Technology Solutions) 6.79 MAX4G 6.80 Mellanox Technologies 6.81 Microsemi Corporation 6.82 Microwave Networks 6.83 MIMOtech 6.84 Mitsubishi Electric Corporation 6.85 Mobiveil 6.86 Molex 6.87 MTI Mobile 6.88 NEC Corporation 6.89 NetScout Systems 6.90 Nokia Networks & Alcatel-Lucent 6.91 Nutaq 6.92 NXP Semiconductors 6.93 Octasic 6.94 OE Solutions 6.95 Parallel Wireless 6.96 PMC-Sierra 6.97 Potevio (China Potevio Company) 6.98 Proxim Wireless Corporation 6.99 QEOS 6.100 Qualcomm 6.101 Qwilt 6.102 Radisys Corporation 6.103 RADWIN 6.104 Red Hat 6.105 Saguna Networks 6.106 SAI Technology 6.107 Samji Electronics Company 6.108 Samsung Electronics 6.109 Sarokal Test Systems 6.110 Siklu 6.111 SOLiD (SOLiD Technologies) 6.112 Source Photonics 6.113 SpiderCloud Wireless 6.114 Sumitomo Electric Industries 6.115 Sunnada (Fujian Sunnada Communication Company) 6.116 Sunwave Communications 6.117 Tarana Wireless 6.118 TEKTELIC Communications 6.119 Telco Systems 6.120 TI (Texas Instruments) 6.121 Viavi Solutions 6.122 Vubiq Networks 6.123 Xelic 6.124 Xilinx 6.125 ZTE =20 7 Chapter 7: Market Analysis & Forecasts 7.1 Global Outlook of C-RAN Investments 7.2 Segmentation by Air Interface Technology 7.2.1 3G & LTE Networks 7.2.2 5G Networks 7.3 Segmentation by Submarket 7.3.1 RRH (Remote Radio Head) 7.3.1.1 Deployment Model Segmentation 7.3.1.2 Indoor 7.3.1.3 Outdoor 7.3.2 BBU (Baseband Unit) 7.3.3 Fronthaul 7.3.3.1 Technology Segmentation 7.3.3.2 Dedicated Fiber 7.3.3.3 WDM 7.3.3.4 OTN & PON 7.3.3.5 Ethernet 7.3.3.6 Microwave 7.3.3.7 Millimeter Wave 7.4 Segmentation by Region 7.4.1 RRH (Remote Radio Head) 7.4.2 BBU (Baseband Unit) 7.4.3 Fronthaul 7.5 Asia Pacific 7.5.1 RRH (Remote Radio Head) 7.5.2 BBU (Baseband Unit) 7.5.3 Fronthaul 7.6 Eastern Europe 7.6.1 RRH (Remote Radio Head) 7.6.2 BBU (Baseband Unit) 7.6.3 Fronthaul 7.7 Latin & Central America 7.7.1 RRH (Remote Radio Head) 7.7.2 BBU (Baseband Unit) 7.7.3 Fronthaul 7.8 Middle East & Africa 7.8.1 RRH (Remote Radio Head) 7.8.2 BBU (Baseband Unit) 7.8.3 Fronthaul 7.9 North America 7.9.1 RRH (Remote Radio Head) 7.9.2 BBU (Baseband Unit) 7.9.3 Fronthaul 7.10 Western Europe 7.10.1 RRH (Remote Radio Head) 7.10.2 BBU (Baseband Unit) 7.10.3 Fronthaul =20 8 Chapter 8: Conclusion & Strategic Recommendations 8.1 Why is the Market Poised to Grow=3F 8.2 Competitive Industry Landscape: Acquisitions, Alliances & Consolidation 8.3 Setting the Foundation for 5G Networks 8.4 Integration with MEC (Mobile Edge Computing) 8.5 Towards a User Centric RAN Architecture 8.6 Prospects of Virtualized Cloud RAN Networks 8.7 RANaaS (RAN as a Service): Envisioning the Future of C-RAN 8.8 Geographic Outlook: Which Countries Offer the Highest Growth Potential=3F 8.9 Which Submarket will Lead the Market=3F 8.10 Strategic Recommendations 8.10.1 C-RAN Solution Providers 8.10.2 Mobile Operators =20 List of Figures =20 Figure 1: C-RAN Architecture Figure 2: Key Characteristics of Small Cells Figure 3: Key RRH & BBU Functions Figure 4: Baseband Processing Distribution Options Figure 5: CPRI Protocol Layers Figure 6: Cloud RAN Concept Figure 7: Annual Global Throughput of Mobile Network Data Traffic by Region= : 2016 - 2030 (Exabytes) Figure 8: Localized C-RAN Deployment Model Figure 9: Enterprise C-RAN Deployment Model Figure 10: China Mobile=92s Cloud RAN Vision Figure 11: NTT DoCoMo=92s Advanced C-RAN Architecture Figure 12: C-RAN Industry Roadmap Figure 13: C-RAN Value Chain Figure 14: Global C-RAN Revenue: 2016 - 2030 ($ Million) Figure 15: Global C-RAN Revenue by Air Interface Technology: 2016 - 2030 ($= Million) Figure 16: Global C-RAN Revenue in 3G & LTE Networks: 2016 - 2030 ($ Millio= n) Figure 17: Global C-RAN Revenue in 5G Networks: 2016 - 2030 ($ Million) Figure 18: Global C-RAN Revenue by Submarket: 2016 - 2030 ($ Million) Figure 19: Global RRH (Remote Radio Heat) Unit Shipments: 2016 - 2030 (Thou= sands of Units) Figure 20: Global RRH (Remote Radio Heat) Unit Shipment Revenue: 2016 - 203= 0 ($ Million) Figure 21: Global RRH (Remote Radio Heat) Unit Shipments by Deployment Mode= l: 2016 - 2030 (Thousands of Units) Figure 22: Global RRH (Remote Radio Heat) Unit Shipment Revenue by Deployme= nt Model: 2016 - 2030 ($ Million) Figure 23: Global Indoor RRH (Remote Radio Heat) Unit Shipments: 2016 - 203= 0 (Thousands of Units) Figure 24: Global Indoor RRH (Remote Radio Heat) Unit Shipment Revenue: 201= 6 - 2030 ($ Million) Figure 25: Global Outdoor RRH (Remote Radio Heat) Unit Shipments: 2016 - 20= 30 (Thousands of Units) Figure 26: Global Outdoor RRH (Remote Radio Heat) Unit Shipment Revenue: 20= 16 - 2030 ($ Million) Figure 27: Global BBU (Baseband Unit) Shipments: 2016 - 2030 (Thousands of = Units) Figure 28: Global BBU (Baseband Unit) Shipment Revenue: 2016 - 2030 ($ Mill= ion) Figure 29: Global C-RAN Fronthaul Revenue: 2016 - 2030 ($ Million) Figure 30: Global C-RAN Fronthaul Revenue by Technology: 2016 - 2030 ($ Mil= lion) Figure 31: Global Dedicated Fiber Fronthaul Revenue: 2016 - 2030 ($ Million) Figure 32: Global WDM Fronthaul Revenue: 2016 - 2030 ($ Million) Figure 33: Global OTN & PON Fronthaul Revenue: 2016 - 2030 ($ Million) Figure 34: Global Ethernet Fronthaul Revenue: 2016 - 2030 ($ Million) Figure 35: Global Microwave Fronthaul Revenue: 2016 - 2030 ($ Million) Figure 36: Global Millimeter Wave Fronthaul Revenue: 2016 - 2030 ($ Million) Figure 37: C-RAN Revenue by Region: 2016 - 2030 ($ Million) Figure 38: RRH (Remote Radio Heat) Unit Shipments by Region: 2016 - 2030 (T= housands of Units) Figure 39: RRH (Remote Radio Heat) Unit Shipment Revenue by Region: 2016 - = 2030 ($ Million) Figure 40: BBU (Baseband Unit) Shipments by Region: 2016 - 2030 (Thousands = of Units) Figure 41: BBU (Baseband Unit) Shipment Revenue by Region: 2016 - 2030 ($ M= illion) Figure 42: C-RAN Fronthaul Revenue by Region: 2016 - 2030 ($ Million) Figure 43: Asia Pacific C-RAN Revenue: 2016 - 2030 ($ Million) Figure 44: Asia Pacific RRH (Remote Radio Heat) Unit Shipments: 2016 - 2030= (Thousands of Units) Figure 45: Asia Pacific RRH (Remote Radio Heat) Unit Shipment Revenue: 2016= - 2030 ($ Million) Figure 46: Asia Pacific BBU (Baseband Unit) Shipments: 2016 - 2030 (Thousan= ds of Units) Figure 47: Asia Pacific BBU (Baseband Unit) Shipment Revenue: 2016 - 2030 (= $ Million) Figure 48: Asia Pacific C-RAN Fronthaul Revenue: 2016 - 2030 ($ Million) Figure 49: Eastern Europe C-RAN Revenue: 2016 - 2030 ($ Million) Figure 50: Eastern Europe RRH (Remote Radio Heat) Unit Shipments: 2016 - 20= 30 (Thousands of Units) Figure 51: Eastern Europe RRH (Remote Radio Heat) Unit Shipment Revenue: 20= 16 - 2030 ($ Million) Figure 52: Eastern Europe BBU (Baseband Unit) Shipments: 2016 - 2030 (Thous= ands of Units) Figure 53: Eastern Europe BBU (Baseband Unit) Shipment Revenue: 2016 - 2030= ($ Million) Figure 54: Eastern Europe C-RAN Fronthaul Revenue: 2016 - 2030 ($ Million) Figure 55: Latin & Central America C-RAN Revenue: 2016 - 2030 ($ Million) Figure 56: Latin & Central America RRH (Remote Radio Heat) Unit Shipments: = 2016 - 2030 (Thousands of Units) Figure 57: Latin & Central America RRH (Remote Radio Heat) Unit Shipment Re= venue: 2016 - 2030 ($ Million) Figure 58: Latin & Central America BBU (Baseband Unit) Shipments: 2016 - 20= 30 (Thousands of Units) Figure 59: Latin & Central America BBU (Baseband Unit) Shipment Revenue: 20= 16 - 2030 ($ Million) Figure 60: Latin & Central America C-RAN Fronthaul Revenue: 2016 - 2030 ($ = Million) Figure 61: Middle East & Africa C-RAN Revenue: 2016 - 2030 ($ Million) Figure 62: Middle East & Africa RRH (Remote Radio Heat) Unit Shipments: 201= 6 - 2030 (Thousands of Units) Figure 63: Middle East & Africa RRH (Remote Radio Heat) Unit Shipment Reven= ue: 2016 - 2030 ($ Million) Figure 64: Middle East & Africa BBU (Baseband Unit) Shipments: 2016 - 2030 = (Thousands of Units) Figure 65: Middle East & Africa BBU (Baseband Unit) Shipment Revenue: 2016 = - 2030 ($ Million) Figure 66: Middle East & Africa C-RAN Fronthaul Revenue: 2016 - 2030 ($ Mil= lion) Figure 67: North America C-RAN Revenue: 2016 - 2030 ($ Million) Figure 68: North America RRH (Remote Radio Heat) Unit Shipments: 2016 - 203= 0 (Thousands of Units) Figure 69: North America RRH (Remote Radio Heat) Unit Shipment Revenue: 201= 6 - 2030 ($ Million) Figure 70: North America BBU (Baseband Unit) Shipments: 2016 - 2030 (Thousa= nds of Units) Figure 71: North America BBU (Baseband Unit) Shipment Revenue: 2016 - 2030 = ($ Million) Figure 72: North America C-RAN Fronthaul Revenue: 2016 - 2030 ($ Million) Figure 73: Western Europe C-RAN Revenue: 2016 - 2030 ($ Million) Figure 74: Western Europe RRH (Remote Radio Heat) Unit Shipments: 2016 - 20= 30 (Thousands of Units) Figure 75: Western Europe RRH (Remote Radio Heat) Unit Shipment Revenue: 20= 16 - 2030 ($ Million) Figure 76: Western Europe BBU (Baseband Unit) Shipments: 2016 - 2030 (Thous= ands of Units) Figure 77: Western Europe BBU (Baseband Unit) Shipment Revenue: 2016 - 2030= ($ Million) Figure 78: Western Europe C-RAN Fronthaul Revenue: 2016 - 2030 ($ Million) Figure 79: Global Virtualized RAN Investments: 2016 - 2030 ($ Million) Figure 80: Global C-RAN Spending Breakdown by Submarket: 2020 (%) =20 Thank you once again and looking forward to hearing from you. =20 Kind Regards =20 Andy Silva Marketing Executive Signals and Systems Telecom andy.silva@snscommunication.com Reef Tower Jumeirah Lake Towers Sheikh Zayed Road Dubai, UAE =20 =20 To unsubscribe send an email with unsubscribe in the subject line to: remov= e@snsreports.com From owner-freebsd-ppc@freebsd.org Thu Jan 28 11:12:39 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 9B86EA71729 for ; Thu, 28 Jan 2016 11:12:39 +0000 (UTC) (envelope-from luciano@vespaperitivo.it) Received: from baobab.bilink.net (baobab.bilink.net [212.45.144.44]) by mx1.freebsd.org (Postfix) with ESMTP id 6233315DC for ; Thu, 28 Jan 2016 11:12:39 +0000 (UTC) (envelope-from luciano@vespaperitivo.it) Received: from localhost (localhost [127.0.0.1]) by baobab.bilink.it (Postfix) with ESMTP id 3prfKF4p21z1cXLL for ; Thu, 28 Jan 2016 12:12:33 +0100 (CET) X-Virus-Scanned: amavisd-new at mcs.it Received: from baobab.bilink.net ([127.0.0.1]) by localhost (baobab.mcs.it [127.0.0.1]) (amavisd-new, port 11027) with ESMTP id bKojuIY-7TsP for ; Thu, 28 Jan 2016 12:12:33 +0100 (CET) Received: from hermes.mcs.it (hermes.mcs.it [192.168.132.21]) by baobab.bilink.it (Postfix) with ESMTP id 3prfKF45d0z1cXLJ for ; Thu, 28 Jan 2016 12:12:33 +0100 (CET) Received: from mordeus (unknown [192.168.45.6]) by hermes.mcs.it (Postfix) with ESMTP id 5136F1B7515 for ; Thu, 28 Jan 2016 12:12:31 +0100 (CET) Date: Thu, 28 Jan 2016 12:12:31 +0100 From: Luciano Mannucci To: freebsd-ppc@freebsd.org Subject: Re: PPC64 20160113-r293801 on IBM KVM In-Reply-To: <3pn3134Nqxz1cXL0@baobab.bilink.it> References: <3pn3134Nqxz1cXL0@baobab.bilink.it> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.1) X-Face: 4qPv4GNcD; h<7Q/sK>+GqF4=CR@KmnPkSmwd+#%\F`4yjKO3"C]p'z=(oWRnsYBQGM\5g:4skqQY0NnV'dM:Mm:^/_+I@a"; [-s=ogufdF"9ggQ'=y MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <3prfKF45d0z1cXLJ@baobab.bilink.it> 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: Thu, 28 Jan 2016 11:12:39 -0000 On Fri, 22 Jan 2016 15:23:47 +0100 Luciano Mannucci wrote: > I'm a bit stuck. Well, I'm doing the obvious thing: running from the install DVD, mounting /dev/da1s2a /mnt, swapon -F /mnt/etc/fstab -a, mount devfs on /mnt, chroot /mnt, ldconfig... Everything seems fine: I've downloaded and installed the ports and compiled pkg flawlessly. Exiting the chroot and unmounting /mnt/dev and /mnt gives me: root@:~ # umount /mnt/dev root@:~ # umount /mnt lock order reversal: 1st 0x7a479a0 isofs (isofs) @ /usr/src/sys/kern/vfs_mount.c:1224 2nd 0x7a41d50 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 Is it harmless? Cheers, Luciano. -- /"\ /Via A. Salaino, 7 - 20144 Milano (Italy) \ / ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2 48578250 X AGAINST HTML MAIL / E-MAIL: posthamster@sublink.sublink.ORG / \ AND POSTINGS / WWW: http://www.lesassaie.IT/ From owner-freebsd-ppc@freebsd.org Thu Jan 28 16:11:19 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 293DEA70B3F for ; Thu, 28 Jan 2016 16:11:19 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DEA5E1E2D for ; Thu, 28 Jan 2016 16:11:18 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-ob0-x229.google.com with SMTP id ba1so39297930obb.3 for ; Thu, 28 Jan 2016 08:11:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AMtRwTDhDKvPpDyPxnFcpuc6S/HGOavRUPk00xOZhW8=; b=P0sZT36XCFSRDYltcVR7dQEB+KKFPNu0+tknayxe0NBIFsXoEzl+MmRfUNzN4PWz3O 9cUXnQK7TjtfGdNJnYVP8S9IS4k0G76NeCKy6dxFqIhHFAAkXMIdMnU4HcJLPX0jy+Jf ywRk9KiRNObJNosdx47OCos2c9qmI13ISDupqKoTssqgKjl0ENdoWfCUJckhm37o/dcw 1Rq51n3B6aNdW7K8rPehzv8U8DrrVrBI14aAO0JygZfuoPYd+FVrPJRTK8wYq0EhJIWx DN2OEyIcyGa+eNk/PGD/A1Lf3Pkq/mQ5Bgw2iuz+DLlOAgVhQw8LnQfqmzrRcAf16CrW sCtA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cwru-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AMtRwTDhDKvPpDyPxnFcpuc6S/HGOavRUPk00xOZhW8=; b=c9zA9BNFKYuv3+0WJmXCL1EhBUFep+EEoQd7QhsQ9rF1nif57jkL6XcelgFmAYPcdQ qbiNyIVBjKKjYa3QBNdvUi+3odYKvIwvHuxDV+nFjz3MG1ZhDqIWBBiick9WY2ph/Ego Kv7Q5G95Wd9RYeIL3Q1FIPhQJMYOZ1P8lIZdkof0SEmhq6O/PndoUQnGC46gWl8rcQ5a OSpOK2x/QJ8Y7pdQckWI1yjRFncxqX7ysTIgOwED0/mdB5qn57qhMod1jrhvhcfK4cdX 2JfqwvkkZGVXVFx157TAbJeN4Xiui6IWuvb58KceBtTjJiZSem+l6r73q9LQODpGl/tB a8Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AMtRwTDhDKvPpDyPxnFcpuc6S/HGOavRUPk00xOZhW8=; b=WwaXwuizaf862csj+uWzpSlczEhFKXbGTMfSUnNEpK3rQ6Qm8YJxCIwvjPYbaVgouN heraU2JLKFfZrj2yYlJ03EdSnL+ofyj5Hj3eita6ZEoWSfZ0sT4j2+E5BNkTI8iEWFFh TsnDIn3q/1AgBe68IgKxBDAoiexWbRIXKS/YtMGgXnk8r/U191PYtoMmcNYExzrGlAD1 Wb/BJmBxeQpF7gfvbYgcfA7lUKL5L9hmFY8ViWP33zKSSNDXjJWFvJ/ctHypD/0CaLK7 eC0r4OZsh2MVnWbNQhJ48+D1ufmlBZZVKdEYjS3iGeLpRkqIWW8+KUfLFD5ahHwDxpbJ 0+Lg== X-Gm-Message-State: AG10YOSKFUjY7LHto0cT3rdQxr1w7xyku8az+WbooSEuoLlfOS2JxOCvy5SCCgDABgPnAgpbraTXcbp0UhLzWA== MIME-Version: 1.0 X-Received: by 10.182.70.70 with SMTP id k6mr2782814obu.74.1453997478240; Thu, 28 Jan 2016 08:11:18 -0800 (PST) Sender: chmeeedalf@gmail.com Received: by 10.182.74.101 with HTTP; Thu, 28 Jan 2016 08:11:18 -0800 (PST) In-Reply-To: <3prfKF45d0z1cXLJ@baobab.bilink.it> References: <3pn3134Nqxz1cXL0@baobab.bilink.it> <3prfKF45d0z1cXLJ@baobab.bilink.it> Date: Thu, 28 Jan 2016 10:11:18 -0600 X-Google-Sender-Auth: 4pm4SjM9ejt21iUVZu-KLJUlT14 Message-ID: Subject: Re: PPC64 20160113-r293801 on IBM KVM From: Justin Hibbits To: Luciano Mannucci Cc: FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 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: Thu, 28 Jan 2016 16:11:19 -0000 Hi Luciano, On Thu, Jan 28, 2016 at 5:12 AM, Luciano Mannucci wrote: > On Fri, 22 Jan 2016 15:23:47 +0100 > Luciano Mannucci wrote: > lock order reversal: > 1st 0x7a479a0 isofs (isofs) @ /usr/src/sys/kern/vfs_mount.c:1224 > 2nd 0x7a41d50 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1375 > > Is it harmless? Yes, it's harmless, and is a well-known LOR. - Justin From owner-freebsd-ppc@freebsd.org Thu Jan 28 22:49:16 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 CE82BA71B77 for ; Thu, 28 Jan 2016 22:49:16 +0000 (UTC) (envelope-from xavier.hilaire@gmail.com) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78D061F45 for ; Thu, 28 Jan 2016 22:49:16 +0000 (UTC) (envelope-from xavier.hilaire@gmail.com) Received: by mail-wm0-x230.google.com with SMTP id p63so45553177wmp.1 for ; Thu, 28 Jan 2016 14:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=AinLaTPfBWrRS4r5/W6B2qo8T2HA88cSlU1E+YeKcCA=; b=JwuVj9kgnZRnOOPPgWpnPFi7OYxTXWMZTcyEwl2cs95PKidklBhEKtbYg/NWyYWkN5 f+kVm3oUznQ/FPDBHUveDAFU9u+gTf9hoq7TwXCYgkqE37tyk1o5ByFHdSmlD1Goj2+B RuK1INjGIr1FbNttoIVk4vtixjKQckPzjNQ6iBlh4h4D/d19K8HVFDuNqrDFMxOi+Yj6 ksPwAdZoAwwNpAPA3ykZPeJNMEWrF6SFlesdlMMkblCVvLE0YPdm6kcN/uAtDHdVfoLY LTSC4G79fpjPF+EgM4YzizGOga65CPPGDAk4oAGMWp9/uLbiCsMWUFayBqMtZd0mrQ0Q 3ZCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=AinLaTPfBWrRS4r5/W6B2qo8T2HA88cSlU1E+YeKcCA=; b=PXhhozdr97d0J9/7RK/+licnbJwK/eo/WL4RNeS4Ajk0pMBwRy0atRrJ1xk6x2+R1d 5uc5szKKmYYzcI6AigQOhDSxWER0QTramCxYO8KbWjiY5HlwYDXLYxdadQTuv3plGi7m 4dap5kCPNi17IKL24qvHsQMjZI0pmdzhoAQ8SxqwTsqlmsVJZl9cTF+Pcyrl3XF9CI9M WSN+Ps+6wdisowV5VoWXVWmDuaxKWWIGltFKIizymKKlyUNzcoHv5M3f23/AcDt7ypTs 4MfqPwbKnpzA8kvp5GGIlpCXIJQDy14PZF6btT+kH6EXKnJxI83VVPsAtP7R34q/1WM1 tSnw== X-Gm-Message-State: AG10YOSWTRWDQnEg9+F5LlZaUsq/fd/W33dLvMyxRrdNdWEkwbQItEuxdcO947friDICbQ== X-Received: by 10.28.146.145 with SMTP id u139mr5347775wmd.81.1454021354931; Thu, 28 Jan 2016 14:49:14 -0800 (PST) Received: from [192.168.1.15] (AAubervilliers-651-1-325-10.w83-200.abo.wanadoo.fr. [83.200.92.10]) by smtp.gmail.com with ESMTPSA id 73sm4839073wmm.7.2016.01.28.14.49.13 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jan 2016 14:49:14 -0800 (PST) To: freebsd-ppc@freebsd.org From: Xavier HILAIRE Subject: On-die temperatures not reported on a Powermac dual G5 Message-ID: <56AA9AE7.6030402@gmail.com> Date: Thu, 28 Jan 2016 23:49:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux ppc64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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: Thu, 28 Jan 2016 22:49:16 -0000 Hi, I recently got an old Powermac dual G5 on which I installed both FreeBSD 10.2 and Linux (Debian, jessie). After booting FreeBSD I noticed the fans were running at an unusual low speed given the CPU-intensive work I was doing (recompile some ports + X11 drivers). A sysctl -a | grep temp showed the following: > net.inet6.ip6.use_tempaddr: 0 > net.inet6.ip6.temppltime: 86400 > net.inet6.ip6.tempvltime: 604800 > net.inet6.ip6.prefer_tempaddr: 0 > hw.usb.template: 0 > dev.ad7417.1.sensor.cpu_b_ad7417_amb.temp: 31.0C > dev.ad7417.0.sensor.cpu_a_ad7417_amb.temp: 33.2C > dev.ds1631.0.sensor.mlb_inlet_amb.temp: 22.2C > dev.ds1631.0.%pnpinfo: name=temp-monitor compat=ds1631 > dev.max6690.0.sensor.u3_heatsink.temp: 63.0C > dev.max6690.0.sensor.backside.temp: 35.3C > dev.max6690.0.%pnpinfo: name=temp-monitor compat=max6690 > dev.ds1775.0.sensor.drive_bay.temp: 21.0C > dev.ds1775.0.%pnpinfo: name=temp-monitor compat=ds1775 > x The only two available temperatures related to the CPUs seem to be those reported by the AD7417 supply monitor's sensors, and there is *no* temperature reported from the on-die sensors at all. When rebooting Linux, the kernel complained about CPU0's temperature higher than the critical value, and shut down the system almost immediately. Now, (well, after a few hours cooling, ideed!) here is copy of what I get on Debian after cd'ing to /sys/devices/platform/windfarm.0 : > xavier@pomme:/sys/devices/platform/windfarm.0$ for f in $(find . -type f); do >> echo -n "$f -> "; cat $f >> done > ./backside-temp -> 66.000 > ./backside-fan -> 19 % > ./cpu-amb-temp-0 -> 38.250 > ./cpu-amb-temp-1 -> 35.250 > ./power/control -> auto > ./power/async -> disabled > ./power/runtime_enabled -> disabled > ./power/runtime_active_kids -> 0 > ./power/runtime_active_time -> 0 > ./power/autosuspend_delay_ms -> cat: ./power/autosuspend_delay_ms: Erreur d'entrée/sortie > ./power/runtime_status -> unsupported > ./power/runtime_usage -> 0 > ./power/runtime_suspended_time -> 0 > ./cpu-current-0 -> 35.522 > ./cpu-current-1 -> 33.447 > ./cpu-pump-0 -> 1250 RPM > ./cpu-pump-1 -> 1250 RPM > ./cpu-front-fan-0 -> 660 RPM > ./cpu-front-fan-1 -> 660 RPM > ./modalias -> platform:windfarm > ./cpu-rear-fan-0 -> 681 RPM > ./cpu-rear-fan-1 -> 681 RPM > ./cpu-12v-current-0 -> 5.004 > ./cpu-12v-current-1 -> 4.577 > ./cpu-voltage-0 -> 1.374 > ./cpu-voltage-1 -> 1.364 > ./hd-temp -> 24.000 > ./cpufreq-clamp -> 0 > ./drive-bay-fan -> 300 RPM > ./uevent -> DRIVER=windfarm > MODALIAS=platform:windfarm > ./cpu-diode-temp-0 -> 70.987 > ./cpu-diode-temp-1 -> 60.784 > ./slots-fan -> 39 % The cpu-diode-temp-* lines just do not have their equivalent from sysctl on FreeBSD. I took a look at the powermac_thermal.{c,h} files in the source tree, and my understanding is that the fans are not managed properly because the on-die temperatures are just not reported, thus accounted for at all in the fan management loop (indeed, the cpu-amb-* temperatures can remain quite stable, while the cpu-diode-temp can increase substantially) Am I right? This is weird, because a "sysctl -a | grep smu" does not report anything, while the kernel *does* include the smu driver, and temperature sensors are normally attached to this device AFAIK. I would *love* using FreeBSD again (rather than Linux, for compatibility reasons). But my code is CPU intensive and relies a lot on Altivec, I wouldn't want to fire my everything... The machine is an M9032LL/A according to Apple's specs: https://support.apple.com/kb/sp96?locale=en_US Any help will be greatly appreciated. Thanks, Xavier From owner-freebsd-ppc@freebsd.org Fri Jan 29 16:23:37 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 00AC6A71915 for ; Fri, 29 Jan 2016 16:23:37 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B815211D1 for ; Fri, 29 Jan 2016 16:23:36 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-oi0-x232.google.com with SMTP id r14so50239619oie.0 for ; Fri, 29 Jan 2016 08:23:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LWb9X2b1uWYckyO4m0NY5nrvAe5wvfpvfGjvXnh0cHM=; b=cuHy/C9X+vXEai+WTAK519jTJdAfiWoOD7M1f3qVqQV5PXUC/Pfzm8e3MRYsLQb1t3 wqoU0lmekw4Br84WEkouYQ4G6b+iYbfLvUaJGPjJpT2JgmA1JrXpnXZ7q1OAtlhuahhi j+G6GwWrJiaRoZHBQ5RWZdT4QHQspGWS9aUvkGjCQ0aLeh3FN1zMrHl2CGbeU2WJhGdf K1sUpKg6zljiI2d5AnfZs6qiuMW74n1V45InYaT8y4XrXGe/31Mse6mYNOfK4CWAfZH3 fmhxJ9PRXWBiADRhLSlcIQNFAzDy6x6y4rl6llLwAMgSsp77ccxnQZFeVXVX2bvqnxYS poBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cwru-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LWb9X2b1uWYckyO4m0NY5nrvAe5wvfpvfGjvXnh0cHM=; b=igQMiIBt1rnDuO+u4KspRxklGVTrdR6pEUts+WFV6fxNUve22V0rduCgx40vNQ8sha x46Zse1WplTwoIxfyJ9gjQmd3XI5JZ6Xj2AY/4/VvwS1qNXamTazpfGcYcFZP5MywFoR ZyUv6tzmW++xjjjc7hSlZwswkc9hbZNdTq7UtfNY+rJ+oq8V2v79uu2SXcouwF66d61H r5Mcq0NEOVvD9aFjGsxJ7kIL1cPWjW3TM5eLkM21OmwyXecGT/nVqZFnVukLmqaJBC55 G0K9IGVKiRmqR2FAaJAI+6APDtUWrVv8yrisytslC6JltiOZ/GdgYgDbWfVS4BJe4vo2 Qj7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LWb9X2b1uWYckyO4m0NY5nrvAe5wvfpvfGjvXnh0cHM=; b=BWFgjsMD7Vm7EYoM0tyKhwyD9OnYGtPWZIAq47BevIE88WkmurmDPjJaEb9nmNc6Ww vFzqEaksgCV4FunoisfQiBmpJn3N2taQFOulHqqkzQ890uYm6PgZlr9b+KBB+bSEt6Zk GDPJ+7okkcjxuynyWXfys60+lBxgt7/x5NRS5EqGDFi8MBNqj4n564PqZFlqbU78S/I8 /ld5+6Jv2tJhz0BGUoyjL18SkSTus+z/T306UV9jkPzWbSq04YVh++ePWmWafrgYNon3 CL+47gqtNKq7bY4GcFsT/9ylRwaRUFCh5P+wTb48eC5/eiAdMyHbp9EBTnvrozVoT9ZO w8DQ== X-Gm-Message-State: AG10YOQYSSbTtfG1s/wOBQZmWNCpz9BFpCJmBA4QQkr0C3MHol38hw4TScmh2Mo6TyttrNNp9SxTZBgLHHqVJQ== MIME-Version: 1.0 X-Received: by 10.202.213.78 with SMTP id m75mr7160805oig.56.1454084615940; Fri, 29 Jan 2016 08:23:35 -0800 (PST) Sender: chmeeedalf@gmail.com Received: by 10.182.74.101 with HTTP; Fri, 29 Jan 2016 08:23:35 -0800 (PST) In-Reply-To: <56AA9AE7.6030402@gmail.com> References: <56AA9AE7.6030402@gmail.com> Date: Fri, 29 Jan 2016 10:23:35 -0600 X-Google-Sender-Auth: jOjRKD2BVoUOLkvG9GVHZGmcxdM Message-ID: Subject: Re: On-die temperatures not reported on a Powermac dual G5 From: Justin Hibbits To: Xavier HILAIRE Cc: FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 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: Fri, 29 Jan 2016 16:23:37 -0000 On Thu, Jan 28, 2016 at 4:49 PM, Xavier HILAIRE wrote: > Hi, > > I recently got an old Powermac dual G5 on which I installed both FreeBSD > 10.2 and Linux (Debian, jessie). > > After booting FreeBSD I noticed the fans were running at an unusual low > speed given the CPU-intensive work I was doing (recompile some ports + X11 > drivers). A sysctl -a | grep temp showed the following: > >> net.inet6.ip6.use_tempaddr: 0 >> net.inet6.ip6.temppltime: 86400 >> net.inet6.ip6.tempvltime: 604800 >> net.inet6.ip6.prefer_tempaddr: 0 >> hw.usb.template: 0 >> dev.ad7417.1.sensor.cpu_b_ad7417_amb.temp: 31.0C >> dev.ad7417.0.sensor.cpu_a_ad7417_amb.temp: 33.2C >> dev.ds1631.0.sensor.mlb_inlet_amb.temp: 22.2C >> dev.ds1631.0.%pnpinfo: name=temp-monitor compat=ds1631 >> dev.max6690.0.sensor.u3_heatsink.temp: 63.0C >> dev.max6690.0.sensor.backside.temp: 35.3C >> dev.max6690.0.%pnpinfo: name=temp-monitor compat=max6690 >> dev.ds1775.0.sensor.drive_bay.temp: 21.0C >> dev.ds1775.0.%pnpinfo: name=temp-monitor compat=ds1775 >> x > > > > The only two available temperatures related to the CPUs seem to be those > reported by the AD7417 supply monitor's sensors, and there is *no* > temperature reported from the on-die sensors at all. > > This is weird, because a "sysctl -a | grep smu" does not report anything, > while the kernel *does* include the smu driver, and temperature sensors are > normally attached to this device AFAIK. Not in your case. The SMU isn't used until the last generation or two of G5. The PowerMac7,2 generation, which you have, puts all the sensors on the ad7417. > > I would *love* using FreeBSD again (rather than Linux, for compatibility > reasons). But my code is CPU intensive and relies a lot on Altivec, I > wouldn't want to fire my everything... > > The machine is an M9032LL/A according to Apple's specs: > https://support.apple.com/kb/sp96?locale=en_US > > > Any help will be greatly appreciated. > > Thanks, > > Xavier Can you post (attach) the output of 'ofwdump -ap'? There's a comment in the Linux driver for ad7417 stating that sometimes some of the sensors aren't listed in the device tree. If that's the case for you, we'll need to special case for it. - Justin From owner-freebsd-ppc@freebsd.org Sat Jan 30 11:27:08 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 97D81A73773 for ; Sat, 30 Jan 2016 11:27:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-1.reflexion.net [208.70.210.1]) (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 5DD801170 for ; Sat, 30 Jan 2016 11:27:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22383 invoked from network); 30 Jan 2016 11:00:39 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 Jan 2016 11:00:39 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 30 Jan 2016 06:00:32 -0500 (EST) Received: (qmail 27377 invoked from network); 30 Jan 2016 11:00:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 30 Jan 2016 11:00:32 -0000 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 B6BD41C43C7; Sat, 30 Jan 2016 03:00:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 based powerpc (32 bit) buildworld runs on a PowerMac! [problems found] From: Mark Millard In-Reply-To: Date: Sat, 30 Jan 2016 03:00:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <55814789-0489-48B5-867C-F678AE4EA5FF@dsl-only.net> References: To: FreeBSD PowerPC ML , FreeBSD Toolchain 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: Sat, 30 Jan 2016 11:27:08 -0000 I got around to trying some more use of the 3.8.0 clang based world on = powerpc (32 bit) (now -r294962 based) and ran into: A) Segmentation faults during signal handlers in syslogd, nfsd, mountd, = and (for SIGNFO) make. B) ls sometimes segmentation faulting C) make -j 6 buildworld segmentation faulting in make eventually but = make buildworld works. I have reduced (A) to a simple program that demonstrates the behavior: > # more sig_snprintf_use_test.c=20 > #include > #include >=20 > volatile sig_atomic_t sat =3D 0; >=20 > void > handler(int sig) > { > char uidbuf[32]; > (void) snprintf(uidbuf, sizeof uidbuf, "%d", 10); > sat =3D uidbuf[0]; > } >=20 > int > main(void) > { > if (signal(SIGINT, handler) !=3D SIG_ERR) raise(SIGINT); > return sat; > } > # ./a.out > Segmentation fault (core dumped) > # /usr/local/bin/gdb a.out /var/crash/a.out.1510.core > GNU gdb (GDB) 7.10 [GDB v7.10 for FreeBSD] . . . > warning: Unexpected size of section `.reg2/100167' in core file. > #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > 124 TLOOP1(*--dst =3D *--src); > (gdb) bt > #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > #1 0x419a3984 in __sfvwrite (fp=3D, uio=3D) at /usr/src/lib/libc/stdio/fvwrite.c:128 > #2 0x41934468 in __sprint (fp=3D, uio=3D, locale=3D) at = /usr/src/lib/libc/stdio/vfprintf.c:164 > #3 io_flush (iop=3D, locale=3D) at = /usr/src/lib/libc/stdio/printfcommon.h:155 > #4 __vfprintf (fp=3D, locale=3D, = fmt0=3D, ap=3D) at = /usr/src/lib/libc/stdio/vfprintf.c:1020 > #5 0x4199c644 in snprintf (str=3D0xffffd734 "", n=3D, = fmt=3D0x1800850 "%d") at /usr/src/lib/libc/stdio/snprintf.c:72 > #6 0x01800708 in handler () > Backtrace stopped: Cannot access memory at address 0xffffd760 (The "Unexpected size . . ." is a known problem in powerpc land at this = point, not tied to clang 3.8.0 .) The syslogd, nfsd, mountd, and SIGINFO-related make backtraces are = similar. I got the program above from simplifying the mountd failure = context. A direct call, handler(0), does not get the segmentation fault. I'll note that in C the handler calling snprintf or other such is a = no-no for the general case: only abort(), _Exit(), or signal() as of C99 = as I understand. But the restriction is not true of use of raise so the = small program is still valid C99 code. Of course it appears FreeBSD = allows more than C99 does in this area. I've not yet investigated what the original signals are in syslogd, = nfsd, or mountd. They may well indicate another problem. I've not gotten as far classifying (B) or (C) as well. (B) is a xo_emit context each time so far (so C elipsis use again, like = (A)) but no signal handler seems to be active. It stops in = xo_format_string_direct. My attempts at simpler code have not produced = the problem so far. (C) is such that GDB 7.10 reports "previous frame to this frame (corrupt = stack?)" or otherwise gives up. It shows Var_Value called by Make_Update = before reporting that. gdb 6.1.1 shows more after that: JobFinish, = JobReapChild, Job_CatchChildern, Job_CatchOutput, Make_Run, main). = SIGCHLD or other such use may well be involved here. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-19, at 2:35 AM, Mark Millard wrote: I now have an SSD that contains: 0) installkernel material from a gcc 4.2.1 based buildkernel 1) installworld material from a clang 3.8.0 based buildworld (clang 3.8.0, libc++, etc.) It boots and seems to be operating fine after booting --in both a G5 and = a G4 PowerMac. Apparently the clang code generation has been updated to not require an = explicit -mlongcall. I had to remove those since clang rejects them on = command lines. It linked without complaint (and later seems to be = running fine). (I've seen llvm review notes mentioning the "medium = model" or some phrase like that for powerpc.) (I've not been able to buildkernel yet for powerpc (non-64) from my = amd64 environment: rejected command lines for other issues. Thus the = current limitation to buildworld.) To get to (1) I did the following sort of sequence: (The first few steps deal with other issues in order to have sufficient = context.) A) Started by installing the latest powerpc (non-64) snapshot. ( = http://ftp1.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/FreeBSD-11.0= -CURRENT-powerpc-20160113-r293801-disc1.iso ) (I had to use a PowerMac with video hardware that vt would handle.) (Basic display, no X-windows involvement here.) B) Rebuild, including using my usual kernel configuration that has both vt and sc. I did this based on projects/clang380-import -r294201 /usr/src but still using gcc 4.2.1 (native on the PowerMac). The configuration turns off kernel debugging extras too. C) installkernel, installworld, etc., set to use sc instead of vt, and = rebooted. (As of this I could use the SSD in more PowerMacs by using sc instead = of vt via a /boot/loader.conf assignment.) D) dump/restore the file systems to another SSD (after partitioning it). Adjust the host name and the like on the copy. (This copy later ends up having new installworld materials overlaid.) E) In a projects/clang380-import -r294201 amd64 environment, buildworld = for TARGET_ARCH=3Dpowerpc . WITH_LIBCPLUSPLUS=3D and clang related = material built, gcc 4.2.1 related material not built. WITH_BOOT=3D as well. I choose WITHOUT_DEBUG=3D and WITHOUT_DEBUG_FILES=3D . (I've not tried enabling = them yet.) binutils is not from ports. F) Use DESTDIR=3D with installworld to an initially empty directory = tree. tar the tree. G) Transfer the tar file to the PowerMac. Mount the to-be-updated SSD to /mnt and /mnt/var. After chflags -R noschg on /mnt and /mnt/var use tar xpf to replace things from the buildworld on /mnt and /mnt/var. (This does leave older gcc 4.2.1 related materials in place.) H) Dismounts, shutdown, and then boot from the updated SSD. Note: I've never manage to get powerpc64-xtoolchain-gcc/powerpc64-gcc to = produce working 32-bit code. So I've never gotten this far via that = path. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sat Jan 30 11:41:00 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 83468A73C3E; Sat, 30 Jan 2016 11:41:00 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 2FF951997; Sat, 30 Jan 2016 11:40:59 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 871E41E207B7; Sat, 30 Jan 2016 12:29:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1454153353; bh=mIriWEK/Cz7pyQWuV4GheycVHVkaVJXk5NyIAjs1LWw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=SQnxg2nWT8inSJKTLfigF3aLpdkxAMqNwhw7SIp+6nZHNav4PcATfR8bKZKOgGc38 VffDlYOr6Eagk93mvRytSgwFI3GAAIHZYek9TidG0Lag2HTLxsMYPa4ApJKjUbiqo0 K/iwJF4FDBzrS9YPVIPnZKWOzwf3/XuqHlxlfFW4= Date: Sat, 30 Jan 2016 12:29:13 +0100 From: Roman Divacky To: Mark Millard Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Subject: Re: clang 3.8.0 based powerpc (32 bit) buildworld runs on a PowerMac! [problems found] Message-ID: <20160130112913.GA7950@vlakno.cz> References: <55814789-0489-48B5-867C-F678AE4EA5FF@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55814789-0489-48B5-867C-F678AE4EA5FF@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Sat, 30 Jan 2016 11:41:00 -0000 Can you file a bug in llvm bugzilla? On Sat, Jan 30, 2016 at 03:00:26AM -0800, Mark Millard wrote: > I got around to trying some more use of the 3.8.0 clang based world on powerpc (32 bit) (now -r294962 based) and ran into: > > A) Segmentation faults during signal handlers in syslogd, nfsd, mountd, and (for SIGNFO) make. > > B) ls sometimes segmentation faulting > > C) make -j 6 buildworld segmentation faulting in make eventually but make buildworld works. > > I have reduced (A) to a simple program that demonstrates the behavior: > > > # more sig_snprintf_use_test.c > > #include > > #include > > > > volatile sig_atomic_t sat = 0; > > > > void > > handler(int sig) > > { > > char uidbuf[32]; > > (void) snprintf(uidbuf, sizeof uidbuf, "%d", 10); > > sat = uidbuf[0]; > > } > > > > int > > main(void) > > { > > if (signal(SIGINT, handler) != SIG_ERR) raise(SIGINT); > > return sat; > > } > > > # ./a.out > > Segmentation fault (core dumped) > > # /usr/local/bin/gdb a.out /var/crash/a.out.1510.core > > GNU gdb (GDB) 7.10 [GDB v7.10 for FreeBSD] > . . . > > warning: Unexpected size of section `.reg2/100167' in core file. > > #0 0x419a89c8 in memcpy (dst0=0xffffd734, src0=, length=) at /usr/src/lib/libc/string/bcopy.c:124 > > 124 TLOOP1(*--dst = *--src); > > (gdb) bt > > #0 0x419a89c8 in memcpy (dst0=0xffffd734, src0=, length=) at /usr/src/lib/libc/string/bcopy.c:124 > > #1 0x419a3984 in __sfvwrite (fp=, uio=) at /usr/src/lib/libc/stdio/fvwrite.c:128 > > #2 0x41934468 in __sprint (fp=, uio=, locale=) at /usr/src/lib/libc/stdio/vfprintf.c:164 > > #3 io_flush (iop=, locale=) at /usr/src/lib/libc/stdio/printfcommon.h:155 > > #4 __vfprintf (fp=, locale=, fmt0=, ap=) at /usr/src/lib/libc/stdio/vfprintf.c:1020 > > #5 0x4199c644 in snprintf (str=0xffffd734 "", n=, fmt=0x1800850 "%d") at /usr/src/lib/libc/stdio/snprintf.c:72 > > #6 0x01800708 in handler () > > Backtrace stopped: Cannot access memory at address 0xffffd760 > > (The "Unexpected size . . ." is a known problem in powerpc land at this point, not tied to clang 3.8.0 .) > > The syslogd, nfsd, mountd, and SIGINFO-related make backtraces are similar. I got the program above from simplifying the mountd failure context. > > A direct call, handler(0), does not get the segmentation fault. > > I'll note that in C the handler calling snprintf or other such is a no-no for the general case: only abort(), _Exit(), or signal() as of C99 as I understand. But the restriction is not true of use of raise so the small program is still valid C99 code. Of course it appears FreeBSD allows more than C99 does in this area. > > I've not yet investigated what the original signals are in syslogd, nfsd, or mountd. They may well indicate another problem. > > > I've not gotten as far classifying (B) or (C) as well. > > (B) is a xo_emit context each time so far (so C elipsis use again, like (A)) but no signal handler seems to be active. It stops in xo_format_string_direct. My attempts at simpler code have not produced the problem so far. > > (C) is such that GDB 7.10 reports "previous frame to this frame (corrupt stack?)" or otherwise gives up. It shows Var_Value called by Make_Update before reporting that. gdb 6.1.1 shows more after that: JobFinish, JobReapChild, Job_CatchChildern, Job_CatchOutput, Make_Run, main). SIGCHLD or other such use may well be involved here. > > > === > Mark Millard > markmi at dsl-only.net > > On 2016-Jan-19, at 2:35 AM, Mark Millard wrote: > > I now have an SSD that contains: > > 0) installkernel material from a gcc 4.2.1 based buildkernel > > 1) installworld material from a clang 3.8.0 based buildworld > (clang 3.8.0, libc++, etc.) > > It boots and seems to be operating fine after booting --in both a G5 and a G4 PowerMac. > > Apparently the clang code generation has been updated to not require an explicit -mlongcall. I had to remove those since clang rejects them on command lines. It linked without complaint (and later seems to be running fine). (I've seen llvm review notes mentioning the "medium model" or some phrase like that for powerpc.) > > (I've not been able to buildkernel yet for powerpc (non-64) from my amd64 environment: rejected command lines for other issues. Thus the current limitation to buildworld.) > > > > To get to (1) I did the following sort of sequence: > (The first few steps deal with other issues in order to have sufficient context.) > > > A) Started by installing the latest powerpc (non-64) snapshot. > ( http://ftp1.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-powerpc-20160113-r293801-disc1.iso ) > > (I had to use a PowerMac with video hardware that vt would handle.) > (Basic display, no X-windows involvement here.) > > > B) Rebuild, including using my usual kernel configuration that has > both vt and sc. I did this based on projects/clang380-import > -r294201 /usr/src but still using gcc 4.2.1 (native on the > PowerMac). The configuration turns off kernel debugging extras too. > > > C) installkernel, installworld, etc., set to use sc instead of vt, and rebooted. > > (As of this I could use the SSD in more PowerMacs by using sc instead of vt via a /boot/loader.conf assignment.) > > > D) dump/restore the file systems to another SSD (after partitioning it). > Adjust the host name and the like on the copy. > > (This copy later ends up having new installworld materials overlaid.) > > > E) In a projects/clang380-import -r294201 amd64 environment, buildworld for > TARGET_ARCH=powerpc . WITH_LIBCPLUSPLUS= and clang related material built, > gcc 4.2.1 related material not built. WITH_BOOT= as well. I choose > WITHOUT_DEBUG= and WITHOUT_DEBUG_FILES= . (I've not tried enabling them yet.) > binutils is not from ports. > > > F) Use DESTDIR= with installworld to an initially empty directory tree. tar the tree. > > > G) Transfer the tar file to the PowerMac. Mount the to-be-updated SSD to > /mnt and /mnt/var. After chflags -R noschg on /mnt and /mnt/var use > tar xpf to replace things from the buildworld on /mnt and /mnt/var. > > (This does leave older gcc 4.2.1 related materials in place.) > > H) Dismounts, shutdown, and then boot from the updated SSD. > > > > Note: I've never manage to get powerpc64-xtoolchain-gcc/powerpc64-gcc to produce working 32-bit code. So I've never gotten this far via that path. > > > === > Mark Millard > markmi at dsl-only.net > > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-ppc@freebsd.org Sat Jan 30 13:58:05 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 6E081A7356E for ; Sat, 30 Jan 2016 13:58:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-2.reflexion.net [208.70.210.2]) (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 3495018FC for ; Sat, 30 Jan 2016 13:58:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26130 invoked from network); 30 Jan 2016 13:58:15 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 30 Jan 2016 13:58:15 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 30 Jan 2016 08:58:08 -0500 (EST) Received: (qmail 32329 invoked from network); 30 Jan 2016 13:58:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 30 Jan 2016 13:58:08 -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 B41D71C42A3; Sat, 30 Jan 2016 05:58:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 based powerpc (32 bit) buildworld runs on a PowerMac! [problems found] From: Mark Millard In-Reply-To: <20160130112913.GA7950@vlakno.cz> Date: Sat, 30 Jan 2016 05:58:02 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <55814789-0489-48B5-867C-F678AE4EA5FF@dsl-only.net> <20160130112913.GA7950@vlakno.cz> To: Roman Divacky 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: Sat, 30 Jan 2016 13:58:05 -0000 On 2016-Jan-30, at 3:29 AM, Roman Divacky wrote: > Can you file a bug in llvm bugzilla? I could try for the example code. But I'd like to make the example more = self contained first, avoiding snprintf from library code and hopefully = with a much smaller, simpler implementation involved than the = very-general library code. Separately: I'm not sure any llvm folks are going to have a way to test = unless someone shows the problem outside a FreeBSD context. = powerpc-clang (32-bit) based FreeBSD buildworld's are not exactly a = normal context at this point. My files with powerpc (32-bit) tied differences from svn for = projects/clang380-import -r294962 are: Index: /media/usr/src/sys/boot/powerpc/Makefile =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 --- /media/usr/src/sys/boot/powerpc/Makefile (revision 294962) +++ /media/usr/src/sys/boot/powerpc/Makefile (working copy) @@ -1,5 +1,9 @@ # $FreeBSD$ =20 -SUBDIR=3D boot1.chrp kboot ofw ps3 uboot +SUBDIR=3D boot1.chrp +.if ${MACHINE_ARCH} =3D=3D "powerpc64" +SUBDIR+=3D kboot +.endif +SUBDIR+=3D ofw ps3 uboot =20 .include Index: /media/usr/src/sys/conf/Makefile.powerpc =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 --- /media/usr/src/sys/conf/Makefile.powerpc (revision 294962) +++ /media/usr/src/sys/conf/Makefile.powerpc (working copy) @@ -35,7 +35,11 @@ =20 INCLUDES+=3D -I$S/contrib/libfdt =20 +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -msoft-float -Wa,-many +.else +CFLAGS+=3D -msoft-float +.endif =20 # Build position-independent kernel CFLAGS+=3D -fPIC Index: /media/usr/src/sys/conf/kern.mk =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 --- /media/usr/src/sys/conf/kern.mk (revision 294962) +++ /media/usr/src/sys/conf/kern.mk (working copy) @@ -144,7 +144,11 @@ # .if ${MACHINE_CPUARCH} =3D=3D "powerpc" CFLAGS+=3D -mno-altivec +.if ${COMPILER_TYPE} =3D=3D "clang" && ${COMPILER_VERSION} < 30800 CFLAGS.clang+=3D -mllvm -disable-ppc-float-in-variadic=3Dtrue +.else +CFLAGS.clang+=3D -msoft-float +.endif CFLAGS.gcc+=3D -msoft-float INLINE_LIMIT?=3D 15000 .endif Index: /media/usr/src/sys/conf/kmod.mk =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 --- /media/usr/src/sys/conf/kmod.mk (revision 294962) +++ /media/usr/src/sys/conf/kmod.mk (working copy) @@ -137,8 +137,12 @@ .endif =20 .if ${MACHINE_CPUARCH} =3D=3D powerpc +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -mlongcall -fno-omit-frame-pointer +.else +CFLAGS+=3D -fno-omit-frame-pointer .endif +.endif =20 .if ${MACHINE_CPUARCH} =3D=3D mips CFLAGS+=3D -G0 -fno-pic -mno-abicalls -mlong-calls (I can not actually buildkernel for powerpc via clang 3.8.0. Still some = of the above is for the kernel context.) src.conf content: KERNCONF=3DGENERICvtsc-NODEBUG TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc # WITH_FAST_DEPEND=3D WITH_LIBCPLUSPLUS=3D WITH_BOOT=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D # # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB=3D # WITHOUT_LIB32=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D On Sat, Jan 30, 2016 at 03:00:26AM -0800, Mark Millard wrote: > I got around to trying some more use of the 3.8.0 clang based world on = powerpc (32 bit) (now -r294962 based) and ran into: >=20 > A) Segmentation faults during signal handlers in syslogd, nfsd, = mountd, and (for SIGNFO) make. >=20 > B) ls sometimes segmentation faulting >=20 > C) make -j 6 buildworld segmentation faulting in make eventually but = make buildworld works. >=20 > I have reduced (A) to a simple program that demonstrates the behavior: >=20 >> # more sig_snprintf_use_test.c=20 >> #include >> #include >>=20 >> volatile sig_atomic_t sat =3D 0; >>=20 >> void >> handler(int sig) >> { >> char uidbuf[32]; >> (void) snprintf(uidbuf, sizeof uidbuf, "%d", 10); >> sat =3D uidbuf[0]; >> } >>=20 >> int >> main(void) >> { >> if (signal(SIGINT, handler) !=3D SIG_ERR) raise(SIGINT); >> return sat; >> } >=20 >> # ./a.out >> Segmentation fault (core dumped) >> # /usr/local/bin/gdb a.out /var/crash/a.out.1510.core >> GNU gdb (GDB) 7.10 [GDB v7.10 for FreeBSD] > . . . >> warning: Unexpected size of section `.reg2/100167' in core file. >> #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 >> 124 TLOOP1(*--dst =3D *--src); >> (gdb) bt >> #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 >> #1 0x419a3984 in __sfvwrite (fp=3D, uio=3D) at /usr/src/lib/libc/stdio/fvwrite.c:128 >> #2 0x41934468 in __sprint (fp=3D, uio=3D, locale=3D) at = /usr/src/lib/libc/stdio/vfprintf.c:164 >> #3 io_flush (iop=3D, locale=3D) at = /usr/src/lib/libc/stdio/printfcommon.h:155 >> #4 __vfprintf (fp=3D, locale=3D, = fmt0=3D, ap=3D) at = /usr/src/lib/libc/stdio/vfprintf.c:1020 >> #5 0x4199c644 in snprintf (str=3D0xffffd734 "", n=3D, = fmt=3D0x1800850 "%d") at /usr/src/lib/libc/stdio/snprintf.c:72 >> #6 0x01800708 in handler () >> Backtrace stopped: Cannot access memory at address 0xffffd760 >=20 > (The "Unexpected size . . ." is a known problem in powerpc land at = this point, not tied to clang 3.8.0 .) >=20 > The syslogd, nfsd, mountd, and SIGINFO-related make backtraces are = similar. I got the program above from simplifying the mountd failure = context. >=20 > A direct call, handler(0), does not get the segmentation fault. >=20 > I'll note that in C the handler calling snprintf or other such is a = no-no for the general case: only abort(), _Exit(), or signal() as of C99 = as I understand. But the restriction is not true of use of raise so the = small program is still valid C99 code. Of course it appears FreeBSD = allows more than C99 does in this area. >=20 > I've not yet investigated what the original signals are in syslogd, = nfsd, or mountd. They may well indicate another problem. >=20 >=20 > I've not gotten as far classifying (B) or (C) as well. >=20 > (B) is a xo_emit context each time so far (so C elipsis use again, = like (A)) but no signal handler seems to be active. It stops in = xo_format_string_direct. My attempts at simpler code have not produced = the problem so far. >=20 > (C) is such that GDB 7.10 reports "previous frame to this frame = (corrupt stack?)" or otherwise gives up. It shows Var_Value called by = Make_Update before reporting that. gdb 6.1.1 shows more after that: = JobFinish, JobReapChild, Job_CatchChildern, Job_CatchOutput, Make_Run, = main). SIGCHLD or other such use may well be involved here. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Jan-19, at 2:35 AM, Mark Millard wrote: >=20 > I now have an SSD that contains: >=20 > 0) installkernel material from a gcc 4.2.1 based buildkernel >=20 > 1) installworld material from a clang 3.8.0 based buildworld > (clang 3.8.0, libc++, etc.) >=20 > It boots and seems to be operating fine after booting --in both a G5 = and a G4 PowerMac. >=20 > Apparently the clang code generation has been updated to not require = an explicit -mlongcall. I had to remove those since clang rejects them = on command lines. It linked without complaint (and later seems to be = running fine). (I've seen llvm review notes mentioning the "medium = model" or some phrase like that for powerpc.) >=20 > (I've not been able to buildkernel yet for powerpc (non-64) from my = amd64 environment: rejected command lines for other issues. Thus the = current limitation to buildworld.) >=20 >=20 >=20 > To get to (1) I did the following sort of sequence: > (The first few steps deal with other issues in order to have = sufficient context.) >=20 >=20 > A) Started by installing the latest powerpc (non-64) snapshot. > ( = http://ftp1.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/FreeBSD-11.0= -CURRENT-powerpc-20160113-r293801-disc1.iso ) >=20 > (I had to use a PowerMac with video hardware that vt would handle.) > (Basic display, no X-windows involvement here.) >=20 >=20 > B) Rebuild, including using my usual kernel configuration that has > both vt and sc. I did this based on projects/clang380-import > -r294201 /usr/src but still using gcc 4.2.1 (native on the > PowerMac). The configuration turns off kernel debugging extras too. >=20 >=20 > C) installkernel, installworld, etc., set to use sc instead of vt, and = rebooted. >=20 > (As of this I could use the SSD in more PowerMacs by using sc instead = of vt via a /boot/loader.conf assignment.) >=20 >=20 > D) dump/restore the file systems to another SSD (after partitioning = it). > Adjust the host name and the like on the copy. >=20 > (This copy later ends up having new installworld materials overlaid.) >=20 >=20 > E) In a projects/clang380-import -r294201 amd64 environment, = buildworld for > TARGET_ARCH=3Dpowerpc . WITH_LIBCPLUSPLUS=3D and clang related = material built, > gcc 4.2.1 related material not built. WITH_BOOT=3D as well. I choose > WITHOUT_DEBUG=3D and WITHOUT_DEBUG_FILES=3D . (I've not tried = enabling them yet.) > binutils is not from ports. >=20 >=20 > F) Use DESTDIR=3D with installworld to an initially empty directory = tree. tar the tree. >=20 >=20 > G) Transfer the tar file to the PowerMac. Mount the to-be-updated SSD = to > /mnt and /mnt/var. After chflags -R noschg on /mnt and /mnt/var use > tar xpf to replace things from the buildworld on /mnt and /mnt/var. >=20 > (This does leave older gcc 4.2.1 related materials in place.) >=20 > H) Dismounts, shutdown, and then boot from the updated SSD. >=20 >=20 >=20 > Note: I've never manage to get powerpc64-xtoolchain-gcc/powerpc64-gcc = to produce working 32-bit code. So I've never gotten this far via that = path. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" =3D=3D=3D Mark Millard markmi at dsl-only.net