Possible obscure storage management bug in type.c

[Julian Seward (Intl Vendor)]

I refer to scc.c.  This file defines

static Cell daSccs = NIL

and uses it as a temporary in which to accumulate the output
list of strongly connected components during the computation.

In order for the world to continue to revolve smoothly,
any file which includes scc.c needs to ensure that daSccs
is marked when everybody(MARK) is issued.  Note that different
C source files will have different daSccs since it is declared
static, so a single global mark(daSccs) will not work.

First observation: type.c uses the scc.c mechanism but doesn't
have a mark(daSccs) in its MARK section.  I think it should.

Second observation: static.c includes scc.c twice.  It _does_
have a mark(daSccs) in its MARK section.  However, since daSccs
is declared static, it's unclear which of the two daSccs the
mark() call refers to.  Certainly it can't refer to both, unless
gcc/the linker magically merges them into a single variable.

It seems to me that the second observation means we need to
declare daSccs thusly

static Cell DASCCS = NIL

and have the includer define DASCCS on a per-inclusion basis, 
as SCC SETDEPENDS LOWLINK, etc, are at the moment, so all the
instances of it have distinct names.

Finally, since we are now asking client code to mark their DASCCS
at every GC, it would seem safe to NIL the variable out at the
point where SCC returns, thusly:

#ifdef SCC
static List local SCC(bs)               /* sort list with added dependency
*/
List bs; {                              /* info into SCCs
*/
    List tmp = NIL;
    clearStack();
    DASCCS = NIL;                       /* clear current list of SCCs
*/

    for (daCount=1; nonNull(bs); bs=tl(bs))      /* visit each binding
*/
        if (!visited(hd(bs)))
            LOWLINK(hd(bs));
    tmp = rev(DASCCS);
    DASCCS = NIL;
    return tmp;                         /* reverse to obtain correct order
*/
}
#endif

so as to avoid gratuitious hanging-on-to-stuff later on.

As background, I spent this morning looking for obscure storage
management bugs in the simplifier for STG hugs, and it turned out
to be the abovementioned problems.  I use the scc machinery in the
simplifier to scc-ify STG let bindings.

J