|
Boost : |
From: Dave Abrahams (dave_at_[hidden])
Date: 2003-02-05 14:22:52
On Wednesday, February 05, 2003 2:04 PM [GMT+1=CET],
Matthias Troyer <troyer_at_[hidden]> 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 <troyer_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk