3.0.1 release?

Bateman David-ADB014 David.Bateman at motorola.com
Tue Apr 8 08:25:25 CDT 2008


The code

#include <iostream>
int main (void)
{
        uint64_t a = 0x001FFFFFFFFFFFFFUL^0x0007FFFFFFFFFFFFUL; 
        std::cerr << a  << std::endl;
        return 0;
}

returns 6755399441055744, and I suspect it does something else under MSVC

D.


-----Original Message-----
From: Michael Goffioul [mailto:michael.goffioul at gmail.com]
Sent: Tue 08-Apr-08 3:06 PM
To: Bateman David-ADB014
Cc: John W. Eaton; octave-maintainers at octave.org
Subject: Re: 3.0.1 release?
 
On Tue, Apr 8, 2008 at 3:01 PM, David Bateman
<David.Bateman at motorola.com> wrote:
>  I just looked at this issue a little bit and the failing part of the
>  code is
>
>   Bmax = bitmax;
>   A = bitshift(Bmax,-2);
>   bitxor(cast(A,'uint64'),cast(Bmax,'uint64'))
>
>  Bmax is '2^53 - 1' and A is '2^51 - 1" and so bitxor of the above should
>  be '2^52 + 2^51' and is under linux. Under windows this appears to
>  return '2^53 + 2^51' which is of course a bug.. The equivalent in C++
>  would be
>
>  0x000FFFFFFFFFFFFFUL^ x0003FFFFFFFFFFFFUL
>
>  so what does this return when compiled with MSVC in C++ mode? If its not
>  '2^52 + 2^51' its time to file a bug report against MSVC..

Could you provide some code that I can compile and run out-of-the-box?
I'm not sure I fully understand the problem...

Michael.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.cae.wisc.edu/pipermail/octave-maintainers/attachments/20080408/f7e8196b/attachment-0001.html 


More information about the Octave-maintainers mailing list