-ftrivial-auto-var-init=zero issues with pointers to data members

[dangelog]

I can't find accurate documentation for what -ftrivial-auto-var-init=zero is meant to do; https://clang.llvm.org/docs/ClangCommandLineReference.html simply says

Initialize trivial automatic stack variables. Defaults to ‘uninitialized’. must be ‘uninitialized’, ‘zero’ or ‘pattern’.

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.

[tkoeppe]

What does -ftrivial-auto-var-init=pattern do?

[dangelog]

It seems to fill the variable with repeated 0xAA bytes. On GCC, it's filled with 0xFE.

https://gcc.godbolt.org/z/c7xv9e5P9

[dangelog]

Hi,

It's been pointed out to me that I used some inaccurate wording in the report, so let me try clarify:

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.

To turn this into a more correct statement: I would like for -ftrivial-auto-var-init=zero to fill the storage of automatic variables using the same value that would be there, had the automatic variable been zero-initialized.

• For scalars, this would mean filling integers, enums and floating points with their representation of 0 (which is indeed 0x00 filling for integers, since their representation is mandated. It's also 0x00 for floating points on IEEE754, does Clang/LLVM support some more exoteric FP type?), and pointers with whatever the ABI mandates for their nullptr representation.
• For classes, this means filling the storage of their scalar subobjects as indicated above, and zero-filling padding bits.

Hope this is more accurate.

--

Also: please let me know if you think this should be considered a bugfix for -ftrivial-auto-var-init=zero, or an outright new feature with its own command line switch.
I personally think it should be a bugfix: the behavior is going to be the same for most things, but users are going to get the added benefit that reads of uninitialized pointers always give back nullptr, no matter the kind of pointer / the ABI.

--

Twin GCC feature request: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404

[llvmbot]

@llvm/issue-subscribers-clang-driver