Need some 64-bit testing help.
Folks, I need some help with the tests in: sandbox/big_number/libs/multiprecision/test Which I have an suspicion may have problems in 64-bit release mode (though I hope not!), so I'm looking for some folks to do a: bjam release --disable-concepts in that directory with whatever 64-bit compilers you have access to. Many thanks in advance! John.
On 16/01/2012 18:48, John Maddock wrote:
Folks, I need some help with the tests in:
sandbox/big_number/libs/multiprecision/test
Which I have an suspicion may have problems in 64-bit release mode (though I hope not!), so I'm looking for some folks to do a:
bjam release --disable-concepts
in that directory with whatever 64-bit compilers you have access to.
(Compiled against trunk version of Boost) The "--disable-concepts" doesn't seems to be working. Got lots of errors on both x86 & x64 because of "no such file ...". Can't really test it because of that. KTC
Folks, I need some help with the tests in:
sandbox/big_number/libs/multiprecision/test
Which I have an suspicion may have problems in 64-bit release mode (though I hope not!), so I'm looking for some folks to do a:
bjam release --disable-concepts
in that directory with whatever 64-bit compilers you have access to.
(Compiled against trunk version of Boost)
The "--disable-concepts" doesn't seems to be working. Got lots of errors on both x86 & x64 because of "no such file ...". Can't really test it because of that.
Weird, works for me and few others. You can run the tests without that flag (please update the SVN before you do though, as I've just fixed some 64-bit issues), it'll just take a little longer.... Many thanks, John.
On 17/01/2012 13:18, John Maddock wrote:
Weird, works for me and few others. You can run the tests without that flag (please update the SVN before you do though, as I've just fixed some 64-bit issues), it'll just take a little longer....
Sorry my bad. I was being an idiot and somehow managed to checkout */libs/* without checking out the */boost/* part. Though now I do seems to have a real problem with "has_gmp builds : yes" when testing it with VC10. Ignoring that, the number of errors with x86 and with x64 is the same per compiler version. http://www.ktchan.info/boost/multiprecision/VS9x64.txt */VS9x86.txt */VS10x64.txt */VS10x86.txt KTC
Weird, works for me and few others. You can run the tests without that flag (please update the SVN before you do though, as I've just fixed some 64-bit issues), it'll just take a little longer....
Sorry my bad. I was being an idiot and somehow managed to checkout */libs/* without checking out the */boost/* part. Though now I do seems to have a real problem with "has_gmp builds : yes" when testing it with VC10. Ignoring that, the number of errors with x86 and with x64 is the same per compiler version.
http://www.ktchan.info/boost/multiprecision/VS9x64.txt */VS9x86.txt */VS10x64.txt */VS10x86.txt
Many thanks, seems like your VC10 install must have a copy of gmp.h somewhere, but other than that looks basically OK. Cheers, John.
On 01/16/2012 07:48 PM, John Maddock wrote:
Folks, I need some help with the tests in:
sandbox/big_number/libs/multiprecision/test
Which I have an suspicion may have problems in 64-bit release mode (though I hope not!), so I'm looking for some folks to do a:
bjam release --disable-concepts
in that directory with whatever 64-bit compilers you have access to.
Many thanks in advance! John.
You mean it has only been tested to work with extended-precision x87? In which case GCC with -msse2 -mfpmath=sse would allow you to test it without any x87 use, be it on 32 or 64 bit (those flags are enabled by default on x86-64).
in that directory with whatever 64-bit compilers you have access to.
Many thanks in advance! John.
You mean it has only been tested to work with extended-precision x87?
No I mean it's only been tested on a machine with a 32-bit registers. It's the integer manipulations I want to double check - there are some expressions which could conceivably be optimized in a way that would fail if 64-bit registers are used - I believe they shouldn't do so if the standard is strictly followed - but sometimes compilers can play a bit fast-and-loose when optimizations are turned on. If necessary I have a fallback, but let's see if there's an issue first. John.
John Maddock wrote:
in that directory with whatever 64-bit compilers you have access to.
Many thanks in advance! John.
You mean it has only been tested to work with extended-precision x87?
No I mean it's only been tested on a machine with a 32-bit registers. It's the integer manipulations I want to double check - there are some expressions which could conceivably be optimized in a way that would fail if 64-bit registers are used - I believe they shouldn't do so if the standard is strictly followed - but sometimes compilers can play a bit fast-and-loose when optimizations are turned on. If necessary I have a fallback, but let's see if there's an issue first.
John.
I'm confused. As I'm sure we all know, 64 bit amd x86_64 uses 64 bit pointers, but int is still 32 bit.
No I mean it's only been tested on a machine with a 32-bit registers. It's the integer manipulations I want to double check - there are some expressions which could conceivably be optimized in a way that would fail if 64-bit registers are used - I believe they shouldn't do so if the standard is strictly followed - but sometimes compilers can play a bit fast-and-loose when optimizations are turned on. If necessary I have a fallback, but let's see if there's an issue first.
John.
I'm confused. As I'm sure we all know, 64 bit amd x86_64 uses 64 bit pointers, but int is still 32 bit.
It uses a mix of 32 and 64 bit integer operations, for example "complement a 32 bit int, then promote to 64 bits and add". Reverse the order of operations and the complement will do the wrong thing. Any clearer? ;-) John.
participants (4)
-
John Maddock -
KTC -
Mathias Gaunard -
Neal Becker