Skip to contentSkip to conversation

sparse segfault on ppc64.

PATCH New Dave Jones 7 participants 27 messages Mar 22, 2007 – Apr 20, 2007 Sparse checker

lore
Share & tools
lore

Dave Jones

author
#0 lore raw

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

Signature · 1 line
http://www.codemonkey.org.uk
#1 lore raw
Quoted 2 lines · Dave Jones

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.

maintainer
#2 lore raw
Quoted 5 lines · Al Viro

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

maintainer
#25 lore raw

PATCH 1/1 vector parsing, was Re: sparse segfault on ppc64.

In reply to Dave Jones
Quoted 1 line

/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 <[email protected]>
parse.c +12 -0
Index: sparse/parse.c
===================================================================
@@ -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;
 }
symbol.h +3 -1
Index: sparse/symbol.h
===================================================================
@@ -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
evaluate.c +6 -0
Index: sparse/evaluate.c
===================================================================
@@ -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:
validation/vector.c +30 -0
Index: sparse/validation/vector.c
===================================================================
@@ -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);
+}
+
#3 lore raw
In reply to Christopher Li
Quoted 7 lines · Christopher Li
Quoted 5 lines · Al Viro

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.

Quoted 6 lines

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...

author
#23 lore raw
In reply to Al Viro
Quoted 6 lines · Al Viro
Quoted 2 lines · Dave Jones

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

Signature · 1 line
http://www.codemonkey.org.uk
#24 lore raw
Quoted 9 lines · Dave Jones
Quoted 6 lines · Al Viro
Quoted 2 lines · Dave Jones

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...

author
#7 lore raw
In reply to Christopher Li
Quoted 11 lines · Christopher Li
Quoted 5 lines · Al Viro

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

Signature · 1 line
http://www.codemonkey.org.uk
author
#8 lore raw
In reply to Christopher Li
Quoted 7 lines · Christopher Li
Quoted 5 lines · Al Viro

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.

Quoted 6 lines

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'

Signature · 1 line
http://www.codemonkey.org.uk
maintainer
#9 lore raw
Quoted 8 lines · Dave Jones

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

maintainer
#4 lore raw
In reply to Al Viro
Quoted 5 lines · Al Viro

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.

Quoted 2 lines

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

#10 lore raw

more spewage (Re: sparse segfault on ppc64)

In reply to Christopher Li
Quoted 4 lines · On Thu, 22 Mar 2007 15:10:51 -0700 Christopher Li wrote:
Quoted 3 lines · Dave Jones

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

Quoted 8 lines
Quoted 5 lines

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 ***

#11 lore raw

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

Quoted 26 lines

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__'

Quoted 8 lines

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

maintainer
#19 lore raw

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

In reply to Randy Dunlap
Quoted 10 lines · Randy Dunlap

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.

Quoted 9 lines

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 },
{}
};

Quoted 5 lines

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 <[email protected]>
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

maintainer
#12 lore raw

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

In reply to Sam Ravnborg
Quoted 10 lines · Sam Ravnborg
Quoted 7 lines

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

#13 lore raw

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

In reply to Sam Ravnborg
Quoted 28 lines · On Sat, 24 Mar 2007 00:31:27 +0100 Sam Ravnborg wrote:
Quoted 28 lines

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:

Quoted 8 lines
Quoted 6 lines

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.

Quoted 2 lines

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 ***

maintainer
#5 lore raw

PATCH 1/1 Fix the annotated inline call position

In reply to Al Viro

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 <[email protected]>
linearize.c +4 -0
Index: sparse/linearize.c
===================================================================
@@ -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;
 }
maintainer
#20 lore raw

PATCH 1/1 handle label attributes

In reply to Randy Dunlap
Quoted 6 lines · Randy Dunlap

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

	return 0;
rtattr_failure: __attribute__ ((unused))
	return -1;
}
Singed-Off-By Christopher Li<[email protected]>
parse.c +2 -1
Index: sparse/parse.c
===================================================================
@@ -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);
 		}
 	}
validation/label-attr.c +6 -0
Index: sparse/validation/label-attr.c
===================================================================
@@ -0,0 +1,6 @@
+int foo(void)
+{
+       return 0;
+rtattr_failure: __attribute__ ((unused))
+       return -1;
+}
maintainer
#26 lore raw

PATCH 1/1 vector parsing (take II)

In reply to 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 <[email protected]>
symbol.c +3 -0
Index: sparse/symbol.c
===================================================================
@@ -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;
parse.c +27 -0
Index: sparse/parse.c
===================================================================
@@ -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;
symbol.h +3 -1
Index: sparse/symbol.h
===================================================================
@@ -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
lib.c +5 -0
Index: sparse/lib.c
===================================================================
@@ -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;
 }
target.h +6 -0
Index: sparse/target.h
===================================================================
@@ -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
===================================================================

evaluate.c +6 -0
Index: sparse/evaluate.c
===================================================================
@@ -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:
target.c +7 -0
Index: sparse/target.c
===================================================================
@@ -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;
+
lib.h +2 -0
Index: sparse/lib.h
===================================================================
@@ -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;
validation/vector2.c +10 -0
Index: sparse/validation/vector2.c
===================================================================
@@ -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);
+
validation/vector3.c +2 -0
Index: sparse/validation/vector3.c
===================================================================
@@ -0,0 +1,2 @@
+int vector;
+
validation/vector.c +33 -0
Index: sparse/validation/vector.c
===================================================================
@@ -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);
+}
+
#14 lore raw

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

In reply to Randy Dunlap
Quoted 5 lines
Quoted 3 lines

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

#15 lore raw

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

Quoted 6 lines · On Sat, 24 Mar 2007 07:44:56 +0100 Sam Ravnborg wrote:
Quoted 5 lines
Quoted 3 lines

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 ***

#16 lore raw

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

Quoted 3 lines · Randy Dunlap

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

#21 lore raw

Re: [PATCH] handle label attributes

In reply to Christopher Li
Quoted 10 lines · On Fri, 23 Mar 2007 16:10:08 -0700 Christopher Li wrote:
Quoted 6 lines · Randy Dunlap

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

	return 0;
rtattr_failure: __attribute__ ((unused))
	return -1;
}
Singed-Off-By Christopher Li<[email protected]>

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

Thanks.

Quoted 20 lines

Index: sparse/parse.c
===================================================================

parse.c +2 -1
@@ -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
===================================================================

validation/label-attr.c line 6

Quoted 6 lines
validation/label-attr.c +6 -0
@@ -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 ***

maintainer
#17 lore raw

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

In reply to Linus Torvalds
Quoted 8 lines · Linus Torvalds

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

#18 lore raw

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

Quoted 11 lines · On Mon, 26 Mar 2007 11:07:41 -0700 Christopher Li wrote:
Quoted 8 lines · Linus Torvalds

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.

Quoted 2 lines

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 ***

Applied
#6 lore raw

Re: [PATCH] Fix the annotated inline call position

In reply to Christopher Li
Quoted 10 lines · Christopher Li

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

(quoted diff) +1 -1
-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

#22 lore raw

Re: [PATCH] handle label attributes

In reply to Christopher Li
Quoted 7 lines · Christopher Li
Quoted 6 lines · Randy Dunlap

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.

Quoted 1 line
Singed-Off-By Christopher Li<[email protected]>

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

- Josh Triplett