This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: [PATCH] Document arithmetic overflow semantics


I think initializing automatic variables to 0 is the worst you could do as
you would start helping people write erronous code which relies on
uninitialized variables being 0.
If you really want to help people track down problems with uninitialzed
variables, initialize all variables with some "magic" value which is always
the same so that you get predictable behaviour, but a value which is useless
to 99.9% of all programs because it will automatically yield wrong results.


Marcel Cox

"Chris Lattner" <sabre@nondot.org> wrote in message
Pine.LNX.4.44.0302131450560.9271-100000@nondot.org">news:Pine.LNX.4.44.0302131450560.9271-100000@nondot.org...
>
> >> Are you really claiming that a program with an uninitialized variable
> >> must be compiled in such a way that it produces the same result
> >> independent of optimization?
>
> > No one claims this, but it is useful to observe that the problem of
> > uninitialized variables causing different results in unoptimized and
> > optimized code is a severe one in practice that causes a lot of grief,
> > especially in large systems where tracking down the difference can be a
> > lot of work. However, in this case, the cure would be very expensive,
> > and the gain from "optimizing" (which typically comes from putting stuff
> > in registers) is so great as to be worth the pain.
>
> That's not really true... a straight-forward way to "fix" this problem is
> to simply initialize all variables to, for example, zero.  In almost all
> cases, optimization would DCE this initialization anyway, so there is
> really very little cost.  The only major cases I can think of that the
> initialization would not be killed would be something like this:
>
> int X;
>
> if (predicate) {
> ...
>   X = 6;
> }
>
> ...
>
> if (predicate) {
>   = X;
> }
>
> In this case, X is always initialized before being used, but it's unlikely
> an optimizer would know that, and thus it would have to insert an
> initialization for X on the first !predicate path...
>
> Despite the small cost, this could be a real help to some people...
>
> -Chris
>
> -- 
> http://llvm.cs.uiuc.edu/
> http://www.nondot.org/~sabre/Projects/
>
>




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