Fix warning
arch/i386/kernel/io_apic.c: In function `create_irq':
arch/i386/kernel/io_apic.c:2420: warning: 'vector' might be used uninitialized in this function
Signed-off-by: Stefan Richter <[email protected]>
---
Only compile-tested.
arch/x86_64/kernel/io_apic.c seems to have the same initialization already.
Index: linux-2.6.19-rc3/arch/i386/kernel/io_apic.c
===================================================================
--- linux-2.6.19-rc3.orig/arch/i386/kernel/io_apic.c 2006-10-29 20:41:20.000000000 +0100
+++ linux-2.6.19-rc3/arch/i386/kernel/io_apic.c 2006-10-29 21:55:19.000000000 +0100
@@ -2421,6 +2421,7 @@ int create_irq(void)
unsigned long flags;
irq = -ENOSPC;
+ vector = 0;
spin_lock_irqsave(&vector_lock, flags);
for (new = (NR_IRQS - 1); new >= 0; new--) {
if (platform_legacy_irq(new))
* Stefan Richter <[email protected]> wrote:
> Fix warning
> arch/i386/kernel/io_apic.c: In function `create_irq':
> arch/i386/kernel/io_apic.c:2420: warning: 'vector' might be used uninitialized in this function
> @@ -2421,6 +2421,7 @@ int create_irq(void)
> unsigned long flags;
>
> irq = -ENOSPC;
> + vector = 0;
NAK - the code is fine, and this is fixed in Jeff's gcc-warnings tree
via annotation.
Ingo
On Mon, 30 Oct 2006 10:02:31 +0100
Ingo Molnar <[email protected]> wrote:
> * Stefan Richter <[email protected]> wrote:
>
> > Fix warning
> > arch/i386/kernel/io_apic.c: In function `create_irq':
> > arch/i386/kernel/io_apic.c:2420: warning: 'vector' might be used uninitialized in this function
>
> > @@ -2421,6 +2421,7 @@ int create_irq(void)
> > unsigned long flags;
> >
> > irq = -ENOSPC;
> > + vector = 0;
>
> NAK - the code is fine, and this is fixed in Jeff's gcc-warnings tree
> via annotation.
err, what gcc-warnings tree?
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git#gccbug
just does lots of initialise-to-zero thingies, doesn't have any special
annotation and doesn't fix io_apic.c.
On Mon, 2006-10-30 at 17:04 -0800, Andrew Morton wrote:
> > > irq = -ENOSPC;
> > > + vector = 0;
> >
> > NAK - the code is fine, and this is fixed in Jeff's gcc-warnings
> tree
> > via annotation.
>
> err, what gcc-warnings tree?
>
> git
> +ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git#gccbug
> just does lots of initialise-to-zero thingies, doesn't have any
> special
> annotation and doesn't fix io_apic.c.
this is an initialize-to-zero annotation for a false-positive gcc
warning. If it's not in Jeff tree yet then it should be there ...
Ingo
On Tue, 31 Oct 2006 10:37:37 +0100
Ingo Molnar <[email protected]> wrote:
> On Mon, 2006-10-30 at 17:04 -0800, Andrew Morton wrote:
> > > > irq = -ENOSPC;
> > > > + vector = 0;
> > >
> > > NAK - the code is fine, and this is fixed in Jeff's gcc-warnings
> > tree
> > > via annotation.
> >
> > err, what gcc-warnings tree?
> >
> > git
> > +ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git#gccbug
> > just does lots of initialise-to-zero thingies, doesn't have any
> > special
> > annotation and doesn't fix io_apic.c.
>
> this is an initialize-to-zero annotation for a false-positive gcc
> warning. If it's not in Jeff tree yet then it should be there ...
>
hm, I wouldn't call that "annotation".
Now, the
#define SHUT_GCC_UP(x) = x
...
int foo SHUT_GCC_UP(foo);
...
(or whatever it was) trick was "annotation". A good way of doing it too, IMO.
* Andrew Morton <[email protected]> wrote:
> > this is an initialize-to-zero annotation for a false-positive gcc
> > warning. If it's not in Jeff tree yet then it should be there ...
>
> hm, I wouldn't call that "annotation".
>
> Now, the
>
> #define SHUT_GCC_UP(x) = x
>
> ...
> int foo SHUT_GCC_UP(foo);
> ...
>
> (or whatever it was) trick was "annotation". A good way of doing it
> too, IMO.
hm, i thought Jeff's tree was doing that ...
we definitely do not want to hide these places. They both make the code
less readable (why initialize it to some value if that value is never
used) and they hide the problem from the GCC folks too.
Ingo
On Tue, Oct 31, 2006 at 12:15:02PM +0100, Ingo Molnar wrote:
>...
> we definitely do not want to hide these places. They both make the code
> less readable (why initialize it to some value if that value is never
> used) and they hide the problem from the GCC folks too.
What about cases where it's technically impossible for gcc to ever see
that a variable actually gets initialized?
> Ingo
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
* Adrian Bunk <[email protected]> wrote:
> On Tue, Oct 31, 2006 at 12:15:02PM +0100, Ingo Molnar wrote:
> >...
> > we definitely do not want to hide these places. They both make the
> > code less readable (why initialize it to some value if that value is
> > never used) and they hide the problem from the GCC folks too.
>
> What about cases where it's technically impossible for gcc to ever see
> that a variable actually gets initialized?
we should mark them as such or even initialize them outright. But these
are the exception.
Ingo