The 64 bit compiler that comes with the Windows 7 SDK treats long as 32 bits leading to occasional crashes in AlignedMalloc. Changing the cast in
segments[1] =
(void *) (((long) segments[0] + alignment - 1) & ~(alignment - 1));
to
segments[1] =
(void *) (((long long) segments[0] + alignment - 1) & ~(alignment - 1));
appears to fix the problem.
crafty (or MSVC) bug
Moderators: hgm, Rebel, chrisw
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: crafty (or MSVC) bug
jwes wrote:The 64 bit compiler that comes with the Windows 7 SDK treats long as 32 bits leading to occasional crashes in AlignedMalloc. Changing the cast in
segments[1] =
(void *) (((long) segments[0] + alignment - 1) & ~(alignment - 1));
to
segments[1] =
(void *) (((long long) segments[0] + alignment - 1) & ~(alignment - 1));
appears to fix the problem.
I am working on a fix for this brain-dead decision by Microsoft. Going to try to use the new standard types header file.
-
- Posts: 388
- Joined: Wed Mar 08, 2006 10:08 pm
Re: crafty (or MSVC) bug
jwes wrote:The 64 bit compiler that comes with the Windows 7 SDK treats long as 32 bits leading to occasional crashes in AlignedMalloc. Changing the cast in
segments[1] =
(void *) (((long) segments[0] + alignment - 1) & ~(alignment - 1));
to
segments[1] =
(void *) (((long long) segments[0] + alignment - 1) & ~(alignment - 1));
appears to fix the problem.
In Windows, long is always 32-bits. All compilers for Windows abide by this (GCC, LCC, ICC, MSVC).
The correct code would be to use size_t instead of long or longlong.
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: crafty (or MSVC) bug
CThinker wrote:jwes wrote:The 64 bit compiler that comes with the Windows 7 SDK treats long as 32 bits leading to occasional crashes in AlignedMalloc. Changing the cast in
segments[1] =
(void *) (((long) segments[0] + alignment - 1) & ~(alignment - 1));
to
segments[1] =
(void *) (((long long) segments[0] + alignment - 1) & ~(alignment - 1));
appears to fix the problem.
In Windows, long is always 32-bits. All compilers for Windows abide by this (GCC, LCC, ICC, MSVC).
The correct code would be to use size_t instead of long or longlong.
Or the more modern int64_t/int32_t in stdint.h... I am trying to test this on MSVC now. Works perfectly on linux and gives on the ability to declare 8/16/32/64 bit values, signed or unsigned, without the compiler doing something goofy such as long = 32 bits on a 64 bit machine, as in windows.
-
- Posts: 319
- Joined: Fri Dec 18, 2009 11:40 am
- Location: Naperville, IL
Re: crafty (or MSVC) bug
What about intptr_t? That seems like what is meant, and I've read that even Microsoft ships stdint.h (finally!!).
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: crafty (or MSVC) bug
Depends on what is being done. For pointers, that is the right type. For "long" integers, int64_t is the right one.UncombedCoconut wrote:What about intptr_t? That seems like what is meant, and I've read that even Microsoft ships stdint.h (finally!!).
-
- Posts: 4367
- Joined: Fri Mar 10, 2006 5:23 am
- Location: http://www.arasanchess.org
Re: crafty (or MSVC) bug
Arasan uses the intrinsic _aligned_malloc for MSVC, and posix_memalign for Linux. Unfortunately though there does not seem to be an equivalent for Mac OS.
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: crafty (or MSVC) bug
And posix_memalign() is not present on all linux distributions since some still use older ones. I used that for a while, but decided to write my own to make things completely portable.jdart wrote:Arasan uses the intrinsic _aligned_malloc for MSVC, and posix_memalign for Linux. Unfortunately though there does not seem to be an equivalent for Mac OS.