https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375
Bug ID: 110375 Summary: -ftrivial-auto-var-init=zero issues with pointers to data members Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: dangelog at gmail dot com Target Milestone: --- -ftrivial-auto-var-init=zero is documented to "Initialize automatic variables with zeroes". I assume that means to memset(0) their storage. 0 is a bit pattern that works _almost_ universally to set a "safe" default. However, pointers to data members are a problem: on Itanium, a null pointer to data member is represented by -1u, and not 0. https://itanium-cxx-abi.github.io/cxx-abi/abi.html#data-member-pointers This means that this snippet hits the assert under -ftrivial-auto-var-init=zero: #include <cassert> struct S {}; int main() { int S::*ptr; assert(ptr == nullptr); } https://gcc.godbolt.org/z/7sb6GcbPE IMHO it would be more useful to have -ftrivial-auto-var-init=zero to mean "to _value-initialize_ automatic variables", including non-static data members of classes, recursively, before a constructor is eventually run. Such value-initialization for scalar taypes resolves into zero-initialization (and *not* zero-filling), as per https://eel.is/c++draft/dcl.init#general-9.3 , so the name "=zero" is still somehow appropriate. The difference is that zero-initialization will correctly sets *all* pointers types to null.