Boost logo

Boost :

Subject: Re: [boost] Teeks GCC test failures - multiprecision, spirit and others
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-03-20 16:06:27

On Thursday 20 March 2014 19:32:22 John Maddock wrote:
> There are a lot of inscrutable failures from the Teeks machines running
> GCC on linux that I'm unable to reproduce (and aren't reproduced by
> other testers), for example:
>> Ubuntu12-04-64-boost-bin-v2-libs-multiprecision-test-ublas5_et-test-gcc-4-7-
> debug.html
> All the failures refer to is_convertible, and have an instantiation back
> trace that leads nowhere (a line that doesn't instantiate anything, and
> which refers to Boost.Range which multiprecision doesn't use). I see
> similar failures in the spirit tests as well. Is anyone able to
> reproduce these? Any ideas what may be going on? The failures are on
> the master branch as well if that helps.

I can't reproduce it on my local machine (gcc 4.7.3 on Ubuntu 13.10), but it's
possible that my gcc is not the same as the one the tester uses.

My guess is that this may be a compiler problem. Your code includes
range/iterator_range_core.hpp indirectly via lexical_cast.hpp, which is
included in multiprecision/detail/number_base.hpp. (Hint: You can add -H
switch to gcc command line in the error log to track down the include chain.)

I think that the problem could be that FP_NAN and/or FP_INFINITE are declares
as anonymous enum constants. The compiler tries to find operator== through ADL
and finds templated boost::operator== from Boost.Range and tries to
instantiate it with the anonymous enum type and breaks. Again, this is just my
guess. You could try to work it around by explicitly casting the constants to

Boost list run by bdawes at, gregod at, cpdaniel at, john at