sparse segfault on ppc64.

sparse segfault on ppc64.

[Dave Jones]

I thought I'd see what happens if I hooked up sparse
to our daily builds of Linus' tree.
The answer: a segfault on ppc64.

/usr/lib/gcc/ppc64-redhat-linux/4.1.2/include/altivec.h:37:2: error: Use the "-maltivec" flag to enable PowerPC AltiVec support
drivers/md/raid6altivec1.c:41:16: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:41:16: error: got signed
drivers/md/raid6altivec1.c:50:45: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:50:45: error: got SHLBYTE
drivers/md/raid6altivec1.c:53:1: error: Expected ; end of type declaration
drivers/md/raid6altivec1.c:53:1: error: got }
drivers/md/raid6altivec1.c:64:2: error: Trying to use reserved word 'return' as identifier
drivers/md/raid6altivec1.c:64:20: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:64:20: error: got __builtin_vec_cmpgt
drivers/md/raid6altivec1.c:65:1: error: Expected ; end of type declaration
drivers/md/raid6altivec1.c:65:1: error: got }
drivers/md/raid6altivec1.c:77:12: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:77:12: error: got wd0
drivers/md/raid6altivec1.c:78:12: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:78:12: error: got x1d
drivers/md/raid6altivec1.c:84:10: error: Expected ) in function declarator
drivers/md/raid6altivec1.c:84:10: error: got =
drivers/md/raid6altivec1.c:84:2: error: Trying to use reserved word 'for' as identifier
drivers/md/raid6altivec1.c:84:18: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:84:18: error: got <
drivers/md/raid6altivec1.c:84:30: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:84:30: error: got +=
drivers/md/raid6altivec1.c:86:11: error: Expected ) in function declarator
drivers/md/raid6altivec1.c:86:11: error: got =
drivers/md/raid6altivec1.c:86:3: error: Trying to use reserved word 'for' as identifier
drivers/md/raid6altivec1.c:86:22: error: Expected ; at end of declaration
vers/md/raid6altivec1.c:86:22: error: got >=
drivers/md/raid6altivec1.c:86:30: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:86:30: error: got --
drivers/md/raid6altivec1.c:94:3: error: Expected ; end of type declaration
drivers/md/raid6altivec1.c:94:3: error: got }
drivers/md/raid6altivec1.c:96:15: error: Expected ) in nested declarator
drivers/md/raid6altivec1.c:96:15: error: got *
drivers/md/raid6altivec1.c:97:2: error: Expected ; end of type declaration
drivers/md/raid6altivec1.c:97:2: error: got }
drivers/md/raid6altivec1.c:107:2: error: Trying to use reserved word 'do' as identifier
drivers/md/raid6altivec1.c:107:2: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:107:2: error: got {
drivers/md/raid6altivec1.c:108:1: error: Expected ; end of type declaration
drivers/md/raid6altivec1.c:108:1: error: got }
drivers/md/raid6altivec1.c:80:7: error: undefined identifier 'disks'
drivers/md/raid6altivec1.c:80:2: error: symbol 'z0' redeclared with different type (originally declared at drivers/md/raid6altivec1.c:7
5) - different signedness
drivers/md/raid6altivec1.c:81:6: error: undefined identifier 'dptr'
drivers/md/raid6altivec1.c:81:2: error: symbol 'p' redeclared with different type (originally declared at drivers/md/raid6altivec1.c:74
) - different base types
drivers/md/raid6altivec1.c:82:6: error: undefined identifier 'dptr'
drivers/md/raid6altivec1.c:82:2: error: symbol 'q' redeclared with different type (originally declared at drivers/md/raid6altivec1.c:74
) - different base types
drivers/md/raid6altivec1.c:84:16: error: symbol 'd' redeclared with different type (originally declared at drivers/md/raid6altivec1.c:7
5) - different signedness
drivers/md/raid6altivec1.c:84:28: error: symbol 'd' redeclared with different type (originally declared at drivers/md/raid6altivec1.c:7
5) - different signedness
drivers/md/raid6altivec1.c:86:20: error: symbol 'z' redeclared with different type (originally declared at drivers/md/raid6altivec1.c:7
5) - different signedness
drivers/md/raid6altivec1.c:86:29: error: symbol 'z' redeclared with different type (originally declared at drivers/md/raid6altivec1.c:7
5) - different signedness
drivers/md/raid6altivec1.c:88:10: error: undefined identifier '__builtin_vec_xor'
drivers/md/raid6altivec1.c:89:10: error: undefined identifier 'MASK'
drivers/md/raid6altivec1.c:90:10: error: undefined identifier 'SHLBYTE'
drivers/md/raid6altivec1.c:91:10: error: undefined identifier '__builtin_vec_and'
drivers/md/raid6altivec1.c:92:10: error: undefined identifier '__builtin_vec_xor'
drivers/md/raid6altivec1.c:93:10: error: undefined identifier '__builtin_vec_xor'
drivers/md/raid6altivec1.c:96:3: error: symbol 'unative_t' redeclared with different type (originally declared at drivers/md/raid6altiv
ec1.c:78) - different base types
drivers/md/raid6altivec1.c:124:2: error: undefined identifier 'raid6_altivec1_gen_syndrome'
/bin/sh: line 1: 22303 Segmentation fault      sparse-0.2/sparse -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ -Wbitwise -m32 -D__po
werpc__ -D__powerpc32__ -nostdinc -isystem /usr/lib/gcc/ppc64-redhat-linux/4.1.2/include -Wp,-MD,drivers/md/.raid6altivec1.o.d -nostdin
c -isystem /usr/lib/gcc/ppc64-redhat-linux/4.1.2/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Iarch/powerpc -Iarch
/powerpc/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaratio
n -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Os -msoft-float -pipe -Iarch/powerpc -ffixed-r2 -mmultiple -mno-altive
c -funit-at-a-time -mstring -mcpu=powerpc -Wa,-maltivec -fomit-frame-pointer -g -fno-stack-protector -Wdeclaration-after-statement -Wno
-pointer-sign -maltivec -mabi=altivec -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(raid6altivec1)" -D"KBUILD_MODNAME=KBU
ILD_STR(raid456)" drivers/md/raid6altivec1.c
make[2]: *** [drivers/md/raid6altivec1.o] Error 139


Is this something new, or am I the first person dumb enough to try and
run sparse on non-x86 ?

	Dave

-- 
http://www.codemonkey.org.uk

Re: sparse segfault on ppc64.

[Christopher Li]

On Thu, Mar 22, 2007 at 07:33:44AM +0000, Al Viro wrote:
> Segfault is new (which version?); the fscking mess in altivec is not, but
> it (a) doesn't depend on host sparse is ran on; (b) shouldn't lead to
> segfaults.  Altivec extensions are undocumented and fortunately used only
> in one place in the tree.  You should get sparse errors, but it shouldn't
> die on those.

I think the segfault is likely to cause by my recent change in the parser.

Dave, can you get a backtrace of the segfault? Even better if you can
give me a small test case which I can reproduce it on x86.

My guess it is cause by the bad_ctype related changes.

Chris

Re: sparse segfault on ppc64.

[Al Viro]

On Thu, Mar 22, 2007 at 02:36:00AM -0400, Dave Jones wrote:

> Is this something new, or am I the first person dumb enough to try and
> run sparse on non-x86 ?

Segfault is new (which version?); the fscking mess in altivec is not, but
it (a) doesn't depend on host sparse is ran on; (b) shouldn't lead to
segfaults.  Altivec extensions are undocumented and fortunately used only
in one place in the tree.  You should get sparse errors, but it shouldn't
die on those.

[PATCH] vector parsing, was Re: sparse segfault on ppc64.

[Christopher Li]

> /bin/sh: line 1: 22303 Segmentation fault      sparse-0.2/sparse -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ -Wbitwise -m32 -D__po

I am still interest to get the segfault.

On the other hand, I hack up a patch for vector parsing.
Care to give it a try?

Chris

It add very basic vector parsing. Not heavily tested yet.

Signed-Off-By: Christopher Li <sparse@chrisli.org>

Index: sparse/parse.c
===================================================================
--- sparse.orig/parse.c	2007-03-22 00:57:02.000000000 -0700
+++ sparse/parse.c	2007-03-22 02:01:35.000000000 -0700
@@ -34,6 +34,8 @@ static struct symbol_list **function_sym
 struct symbol_list *function_computed_target_list;
 struct statement_list *function_computed_goto_list;
 
