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.
Created attachment 21319 [details] compressed .i file
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; }
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.
Hmm, mine :) Honza
Created attachment 21374 [details] patch I am testing.
This is fixed now?
WAITING is for waiting for submitters information.
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.