Re: GC changes

[Mike Stump <mrs at windriver dot com>]

> Date: Mon, 15 Jan 2001 12:32:34 +0000 (GMT)
> From: Bernd Schmidt <bernds@redhat.com>

> On Mon, 15 Jan 2001, Jamie Lokier wrote:

> > Mike Stump wrote:
> > > > That is not safe.  You can't predict what kind of address arithmetic
> > > > the compiler will make.  For example, strength reduction could cause
> > > > a pointer to be pointing into the middle of an array, or worse,
> > > > somewhere beyond it (incorporating some constant adjustments).
> > >
> > > We already need a switch to disable GC unfriendly optimizations.

> Which ones would that be?

-mgc-safe, -fgc-safe or something along those lines.  I don't know why
 you ask, unless someone has the patches, picking the name is
a bit  premature.

> And how can we verify that the generated code is indeed GC friendly?

When all the GC applications verify that they work 100% all the time
and they never report any bugs, we can know that the code is
reasonably GC friendly.  When the experts conditionalize all the known
optimizations on this flag, we can be obtain more comfort that it is.

``Given enough eyeballs, all bugs are shallow''
http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/.

> If it can't be verified with a testsuite, such a switch might as
> well not be there, since it won't work in practice.

Sounds kinda defeatist to me.  The software already doesn't work in
practice, why should we bother to work on it?  Answer, because the
level that it works at today is good enough for some, and those that
work on it, only need it to work a little bit better, not perfection,
but just a tad bit better.  This is easy enough to achieve.

Also, there are tons of features in the compiler that don't have
testsuites, that work on a routine basis.  Are you saying that we
should rip out all features that haven't been put through a testsuite
in the past 30 days?