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

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

[steffen-schmidt at siemens dot com]

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.

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

[steffen-schmidt at siemens dot com]

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

--- Comment #1 from Steffen Schmidt <steffen-schmidt at siemens dot com> 2012-04-05 08:19:24 UTC ---
Created attachment 27097
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27097
Example code v2

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

[steffen-schmidt at siemens dot com]

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

--- Comment #3 from Steffen Schmidt <steffen-schmidt at siemens dot com> 2012-04-05 08:20:23 UTC ---
Created attachment 27099
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27099
Assembly -O0

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

[steffen-schmidt at siemens dot com]

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

--- Comment #2 from Steffen Schmidt <steffen-schmidt at siemens dot com> 2012-04-05 08:19:49 UTC ---
Created attachment 27098
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27098
Example code v3

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

[steffen-schmidt at siemens dot com]

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

--- Comment #4 from Steffen Schmidt <steffen-schmidt at siemens dot com> 2012-04-05 08:21:03 UTC ---
Created attachment 27100
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27100
Assembly -O1 -mx32 gcc 4.7.0

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

[steffen-schmidt at siemens dot com]

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

--- Comment #5 from Steffen Schmidt <steffen-schmidt at siemens dot com> 2012-04-05 08:21:38 UTC ---
Created attachment 27101
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27101
Assembly -O1 -mx32 gcc 4.6.3 x32 branch

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

[ubizjak at gmail dot com]

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

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |52854

--- Comment #6 from Uros Bizjak <ubizjak at gmail dot com> 2012-04-05 10:16:32 UTC ---
This is similar issue as PR 52854, but this time:

(insn 6 3 7 2 (set (reg/f:DI 64 [ addr ])
        (sign_extend:DI (subreg/u:SI (reg/v/f:DI 63 [ addr ]) 0))) pr52876.c:6
122 {*extendsidi2_rex64}
     (expr_list:REG_DEAD (reg/v/f:DI 63 [ addr ])
        (nil)))

(insn 7 6 8 2 (parallel [
            (set (reg:DI 61 [ li.4 ])
                (and:DI (reg/f:DI 64 [ addr ])
                    (const_int 4294967295 [0xffffffff])))
            (clobber (reg:CC 17 flags))
        ]) pr52876.c:10 377 {*anddi_1}
     (expr_list:REG_DEAD (reg/f:DI 64 [ addr ])
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (nil))))

combine converts this to:

Trying 6 -> 7:
Successfully matched this instruction:
(set (reg:DI 61 [ li.4 ])
    (reg/v/f:DI 63 [ addr ]))

(note 6 3 7 2 NOTE_INSN_DELETED)

(insn 7 6 8 2 (set (reg:DI 61 [ li.4 ])
        (reg/v/f:DI 63 [ addr ])) pr52876.c:10 62 {*movdi_internal_rex64}
     (expr_list:REG_DEAD (reg/v/f:DI 63 [ addr ])
        (nil)))

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

[ubizjak at gmail dot com]

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

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|52854                       |52838

--- Comment #7 from Uros Bizjak <ubizjak at gmail dot com> 2012-04-05 10:17:37 UTC ---
(In reply to comment #6)
> This is similar issue as PR 52854, but this time:

Oops, PR 52838.

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

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> 2012-04-05 13:42:30 UTC ---
The reason why GCC 4.6 works is it uses SImode for Pmode.
On trunk, I got

[hjl@gnu-6 pr52876]$ cat x.i
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;
}
[hjl@gnu-6 pr52876]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O  x.i
-maddress-mode=long
[hjl@gnu-6 pr52876]$ cat x.s
    .file    "x.i"
    .text
    .globl    testfunc
    .type    testfunc, @function
testfunc:
.LFB0:
    .cfi_startproc
    movslq    %edi, %rax
    movq    %rax, li(%rip)
    ret
    .cfi_endproc
.LFE0:
    .size    testfunc, .-testfunc
    .comm    li,8,8
    .ident    "GCC: (GNU) 4.8.0 20120403 (experimental)"
    .section    .note.GNU-stack,"",@progbits
[hjl@gnu-6 pr52876]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -S -o x.s -mx32 -O  x.i
-maddress-mode=short
[hjl@gnu-6 pr52876]$ cat x.s
    .file    "x.i"
    .text
    .globl    testfunc
    .type    testfunc, @function
testfunc:
.LFB0:
    .cfi_startproc
    movq    %rdi, %rax
    movq    %rdi, li(%rip)
    ret
    .cfi_endproc
.LFE0:
    .size    testfunc, .-testfunc
    .comm    li,8,8
    .ident    "GCC: (GNU) 4.8.0 20120403 (experimental)"
    .section    .note.GNU-stack,"",@progbits
[hjl@gnu-6 pr52876]$ 

-maddress-mode=long generates the wrong code.  We have a
POINTERS_EXTEND_UNSIGNED bug.

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

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ubizjak at gmail dot com

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> 2012-04-05 13:49:31 UTC ---
On trunk, cse1 turns

(insn 6 3 7 2 (set (reg:DI 64)
        (sign_extend:DI (subreg/u:SI (reg/v/f:DI 63 [ addr ]) 0))) x.i:6 122
{*e
xtendsidi2_rex64}
     (nil))

(insn 7 6 8 2 (parallel [
            (set (reg:DI 61 [ li.3 ])
                (and:DI (reg:DI 64)
                    (const_int 4294967295 [0xffffffff])))
            (clobber (reg:CC 17 flags))
        ]) x.i:10 377 {*anddi_1}
     (nil))

