> From: Michael Veksler <[EMAIL PROTECTED]>
> In theory you could be right:
> ...
> 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).
- "subjectively", the only plausible alternatives to would seem to be:
- remove unreachable code; making no assumptions otherwise, or:
- presume otherwise un-initialized variables actually are by default.
(as you've suggested as a potential option)
- presume otherwise un-initialized variables and all code which they
are known to potentially indeterminately effect the controllability
and/or observably of are correspondingly removed from compilation;
leaving only that behavior which is portably deterministic. (rather
than introducing potentially a different non-deterministic behavior;
thereby the cited code would then pedantically compile to nothing)
> 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
- Thank you, I'll give it a try; although may attempt to name it:
-force-deterministic-semantics
presuming its longer term intent would be to warrant that some defined
default deterministic semantic is uniformly assumed for all otherwise
indeterminate behaviors throughout all levels of optimization; thereby
guaranteeing that a given program will behave logically the same
regardless of the level of optimizations applied to it.
> I would not be surprised if this is a matter of only a few dozens of
> lines to implement.
>
> --
> Michael
