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.