[Bug middle-end/49798] New: .quad instead of .long is used for address for x32

[Bug middle-end/49798] New: .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

           Summary: .quad instead of .long is used for address for x32
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hjl.tools@gmail.com


---
union U
{
  int *m;
  double d;
};

extern int xxxx;

int
foo (union U u)
{
  union U v = { &xxxx};
  return u.d == v.d;
}
---

I got

[hjl@gnu-6 gcc]$ ./xgcc -B./ -mx32 -O2 -S x.c 
[hjl@gnu-6 gcc]$ cat x.s
    .file    "x.c"
    .text
    .p2align 4,,15
    .globl    foo
    .type    foo, @function
foo:
.LFB0:
    .cfi_startproc
    movq    %rdi, -8(%rsp)
    movsd    .LC0(%rip), %xmm1
    movsd    -8(%rsp), %xmm0
    movl    $1, %eax
    ucomisd    %xmm1, %xmm0
    jp    .L3
    jne    .L3
    rep
    ret
    .p2align 4,,10
    .p2align 3
.L3:
    xorl    %eax, %eax
    .p2align 4,,9
    ret
    .cfi_endproc
.LFE0:
    .size    foo, .-foo
    .section    .rodata.cst8,"aM",@progbits,8
    .align 8
.LC0:
    .quad    xxxx
    .ident    "GCC: (GNU) 4.7.0 20110720 (experimental)"
    .section    .note.GNU-stack,"",@progbits
[hjl@gnu-6 gcc]$

[Bug middle-end/49798] .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-21 00:56:19 UTC ---
It comes from constant pool:

(gdb) bt
#0  integer_asm_op (size=8, aligned_p=1) at
/export/gnu/import/git/gcc-x32/gcc/varasm.c:2421
#1  0x0000000000df1a96 in default_assemble_integer (x=0x7ffff074fec0, size=8,
aligned_p=1)
    at /export/gnu/import/git/gcc-x32/gcc/varasm.c:2461
#2  0x0000000000df1b79 in assemble_integer (x=0x7ffff074fec0, size=8, align=64,
force=1)
    at /export/gnu/import/git/gcc-x32/gcc/varasm.c:2482
#3  0x0000000000df8040 in output_constant_pool_2 (mode=DImode,
x=0x7ffff074fec0, align=64)
    at /export/gnu/import/git/gcc-x32/gcc/varasm.c:3654
#4  0x0000000000df82a8 in output_constant_pool_1 (desc=0x7ffff07ae680,
align=64)
    at /export/gnu/import/git/gcc-x32/gcc/varasm.c:3736
#5  0x0000000000df874a in output_constant_pool_contents (pool=0x7ffff084a360)
    at /export/gnu/import/git/gcc-x32/gcc/varasm.c:3856
#6  0x0000000000df87a3 in output_shared_constant_pool ()
    at /export/gnu/import/git/gcc-x32/gcc/varasm.c:3891
#7  0x0000000000af21de in compile_file () at
/export/gnu/import/git/gcc-x32/gcc/toplev.c:579
#8  0x0000000000af4392 in do_compile () at
/export/gnu/import/git/gcc-x32/gcc/toplev.c:1886
#9  0x0000000000af44f8 in toplev_main (argc=15, argv=0x7fffffffdf48)
    at /export/gnu/import/git/gcc-x32/gcc/toplev.c:1958
#10 0x00000000005ab9ec in main (argc=15, argv=0x7fffffffdf48)
    at /export/gnu/import/git/gcc-x32/gcc/main.c:36
(gdb) f 2
#2  0x0000000000df1b79 in assemble_integer (x=0x7ffff074fec0, size=8, align=64,
force=1)
    at /export/gnu/import/git/gcc-x32/gcc/varasm.c:2482
2482      if (targetm.asm_out.integer (x, size, aligned_p))
(gdb) call debug_rtx (x)
(symbol_ref:DI ("xxxx") [flags 0x40] <var_decl 0x7ffff0859140 xxxx>)
(gdb) 

To get Pmode value out of symbol in ptr_mode, we have to do zero-extension
ourself.

[Bug target/49798] .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |target

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-21 01:07:29 UTC ---
We need to define TARGET_ASM_INTEGER for x32.

[Bug target/49798] .quad instead of .long is used for address for x32

