[Bug c++/110404] New: Feature request: make -ftrivial-auto-var-init=zero zero-initialize, not zero-fill

[Bug c++/110404] New: Feature request: make -ftrivial-auto-var-init=zero zero-initialize, not zero-fill

[dangelog at gmail dot com]

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.

[Bug c++/110404] Feature request: add a new option which is like -ftrivial-auto-var-init=zero but zero-initialize instead of zero-fill

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
            Summary|Feature request: make       |Feature request: add a new
                   |-ftrivial-auto-var-init=zer |option which is like
                   |o zero-initialize, not      |-ftrivial-auto-var-init=zer
                   |zero-fill                   |o but zero-initialize
                   |                            |instead of zero-fill

[Bug c++/110404] Feature request: add a new option which is like -ftrivial-auto-var-init=zero but zero-initialize instead of zero-fill

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-06-26
                 CC|                            |rguenth at gcc dot gnu.org
             Status|UNCONFIRMED                 |WAITING

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
But your testcase is invoking undefined behavior when inspecting 'ptr'?  That
doesn't change with -ftrivial-auto-var-init=zero, so getting a trap is good
here and you need to fix your code instead.

[Bug c++/110404] Feature request: add a new option which is like -ftrivial-auto-var-init=zero but zero-initialize instead of zero-fill

[dangelog at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404

--- Comment #2 from Giuseppe D'Angelo <dangelog at gmail dot com> ---
(In reply to Richard Biener from comment #1)
> But your testcase is invoking undefined behavior when inspecting 'ptr'? 
> That doesn't change with -ftrivial-auto-var-init=zero, so getting a trap is
> good
> here and you need to fix your code instead.

Hi,

Well, the point of -ftrivial-auto-var-init=zero is to turn that UB in a
specific  behavior, that is, to read 0. From a formal point of view, this is a
perfectly valid expression of UB.

The problem I'm raising above is that I'd like reads of uninitialized pointers
to yield nullptr, which is currently not the case of pointers to data members
on Itanium.

--

Then there's the question regarding whether GCC can "see the UB" and e.g.
optimize the whole thing away, based on reasonings like "this code exhibits UB,
therefore it can never be called, therefore it's dead, therefore I can remove
it".

I don't know if this is actually the case at the moment, but if it is, I'd
consider it a *different* bug report. The whole point of
-ftrivial-auto-var-init=zero is to prevent that sort of UB from manifesting
itself (by zero-filling the storage); to prevent leaking "secrets" (leaks that
imply an uninitialized read anyhow, so UB);  etc.

I am not able at the moment to prove or disprove this using GCC. Clang however
disables such UB-optimizations when using -ftrivial-auto-var-init=zero :

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