* [Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
2011-07-27 4:29 [Bug target/49860] New: [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode hjl.tools at gmail dot com
@ 2011-07-27 8:09 ` ubizjak at gmail dot com
2011-07-27 12:39 ` hjl.tools at gmail dot com
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ubizjak at gmail dot com @ 2011-07-27 8:09 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
2011-07-27 4:29 [Bug target/49860] New: [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode hjl.tools at gmail dot com
2011-07-27 8:09 ` [Bug target/49860] " ubizjak at gmail dot com
@ 2011-07-27 12:39 ` hjl.tools at gmail dot com
2011-07-27 12:50 ` ubizjak at gmail dot com
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: hjl.tools at gmail dot com @ 2011-07-27 12:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
2011-07-27 4:29 [Bug target/49860] New: [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode hjl.tools at gmail dot com
2011-07-27 8:09 ` [Bug target/49860] " ubizjak at gmail dot com
2011-07-27 12:39 ` hjl.tools at gmail dot com
@ 2011-07-27 12:50 ` ubizjak at gmail dot com
2011-07-27 12:56 ` hjl.tools at gmail dot com
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ubizjak at gmail dot com @ 2011-07-27 12:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
2011-07-27 4:29 [Bug target/49860] New: [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode hjl.tools at gmail dot com
` (2 preceding siblings ...)
2011-07-27 12:50 ` ubizjak at gmail dot com
@ 2011-07-27 12:56 ` hjl.tools at gmail dot com
2011-07-27 15:11 ` ubizjak at gmail dot com
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: hjl.tools at gmail dot com @ 2011-07-27 12:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
2011-07-27 4:29 [Bug target/49860] New: [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode hjl.tools at gmail dot com
` (3 preceding siblings ...)
2011-07-27 12:56 ` hjl.tools at gmail dot com
@ 2011-07-27 15:11 ` ubizjak at gmail dot com
2011-07-27 15:43 ` hjl.tools at gmail dot com
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ubizjak at gmail dot com @ 2011-07-27 15:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
2011-07-27 4:29 [Bug target/49860] New: [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode hjl.tools at gmail dot com
` (4 preceding siblings ...)
2011-07-27 15:11 ` ubizjak at gmail dot com
@ 2011-07-27 15:43 ` hjl.tools at gmail dot com
2011-07-27 16:05 ` ubizjak at gmail dot com
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: hjl.tools at gmail dot com @ 2011-07-27 15:43 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
2011-07-27 4:29 [Bug target/49860] New: [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode hjl.tools at gmail dot com
` (5 preceding siblings ...)
2011-07-27 15:43 ` hjl.tools at gmail dot com
@ 2011-07-27 16:05 ` ubizjak at gmail dot com
2011-07-27 16:15 ` hjl.tools at gmail dot com
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ubizjak at gmail dot com @ 2011-07-27 16:05 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
2011-07-27 4:29 [Bug target/49860] New: [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode hjl.tools at gmail dot com
` (6 preceding siblings ...)
2011-07-27 16:05 ` ubizjak at gmail dot com
@ 2011-07-27 16:15 ` hjl.tools at gmail dot com
2011-07-27 16:17 ` hjl.tools at gmail dot com
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: hjl.tools at gmail dot com @ 2011-07-27 16:15 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
2011-07-27 4:29 [Bug target/49860] New: [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode hjl.tools at gmail dot com
` (7 preceding siblings ...)
2011-07-27 16:15 ` hjl.tools at gmail dot com
@ 2011-07-27 16:17 ` hjl.tools at gmail dot com
2011-07-29 15:57 ` hjl at gcc dot gnu.org
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: hjl.tools at gmail dot com @ 2011-07-27 16:17 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
2011-07-27 4:29 [Bug target/49860] New: [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode hjl.tools at gmail dot com
` (8 preceding siblings ...)
2011-07-27 16:17 ` hjl.tools at gmail dot com
@ 2011-07-29 15:57 ` hjl at gcc dot gnu.org
2011-08-02 6:37 ` ubizjak at gmail dot com
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: hjl at gcc dot gnu.org @ 2011-07-29 15:57 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
2011-07-27 4:29 [Bug target/49860] New: [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode hjl.tools at gmail dot com
` (9 preceding siblings ...)
2011-07-29 15:57 ` hjl at gcc dot gnu.org
@ 2011-08-02 6:37 ` ubizjak at gmail dot com
2011-08-02 14:09 ` hjl at gcc dot gnu.org
2011-08-06 14:07 ` hjl at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: ubizjak at gmail dot com @ 2011-08-02 6:37 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
2011-07-27 4:29 [Bug target/49860] New: [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode hjl.tools at gmail dot com
` (10 preceding siblings ...)
2011-08-02 6:37 ` ubizjak at gmail dot com
@ 2011-08-02 14:09 ` hjl at gcc dot gnu.org
2011-08-06 14:07 ` hjl at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: hjl at gcc dot gnu.org @ 2011-08-02 14:09 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
2011-07-27 4:29 [Bug target/49860] New: [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode hjl.tools at gmail dot com
` (11 preceding siblings ...)
2011-08-02 14:09 ` hjl at gcc dot gnu.org
@ 2011-08-06 14:07 ` hjl at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: hjl at gcc dot gnu.org @ 2011-08-06 14:07 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread