[Bug target/52876] New: [x32] - Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher

["steffen-schmidt at siemens dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52876

             Bug #: 52876
           Summary: [x32] - Sign extend 32 to 64bit then clear upper
                    32bits fails O1 or higher
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: steffen-schmidt@siemens.com


Created attachment 27096
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27096
Example code v1

This function sign extends an x32 32bit void* into a 64bit long long global
variable. Afterwards it zeros upper 32bits using binary AND.

long long li;

long long testfunc(void* addr) __attribute__ ((noinline));
long long testfunc(void* addr)
{
  li = (long long)(int)addr;

  // next line is important, if the address from pv
  // has been sign extended with leading ONEs
  li &= 0xffffffff;

  return li;
}


int main (void)
{
    volatile long long rv_test;
    rv_test = testfunc((void*)0x87651234);

    return 0;
}

The following examples are called with parameter (void*)0x87651234

Compiled with gcc 4.7.0 -mx32 -O0 produces:
movq    %rdi, %rax
movl    %eax, -4(%rbp)
movl    -4(%rbp), %eax
cltq #sign extend EAX to RAX, e.g. 0x87651234 to 0xffffffff87651234
movq    %rax, li(%rip)
movq    li(%rip), %rax
andl    $4294967295, %eax  #the AND 0xffffffff, producing 0x0000000087651234
movq    %rax, li(%rip)
movq    li(%rip), %rax

Compiled with gcc 4.7.0 -mx32 -O1 produces:
movslq    %edi, %rax #this is only a sign extend producing 0xffffffff87651234
                   #the zero-ing of the upper 32bits is missing.
movq    %rax, li(%rip)

Compiled with gcc 4.6.3 (x32 branch) -mx32 -O1 produces:
movq    %rdi, %rax #Here the sign extend and the AND are combined to a mov
                   #the results in 0x0000000087651234 which is correct.
movq    %rdi, li(%rip)


It seems that somehow gcc 4.7.0 "forgets" to clear the upper bits, which gcc
4.6.3 branch x32 did correctly.
The effect only happens in a stand-alone function and using a global variable,
when inlining, the result is correct.

I've attached 3 versions of the test, all failing in O1 or higher.  The first
using a global variable, the second a union and a local variable, the third
using a variadic function.