[Bug target/49860] New: [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

[Bug target/49860] New: [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

[hjl.tools at gmail dot com]

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

           Summary: [x32] Error: cannot represent relocation type
                    BFD_RELOC_64 in x32 mode
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hjl.tools@gmail.com
                CC: ubizjak@gmail.com


[hjl@gnu-6 ilp32-30]$ cat x.i
extern char inbuf[];
extern char outbuf[];
extern unsigned insize;
extern unsigned inptr;
static int max_len;
static int peek_bits;
void build_tree() {
  int len;
  char *prefixp;
  max_len = inbuf[inptr++];
  peek_bits = ((max_len) <= (12) ? (max_len) : (12));
  prefixp = &outbuf[1<<peek_bits];
  for (len = 1;
       len <= peek_bits;
       len++) {
  }
  while (prefixp > outbuf) *--prefixp = 0;
}
[hjl@gnu-6 ilp32-30]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -S -o x.s -mx32
-funroll-all-loops -O3 -dp  x.i
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -mx32 -funroll-all-loops -O3
-dp  -c -o x.o x.s
x.s: Assembler messages:
x.s:25: Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
make: *** [x.o] Error 1
[hjl@gnu-6 ilp32-30]

[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

[ubizjak at gmail dot com]

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

--- Comment #1 from Uros Bizjak <ubizjak at gmail dot com> 2011-07-27 08:09:13 UTC ---
Assembler should accept R_X86_64_64 and zero-extend it to 8 bytes. It is the
same issue as [1].

[1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01825.html

[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-27 12:39:39 UTC ---
(In reply to comment #1)
> Assembler should accept R_X86_64_64 and zero-extend it to 8 bytes. It is the
> same issue as [1].
> 
> [1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01825.html

X32 is 32bit environment. For this testcase, x32 should generate
very similar code to ia32, except for additional 8 registers. In
another word, if a memory operand is OK for ia32, it must be OK
for x32.

[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

[ubizjak at gmail dot com]

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

Uros Bizjak <ubizjak at gmail dot com> changed:

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

--- Comment #3 from Uros Bizjak <ubizjak at gmail dot com> 2011-07-27 12:49:52 UTC ---
(In reply to comment #2)

> > Assembler should accept R_X86_64_64 and zero-extend it to 8 bytes. It is the
> > same issue as [1].
> > 
> > [1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01825.html
> 
> X32 is 32bit environment. For this testcase, x32 should generate
> very similar code to ia32, except for additional 8 registers. In
> another word, if a memory operand is OK for ia32, it must be OK
> for x32.

Can you prevent x32 to generate DImode symbols? No, since Pmode is still in
DImode and DImode addresses are *valid* addresses. For the testcase from PR,
expand generates SImode symbol that is later extended to DImode and handled
through movabs.

Your patch just papers over this fact. Assembler should put correctly
zero-extended symbol at the relocation site.

[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-27 12:56:01 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> 
> > > Assembler should accept R_X86_64_64 and zero-extend it to 8 bytes. It is the
> > > same issue as [1].
> > > 
> > > [1] http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01825.html
> > 
> > X32 is 32bit environment. For this testcase, x32 should generate
> > very similar code to ia32, except for additional 8 registers. In
> > another word, if a memory operand is OK for ia32, it must be OK
> > for x32.
> 
> Can you prevent x32 to generate DImode symbols? No, since Pmode is still in
> DImode and DImode addresses are *valid* addresses. For the testcase from PR,
> expand generates SImode symbol that is later extended to DImode and handled
> through movabs.

This testcase is about valid address for x86_64_immediate_operand
and x86_64_zext_immediate_operand.  If it is valid for TARGET_32BIT,
it should be valid for TARGET_X32.

> Your patch just papers over this fact. Assembler should put correctly
> zero-extended symbol at the relocation site.

Assembler is done on purpose to catch problems like this.

[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

[ubizjak at gmail dot com]

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

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

> > Can you prevent x32 to generate DImode symbols? No, since Pmode is still in
> > DImode and DImode addresses are *valid* addresses. For the testcase from PR,
> > expand generates SImode symbol that is later extended to DImode and handled
> > through movabs.
> 
> This testcase is about valid address for x86_64_immediate_operand
> and x86_64_zext_immediate_operand.  If it is valid for TARGET_32BIT,
> it should be valid for TARGET_X32.

(define_predicate "x86_64_immediate_operand"
  (match_code "const_int,symbol_ref,label_ref,const")
{
  if (!TARGET_64BIT)
    return immediate_operand (op, mode);
  ...
}

I guess the code above speaks for itself.

> Assembler is done on purpose to catch problems like this.

This is artificial limitation.

[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-27 15:42:37 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> 
> > > Can you prevent x32 to generate DImode symbols? No, since Pmode is still in
> > > DImode and DImode addresses are *valid* addresses. For the testcase from PR,
> > > expand generates SImode symbol that is later extended to DImode and handled
> > > through movabs.
> > 
> > This testcase is about valid address for x86_64_immediate_operand
> > and x86_64_zext_immediate_operand.  If it is valid for TARGET_32BIT,
> > it should be valid for TARGET_X32.
> 
> (define_predicate "x86_64_immediate_operand"
>   (match_code "const_int,symbol_ref,label_ref,const")
> {
>   if (!TARGET_64BIT)
>     return immediate_operand (op, mode);
>   ...

X32 != LP64.

> 
> I guess the code above speaks for itself.
> 
> > Assembler is done on purpose to catch problems like this.
> 
> This is artificial limitation.

Those generated codes aren't very efficient for x32. There is
a problem somewhere.

[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

[ubizjak at gmail dot com]

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

--- Comment #7 from Uros Bizjak <ubizjak at gmail dot com> 2011-07-27 16:04:47 UTC ---
(In reply to comment #6)

> > > This testcase is about valid address for x86_64_immediate_operand
> > > and x86_64_zext_immediate_operand.  If it is valid for TARGET_32BIT,
> > > it should be valid for TARGET_X32.
> > 
> > (define_predicate "x86_64_immediate_operand"
> >   (match_code "const_int,symbol_ref,label_ref,const")
> > {
> >   if (!TARGET_64BIT)
> >     return immediate_operand (op, mode);
> >   ...
> 
> X32 != LP64.

i686   = TARGET_32BIT
x32    = TARGET_64BIT
x86_64 = TARGET_64BIT

> > This is artificial limitation.
> 
> Those generated codes aren't very efficient for x32. There is
> a problem somewhere.

It is *movdi_internal_rex64. But you can't change it. It must handle all
immediate_operands.

[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-27 16:14:39 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> 
> > > > This testcase is about valid address for x86_64_immediate_operand
> > > > and x86_64_zext_immediate_operand.  If it is valid for TARGET_32BIT,
> > > > it should be valid for TARGET_X32.
> > > 
> > > (define_predicate "x86_64_immediate_operand"
> > >   (match_code "const_int,symbol_ref,label_ref,const")
> > > {
> > >   if (!TARGET_64BIT)
> > >     return immediate_operand (op, mode);
> > >   ...
> > 
> > X32 != LP64.
> 
> i686   = TARGET_32BIT
> x32    = TARGET_64BIT
> x86_64 = TARGET_64BIT
> 

We have TARGET_LP64 and TARGET_X32.

[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> 2011-07-27 16:16:54 UTC ---
Let's punt it for now.  We will investigate it later.

[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

[hjl at gcc dot gnu.org]

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

--- Comment #10 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> 2011-07-29 15:56:38 UTC ---
Author: hjl
Date: Fri Jul 29 15:56:36 2011
New Revision: 176928

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176928
Log:
Rename gcc.target/i386/pr47446-3.c to gcc.target/i386/pr49860-1.c.

2011-07-26  H.J. Lu  <hongjiu.lu@intel.com>

    PR target/49860
    * gcc.target/i386/pr47446-3.c: Renamed to ...
    * gcc.target/i386/pr49860-1.c: This.

Added:
    branches/x32/gcc/testsuite/gcc.target/i386/pr49860-1.c
      - copied unchanged from r176926,
branches/x32/gcc/testsuite/gcc.target/i386/pr47446-3.c
Removed:
    branches/x32/gcc/testsuite/gcc.target/i386/pr47446-3.c
Modified:
    branches/x32/gcc/testsuite/ChangeLog.x32

[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

[ubizjak at gmail dot com]

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

Uros Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x32
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #11 from Uros Bizjak <ubizjak at gmail dot com> 2011-08-02 06:36:28 UTC ---
Fixed in binutils [1], not a gcc bug.

[1] http://sourceware.org/ml/binutils/2011-08/msg00010.html

[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

[hjl at gcc dot gnu.org]

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

--- Comment #12 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> 2011-08-02 14:03:40 UTC ---
Author: hjl
Date: Tue Aug  2 14:03:36 2011
New Revision: 177158

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177158
Log:
Allow movabs for x32.

2011-08-02  H.J. Lu  <hongjiu.lu@intel.com>

    Revert
    PR target/49860
    * config/i386/i386.md (*movdi_internal_rex64): Only allow moving
    integer constants into 64bit registers for TARGET_X32.
    (*movabs<mode>_1): Only allow for TARGET_LP64.
    (*movabs<mode>_2): Likewise.

    * config/i386/predicates.md (x86_64_immediate_operand): Always
    allow the offsetted memory references for TARGET_X32.
    (x86_64_zext_immediate_operand): Likewise.

Modified:
    branches/x32/gcc/ChangeLog.x32
    branches/x32/gcc/config/i386/i386.md
    branches/x32/gcc/config/i386/predicates.md

[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode

[hjl at gcc dot gnu.org]

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

--- Comment #13 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> 2011-08-06 14:05:43 UTC ---
Author: hjl
Date: Sat Aug  6 14:05:39 2011
New Revision: 177509

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177509
Log:
Add testcases for PRs 48084/49504/49860.

2011-08-06  H.J. Lu  <hongjiu.lu@intel.com>

    PR target/48084
    * gcc.target/i386/pr48084-1.c: New.
    * gcc.target/i386/pr48084-2.c: Likewise.
    * gcc.target/i386/pr48084-3.c: Likewise.
    * gcc.target/i386/pr48084-4.c: Likewise.
    * gcc.target/i386/pr48084-5.c: Likewise.

    PR rtl-optimization/49504
    * gcc.target/i386/pr49504.c: New.

    PR target/49860
    * gcc.dg/pr49860.c: New.

Added:
    trunk/gcc/testsuite/gcc.dg/pr49860.c
    trunk/gcc/testsuite/gcc.target/i386/pr48084-1.c
    trunk/gcc/testsuite/gcc.target/i386/pr48084-2.c
    trunk/gcc/testsuite/gcc.target/i386/pr48084-3.c
    trunk/gcc/testsuite/gcc.target/i386/pr48084-4.c
    trunk/gcc/testsuite/gcc.target/i386/pr48084-5.c
    trunk/gcc/testsuite/gcc.target/i386/pr49504.c
Modified:
    trunk/gcc/testsuite/ChangeLog