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