This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Storage for uninitialized objects (PR 24626)
- From: Michael Veksler <mveksler at techunix dot technion dot ac dot il>
- To: Paul Schlie <schlie at comcast dot net>
- Cc: Ian Lance Taylor <ian at airs dot com>, John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>, gcc at gcc dot gnu dot org
- Date: Sun, 15 Jan 2006 15:49:53 +0200
- Subject: Re: Storage for uninitialized objects (PR 24626)
Paul,
In theory you could be right:
Quoting Paul Schlie <schlie@comcast.net>:
[...]
> Given that it would appear that the only time the compiler may attempt
> to optimize the allocation/use of an un-initialized variable, is when it
> knows for certain it hasn't been initialized; might it be preferable to
> then assign it a deterministic cheap value such as 0 which it may then
> presume during optimization, given all remaining alternatives would seem
> to have less desirable potential consequences?
[...]
But in practice, it ranges from very difficult to impractical to do
what you want, and hence it could be a real waste of time to handle
the issue the way you want it. I would also like to have some magic
knob that would make my code as deterministic as possible in the
presence of undefined behavior, but I don't think this wish is practical.
Consider the following example:
void inc_array(int array[])
{
for (i=0 ; i < 10000 ; ++i)
{
int a;
if (is_debug_enabled(i))
a= calc_debug_value(array, i);
++array[i];
if (is_debug_verbose_enabled(i)) /* a pure function */
printf("%d\n", a);
}
}
Now, consider the case where the compiler can prove that
is_debug_enabled(i) is always zero. So `a' is never initialized.
Why can't the compiler assume that is_debug_verbose_enabled(i) is
zero as well? By ignoring this optimization opportunity, you might
get a much slower code (esp. in examples such as this).
As someone who spent hours debugging in optimized assembly complex C++
templates due to broken aliasing rules (my bug), I can attest that
bad code with compiler transformations is a very bad combination. But
in this case, you have a very shaky ground to stand on. For uninitialized
objects, GCC generates a reasonable warning that catches most
problems, and valgrind catches the other cases. Making GCC behave
"better" on uninitialized objects will bring a marginal improvement
to life of GCC users, with a non-trivial cost on GCC.
If you really feel that strongly about it, you can try to submit a
patch to C and C++ (cut and paste from g77 help):
-finit-local-zero Initialize local vars and arrays to zero
I would not be surprised if this is a matter of only a few dozens of
lines to implement.
--
Michael