I am using VS 2017 Community edition, Intel Compiler 17.00 update 6 and and boost 1.66, trying to learn my way around boost::multiprecision::float128. Literally taking the example code from here and putting it in a new project for VS.
Compiling gives multiple errors, in roughly two categories/files:
In float128.hpp:
three errors of "error : identifier "xxx" is undefined" for fmaq, remquoq and remainderq. Indeed I am not able to find definitions for them - a missing include?
the global scope has no "signbitq" - this again looks like missing definition (i.e. the same as above)
For GCC the above functions are found within quadmath.h, however, the boost header doesn't seem to include it when using ICC (i.e BOOST_MP_USE_QUAD is set).
I assume that i need to remove something that has been put in by default from the VS, but I am at a loss what exactly.
Thank you for your help
EDIT: Errors #2 above are actually not against boost at all (should I move this to a separate question?). The following code copied from here! is not being compiled in my setup:
#include <iostream>
#include <string>
int main() {
std::string str("Test string");
for (std::string::iterator it = str.begin(); it != str.end(); ++it)
std::cout << *it;
std::cout << '\n';
return 0;
}
The exact error (one of them) is:
1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\xutility(680): error : an explicit template argument list is not allowed on this declaration
1> _INLINE_VAR constexpr bool _Is_iterator_v<_Ty, void_t<_Iter_cat_t<_Ty>>> = true;
1> ^
1> detected during:
1> instantiation of "const bool std::_Is_iterator_v [with _Ty=char *, <unnamed>=void]" at line 520 of "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\string"
1> instantiation of "std::basic_string<_Elem, std::char_traits<_Elem>, std::allocator<_Elem>> std::_Integral_to_string<_Elem,_Ty>(_Ty) [with _Elem=char, _Ty=int]" at line 554 of "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\include\string"
I found this which indicates that there could be a problem with the particular versions used (ICC- 17.0 Up6 and VS 15.6), however i cannot really move to new intel compiler and i cannot test VS 15.4
I would like to write down how I managed to deal with error #2 from the original question, as it might be useful to someone.
Just as a reminder, the second errors I was seeing were in xutility. With the help of everyone that provided suggestions, it turned out that icc was in fact failing on very simple code - the following is enough to "break" it
int main() {
std::string str("Test string");
}
I have posted the question to intel's forums, however so far I have not received answers (for the 17.0 version of the compiler). Link here if anyone is interested.
That said, I came upon this blog post from the VC++ team, showing that the base toolset shown as v141 in VC2017 actually has had several minor revisions. It is possible to change the version of the MSVC toolchain but this needs to happen via editing of project files (rather than UI parameter changes).
My testing shows that version 14.11 (which is part of VS2017 15.3 and 15.4) works for Intel 17.0 while versions 14.12 and 14.13 (the last one is the current default for VS2017 15.6.4) do not. This has been done for Update 6 of the compiler. So in order to use the intel compiler on windows with visual studio, one needs to use particular MSVC toolchain versions.
Side note: I also installed icc version 18.0 update 1 for testing -- it too was giving compiler errors (and not just for me this time). The reason there though can be linked to some internal issue for icc, per this forum post. I can confirm that removing the compiler option /permissive- from the compiler fixes the errors irrespective of the base toolchain. Using v14.11 as base toolchain also fixes this particular problem for me with or without the option. /permissive- is a new option for icc (it is not part of 17.0).
The above solves more or less the second part of my problem with the icc. The rest of the question (boost's float128) though still remains. I will add more if i hear from boost's guys.
EDIT: the errors coming from boost turned out to be an issue there -- it was fixed by the maintainers in development branch, so this is resolved as well.