Teeks GCC test failures - multiprecision, spirit and others
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-... 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. Many thanks, John.
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.
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
Hello, I have run multiprecision tests on the same configuration (i get the same output if i am gcc --version) and I can confirm there are some compile errors. However, the error log is too big and I can't tell you exactly if it is the same test (ublas5_et). Also, I don't know how to run only this test. If I try to run b2 ublas5_et I get the following message. ...patience... ...found 1106 targets... If anyone can help me to run only this test maybe I can provide more specific information. Thank you, Cosmin Boaca
Hello,
I have run the whole test suite again and it appeared that the compile
errors were from the tests that should have failed. I am sorry for false
alarm.
Cosmin Boaca
On 21 March 2014 00:48, Cosmin Boaca
Hello,
I have run multiprecision tests on the same configuration (i get the same output if i am gcc --version) and I can confirm there are some compile errors. However, the error log is too big and I can't tell you exactly if it is the same test (ublas5_et). Also, I don't know how to run only this test. If I try to run b2 ublas5_et I get the following message. ...patience... ...found 1106 targets... If anyone can help me to run only this test maybe I can provide more specific information.
Thank you, Cosmin Boaca
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.
Will do, if that's the cause it's a pretty evil failure to track down, and many thanks for the hint! John.
participants (5)
-
Andrey Semashev -
Cosmin Boaca -
John Maddock -
John Maddock -
Tom Kent