https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61662
Bug ID: 61662 Summary: Incorrect value calculated for _lrotl on LLP64 systems Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: gccbugzilla at limegreensocks dot com Created attachment 33037 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33037&action=edit Proposed patch There is a problem in ia32intrin.h. Extracting bits of the code to highlight the problem, we get: #ifdef __x86_64__ #define _lrotl(a,b) __rolq((a), (b)) // rotate left qword #else #define _lrotl(a,b) __rold((a), (b)) // rotate left dword #endif This works correctly for linux, since on linux, longs use 8 bytes on 64bit and 4 bytes on 32bit (aka LP64). However, in native Windows, longs are 4 bytes for both (aka LLP64). So on 64bit Windows, 4 byte longs get promoted to a qword, bits get rotated into the upper bytes, then get truncated when cast back into a 4 byte long. Oops. The problem here is that using "#ifdef __x86_64__" to determine the size of a long does not reliably yield the correct result. While gcc provides a define named __SIZEOF_LONG__, it doesn't seem like this is used very often outside of the testsuite. Therefore the proposed patch (attached) uses the __LP64__ define. Testcase: printf("sizeof(long): %d sizeof(ptr): %d " "_lrotl(0x80000000,1): 0x%lx _lrotr(1,1): 0x%lx\n", sizeof(long), sizeof(void *), _lrotl(0x80000000, 1), _lrotr(1,1)); 64bit Windows yields: sizeof(long): 4 sizeof(ptr): 8 _lrotl(0x80000000,1): 0x0 _lrotr(1,1): 0x0 Applying the patch yields: sizeof(long): 4 sizeof(ptr): 8 _lrotl(0x80000000,1): 0x1 _lrotr(1,1): 0x80000000