Re: [boost] Results of Cray SV1 regression tests

From: Matthias Troyer (troyer_at_[hidden])
Date: 2003-02-05 10:11:56

On Wednesday, February 5, 2003, at 02:56 PM, Jeff Garland wrote:
> The lack of support of standard library functions associated with
> long long is a problem on other platforms and other functions (eg:
> std::abs).  This has been a headache for me using the int64_t in
> date-time.
>
> So I presume that the boost::int64_t is typedefed to long
> for the Cray now?

The current CVS version uses long long as default even if long is 64 
bit. I have thus patched my version of cstdint.hpp to typedef int64_t 
to long, whicha voids some of the problems with long long.

> Curiously the one failure for date-time
> was in handling of big time durations.  The failure is
> probably an overflow problem, which can happen if you try
> to use a plain 32-bit integer to get nano-second resolutions
> and large time durations.  Nano-second resolution is the default
> configuration for the library and it normally uses a 64-bit
> type for efficient calculation...

I am looking into it but already have a conjecture. When using signed 
64 bit integers the Cray compiler (with optimization turned on) uses 
the floating point units to actually perform the operations in 46 bit 
arithmetic. This speeds up things but causes compatibility problems. In 
the case of the jam sources we could avoid this "optimization" by using 
unsigned types. Is it possible to use an unsigned integer here to avoid 
similar problems?

Matthias