Re: Re: boost regex support for 64-bit
The errors that we got:
1. The Workshop 6 errors (SunOS):
CC -c -O2 -I../../../ -o sunpro/libboost_regex/c_regex_traits.o ../src/c_regex_traits.cpp "../../..//boost/regex/v4/match_flags.hpp", line 91: Error: Cannot assign int to boost::regex_constants::_match_flags. "../../..//boost/regex/v4/match_flags.hpp", line 93: Error: Cannot assign int to boost::regex_constants::_match_flags. "../../..//boost/regex/v4/match_flags.hpp", line 95: Error: Cannot assign int to boost::regex_constants::_match_flags. 3 Error(s) detected.
These are just a few. The rest of the errors occured for the same reasons in various files. (If you want those too - let me know).
2. The aCC errors are (HP-IX): aCC -o generic/boost_regex/cpp_regex_traits.o -c -Aa -AA +O2 -I../../../ -O ../src/cpp_regex_traits.cpp Error 742: "../src/cpp_regex_traits.cpp", line 382 # Source type const char *& and target type char * in a const_cast can only differ in their qualifiers pmd->sbuf.pubsetbuf(const_cast
(first), static_caststd::streamsize(last-first)); I mistakingly wrote dynamic_cast in the original post, but I meant const_cast. Sorry for the confusion.
Please notice that we had to add manually some flags to generic.mak (which is the makefile we used to build it on HP-IX). I'm aware of some example you gave in the html documentation about compiling with aCC - but we still had to change some flags. (I know these weren't formal settings and just an example).
Is there any chance that there will be a HP-IX-special makefile? It will make life much easier. :-)
3. I forgot to mension, that we managed to compile RegEX with SunOS C++ 5.5 both in 32 & 64 bits. There were no errors, BUT in 64 bits when we tried to run the rs/regress test - it failed (something which didn't happen in the 32-bits version). There was also a memory access violation, so even thought the compilation went just fine - apparently the library is not fully 64-bit compatible. What can we do to overcome this problem? Thanks alot, Yaron
CC -c -O2 -I../../../ -o sunpro/libboost_regex/c_regex_traits.o ../src/c_regex_traits.cpp "../../..//boost/regex/v4/match_flags.hpp", line 91: Error: Cannot assign int to boost::regex_constants::_match_flags. "../../..//boost/regex/v4/match_flags.hpp", line 93: Error: Cannot assign int to boost::regex_constants::_match_flags. "../../..//boost/regex/v4/match_flags.hpp", line 95: Error: Cannot assign int to boost::regex_constants::_match_flags. 3 Error(s) detected.
That would be a compiler bug, please submit it such if you are able to, in
the mean time I will patch a workaround into the source.
[ Note - the reason it's a compiler bug, is that in the code:
inline match_flags& operator&=(match_flags& m1, match_flags m2)
{ m1 = m1&m2; return m1; }
The result of m1&m2 is type match_flags, and *not* int as the compiler
suggests, because of the earlier defined operator:
inline match_flags operator&(match_flags m1, match_flags m2)
{ return static_cast
These are just a few. The rest of the errors occured for the same reasons in various files. (If you want those too - let me know).
Yes! I can't patch the source unless you give me all the available information. Incidently it might be easiest to work around this by including sunpro in the workaround above that reads: #if BOOST_WORKAROUND(BOOST_MSVC, <= 1200) || BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) in match_flags.hpp
2. The aCC errors are (HP-IX): aCC -o generic/boost_regex/cpp_regex_traits.o -c -Aa -AA +O2 -I../../../ -O ../src/cpp_regex_traits.cpp Error 742: "../src/cpp_regex_traits.cpp", line 382 # Source type const char *& and target type char * in a const_cast can only differ in their qualifiers pmd->sbuf.pubsetbuf(const_cast
(first), static_caststd::streamsize(last-first)); I mistakingly wrote dynamic_cast in the original post, but I meant const_cast. Sorry for the confusion.
Please notice that we had to add manually some flags to generic.mak (which is the makefile we used to build it on HP-IX). I'm aware of some example you gave in the html documentation about compiling with aCC - but we still had to change some flags. (I know these weren't formal settings and just an example).
Is there any chance that there will be a HP-IX-special makefile? It will make life much easier. :-)
If you want to provide one - I don't have access to that compiler.
3. I forgot to mension, that we managed to compile RegEX with SunOS C++ 5.5 both in 32 & 64 bits. There were no errors, BUT in 64 bits when we tried to run the rs/regress test - it failed (something which didn't happen in the 32-bits version). There was also a memory access violation, so even thought the compilation went just fine - apparently the library is not fully 64-bit compatible.
What can we do to overcome this problem?
OK a couple of data points: the library is passing all it's tests with IBM C++ on Itanium, so I would be surprised if this is 64-bit issue as such, it's more likely to be a compiler or platform specific issue. As I asked before what precisely is failing? What is the general protection fault? Where in the code does it occur (stack trace?) and so on. I'm going to need a lot more information before I can make any suggestions, and probably you're going to have to do some debugging as well... John.
As for the Workshop 6 compiler - it does look like a compiler bug. I don't
know if I mentioned, but we compiled it also on a new
compiler (on the same platform, ofcourse) and there were no errors.
If you'll take a look at the errors below (please don't be alarmed by the
long list - it's just long error messages...) you'll see that all the
errors are given for the same reason.
The errors I get compiling with Workshop 6 (on SunOS) are (sorry for the
long list...):
"../../..//boost/regex/v4/match_flags.hpp", line 91: Error: Cannot assign
int to boost::regex_constants::_match_flags.
"../../..//boost/regex/v4/match_flags.hpp", line 93: Error: Cannot assign
int to boost::regex_constants::_match_flags.
"../../..//boost/regex/v4/match_flags.hpp", line 95: Error: Cannot assign
int to boost::regex_constants::_match_flags.
"../../..//boost/regex/v4/regex_grep.hpp", line 63: Error: Formal argument f
of type boost::regex_constants::_match_flags in call to
boost::re_detail::perl_matcher
CC -c -O2 -I../../../ -o sunpro/libboost_regex/c_regex_traits.o ../src/c_regex_traits.cpp "../../..//boost/regex/v4/match_flags.hpp", line 91: Error: Cannot assign int to boost::regex_constants::_match_flags. "../../..//boost/regex/v4/match_flags.hpp", line 93: Error: Cannot assign int to boost::regex_constants::_match_flags. "../../..//boost/regex/v4/match_flags.hpp", line 95: Error: Cannot assign int to boost::regex_constants::_match_flags. 3 Error(s) detected.
That would be a compiler bug, please submit it such if you are able to, in the mean time I will patch a workaround into the source.
[ Note - the reason it's a compiler bug, is that in the code:
inline match_flags& operator&=(match_flags& m1, match_flags m2)
{ m1 = m1&m2; return m1; }
The result of m1&m2 is type match_flags, and *not* int as the compiler suggests, because of the earlier defined operator:
inline match_flags operator&(match_flags m1, match_flags m2)
{ return static_cast
(static_castboost::int32_t(m1) & static_castboost::int32_t(m2)); } - end note ]
These are just a few. The rest of the errors occured for the same reasons in various files. (If you want those too - let me know).
Yes! I can't patch the source unless you give me all the available information. Incidently it might be easiest to work around this by including sunpro in the workaround above that reads:
#if BOOST_WORKAROUND(BOOST_MSVC, <= 1200) || BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564))
in match_flags.hpp
2. The aCC errors are (HP-IX): aCC -o generic/boost_regex/cpp_regex_traits.o -c -Aa -AA +O2 -I../../../ -O ../src/cpp_regex_traits.cpp Error 742: "../src/cpp_regex_traits.cpp", line 382 # Source type const char *& and target type char * in a const_cast can only differ in their qualifiers pmd->sbuf.pubsetbuf(const_cast
(first), static_caststd::streamsize(last-first)); I mistakingly wrote dynamic_cast in the original post, but I meant const_cast. Sorry for the confusion.
Please notice that we had to add manually some flags to generic.mak (which is the makefile we used to build it on HP-IX). I'm aware of some example you gave in the html documentation about compiling with aCC - but we still had to change some flags. (I know these weren't formal settings and just an example).
Is there any chance that there will be a HP-IX-special makefile? It will make life much easier. :-)
If you want to provide one - I don't have access to that compiler.
3. I forgot to mension, that we managed to compile RegEX with SunOS C++ 5.5 both in 32 & 64 bits. There were no errors, BUT in 64 bits when we tried to run the rs/regress test - it failed (something which didn't happen in the 32-bits version). There was also a memory access violation, so even thought the compilation went just fine - apparently the library is not fully 64-bit compatible.
What can we do to overcome this problem?
OK a couple of data points: the library is passing all it's tests with IBM C++ on Itanium, so I would be surprised if this is 64-bit issue as such, it's more likely to be a compiler or platform specific issue. As I asked before what precisely is failing? What is the general protection fault? Where in the code does it occur (stack trace?) and so on. I'm going to need a lot more information before I can make any suggestions, and probably you're going to have to do some debugging as well...
John. "John Maddock"
wrote in message news:01d001c44a1e$f32180f0$52f20352@fuji... CC -c -O2 -I../../../ -o sunpro/libboost_regex/c_regex_traits.o ../src/c_regex_traits.cpp "../../..//boost/regex/v4/match_flags.hpp", line 91: Error: Cannot assign int to boost::regex_constants::_match_flags. "../../..//boost/regex/v4/match_flags.hpp", line 93: Error: Cannot assign int to boost::regex_constants::_match_flags. "../../..//boost/regex/v4/match_flags.hpp", line 95: Error: Cannot assign int to boost::regex_constants::_match_flags. 3 Error(s) detected.
That would be a compiler bug, please submit it such if you are able to, in the mean time I will patch a workaround into the source.
[ Note - the reason it's a compiler bug, is that in the code:
inline match_flags& operator&=(match_flags& m1, match_flags m2)
{ m1 = m1&m2; return m1; }
The result of m1&m2 is type match_flags, and *not* int as the compiler suggests, because of the earlier defined operator:
inline match_flags operator&(match_flags m1, match_flags m2)
{ return static_cast
(static_castboost::int32_t(m1) & static_castboost::int32_t(m2)); } - end note ]
These are just a few. The rest of the errors occured for the same reasons in various files. (If you want those too - let me know).
Yes! I can't patch the source unless you give me all the available information. Incidently it might be easiest to work around this by including sunpro in the workaround above that reads:
#if BOOST_WORKAROUND(BOOST_MSVC, <= 1200) || BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564))
in match_flags.hpp
2. The aCC errors are (HP-IX): aCC -o generic/boost_regex/cpp_regex_traits.o -c -Aa -AA +O2 -I../../../ -O ../src/cpp_regex_traits.cpp Error 742: "../src/cpp_regex_traits.cpp", line 382 # Source type const char *& and target type char * in a const_cast can only differ in their qualifiers pmd->sbuf.pubsetbuf(const_cast
(first), static_caststd::streamsize(last-first)); I mistakingly wrote dynamic_cast in the original post, but I meant const_cast. Sorry for the confusion.
Please notice that we had to add manually some flags to generic.mak (which is the makefile we used to build it on HP-IX). I'm aware of some example you gave in the html documentation about compiling with aCC - but we still had to change some flags. (I know these weren't formal settings and just an example).
Is there any chance that there will be a HP-IX-special makefile? It will make life much easier. :-)
If you want to provide one - I don't have access to that compiler.
3. I forgot to mension, that we managed to compile RegEX with SunOS C++
5.5
both in 32 & 64 bits. There were no errors, BUT in 64 bits when we tried to run the rs/regress test - it failed (something which didn't happen in the 32-bits version). There was also a memory access violation, so even thought the compilation went just fine - apparently the library is not fully 64-bit compatible.
What can we do to overcome this problem?
OK a couple of data points: the library is passing all it's tests with IBM C++ on Itanium, so I would be surprised if this is 64-bit issue as such, it's more likely to be a compiler or platform specific issue. As I asked before what precisely is failing? What is the general protection fault? Where in the code does it occur (stack trace?) and so on. I'm going to need a lot more information before I can make any suggestions, and probably you're going to have to do some debugging as well...
John.
As for the Workshop 6 compiler - it does look like a compiler bug. I don't know if I mentioned, but we compiled it also on a new compiler (on the same platform, ofcourse) and there were no errors.
OK, good.
If you'll take a look at the errors below (please don't be alarmed by the long list - it's just long error messages...) you'll see that all the errors are given for the same reason. The errors I get compiling with Workshop 6 (on SunOS) are (sorry for the long list...):
[snipped] I'm not sure that I can patch all of those, but I'll look into it.
As for the 64-bit issue: In order to compile it I simply added the -xarch=v9 flag. Am I supposed to add something else? I run "regress ../tests.txt". And what I get is (again, sorry for the massive data...)
Error in line 756 of file ../tests.txt Expression: a Search text: a a a aa Flags: REG_EXTENDED | REG_PERL | REG_AWK | REG_EGREP | REG_STARTEND | basic | escape_in_lists | char_classes | intervals | bk_refs | perlex | normal | basic | extended | perl | REG_GREP class RegEx grep error in $`: found [4294967295,8589934590] expected [8,8] class RegEx grep error in $': found [4294967295,8589934590] expected [9,9] class RegEx grep error in $`: found [4294967295,8589934590] expected [8,8] class RegEx grep error in $': found [4294967295,8589934590] expected [9,9] class RegEx grep error in $`: found [4294967295,8589934590] expected [8,8] class RegEx grep error in $': found [4294967295,8589934590] expected [9,9]
OK, that's good: the error's are only comming from the RegEx class (which is depecated anyway), and not the underlying template code, actually it looks to me like this may be an error in the test suite rather than the library itself. I'll see if I can scope any obvious integer overflows and the like. BTW, I have access to aCC now thanks to HP's testdrive program, and the current cvs source compiles and runs with no issues/errors you'll be pleased to know. Thanks, John.
participants (2)
-
John Maddock
-
Yaron Hirsch