[Bug middle-end/106578] New: spurious -Wuse-after-free=2 after conditional free()

[Bug middle-end/106578] New: spurious -Wuse-after-free=2 after conditional free()

[gcc.gnu.org at aydos dot de]

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

            Bug ID: 106578
           Summary: spurious -Wuse-after-free=2 after conditional free()
           Product: gcc
           Version: 12.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc.gnu.org at aydos dot de
  Target Milestone: ---

I am new to GCC's components, so feel free to rename the headers if I
classified the bug wrong.

The following code throws the `use-after-free` error:

```
#include <stdlib.h>

void *buf = NULL;
size_t buf_size = 0;

int main() {
    void *tmp = buf;

    buf = realloc(tmp, 10);

    // Realloc returns a pointer to the new object, or a null pointer if the
    // new object could not be allocated. Free the original pointer
    // to avoid memory leak in latter case.
    if (!buf)
        free(tmp);
}
```
```
$ gcc -Wall -Wuse-after-free=2 main.c
main.c: In function ‘main’:
main.c:15:17: warning: pointer ‘tmp’ may be used after ‘realloc’
[-Wuse-after-free]
   15 |                 free(tmp);
      |                 ^~~~~~~~~
main.c:9:15: note: call to ‘realloc’ here
    9 |         buf = realloc(tmp, 10);
      |               ^~~~~~~~~~~~~~~~
```

A workaround is to `realloc` directly `buf` and use `tmp` for the return value
of `realloc`:

```
#include <stdlib.h>

void *buf = NULL;
size_t buf_size = 0;

int main() {
    void *tmp = buf;

    tmp = realloc(buf, 10);

    if (!tmp)
        free(buf);
}
```

>From what I saw in other bugs this one may also be related to the meta-bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075.

Can someone confirm this case?

[Bug middle-end/106578] spurious -Wuse-after-free=2 after conditional free()

[gcc.gnu.org at aydos dot de]

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

--- Comment #1 from Gökçe Aydos <gcc.gnu.org at aydos dot de> ---
FYI: [`realloc` behavior in the C11
standard](http://port70.net/~nsz/c/c11/n1570.html#7.22.3.5)

[Bug middle-end/106578] spurious -Wuse-after-free=2 after conditional free()

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-08-10
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
The pattern matching of the if (result == NULL) doesn't work reliably without
optimization because it goes through memory:

  <bb 2> :
  tmp_5 = buf;
  _1 = realloc (tmp_5, 10);
  buf = _1;
  buf.0_2 = buf;
  if (buf.0_2 == 0B)
    goto <bb 3>; [INV]
  else
    goto <bb 4>; [INV]

  <bb 3> :
  free (tmp_5);

  <bb 4> :
  _9 = 0;

  <bb 5> :
<L2>:
  return _9;

using 'tmp' instead makes it properly fire.  Could be fixed with extra
compile-time cycles doing virtual VN like we do for early uninit
analysis (note this is the late waccess pass).

[Bug middle-end/106578] spurious -Wuse-after-free=2 after conditional free() when not optimizing

[gcc.gnu.org at aydos dot de]

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

--- Comment #3 from Gökçe Aydos <gcc.gnu.org at aydos dot de> ---
> using 'tmp' instead makes it properly fire.

Dear Richard, maybe I misunderstood what you meant with *fire*. If `tmp` is
used then gcc does not *fire* any warning and works correctly, right?

[Bug middle-end/106578] spurious -Wuse-after-free=2 after conditional free() when not optimizing

[gcc.gnu.org at aydos dot de]

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

--- Comment #4 from Gökçe Aydos <gcc.gnu.org at aydos dot de> ---
Just to clarify my entry:

In my opinion gcc should not fire a warning in my first example. In case
`realloc` was not successful, then `realloc` does not touch its argument. I
should be able to use its argument in this case.