Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes:
>
> > I'm seeing miscompilation of newlib's memcmp() for my 16-bit ix86 port. The
> > REG_RETVAL and REG_LIBCALL notes seem to play an important part in the
> > failure. From the first subreg dump:
>
> Try this:
>
> Index: gcc/lower-subreg.c
> ===================================================================
> --- gcc/lower-subreg.c (revision 124389)
> +++ gcc/lower-subreg.c (working copy)
> @@ -610,7 +610,7 @@ resolve_reg_notes (rtx insn)
> rtx *pnote, note;
>
> note = find_reg_equal_equiv_note (insn);
> - if (note)
> + if (note || find_reg_note (insn, REG_RETVAL, NULL) != NULL_RTX)
> {
> if (for_each_rtx (&XEXP (note, 0), resolve_subreg_use, NULL))
> {
Of course that isn't going to work. Sorry.
The issue here is that we have a libcall without the REG_EQUAL note.
That is sensible for a REG_NO_CONFLICT block. Normally gcc will only
build REG_NO_CONFLICT blocks for code which lower-subreg can't pick
apart anyhow. Your backend appears to be an exception.
This may be the right patch. I have no good way to test it.
Ian
Index: lower-subreg.c
===================================================================
--- lower-subreg.c (revision 124389)
+++ lower-subreg.c (working copy)
@@ -1128,6 +1128,8 @@ decompose_multiword_subregs (bool update
{
changed = true;
+ remove_retval_note (insn);
+
recog_memoized (insn);
extract_insn (insn);
@@ -1157,6 +1159,8 @@ decompose_multiword_subregs (bool update
i = apply_change_group ();
gcc_assert (i);
+ remove_retval_note (insn);
+
changed = true;
}
}
