[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090605145756.ed566f48.akpm@linux-foundation.org>
Date: Fri, 5 Jun 2009 14:57:56 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: lkml@...ethan.org, linux-kernel@...r.kernel.org
Subject: Re: [Compile Warning] 2.6.30-rc8 build
On Fri, 5 Jun 2009 19:01:38 +0100
Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> On Fri, 5 Jun 2009 11:43:03 -0500
> "Michael S. Zick" <lkml@...ethan.org> wrote:
>
> > Group,
> >
> > To my reading of the function, I think gcc has a point:
> >
> > drivers/serial/8250.c: In function 'serial8250_shutdown':
> > drivers/serial/8250.c:1685: warning: 'i' may be used uninitialized in this function
> >
> > It does read as if the code might try to initialize
> > the 'lock' field of a null pointer.
> >
> > Suggestions?
>
> Newer gcc ? At least current gcc appears to correctly deduce the code is
> safe.
That's a gcc regression isn't it?
static void serial_unlink_irq_chain(struct uart_8250_port *up)
{
struct irq_info *i;
struct hlist_node *n;
struct hlist_head *h;
mutex_lock(&hash_mutex);
h = &irq_lists[up->port.irq % NR_IRQ_HASH];
hlist_for_each(n, h) {
i = hlist_entry(n, struct irq_info, node);
if (i->irq == up->port.irq)
break;
}
#define hlist_for_each(pos, head) \
for (pos = (head)->first; pos && ({ prefetch(pos->next); 1; }); \
pos = pos->next)
I don't think there's any way in which gcc can deduce that h->first is
non-zero on entry to that loop. Even if it inlines
serial_unlink_irq_chain() into serial8250_shutdown().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists