Date: Mon, 23 Mar 2015 22:47:16 -0700 From: Mark Millard <markmi@dsl-only.net> To: rodrigc@FreeBSD.org, Dimitry Andric <dim@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import [what N2255 suggests] Message-ID: <E1513AF1-22CB-4481-82F6-2A27AF37C852@dsl-only.net> In-Reply-To: <96AD8046-52B1-455F-A07B-39FA8CADF80D@dsl-only.net> References: <96AD8046-52B1-455F-A07B-39FA8CADF80D@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <type_traits> > class X { X(const X&); }; > bool b =3D std::is_convertible<const X&, X>::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 <markmi at dsl-only.net> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1513AF1-22CB-4481-82F6-2A27AF37C852>