+static struct symbol * alloc_indirect_symbol(struct position pos, struct ctype *ctype, int type);
+
 static struct token *statement(struct token *token, struct statement **tree);
 static struct token *handle_attributes(struct token *token, struct ctype *ctype);
 
@@ -225,6 +227,8 @@ static struct init_keyword {
 	{ "union", 	NS_TYPEDEF, .op = &union_op },
 	{ "enum", 	NS_TYPEDEF, .op = &enum_op },
 
+	{ "vector", 	NS_TYPEDEF, MOD_VECTOR, .op = &modifier_op },
+
 	{ "inline",	NS_TYPEDEF, MOD_INLINE, .op = &modifier_op },
 	{ "__inline",	NS_TYPEDEF, MOD_INLINE, .op = &modifier_op },
 	{ "__inline__",	NS_TYPEDEF, MOD_INLINE, .op = &modifier_op },
@@ -382,6 +386,7 @@ static int apply_modifiers(struct positi
 		case SYM_ARRAY:
 		case SYM_BITFIELD:
 		case SYM_PTR:
+		case SYM_VECTOR:
 			ctype = &base->ctype;
 			continue;
 		}
@@ -412,6 +417,13 @@ static int apply_modifiers(struct positi
 		ctype->base_type = type;
 		create_fouled(type);
 	}
+	if (ctype->modifiers & MOD_VECTOR) {
+		struct symbol *vec;
+		ctype->modifiers &= ~MOD_VECTOR;
+		vec = alloc_indirect_symbol(pos, ctype, SYM_VECTOR);
+		/* XXX: correct the size and alignment of vector */
+
+	}
 	return 0;
 }
 
Index: sparse/symbol.h
===================================================================
--- sparse.orig/symbol.h	2007-03-22 00:57:02.000000000 -0700
+++ sparse/symbol.h	2007-03-22 01:36:43.000000000 -0700
@@ -54,6 +54,7 @@ enum type {
 	SYM_LABEL,
 	SYM_RESTRICT,
 	SYM_FOULED,
+	SYM_VECTOR,
 	SYM_KEYWORD,
 	SYM_BAD,
 };
