[Bug analyzer/106204] New: False positive from -Wanalyzer-use-of-uninitialized-value with -ftrivial-auto-var-init=zero

[Bug analyzer/106204] New: False positive from -Wanalyzer-use-of-uninitialized-value with -ftrivial-auto-var-init=zero

[dmalcolm at gcc dot gnu.org]

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

            Bug ID: 106204
           Summary: False positive from
                    -Wanalyzer-use-of-uninitialized-value with
                    -ftrivial-auto-var-init=zero
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: analyzer
          Assignee: dmalcolm at gcc dot gnu.org
          Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

I'm seeing a lot of false positives from -Wanalyzer-use-of-uninitialized-value
when building the upstream Linux kernel.

Seems to be a bad interaction with -ftrivial-auto-var-init=zero; minimal
reproducer:

$ cat ../../src/hooks.c
int foo(unsigned *len);
int test()
{
 unsigned len;
 int rc;

 rc = foo(&len);
 if (!rc)
  rc = len;
 return rc;
}

$ ./xgcc -B. ../../src/hooks.c -ftrivial-auto-var-init=zero -fanalyzer -S 
../../src/hooks.c: In function ‘test’:
../../src/hooks.c:4:11: warning: use of uninitialized value ‘<unknown>’
[CWE-457] [-Wanalyzer-use-of-uninitialized-value]
    4 |  unsigned len;
      |           ^~~
  ‘test’: event 1
    |
    |    4 |  unsigned len;
    |      |           ^~~
    |      |           |
    |      |           (1) use of uninitialized value ‘<unknown>’ here
    |

where the uninit is being reported on the assignment to "len = _1;" here:

  _1 = .DEFERRED_INIT (4, 2, &"len"[0]);
  len = _1;

[Bug analyzer/106204] False positive from -Wanalyzer-use-of-uninitialized-value with -ftrivial-auto-var-init=zero

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-07-05
     Ever confirmed|0                           |1

--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Affects trunk and GCC 12 branch.

https://godbolt.org/z/P1x4fMr1E

[Bug analyzer/106204] False positive from -Wanalyzer-use-of-uninitialized-value with -ftrivial-auto-var-init=zero

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
I'm testing a fix.

[Bug analyzer/106204] False positive from -Wanalyzer-use-of-uninitialized-value with -ftrivial-auto-var-init=zero

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by David Malcolm <dmalcolm@gcc.gnu.org>:

https://gcc.gnu.org/g:b33dd7874523af5c244fff3c45be1358815691e4

commit r13-1517-gb33dd7874523af5c244fff3c45be1358815691e4
Author: David Malcolm <dmalcolm@redhat.com>
Date:   Wed Jul 6 07:27:45 2022 -0400

    analyzer: fix uninit false positive with -ftrivial-auto-var-init=
[PR106204]

    -fanalyzer handles -ftrivial-auto-var-init= by special-casing
    IFN_DEFERRED_INIT to be a no-op, so that e.g.:

      len_2 = .DEFERRED_INIT (4, 2, &"len"[0]);

    is treated as a no-op, so that len_2 is still uninitialized after the
    stmt.

    PR analyzer/106204 reports that -fanalyzer gives false positives from
    -Wanalyzer-use-of-uninitialized-value on locals that have their address
    taken, due to e.g.:

      _1 = .DEFERRED_INIT (4, 2, &"len"[0]);
      len = _1;

    where -fanalyzer leaves _1 uninitialized, and then complains about
    the assignment to "len".

    Fixed thusly by suppressing the warning when assigning from such SSA
    names.

    gcc/analyzer/ChangeLog:
            PR analyzer/106204
            * region-model.cc (within_short_circuited_stmt_p): Move extraction
            of assign_stmt to caller.
            (due_to_ifn_deferred_init_p): New.
            (region_model::check_for_poison): Move extraction of assign_stmt
            from within_short_circuited_stmt_p to here.  Share logic with
            call to due_to_ifn_deferred_init_p.

    gcc/testsuite/ChangeLog:
            PR analyzer/106204
            * gcc.dg/analyzer/torture/uninit-pr106204.c: New test.
            * gcc.dg/analyzer/uninit-pr106204.c: New test.

    Signed-off-by: David Malcolm <dmalcolm@redhat.com>

[Bug analyzer/106204] False positive from -Wanalyzer-use-of-uninitialized-value with -ftrivial-auto-var-init=zero

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Should be fixed on trunk (for gcc 13) by the above commit.

Keeping open to backport to gcc 12.

[Bug analyzer/106204] False positive from -Wanalyzer-use-of-uninitialized-value with -ftrivial-auto-var-init=zero

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by David Malcolm
<dmalcolm@gcc.gnu.org>:

https://gcc.gnu.org/g:09cb9c88ef8e2c0c89ada9cde2caf1a960db7a77

commit r12-8637-g09cb9c88ef8e2c0c89ada9cde2caf1a960db7a77
Author: David Malcolm <dmalcolm@redhat.com>
Date:   Wed Jul 27 17:38:55 2022 -0400

    analyzer: fix uninit false positive with -ftrivial-auto-var-init=
[PR106204]

    (cherry picked from r13-1517-gb33dd7874523af)

    -fanalyzer handles -ftrivial-auto-var-init= by special-casing
    IFN_DEFERRED_INIT to be a no-op, so that e.g.:

      len_2 = .DEFERRED_INIT (4, 2, &"len"[0]);

    is treated as a no-op, so that len_2 is still uninitialized after the
    stmt.

    PR analyzer/106204 reports that -fanalyzer gives false positives from
    -Wanalyzer-use-of-uninitialized-value on locals that have their address
    taken, due to e.g.:

      _1 = .DEFERRED_INIT (4, 2, &"len"[0]);
      len = _1;

    where -fanalyzer leaves _1 uninitialized, and then complains about
    the assignment to "len".

    Fixed thusly by suppressing the warning when assigning from such SSA
    names.

    gcc/analyzer/ChangeLog:
            PR analyzer/106204
            * region-model.cc (within_short_circuited_stmt_p): Move extraction
            of assign_stmt to caller.
            (due_to_ifn_deferred_init_p): New.
            (region_model::check_for_poison): Move extraction of assign_stmt
            from within_short_circuited_stmt_p to here.  Share logic with
            call to due_to_ifn_deferred_init_p.

    gcc/testsuite/ChangeLog:
            PR analyzer/106204
            * gcc.dg/analyzer/torture/uninit-pr106204.c: New test.
            * gcc.dg/analyzer/uninit-pr106204.c: New test.

    Signed-off-by: David Malcolm <dmalcolm@redhat.com>

[Bug analyzer/106204] False positive from -Wanalyzer-use-of-uninitialized-value with -ftrivial-auto-var-init=zero

[dmalcolm at gcc dot gnu.org]

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

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #6 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Backported to gcc 12, so marking as resolved.