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.