@@ -178,7 +179,8 @@ struct symbol {
 #define MOD_LONG	0x0400
 #define MOD_LONGLONG	0x0800
 
-#define MOD_TYPEDEF	0x1000
+#define MOD_VECTOR	0x1000
+#define MOD_TYPEDEF	0x2000
 
 #define MOD_INLINE	0x40000
 #define MOD_ADDRESSABLE	0x80000
Index: sparse/evaluate.c
===================================================================
--- sparse.orig/evaluate.c	2007-03-19 16:16:29.000000000 -0700
+++ sparse/evaluate.c	2007-03-22 01:56:50.000000000 -0700
@@ -349,6 +349,7 @@ enum {
 	TYPE_PTR = 16,
 	TYPE_COMPOUND = 32,
 	TYPE_FOULED = 64,
+	TYPE_VECTOR = 128,
 };
 
 static inline int classify_type(struct symbol *type, struct symbol **base)
@@ -362,6 +363,7 @@ static inline int classify_type(struct s
 		[SYM_BITFIELD] = TYPE_NUM | TYPE_BITFIELD,
 		[SYM_RESTRICT] = TYPE_NUM | TYPE_RESTRICT,
 		[SYM_FOULED] = TYPE_NUM | TYPE_RESTRICT | TYPE_FOULED,
+		[SYM_VECTOR] = TYPE_VECTOR | TYPE_NUM, 
 	};
 	if (type->type == SYM_NODE)
 		type = type->ctype.base_type;
@@ -556,6 +558,9 @@ static struct symbol *evaluate_arith(str
 	if (!(lclass & rclass & TYPE_NUM))
 		goto Bad;
 
+	if ((lclass ^ rclass) & TYPE_VECTOR)
+		goto Bad;
+
 	if (!float_ok && (lclass | rclass) & TYPE_FLOAT)
 		goto Bad;
 
@@ -2086,6 +2091,7 @@ static void evaluate_initializer(struct 
 		switch (ctype->type) {
 		case SYM_ARRAY:
 		case SYM_PTR:
+		case SYM_VECTOR:
 			evaluate_array_initializer(get_base_type(ctype), expr);
 			return;
 		case SYM_UNION:
Index: sparse/validation/vector.c
===================================================================
--- sparse.orig/validation/vector.c	2007-03-22 00:51:11.000000000 -0700
+++ sparse/validation/vector.c	2007-03-22 01:07:00.000000000 -0700
@@ -0,0 +1,30 @@
+typedef vector signed char unative_t;
+
+#define NBYTES(x) ((vector signed char) {x,x,x,x, x,x,x,x, x,x,x,x, x,x,x,x})
+#define NSIZE	sizeof(unative_t)
+
+#define __attribute_const__		__attribute__((__const__))
+
+extern unative_t vec_add(unative_t a, unative_t b);
+extern unative_t vec_cmpgt(unative_t a, unative_t b);
+
+static inline __attribute_const__ unative_t SHLBYTE(unative_t v)
+{
+	return vec_add(v,v);
+}
+
+static inline __attribute_const__ unative_t MASK(unative_t v)
+{
+	unative_t zv = NBYTES(0);
+
+	/* vec_cmpgt returns a vector bool char; thus the need for the cast */
+	return (unative_t)vec_cmpgt(zv, v);
+}
+
+
+unative_t foo(void)
+{
+	unative_t i = NBYTES(1);
+	return SHLBYTE(i) + MASK(i);
+}
+

Re: sparse segfault on ppc64.

[Al Viro]

On Thu, Mar 22, 2007 at 12:03:54AM -0700, Christopher Li wrote:
> On Thu, Mar 22, 2007 at 07:33:44AM +0000, Al Viro wrote:
> > Segfault is new (which version?); the fscking mess in altivec is not, but
> > it (a) doesn't depend on host sparse is ran on; (b) shouldn't lead to
> > segfaults.  Altivec extensions are undocumented and fortunately used only
> > in one place in the tree.  You should get sparse errors, but it shouldn't
> > die on those.
> 
> I think the segfault is likely to cause by my recent change in the parser.
> 
> Dave, can you get a backtrace of the segfault? Even better if you can
> give me a small test case which I can reproduce it on x86.
> 
> My guess it is cause by the bad_ctype related changes.

Humm...  I don't see ppc segfaults with the current tree.  However, after
merging the mainline sparse changes and looking for regressions on kernel
allmodconfig builds, I'm seeing a lot of noise due to expression_error() use.
What used to generate a single error now brings a cascade.  More often than
not it's utterly pointless; actually, I can't find a single instance where
additional errors would add any useful information...

Re: sparse segfault on ppc64.

[Dave Jones]

On Thu, Mar 22, 2007 at 07:33:44AM +0000, Al Viro wrote:
 > On Thu, Mar 22, 2007 at 02:36:00AM -0400, Dave Jones wrote:
 > 
 > > Is this something new, or am I the first person dumb enough to try and
 > > run sparse on non-x86 ?
 > 
 > Segfault is new (which version?);

0.2

	Dave

-- 
http://www.codemonkey.org.uk

Re: sparse segfault on ppc64.

[Al Viro]

On Thu, Mar 22, 2007 at 11:56:51AM -0400, Dave Jones wrote:
> On Thu, Mar 22, 2007 at 07:33:44AM +0000, Al Viro wrote:
>  > On Thu, Mar 22, 2007 at 02:36:00AM -0400, Dave Jones wrote:
>  > 
>  > > Is this something new, or am I the first person dumb enough to try and
>  > > run sparse on non-x86 ?
>  > 
>  > Segfault is new (which version?);
> 
> 0.2

Could you run

make C=2 V=1 drivers/md/raid6altivec1.o

pick sparse invocation out of that and mail it *and* its output with -E
added to command line?  IOW, flags and preprocessed-by-sparse input...

Re: sparse segfault on ppc64.

[Dave Jones]

On Thu, Mar 22, 2007 at 12:03:54AM -0700, Christopher Li wrote:
 > On Thu, Mar 22, 2007 at 07:33:44AM +0000, Al Viro wrote:
 > > Segfault is new (which version?); the fscking mess in altivec is not, but
 > > it (a) doesn't depend on host sparse is ran on; (b) shouldn't lead to
 > > segfaults.  Altivec extensions are undocumented and fortunately used only
 > > in one place in the tree.  You should get sparse errors, but it shouldn't
 > > die on those.
 > 
 > I think the segfault is likely to cause by my recent change in the parser.
 > 
 > Dave, can you get a backtrace of the segfault? Even better if you can
 > give me a small test case which I can reproduce it on x86.

I did battle with our ppc64 buildhost last night to try and coax it
into giving me a coredump, no luck. And as I don't have gcc in that
chroot, I couldn't build it natively.  Given this is altivec stuff,
I didn't try building it on x86. At which point I admitted defeat
and turned in for the night ;)

I'll see if I can force it into something buildable on x86 later,
but first I'll see if I can get a useful shell on that buildhost
that I can run gcc & gdb in.

	Dave
-- 
http://www.codemonkey.org.uk

Re: sparse segfault on ppc64.

[Dave Jones]

On Thu, Mar 22, 2007 at 12:03:54AM -0700, Christopher Li wrote:
 > On Thu, Mar 22, 2007 at 07:33:44AM +0000, Al Viro wrote:
 > > Segfault is new (which version?); the fscking mess in altivec is not, but
 > > it (a) doesn't depend on host sparse is ran on; (b) shouldn't lead to
 > > segfaults.  Altivec extensions are undocumented and fortunately used only
 > > in one place in the tree.  You should get sparse errors, but it shouldn't
 > > die on those.
 > 
 > I think the segfault is likely to cause by my recent change in the parser.
 > 
 > Dave, can you get a backtrace of the segfault? Even better if you can
 > give me a small test case which I can reproduce it on x86.
 > 
 > My guess it is cause by the bad_ctype related changes.

So the good news is that this only seems to affect 0.2
Current git doesn't segfault, but still emits lots of spew.

	Dave

make -f scripts/Makefile.build obj=drivers/md drivers/md/raid6altivec1.o
  sparse -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ -Wbitwise  -m64 -D__powerpc__ -D__powerpc64__  -nostdinc -isystem /usr/lib/gcc/powerpc64-linux/4.0.1/include -Wp,-MD,drivers/md/.raid6altivec1.o.d  -nostdinc -isystem /usr/lib/gcc/powerpc64-linux/4.0.1/include -D__KERNEL__ -Iinclude  -include include/linux/autoconf.h  -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Os -msoft-float -pipe -mminimal-toc -mtraceback=none  -mcall-aixdesc -mtune=power4 -mno-altivec -funit-at-a-time -mstring -Wa,-maltivec -fomit-frame-pointer -g  -Wdeclaration-after-statement -Wno-pointer-sign  -maltivec -mabi=altivec -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(raid6altivec1)"  -D"KBUILD_MODNAME=KBUILD_STR(raid456)" drivers/md/raid6altivec1.c ;
/usr/lib/gcc/powerpc64-linux/4.0.1/include/altivec.h:36:2: error: Use the "-maltivec" flag to enable PowerPC AltiVec support
drivers/md/raid6altivec1.c:41:16: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:41:16: error: got signed
drivers/md/raid6altivec1.c:50:45: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:50:45: error: got SHLBYTE
drivers/md/raid6altivec1.c:53:1: error: Expected ; end of type declaration
drivers/md/raid6altivec1.c:53:1: error: got }
drivers/md/raid6altivec1.c:64:2: error: Trying to use reserved word 'return' as identifier
drivers/md/raid6altivec1.c:64:20: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:64:20: error: got __builtin_choose_expr
drivers/md/raid6altivec1.c:65:1: error: Expected ; end of type declaration
drivers/md/raid6altivec1.c:65:1: error: got }
drivers/md/raid6altivec1.c:77:12: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:77:12: error: got wd0
drivers/md/raid6altivec1.c:78:12: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:78:12: error: got x1d
drivers/md/raid6altivec1.c:84:10: error: Expected ) in function declarator
drivers/md/raid6altivec1.c:84:10: error: got =
drivers/md/raid6altivec1.c:84:2: error: Trying to use reserved word 'for' as identifier
drivers/md/raid6altivec1.c:84:18: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:84:18: error: got <
drivers/md/raid6altivec1.c:84:30: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:84:30: error: got +=
drivers/md/raid6altivec1.c:86:11: error: Expected ) in function declarator
drivers/md/raid6altivec1.c:86:11: error: got =
drivers/md/raid6altivec1.c:86:3: error: Trying to use reserved word 'for' as identifier
drivers/md/raid6altivec1.c:86:22: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:86:22: error: got >=
drivers/md/raid6altivec1.c:86:30: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:86:30: error: got --
drivers/md/raid6altivec1.c:88:10: error: Expected , in __builtin_types_compatible_p
drivers/md/raid6altivec1.c:88:10: error: got float
drivers/md/raid6altivec1.c:91:10: error: Expected , in __builtin_types_compatible_p
drivers/md/raid6altivec1.c:91:10: error: got float
drivers/md/raid6altivec1.c:92:10: error: Expected , in __builtin_types_compatible_p
drivers/md/raid6altivec1.c:92:10: error: got float
drivers/md/raid6altivec1.c:93:10: error: Expected , in __builtin_types_compatible_p
drivers/md/raid6altivec1.c:93:10: error: got float
drivers/md/raid6altivec1.c:94:3: error: Expected ; end of type declaration
drivers/md/raid6altivec1.c:94:3: error: got }
drivers/md/raid6altivec1.c:96:15: error: Expected ) in nested declarator
drivers/md/raid6altivec1.c:96:15: error: got *
drivers/md/raid6altivec1.c:97:2: error: Expected ; end of type declaration
drivers/md/raid6altivec1.c:97:2: error: got }
drivers/md/raid6altivec1.c:107:2: error: Trying to use reserved word 'do' as identifier
drivers/md/raid6altivec1.c:107:2: error: Expected ; at end of declaration
drivers/md/raid6altivec1.c:107:2: error: got {
drivers/md/raid6altivec1.c:108:1: error: Expected ; end of type declaration
drivers/md/raid6altivec1.c:108:1: error: got }
drivers/md/raid6altivec1.c:80:7: error: undefined identifier 'disks'
drivers/md/raid6altivec1.c:80:2: error: symbol 'z0' redeclared with different type (originally declared at drivers/md/raid6altivec1.c:75) - different signedness
drivers/md/raid6altivec1.c:81:6: error: undefined identifier 'dptr'
drivers/md/raid6altivec1.c:81:2: error: symbol 'p' redeclared with different type (originally declared at drivers/md/raid6altivec1.c:74) - different base types
drivers/md/raid6altivec1.c:82:6: error: undefined identifier 'dptr'
drivers/md/raid6altivec1.c:82:2: error: symbol 'q' redeclared with different type (originally declared at drivers/md/raid6altivec1.c:74) - different base types
drivers/md/raid6altivec1.c:84:16: error: symbol 'd' redeclared with different type (originally declared at drivers/md/raid6altivec1.c:75) - different signedness
drivers/md/raid6altivec1.c:84:28: error: symbol 'd' redeclared with different type (originally declared at drivers/md/raid6altivec1.c:75) - different signedness
drivers/md/raid6altivec1.c:86:20: error: symbol 'z' redeclared with different type (originally declared at drivers/md/raid6altivec1.c:75) - different signedness
drivers/md/raid6altivec1.c:86:29: error: symbol 'z' redeclared with different type (originally declared at drivers/md/raid6altivec1.c:75) - different signedness
drivers/md/raid6altivec1.c:89:10: error: undefined identifier 'MASK'
drivers/md/raid6altivec1.c:90:10: error: undefined identifier 'SHLBYTE'
drivers/md/raid6altivec1.c:96:3: error: symbol 'unative_t' redeclared with different type (originally declared at drivers/md/raid6altivec1.c:78) - different base types
drivers/md/raid6altivec1.c:124:2: error: undefined identifier 'raid6_altivec1_gen_syndrome'

-- 
http://www.codemonkey.org.uk

Re: sparse segfault on ppc64.

[Christopher Li]

