This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/64226] [5.0 Regression] Secondary reload incorrect TOC address
- From: "dje at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 08 Dec 2014 16:16:57 +0000
- Subject: [Bug target/64226] [5.0 Regression] Secondary reload incorrect TOC address
- Auto-submitted: auto-generated
- References: <bug-64226-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64226
--- Comment #2 from David Edelsohn <dje at gcc dot gnu.org> ---
Uli mentioned in private email:
"I think the piece of code quoted above from rs6000_secondary_reload_inner
is wrong; it should not call create_TOC_reference unconditionally.
"Other places that use TOC-relative addressing first verify whether the
symbol actually supports that, using use_toc_relative_ref. So this
check should probably be done here too. If a symbol cannot be accessed
via TOC-relative addressing, we should call rs6000_emit_move, which
should do the right thing (forcing the address into the TOC)."
And the following patch to remove the special call to create_TOC_reference
seems to fix the problem.
Index: rs6000.c
===================================================================
--- rs6000.c (revision 218484)
+++ rs6000.c (working copy)
@@ -17379,12 +17379,7 @@
case SYMBOL_REF:
case CONST:
case LABEL_REF:
- if (TARGET_TOC)
- emit_insn (gen_rtx_SET (VOIDmode, scratch,
- create_TOC_reference (addr, scratch)));
- else
- rs6000_emit_move (scratch, addr, Pmode);
-
+ rs6000_emit_move (scratch, addr, Pmode);
new_addr = scratch;
break;
I am testing bootstrap.