Re: Commit policy wrt. to-be-obsolete targets

[Ian Dall <ian at beware dot dropbear dot id dot au>]

Gerald Pfeifer writes:
 > On Thu, 30 May 2002, Zack Weinberg wrote:
 > >> I'm trying to help a friend (and PC532 owner :-) rescue the ns32k
 > >> target from being tossed into the bit bucket. [...]
 > > I'd be inclined to say that anyone who wants it can have the
 > > maintainership, and take the obsoletion off the list [...]
 > 
 > ...provided that s/he actually shows signs of activity. ;-)
 > 
 > That is, just assuming maintainership to rescue a port, but not actually
 > doing anything about that port is not sufficient. Personally, I'm leaning
 > towards handing over maintainership after a first set of patches to the
 > port and documentation (gcc/doc/install.texi) has been submitted.

I am willing to maintain this port. I was the last person to
contribute significant input to it, I do still run a pc532 and am in
the process of trying to get gcc mainline working.

The remaining problem I have is that I get an abort in find_reloads(). This is
in:

    #ifdef HAVE_cc0
      /* If we made any reloads for addresses, see if they violate a
	 "no input reloads" requirement for this insn.  But loads that we
	 do after the insn (such as for output addresses) are fine.  */
      if (no_input_reloads)
	for (i = 0; i < n_reloads; i++)
	  if (rld[i].in != 0
	      && rld[i].when_needed != RELOAD_FOR_OUTADDR_ADDRESS
	      && rld[i].when_needed != RELOAD_FOR_OUTPUT_ADDRESS)
	    abort ();
    #endif

This is on a "seq" insn.

    (set (mem/s:SI (plus:SI (reg/v/f:SI 38)
		    (const_int 32 [0x20])))
	    (eq:SI (cc0)
		(const_int 0 [0x0])))

There seems to be a problem in the generic code in so far as it should
be possible to allocate and use a memory slot (frame pointer relative)
in this situation. This problem arose soon after I contributed the
last lot of ns32k changes. Since it seemed to be a problem in generic
code and I couldn't see how to fix it, I sort of gave up hoping that
it would be fixed in due course by someone else.

HOWEVER, the ns32k does not change condition codes for "move"
instructions, so this test should not be needed. As far as I can see,
NOTICE_UPDATE_CC is not considered here.

I have concluded that the right solution, for the ns32k at least, is
it redo the machine description to not use cc0, but instead use a
special register explicitly updated, used or clobbered by the relevant
instructions.  I don't think this change is hard, but I don't think it
is trivial either. I'd appreciate pointers as to whether this is on
the right track before I dive in.

Ian