On Thu, Mar 22, 2007 at 01:11:18PM -0400, Dave Jones wrote:
> So the good news is that this only seems to affect 0.2
> Current git doesn't segfault, but still emits lots of spew.
> 
> 	Dave
> 
> /usr/lib/gcc/powerpc64-linux/4.0.1/include/altivec.h:36:2: error: Use the "-maltivec" flag to enable PowerPC AltiVec support
> drivers/md/raid6altivec1.c:41:16: error: Expected ; at end of declaration
> drivers/md/raid6altivec1.c:41:16: error: got signed

The spew is cause by the vector extension which sparse know nothing about.
It is kind of expected.

I found a few place the kernel use "vector" as declarator. This introduce
ambiguity in expression:

(vector char) { x, x }

We look at 'vector', we can't decide it is a type or node yet. Because 'vector'
can be use as symbol. We have to look at the next token to decide if this is
cast expression or not.

Do we want to support vector in sparse?

Chris

Re: sparse segfault on ppc64.

[Christopher Li]

On Thu, Mar 22, 2007 at 12:59:11PM +0000, Al Viro wrote:
> On Thu, Mar 22, 2007 at 12:03:54AM -0700, Christopher Li wrote:
> Humm...  I don't see ppc segfaults with the current tree.  However, after
> merging the mainline sparse changes and looking for regressions on kernel
> allmodconfig builds, I'm seeing a lot of noise due to expression_error() use.
> What used to generate a single error now brings a cascade.  More often than

Can you show me some example of the duplicate error? I can't seem to hit it
in on x86. I do notice though there is a few context imbalance report on the
inline function instead of the caller site.

> not it's utterly pointless; actually, I can't find a single instance where
> additional errors would add any useful information...

The expression_error is not intend to report more error. It is try to avoid
test expr->ctype against zero all the time. We often have error path there is
some expression has NULL in ctype then sparse segfaulted.

We can work on clean up the duplicate warnings.

Chris

more spewage (Re: sparse segfault on ppc64)

[Randy Dunlap]

On Thu, 22 Mar 2007 15:10:51 -0700 Christopher Li wrote:

> On Thu, Mar 22, 2007 at 01:11:18PM -0400, Dave Jones wrote:
> > So the good news is that this only seems to affect 0.2
> > Current git doesn't segfault, but still emits lots of spew.
> > 
> > 	Dave
> > 
> > /usr/lib/gcc/powerpc64-linux/4.0.1/include/altivec.h:36:2: error: Use the "-maltivec" flag to enable PowerPC AltiVec support
> > drivers/md/raid6altivec1.c:41:16: error: Expected ; at end of declaration
> > drivers/md/raid6altivec1.c:41:16: error: got signed
> 
> The spew is cause by the vector extension which sparse know nothing about.
> It is kind of expected.

There are also sparse error spewings on attributes((...)) that are
not in the expected source code location.  Three examples:


1.  net/sched/cls_api.c, lines 593-611:

	return 0;
rtattr_failure: __attribute__ ((unused))
	return -1;
}

...

	return 0;
rtattr_failure: __attribute__ ((unused))
	return -1;
}

These spew:

net/sched/cls_api.c:593:17: error: typename in expression
net/sched/cls_api.c:594:2: error: Expected ; at end of statement
net/sched/cls_api.c:594:2: error: got return
net/sched/cls_api.c:611:17: error: typename in expression
net/sched/cls_api.c:612:2: error: Expected ; at end of statement
net/sched/cls_api.c:612:2: error: got return
net/sched/cls_api.c:593:17: error: undefined identifier '__attribute__'
net/sched/cls_api.c:611:17: error: undefined identifier '__attribute__'


2.  in 2.6.21-rc4-mm1 only AFAIK, arch/x86_64/kernel/early-quirks.c, #79:

static struct __initdata chipset early_qrk[] = {
	{ PCI_VENDOR_ID_NVIDIA, nvidia_bugs },
	{ PCI_VENDOR_ID_VIA, via_bugs },
	{ PCI_VENDOR_ID_ATI, ati_bugs },
	{}
};

spews:

arch/x86_64/kernel/early-quirks.c:79:15: error: Trying to use reserved word '__attribute__' as identifier
arch/x86_64/kernel/early-quirks.c:79:15: error: Expected ) in function declarator
arch/x86_64/kernel/early-quirks.c:79:15: error: got ".init.data"


3.  drivers/kvm/ spews LOTS of mess:

