[Bug c/52146] New: [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[Bug c/52146] New: [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[steffen-schmidt at siemens dot com]

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

             Bug #: 52146
           Summary: [x32] - Wrong code to access addresses 0x80000000 to
                    0xFFFFFFFF
    Classification: Unclassified
           Product: gcc
           Version: 4.6.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: steffen-schmidt@siemens.com


Created attachment 26596
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26596
C code resulting in wrong instructions when compiled with -mx32 and O1 or
higher

When accessing memory addresses in the region 0x80000000 to 0xFFFFFFFF starting
from optimization -O1 or higher -mx32 GCC seems to generate faulty assembler
instructions.

Using -mx32 GCC will generate code for x86_64 target but using 4 byte pointers
(instead of 8 byte pointers when using -m64). Nonetheless we're running on a
x86_64 64bit machine.

The example shows the problem:
typedef unsigned int uint32_t;
volatile uint32_t * apic_tpr_addr = (uint32_t*)0xfee00080;
*apic_tpr_addr = 0;


GCC -mx32 generates the following assembler instructions:
movl    $0, -18874240

On on x86 32bit system, this instruction would be correct, movl uses signed
addresses as destination when directly accessing memory. On an x86_64 system,
on the other hand, this instruction does not refer to address 0xFEE00080, but
to 0xFFFFFFFFFEE00080, because the signed address is interpreted in 64bit by
the processor, which leads to an error.

GCC -m64 generates the correct instructions:
xorl    %eax, %eax
movabsl    %eax, 4276093056

It seems to be necessary to use movabsl instruction instead of movl.


The problem does not occur by forcing access to memory via a register:
volatile uintptr_t ptr = 0xfee00080;
volatile uint32_t * apic_tpr_addr = (uint32_t*)ptr;
*apic_tpr_addr = 0;

In this case -mx32 GCC generates the follwoing code:
movl    $-18874240, -4(%esp)
movl    -4(%esp), %eax
movl    $0, (%eax)
Here the access to memory is correct, using 32bit register eax

Code generated by -m64 GCC looks similar, but using 64bit addresses and
registers.
movl    $4276093056, %eax
movq    %rax, -8(%rsp)
movq    -8(%rsp), %rax
movl    $0, (%rax)

[Bug c/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[steffen-schmidt at siemens dot com]

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

--- Comment #2 from Steffen Schmidt <steffen-schmidt at siemens dot com> 2012-02-07 08:58:30 UTC ---
Created attachment 26598
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26598
Generate -m64 assembler

[Bug c/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[steffen-schmidt at siemens dot com]

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

--- Comment #1 from Steffen Schmidt <steffen-schmidt at siemens dot com> 2012-02-07 08:58:00 UTC ---
Created attachment 26597
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26597
Generated -mx32 assembler

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-02-07
     Ever Confirmed|0                           |1

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-02-07 17:07:23 UTC ---
(insn 5 4 0 (set (mem/s/v:SI (const_int -18874240 [0xfffffffffee00080]) [3
MEM[(volatile struct apic_test_t *)4276093056B].blubb1+0 S4 A32])
        (const_int 0 [0])) t67.c:27 -1
     (nil))

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[ubizjak at gmail dot com]

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

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #4 from Uros Bizjak <ubizjak at gmail dot com> 2012-02-09 22:35:05 UTC ---
CC author.

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> 2012-02-10 00:21:18 UTC ---
Created attachment 26636
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26636
A patch

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-02-10 07:43:12 UTC ---
0x80000000 to 0x7fffffff should read 0x80000000 to 0xffffffff in the patch.

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[ubizjak at gmail dot com]

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

--- Comment #7 from Uros Bizjak <ubizjak at gmail dot com> 2012-02-10 10:14:36 UTC ---
(In reply to comment #5)
> Created attachment 26636 [details]
> A patch

This should be implemented in constant_address_p.

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[steffen-schmidt at siemens dot com]

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

--- Comment #8 from Steffen Schmidt <steffen-schmidt at siemens dot com> 2012-02-10 12:23:00 UTC ---
(In reply to comment #5)
> Created attachment 26636 [details]
> A patch

I've tried the patch, it applied cleanly, but unfortunately it had no effect on
the generated code.
The gcc built is based on latest of branch hjl/x32/gcc-4_6-branch+mx32, should
I switch to another gcc branch?

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[ubizjak at gmail dot com]

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

--- Comment #9 from Uros Bizjak <ubizjak at gmail dot com> 2012-02-10 17:05:47 UTC ---
HJ, Steffen, can you please test following patch instead:

--cut here--
Index: i386/i386.c
===================================================================
--- i386/i386.c (revision 184096)
+++ i386/i386.c (working copy)
@@ -11932,6 +11932,13 @@ ix86_legitimate_address_p (enum machine_mode mode
   rtx base, index, disp;
   HOST_WIDE_INT scale;

+  /* Since constant address in x32 is signed extended to 64bit,
+     we have to prevent addresses from 0x80000000 to 0xffffffff.  */
+  if (TARGET_X32
+      && CONST_INT_P (addr)
+      && val_signbit_known_set_p (SImode, INTVAL (addr)))
+    return false;
+
   if (ix86_decompose_address (addr, &parts) <= 0)
     /* Decomposition failed.  */
     return false;
--cut here--

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> 2012-02-10 17:28:54 UTC ---
(In reply to comment #9)
> HJ, Steffen, can you please test following patch instead:
> 
> --cut here--
> Index: i386/i386.c
> ===================================================================
> --- i386/i386.c (revision 184096)
> +++ i386/i386.c (working copy)
> @@ -11932,6 +11932,13 @@ ix86_legitimate_address_p (enum machine_mode mode
>    rtx base, index, disp;
>    HOST_WIDE_INT scale;
> 
> +  /* Since constant address in x32 is signed extended to 64bit,
> +     we have to prevent addresses from 0x80000000 to 0xffffffff.  */
> +  if (TARGET_X32
> +      && CONST_INT_P (addr)
> +      && val_signbit_known_set_p (SImode, INTVAL (addr)))
> +    return false;
> +
>    if (ix86_decompose_address (addr, &parts) <= 0)
>      /* Decomposition failed.  */
>      return false;
> --cut here--

It works.

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[ubizjak at gmail dot com]

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

--- Comment #11 from Uros Bizjak <ubizjak at gmail dot com> 2012-02-10 17:42:30 UTC ---
(In reply to comment #9)
> HJ, Steffen, can you please test following patch instead:

val_signbit_known_set_p is a bit overkill, following patch works as well:

--cut here--
Index: i386.c
===================================================================
--- i386.c      (revision 184096)
+++ i386.c      (working copy)
@@ -11932,6 +11932,13 @@ ix86_legitimate_address_p (enum machine_mode mode
   rtx base, index, disp;
   HOST_WIDE_INT scale;

+  /* Since constant address in x32 is signed extended to 64bit,
+     we have to prevent addresses from 0x80000000 to 0xffffffff.  */
+  if (TARGET_X32
+      && CONST_INT_P (addr)
+      && INTVAL (addr) < 0)
+    return false;
+
   if (ix86_decompose_address (addr, &parts) <= 0)
     /* Decomposition failed.  */
     return false;
--cut here--

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-02-10 17:48:42 UTC ---
What if the CONST_INT is from DImode expansion instead of SImode?
val_signbit_known_set_p would handle that, INTVAL () < 0 not.

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[ubizjak at gmail dot com]

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

--- Comment #13 from Uros Bizjak <ubizjak at gmail dot com> 2012-02-10 18:01:29 UTC ---
(In reply to comment #12)
> What if the CONST_INT is from DImode expansion instead of SImode?
> val_signbit_known_set_p would handle that, INTVAL () < 0 not.

I have tested this case, and was not able to pass any constant that didn't fit
SImode to legitimate_address_p.

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[hjl at gcc dot gnu.org]

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

--- Comment #14 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> 2012-02-10 18:23:16 UTC ---
Author: hjl
Date: Fri Feb 10 18:23:12 2012
New Revision: 184111

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184111
Log:
Disallow negative constant address for x32

gcc/

2012-02-10  Uros Bizjak  <ubizjak@gmail.com>

    PR target/52146
    * config/i386/i386.c (ix86_legitimate_address_p): Disallow
    negative constant address for x32.

gcc/testsuite/

2012-02-10  H.J. Lu  <hongjiu.lu@intel.com>

    PR target/52146
    * gcc.target/i386/pr52146.c: New.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/ChangeLog

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[hjl at gcc dot gnu.org]

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

--- Comment #15 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> 2012-02-10 20:03:11 UTC ---
Author: hjl
Date: Fri Feb 10 20:03:08 2012
New Revision: 184113

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184113
Log:
Add the testcase for PR 52146

Added:
    trunk/gcc/testsuite/gcc.target/i386/pr52146.c

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[hjl.tools at gmail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> 2012-02-11 04:21:21 UTC ---
Fixed on trunk, hjl/x32/gcc-4_6-branch and hjl/x32/gcc-4_6-branch+mx32.

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[hjl.tools at gmail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.7.0

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[steffen-schmidt at siemens dot com]

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

--- Comment #17 from Steffen Schmidt <steffen-schmidt at siemens dot com> 2012-02-13 10:52:31 UTC ---
Fixes work fine, thanks alot!

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[pinskia at gcc dot gnu.org]

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

--- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-02-23 17:27:29 UTC ---
*** Bug 52352 has been marked as a duplicate of this bug. ***

[Bug target/52146] [x32] - Wrong code to access addresses 0x80000000 to 0xFFFFFFFF

[hjl at gcc dot gnu.org]

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

--- Comment #19 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> 2012-03-04 21:17:37 UTC ---
Author: hjl
Date: Sun Mar  4 21:17:34 2012
New Revision: 184898

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184898
Log:
Update gcc.target/i386/pr52146.c to allow $-18874240

2012-03-04  H.J. Lu  <hongjiu.lu@intel.com>

    PR target/52146
    * gcc.target/i386/pr52146.c: Update final-scan to allow $-18874240.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.target/i386/pr52146.c