I'm running:
$ gcc-4.7 --version
gcc-4.7 (Ubuntu/Linaro 4.7.3-2ubuntu1~12.04) 4.7.3
This is running on Ubuntu 12.04.
On Thu, Mar 20, 2014 at 3:06 PM, Andrey Semashev
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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost