[Bug c/110368] New: Incorrect "is used uninitialized" warning message

[Bug c/110368] New: Incorrect "is used uninitialized" warning message

[clugstj at gmail dot com]

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

            Bug ID: 110368
           Summary: Incorrect "is used uninitialized" warning message
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: clugstj at gmail dot com
  Target Milestone: ---

Created attachment 55384
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55384&action=edit
Code that causes warning

The attached code, when compiled with:

>gcc -O2 -Wall -Wextra -c uninit.c

results in the following error messages:

uninit.c: In function 'cksum':
uninit.c:20:13: warning: 'l' is used uninitialized [-Wuninitialized]
   20 |    unsigned l = len;
      |             ^
uninit.c:21:13: warning: 'n' is used uninitialized [-Wuninitialized]
   21 |    unsigned n = protocol;
      |             ^

[Bug c/110368] Incorrect "is used uninitialized" warning message

[clugstj at gmail dot com]

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

--- Comment #1 from Jon Clugston <clugstj at gmail dot com> ---
Created attachment 55385
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55385&action=edit
gcc -v

[Bug c/110368] Incorrect "is used uninitialized" warning message

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The warning is due to the code having undefined behavior in it. The code stores
in a variable as int but reads part of it via short type. That is an aliasing
violation.

[Bug c/110368] Incorrect "is used uninitialized" warning message

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
As explained undefined code.

[Bug c/110368] Incorrect "is used uninitialized" warning message

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The code can fixed using memcpy
Replace:
c   += *data_16++

With:
unsigned tmp;
memcpy(&tmp, data_16, sizeof(tmp));
data_16++;
c += tmp;

[Bug c/110368] Incorrect "is used uninitialized" warning message

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #4)
> The code can fixed using memcpy
> Replace:
> c   += *data_16++
> 
> With:
> unsigned tmp;
> memcpy(&tmp, data_16, sizeof(tmp));
> data_16++;
> c += tmp;

Small typo, the type of tmp should have been `unsigned short`.

[Bug c/110368] Incorrect "is used uninitialized" warning message

[clugstj at gmail dot com]

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

--- Comment #6 from Jon Clugston <clugstj at gmail dot com> ---
So, "undefined behavior" gives the compiler license to output any warning it
wants?

The warning message is utterly wrong and completely misleading.

[Bug c/110368] Incorrect "is used uninitialized" warning message

[sjames at gcc dot gnu.org]

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

--- Comment #7 from Sam James <sjames at gcc dot gnu.org> ---
That said, I suppose we should do better here with -Wstrict-aliasing. No level
detects it.

[Bug c/110368] Incorrect "is used uninitialized" warning message

[xry111 at gcc dot gnu.org]

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

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

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

--- Comment #8 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Sam James from comment #7)
> That said, I suppose we should do better here with -Wstrict-aliasing. No
> level detects it.

I think it's very difficult to make -Wstrict-aliasing really useful.  A
sanitizer at runtime would be much more useful but the develop of such a
sanitizer seems stalled
(https://discourse.llvm.org/t/reviving-typesanitizer-a-sanitizer-to-catch-type-based-aliasing-violations/).

For now we can only compare the output with or without -fno-strict-aliasing. 
And we are already saying "try -fno-strict-aliasing" in the bug report
guidance.