This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Live range splitting in new allocator
- To: David Korn <dkorn at pixelpower dot com>
- Subject: Re: Live range splitting in new allocator
- From: Michael Meissner <meissner at cygnus dot com>
- Date: Wed, 31 Jan 2001 14:19:48 -0500
- Cc: gcc at gcc dot gnu dot org
- References: <718D38CAB6E0D011B2C90060970C28A564265A@EXCHANGESERVER>
On Wed, Jan 31, 2001 at 04:59:40PM -0000, David Korn wrote:
>
> >> Ummm, -finitialize-stack[=value] would seem to make more sense than
> >> initialize-all, since you would not be initializing the statics or
> >> globals (or possibly the registers).
> >
> >Right. IIRC, statics and globals are initialized to 0 by the system
> >anyway (unless otherwise initialized in the code).
> >
> >For the registers, I guess the function prologue could set them to
> >the specified value at the same time as the stack...
>
> And if there was a way to initialise the variables with a value that
> in some way could be tracked back to the function (a hash of the function's
> name, for example) you'd be able to spot when uninitialized pointers were
> used and where they came from even if the error didn't occur until a
> completely diffeent part of the test app. was running.
As long as people (both gcc hackers and user) realize that really there are no
out of band values. I recall many years ago, people running into WatCom's
fortran compiler using a special value for unset, and running programs that
wanted to calculate that value as a normal result and the interpreter flagging
it as an undefined memory reference.
Instead of -finitialize-stack, it would probably be more useful to use
-fcheck-memory-usage and Checker, as it would catch more cases.
--
Michael Meissner, Red Hat, Inc. (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: meissner@redhat.com phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482