no match for ‘operator!=’ in ‘i != std::vector<_Tp, _Alloc>::rend() [with _Tp = re2c::bitmap_t, _Alloc = std::allocator<re2c::bitmap_t>]()’

[ryandesign]

Hello, I'm a developer with the MacPorts package management system, and I noticed that re2c 1.0.2 does not build on Mac OS X 10.5.8 with its gcc version 4.2.1 (Apple Inc. build 5577). The error is:

depbase=`echo src/code/bitmap.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
	/usr/bin/g++-4.2 -DHAVE_CONFIG_H -I.   -I/opt/local/include -std=c++98  -W  -Wall  -Wextra  -Weffc++  -pedantic  -Wformat=2  -Wredundant-decls  -Wconversion  -O2  -pipe -Os -arch ppc -MT src/code/bitmap.o -MD -MP -MF $depbase.Tpo -c -o src/code/bitmap.o src/code/bitmap.cc &&\
	mv -f $depbase.Tpo $depbase.Po
In file included from ./src/conf/warn.h:9,
                 from ./src/conf/opt.h:9,
                 from ./src/code/output.h:14,
                 from ./src/code/go.h:8,
                 from src/code/bitmap.cc:5:
./src/util/free_list.h: In instantiation of ‘re2c::free_list<re2c::Code*>’:
./src/re/rule.h:32:   instantiated from here
./src/util/free_list.h:11: warning: base class ‘class std::set<re2c::Code*, std::less<re2c::Code*>, std::allocator<re2c::Code*> >’ has a non-virtual destructor
src/code/bitmap.cc: In member function ‘void re2c::bitmaps_t::insert(const re2c::Go*, const re2c::State*)’:
src/code/bitmap.cc:30: error: no match for ‘operator!=’ in ‘i != std::vector<_Tp, _Alloc>::rend() [with _Tp = re2c::bitmap_t, _Alloc = std::allocator<re2c::bitmap_t>]()’
./src/re/tag.h: At global scope:
./src/re/tag.h:15: warning: ‘re2c::TAGVER_BOTTOM’ defined but not used
./src/re/tag.h:17: warning: ‘re2c::TAGVER_CURSOR’ defined but not used
make[1]: *** [src/code/bitmap.o] Error 1

I am not a C++ programmer so I can't offer any suggestions.

[ryandesign]

I should add that the above build failure is on a 32-bit PowerPC Mac, Mac OS X 10.5.8, Xcode 3.1.4's gcc version 4.2.1 (Apple Inc. build 5577). The same problem occurs if I use a newer Apple gcc from MacPorts (gcc version 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_15)).

The build succeeds on a 32-bit Intel Mac, Mac OS X 10.6.8, Xcode 3.2.6's gcc version 4.2.1 (Apple Inc. build 5666) (dot 3).

I have also tested gcc version 4.0.1 (Apple Inc. build 5493) on the PowerPC Mac and gcc version 4.0.1 (Apple Inc. build 5494) on the Intel Mac and both fail with:

./src/util/free_list.h: In instantiation of ‘re2c::free_list<re2c::Code*>’:
./src/re/rule.h:32:   instantiated from here
./src/util/free_list.h:11: warning: base class ‘class std::set<re2c::Code*, std::less<re2c::Code*>, std::allocator<re2c::Code*> >’ has a non-virtual destructor
src/code/bitmap.cc: In member function ‘void re2c::bitmaps_t::insert(const re2c::Go*, const re2c::State*)’:
src/code/bitmap.cc:30: error: no match for ‘operator!=’ in ‘i != std::vector<_Tp, _Alloc>::rend() [with _Tp = re2c::bitmap_t, _Alloc = std::allocator<re2c::bitmap_t>]()’
/usr/include/c++/4.0.0/bits/stl_tree.h: In constructor ‘std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Rb_tree_impl<_Key_compare, _Is_pod_comparator>::_Rb_tree_impl(const typename _Alloc::rebind<std::_Rb_tree_node<_Val> >::other&, const _Key_compare&) [with _Key_compare = std::less<uint32_t>, bool _Is_pod_comparator = false, _Key = uint32_t, _Val = uint32_t, _KeyOfValue = std::_Identity<uint32_t>, _Compare = std::less<uint32_t>, _Alloc = std::allocator<uint32_t>]’:
/usr/include/c++/4.0.0/bits/stl_tree.h:554:   instantiated from ‘std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Rb_tree(const _Compare&, const _Alloc&) [with _Key = uint32_t, _Val = uint32_t, _KeyOfValue = std::_Identity<uint32_t>, _Compare = std::less<uint32_t>, _Alloc = std::allocator<uint32_t>]’
/usr/include/c++/4.0.0/bits/stl_set.h:150:   instantiated from ‘std::set<_Key, _Compare, _Alloc>::set() [with _Key = uint32_t, _Compare = std::less<uint32_t>, _Alloc = std::allocator<uint32_t>]’
./src/re/rule.h:64:   instantiated from here
/usr/include/c++/4.0.0/bits/stl_tree.h:403: warning: ‘std::_Rb_tree<uint32_t, uint32_t, std::_Identity<uint32_t>, std::less<uint32_t>, std::allocator<uint32_t> >::_Rb_tree_impl<std::less<uint32_t>, false>::_M_header’ should be initialized in the member initialization list
make[1]: *** [src/code/bitmap.o] Error 1

[skvadrik]

Hi Ryan,

It seems that the problem is caused by an old compiler version that is unable to deduce const-ness of a loop variable in the following (pseudo)code:

for (const_reverse_iterator i = v.rbegin(); i != v.rend(); ++i) ...

Here v.rend() might refer to one of the two overloads:

reverse_iterator rend();
const_reverse_iterator rend() const;

The compiler should deduce the second overload (as the only possible), but for some reason it fails. You can find this issue on stackoverflow: https://stackoverflow.com/questions/5907078/reverse-iterator-error-no-match-for-operator-in-rcit-stdvector-tp

The best option is to update the compiler. If for some reason update is not possible, I can write a patch for re2c-1.0.2 and you would be able to use it in MacPorts. Applying this sort of patches to upstream re2c is a bad thing to do because I have no way of testing if it works, and I will probably "break" the code again very soon.

[ryandesign]

Unfortunately, no newer version of Apple gcc exists. gcc 4.3 changed the license to GPL-3, which caused Apple to abandon it and move development to clang, which is a great compiler that we use on newer systems, but it does not work on PowerPC systems. We could probably use a newer FSF gcc on PowerPC systems, at the expense of being able to compile for multiple architectures, since that was a feature Apple added to gcc which is not in FSF gcc. But a compiler is a huge dependency, and re2c is a small program, which is a dependency of ninja, which is a dependency of meson, which is a new build system that we want to use for some programs, and requiring a new compiler just to run what is essentially the equivalent of a configure script seems very heavy to me.

If it's not too difficult to figure out a patch that will let it build with older compilers, that would be appreciated. We can try it in MacPorts before you commit it, but committing it to your sources is best so that all users, not just MacPorts users, can benefit from it.

[skvadrik]

I created a separate branch mac_ports with the necessary fix. Can you check that it works? 5b95c8e

Since it concerns MacOS on PowerPC (and other systems not supported by clang), I will consider merging the fix in master. But the sad thing is, I'll probably break it again in the next release.

[ryandesign]

Thanks, I really appreciate your willingness to work on this.

That patch works and I've applied it to MacPorts. If it breaks in the future, I know what to look for and will try to send you fixes.

[skvadrik]

Ok! Since the patch is trivial, I've pushed it to master and released 1.0.3.