This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Live range splitting in new allocator


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]