Messages in this thread Patch in this message | | | Date | Fri, 20 May 2005 12:23:52 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: NUMA aware slab allocator V3 |
| |
On Fri, 20 May 2005, Matthew Dobson wrote:
> Christoph, I'm getting the following errors building rc4-mm2 w/ GCC 2.95.4:
Works fine here with gcc 2.95.4.ds15-22 but that is a debian gcc 2.95.4 patched up to work correctly. If you need to address the pathology in pristine gcc 2.95.4 by changing the source then declare the entry field with 0 members.
Index: linux-2.6.12-rc4/mm/slab.c =================================================================== --- linux-2.6.12-rc4.orig/mm/slab.c 2005-05-19 21:29:45.000000000 +0000 +++ linux-2.6.12-rc4/mm/slab.c 2005-05-20 19:18:22.000000000 +0000 @@ -267,7 +267,7 @@ #ifdef CONFIG_NUMA spinlock_t lock; #endif - void *entry[]; + void *entry[0]; }; /* bootstrap: The caches do not work without cpuarrays anymore,
gcc 2.95 can produce proper code for ppc64?
> mm/slab.c:281: field `entry' has incomplete typemm/slab.c: In function > 'cache_alloc_refill':
See patch above?
> mm/slab.c:2497: warning: control reaches end of non-void function
That is the end of cache_alloc_debug_check right? This is a void function in my source.
> mm/slab.c: In function `kmem_cache_alloc': > mm/slab.c:2567: warning: `objp' might be used uninitialized in this function > mm/slab.c: In function `kmem_cache_alloc_node': > mm/slab.c:2567: warning: `objp' might be used uninitialized in this function > mm/slab.c: In function `__kmalloc': > mm/slab.c:2567: warning: `objp' might be used uninitialized in this function
There is a branch there and the object is initialized in either branch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |