From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18639 invoked by alias); 27 Jul 2011 12:50:27 -0000 Received: (qmail 18629 invoked by uid 22791); 27 Jul 2011 12:50:27 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_ZJ X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 27 Jul 2011 12:50:13 +0000 From: "ubizjak at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/49860] [x32] Error: cannot represent relocation type BFD_RELOC_64 in x32 mode X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ubizjak at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Wed, 27 Jul 2011 12:50:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg02339.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49860 Uros Bizjak changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rth at gcc dot gnu.org --- Comment #3 from Uros Bizjak 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.