Re: [boost] Teeks GCC test failures - multiprecision, spirit and others

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:
> http://www.boost.org/development/tests/develop/developer/output/teeks99-03d-> 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 
int.