drivers/kvm/svm.h:50:8: error: Trying to use reserved word '__attribute__' as identifier
drivers/kvm/svm.h:50:37: error: Expected ; at end of declaration
drivers/kvm/svm.h:50:37: error: got vmcb_control_area
drivers/kvm/svm.h:81:1: error: Expected ; end of type declaration
drivers/kvm/svm.h:81:1: error: got }
drivers/kvm/svm.h:114:8: error: Trying to use reserved word '__attribute__' as identifier
drivers/kvm/svm.h:114:37: error: Expected ; at end of declaration
drivers/kvm/svm.h:114:37: error: got vmcb_seg
drivers/kvm/svm.h:119:1: error: Expected ; end of type declaration
drivers/kvm/svm.h:119:1: error: got }
drivers/kvm/svm.h:121:8: error: Trying to use reserved word '__attribute__' as identifier
drivers/kvm/svm.h:121:37: error: Expected ; at end of declaration
drivers/kvm/svm.h:121:37: error: got vmcb_save_area
drivers/kvm/svm.h:164:1: error: Expected ; end of type declaration
drivers/kvm/svm.h:164:1: error: got }
drivers/kvm/svm.h:166:8: error: Trying to use reserved word '__attribute__' as identifier
drivers/kvm/svm.h:166:37: error: Expected ; at end of declaration
drivers/kvm/svm.h:166:37: error: got vmcb
drivers/kvm/svm.h:169:1: error: Expected ; end of type declaration
drivers/kvm/svm.h:169:1: error: got }
drivers/kvm/svm.c:87:46: error: no member 'save' in struct vmcb
drivers/kvm/svm.c:90:10: error: no member 'cr0' in struct vmcb_save_area
drivers/kvm/svm.c:93:16: error: no member 'cs' in struct vmcb_save_area
drivers/kvm/svm.c:186:17: error: no member 'save' in struct vmcb
drivers/kvm/svm.c:192:17: error: no member 'control' in struct vmcb
drivers/kvm/svm.c:196:17: error: no member 'control' in struct vmcb
drivers/kvm/svm.c:201:17: error: no member 'control' in struct vmcb
drivers/kvm/svm.c:208:17: error: no member 'control' in struct vmcb
drivers/kvm/svm.c:231:43: error: no member 'save' in struct vmcb
drivers/kvm/svm.c:234:25: error: no member 'save' in struct vmcb
drivers/kvm/svm.c:238:29: error: no member 'save' in struct vmcb
drivers/kvm/svm.c:239:17: error: no member 'control' in struct vmcb
drivers/kvm/svm.c:438:5: error: no member 'selector' in struct vmcb_seg
drivers/kvm/svm.c:439:5: error: no member 'attrib' in struct vmcb_seg
drivers/kvm/svm.c:441:5: error: no member 'limit' in struct vmcb_seg
drivers/kvm/svm.c:442:5: error: no member 'base' in struct vmcb_seg
drivers/kvm/svm.c:447:5: error: no member 'selector' in struct vmcb_seg
drivers/kvm/svm.c:448:5: error: no member 'attrib' in struct vmcb_seg
drivers/kvm/svm.c:449:5: error: no member 'limit' in struct vmcb_seg
drivers/kvm/svm.c:450:5: error: no member 'base' in struct vmcb_seg
drivers/kvm/svm.c:460:43: error: no member 'control' in struct vmcb
drivers/kvm/svm.c:461:37: error: no member 'save' in struct vmcb
drivers/kvm/svm.c:464:9: error: no member 'intercept_cr_read' in struct vmcb_control_area
drivers/kvm/svm.c:468:9: error: no member 'intercept_cr_write' in struct vmcb_control_area
drivers/kvm/svm.c:472:9: error: no member 'intercept_dr_read' in struct vmcb_control_area
drivers/kvm/svm.c:477:9: error: no member 'intercept_dr_write' in struct vmcb_control_area
drivers/kvm/svm.c:484:9: error: no member 'intercept_exceptions' in struct vmcb_control_area
drivers/kvm/svm.c:487:9: error: no member 'intercept' in struct vmcb_control_area
drivers/kvm/svm.c:516:9: error: no member 'iopm_base_pa' in struct vmcb_control_area
drivers/kvm/svm.c:517:9: error: no member 'msrpm_base_pa' in struct vmcb_control_area
drivers/kvm/svm.c:519:9: error: no member 'tsc_offset' in struct vmcb_control_area
drivers/kvm/svm.c:520:9: error: no member 'int_ctl' in struct vmcb_control_area
drivers/kvm/svm.c:522:16: error: no member 'es' in struct vmcb_save_area
drivers/kvm/svm.c:523:16: error: no member 'ss' in struct vmcb_save_area
drivers/kvm/svm.c:524:16: error: no member 'ds' in struct vmcb_save_area
drivers/kvm/svm.c:525:16: error: no member 'fs' in struct vmcb_save_area
drivers/kvm/svm.c:526:16: error: no member 'gs' in struct vmcb_save_area
drivers/kvm/svm.c:528:6: error: no member 'cs' in struct vmcb_save_area
drivers/kvm/svm.c:530:6: error: no member 'cs' in struct vmcb_save_area
drivers/kvm/svm.c:532:6: error: no member 'cs' in struct vmcb_save_area
drivers/kvm/svm.c:539:6: error: no member 'cs' in struct vmcb_save_area
drivers/kvm/svm.c:541:6: error: no member 'gdtr' in struct vmcb_save_area
drivers/kvm/svm.c:542:6: error: no member 'idtr' in struct vmcb_save_area
drivers/kvm/svm.c:544:20: error: no member 'ldtr' in struct vmcb_save_area
drivers/kvm/svm.c:545:20: error: no member 'tr' in struct vmcb_save_area
drivers/kvm/svm.c:547:6: error: no member 'efer' in struct vmcb_save_area
drivers/kvm/svm.c:549:13: error: no member 'dr6' in struct vmcb_save_area
drivers/kvm/svm.c:550:6: error: no member 'dr7' in struct vmcb_save_area
drivers/kvm/svm.c:551:6: error: no member 'rflags' in struct vmcb_save_area
drivers/kvm/svm.c:552:6: error: no member 'rip' in struct vmcb_save_area
drivers/kvm/svm.c:558:6: error: no member 'cr0' in struct vmcb_save_area
drivers/kvm/svm.c:559:6: error: no member 'cr4' in struct vmcb_save_area
drivers/kvm/svm.c:619:45: error: no member 'save' in struct vmcb
drivers/kvm/svm.c:620:45: error: no member 'save' in struct vmcb
drivers/kvm/svm.c:621:29: error: no member 'save' in struct vmcb
drivers/kvm/svm.c:626:17: error: no member 'save' in struct vmcb
drivers/kvm/svm.c:627:17: error: no member 'save' in struct vmcb
drivers/kvm/svm.c:628:17: error: no member 'save' in struct vmcb
drivers/kvm/svm.c:633:24: error: no member 'save' in struct vmcb
drivers/kvm/svm.c:638:17: error: no member 'save' in struct vmcb
drivers/kvm/svm.c:643:48: error: no member 'save' in struct vmcb
drivers/kvm/svm.c:646:33: error: no member 'cs' in struct vmcb_save_area
drivers/kvm/svm.c:647:33: error: no member 'ds' in struct vmcb_save_area
drivers/kvm/svm.c:648:33: error: no member 'es' in struct vmcb_save_area
drivers/kvm/svm.c:649:33: error: no member 'fs' in struct vmcb_save_area
drivers/kvm/svm.c:650:33: error: no member 'gs' in struct vmcb_save_area
drivers/kvm/svm.c:651:33: error: no member 'ss' in struct vmcb_save_area
drivers/kvm/svm.c:652:33: error: no member 'tr' in struct vmcb_save_area
drivers/kvm/svm.c:653:35: error: no member 'ldtr' in struct vmcb_save_area
drivers/kvm/svm.c:663:10: error: no member 'base' in struct vmcb_seg
drivers/kvm/svm.c:671:15: error: no member 'base' in struct vmcb_seg
drivers/kvm/svm.c:672:16: error: no member 'limit' in struct vmcb_seg
drivers/kvm/svm.c:673:19: error: no member 'selector' in struct vmcb_seg
drivers/kvm/svm.c:674:15: error: no member 'attrib' in struct vmcb_seg
drivers/kvm/svm.c:675:13: error: no member 'attrib' in struct vmcb_seg
drivers/kvm/svm.c:676:15: error: no member 'attrib' in struct vmcb_seg
drivers/kvm/svm.c:677:19: error: no member 'attrib' in struct vmcb_seg
drivers/kvm/svm.c:678:15: error: no member 'attrib' in struct vmcb_seg
drivers/kvm/svm.c:679:13: error: no member 'attrib' in struct vmcb_seg
drivers/kvm/svm.c:680:14: error: no member 'attrib' in struct vmcb_seg
drivers/kvm/svm.c:681:13: error: no member 'attrib' in struct vmcb_seg
drivers/kvm/svm.c:689:10: error: too many errors
drivers/kvm/kvm_main.c:590:9: error: Trying to use reserved word '__attribute__' as identifier
drivers/kvm/kvm_main.c:590:38: error: Expected ; at end of declaration
drivers/kvm/kvm_main.c:590:38: error: got fx_image_s
drivers/kvm/kvm_main.c:602:14: error: Expected ) in function declarator
drivers/kvm/kvm_main.c:602:14: error: got ->
drivers/kvm/kvm_main.c:604:14: error: Expected ) in function declarator
drivers/kvm/kvm_main.c:604:14: error: got ->
drivers/kvm/kvm_main.c:605:17: error: Expected ) in function declarator
drivers/kvm/kvm_main.c:605:17: error: got ->
drivers/kvm/kvm_main.c:608:10: error: Expected ; at end of declaration
drivers/kvm/kvm_main.c:608:10: error: got ->
drivers/kvm/kvm_main.c:609:2: error: Expected ) in function declarator
drivers/kvm/kvm_main.c:609:2: error: got 0
drivers/kvm/kvm_main.c:611:1: error: Expected ; end of type declaration
drivers/kvm/kvm_main.c:611:1: error: got }
drivers/kvm/kvm_main.c:607:34: error: undefined identifier 'vcpu'
drivers/kvm/kvm_main.c:607:2: error: symbol 'fx_image' redeclared with different type (originally declared at drivers/kvm/kvm_main.c:600) - different base types
drivers/kvm/kvm_main.c:608:2: error: symbol 'fx_image' redeclared with different type (originally declared at drivers/kvm/kvm_main.c:600) - different base types



---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: more spewage (Re: sparse segfault on ppc64)

[Christopher Li]

On Fri, Mar 23, 2007 at 03:04:59PM -0700, Randy Dunlap wrote:
> There are also sparse error spewings on attributes((...)) that are
> not in the expected source code location.  Three examples:
> 
> 
> 1.  net/sched/cls_api.c, lines 593-611:
> 
> 	return 0;
> rtattr_failure: __attribute__ ((unused))
> 	return -1;
> }

I will submit a patch to fix that.


> 2.  in 2.6.21-rc4-mm1 only AFAIK, arch/x86_64/kernel/early-quirks.c, #79:
> 
> static struct __initdata chipset early_qrk[] = {
> 	{ PCI_VENDOR_ID_NVIDIA, nvidia_bugs },
> 	{ PCI_VENDOR_ID_VIA, via_bugs },
> 	{ PCI_VENDOR_ID_ATI, ati_bugs },
> 	{}
> };
> 
> spews:
> 
> arch/x86_64/kernel/early-quirks.c:79:15: error: Trying to use reserved word '__attribute__' as identifier
> arch/x86_64/kernel/early-quirks.c:79:15: error: Expected ) in function declarator
> arch/x86_64/kernel/early-quirks.c:79:15: error: got ".init.data"

I think this should be fixed in git tree.

commit 1db467c6263823a4301d181a10ed9cd7700fd11c
Author: Christopher Li <sparse@chrisli.org>
Date:   Wed Feb 14 12:15:49 2007 -0800

    Handle structure attributes between the structure keyword and the name
    
    struct __attribute__((__aligned__(16))) foo {
        int a;
    };
    

Chris

Re: more spewage (Re: sparse segfault on ppc64)

[Christopher Li]

