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]
Other format: [Raw text]

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


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