The test fails on metacomm-v2 for msvc-6.5, 7.0 and for borland: http://tinyurl.com/y6otrh http://tinyurl.com/ynz9z3 http://tinyurl.com/yxlcv7 The borland and 6.5 failures seem to be related to compiler problems that trigger *on the test itself*, so it might be possible to revive the test. The 7.0 failures is something deeper inside the math library. Is somebody in position to look at those? Thanks, Volodya
On 11/26/06 1:42 PM, "Vladimir Prus" <ghost@cs.msu.su> wrote:
The test fails on metacomm-v2 for msvc-6.5, 7.0 and for borland:
http://tinyurl.com/y6otrh http://tinyurl.com/ynz9z3 http://tinyurl.com/yxlcv7
The borland and 6.5 failures seem to be related to compiler problems that trigger *on the test itself*, so it might be possible to revive the test.
The 7.0 failures is something deeper inside the math library.
From the error messages, it looks like whenever the compiler sees a class-static built-in-integer constant that evaluates to zero, it tries grouping it as a pure virtual member function, which obviously fails because
Borland seems to have a problem requiring explicitly declared specialization. I'm not sure that any workaround would be legal on any other compiler. For MSVC 6.5, the compiler is just fried here. Pure virtual member functions look like: virtual void my_pure_virtual() = 0; Compile-time class-static built-in-integer constants look like: static int const my_value = 3; the "= 0" is the only thing the two syntaxes have in common. (It seems like the creators gave the parser's pure-virtual part too much priority.) For MSVC 7.0, it seems like the actual numeric test types aren't correctly extracted from the MPL lists (signed_test_types and unsigned_test_types) by the various BOOST_AUTO_TEST_CASE_TEMPLATE instances. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker wrote:
For MSVC 6.5, the compiler is just fried here. Pure virtual member functions look like:
virtual void my_pure_virtual() = 0;
Compile-time class-static built-in-integer constants look like:
static int const my_value = 3;
inline static const's aren't supported by that compiler, using BOOST_STATIC_CONSTANT would likely fix the problem: that's what we provided it for :-) John.
Daryle the attached patch fixes the test for VC7. It also fixes most of the VC6 issues, but leaves me with an internal compiler error inside Boost.Test that I can't fix at present (But see below). I've had a look at Borland, but I've not been able to completely fix the errors, they're related to Borland not supporting member template friends, so your integer wrapper classes don't compile. Consequently I've disabled the UDT tests for compilers that define BOOST_NO_MEMBER_TEMPLATE_FRIENDS, this has the effect of fixing the VC6 internal error as well. That means with the patch applied, VC6, 7, 7.1, Borland-5.8.2, and gcc-3.4 all pass the test. So... OK to commit? John.
On 11/27/06 4:13 AM, "John Maddock" <john@johnmaddock.co.uk> wrote:
Daryle the attached patch fixes the test for VC7.
It also fixes most of the VC6 issues, but leaves me with an internal compiler error inside Boost.Test that I can't fix at present (But see below).
I've had a look at Borland, but I've not been able to completely fix the errors, they're related to Borland not supporting member template friends, so your integer wrapper classes don't compile. Consequently I've disabled the UDT tests for compilers that define BOOST_NO_MEMBER_TEMPLATE_FRIENDS, this has the effect of fixing the VC6 internal error as well.
That means with the patch applied, VC6, 7, 7.1, Borland-5.8.2, and gcc-3.4 all pass the test.
So... OK to commit?
Is this for the 1.34 branch or the HEAD, or both? (Vladimir copied the HEAD version to 1.34.) Looking at the diff, I noticed that you conditionally replace the custom types with (unsigned) long. The point of those types is to use non-built-in types with or without numeric limits. If they can't be supported, then those tests should be skipped completely, not substituted with (unsigned) long. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker wrote:
Is this for the 1.34 branch or the HEAD, or both? (Vladimir copied the HEAD version to 1.34.)
1.34 branch.
Looking at the diff, I noticed that you conditionally replace the custom types with (unsigned) long. The point of those types is to use non-built-in types with or without numeric limits. If they can't be supported, then those tests should be skipped completely, not substituted with (unsigned) long.
I know: however I had problems with the pp-logic, without that extra dummy type the mpl list terminated with a "," which wasn't legal code. OK let me try again, how about changing that section to: typedef ::boost::mpl::list< #ifdef BOOST_HAS_LONG_LONG long long, #elif defined(BOOST_HAS_MS_INT64) __int64, #endif signed char, short, int, long #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS , MyInt1 #endif
signed_test_types;
typedef ::boost::mpl::list< #ifdef BOOST_HAS_LONG_LONG unsigned long long, #elif defined(BOOST_HAS_MS_INT64) unsigned __int64, #endif unsigned char, unsigned short, unsigned, unsigned long #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS , MyUnsigned1, MyUnsigned2 #endif
unsigned_test_types;
Which puts things in a slightly unnatural order, but does what you want now I think? John.
Daryle Walker wrote:
On 11/26/06 1:42 PM, "Vladimir Prus" <ghost@cs.msu.su> wrote:
The test fails on metacomm-v2 for msvc-6.5, 7.0 and for borland:
http://tinyurl.com/y6otrh http://tinyurl.com/ynz9z3 http://tinyurl.com/yxlcv7
The borland and 6.5 failures seem to be related to compiler problems that trigger *on the test itself*, so it might be possible to revive the test.
The 7.0 failures is something deeper inside the math library.
Borland seems to have a problem requiring explicitly declared specialization. I'm not sure that any workaround would be legal on any other compiler.
You can wrap the workaround in #ifdef, I think? If that's no feasible, or there's no workaround, can you mark the failure as expected?
For MSVC 6.5, the compiler is just fried here. Pure virtual member functions look like:
virtual void my_pure_virtual() = 0;
Compile-time class-static built-in-integer constants look like:
static int const my_value = 3;
Yes. Again, if this is not workaroundable, can you mark the failures as expected?
From the error messages, it looks like whenever the compiler sees a class-static built-in-integer constant that evaluates to zero, it tries grouping it as a pure virtual member function, which obviously fails because the "= 0" is the only thing the two syntaxes have in common. (It seems like the creators gave the parser's pure-virtual part too much priority.)
For MSVC 7.0, it seems like the actual numeric test types aren't correctly extracted from the MPL lists (signed_test_types and unsigned_test_types) by the various BOOST_AUTO_TEST_CASE_TEMPLATE instances.
So, is this Boost.Test problem, or Boost.Math problem, or test case problem and what can be done about it? Thanks, Volodya
participants (3)
-
Daryle Walker -
John Maddock -
Vladimir Prus