CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import [what N2255 suggests]

[Mark Millard]

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=22771 :

> Here's a testcase that fails with Clang:
> 
>  #define __has_feature(x) 0
>  #include <type_traits>
>  class X { X(const X&); };
>  bool b = std::is_convertible<const X&, X>::value;
> 
> (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.

===
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=powerpc64-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=powerpc64-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.html )



> sizeof(__is_convertible_imp::__test<_T2>(__is_convertible_imp::__source<_T1>()))
>     == 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.


===
Mark Millard
markmi at dsl-only.net