Latest working kernel version:2.6.29-rc2 Earliest failing kernel version:2.6.29rc3 Distribution:Debian Sid Hardware Environment:Imac G3 600mhz 640MB RAM, 40GB Hard drive Software Environment:? Problem Description: When compiling gets this error on Ext4 FS: "fs/ext4/extents.c: In function ‘ext4_ext_search_right’: fs/ext4/extents.c:1120: warning: ‘ix’ may be used uninitialized in this function " Steps to reproduce:Compile kernel with Ext4
I think this is fixed upstream; you say in the bug metadata that this is version 2.6.28.4 but the first comment says 2.6.29-rc* - which is it?
On Mon, Feb 09, 2009 at 03:15:49AM -0800, bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=12676 > > Summary: fs/ext4/extents.c: In function > ‘ext4_ext_search_right’: fs/ext4/extents.c:1120: > warning: ‘ix’ may be used uninitialized in this > function > When compiling gets this error on Ext4 FS: > "fs/ext4/extents.c: In function ‘ext4_ext_search_right’: > fs/ext4/extents.c:1120: warning: ‘ix’ may be used uninitialized in this > function > " What version of gcc are you using to compile your kernel? This looks like the case of "gcc is stupid not to notice that depth must be non-zero, so ix is always initialized". Which doesn't seem to be the case with gcc 4.3.2, but it might be true with an older version of gcc. We can shut up gcc by forcibly initializing ix, but if this is only a problem with older gcc's, as it seems, it's probably best not to clutter the source (and the compiled binary) with an unneeded initialization: /* go up and search for index to the right */ while (--depth >= 0) { ix = path[depth].p_idx; if (ix != EXT_LAST_INDEX(path[depth].p_hdr)) goto got_index; } /* we've gone up to the root and found no index to the right */ return 0; got_index: /* we've found index to the right, let's * follow it and find the closest allocated * block to the right */ ix++; ^^^^^ Gee, aren't (some verions of) gcc stupid? - Ted
No response from the person filing the bug, and I don't see any compiler warnings gcc 4.3.x, so I'm closing this bug.