[Bug middle-end/110375] New: -ftrivial-auto-var-init=zero issues with pointers to data members

[Bug middle-end/110375] New: -ftrivial-auto-var-init=zero issues with pointers to data members

[dangelog at gmail dot com]

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.

[Bug middle-end/110375] -ftrivial-auto-var-init=zero issues with pointers to data members

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The code is undefined, the point to initialize it something which might be safe
enough for most cases. Yes in the case of pointer to data members, it is not
the same as null but that is ok, it is still intialized to something.

[Bug middle-end/110375] -ftrivial-auto-var-init=zero issues with pointers to data members

[dangelog at gmail dot com]

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

--- Comment #2 from Giuseppe D'Angelo <dangelog at gmail dot com> ---
(In reply to Andrew Pinski from comment #1)
> The code is undefined,

Sure, although there are C++ proposals to make it well-defined /
implementatiopn-defined (see
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2723r1.html and
https://isocpp.org/files/papers/P2795R1.html).

But that's beside the point, I'm not claiming that the code does not have UB --
although I'm not sure whether, if -ftrivial-auto-var-init is in use, an
optimizer stops considering such reads as UB. At least Clang stops:
https://gcc.godbolt.org/z/bKW5Mccsa



> the point to initialize it something which might be
> safe enough for most cases. Yes in the case of pointer to data members, it
> is not the same as null but that is ok, it is still intialized to something.

What I'm asking is to make it safe for *more* cases, so I don't see what's
wrong with such a feature request. -ftrivial-auto-var-init has several options
precisely because one may want different bit patterns of initialization for
various purposes (safety/ease of debugging/...); right now it's just 

* all 0 (=zero)
* all 0xFE (=pattern)


Something that zero-initializes is missing, and I'm asking to make =zero do so.

--

Anyhow, this is useful information, because P2795R1 claims its proposed
behavior is already implemented by GCC, while it actually isn't. It also isn't
by Clang (twin bug report https://github.com/llvm/llvm-project/issues/63471 ).

[Bug middle-end/110375] -ftrivial-auto-var-init=zero issues with pointers to data members

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Giuseppe D'Angelo from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > The code is undefined,
> 
> Sure, although there are C++ proposals to make it well-defined /
> implementatiopn-defined (see
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2723r1.html and
> https://isocpp.org/files/papers/P2795R1.html).
> 
> But that's beside the point, I'm not claiming that the code does not have UB
> -- although I'm not sure whether, if -ftrivial-auto-var-init is in use, an
> optimizer stops considering such reads as UB. At least Clang stops:
> https://gcc.godbolt.org/z/bKW5Mccsa

But those proposals will be done in the front-end while
-ftrivial-auto-var-init=zero is a generic non-front-end option. The middle-end
will see the right thing and that option will not have an effect really.

Note GCC with that option is not exactly undefined behavior but rather it is
defined to be using that pattern. But what I was saying is rather it is the
pattern 0 rather the 0.

[Bug middle-end/110375] -ftrivial-auto-var-init=zero issues with pointers to data members

[dangelog at gmail dot com]

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

--- Comment #4 from Giuseppe D'Angelo <dangelog at gmail dot com> ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Giuseppe D'Angelo from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > The code is undefined,
> > 
> > Sure, although there are C++ proposals to make it well-defined /
> > implementatiopn-defined (see
> > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2723r1.html and
> > https://isocpp.org/files/papers/P2795R1.html).
> > 
> > But that's beside the point, I'm not claiming that the code does not have UB
> > -- although I'm not sure whether, if -ftrivial-auto-var-init is in use, an
> > optimizer stops considering such reads as UB. At least Clang stops:
> > https://gcc.godbolt.org/z/bKW5Mccsa
> 
> But those proposals will be done in the front-end

That's not P2723R1's claim. Quoting:

"We propose to zero-initialize all objects of automatic storage duration,
making C++ safer by default.

This was implemented as an opt-in compiler flag in 2018 for LLVM [LLVMReview]
and MSVC [WinKernel], and 2021 in for GCC [GCCReview]."


This report (and Clang's) shows that that's misleading.


> while
> -ftrivial-auto-var-init=zero is a generic non-front-end option. The
> middle-end will see the right thing and that option will not have an effect
> really.


Fair enough; then, please, could this report be turned into a feature request
for the C/C++ frontends?

[Bug middle-end/110375] -ftrivial-auto-var-init=zero issues with pointers to data members

[dangelog at gmail dot com]

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

--- Comment #5 from Giuseppe D'Angelo <dangelog at gmail dot com> ---
Done in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404 .