We're testing the Intel C++ compiler to see how well it builds our modestly large software system. We build on both windows and linux (64-bit only). It seems to work OK for most of the software. However, I'm having a problem with a bit of code which uses the Boost Spirit parser generator. In particular, this parser uses Spirit "Classic" from Boost 1.47.0. Perhaps see http://www.boost.org/doc/libs/1_47_0/libs/spirit/classic/index.html for some documentation. In brief, Spirit makes heavy use of operator overloading, templates and metaprogramming techniques to allow you write something which vaguely resembles a BNR representation of your grammar directly in C++. It's neat but it seems to put a lot of stress on the compiler.
We have a couple of parsers written with Spirit; one of them is failing to accept a well-formed input file when compiled with Intel C++ on windows using 220.127.116.11 Build 20130728. On linux, icpc 13.1.3 20130607 is able to build the parser without difficulty and it passes all our regression testing. (And, for what it's worth, build's using GCC 4.x and MSVC 16.00.x pass our regressions OK, too.)
I have attached the source code for a simplified version of our parser. There are two issues I would like to report about 18.104.22.168 Build 20130728:
1. When icl compiles the example program, it produces a mountain of warnings of the form:
c:\vendors\x64-windows\boost-1.47.0\include\boost-1_47\boost/detail/compressed_pair.hpp(51): warning #2586: \'value\' : decorated name length exceeded, name was truncated
It still seems to compile the file OK, but icpc (on linux) doesn't report this warning. In my example program, I added #pragma warning(disable:2586).
2. Running the NMakefile on windows builds three different variants on the code:
A. example_works.exe uses a slightly abbreviated expression for one of the two parsers in the source. This version of the example code works OK; it parses the file properly. However, the object which is abbreviated is not actually used by the parser! I just commented out a single production in an unused object and it passes the test.
B. example_fails.exe activates the production commented out above and the resulting program fails to parse the input file.
C. example_fails_gdb.exe compiles version B with no optimization, but including the extra production; this executable passes the test.
You need to have Boost installed to build the example program and will probably need to set BOOST_INCLUDE_DIR in the NMakefile. The examples can be built and run with "nmake -f NMakefile CXX=icl".