From owner-freebsd-toolchain@freebsd.org Sun Jan 24 06:17:35 2016 Return-Path: Delivered-To: freebsd-toolchain@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 5B306A8FEB1 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 1FD001EEB for ; Sun, 24 Jan 2016 06:17:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9736 invoked from network); 24 Jan 2016 06:17:29 -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:29 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Sun Jan 24 07:05:03 2016 Return-Path: Delivered-To: freebsd-toolchain@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 519DEA8EE05 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 12A5113D1 for ; Sun, 24 Jan 2016 07:05:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3583 invoked from network); 24 Jan 2016 07:05:12 -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:12 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Sun Jan 24 11:20:33 2016 Return-Path: Delivered-To: freebsd-toolchain@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 C9EDC759D 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 847073D8 for ; Sun, 24 Jan 2016 11:20:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3472 invoked from network); 24 Jan 2016 11:20:30 -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:30 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Sun Jan 24 17:20:43 2016 Return-Path: Delivered-To: freebsd-toolchain@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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Sun Jan 24 20:40:01 2016 Return-Path: Delivered-To: freebsd-toolchain@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 99CD87117 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 58DFD10AE for ; Sun, 24 Jan 2016 20:40:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 21585 invoked from network); 24 Jan 2016 20:39:58 -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:39:58 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Mon Jan 25 01:00:11 2016 Return-Path: Delivered-To: freebsd-toolchain@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 F0134A3133F 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 A7C44617 for ; Mon, 25 Jan 2016 01:00:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17692 invoked from network); 25 Jan 2016 01:00:21 -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:21 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Mon Jan 25 01:43:44 2016 Return-Path: Delivered-To: freebsd-toolchain@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 27CCB723F 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 DEC3E666 for ; Mon, 25 Jan 2016 01:43:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5120 invoked from network); 25 Jan 2016 01:43:43 -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:43 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Mon Jan 25 02:22:45 2016 Return-Path: Delivered-To: freebsd-toolchain@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 50FE47E8E for ; Mon, 25 Jan 2016 02:22:45 +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 0754F1E6 for ; Mon, 25 Jan 2016 02:22:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9355 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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-toolchain@freebsd.org Sat Jan 30 11:27:08 2016 Return-Path: Delivered-To: freebsd-toolchain@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 9BA54A73774 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 5DDE01171 for ; Sat, 30 Jan 2016 11:27:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10476 invoked from network); 30 Jan 2016 11:00:26 -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:26 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 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-toolchain@freebsd.org Sat Jan 30 11:41:00 2016 Return-Path: Delivered-To: freebsd-toolchain@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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 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-toolchain@freebsd.org Sat Jan 30 13:58:05 2016 Return-Path: Delivered-To: freebsd-toolchain@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 6E1B0A7356F 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 349AA18FD for ; Sat, 30 Jan 2016 13:58:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9585 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 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