On Sat, Mar 24, 2007 at 12:31:27AM +0100, Sam Ravnborg wrote:
> > 
> > static struct __initdata chipset early_qrk[] = {
> > 	{ PCI_VENDOR_ID_NVIDIA, nvidia_bugs },
> > 	{ PCI_VENDOR_ID_VIA, via_bugs },
> > 	{ PCI_VENDOR_ID_ATI, ati_bugs },
> > 	{}
> > };
> In this case it is only good that sparse complains because the
> __initdata is not placed right before the variable name as it should be.
>

It has different meanings. If it place before the struct.
The attribute only apply to early_qrk.

If it is place between the struct and name. Declaration using
struct chipset later will get the attribute.

Chris
 

[PATCH] Fix the annotated inline call position

[Christopher Li]

Here is some diff comparing output between the sparse 0.2 and the tip of git.

-mm/mmap.c:1631:2: warning: context imbalance in 'expand_stack' - different lock
 contexts for basic block
+include/linux/rmap.h:55:2: warning: context imbalance in 'expand_stack' - diffe

The change is introduced by the inline annotate instruction,
which mark the bb->pos to the inline function.

This change make it back to the caller position.

Signed-Off-By: Christopher Li <sparse@chrisli.org>

Index: sparse/linearize.c
===================================================================
--- sparse.orig/linearize.c	2007-03-22 14:11:40.000000000 -0700
+++ sparse/linearize.c	2007-03-23 13:15:28.000000000 -0700
@@ -1650,6 +1650,7 @@ static pseudo_t linearize_inlined_call(s
 {
 	struct instruction *insn = alloc_instruction(OP_INLINED_CALL, 0);
 	struct statement *args = stmt->args;
+	struct basic_block *bb;
 	pseudo_t pseudo;
 
 	if (args) {
@@ -1664,6 +1665,9 @@ static pseudo_t linearize_inlined_call(s
 
 	insn->target = pseudo = linearize_compound_statement(ep, stmt);
 	use_pseudo(insn, symbol_pseudo(ep, stmt->inline_fn), &insn->func);
+	bb = ep->active;
+	if (bb && !bb->insns)
+		bb->pos = stmt->pos;
 	add_one_insn(ep, insn);
 	return pseudo;
 }

[PATCH] handle label attributes

[Christopher Li]

On Fri, Mar 23, 2007 at 03:04:59PM -0700, Randy Dunlap wrote:
> 1.  net/sched/cls_api.c, lines 593-611:
> 
> 	return 0;
> rtattr_failure: __attribute__ ((unused))
> 	return -1;
> }


Singed-Off-By: Christopher Li<sparse@chrisli.org>

Index: sparse/parse.c
===================================================================
--- sparse.orig/parse.c	2007-03-23 16:09:39.000000000 -0700
+++ sparse/parse.c	2007-03-23 16:10:00.000000000 -0700
@@ -1701,7 +1701,8 @@ static struct token *statement(struct to
 		if (match_op(token->next, ':')) {
 			stmt->type = STMT_LABEL;
 			stmt->label_identifier = label_symbol(token);
-			return statement(token->next->next, &stmt->label_statement);
+			token = handle_attributes(token->next->next, &stmt->label_identifier->ctype);
+			return statement(token, &stmt->label_statement);
 		}
 	}
 
Index: sparse/validation/label-attr.c
===================================================================
--- sparse.orig/validation/label-attr.c	2007-03-23 16:10:00.000000000 -0700
+++ sparse/validation/label-attr.c	2007-03-23 16:10:00.000000000 -0700
@@ -0,0 +1,6 @@
+int foo(void)
+{
+       return 0;
+rtattr_failure: __attribute__ ((unused))
+       return -1;
+}

[PATCH] vector parsing (take II)

[Christopher Li]

Any one want to try this patch on PowerPC for vector
support? I surely don't have one.

Chris


Sparse will take "-maltivec" into account and turn on
vector parsing accordingly.

Signed-Off-By: Christopher Li <sparse@chrisli.org>

Index: sparse/symbol.c
===================================================================
--- sparse.orig/symbol.c	2007-03-23 12:45:11.000000000 -0700
+++ sparse/symbol.c	2007-03-23 13:48:02.000000000 -0700
@@ -425,6 +425,9 @@ struct symbol *examine_symbol_type(struc
 	case SYM_FOULED:
 		examine_base_type(sym);
 		return sym;
+	case SYM_VECTOR:
+		examine_base_type(sym);
+		return sym;
 	default:
 		sparse_error(sym->pos, "Examining unknown symbol type %d", sym->type);
 		break;
Index: sparse/parse.c
===================================================================
--- sparse.orig/parse.c	2007-03-23 12:45:11.000000000 -0700
+++ sparse/parse.c	2007-03-23 15:33:28.000000000 -0700
@@ -34,6 +34,9 @@ static struct symbol_list **function_sym
 struct symbol_list *function_computed_target_list;
 struct statement_list *function_computed_goto_list;
 
+static struct symbol *alloc_indirect_symbol(struct position pos, struct ctype *ctype, int type);
+static struct token *declaration_specifiers(struct token *next, struct ctype *ctype, int qual);
+
 static struct token *statement(struct token *token, struct statement **tree);
 static struct token *handle_attributes(struct token *token, struct ctype *ctype);
 
@@ -42,6 +45,7 @@ static struct token *union_specifier(str
 static struct token *enum_specifier(struct token *token, struct ctype *ctype);
 static struct token *attribute_specifier(struct token *token, struct ctype *ctype);
 static struct token *typeof_specifier(struct token *token, struct ctype *ctype);
+static struct token *vector_specifier(struct token *token, struct ctype *ctype);
 
 static struct token *parse_if_statement(struct token *token, struct statement *stmt);
 static struct token *parse_return_statement(struct token *token, struct statement *stmt);
@@ -103,6 +107,9 @@ static struct symbol_op enum_op = {
 	.declarator = enum_specifier,
 };
 
+static struct symbol_op vector_op = {
+	.declarator = vector_specifier,
+};
 
 
 static struct symbol_op if_op = {
@@ -225,6 +232,8 @@ static struct init_keyword {
 	{ "union", 	NS_TYPEDEF, .op = &union_op },
 	{ "enum", 	NS_TYPEDEF, .op = &enum_op },
 
+	{ "vector", 	NS_TYPEDEF, .op = &vector_op },
+
 	{ "inline",	NS_TYPEDEF, MOD_INLINE, .op = &modifier_op },
 	{ "__inline",	NS_TYPEDEF, MOD_INLINE, .op = &modifier_op },
 	{ "__inline__",	NS_TYPEDEF, MOD_INLINE, .op = &modifier_op },
@@ -382,6 +391,7 @@ static int apply_modifiers(struct positi
 		case SYM_ARRAY:
 		case SYM_BITFIELD:
 		case SYM_PTR:
+		case SYM_VECTOR:
 			ctype = &base->ctype;
 			continue;
 		}
@@ -720,6 +730,21 @@ static struct token *enum_specifier(stru
 	return ret;
 }
 
+static struct token *vector_specifier(struct token *token, struct ctype *ctype)
+{
+	struct token *next;
+	struct symbol *vector;
+
+	if (!maltivec)
+		return NULL;
+
+	next = declaration_specifiers(token, ctype, 0);
+	vector = alloc_indirect_symbol(token->pos, ctype, SYM_VECTOR);
+	vector->bit_size = bits_in_vector;
+	vector->ctype.alignment = vector_alignment;
+	return next;
+}
+
 static struct token *typeof_specifier(struct token *token, struct ctype *ctype)
 {
 	struct symbol *sym;
@@ -1046,6 +1071,8 @@ static struct token *declaration_specifi
 		}
 		if (s->type == SYM_KEYWORD && s->op->declarator) {
 			next = s->op->declarator(next, &thistype);
+			if (!next)
+				break;
 			mod = thistype.modifiers;
 		}
 		type = thistype.base_type;
Index: sparse/symbol.h
===================================================================
--- sparse.orig/symbol.h	2007-03-23 12:45:11.000000000 -0700
+++ sparse/symbol.h	2007-03-23 13:48:02.000000000 -0700
@@ -54,6 +54,7 @@ enum type {
 	SYM_LABEL,
 	SYM_RESTRICT,
 	SYM_FOULED,
+	SYM_VECTOR,
 	SYM_KEYWORD,
 	SYM_BAD,
 };
@@ -178,7 +179,8 @@ struct symbol {
 #define MOD_LONG	0x0400
 #define MOD_LONGLONG	0x0800
 
-#define MOD_TYPEDEF	0x1000
+#define MOD_VECTOR	0x1000
+#define MOD_TYPEDEF	0x2000
 
 #define MOD_INLINE	0x40000
 #define MOD_ADDRESSABLE	0x80000
Index: sparse/lib.c
===================================================================
--- sparse.orig/lib.c	2007-03-22 14:11:40.000000000 -0700
+++ sparse/lib.c	2007-03-23 15:29:44.000000000 -0700
@@ -208,6 +208,8 @@ int Wuninitialized = 1;
 int dbg_entry = 0;
 int dbg_dead = 0;
 
+int maltivec = 0;
+
 int preprocess_only;
 char *include;
 
@@ -321,6 +323,9 @@ static char **handle_switch_m(char *arg,
 		max_int_alignment = 8;
 		bits_in_pointer = 64;
 		pointer_alignment = 8;
+	} else if (!strcmp(arg, "maltivec")) {
+		maltivec = 1;
+		add_pre_buffer("#define __VEC__\n");
 	}
 	return next;
 }
Index: sparse/target.h
===================================================================
--- sparse.orig/target.h	2006-12-05 16:17:39.000000000 -0800
+++ sparse/target.h	2007-03-23 14:53:26.000000000 -0700
@@ -42,4 +42,10 @@ extern int pointer_alignment;
 extern int bits_in_enum;
 extern int enum_alignment;
 
+/*
+ * Vector data types.
+ */
+extern int bits_in_vector;
+extern int vector_alignment;
+
 #endif
Index: sparse/expression.h
===================================================================
Index: sparse/evaluate.c
===================================================================
--- sparse.orig/evaluate.c	2007-03-23 12:45:11.000000000 -0700
+++ sparse/evaluate.c	2007-03-23 13:48:02.000000000 -0700
@@ -349,6 +349,7 @@ enum {
 	TYPE_PTR = 16,
 	TYPE_COMPOUND = 32,
 	TYPE_FOULED = 64,
+	TYPE_VECTOR = 128,
 };
 
 static inline int classify_type(struct symbol *type, struct symbol **base)
@@ -362,6 +363,7 @@ static inline int classify_type(struct s
 		[SYM_BITFIELD] = TYPE_NUM | TYPE_BITFIELD,
 		[SYM_RESTRICT] = TYPE_NUM | TYPE_RESTRICT,
 		[SYM_FOULED] = TYPE_NUM | TYPE_RESTRICT | TYPE_FOULED,
+		[SYM_VECTOR] = TYPE_VECTOR | TYPE_NUM, 
 	};
 	if (type->type == SYM_NODE)
 		type = type->ctype.base_type;
@@ -556,6 +558,9 @@ static struct symbol *evaluate_arith(str
 	if (!(lclass & rclass & TYPE_NUM))
 		goto Bad;
 
+	if ((lclass ^ rclass) & TYPE_VECTOR)
+		goto Bad;
+
 	if (!float_ok && (lclass | rclass) & TYPE_FLOAT)
 		goto Bad;
 
@@ -2086,6 +2091,7 @@ static void evaluate_initializer(struct 
 		switch (ctype->type) {
 		case SYM_ARRAY:
 		case SYM_PTR:
+		case SYM_VECTOR:
 			evaluate_array_initializer(get_base_type(ctype), expr);
 			return;
 		case SYM_UNION:
Index: sparse/target.c
===================================================================
--- sparse.orig/target.c	2006-12-05 16:17:39.000000000 -0800
+++ sparse/target.c	2007-03-23 14:51:51.000000000 -0700
@@ -43,3 +43,10 @@ int pointer_alignment = 4;
  */
 int bits_in_enum = 32;
 int enum_alignment = 4;
+
+/*
+ * Vector data types.
+ */
+int bits_in_vector = 128;
+int vector_alignment = 16;
+
Index: sparse/lib.h
===================================================================
--- sparse.orig/lib.h	2007-03-22 14:11:40.000000000 -0700
+++ sparse/lib.h	2007-03-23 14:50:04.000000000 -0700
@@ -99,6 +99,8 @@ extern int Wcast_truncate;
 extern int Wdo_while;
 extern int Wuninitialized;
 
+extern int maltivec;
+
 extern int dbg_entry;
 extern int dbg_dead;
 
Index: sparse/validation/vector2.c
===================================================================
--- sparse.orig/validation/vector2.c	2007-03-23 13:48:01.000000000 -0700
+++ sparse/validation/vector2.c	2007-03-23 15:19:11.000000000 -0700
@@ -0,0 +1,10 @@
+
+typedef vector signed char unative_t;
+
+int vector;
+
+#define NBYTES(x) ((vector signed char) {x,x,x,x, x,x,x,x, x,x,x,x, x,x,x,x})
+#define NSIZE	sizeof(unative_t)
+
+unative_t zv = NBYTES(0);
+
Index: sparse/validation/vector3.c
===================================================================
--- sparse.orig/validation/vector3.c	2007-03-23 15:19:34.000000000 -0700
+++ sparse/validation/vector3.c	2007-03-23 15:19:47.000000000 -0700
@@ -0,0 +1,2 @@
+int vector;
+
Index: sparse/validation/vector.c
===================================================================
--- sparse.orig/validation/vector.c	2007-03-23 13:48:01.000000000 -0700
+++ sparse/validation/vector.c	2007-03-23 15:41:32.000000000 -0700
@@ -0,0 +1,33 @@
+#ifndef __VEC__
+#error Use "-maltivec" flag to enable PowerPC AltiVec support.
+#endif
+
+typedef vector signed char unative_t;
+
+#define NBYTES(x) ((vector signed char) {x,x,x,x, x,x,x,x, x,x,x,x, x,x,x,x})
+#define NSIZE	sizeof(unative_t)
+
+#define __attribute_const__		__attribute__((__const__))
+
+extern unative_t vec_add(unative_t a, unative_t b);
+extern unative_t vec_cmpgt(unative_t a, unative_t b);
+
+static inline __attribute_const__ unative_t SHLBYTE(unative_t v)
+{
+	return vec_add(v,v);
+}
+
+static inline __attribute_const__ unative_t MASK(unative_t v)
+{
+	unative_t zv = NBYTES(0);
+
+	/* vec_cmpgt returns a vector bool char; thus the need for the cast */
+	return (unative_t)vec_cmpgt(zv, v);
+}
+
+unative_t foo(void)
+{
+	unative_t i = NBYTES(1);
+	return SHLBYTE(i) + MASK(i);
+}
+

Re: more spewage (Re: sparse segfault on ppc64)

[Sam Ravnborg]

> 1.  net/sched/cls_api.c, lines 593-611:
> 
> 	return 0;
> rtattr_failure: __attribute__ ((unused))
> 	return -1;
> }
> 
> ...
> 
> 	return 0;
> rtattr_failure: __attribute__ ((unused))
> 	return -1;
> }
> 
> These spew:
> 
> net/sched/cls_api.c:593:17: error: typename in expression
> net/sched/cls_api.c:594:2: error: Expected ; at end of statement
> net/sched/cls_api.c:594:2: error: got return
> net/sched/cls_api.c:611:17: error: typename in expression
> net/sched/cls_api.c:612:2: error: Expected ; at end of statement
> net/sched/cls_api.c:612:2: error: got return
> net/sched/cls_api.c:593:17: error: undefined identifier '__attribute__'
> net/sched/cls_api.c:611:17: error: undefined identifier '__attribute__'
> 
> 
> 2.  in 2.6.21-rc4-mm1 only AFAIK, arch/x86_64/kernel/early-quirks.c, #79:
> 
> static struct __initdata chipset early_qrk[] = {
> 	{ PCI_VENDOR_ID_NVIDIA, nvidia_bugs },
> 	{ PCI_VENDOR_ID_VIA, via_bugs },
> 	{ PCI_VENDOR_ID_ATI, ati_bugs },
> 	{}
> };
In this case it is only good that sparse complains because the
__initdata is not placed right before the variable name as it should be.

You could argue that the error from sparse could be better but
it is preferable to have consistent style over the kernel.

	Sam

Re: more spewage (Re: sparse segfault on ppc64)

[Randy Dunlap]

On Sat, 24 Mar 2007 00:31:27 +0100 Sam Ravnborg wrote:

> > 1.  net/sched/cls_api.c, lines 593-611:
> > 
> > 	return 0;
> > rtattr_failure: __attribute__ ((unused))
> > 	return -1;
> > }
> > 
> > ...
> > 
> > 	return 0;
> > rtattr_failure: __attribute__ ((unused))
> > 	return -1;
> > }
> > 
> > These spew:
> > 
> > net/sched/cls_api.c:593:17: error: typename in expression
> > net/sched/cls_api.c:594:2: error: Expected ; at end of statement
> > net/sched/cls_api.c:594:2: error: got return
> > net/sched/cls_api.c:611:17: error: typename in expression
> > net/sched/cls_api.c:612:2: error: Expected ; at end of statement
> > net/sched/cls_api.c:612:2: error: got return
> > net/sched/cls_api.c:593:17: error: undefined identifier '__attribute__'
> > net/sched/cls_api.c:611:17: error: undefined identifier '__attribute__'
> > 
> > 
> > 2.  in 2.6.21-rc4-mm1 only AFAIK, arch/x86_64/kernel/early-quirks.c, #79:
> > 
> > static struct __initdata chipset early_qrk[] = {
> > 	{ PCI_VENDOR_ID_NVIDIA, nvidia_bugs },
> > 	{ PCI_VENDOR_ID_VIA, via_bugs },
> > 	{ PCI_VENDOR_ID_ATI, ati_bugs },
> > 	{}
> > };
> In this case it is only good that sparse complains because the
> __initdata is not placed right before the variable name as it should be.

That one is quite ugly IMO.  I'm surprised that a compiler
parses it.

> You could argue that the error from sparse could be better but
> it is preferable to have consistent style over the kernel.

I lean more towards "is it valid C or not"?

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: more spewage (Re: sparse segfault on ppc64)

[Sam Ravnborg]

> 
> > You could argue that the error from sparse could be better but
> > it is preferable to have consistent style over the kernel.
> 
> I lean more towards "is it valid C or not"?
I thought all the attribute() stuff was purely gcc extensions.

	Sam

Re: more spewage (Re: sparse segfault on ppc64)

[Randy Dunlap]

On Sat, 24 Mar 2007 07:44:56 +0100 Sam Ravnborg wrote:

> > 
> > > You could argue that the error from sparse could be better but
> > > it is preferable to have consistent style over the kernel.
> > 
> > I lean more towards "is it valid C or not"?
> I thought all the attribute() stuff was purely gcc extensions.

That's probably correct.  I should have said something more like
"is it accepted by a widely-used C compiler or not".  :)

But I would not complain if sparse just read & ignored the
attributes (rather than throwing errors on them).

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: more spewage (Re: sparse segfault on ppc64)

[Linus Torvalds]

On Sat, 24 Mar 2007, Randy Dunlap wrote:
> 
> But I would not complain if sparse just read & ignored the
> attributes (rather than throwing errors on them).

Well, sparse is often also an "arbiter of good taste".

"Technically correct" or "..but gcc accepts it" are secondary to "does the 
source make sense".

For example, gcc accepts a *lot* of insanity when it comes to attributes 
in odd places. That doesn't necessarily mean that sparse should accept it.

And any C compiler will accept

	void *ptr = 0;

and that doesn't mean that sparse should accept that mind-boggling bug in 
the C standard. Yes, the zero constant is a special pointer, but it's 
special when cast to a pointer type, not when used as a integer. And the 
fact that the C standard disagrees with me just means that the C standard 
is wrong.

So I don't think sparse should necessarily accept crap code just because 
(a) gcc accepts it and (b) there is some crap code in the kernel that uses 
it. That "__attribute__((unused))" on a label seems to be exactly that 
kind of horror. It's not like it's any prettier than tons of *valid* ways 
to do the same (for example, using the C preprocessor).

			Linus

Re: [PATCH] handle label attributes

[Randy Dunlap]

On Fri, 23 Mar 2007 16:10:08 -0700 Christopher Li wrote:

> On Fri, Mar 23, 2007 at 03:04:59PM -0700, Randy Dunlap wrote:
> > 1.  net/sched/cls_api.c, lines 593-611:
> > 
> > 	return 0;
> > rtattr_failure: __attribute__ ((unused))
> > 	return -1;
> > }
> 
> 
> Singed-Off-By: Christopher Li<sparse@chrisli.org>

Hi,
Yes, that does handle the label attributes cleanly.

Thanks.

> Index: sparse/parse.c
> ===================================================================
> --- sparse.orig/parse.c	2007-03-23 16:09:39.000000000 -0700
> +++ sparse/parse.c	2007-03-23 16:10:00.000000000 -0700
> @@ -1701,7 +1701,8 @@ static struct token *statement(struct to
>  		if (match_op(token->next, ':')) {
>  			stmt->type = STMT_LABEL;
>  			stmt->label_identifier = label_symbol(token);
> -			return statement(token->next->next, &stmt->label_statement);
> +			token = handle_attributes(token->next->next, &stmt->label_identifier->ctype);
> +			return statement(token, &stmt->label_statement);
>  		}
>  	}
>  
> Index: sparse/validation/label-attr.c
> ===================================================================
> --- sparse.orig/validation/label-attr.c	2007-03-23 16:10:00.000000000 -0700
> +++ sparse/validation/label-attr.c	2007-03-23 16:10:00.000000000 -0700
> @@ -0,0 +1,6 @@
> +int foo(void)
> +{
> +       return 0;
> +rtattr_failure: __attribute__ ((unused))
> +       return -1;
> +}
> 


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: more spewage (Re: sparse segfault on ppc64)

[Christopher Li]

On Sat, Mar 24, 2007 at 10:02:22AM -0700, Linus Torvalds wrote:
> 
> Well, sparse is often also an "arbiter of good taste".
> 
> "Technically correct" or "..but gcc accepts it" are secondary to "does the 
> source make sense".
> 
> For example, gcc accepts a *lot* of insanity when it comes to attributes 
> in odd places. That doesn't necessarily mean that sparse should accept it.

Points taken.  Sparse can parse it and warn about it. It is still better than
the obscure parser error from sparse.

Chris

Re: more spewage (Re: sparse segfault on ppc64)

[Randy Dunlap]

On Mon, 26 Mar 2007 11:07:41 -0700 Christopher Li wrote:

> On Sat, Mar 24, 2007 at 10:02:22AM -0700, Linus Torvalds wrote:
> > 
> > Well, sparse is often also an "arbiter of good taste".
> > 
> > "Technically correct" or "..but gcc accepts it" are secondary to "does the 
> > source make sense".
> > 
> > For example, gcc accepts a *lot* of insanity when it comes to attributes 
> > in odd places. That doesn't necessarily mean that sparse should accept it.
> 
> Points taken. 

Ack.

> Sparse can parse it and warn about it. It is still better than
> the obscure parser error from sparse.

Yes, thanks.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: [PATCH] Fix the annotated inline call position

[Josh Triplett]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

Christopher Li wrote:
> Here is some diff comparing output between the sparse 0.2 and the tip of git.
> 
> -mm/mmap.c:1631:2: warning: context imbalance in 'expand_stack' - different lock
>  contexts for basic block
> +include/linux/rmap.h:55:2: warning: context imbalance in 'expand_stack' - diffe
> 
> The change is introduced by the inline annotate instruction,
> which mark the bb->pos to the inline function.
> 
> This change make it back to the caller position.

Applied, thanks.

- Josh Triplett



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [PATCH] handle label attributes

[Josh Triplett]

[-- Attachment #1: Type: text/plain, Size: 491 bytes --]

Christopher Li wrote:
> On Fri, Mar 23, 2007 at 03:04:59PM -0700, Randy Dunlap wrote:
>> 1.  net/sched/cls_api.c, lines 593-611:
>>
>> 	return 0;
>> rtattr_failure: __attribute__ ((unused))
>> 	return -1;
>> }

Applied, with the minor change of making the function in the new test case
static to avoid an unrelated warning with -Wdecl.

> Singed-Off-By: Christopher Li<sparse@chrisli.org>

And just what sound *does* a patch make when you sing it off? :)

- Josh Triplett


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]