[ubizjak at gmail dot com]

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

--- Comment #3 from Uros Bizjak <ubizjak at gmail dot com> 2011-07-21 10:25:28 UTC ---
(In reply to comment #1)

> To get Pmode value out of symbol in ptr_mode, we have to do zero-extension
> ourself.

Linker should put correct address (so, zero extended 32bit address) here.

[Bug target/49798] .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-p
                   |                            |atches/2011-07/msg01711.htm
                   |                            |l

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-21 13:09:21 UTC ---
(In reply to comment #3)
> (In reply to comment #1)
> 
> > To get Pmode value out of symbol in ptr_mode, we have to do zero-extension
> > ourself.
> 
> Linker should put correct address (so, zero extended 32bit address) here.

Did you mean assembler? In many cases, .quad is still simply wrong (PR 47446).
GCC shouldn't generate .quad in this case.  A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01711.html

[Bug target/49798] .quad instead of .long is used for address for x32

[ubizjak at gmail dot com]

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

--- Comment #5 from Uros Bizjak <ubizjak at gmail dot com> 2011-07-21 13:30:22 UTC ---
(In reply to comment #4)

> > Linker should put correct address (so, zero extended 32bit address) here.
> 
> Did you mean assembler? In many cases, .quad is still simply wrong (PR 47446).

No, the linker. But looking at mentioned PR, linker is not able to generate
BFD_RELOC_64.

> GCC shouldn't generate .quad in this case.  A patch is posted at
> 
> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01711.html

IMO, this patch is wrong. Generated code should look like the one for i686, so
it looks to me that check for Pmode != ptr_mode is missing somewhere in the
middle end.

[Bug target/49798] .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-21 14:02:54 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> 
> > > Linker should put correct address (so, zero extended 32bit address) here.
> > 
> > Did you mean assembler? In many cases, .quad is still simply wrong (PR 47446).
> 
> No, the linker. But looking at mentioned PR, linker is not able to generate
> BFD_RELOC_64.

That is correct. We shouldn't have BFD_RELOC_64 in 32bit.

> > GCC shouldn't generate .quad in this case.  A patch is posted at
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01711.html
> 
> IMO, this patch is wrong. Generated code should look like the one for i686, so
> it looks to me that check for Pmode != ptr_mode is missing somewhere in the
> middle end.

That is not necessarily true if Pmode is used here.
In this regard, x32 is the same as x86-64.  Basically
a 64bit value is generated from an address. If address
is 32bit, we just need to zero-extend it.

[Bug target/49798] .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-21 15:53:56 UTC ---
IRA generates

(insn 13 3 18 2 (set (reg/v:DI 21 xmm0 [orig:63 v ] [63])
        (mem/u/c/i:DI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S8 A64]))
x.i:12 62 {*movdi_internal_rex64}
     (expr_list:REG_EQUIV (symbol_ref:DI ("xxxx") [flags 0x40]  <var_decl
0x7f4068bbc140 xxxx>)
        (nil)))

This requires zero-extending 32bit address to 64bit.

[Bug target/49798] .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-21 16:03:20 UTC ---
(In reply to comment #7)
> IRA generates
> 
> (insn 13 3 18 2 (set (reg/v:DI 21 xmm0 [orig:63 v ] [63])
>         (mem/u/c/i:DI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S8 A64]))
> x.i:12 62 {*movdi_internal_rex64}
>      (expr_list:REG_EQUIV (symbol_ref:DI ("xxxx") [flags 0x40]  <var_decl
> 0x7f4068bbc140 xxxx>)
>         (nil)))
> 
> This requires zero-extending 32bit address to 64bit.

I am not sure how we can express it in constant pool beyond what
we have today.  I can add a new assembler directive, xquad, so that we do
something similar to

/* Target hook for assembling integer objects.  The sparc version has
   special handling for aligned DI-mode objects.  */

static bool
sparc_assemble_integer (rtx x, unsigned int size, int aligned_p)
{
  /* ??? We only output .xword's for symbols and only then in environments
     where the assembler can handle them.  */
  if (aligned_p && size == 8
      && (GET_CODE (x) != CONST_INT && GET_CODE (x) != CONST_DOUBLE))
    {
      if (TARGET_V9)
        {
          assemble_integer_with_op ("\t.xword\t", x);
          return true;
        }
      else
        {
          assemble_aligned_integer (4, const0_rtx);
          assemble_aligned_integer (4, x);
          return true;
        }
    }
  return default_assemble_integer (x, size, aligned_p);
}

[Bug target/49798] .quad instead of .long is used for address for x32

[ubizjak at gmail dot com]

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

--- Comment #9 from Uros Bizjak <ubizjak at gmail dot com> 2011-07-21 16:25:49 UTC ---
Please compare optimized tree dumps from i686 (a) compilation vs x32 (b):

(a)

foo (union U u)
{
  union U v;
  _Bool D.2000;
  double D.1999;
  double D.1998;
  int D.1997;

<bb 2>:
  v = {};
  v.m = &xxxx;
  D.1998_1 = u.d;
  D.1999_2 = v.d;
  D.2000_3 = D.1998_1 == D.1999_2;
  D.1997_4 = (int) D.2000_3;
  return D.1997_4;

}

(b)

foo (union U u)
{
  double D.2709;
  _Bool D.2704;
  double D.2702;
  int D.2701;

<bb 2>:
  D.2709_8 = VIEW_CONVERT_EXPR<double>(&xxxx);
  D.2702_1 = u.d;
  D.2704_3 = D.2702_1 == D.2709_8;
  D.2701_4 = (int) D.2704_3;
  return D.2701_4;

}

We can't directly move &xxxx (32bit value) to double (64bit value).

However, we expand to:

(insn 6 5 11 (set (reg/f:DI 66)
        (symbol_ref:DI ("xxxx") [flags 0x40]  <var_decl 0x7f71c5925140 xxxx>))
pr49798.c:12 -1
     (nil))

...

(insn 13 12 14 (set (reg:CCFPU 17 flags)
        (compare:CCFPU (reg:DF 73)
            (subreg:DF (reg/f:DI 66) 0))) pr49798.c:13 -1
     (nil))

Does this looks OK?

[Bug target/49798] .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-21 16:32:01 UTC ---
(In reply to comment #9)
> Please compare optimized tree dumps from i686 (a) compilation vs x32 (b):
> 
> (a)
> 
> foo (union U u)
> {
>   union U v;
>   _Bool D.2000;
>   double D.1999;
>   double D.1998;
>   int D.1997;
> 
> <bb 2>:
>   v = {};
>   v.m = &xxxx;
>   D.1998_1 = u.d;
>   D.1999_2 = v.d;
>   D.2000_3 = D.1998_1 == D.1999_2;
>   D.1997_4 = (int) D.2000_3;
>   return D.1997_4;
> 
> }
> 
> (b)
> 
> foo (union U u)
> {
>   double D.2709;
>   _Bool D.2704;
>   double D.2702;
>   int D.2701;
> 
> <bb 2>:
>   D.2709_8 = VIEW_CONVERT_EXPR<double>(&xxxx);
>   D.2702_1 = u.d;
>   D.2704_3 = D.2702_1 == D.2709_8;
>   D.2701_4 = (int) D.2704_3;
>   return D.2701_4;
> 
> }
> 
> We can't directly move &xxxx (32bit value) to double (64bit value).
> 
> However, we expand to:
> 
> (insn 6 5 11 (set (reg/f:DI 66)
>         (symbol_ref:DI ("xxxx") [flags 0x40]  <var_decl 0x7f71c5925140 xxxx>))
> pr49798.c:12 -1
>      (nil))
> 
> ...
> 
> (insn 13 12 14 (set (reg:CCFPU 17 flags)
>         (compare:CCFPU (reg:DF 73)
>             (subreg:DF (reg/f:DI 66) 0))) pr49798.c:13 -1
>      (nil))
> 
> Does this looks OK?

We can't compare x32 directly with ia32 since ia32 doesn't support
movdi_internal_rex64.  We want to use 64bit instructions for x32.

[Bug target/49798] .quad instead of .long is used for address for x32

[ubizjak at gmail dot com]

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

--- Comment #11 from Uros Bizjak <ubizjak at gmail dot com> 2011-07-21 16:36:56 UTC ---
(In reply to comment #10)

> > Does this looks OK?
> 
> We can't compare x32 directly with ia32 since ia32 doesn't support
> movdi_internal_rex64.  We want to use 64bit instructions for x32.

The problem is not in compare, but in

(insn 6 5 11 (set (reg/f:DI 66)
        (symbol_ref:DI ("xxxx") [flags 0x40]  <var_decl 0x7f71c5925140 xxxx>))
pr49798.c:12 -1
     (nil))

Expander should choose SImode register here and SImode symbol reference.

[Bug target/49798] .quad instead of .long is used for address for x32

[ubizjak at gmail dot com]

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

Uros Bizjak <ubizjak at gmail dot com> changed:

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

--- Comment #12 from Uros Bizjak <ubizjak at gmail dot com> 2011-07-21 16:46:36 UTC ---
(In reply to comment #9)
> Please compare optimized tree dumps from i686 (a) compilation vs x32 (b):
> 
> (a)
> 
> foo (union U u)
> {
>   union U v;
>   _Bool D.2000;
>   double D.1999;
>   double D.1998;
>   int D.1997;
> 
> <bb 2>:
>   v = {};
>   v.m = &xxxx;
>   D.1998_1 = u.d;
>   D.1999_2 = v.d;
>   D.2000_3 = D.1998_1 == D.1999_2;
>   D.1997_4 = (int) D.2000_3;
>   return D.1997_4;
> 
> }
> 
> (b)
> 
> foo (union U u)
> {
>   double D.2709;
>   _Bool D.2704;
>   double D.2702;
>   int D.2701;
> 
> <bb 2>:
>   D.2709_8 = VIEW_CONVERT_EXPR<double>(&xxxx);
>   D.2702_1 = u.d;
>   D.2704_3 = D.2702_1 == D.2709_8;
>   D.2701_4 = (int) D.2704_3;
>   return D.2701_4;
> 
> }
> 
> We can't directly move &xxxx (32bit value) to double (64bit value).
> 
> However, we expand to:
> 
> (insn 6 5 11 (set (reg/f:DI 66)
>         (symbol_ref:DI ("xxxx") [flags 0x40]  <var_decl 0x7f71c5925140 xxxx>))
> pr49798.c:12 -1
>      (nil))
> 
> ...
> 
> (insn 13 12 14 (set (reg:CCFPU 17 flags)
>         (compare:CCFPU (reg:DF 73)
>             (subreg:DF (reg/f:DI 66) 0))) pr49798.c:13 -1
>      (nil))
> 
> Does this looks OK?

IMO, VIEW_CONVERT_EXPR is already wrong, let's CC richi for opinion.

[Bug target/49798] .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-21 17:16:35 UTC ---
With -mx32 -O, I got

foo (union U u)
{
  union U v;
  _Bool D.2704;
  double D.2703;
  double D.2702;
  int D.2701;

  # BLOCK 2 freq:10000
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  v = {};
  v.m = &xxxx;
  D.2702_1 = u.d;
  D.2703_2 = v.d;
  D.2704_3 = D.2702_1 == D.2703_2;
  D.2701_4 = (int) D.2704_3;
  return D.2701_4;
  # SUCC: EXIT [100.0%] 

}

In x.i.153r.dfinit,

(insn 8 6 9 2 (set (reg:SI 68) 
        (symbol_ref:SI ("xxxx") [flags 0x40]  <var_decl 0x7fd45d36e140 xxxx>))
x.i:12 64 {*movsi_internal}
     (nil))

(insn 9 8 10 2 (set (reg:DI 67) 
        (zero_extend:DI (reg:SI 68))) x.i:12 112 {*zero_extendsidi2_rex64}
     (nil))

x.i.154r.cse1 has

(insn 8 6 9 2 (set (reg/f:SI 68) 
        (symbol_ref:SI ("xxxx") [flags 0x40]  <var_decl 0x7fd45d36e140 xxxx>))
x.i:12 64 {*movsi_internal}
     (nil))

(insn 9 8 10 2 (set (reg/f:DI 67) 
        (symbol_ref:DI ("xxxx") [flags 0x40]  <var_decl 0x7fd45d36e140 xxxx>))
x.i:12 62 {*movdi_internal_rex64}
     (nil))

[Bug target/49798] .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

--- Comment #14 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-21 17:19:06 UTC ---
It looks like (symbol_ref:DI ("xxxx")) is treated as zero_extend
for symbol address.  My patch just does that, similar to Sparc.

[Bug target/49798] .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

--- Comment #15 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-21 17:24:01 UTC ---
Another example:

[hjl@gnu-6 pr49798]$ cat y.i
union U
{
  int *m;
  long long d;
};
extern int xxxx;
long long
foo ()
{
  union U v = { &xxxx};
  return v.d;
}
[hjl@gnu-6 pr49798]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -S -o y.s -mx32 -O -msse4   y.i
-da
[hjl@gnu-6 pr49798]$ cat y.s
    .file    "y.i"
    .text
    .globl    foo
    .type    foo, @function
foo:
.LFB0:
    .cfi_startproc
    movl    $xxxx, %eax
    ret
    .cfi_endproc
.LFE0:
    .size    foo, .-foo
    .ident    "GCC: (GNU) 4.7.0 20110720 (experimental)"
    .section    .note.GNU-stack,"",@progbits
[hjl@gnu-6 pr49798]$ cat y.i.223r.final

;; Function foo (foo, funcdef_no=0, decl_uid=1711, cgraph_uid=0)

(note 1 0 3 NOTE_INSN_DELETED)

(note 3 1 24 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(note 24 3 2 2 NOTE_INSN_PROLOGUE_END)

(note 2 24 17 2 NOTE_INSN_FUNCTION_BEG)

(insn 17 2 20 2 (set (reg/i:DI 0 ax)
        (symbol_ref:DI ("xxxx") [flags 0x40]  <var_decl 0x7ffdb52bb140 xxxx>))
y.i:12 62 {*movdi_internal_rex64}
     (nil))

(insn 20 17 25 2 (use (reg/i:DI 0 ax)) y.i:12 -1
     (nil))

(note 25 20 26 2 NOTE_INSN_EPILOGUE_BEG)

(jump_insn 26 25 27 2 (return) y.i:12 645 {return_internal}
     (nil))

(barrier 27 26 23)

(note 23 27 0 NOTE_INSN_DELETED)
[hjl@gnu-6 pr49798]$

[Bug target/49798] .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

--- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-21 19:59:31 UTC ---
(In reply to comment #9)
> Please compare optimized tree dumps from i686 (a) compilation vs x32 (b):
> 
> (b)
> 
> foo (union U u)
> {
>   double D.2709;
>   _Bool D.2704;
>   double D.2702;
>   int D.2701;
> 
> <bb 2>:
>   D.2709_8 = VIEW_CONVERT_EXPR<double>(&xxxx);
>   D.2702_1 = u.d;
>   D.2704_3 = D.2702_1 == D.2709_8;
>   D.2701_4 = (int) D.2704_3;
>   return D.2701_4;
> 
> }
> 
> 

I didn't see it with -mx32. I got

1. -m64 -O

foo (union U u)
{
  double D.2709;
  _Bool D.2704;
  double D.2702;
  int D.2701;

  # BLOCK 2 freq:10000
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  D.2709_8 = VIEW_CONVERT_EXPR<double>(&xxxx);
  D.2702_1 = u.d;
  D.2704_3 = D.2702_1 == D.2709_8;
  D.2701_4 = (int) D.2704_3;
  return D.2701_4;
  # SUCC: EXIT [100.0%] 

}

2. -mx32 -O:

foo (union U u)
{
  union U v;
  _Bool D.2704;
  double D.2703;
  double D.2702;
  int D.2701;

  # BLOCK 2 freq:10000
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  v = {};
  v.m = &xxxx;
  D.2702_1 = u.d;
  D.2703_2 = v.d;
  D.2704_3 = D.2702_1 == D.2703_2;
  D.2701_4 = (int) D.2704_3;
  return D.2701_4;
  # SUCC: EXIT [100.0%] 

}

Did I miss anything?

[Bug target/49798] .quad instead of .long is used for address for x32

[ubizjak at gmail dot com]

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

--- Comment #17 from Uros Bizjak <ubizjak at gmail dot com> 2011-07-21 20:12:50 UTC ---
(In reply to comment #16)

> I didn't see it with -mx32. I got

Hm, I also don't get this anymore...

[Bug target/49798] .quad instead of .long is used for address for x32

[hjl.tools at gmail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #18 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-22 11:54:45 UTC ---
Won't fix.