This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]