This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libjava build failure sol2.6 asm problem?
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Andreas Tobler <toa at pop dot agri dot ch>, Phil Edwards <pedwards at disaster dot jaj dot com>, gcc at gcc dot gnu dot org
- Date: Wed, 19 Dec 2001 14:46:29 -0500 (EST)
- Subject: Re: libjava build failure sol2.6 asm problem?
On 19 Dec 2001, Alexandre Oliva wrote:
> It's probably not the same problem as the one mentioned in the
> URL above. I tried a build a while ago using GNU as and ran into the
> same problem. It turned out that the label referenced in the
> expression was indeed not present in the assembly code produced by
> GCC. It had been optimized away. We do have a bug, indeed, but I
> didn't have time to track it down.
Exactly. We have a LABEL_REF pointing to that CODE_LABEL, but the label
gets deleted anyway. This only happens with -fPIC and -On where n > 0.
I looked at it a little... it can be "fixed" with the one line below, but
I have no idea where the real problem lies (my knowledge of the
backend and .md files is extremely limited). For that matter, the
expletive comment isn't mine... I'd be curious to know what that's about.
If somebody can give me some guidance here, I'm willing to test and
submit a proper patch.
2001-12-19 Jeff Sturm <jsturm@one-point.com>
* sparc.md: Preserve the CODE_LABEL operand of a pic_label_ref.
--- sparc-orig.md Wed Dec 19 14:31:57 2001
+++ sparc.md Wed Dec 19 01:08:22 2001
@@ -2226,6 +2226,7 @@
if (GET_CODE (operands[1]) == LABEL_REF)
{
/* shit */
+ LABEL_PRESERVE_P (XEXP (operands[1], 0)) = 1;
emit_insn (gen_movsi_pic_label_ref (operands[0], operands[1]));
DONE;
}