Re: [boost] [integer] Recent changes introduced failures on many platforms

From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2008-07-29 04:47:18

Daryle Walker wrote:
> On Jul 28, 2008, at 4:36 AM, Markus Schöpflin wrote:
> 
>> Now I have the following issues:
>>
>> 1) I need to increase the maximum number of pending instantiations, it 
>> seems that the default value of the compiler (64) is not enough. This 
>> is also true for the acc toolset, AFAICT.
> 
> That's the price of exhaustive testing.  Have you tried setting 
> CONTROL_FULL_COUNTS to 0?  (That preprocessor flag is made to be 
> overridable by your command-line parameters.)  That'll reduce the number 
> of bit-count cases to just 8 or so, but you might miss some important 
> cases (like bit-count == 0).

As long as its only needed for running the regression tests, I'll just go 
ahead and modify the compiler parameters in my local configuration file.

>> 2) I get a number of compile time errors along the lines of:
>>
>> cxx: Error: integer_test.cpp, line 623: expression must have a 
>> constant value
>>           (exprnotconst)
>>     BOOST_CHECK_EQUAL( static_cast<typename
>> ----^
>> cxx: Error: ../../../boost/integer.hpp, line 375: class 
>> "boost::maximum_unsigned_integral<<error-constant>>" has no member "type"
>>           (notmember)
>>           detected during instantiation of class 
>> "boost::uint_value_t<Value> [with Value=<error-constant>]" at line 623 
>> of "integer_test.cpp"
>>       typedef typename maximum_unsigned_integral<Value>::type  least;
>> ---------------------------------------------------------^
>>
>> It looks like all EDG based compilers are flagging this error, see for 
>> example http://tinyurl.com/58s3zc.
> 
> I've tried redoing how the compile-time integral constants are made.  
> Try out revision 47852.

OK, it works now. All integer tests are passing for me.

> 
>> 3) There are quite a few warning about truncation of values or sign 
>> changes, where I can't tell whether they are expected or not.
> 
> I saw those in the same URL you gave.  Those tests are supposed to set 
> either the highest bit or the highest mantissa and/or sign bit, roll off 
> the highest bit in a shift while adding the old bit value back in, then 
> confirm that the value didn't change.  (If I missed the highest bit, 
> then it wouldn't roll off and the value will change.)  Any compiler that 
> warns about bits rolling off or transitioning between the mantissa and 
> sign areas will complain.

OK, so these are to be expected and can be ignored.

Thanks for your work,
Markus