I am the current maintainer, and a past contributor, of the Boost preprocessor library, known as Boost PP for short. In running the tests for Boost PP with the Intel C++ compiler for Windows 19.0, and seeing a single test failure, I discovered a preprocessor bug in the Intel compiler. Before I show the bug let me explain that Boost PP, while supporting the C++ standard preprocessors of compilers such as gcc and clang, also supports through a number of workarounds in the Boost PP code the non-standard preprocessor of Visual C++. Since Intel C++ on Windows emulates the preprocessing of Visual C++ the Boost PP library also supports Intel C++ for Windows by treating it with the exact same workarounds as Visual C++ in the Boost PP code. Therefore the bug I am about to show, which is a reduced example of the single failed Boost PP library test using Intel C++ for Windows, needs to be compared to the equivalent Visual C++ compiler output to most easily see that it is a bug in the Intel C++ for Windows preprocessor. This reduced example uses none of the code in the Boost PP library but can be run on its own.
The code is:
#define TRANSFORM_A(m,e) m(LPAREN() COMMA() TRANSFORM_A_ID) #define TRANSFORM_B(m,e) m(RPAREN() TRANSFORM_B_ID) #define TRANSFORM_A_ID() TRANSFORM_A #define TRANSFORM_B_ID() TRANSFORM_B #define TRANSFORM_REM(data) data #define EAT(...) #define LPAREN() ( #define RPAREN() ) #define COMMA() , TRANSFORM_A (TRANSFORM_REM, )() (EAT, ?) NIL TRANSFORM_B (TRANSFORM_REM, )() (EAT, ?)
When the above line becomes expanded using Intel C++ for Windows 19.0 with vc14.1 ( VS2017 ) compatibility, the result is incorrectly:
( NIL )
Using Visual C++ 14.1 ( VS2017 ) the expanded code is correctly:
( , NIL )
Both gcc and clang, as well as Intel C++ for Linux, expand the code correctly.
My command line switches when running the Intel C++ for Windows 19.0 compiler are:
-TP /Z7 /Od /Ob0 /W3 /GR /MDd /Zc:forScope /Zc:wchar_t /nologo /Qwn5 /Qwd985 -Qoption,c,--arg_dep_lookup /Qvc14.1 -Qpchi- /wd4675 /EHs -c
The incorrect preprocessor output also occurs in Intel 17.0 and Intel 18.0, for Windows. The Intel C++ for Linux 19.0 compiler, which does intend to implement a C++ standard preprocessor, runs the Boost PP tests without any errors and produces the correct output in the above case.
Let me reiterate that while the code above seems artificial it does occur in very similar form in the Boost PP library when implementing one of the pieces of functionality in that library, and is the reason for the single instance of a failing test when running the Boost PP tests with the Intel C++ compiler for Windows. For those who are really interested the failing case in the Boost PP tests for Intel C++ for Windows occurs when running 'BOOST_PP_SEQ_TO_LIST(())', where the output with Intel C++ for Windows is '( BOOST_PP_NIL )' instead of the correct '( , BOOST_PP_NIL )'.
If you need a full source file showing the bug using the code above I can supply a .cpp file, but you should be able to set one up for yourself from the code above. At what point the expansion of the macros fails to expand correctly I can not tell. If Intel C++ for Windows had a program/tool which was able to show its own step by step expansion of a macro I could have found out exactly where the preprocessor was failing, but unfortunately Intel C++, along with every other compiler, offers no such tool.