Bug 59908 - Incorrect uninit warning with -fsanitize=address caused by LIM
Summary: Incorrect uninit warning with -fsanitize=address caused by LIM
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.9.0
: P3 normal
Target Milestone: 4.9.2
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
: 60649 (view as bug list)
Depends on:
Blocks: Wuninitialized
  Show dependency treegraph
 
Reported: 2014-01-22 17:14 UTC by Jakub Jelinek
Modified: 2021-08-24 21:08 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.9.2
Known to fail: 4.9.1
Last reconfirmed: 2014-01-22 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Jelinek 2014-01-22 17:14:23 UTC
struct S
{
  int s;
  struct S *p;
};
extern void bar (void) __attribute__ ((__noreturn__));
extern void baz (struct S **);

void
foo (struct S *x, long c)
{
  int s;
  struct S *y;
  if (c)
    bar ();
lab:
  s = x->s;
  y = x;
  switch (s)
    {
    case 0:
      x = x->p;
      goto lab;
    case 1:
      baz (&y);
    }
}

when compiled with -O2 -Wall -fsanitize=address incorrectly warns about maybe uninitialized y, with just -O2 -Wall it doesn't (both 4.8 and trunk).

I couldn't find anything wrong in the -fdump-tree-asan1-all dump though, seems like the problematic uninitialized load is inserted by lim pass, a single store into y in the loop is replaced by load from uninitialized var before the loop and 4 different stores after the loop (2 before the __asan_report* noreturn calls, one before call to baz and one before exit.
Comment 1 Marek Polacek 2014-01-22 17:19:27 UTC
Confirmed.
Comment 2 Richard Biener 2014-01-29 13:37:27 UTC
There is a very old duplicate somewhere.  Happens with store-motion for a simple

void foo (int n)
{
  int x, i;
  for (i = 0; i < n; ++i)
    x = i;
  bar (&x);
}

IIRC.  Of course requires us to re-write x into SSA form later, so some more
"clever" testcase is required.  LIM does:

  <bb 2>:
  if (n_4(D) > 0)
    goto <bb 3>;
  else
    goto <bb 9>;

  <bb 3>:
  x_lsm.3_5 = x;
^^^^
load of uninitialized x


  <bb 4>:
  # i_11 = PHI <i_6(5), 0(3)>
  x_lsm.3_1 = i_11;
  i_6 = i_11 + 1;
  if (n_4(D) > i_6)
    goto <bb 5>;
  else
    goto <bb 10>;

  <bb 10>:
  # x_lsm.3_9 = PHI <x_lsm.3_1(4)>
  x = x_lsm.3_9;
  goto <bb 7>;

now go find the duplicate ;)
Comment 3 Jakub Jelinek 2014-03-26 10:09:15 UTC
*** Bug 60649 has been marked as a duplicate of this bug. ***
Comment 4 Richard Biener 2014-03-26 13:16:56 UTC
PR39612?
Comment 5 Jakub Jelinek 2014-04-22 11:36:52 UTC
GCC 4.9.0 has been released
Comment 6 Jakub Jelinek 2014-07-16 13:30:12 UTC
GCC 4.9.1 has been released.
Comment 7 Jakub Jelinek 2014-10-30 10:40:15 UTC
GCC 4.9.2 has been released.
Comment 8 Jakub Jelinek 2015-06-26 19:53:05 UTC
GCC 4.9.3 has been released.
Comment 9 Andrew Pinski 2021-08-08 04:45:33 UTC
Fixed for GCC 5 with r5-2621 and 4.9.2 with g:5456720833910e .

Basically The inlining of the ASAN_CHECK later on fixes the issue.