https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404
Bug ID: 110404
Summary: Feature request: make -ftrivial-auto-var-init=zero
zero-initialize, not zero-fill
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hello,
This is the same report as bug 110375, however turned into a wishlist/feature
request for the C++ front-end.
Right now -ftrivial-auto-var-init=zero is a middle-end feature that zero-fills
storage for automatic variables. 0x00 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" (and zero-fill padding bits), including
non-static data members of classes, recursively, before a constructor is
eventually run.
Such value-initialization for scalar types 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.
--
Regarding whether one should change -ftrivial-auto-var-init=zero semantics or
introduce a new command line option, I'd rather change the semantics. The fact
that it's currently a middle-end feature is not interesting at all for the
end-user. In their mind, what they want is zero-initialization, not
zero-filling (aka any sort of pointer is nullptr, any arithmetic is 0, etc;
irregardless of ABI).
For the C front-end, this shouldn't mean any change (unless GCC runs on some C
ABI where pointers or floating pointes aren't all 0-bits?). For the C++
front-end, this means fixing pointers to data members Itanium.
--
References:
* https://github.com/llvm/llvm-project/issues/63471 twin bug report
* https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2723r1.html that
aims to zero-initialize variables with automatic storage, but erronousely say
that GCC and Clang already implement this feature.
