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/64226] [5.0 Regression] Secondary reload incorrect TOC address


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.


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