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
