Re: NUMA aware slab allocator V3

[Christoph Lameter]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/