https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375
--- Comment #2 from Giuseppe D'Angelo <dangelog at gmail dot com> --- (In reply to Andrew Pinski from comment #1) > The code is undefined, Sure, although there are C++ proposals to make it well-defined / implementatiopn-defined (see https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2723r1.html and https://isocpp.org/files/papers/P2795R1.html). But that's beside the point, I'm not claiming that the code does not have UB -- although I'm not sure whether, if -ftrivial-auto-var-init is in use, an optimizer stops considering such reads as UB. At least Clang stops: https://gcc.godbolt.org/z/bKW5Mccsa > the point to initialize it something which might be > safe enough for most cases. Yes in the case of pointer to data members, it > is not the same as null but that is ok, it is still intialized to something. What I'm asking is to make it safe for *more* cases, so I don't see what's wrong with such a feature request. -ftrivial-auto-var-init has several options precisely because one may want different bit patterns of initialization for various purposes (safety/ease of debugging/...); right now it's just * all 0 (=zero) * all 0xFE (=pattern) Something that zero-initializes is missing, and I'm asking to make =zero do so. -- Anyhow, this is useful information, because P2795R1 claims its proposed behavior is already implemented by GCC, while it actually isn't. It also isn't by Clang (twin bug report https://github.com/llvm/llvm-project/issues/63471 ).
