User account creation filtered due to spam.

Bug 45085 - [4.6 Regression] incorrect -Wuninitialized warning
Summary: [4.6 Regression] incorrect -Wuninitialized warning
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: 4.6.0
Assignee: Jan Hubicka
URL:
Keywords: patch
Depends on:
Blocks: Wuninitialized
  Show dependency treegraph
 
Reported: 2010-07-26 16:11 UTC by Tom Tromey
Modified: 2010-09-03 09:10 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.5.0
Known to fail: 4.6.0
Last reconfirmed: 2010-07-27 14:13:35


Attachments
compressed .i file (147.15 KB, application/x-gzip)
2010-07-26 16:12 UTC, Tom Tromey
Details
patch I am testing. (2.65 KB, patch)
2010-08-03 12:08 UTC, Jan Hubicka
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Tromey 2010-07-26 16:11:22 UTC
I'm using a relatively recent svn trunk gcc on an x86 Fedora 13 machine.
I'm trying to compile gdb with it.  I got this error:

../../archer/gdb/remote.c: In function ‘remote_wait’:
../../archer/gdb/remote.c:5561:10: error: ‘event_ptid.tid’ may be used uninitialized in this function [-Werror=uninitialized]
../../archer/gdb/remote.c:5561:10: error: ‘event_ptid.lwp’ may be used uninitialized in this function [-Werror=uninitialized]
../../archer/gdb/remote.c:5561:10: error: ‘event_ptid.pid’ may be used uninitialized in this function [-Werror=uninitialized]
cc1: all warnings being treated as errors

But the body of remote_wait is simple:

{
  ptid_t event_ptid;

  if (non_stop)
    event_ptid = remote_wait_ns (ptid, status, options);
  else
    event_ptid = remote_wait_as (ptid, status, options);

  if (target_can_async_p ())
    {
      /* If there are are events left in the queue tell the event loop
	 to return here.  */
      if (stop_reply_queue)
	mark_async_event_handler (remote_async_inferior_event_token);
    }

  return event_ptid;
}

I thought perhaps that inlining was causing a problem (in which case this
error message is quite confusing, since it would point to the wrong function).

However, I added this:

  memset (&event_ptid, 0, sizeof (event_ptid));

... to the function before the "if", and the error went away.
So, I think this is a gcc bug.

I will attach the .i file.
Comment 1 Tom Tromey 2010-07-26 16:12:35 UTC
Created attachment 21319 [details]
compressed .i file
Comment 2 Jakub Jelinek 2010-07-27 12:42:07 UTC
Simplified testcase for -m32 -O2 -Wuninitialized:

struct S { char *s1; long s2; };
struct T { int t1; long t2; long t3; };
extern int fn2 (void);
extern int fn3 (struct T);
extern struct T fn4 ();
extern int fn5 (char **, long *, int);
extern void fn6 (void);
extern void fn7 (void *);
struct S *fn10 ();
static int p;
static void *q;
extern struct T r;

static struct T
fn8 (struct T x, int y)
{
  struct S *u = fn10 ();
  int v = fn5 (&u->s1, &u->s2, 0);
  while (1)
    {
      if (p)
fn6 ();
      if (fn3 (x))
return fn4 ();
      if (y & 1)
return r;
      v = fn5 (&u->s1, &u->s2, 1);
    }
}

struct T
fn9 (struct T x, int y)
{
  struct T t = fn8 (x, y);
  if (fn2 ())
    fn7 (q);
  return t;
}

void *
fn1 (void)
{
  return fn9;
}
Comment 3 Jakub Jelinek 2010-07-27 12:58:00 UTC
Seems to be caused by partial inlining.
fnsplit splits off the:
  q.0D.2030_3 = qD.1248;
  fn7 (q.0D.2030_3);
part of fn9 into fn9.part.0:
fn9.part.0 ()
{
  intD.0 D.2054;
  voidD.32 * q.0D.2053;
  struct T tD.2052;
  struct T xD.2050;
  intD.0 yD.2051;
  
<bb 4>:
  
<bb 2>:
  q.0D.2053_1 = qD.1248;
  fn7 (q.0D.2053_1);

<bb 3>:
  <retval> = tD.2052;
  return <retval>;
  
}

and uses:
  tD.1261 = fn9.part.0 (); [return slot optimization]
in fn9 instead.  tD.2052 isn't initialized anywhere though (and, it is unclear why it did that at all, as that hunk doesn't modify t).  Perhaps with -m32 and aggregate return (where in the end t will be returned via hidden reference) t is addressable?  In any case, this is fnsplit bug.
Comment 4 Jan Hubicka 2010-07-27 14:13:35 UTC
Hmm, mine :)

Honza
Comment 5 Jan Hubicka 2010-08-03 12:08:51 UTC
Created attachment 21374 [details]
patch I am testing.
Comment 6 Richard Biener 2010-09-02 11:11:20 UTC
This is fixed now?
Comment 7 Manuel López-Ibáñez 2010-09-02 22:59:19 UTC
WAITING is for waiting for submitters information. 
Comment 8 Jakub Jelinek 2010-09-03 09:10:48 UTC
Seems http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162842
has been committed, just Honza forgot to mention the PR in the ChangeLog, testcase and commit message.
I certainly can't reproduce this bug with 20100811 gcc and later, while I can with 20100730.