https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404
--- Comment #2 from Giuseppe D'Angelo <dangelog at gmail dot com> --- (In reply to Richard Biener from comment #1) > But your testcase is invoking undefined behavior when inspecting 'ptr'? > That doesn't change with -ftrivial-auto-var-init=zero, so getting a trap is > good > here and you need to fix your code instead. Hi, Well, the point of -ftrivial-auto-var-init=zero is to turn that UB in a specific behavior, that is, to read 0. From a formal point of view, this is a perfectly valid expression of UB. The problem I'm raising above is that I'd like reads of uninitialized pointers to yield nullptr, which is currently not the case of pointers to data members on Itanium. -- Then there's the question regarding whether GCC can "see the UB" and e.g. optimize the whole thing away, based on reasonings like "this code exhibits UB, therefore it can never be called, therefore it's dead, therefore I can remove it". I don't know if this is actually the case at the moment, but if it is, I'd consider it a *different* bug report. The whole point of -ftrivial-auto-var-init=zero is to prevent that sort of UB from manifesting itself (by zero-filling the storage); to prevent leaking "secrets" (leaks that imply an uninitialized read anyhow, so UB); etc. I am not able at the moment to prove or disprove this using GCC. Clang however disables such UB-optimizations when using -ftrivial-auto-var-init=zero : https://gcc.godbolt.org/z/qhMxM11jE
