boyer_moore.hpp fails on Linux w/ gcc-4.7.2, OK with Mac clang

[boost@…]

I have a simple find-string-in-file program that uses boyer_moore matching. On Mac, it compiles and works OK. (Not sure if Mac is really using gcc; that's the command name, but "gcc -v" says "Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)"

At any rate, the same code, with a freshly-compiled Boost-1.56.0 on Debian 7, gcc-4.7.2, fails to compile:

g++ -g   -I. -I/usr/local/include   -c -o find.o find.cc
In file included from /usr/local/include/boost/range/iterator.hpp:24:0,
                 from /usr/local/include/boost/range/begin.hpp:24,
                 from /usr/local/include/boost/algorithm/searching/boyer_moore.hpp:18,
                 from find.cc:5:
/usr/local/include/boost/mpl/eval_if.hpp: In instantiation of ‘struct boost::mpl::eval_if_c<false, boost::range_const_iterator<const unsigned char*, void>, boost::range_mutable_iterator<const unsigned char*, void> >’:
/usr/local/include/boost/range/iterator.hpp:69:17:   required from ‘struct boost::range_iterator<const unsigned char*, void>’
/usr/local/include/boost/algorithm/searching/boyer_moore.hpp:243:5:   required by substitution of ‘template<class PatternRange, class CorpusRange> typename boost::range_iterator<CorpusRange>::type boost::algorithm::boyer_moore_search(CorpusRange&, const PatternRange&) [with PatternRange = const unsigned char*; CorpusRange = const unsigned char*]’
find.cc:26:106:   required from here
/usr/local/include/boost/mpl/eval_if.hpp:60:31: error: no type named ‘type’ in ‘boost::mpl::eval_if_c<false, boost::range_const_iterator<const unsigned char*, void>, boost::range_mutable_iterator<const unsigned char*, void> >::f_ {aka struct boost::range_mutable_iterator<const unsigned char*, void>}’
make: *** [find.o] Error 1

(On Mac also, I compiled a fresh copy of Boost-1.56.0 using the native compiler.)

[Marshall Clow]

(Not sure if Mac is really using gcc; that's the command name, but "gcc -v" says "Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)"

Yeah, on Mac OS starting with 10.9 (I think), gcc is just an alias to clang.

Do you have a small case that fails?

Looking at the test results, the tests for boyer-moore seem to be passing on most of the linux testers, though non of them are using 4.7.2 (some are using newer versions, some are older).

[boost@…]

Small test case that fails to compile on Linux w/ g++-4.7.2

[boost@…]

That program compiles & runs on Mac w/ clang, but not on Linux:

user@aluminum-debian:/var/tmp$ g++ -v bmtest.cc
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE bmtest.cc -quiet -dumpbase bmtest.cc -mtune=generic -march=x86-64 -auxbase bmtest -version -o /tmp/ccrt5zzG.s
GNU C++ (Debian 4.7.2-5) version 4.7.2 (x86_64-linux-gnu)
	compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.7
 /usr/include/c++/4.7/x86_64-linux-gnu
 /usr/include/c++/4.7/backward
 /usr/lib/gcc/x86_64-linux-gnu/4.7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++ (Debian 4.7.2-5) version 4.7.2 (x86_64-linux-gnu)
	compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 66d178dd81da8c975e003e06d9f5e782
In file included from /usr/local/include/boost/range/iterator.hpp:24:0,
                 from /usr/local/include/boost/range/begin.hpp:24,
                 from /usr/local/include/boost/algorithm/searching/boyer_moore.hpp:18,
                 from bmtest.cc:2:
/usr/local/include/boost/mpl/eval_if.hpp: In instantiation of ‘struct boost::mpl::eval_if_c<false, boost::range_const_iterator<const char*, void>, boost::range_mutable_iterator<const char*, void> >’:
/usr/local/include/boost/range/iterator.hpp:69:17:   required from ‘struct boost::range_iterator<const char*, void>’
/usr/local/include/boost/algorithm/searching/boyer_moore.hpp:243:5:   required by substitution of ‘template<class PatternRange, class CorpusRange> typename boost::range_iterator<CorpusRange>::type boost::algorithm::boyer_moore_search(CorpusRange&, const PatternRange&) [with PatternRange = const char*; CorpusRange = const char*]’
bmtest.cc:12:63:   required from here
/usr/local/include/boost/mpl/eval_if.hpp:60:31: error: no type named ‘type’ in ‘boost::mpl::eval_if_c<false, boost::range_const_iterator<const char*, void>, boost::range_mutable_iterator<const char*, void> >::f_ {aka struct boost::range_mutable_iterator<const char*, void>}’

[boost@…]

FWIW, it looks like the section of eval_if where the error occurs already has some BOOST_WORKAROUND hackery going on. Maybe it just needs to know about quirks in gcc-4.7.2?

[Marshall Clow]

I don't have 4.7.x laying around, but I was able to replicate this with 4.8.1 and 4.9.1 (both on Mac OS X)

It appears that gcc is trying to instantiate the two argument version of boyer_moore_search(line 243), which is failing, and then rather than dropping that from the overload set, it is generating an error.

If I comment out the range based-version (aka the two argument one), then your test compiles and runs.

[boost@…]

Thanks, that helps! (I was compiling 4.9.1 just now...figured I'd give it a try! But I'd rather not wander off into gcc-version-incompatibility hell.)

I commented out the same section of boyer_moore.hpp (lines 240-249) and also had success.

Thanks very much!