This is the mail archive of the
mailing list for the GCC project.
Re: GC changes
On 15-Jan-2001, Bernd Schmidt <firstname.lastname@example.org> wrote:
> 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?
> And how can we verify that the generated code is indeed GC friendly?
One way is to run lots of programs with the Boehm (et al) conservative
collector. The Java and Mercury front-ends may prove to be good
sources of such test cases, since they both use that collector.
But it would also be possible to obtain test cases from code in other
languages by linking with a version of the Boehm collector compiled
with REDIRECT_MALLOC enabled.
> 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.
In general a test suite can show never prove correctness.
A test suite can only ever show the presence of errors.
The empirical evidence seems to be that the vast majority of the time
it does work in practice, even without the switch. The point of
adding the switch would be to increase the likelihood that
conservative GC continues to work in the future, and to make it clear
that optimizations which are not GC-friendly are bugs if the switch is
Fergus Henderson <email@example.com> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.