(insn 8 7 9 2 (set (mem/c:DI (symbol_ref:DI ("li")  <var_decl 0x7ffff19b8140
li>
) [0 li+0 S8 A64])
        (reg:DI 61 [ li.3 ])) x.i:10 62 {*movdi_internal_rex64}
     (nil))

into

(insn 6 3 7 2 (set (reg/f:DI 64 [ addr ])
        (sign_extend:DI (subreg/u:SI (reg/v/f:DI 63 [ addr ]) 0))) x.i:6 122
{*e
xtendsidi2_rex64}
     (nil))

(insn 7 6 8 2 (set (reg:DI 61 [ li.3 ])
        (reg/f:DI 64 [ addr ])) x.i:10 62 {*movdi_internal_rex64}
     (nil))

(insn 8 7 9 2 (set (mem/c:DI (symbol_ref:DI ("li")  <var_decl 0x7ffff19b8140
li>
) [0 li+0 S8 A64])
        (reg/f:DI 64 [ addr ])) x.i:10 62 {*movdi_internal_rex64}
     (nil))

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

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> 2012-04-05 14:30:40 UTC ---
simplify_binary_operation (code=AND, mode=DImode, op0=0x7ffff1ac0900, 
    op1=0x7ffff1a8ffb0) at /export/gnu/import/git/gcc/gcc/simplify-rtx.c:1893
1893      gcc_assert (GET_RTX_CLASS (code) != RTX_COMPARE);
(gdb) call debug_rtx (op0)
(reg/f:DI 64 [ addr ])
(gdb) call debug_rtx (op1)
(const_int 4294967295 [0xffffffff])
(gdb) 

returns

(reg/f:DI 64 [ addr ])

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

[ubizjak at gmail dot com]

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

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-04-05
          Component|target                      |rtl-optimization
     Ever Confirmed|0                           |1

--- Comment #11 from Uros Bizjak <ubizjak at gmail dot com> 2012-04-05 15:16:30 UTC ---
Confirmed as rtl optimization issue.

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

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |UNCONFIRMED
          Component|rtl-optimization            |target
     Ever Confirmed|1                           |0

--- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> 2012-04-05 15:21:15 UTC ---
The problem starts with

(insn 6 3 7 2 (set (reg/f:DI 64 [ addr ])
        (sign_extend:DI (subreg/u:SI (reg/v/f:DI 63 [ addr ]) 0))) x.i:6 122
{*e
xtendsidi2_rex64}
     (nil))

Reg 64 shouldn't be frame related after sign-extension.

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

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> 2012-04-05 15:46:02 UTC ---
We shouldn't copy REG_POINTER from SIGN_EXTEND on target with
POINTERS_EXTEND_UNSIGNED > 0.  This patch works for me:

diff --git a/gcc/reginfo.c b/gcc/reginfo.c
index 6353126..77a7e66 100644
--- a/gcc/reginfo.c
+++ b/gcc/reginfo.c
@@ -1225,8 +1225,12 @@ reg_scan_mark_refs (rtx x, rtx insn)
     {
       rtx src = SET_SRC (x);

-      while (GET_CODE (src) == SIGN_EXTEND
-         || GET_CODE (src) == ZERO_EXTEND
+      while (GET_CODE (src) == ZERO_EXTEND
+         || (GET_CODE (src) == SIGN_EXTEND
+#ifdef POINTERS_EXTEND_UNSIGNED
+             && POINTERS_EXTEND_UNSIGNED <= 0
+#endif
+            )
          || GET_CODE (src) == TRUNCATE
          || (GET_CODE (src) == SUBREG && subreg_lowpart_p (src)))
         src = XEXP (src, 0);

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

[hjl.tools at gmail dot com]

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

--- Comment #14 from H.J. Lu <hjl.tools at gmail dot com> 2012-04-10 14:49:37 UTC ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00320.html

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

[hjl at gcc dot gnu.org]

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

--- Comment #15 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> 2012-04-11 19:31:49 UTC ---
Author: hjl
Date: Wed Apr 11 19:31:45 2012
New Revision: 186351

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186351
Log:
Check for incompatible pointer sign extension

gcc/

    PR rtl-optimization/52876
    * emit-rtl.c (set_reg_attrs_from_value): Handle arbitrary value.
    Don't call mark_reg_pointer for incompatible pointer sign
    extension.

    * reginfo.c (reg_scan_mark_refs): Call set_reg_attrs_from_value 
    directly.

gcc/testsuite

    PR rtl-optimization/52876
    * gcc.target/i386/pr52876.c: New.

Added:
    trunk/gcc/testsuite/gcc.target/i386/pr52876.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/emit-rtl.c
    trunk/gcc/reginfo.c
    trunk/gcc/testsuite/ChangeLog

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

[steffen-schmidt at siemens dot com]

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

--- Comment #16 from Steffen Schmidt <steffen-schmidt at siemens dot com> 2013-02-07 11:49:38 UTC ---
The proposed patch works on GCC 4.7.0.

Has this patch already found its way into a GCC release. I was not able to find
it applied in GCC 4.7.1/4.7.2?

Would it be possible to bring it into future releases?

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

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|2012-04-05 00:00:00         |2013-02-07
     Ever Confirmed|0                           |1

--- Comment #17 from H.J. Lu <hjl.tools at gmail dot com> 2013-02-07 16:33:24 UTC ---
The fix is on hjl/x32/gcc-4_7-branch branch.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |4.8.0

--- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed long ago.