From owner-freebsd-toolchain@FreeBSD.ORG Tue Mar 24 05:47:27 2015 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 55EB2B64 for ; Tue, 24 Mar 2015 05:47:27 +0000 (UTC) Received: from asp.reflexion.net (outbound-241.asp.reflexion.net [69.84.129.241]) (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 D061BC6F for ; Tue, 24 Mar 2015 05:47:25 +0000 (UTC) Received: (qmail 1067 invoked from network); 24 Mar 2015 05:47:19 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 24 Mar 2015 05:47:19 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.40.1) with SMTP; Tue, 24 Mar 2015 01:47:19 -0400 (EDT) Received: (qmail 26159 invoked from network); 24 Mar 2015 05:47:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Mar 2015 05:47:18 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-67-189-19-145.hsd1.or.comcast.net [67.189.19.145]) by iron2.pdx.net (Postfix) with ESMTPSA id 87ED21C43A2; Mon, 23 Mar 2015 22:47:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import [what N2255 suggests] From: Mark Millard In-Reply-To: <96AD8046-52B1-455F-A07B-39FA8CADF80D@dsl-only.net> Date: Mon, 23 Mar 2015 22:47:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <96AD8046-52B1-455F-A07B-39FA8CADF80D@dsl-only.net> To: rodrigc@FreeBSD.org, Dimitry Andric X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, FreeBSD PowerPC ML X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 05:47:27 -0000 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2255.html has = the following note about std::is_convertible : > Library implementor's note: Except for the protected/private access = checks, and the ambiguity checks, this specification is completely = implementable in C++03 (even without rvalue references). However it is = intended that this be implemented with compiler help to get the access = and ambiguity checks correct. This note would seem to apply to examples like Richard Smith's tiny test = case listed in https://llvm.org/bugs/show_bug.cgi?id=3D22771 : > Here's a testcase that fails with Clang: >=20 > #define __has_feature(x) 0 > #include > class X { X(const X&); }; > bool b =3D std::is_convertible::value; >=20 > (Using a public deleted copy constructor fails similarly.) It sounds like there are going to be limitations to any library-only = solution (i.e., to any fallback implementation of std::is_convertible). So for a failing fallback test example to matter likely requires that = the failure not depend on accessibility checks or ambiguity checks. Might it be that the improvement that was being tested is sufficient = given the general limitations on library-only code solutions? Going the other way: if one wants code (such as llvm/clang source) to = survive environments that need to use a library-only fallback then that = code needs to avoid depending on accessibility or ambiguity properties = for its direct or indirect use of std::is_convertible. I do not know = what criteria llvm/clang uses for such issues. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2015-Mar-22, at 09:56 PM, Mark Millard = wrote: I'd sent out a note Saturday for this for powerpc64-xtoolchain-gcc and = its powerpc64-gcc port: use of CROSS_TOOLCHAIN=3Dpowerpc64-gcc used on a = powerpc64. No solution, just notes about what was going on after looking = at the source code related to the messages. If you care, see: > CROSS_TOOLCHAIN=3Dpowerpc64-gcc mishandles "Substitution Failure Is = Not An Error" when compiling clang and stops the build ( = https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001506.ht= ml ) > = sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T= 1>())) > =3D=3D 1 is the core place involved in your example and mine but the order of = compilation for my context means a different starting place that ended = up using the above. lang/gcc5 did the same when I later tried it. I doubt that host-type or TARGET or TARGET_ARCH matter. I doubt = xtoolchain vs. normal port matters. I expect that the issue spans a = range of g++ versions. Unfortunately that probably also means that the effectively = "Substitution Failure of this kind Is An Error" rule now in use will = probably be around for a while: it is likely not some local accident = that has a quick fix. The best case is if it is simple but each = version/variant needs to release with the change. =3D=3D=3D Mark Millard markmi at dsl-only.net