[Bug libgcc/61662] New: Incorrect value calculated for _lrotl on LLP64 systems

[gccbugzilla at limegreensocks dot com]

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