From owner-freebsd-toolchain@freebsd.org  Sun Jan 24 06:17:35 2016
Return-Path: <owner-freebsd-toolchain@freebsd.org>
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 <freebsd-toolchain@mailman.ysv.freebsd.org>;
 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 <freebsd-toolchain@freebsd.org>; 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 <markmi@dsl-only.net>
In-Reply-To: <5B511209-F26D-4788-B80B-E0328963C263@FreeBSD.org>
Date: Sat, 23 Jan 2016 22:17:27 -0800
Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>,
 FreeBSD Toolchain <freebsd-toolchain@freebsd.org>
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 <dim@FreeBSD.org>
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
 <freebsd-toolchain.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-toolchain>, 
 <mailto:freebsd-toolchain-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-toolchain/>
List-Post: <mailto:freebsd-toolchain@freebsd.org>
List-Help: <mailto:freebsd-toolchain-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain>, 
 <mailto:freebsd-toolchain-request@freebsd.org?subject=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 <class _Cp>
> inline _LIBCPP_INLINE_VISIBILITY
> typename _Cp::iterator
> begin(_Cp& __c)
> {
>     return __c.begin();
> }
>=20
> template <class _Cp>
> inline _LIBCPP_INLINE_VISIBILITY
> typename _Cp::const_iterator
> begin(const _Cp& __c)
> {
>     return __c.begin();
> }
>=20
> template <class _Cp>
> inline _LIBCPP_INLINE_VISIBILITY
> typename _Cp::iterator
> end(_Cp& __c)
> {
>     return __c.end();
> }
>=20
> template <class _Cp>
> inline _LIBCPP_INLINE_VISIBILITY
> typename _Cp::const_iterator
> end(const _Cp& __c)
> {
>     return __c.end();
> }


Manually forced replacement with modern source:

> template <class _Cp>
> inline _LIBCPP_INLINE_VISIBILITY
> auto
> begin(_Cp& __c) -> decltype(__c.begin())
> {
>     return __c.begin();
> }
>=20
> template <class _Cp>
> inline _LIBCPP_INLINE_VISIBILITY
> auto
> begin(const _Cp& __c) -> decltype(__c.begin())
> {
>     return __c.begin();
> }
>=20
> template <class _Cp>
> inline _LIBCPP_INLINE_VISIBILITY
> auto
> end(_Cp& __c) -> decltype(__c.end())
> {
>     return __c.end();
> }
>=20
> template <class _Cp>
> 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 <class _Cp>
> inline _LIBCPP_INLINE_VISIBILITY
> auto
> begin(_Cp& __c) -> decltype(__c.begin())
> {
>     return __c.begin();
> }
>=20
> template <class _Cp>
> inline _LIBCPP_INLINE_VISIBILITY
> auto
> begin(const _Cp& __c) -> decltype(__c.begin())
> {
>     return __c.begin();
> }
>=20
> template <class _Cp>
> inline _LIBCPP_INLINE_VISIBILITY
> auto
> end(_Cp& __c) -> decltype(__c.end())
> {
>     return __c.end();
> }
>=20
> template <class _Cp>
> 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 <class _Cp>
> inline _LIBCPP_INLINE_VISIBILITY
> typename _Cp::iterator
> begin(_Cp& __c)
> {
>     return __c.begin();
> }
>=20
> template <class _Cp>
> inline _LIBCPP_INLINE_VISIBILITY
> typename _Cp::const_iterator
> begin(const _Cp& __c)
> {
>     return __c.begin();
> }
>=20
> template <class _Cp>
> inline _LIBCPP_INLINE_VISIBILITY
> typename _Cp::iterator
> end(_Cp& __c)
> {
>     return __c.end();
> }
>=20
> template <class _Cp>
> 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 <typename IteratorT>
>   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 <class T> iterator_range<T> make_range(T x, T y) {
>     return iterator_range<T>(x, y);
>   }
>=20
>   template <typename ContainerTy>
>   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_iterator> 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 <string>, 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 <dim@FreeBSD.org> wrote:

On 23 Jan 2016, at 12:25, Mark Millard <markmi@dsl-only.net> 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<clang::CFG> =
{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