[Bug middle-end/70069] New: Uninitialized value default to zero, plus warning

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70069

            Bug ID: 70069
           Summary: Uninitialized value default to zero, plus warning
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rth at gcc dot gnu.org
  Target Milestone: ---

Quoting Ingo Monlar, via a LKML discussion:

=====
It could be combined with the following 'safe' runtime behavior: when built
with 
-Ow then all uninitialized values are initialized to 0. This should be
relatively 
easy to implement, as it does not depend on any optimization. After all is said 
and done, there's two cases:

  - a 0-initialization gets optimized out by an optimization pass. This is the 
    common case.

  - a variable gets initialized to 0 unnecessarily. (If a warning got ignored.)

having some runtime overhead for zero initialization is much preferred for many 
projects.

The warning could even be generated at this late stage: i.e. the warning would 
simply warn about remaining 0-initializations that previous passes were unable
to 
eliminate.

This way no undeterministic, random, uninitialized (and worst-case: attacker 
controlled) values can ever enter the program flow (from the stack) - in the
worst 
case (where a warning was ignored) a 0 value is set implicitly - which is still 
deterministic behavior.
======

I imagine a marked value of some sort (e.g. a flag on existing *_CST, or
maybe a new UNINIT_CST) with such an initialization being applied to all
auto variables that aren't already initialized at declaration.  Optimize
as usual, but don't discard the marked value at PHIs.  Warn if any persist
during expansion.

All controlled by -fnew-flag, so that it's opt-in.