[Bug analyzer/114285] New: Use of uninitialized value when copying a struct field by field

[Bug analyzer/114285] New: Use of uninitialized value when copying a struct field by field

[bouanto at zoho dot com]

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

            Bug ID: 114285
           Summary: Use of uninitialized value when copying a struct field
                    by field
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: analyzer
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: bouanto at zoho dot com
  Target Milestone: ---

Created attachment 57655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57655&action=edit
Reproducer for the bug

Hi.
Not sure if it's the same case as the other issues related to
-Wanalyzer-use-of-uninitialized-value and I wanted to discuss this anyway.

In rustc_codegen_gcc, I can get "use of uninitialized value" when using the
Option type, which contains a value and whether there's a value or not.

I tried to reproduce in C and I attached the reproducer.

Not sure what we should do here. Copying the whole struct doesn't trigger any
warning (should it?) and using memcpy doesn't fix the warning.

Rust will sometimes copy uninitialized memory and I'd like to avoid disabling
this specific warning.
Should there be a dinstinction between copying uninitialized memory and using
it?
What are your thoughts on this?

Thanks.

[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Given GCC considers memory to be initialized when you write to it and
copying from A to B involves a write to B the uninit info would be lost if
A is uninitialized.  So IMO it's reasonable to diagnose a copy from
uninitialized, at least unless you can fully analyze all possible uses
of B (which, when B is memory is unlikely).

Note that's not the analyzer-specific opinion but viewed from the
-Wuninitialized implementation point of view.

[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Antoni from comment #0)
> Created attachment 57655 [details]
> Reproducer for the bug

[...]

> I tried to reproduce in C and I attached the reproducer.

Trunk with -fanalyzer: https://godbolt.org/z/847M165zf

[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>Rust will sometimes copy uninitialized memory and I'd like to avoid disabling this specific warning.


Note in C, there are specific rules about copying unitialized memory. Most is
it is undefined. It is kinda of odd a "security" language like Rust allows
copying unitialized memory at all since a copy should be considered an use ...

[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field

[bouanto at zoho dot com]

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

--- Comment #4 from Antoni <bouanto at zoho dot com> ---
(In reply to Andrew Pinski from comment #3)
> >Rust will sometimes copy uninitialized memory and I'd like to avoid disabling this specific warning.
> 
> 
> Note in C, there are specific rules about copying unitialized memory. Most
> is it is undefined. It is kinda of odd a "security" language like Rust
> allows copying unitialized memory at all since a copy should be considered
> an use ...

A load in LLVM returns undef, so it is not UB. The problem is in
rustc_codegen_gcc itself.

[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field

[bouanto at zoho dot com]

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

--- Comment #5 from Antoni <bouanto at zoho dot com> ---
(In reply to Andrew Pinski from comment #3)
> >Rust will sometimes copy uninitialized memory and I'd like to avoid disabling this specific warning.
> 
> 
> Note in C, there are specific rules about copying unitialized memory. Most
> is it is undefined. It is kinda of odd a "security" language like Rust
> allows copying unitialized memory at all since a copy should be considered
> an use ...

So, if it is UB in C, it makes sense that the analyzer stays that way.
However, I would need another solution to copy undefined memory using a
different GIMPLE construct or something.

[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Antoni from comment #4)
> A load in LLVM returns undef, so it is not UB. The problem is in
> rustc_codegen_gcc itself.

Right, GCC gimple semantics are different from LLVM semantics. GCC gimple
semantics are in my opinion the better semantics really. How to handle things
like Rust semantics with the GCC gimple semantics is an open question.
Basically if I understand correctly Rust semantics depend on LLVM semantics
which seems like wrong approach for a security language. undef vs UB is a small
semantic difference that makes it hard to program rust really :).

[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, if all you want is just to avoid the -Wuninitialized warnings for Rust
copies from uninitialized, just wrap the memcpy into some noipa wrapper, then
the compiler won't know whether the data isn't initialized in there etc.
Or set no warning flag on the unitialized var (but that will turn off that
warning on all uses).

[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field

[bouanto at zoho dot com]

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

--- Comment #8 from Antoni <bouanto at zoho dot com> ---
Created attachment 57726
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57726&action=edit
Reproducer using union

I tried switching to a union and I still get the same error.

A union is used by std::optional, so I would assume that this should work.
Or is copying uninitialized memory via a union also UB?

[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #9 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Antoni from comment #8)
> Created attachment 57726 [details]
> Reproducer using union
> 
> I tried switching to a union and I still get the same error.
> 
> A union is used by std::optional, so I would assume that this should work.
> Or is copying uninitialized memory via a union also UB?

Yes.

std::optional copy constructor is not a default copy constructor.  It does not
copy if the input is nullopt.