This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
- From: "hjl.tools at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 27 Jul 2011 12:56:44 +0000
- Subject: [Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode
- Auto-submitted: auto-generated
- References: <bug-49860-4@http.gcc.gnu.org/bugzilla/>
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.