On Wednesday, February 05, 2003 2:04 PM [GMT+1=CET], Matthias Troyer <[EMAIL PROTECTED]> wrote:
> On Wednesday, February 5, 2003, at 04:24 PM, Dave Abrahams wrote: > > > On Wednesday, February 05, 2003 10:11 AM [GMT+1=CET], > > Matthias Troyer <[EMAIL PROTECTED]> wrote: > > > > > 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? > > > > > > Just to be clear, we didn't avoid an optimization by using unsigned > > types. > > We avoided undefined behavior due to overflow in signed integers, or > > conversions from unsigned->signed. > > Actually there were two problems. One was the one you mentioned above. > The other was that we needed either a masking to 32 bits or the type > made unsigned to prevent an optimization (integer calculations done on > FPU), which led to non-conforming overflow behavior. I never got very clear feedback from your guys about what was happening, but: If the calculations are only done in the FPU when the integers are signed, then the overflow behavior is conforming, since signed integer overflow is undefined behavior. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
