jfb added a comment. > That sounds reasonable to me. So the behavior we're looking for is: > > - If `-ftrivial-auto-init` is off, then we guarantee to zero padding when the > language spec requires it, and otherwise provide no such guarantee. > - If `-ftrivial-auto-init=zeroes` then we guarantee to zero padding within > structs and unions with automatic storage duration, when that padding would > otherwise be left uninitialized. > - If `-ftrivial-auto-init=pattern` then we guarantee to pattern-fill padding > within structs and unions with automatic storage duration, when that padding > would otherwise be left uninitialized (and will provide the zeroes required > by the language rule when that is the required behavior).
That's exactly what I'd like, yes! > [One possible tweak: for the `pattern` case, should we guarantee that the > uninitialized padding will be pattern-filled? It would be simpler if we > guaranteed it to be *either* zero- or pattern-filled; that way we can provide > a conservatively-correct approximation by zero-filling whenever we're unsure.] Not guaranteeing a specific value for "pattern" remains my preferred choice. Where feasible, I'd rather we generate the most-repeated pattern so it's cheaper to synthesize. > And we do not initially provide any guarantees as to what happens to padding > within objects of other storage durations beyond what the language spec > requires. (We might at some point in the future, but that would be behind a > separate flag from `-ftrivial-auto-init`.) I'd be happy with that approach. > Does that address everyone's concerns? Yup! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68115/new/ https://reviews.llvm.org/D68115 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
