This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/14580] [3.5 Regression] symbol emitted instead of a non_lazy_symbol
- From: "roger at eyesopen dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 16 Mar 2004 17:48:24 -0000
- Subject: [Bug target/14580] [3.5 Regression] symbol emitted instead of a non_lazy_symbol
- References: <20040315144015.14580.pinskia@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From roger at eyesopen dot com 2004-03-16 17:48 -------
Well, it looks like combine is doing "the right thing" as far as the RTL-level
transformation is concerned. It's turning
(set (reg119) (...)) (REG_EQUAL symbol_ref (!t__unmap)))
(set (reg3) (call (mem (reg119))))
into
(set (reg3) (call (mem (symbol_ref (!t__unmap)))))
i.e. it's optimized an indirect jump into a direct jump. I suspect that
the problem with the rs6000.md backend may be that the constraints for the
*call_value_nonlocal_sysv pattern shouldn't be accepting this replacement,
recognizing "mem (symbol_ref (!t__unmap))" as a invalid operand on darwin.
I think rs6000's use of REG_EQUAL notes is reasonable in this case, as they
can be used in other optimizations. So I believe that the correct fix is to
inform the backend that library functions must be called indirectly via their
thunks. I'm also surprised that this hasn't bitten folks in CSE and/or GCSE
before now.
Of course, I'm assuming that the RTL is accurately describing the intended
semantics here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14580