0

boost/mpl/list.hpp has the following code:

#if !defined(BOOST_NEEDS_TOKEN_PASTING_OP_FOR_TOKENS_JUXTAPOSING)
#   define AUX778076_LIST_HEADER \
    BOOST_PP_CAT(list,BOOST_MPL_LIMIT_LIST_SIZE).hpp \
    /**/
#else
#   define AUX778076_LIST_HEADER \
    BOOST_PP_CAT(list,BOOST_MPL_LIMIT_LIST_SIZE)##.hpp \
    /**/
#endif

#   include BOOST_PP_STRINGIZE(boost/mpl/list/AUX778076_LIST_HEADER)
#   undef AUX778076_LIST_HEADER
#endif

When I tried compiling it with the Vivado HLS C++ compiler, I get an error:

/usr/include/boost/mpl/list.hpp:36:13: fatal error: 'boost/mpl/list/list20.hpp /**/' file not found
#   include BOOST_PP_STRINGIZE(boost/mpl/list/AUX778076_LIST_HEADER)

I concluded that the preprocessor appends the empty comment /**/ to the filename being included. Removing it (with the preceding line's backslash \) solves the issue, although there are many other such empty comments causing new errors.

Why does the AUX778076_LIST_HEADER macro have this empty comment to begin with? Is it correct to expect BOOST_PP_STRINGIZE to remove it?

haggai_e
  • 4,689
  • 1
  • 24
  • 37
  • We can only guess that there is *some other* compiler that will fail if the empty comment is removed. – Bo Persson Sep 27 '17 at 09:05
  • It's possible. Another guess would be that this is a convention to reduce line changes when changing a macro, like having a comma after the last enum value. – haggai_e Sep 27 '17 at 14:06
  • 1
    There's a `-CC` option to the GCC C preprocessor which causes this behaviour and I'm assuming there is some reason that HLS sets it. I use the following pretty horrible `sed` to strip out all of the offending comments - hope it helps someone. `find -name "*.hpp" -exec sed ':start /\\$/{N; s/\\$/\\/; t start; s:\\\n */\*\*/ *$::;}' -i '{}' ';'` – Peter Ogden Oct 12 '17 at 14:40
  • HLS does pass the `-CC` option to gcc, when invoking it for clang. It is seen for example in the `autopilot.flow.log` file: `Source preprocessing: exec clang -fno-limit-debug-info -gcc-toolchain "/opt/Xilinx/Vivado_HLS/2016.2/lnx64/tools/gcc" -hls -fno-exceptions -D__llvm__ -CC -E ...` Perhaps this is needed for clang to generate correct line numbers? – haggai_e Dec 24 '17 at 09:55

0 Answers0