* Bug#873508: sparse test failures on ppc32le (and other not so common archs)
[not found] <150392922734.24087.13050909898214597041.reportbug@curie.anarc.at>
@ 2017-08-30 16:14 ` Uwe Kleine-König
2017-08-30 16:55 ` Ramsay Jones
2017-09-01 11:33 ` Bug#873508: sparse test failures on ppc32le (and other not so common archs) Antoine Beaupré
` (9 subsequent siblings)
10 siblings, 1 reply; 55+ messages in thread
From: Uwe Kleine-König @ 2017-08-30 16:14 UTC (permalink / raw)
To: linux-sparse; +Cc: 873508, Antoine Beaupre
[-- Attachment #1: Type: text/plain, Size: 52666 bytes --]
Hello,
Antoine Beaupre (on Cc:) noticed that sparse doesn't work on some not so
common architectures like ppc32le, s390x, ppc64 and sparc64[1]. This is
nicely catched by the testsuite, e.g.:
ukleinek@plummer:~/sparse$ git rev-parse HEAD
958c11c35d98417eb6b948bffe2dffed14eb3320
ukleinek@plummer:~/sparse$ uname -a
Linux plummer 4.9.0-3-powerpc64le #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) ppc64le GNU/Linux
ukleinek@plummer:~/sparse$ make check V=1
cd validation && ./test-suite
TEST Woverride-init-def (Woverride-init-def.c)
Using command : ../sparse Woverride-init-def.c
Expecting exit value: 0
TEST Woverride-init-no (Woverride-init-no.c)
Using command : ../sparse -Wno-override-init Woverride-init-no.c
Expecting exit value: 0
TEST Woverride-init-yes (Woverride-init-yes.c)
Using command : ../sparse -Woverride-init Woverride-init-yes.c
Expecting exit value: 0
TEST warn-unknown-attribute (Wunknown-attribute-def.c)
Using command : ../sparse Wunknown-attribute-def.c
Expecting exit value: 0
TEST warn-unknown-attribute-no (Wunknown-attribute-no.c)
Using command : ../sparse -Wno-unknown-attribute Wunknown-attribute-no.c
Expecting exit value: 0
TEST warn-unknown-attribute-yes (Wunknown-attribute-yes.c)
Using command : ../sparse -Wunknown-attribute Wunknown-attribute-yes.c
Expecting exit value: 0
TEST __func__ (__func__.c)
Using command : ../sparse -Wall __func__.c
Expecting exit value: 0
TEST abstract array declarator static (abstract-array-declarator-static.c)
Using command : ../sparse abstract-array-declarator-static.c
Expecting exit value: 0
TEST address_space attribute (address_space.c)
Using command : ../sparse address_space.c
Expecting exit value: 0
TEST alias distinct symbols (alias-distinct.c)
Using command : ../test-linearize alias-distinct.c
Expecting exit value: 0
TEST alias symbol/pointer (alias-mixed.c)
Using command : ../test-linearize alias-mixed.c
Expecting exit value: 0
TEST alias same symbols (alias-same.c)
Using command : ../test-linearize alias-same.c
Expecting exit value: 0
TEST attribute __alloc_align__ (alloc-align.c)
Using command : ../sparse alloc-align.c
Expecting exit value: 0
TEST alternate keywords (alternate-keywords.c)
Using command : ../sparse alternate-keywords.c
Expecting exit value: 0
TEST test anonymous union initializer (anon-union.c)
Using command : ../sparse anon-union.c
Expecting exit value: 0
TEST Asm with goto labels. (asm-empty-clobber.c)
Using command : ../sparse asm-empty-clobber.c
Expecting exit value: 0
TEST Asm with goto labels. (asm-goto-lables.c)
Using command : ../sparse asm-goto-lables.c
Expecting exit value: 0
TEST asm-toplevel.c (asm-toplevel.c)
Using command : ../test-linearize asm-toplevel.c
Expecting exit value: 0
TEST inline attributes (attr-inline.c)
Using command : ../sparse attr-inline.c
Expecting exit value: 0
TEST attribute no_sanitize_address (attr-no_sanitize_address.c)
Using command : ../sparse attr-no_sanitize_address.c
Expecting exit value: 0
TEST attribute noclone (attr-noclone.c)
Using command : ../sparse attr-noclone.c
Expecting exit value: 0
TEST optimize attributes (attr-optimize.c)
Using command : ../sparse attr-optimize.c
Expecting exit value: 0
TEST attribute warning (attr-warning.c)
Using command : ../sparse attr-warning.c
Expecting exit value: 0
TEST attribute assume_aligned (attr_aligned.c)
Using command : ../sparse attr_aligned.c
Expecting exit value: 0
TEST attribute after ( in direct-declarator (attr_in_parameter.c)
Using command : ../sparse attr_in_parameter.c
Expecting exit value: 0
TEST attribute vector_size (attr_vector_size.c)
Using command : ../sparse attr_vector_size.c
Expecting exit value: 0
TEST Arithmetic operator code generation (backend/arithmetic-ops.c)
Using command : ../sparsec -c backend/arithmetic-ops.c -o tmp.o
Expecting exit value: 0
error: actual error text does not match expected error text.
error: see backend/arithmetic-ops.c.error.* for further investigation.
--- backend/arithmetic-ops.c.error.expected 2017-08-30 16:02:05.100096386 +0000
+++ backend/arithmetic-ops.c.error.got 2017-08-30 16:02:05.096096330 +0000
@@ -0,0 +1,10 @@
+{standard input}: Assembler messages:
+{standard input}:38: Error: unrecognized opcode: `xsaddsp'
+{standard input}:52: Error: unrecognized opcode: `xsadddp'
+{standard input}:94: Error: unrecognized opcode: `xssubsp'
+{standard input}:108: Error: unrecognized opcode: `xssubdp'
+{standard input}:150: Error: unrecognized opcode: `xsmulsp'
+{standard input}:164: Error: unrecognized opcode: `xsmuldp'
+{standard input}:206: Error: unrecognized opcode: `xsdivsp'
+{standard input}:220: Error: unrecognized opcode: `xsdivdp'
+mv: cannot stat '/tmp/tmp.RyRzUr.o': No such file or directory
TEST Array code generation (backend/array.c)
Using command : ../sparsec -c backend/array.c -o tmp.o
Expecting exit value: 0
TEST Bitwise operator code generation (backend/bitwise-ops.c)
Using command : ../sparsec -c backend/bitwise-ops.c -o tmp.o
Expecting exit value: 0
TEST Boolean type code generation (backend/bool-test.c)
Using command : ../sparsec -c backend/bool-test.c -o tmp.o
Expecting exit value: 0
TEST Cast code generation (backend/cast.c)
Using command : ../sparsec -c backend/cast.c -o tmp.o
Expecting exit value: 0
TEST Comparison operator code generation (backend/cmp-ops.c)
Using command : ../sparsec -c backend/cmp-ops.c -o tmp.o
Expecting exit value: 0
error: actual error text does not match expected error text.
error: see backend/cmp-ops.c.error.* for further investigation.
--- backend/cmp-ops.c.error.expected 2017-08-30 16:02:05.392100473 +0000
+++ backend/cmp-ops.c.error.got 2017-08-30 16:02:05.384100361 +0000
@@ -0,0 +1,18 @@
+{standard input}: Assembler messages:
+{standard input}:13: Error: unrecognized opcode: `isel'
+{standard input}:29: Error: unrecognized opcode: `isel'
+{standard input}:46: Error: unrecognized opcode: `isel'
+{standard input}:63: Error: unrecognized opcode: `isel'
+{standard input}:79: Error: unrecognized opcode: `isel'
+{standard input}:95: Error: unrecognized opcode: `isel'
+{standard input}:112: Error: unrecognized opcode: `isel'
+{standard input}:129: Error: unrecognized opcode: `isel'
+{standard input}:145: Error: unrecognized opcode: `isel'
+{standard input}:161: Error: unrecognized opcode: `isel'
+{standard input}:178: Error: unrecognized opcode: `isel'
+{standard input}:194: Error: unrecognized opcode: `isel'
+{standard input}:211: Error: unrecognized opcode: `isel'
+{standard input}:228: Error: unrecognized opcode: `isel'
+{standard input}:245: Error: unrecognized opcode: `isel'
+{standard input}:262: Error: unrecognized opcode: `isel'
+mv: cannot stat '/tmp/tmp.ui73QJ.o': No such file or directory
TEST Extern symbol code generation (backend/extern.c)
Using command : ../sparsec -c backend/extern.c -o tmp.o
Expecting exit value: 0
TEST Function pointer code generation (backend/function-ptr.c)
Using command : ../sparsec -c backend/function-ptr.c -o tmp.o
Expecting exit value: 0
TEST 'hello, world' code generation (backend/hello.c)
Using command : ../sparsec -c backend/hello.c -o tmp.o
Expecting exit value: 0
error: actual error text does not match expected error text.
error: see backend/hello.c.error.* for further investigation.
--- backend/hello.c.error.expected 2017-08-30 16:02:05.528102376 +0000
+++ backend/hello.c.error.got 2017-08-30 16:02:05.496101928 +0000
@@ -0,0 +1 @@
+/usr/include/powerpc64le-linux-gnu/gnu/stubs.h:8:12: error: unable to open 'gnu/stubs-32.h'
TEST Non-bool condition values in branch/select (backend/int-cond.c)
Using command : ../sparsec -c backend/int-cond.c -o tmp.o
Expecting exit value: 0
error: actual error text does not match expected error text.
error: see backend/int-cond.c.error.* for further investigation.
--- backend/int-cond.c.error.expected 2017-08-30 16:02:05.576103048 +0000
+++ backend/int-cond.c.error.got 2017-08-30 16:02:05.572102992 +0000
@@ -0,0 +1,4 @@
+{standard input}: Assembler messages:
+{standard input}:11: Error: unrecognized opcode: `isel'
+{standard input}:26: Error: unrecognized opcode: `isel'
+mv: cannot stat '/tmp/tmp.M5YFeP.o': No such file or directory
TEST Type of loaded objects (backend/load-type.c)
Using command : ../sparsec -c backend/load-type.c -o tmp.o
Expecting exit value: 0
TEST Logical operator code generation (backend/logical-ops.c)
Using command : ../sparsec -c backend/logical-ops.c -o tmp.o
Expecting exit value: 0
error: actual error text does not match expected error text.
error: see backend/logical-ops.c.error.* for further investigation.
--- backend/logical-ops.c.error.expected 2017-08-30 16:02:05.668104336 +0000
+++ backend/logical-ops.c.error.got 2017-08-30 16:02:05.664104280 +0000
@@ -0,0 +1,4 @@
+{standard input}: Assembler messages:
+{standard input}:14: Error: unrecognized opcode: `isel'
+{standard input}:32: Error: unrecognized opcode: `isel'
+mv: cannot stat '/tmp/tmp.gKQ3me.o': No such file or directory
TEST Loops (backend/loop.c)
Using command : ../sparsec -c backend/loop.c -o tmp.o
Expecting exit value: 0
TEST Loops with unused counter (backend/loop2.c)
Using command : ../sparsec -c backend/loop2.c -o tmp.o
Expecting exit value: 0
TEST Pointer cast code generation (backend/ptrcast.c)
Using command : ../sparsec -c backend/ptrcast.c -o tmp.o
Expecting exit value: 0
TEST Type of stored objects (backend/store-type.c)
Using command : ../sparsec -c backend/store-type.c -o tmp.o
Expecting exit value: 0
TEST struct access code generation (backend/struct-access.c)
Using command : ../sparsec -c backend/struct-access.c -o tmp.o
Expecting exit value: 0
TEST Struct code generation (backend/struct.c)
Using command : ../sparsec -c backend/struct.c -o tmp.o
Expecting exit value: 0
TEST sum from 1 to n (backend/sum.c)
Using command : ../sparsei backend/sum.c
Expecting exit value: 0
TEST Union code generation (backend/union.c)
Using command : ../sparsec -c backend/union.c -o tmp.o
Expecting exit value: 0
TEST void return type code generation (backend/void-return-type.c)
Using command : ../sparsec -c backend/void-return-type.c -o tmp.o
Expecting exit value: 0
TEST Bad array designated initializer (bad-array-designated-initializer.c)
Using command : ../sparse bad-array-designated-initializer.c
Expecting exit value: 0
TEST bad assignment (bad-assignment.c)
Using command : ../sparse bad-assignment.c
Expecting exit value: 0
TEST Bad cast syntax (bad-cast.c)
Using command : ../sparse bad-cast.c
Expecting exit value: 0
TEST Bad ternary syntax (bad-ternary-cond.c)
Using command : ../sparse bad-ternary-cond.c
Expecting exit value: 0
TEST Bad typeof syntax segfault (bad-typeof.c)
Using command : ../sparse bad-typeof.c
Expecting exit value: 0
TEST enum not in scope (badtype1.c)
Using command : ../sparse badtype1.c
Expecting exit value: 0
error: actual error text does not match expected error text.
error: see badtype1.c.error.* for further investigation.
--- badtype1.c.error.expected 2017-08-30 16:02:06.144110998 +0000
+++ badtype1.c.error.got 2017-08-30 16:02:06.140110942 +0000
@@ -1 +0,0 @@
-badtype1.c:1:22: warning: bad scope for 'enum bar'
info: test 'badtype1.c' is known to fail
TEST missing type (badtype2.c)
Using command : ../sparse badtype2.c
Expecting exit value: 0
TEST missing type in argument list (badtype3.c)
Using command : ../sparse badtype3.c
Expecting exit value: 0
TEST switch(bad_type) {...} segfault (badtype4.c)
Using command : ../sparse badtype4.c
Expecting exit value: 0
TEST badtype5.c (badtype5.c)
Using command : ../sparse badtype5.c
Expecting exit value: 0
TEST binary constant (binary-constant.c)
Using command : ../sparse binary-constant.c
Expecting exit value: 0
TEST bitfield size (bitfield-size.c)
Using command : ../test-linearize -Wno-decl bitfield-size.c
Expecting exit value: 0
TEST bitfield to integer promotion (bitfields.c)
Using command : ../sparse bitfields.c
Expecting exit value: 0
TEST conversions to bitwise types (bitwise-cast.c)
Using command : ../sparse -Wbitwise bitwise-cast.c
Expecting exit value: 0
TEST sizeof(bool array) (bool-array.c)
Using command : ../sparse -Wno-sizeof-bool bool-array.c
Expecting exit value: 0
TEST bool-cast-bad.c (bool-cast-bad.c)
Using command : ../sparse bool-cast-bad.c
Expecting exit value: 0
TEST bool-cast-explicit (bool-cast-explicit.c)
Using command : ../test-linearize -m64 bool-cast-explicit.c
Expecting exit value: 0
TEST bool-cast-implicit (bool-cast-implicit.c)
Using command : ../test-linearize -m64 bool-cast-implicit.c
Expecting exit value: 0
TEST bool-cast-restricted.c (bool-cast-restricted.c)
Using command : ../sparse -Wno-decl bool-cast-restricted.c
Expecting exit value: 0
TEST constant folding in bswap builtins (bswap-constant-folding.c)
Using command : ../sparse bswap-constant-folding.c
Expecting exit value: 0
TEST inlining switch statement (bug_inline_switch.c)
Using command : ../sparse bug_inline_switch.c
Expecting exit value: 0
TEST builtin-args-checking (builtin-args-checking.c)
Using command : ../sparse builtin-args-checking.c
Expecting exit value: 0
TEST builtin-bswap-constant (builtin-bswap-constant.c)
Using command : ../test-linearize builtin-bswap-constant.c
Expecting exit value: 0
TEST builtin-bswap (builtin-bswap-variable.c)
Using command : ../test-linearize builtin-bswap-variable.c
Expecting exit value: 0
TEST __builtin_atomic (builtin_atomic.c)
Using command : ../sparse builtin_atomic.c
Expecting exit value: 0
TEST __builtin_bswap (builtin_bswap.c)
Using command : ../sparse builtin_bswap.c
Expecting exit value: 0
TEST __builtin INFINITY / nan() (builtin_inf.c)
Using command : ../sparse builtin_inf.c
Expecting exit value: 0
TEST __builtin_safe (builtin_safe1.c)
Using command : ../sparse builtin_safe1.c
Expecting exit value: 0
TEST __builtin_unreachable() (builtin_unreachable.c)
Using command : ../sparse builtin_unreachable.c
Expecting exit value: 0
TEST __builtin_va_arg_pack() (builtin_va_arg_pack.c)
Using command : ../sparse builtin_va_arg_pack.c
Expecting exit value: 0
TEST c11-alignas (c11-alignas.c)
Using command : ../test-linearize -std=c11 c11-alignas.c
Expecting exit value: 0
TEST c11-alignof (c11-alignof.c)
Using command : ../test-linearize -std=c11 c11-alignof.c
Expecting exit value: 0
TEST c11-noreturn (c11-noreturn.c)
Using command : ../test-parsing -std=c11 c11-noreturn.c
Expecting exit value: 0
TEST c11-stdc-version (c11-stdc-version.c)
Using command : ../sparse -E -std=c11 c11-stdc-version.c
Expecting exit value: 0
TEST c11-thread-local (c11-thread-local.c)
Using command : ../test-parsing -std=c11 c11-thread-local.c
Expecting exit value: 0
TEST C99 for-loop declarations (c99-for-loop-decl.c)
Using command : ../sparse c99-for-loop-decl.c
Expecting exit value: 0
TEST C99 for loop variable declaration (c99-for-loop.c)
Using command : ../test-linearize c99-for-loop.c
Expecting exit value: 0
TEST Calling convention attributes (calling-convention-attributes.c)
Using command : ../sparse calling-convention-attributes.c
Expecting exit value: 0
TEST cast-constant-to-float (cast-constant-to-float.c)
Using command : ../test-linearize -Wno-decl cast-constant-to-float.c
Expecting exit value: 0
TEST cast-constants.c (cast-constants.c)
Using command : ../test-linearize -m64 cast-constants.c
Expecting exit value: 0
TEST cast-kinds (cast-kinds.c)
Using command : ../test-linearize -m64 cast-kinds.c
Expecting exit value: 0
TEST Segfault in check_byte_count after syntax error (check_byte_count-ice.c)
Using command : ../sparse check_byte_count-ice.c
Expecting exit value: 0
TEST choose expr builtin (choose_expr.c)
Using command : ../sparse choose_expr.c
Expecting exit value: 0
TEST Comma and array decay (comma.c)
Using command : ../sparse comma.c
Expecting exit value: 0
TEST Compare null pointer constant to int (compare-null-to-int.c)
Using command : ../sparse compare-null-to-int.c
Expecting exit value: 0
TEST compound-assign-type (compound-assign-type.c)
Using command : ../test-linearize -m64 compound-assign-type.c
Expecting exit value: 0
TEST cond-address-array.c (cond-address-array.c)
Using command : ../test-linearize -Wno-decl -Waddress cond-address-array.c
Expecting exit value: 0
TEST cond-address-function (cond-address-function.c)
Using command : ../test-linearize -Wno-decl -Waddress cond-address-function.c
Expecting exit value: 0
TEST cond-address.c (cond-address.c)
Using command : ../test-linearize -Wno-decl cond-address.c
Expecting exit value: 0
TEST cond-err-expand.c (cond-err-expand.c)
Using command : ../test-linearize -Wno-decl cond-err-expand.c
Expecting exit value: 0
TEST Two-argument conditional expression types (cond_expr.c)
Using command : ../sparse cond_expr.c
Expecting exit value: 0
TEST type of conditional expression (cond_expr2.c)
Using command : ../sparse cond_expr2.c
Expecting exit value: 0
TEST result type of relational and logical operators (cond_expr3.c)
Using command : ../sparse cond_expr3.c
Expecting exit value: 0
TEST conditional-type (conditional-type.c)
Using command : ../sparse conditional-type.c
Expecting exit value: 0
TEST address of static object's member constness verification. (constexpr-addr-of-static-member.c)
Using command : ../sparse -Wconstexpr-not-const constexpr-addr-of-static-member.c
Expecting exit value: 0
TEST address of static object constness verification. (constexpr-addr-of-static.c)
Using command : ../sparse -Wconstexpr-not-const constexpr-addr-of-static.c
Expecting exit value: 0
TEST Expression constness propagation in binops and alike (constexpr-binop.c)
Using command : ../sparse constexpr-binop.c
Expecting exit value: 0
TEST Expression constness propagation in casts (constexpr-cast.c)
Using command : ../sparse constexpr-cast.c
Expecting exit value: 0
TEST compound literal address constness verification (constexpr-compound-literal.c)
Using command : ../sparse -Wconstexpr-not-const constexpr-compound-literal.c
Expecting exit value: 0
TEST Expression constness propagation in conditional expressions (constexpr-conditional.c)
Using command : ../sparse constexpr-conditional.c
Expecting exit value: 0
TEST static storage object initializer constness verification. (constexpr-init.c)
Using command : ../sparse -Wconstexpr-not-const constexpr-init.c
Expecting exit value: 0
TEST label reference constness verification. (constexpr-labelref.c)
Using command : ../sparse -Wconstexpr-not-const constexpr-labelref.c
Expecting exit value: 0
TEST __builtin_offsetof() constness verification. (constexpr-offsetof.c)
Using command : ../sparse constexpr-offsetof.c
Expecting exit value: 0
TEST pointer arithmetic constness verification. (constexpr-pointer-arith.c)
Using command : ../sparse -Wconstexpr-not-const constexpr-pointer-arith.c
Expecting exit value: 0
TEST integer literal cast to pointer type constness verification. (constexpr-pointer-cast.c)
Using command : ../sparse -Wconstexpr-not-const constexpr-pointer-cast.c
Expecting exit value: 0
TEST Expression constness propagation in preops (constexpr-preop.c)
Using command : ../sparse constexpr-preop.c
Expecting exit value: 0
TEST constness of pure/const builtins (constexpr-pure-builtin.c)
Using command : ../sparse constexpr-pure-builtin.c
Expecting exit value: 0
TEST string literal constness verification. (constexpr-string.c)
Using command : ../sparse -Wconstexpr-not-const constexpr-string.c
Expecting exit value: 0
TEST __builtin_types_compatible_p() constness verification. (constexpr-types-compatible-p.c)
Using command : ../sparse constexpr-types-compatible-p.c
Expecting exit value: 0
TEST Check -Wcontext (context.c)
Using command : ../sparse context.c
Expecting exit value: 0
TEST crash add-doms (crash-add-doms.c)
Using command : ../test-linearize crash-add-doms.c
Expecting exit value: 0
TEST crash bb_target (crash-bb_target.c)
Using command : ../test-linearize crash-bb_target.c
Expecting exit value: 0
TEST crash ep->active (crash-ep-active.c)
Using command : ../test-linearize crash-ep-active.c
Expecting exit value: 0
TEST crash ptrlist (crash-ptrlist.c)
Using command : ../test-linearize crash-ptrlist.c
Expecting exit value: 0
TEST crash rewrite_branch (crash-rewrite-branch.c)
Using command : ../test-linearize crash-rewrite-branch.c
Expecting exit value: 0
TEST crazy02-not-so.c (crazy02-not-so.c)
Using command : ../sparse -Wno-decl crazy02-not-so.c
Expecting exit value: 0
TEST crazy03.c (crazy03.c)
Using command : ../sparse crazy03.c
Expecting exit value: 0
TEST declaration after statement (ANSI) (declaration-after-statement-ansi.c)
Using command : ../sparse -ansi declaration-after-statement-ansi.c
Expecting exit value: 0
TEST declaration after statement (C89) (declaration-after-statement-c89.c)
Using command : ../sparse -std=c89 declaration-after-statement-c89.c
Expecting exit value: 0
TEST declaration after statement (C99) (declaration-after-statement-c99.c)
Using command : ../sparse -std=c99 declaration-after-statement-c99.c
Expecting exit value: 0
TEST declaration after statement (default) (declaration-after-statement-default.c)
Using command : ../sparse declaration-after-statement-default.c
Expecting exit value: 0
TEST finding definitions (definitions.c)
Using command : ../sparse definitions.c
Expecting exit value: 0
TEST designated_init attribute (designated-init.c)
Using command : ../sparse designated-init.c
Expecting exit value: 0
TEST discarded-label-statement (discarded-label-statement.c)
Using command : ../test-linearize discarded-label-statement.c
Expecting exit value: 0
TEST division constants (div.c)
Using command : ../sparse div.c
Expecting exit value: 0
TEST Double semicolon in struct (double-semicolon.c)
Using command : ../sparse double-semicolon.c
Expecting exit value: 0
TEST Dubious bitwise operation on !x (dubious-bitwise-with-not.c)
Using command : ../sparse dubious-bitwise-with-not.c
Expecting exit value: 0
TEST endian-big.c (endian-big.c)
Using command : ../sparse -mbig-endian endian-big.c
Expecting exit value: 0
TEST endian-little.c (endian-little.c)
Using command : ../sparse -mlittle-endian endian-little.c
Expecting exit value: 0
TEST enum-mismatch (enum-mismatch.c)
Using command : ../sparse -Wenum-mismatch enum-mismatch.c
Expecting exit value: 0
TEST enumeration constants' scope [6.2.1p7] (enum_scope.c)
Using command : ../sparse enum_scope.c
Expecting exit value: 0
TEST Character escape sequences (escapes.c)
Using command : ../sparse escapes.c
Expecting exit value: 0
TEST duplicate extern array (extern-array.c)
Using command : ../sparse extern-array.c
Expecting exit value: 0
TEST extern inline function (extern-inline.c)
Using command : ../sparse extern-inline.c extern-inline.c
Expecting exit value: 0
TEST field overlap (field-overlap.c)
Using command : ../sparse field-overlap.c
Expecting exit value: 0
TEST field-override (field-override.c)
Using command : ../sparse -Woverride-init -Woverride-init-all field-override.c
Expecting exit value: 0
TEST Forced function argument type. (fored_arg.c)
Using command : ../sparse fored_arg.c
Expecting exit value: 0
TEST foul bitwise (foul-bitwise.c)
Using command : ../sparse foul-bitwise.c
Expecting exit value: 0
TEST fp-vs-ptrcast (fp-vs-ptrcast.c)
Using command : ../test-linearize -Wno-decl fp-vs-ptrcast.c
Expecting exit value: 0
TEST Function pointer inheritance (function-pointer-inheritance.c)
Using command : ../sparse function-pointer-inheritance.c
Expecting exit value: 0
TEST function-redecl (function-redecl.c)
Using command : ../sparse function-redecl.c
Expecting exit value: 0
TEST goto labels (goto-label.c)
Using command : ../sparse goto-label.c
Expecting exit value: 0
TEST identifier-list parsing (identifier_list.c)
Using command : ../sparse identifier_list.c
Expecting exit value: 0
TEST implicit-ret-type.c (implicit-ret-type.c)
Using command : ../sparse -Wno-decl implicit-ret-type.c
Expecting exit value: 0
TEST implicit-type.c (implicit-type.c)
Using command : ../sparse -Wno-decl implicit-type.c
Expecting exit value: 0
TEST internal infinite loop (0) (infinite-loop0.c)
Using command : ../sparse -Wno-decl infinite-loop0.c
Expecting exit value: 0
TEST infinite loop 02 (infinite-loop02.c)
Using command : ../sparse -Wno-decl infinite-loop02.c
Expecting exit value: 0
TEST infinite loop 03 (infinite-loop03.c)
Using command : ../sparse -Wno-decl infinite-loop03.c
Expecting exit value: 0
TEST char array initializers (init-char-array.c)
Using command : ../sparse init-char-array.c
Expecting exit value: 0
TEST parenthesized string initializer (init-char-array1.c)
Using command : ../sparse -Wparen-string init-char-array1.c
Expecting exit value: 0
TEST -Winit-cstring option (init_cstring.c)
Using command : ../sparse -Winit-cstring init_cstring.c
Expecting exit value: 0
TEST Initializer entry defined twice (initializer-entry-defined-twice.c)
Using command : ../sparse initializer-entry-defined-twice.c
Expecting exit value: 0
TEST inline compound literals (inline_compound_literals.c)
Using command : ../sparse inline_compound_literals.c
Expecting exit value: 0
TEST int128 (int128.c)
Using command : ../test-linearize int128.c
Expecting exit value: 0
TEST Integer promotions (integer-promotions.c)
Using command : ../sparse integer-promotions.c
Expecting exit value: 0
TEST integer constant & conditional expression (ioc-typecheck.c)
Using command : ../sparse ioc-typecheck.c
Expecting exit value: 0
error: actual error text does not match expected error text.
error: see ioc-typecheck.c.error.* for further investigation.
--- ioc-typecheck.c.error.expected 2017-08-30 16:02:07.552130702 +0000
+++ ioc-typecheck.c.error.got 2017-08-30 16:02:07.548130646 +0000
@@ -0,0 +1 @@
+ioc-typecheck.c:3:16: error: bad integer constant expression
info: test 'ioc-typecheck.c' is known to fail
TEST kill-casts (kill-casts.c)
Using command : ../test-linearize kill-casts.c
Expecting exit value: 0
TEST kill-computedgoto (kill-computedgoto.c)
Using command : ../test-linearize kill-computedgoto.c
Expecting exit value: 0
TEST kill-cse (kill-cse.c)
Using command : ../test-linearize -Wno-decl kill-cse.c
Expecting exit value: 0
TEST kill insert-branch (kill-insert-branch.c)
Using command : ../test-linearize -Wno-decl kill-insert-branch.c
Expecting exit value: 0
TEST kill-load (kill-load.c)
Using command : ../test-linearize -Wno-decl kill-load.c
Expecting exit value: 0
TEST kill-phi-node (kill-phi-node.c)
Using command : ../test-linearize kill-phi-node.c
Expecting exit value: 0
TEST kill-phi-ttsbb (kill-phi-ttsbb.c)
Using command : ../test-linearize kill-phi-ttsbb.c
Expecting exit value: 0
TEST kill-phi-ttsbb2 (kill-phi-ttsbb2.c)
Using command : ../test-linearize kill-phi-ttsbb2.c
Expecting exit value: 0
TEST kill-phisrc (kill-phisrc.c)
Using command : ../test-linearize -Wno-decl kill-phisrc.c
Expecting exit value: 0
TEST kill-pure-call (kill-pure-call.c)
Using command : ../test-linearize -Wno-decl kill-pure-call.c
Expecting exit value: 0
TEST kill-replaced-insn (kill-replaced-insn.c)
Using command : ../test-linearize kill-replaced-insn.c
Expecting exit value: 0
TEST kill-rewritten-load (kill-rewritten-load.c)
Using command : ../test-linearize -Wno-decl kill-rewritten-load.c
Expecting exit value: 0
TEST kill-select (kill-select.c)
Using command : ../test-linearize kill-select.c
Expecting exit value: 0
TEST kill-slice (kill-slice.c)
Using command : ../test-linearize -Wno-decl kill-slice.c
Expecting exit value: 0
TEST kill-store (kill-store.c)
Using command : ../test-linearize -Wno-decl kill-store.c
Expecting exit value: 0
TEST kill-unreachable-phi (kill-unreachable-phi.c)
Using command : ../sparse kill-unreachable-phi.c
Expecting exit value: 0
TEST Label followed by __asm__ (label-asm.c)
Using command : ../sparse label-asm.c
Expecting exit value: 0
TEST Label attribute (label-attr.c)
Using command : ../sparse label-attr.c
Expecting exit value: 0
TEST label-expr (label-expr.c)
Using command : ../test-linearize label-expr.c
Expecting exit value: 0
TEST __label__ scope (label-scope.c)
Using command : ../sparse label-scope.c
Expecting exit value: 0
TEST bitfield initializer mask (linear/bitfield-init-mask.c)
Using command : ../test-linearize -fdump-linearize=only -Wno-decl linear/bitfield-init-mask.c
Expecting exit value: 0
TEST bitfield implicit init zero (linear/bitfield-init-zero.c)
Using command : ../test-linearize -Wno-decl linear/bitfield-init-zero.c
Expecting exit value: 0
TEST missing instruction's size (linear/missing-insn-size.c)
Using command : ../test-linearize linear/missing-insn-size.c
Expecting exit value: 0
TEST struct implicit init zero not needed (linear/struct-init-full.c)
Using command : ../test-linearize -Wno-decl linear/struct-init-full.c
Expecting exit value: 0
error: actual output text does not match expected output text.
error: see linear/struct-init-full.c.output.* for further investigation.
--- linear/struct-init-full.c.output.expected 2017-08-30 16:02:07.888135404 +0000
+++ linear/struct-init-full.c.output.got 2017-08-30 16:02:07.884135348 +0000
@@ -1,10 +1,11 @@
s_init_all:
-.L4:
+.L0:
<entry-point>
+ store.96 $0 -> 0[s]
store.32 %arg1 -> 0[s]
store.32 $42 -> 4[s]
store.32 $123 -> 8[s]
- load.96 %r8 <- 0[s]
- ret.96 %r8
+ load.96 %r2 <- 0[s]
+ ret.96 %r2
info: test 'linear/struct-init-full.c' is known to fail
TEST struct implicit init zero needed (linear/struct-init-partial.c)
Using command : ../test-linearize -Wno-decl linear/struct-init-partial.c
Expecting exit value: 0
TEST Local label (local-label.c)
Using command : ../sparse local-label.c
Expecting exit value: 0
TEST Logical and/or (logical.c)
Using command : ../sparse logical.c
Expecting exit value: 0
TEST loop-linearization (loop-linearization.c)
Using command : ../test-linearize loop-linearization.c
Expecting exit value: 0
TEST Expansion of typeof when dealing with member of struct (member_of_typeof.c)
Using command : ../sparse member_of_typeof.c
Expecting exit value: 0
TEST memops-volatile (memops-volatile.c)
Using command : ../test-linearize memops-volatile.c
Expecting exit value: 0
TEST handling of identifier-less declarations (missing-ident.c)
Using command : ../sparse missing-ident.c
Expecting exit value: 0
TEST typedefs with many declarators (multi_typedef.c)
Using command : ../sparse multi_typedef.c
Expecting exit value: 0
TEST nested declarator vs. parameters (nested-declarator.c)
Using command : ../sparse nested-declarator.c
Expecting exit value: 0
TEST more on handling of ( in direct-declarator (nested-declarator2.c)
Using command : ../sparse nested-declarator2.c
Expecting exit value: 0
TEST nocast.c (nocast.c)
Using command : ../sparse nocast.c
Expecting exit value: 0
TEST noderef attribute (noderef.c)
Using command : ../sparse noderef.c
Expecting exit value: 0
TEST Using plain integer as NULL pointer (non-pointer-null.c)
Using command : ../sparse non-pointer-null.c
Expecting exit value: 0
TEST Old initializer with -Wno-old-initializer (old-initializer-nowarn.c)
Using command : ../sparse -Wno-old-initializer
Expecting exit value: 0
TEST Old initializer (old-initializer.c)
Using command : ../sparse old-initializer.c
Expecting exit value: 0
TEST double-unop (optim/binops-same-args.c)
Using command : ../test-linearize -Wno-decl optim/binops-same-args.c
Expecting exit value: 0
TEST bool-context (optim/bool-context.c)
Using command : ../test-linearize -Wno-decl optim/bool-context.c
Expecting exit value: 0
TEST bool-same-args (optim/bool-same-args.c)
Using command : ../test-linearize optim/bool-same-args.c
Expecting exit value: 0
TEST bool-simplify (optim/bool-simplify.c)
Using command : ../test-linearize -Wno-decl optim/bool-simplify.c
Expecting exit value: 0
TEST cse-commutativity (optim/cse-commutativity.c)
Using command : ../test-linearize optim/cse-commutativity.c
Expecting exit value: 0
TEST cse-dual-compare (optim/cse-dual-compare.c)
Using command : ../test-linearize optim/cse-dual-compare.c
Expecting exit value: 0
error: Actual output contains some patterns which are not expected.
info: test 'optim/cse-dual-compare.c' is known to fail
TEST double-unop (optim/double-unop.c)
Using command : ../test-linearize -Wno-decl optim/double-unop.c
Expecting exit value: 0
TEST fpcast-nop (optim/fpcast-nop.c)
Using command : ../test-linearize optim/fpcast-nop.c
Expecting exit value: 0
TEST muldiv-by-one (optim/muldiv-by-one.c)
Using command : ../test-linearize -Wno-decl optim/muldiv-by-one.c
Expecting exit value: 0
TEST muldiv-by-zero (optim/muldiv-by-zero.c)
Using command : ../test-linearize -Wno-decl optim/muldiv-by-zero.c
Expecting exit value: 0
TEST muldiv-minus-one (optim/muldiv-minus-one.c)
Using command : ../test-linearize -Wno-decl optim/muldiv-minus-one.c
Expecting exit value: 0
TEST optim/setcc-setcc (optim/setcc-setcc.c)
Using command : ../test-linearize optim/setcc-setcc.c
Expecting exit value: 0
TEST optim/setcc-seteq (optim/setcc-seteq.c)
Using command : ../test-linearize optim/setcc-seteq.c
Expecting exit value: 0
TEST optim/setcc-setne (optim/setcc-setne.c)
Using command : ../test-linearize optim/setcc-setne.c
Expecting exit value: 0
TEST Ignore VOID in if-convert (optim/void-if-convert.c)
Using command : ../test-linearize -Wno-decl optim/void-if-convert.c
Expecting exit value: 0
TEST There is no scope boundary between global and file scope (outer-scope.c)
Using command : ../sparse -include outer-scope.c outer-scope.c
Expecting exit value: 0
TEST #pragma once (pragma-once.c)
Using command : ../sparse pragma-once.c
Expecting exit value: 0
TEST __COUNTER__ #1 (preprocessor/counter1.c)
Using command : ../sparse -E preprocessor/counter1.c
Expecting exit value: 0
TEST __COUNTER__ #2 (preprocessor/counter2.c)
Using command : ../sparse -Ipreprocessor -E preprocessor/counter2.c
Expecting exit value: 0
TEST __COUNTER__ #3 (preprocessor/counter3.c)
Using command : ../sparse -Ipreprocessor -E preprocessor/counter1.c preprocessor/counter3.c
Expecting exit value: 0
TEST dump-macros with empty file (preprocessor/dump-macros-empty.c)
Using command : ../sparse -E -dD empty-file
Expecting exit value: 0
TEST dump-macros with multiple files (preprocessor/dump-macros-multi.c)
Using command : ../sparse -E -dD empty-file preprocessor/dump-macros-multi.c
Expecting exit value: 0
TEST dump-macros (preprocessor/dump-macros.c)
Using command : ../sparse -E -dD -DIJK=ijk -UNDEF -UNYDEF preprocessor/dump-macros.c
Expecting exit value: 0
TEST early-escape (preprocessor/early-escape.c)
Using command : ../sparse -E preprocessor/early-escape.c
Expecting exit value: 0
TEST predefined __<type>_BIT__ (preprocessor/predef-char-bit.c)
Using command : ../test-linearize -Wno-decl preprocessor/predef-char-bit.c
Expecting exit value: 0
TEST predefined __<type>_MAX__ (preprocessor/predef-max.c)
Using command : ../test-linearize -Wno-decl preprocessor/predef-max.c
Expecting exit value: 0
TEST predefined __SIZEOF_<type>__ (preprocessor/predef-sizeof.c)
Using command : ../test-linearize -Wno-decl preprocessor/predef-sizeof.c
Expecting exit value: 0
TEST Preprocessor #1 (preprocessor/preprocessor1.c)
Using command : ../sparse -E preprocessor/preprocessor1.c
Expecting exit value: 0
TEST Preprocessor #10 (preprocessor/preprocessor10.c)
Using command : ../sparse -E preprocessor/preprocessor10.c
Expecting exit value: 0
TEST Preprocessor #11 (preprocessor/preprocessor11.c)
Using command : ../sparse -E preprocessor/preprocessor11.c
Expecting exit value: 0
TEST Preprocessor #12 (preprocessor/preprocessor12.c)
Using command : ../sparse -E preprocessor/preprocessor12.c
Expecting exit value: 0
TEST Preprocessor #13 (preprocessor/preprocessor13.c)
Using command : ../sparse -E preprocessor/preprocessor13.c
Expecting exit value: 0
TEST Preprocessor #14 (preprocessor/preprocessor14.c)
Using command : ../sparse -E preprocessor/preprocessor14.c
Expecting exit value: 0
TEST Preprocessor #15 (preprocessor/preprocessor15.c)
Using command : ../sparse -E preprocessor/preprocessor15.c
Expecting exit value: 0
TEST Preprocessor #16 (preprocessor/preprocessor16.c)
Using command : ../sparse -E preprocessor/preprocessor16.c
Expecting exit value: 0
TEST Preprocessor #17 (preprocessor/preprocessor17.c)
Using command : ../sparse -E preprocessor/preprocessor17.c
Expecting exit value: 0
TEST Preprocessor #18 (preprocessor/preprocessor18.c)
Using command : ../sparse -E preprocessor/preprocessor18.c
Expecting exit value: 0
TEST Preprocessor #19 (preprocessor/preprocessor19.c)
Using command : ../sparse -E preprocessor/preprocessor19.c
Expecting exit value: 0
TEST Preprocessor #2 (preprocessor/preprocessor2.c)
Using command : ../sparse -E preprocessor/preprocessor2.c
Expecting exit value: 0
TEST Preprocessor #20 (preprocessor/preprocessor20.c)
Using command : ../sparse -E preprocessor/preprocessor20.c
Expecting exit value: 0
TEST Preprocessor #21 (preprocessor/preprocessor21.c)
Using command : ../sparse -E preprocessor/preprocessor21.c
Expecting exit value: 0
TEST Preprocessor #22 (preprocessor/preprocessor22.c)
Using command : ../sparse -E preprocessor/preprocessor22.c
Expecting exit value: 0
TEST Preprocessor #23 (preprocessor/preprocessor23.c)
Using command : ../sparse -E preprocessor/preprocessor23.c
Expecting exit value: 0
TEST Preprocessor #3 (preprocessor/preprocessor3.c)
Using command : ../sparse -E preprocessor/preprocessor3.c
Expecting exit value: 0
TEST Preprocessor #4 (preprocessor/preprocessor4.c)
Using command : ../sparse -E preprocessor/preprocessor4.c
Expecting exit value: 0
TEST Preprocessor #5 (preprocessor/preprocessor5.c)
Using command : ../sparse -E preprocessor/preprocessor5.c
Expecting exit value: 0
TEST Preprocessor #6 (preprocessor/preprocessor6.c)
Using command : ../sparse -E preprocessor/preprocessor6.c
Expecting exit value: 0
TEST Preprocessor #7 (preprocessor/preprocessor7.c)
Using command : ../sparse -E preprocessor/preprocessor7.c
Expecting exit value: 0
TEST Preprocessor #8 (preprocessor/preprocessor8.c)
Using command : ../sparse -E preprocessor/preprocessor8.c
Expecting exit value: 0
TEST Preprocessor #9 (preprocessor/preprocessor9.c)
Using command : ../sparse -E preprocessor/preprocessor9.c
Expecting exit value: 0
TEST Preprocessor #14 (preprocessor/stringify.c)
Using command : ../sparse -E preprocessor/stringify.c
Expecting exit value: 0
TEST wide char token-pasting (preprocessor/wide.c)
Using command : ../sparse -E preprocessor/wide.c
Expecting exit value: 0
TEST Compile skip function prototype (prototype.c)
Using command : ../sparsec -c prototype.c -o tmp.o
Expecting exit value: 0
TEST ptr-inherit.c (ptr-inherit.c)
Using command : ../sparse ptr-inherit.c
Expecting exit value: 0
TEST Pure function attribute (pure-function.c)
Using command : ../sparse pure-function.c
Expecting exit value: 0
TEST const et.al. are reserved identifiers (reserved.c)
Using command : ../sparse reserved.c
Expecting exit value: 0
TEST restrict array attribute (restrict-array.c)
Using command : ../sparse restrict-array.c
Expecting exit value: 0
TEST typeof with bitwise types (restricted-typeof.c)
Using command : ../sparse -Wbitwise restricted-typeof.c
Expecting exit value: 0
TEST sizeof(_Bool) is valid (sizeof-bool.c)
Using command : ../sparse -Wsizeof-bool sizeof-bool.c
Expecting exit value: 0
TEST Handling of sizeof compound-literal . member (sizeof-compound-postfix.c)
Using command : ../sparse sizeof-compound-postfix.c
Expecting exit value: 0
TEST valid specifier combinations (specifiers1.c)
Using command : ../sparse specifiers1.c
Expecting exit value: 0
TEST invalid specifier combinations (specifiers2.c)
Using command : ../sparse specifiers2.c
Expecting exit value: 0
TEST static forward declaration (static-forward-decl.c)
Using command : ../sparse static-forward-decl.c
Expecting exit value: 0
TEST static assertion (static_assert.c)
Using command : ../sparse static_assert.c
Expecting exit value: 0
TEST Address space of a struct member (struct-as.c)
Using command : ../sparse struct-as.c
Expecting exit value: 0
TEST struct attribute placement (struct-attribute-placement.c)
Using command : ../sparse struct-attribute-placement.c
Expecting exit value: 0
TEST struct namespaces #1 (struct-ns1.c)
Using command : ../sparse struct-ns1.c
Expecting exit value: 0
TEST struct not in scope (struct-ns2.c)
Using command : ../sparse struct-ns2.c
Expecting exit value: 0
error: actual error text does not match expected error text.
error: see struct-ns2.c.error.* for further investigation.
--- struct-ns2.c.error.expected 2017-08-30 16:02:09.076152032 +0000
+++ struct-ns2.c.error.got 2017-08-30 16:02:09.068151920 +0000
@@ -1,3 +0,0 @@
-struct-ns2.c:2:11: warning: bad scope for 'struct Bar'
-struct-ns2.c:12:14: error: incomplete type/unknown size for 'y'
-struct-ns2.c:13:5: error: using member 'i' in incomplete 'struct Bar'
info: test 'struct-ns2.c' is known to fail
TEST struct size (struct-size1.c)
Using command : ../sparse struct-size1.c
Expecting exit value: 0
TEST tautological-compare (tautological-compare.c)
Using command : ../sparse -Wno-decl -Wtautological-compare tautological-compare.c
Expecting exit value: 0
TEST binary operations (test-be.c)
Using command : ../sparse test-be.c
Expecting exit value: 0
TEST selfcheck1 (testsuite-selfcheck1.c)
Using command : ../sparse -E testsuite-selfcheck1.c
Expecting exit value: 0
TEST selfcheck2 (testsuite-selfcheck2.c)
Using command : ../sparse -E testsuite-selfcheck2.c
Expecting exit value: 0
error: Actual output doesn't contain some of the expected patterns.
info: test 'testsuite-selfcheck2.c' is known to fail
TEST selfcheck3 (testsuite-selfcheck3.c)
Using command : ../sparse -E testsuite-selfcheck3.c
Expecting exit value: 0
error: Actual output contains some patterns which are not expected.
info: test 'testsuite-selfcheck3.c' is known to fail
TEST Transparent union attribute. (transparent-union.c)
Using command : ../sparse transparent-union.c
Expecting exit value: 0
TEST "char []" to "char *" demotion (type1.c)
Using command : ../sparse type1.c
Expecting exit value: 0
TEST typedef shadowing (typedef_shadow.c)
Using command : ../sparse typedef_shadow.c
Expecting exit value: 0
TEST typeof-addresspace.c (typeof-addresspace.c)
Using command : ../sparse typeof-addresspace.c
Expecting exit value: 0
error: actual error text does not match expected error text.
error: see typeof-addresspace.c.error.* for further investigation.
--- typeof-addresspace.c.error.expected 2017-08-30 16:02:09.204153823 +0000
+++ typeof-addresspace.c.error.got 2017-08-30 16:02:09.200153767 +0000
@@ -0,0 +1,6 @@
+typeof-addresspace.c:9:30: warning: incorrect type in initializer (different address spaces)
+typeof-addresspace.c:9:30: expected int *ptr3
+typeof-addresspace.c:9:30: got int <asn:1>*ptr
+typeof-addresspace.c:10:29: warning: incorrect type in initializer (different address spaces)
+typeof-addresspace.c:10:29: expected int *ptr4
+typeof-addresspace.c:10:29: got int <asn:1>*ptr
info: test 'typeof-addresspace.c' is known to fail
TEST Rusty Russell's typeof attribute casting. (typeof-attribute.c)
Using command : ../sparse typeof-attribute.c
Expecting exit value: 0
TEST typeof-mods (typeof-mods.c)
Using command : ../sparse typeof-mods.c
Expecting exit value: 0
TEST typeof-noderef (typeof-noderef.c)
Using command : ../sparse typeof-noderef.c
Expecting exit value: 0
error: actual error text does not match expected error text.
error: see typeof-noderef.c.error.* for further investigation.
--- typeof-noderef.c.error.expected 2017-08-30 16:02:09.240154327 +0000
+++ typeof-noderef.c.error.got 2017-08-30 16:02:09.236154271 +0000
@@ -0,0 +1,6 @@
+typeof-noderef.c:7:30: warning: incorrect type in initializer (different modifiers)
+typeof-noderef.c:7:30: expected int *ptr3
+typeof-noderef.c:7:30: got int [noderef] *ptr
+typeof-noderef.c:8:29: warning: incorrect type in initializer (different modifiers)
+typeof-noderef.c:8:29: expected int *ptr4
+typeof-noderef.c:8:29: got int [noderef] *ptr
info: test 'typeof-noderef.c' is known to fail
TEST typeof-safe (typeof-safe.c)
Using command : ../sparse typeof-safe.c
Expecting exit value: 0
error: actual error text does not match expected error text.
error: see typeof-safe.c.error.* for further investigation.
--- typeof-safe.c.error.expected 2017-08-30 16:02:09.252154495 +0000
+++ typeof-safe.c.error.got 2017-08-30 16:02:09.248154439 +0000
@@ -0,0 +1,9 @@
+typeof-safe.c:9:30: warning: incorrect type in initializer (different modifiers)
+typeof-safe.c:9:30: expected int *ptr3
+typeof-safe.c:9:30: got int [safe] *ptr
+typeof-safe.c:10:29: warning: incorrect type in initializer (different modifiers)
+typeof-safe.c:10:29: expected int *ptr4
+typeof-safe.c:10:29: got int [safe] *ptr
+typeof-safe.c:13:13: warning: incorrect type in assignment (different modifiers)
+typeof-safe.c:13:13: expected int [safe] *[assigned] ptr
+typeof-safe.c:13:13: got int *<noident>
info: test 'typeof-safe.c' is known to fail
TEST -Wtypesign (typesign.c)
Using command : ../sparse -Wtypesign typesign.c
Expecting exit value: 0
TEST Varargs bogus warning regression test #1 (varargs1.c)
Using command : ../sparse varargs1.c
Expecting exit value: 0
TEST wide character constants (wide.c)
Using command : ../sparse wide.c
Expecting exit value: 0
Out of 287 tests, 272 passed, 15 failed (10 of them are known to fail)
Makefile:232: recipe for target 'check' failed
make: *** [check] Error 1
ukleinek@plummer:~/sparse$
The problem is that some cpp symbols are not defined in sparse that are
expected to exist. So I can "fix" backend/sum.c with the following
patch:
diff --git a/validation/backend/sum.c b/validation/backend/sum.c
index 0604299..d0be8dd 100644
--- a/validation/backend/sum.c
+++ b/validation/backend/sum.c
@@ -1,3 +1,5 @@
+#define __powerpc64__
+#define _CALL_ELF 2
#include <stdio.h>
#include <stdlib.h>
I'm a bit clueless how sparse works here. I see __powerpc64__ and _CALL_ELF
already defined in cgcc, but sparse-llvm doesn't pick it up from there.
I didn't check deeply, but I guess for say amd64 the situation should be
similar because there __x86_64__ is required to be defined.
Can you give me a hint how to fix this? Is this a problem in sparse
itself or maybe llvm?
Best regards
Uwe
[1] https://bugs.debian.org/873508
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: sparse test failures on ppc32le (and other not so common archs)
2017-08-30 16:14 ` Bug#873508: sparse test failures on ppc32le (and other not so common archs) Uwe Kleine-König
@ 2017-08-30 16:55 ` Ramsay Jones
2017-08-30 17:36 ` Uwe Kleine-König
0 siblings, 1 reply; 55+ messages in thread
From: Ramsay Jones @ 2017-08-30 16:55 UTC (permalink / raw)
To: Uwe Kleine-König, linux-sparse; +Cc: 873508, Antoine Beaupre
On 30/08/17 17:14, Uwe Kleine-König wrote:
> Hello,
>
> Antoine Beaupre (on Cc:) noticed that sparse doesn't work on some not so
> common architectures like ppc32le, s390x, ppc64 and sparc64[1]. This is
> nicely catched by the testsuite, e.g.:
The only architecture, from the above list, that is not supported
by cgcc seems to be ppc32le.
> ukleinek@plummer:~/sparse$ git rev-parse HEAD
> 958c11c35d98417eb6b948bffe2dffed14eb3320
> ukleinek@plummer:~/sparse$ uname -a
> Linux plummer 4.9.0-3-powerpc64le #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) ppc64le GNU/Linux
> ukleinek@plummer:~/sparse$ make check V=1
It would be easier to see the results if you _didn't_ add V=1. ;-)
[snip]
> Out of 287 tests, 272 passed, 15 failed (10 of them are known to fail)
> Makefile:232: recipe for target 'check' failed
> make: *** [check] Error 1
> ukleinek@plummer:~/sparse$
The additional five failures are all in the llvm backend (sparsec),
which you do not need to use sparse as a 'checker'.
> The problem is that some cpp symbols are not defined in sparse that are
> expected to exist. So I can "fix" backend/sum.c with the following
> patch:
>
> diff --git a/validation/backend/sum.c b/validation/backend/sum.c
> index 0604299..d0be8dd 100644
> --- a/validation/backend/sum.c
> +++ b/validation/backend/sum.c
> @@ -1,3 +1,5 @@
> +#define __powerpc64__
> +#define _CALL_ELF 2
> #include <stdio.h>
> #include <stdlib.h>
>
>
Yep, sparse/sparsec do not define various macros that gcc/clang define
by default on a given architecture. This is a known problem (that I have
been meaning to fix ...). The 'workaround' for the time being is to use
the cgcc front-end to sparse. (for example 'make CC=cgcc', or perhaps
'cgcc -no-compile').
[You didn't mention your usage - is this for a kernel build?]
ATB,
Ramsay Jones
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: sparse test failures on ppc32le (and other not so common archs)
2017-08-30 16:55 ` Ramsay Jones
@ 2017-08-30 17:36 ` Uwe Kleine-König
2017-08-31 0:11 ` Christopher Li
0 siblings, 1 reply; 55+ messages in thread
From: Uwe Kleine-König @ 2017-08-30 17:36 UTC (permalink / raw)
To: Ramsay Jones; +Cc: linux-sparse, 873508, Antoine Beaupre
[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]
Hello,
On Wed, Aug 30, 2017 at 05:55:00PM +0100, Ramsay Jones wrote:
> On 30/08/17 17:14, Uwe Kleine-König wrote:
> > ukleinek@plummer:~/sparse$ make check V=1
>
> It would be easier to see the results if you _didn't_ add V=1. ;-)
noted for the next time.
> [snip]
> > Out of 287 tests, 272 passed, 15 failed (10 of them are known to fail)
> > Makefile:232: recipe for target 'check' failed
> > make: *** [check] Error 1
> > ukleinek@plummer:~/sparse$
>
> The additional five failures are all in the llvm backend (sparsec),
> which you do not need to use sparse as a 'checker'.
>
> > The problem is that some cpp symbols are not defined in sparse that are
> > expected to exist. So I can "fix" backend/sum.c with the following
> > patch:
> >
> > diff --git a/validation/backend/sum.c b/validation/backend/sum.c
> > index 0604299..d0be8dd 100644
> > --- a/validation/backend/sum.c
> > +++ b/validation/backend/sum.c
> > @@ -1,3 +1,5 @@
> > +#define __powerpc64__
> > +#define _CALL_ELF 2
> > #include <stdio.h>
> > #include <stdlib.h>
> >
> >
>
> Yep, sparse/sparsec do not define various macros that gcc/clang define
> by default on a given architecture. This is a known problem (that I have
> been meaning to fix ...). The 'workaround' for the time being is to use
> the cgcc front-end to sparse. (for example 'make CC=cgcc', or perhaps
> 'cgcc -no-compile').
>
> [You didn't mention your usage - is this for a kernel build?]
This problem became visible during the make check phase when creating packaged
on the listed archs for horst[1]. You can see a build logs at
https://buildd.debian.org/status/fetch.php?pkg=horst&arch=s390x&ver=5.0-1&stamp=1503905687&raw=0
https://buildd.debian.org/status/fetch.php?pkg=horst&arch=ppc64el&ver=5.0-1&stamp=1503906226&raw=0
The error message looks identical (I checked the ppc64el log) to the
problem with backend/sum.c:
sparse -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -std=gnu99 -Wall -Wextra -g -I. -DDO_DEBUG -I/usr/include/libnl3 *.[ch]
/usr/include/powerpc64le-linux-gnu/gnu/stubs.h:8:12: error: unable to open 'gnu/stubs-32.h'
Makefile:113: recipe for target 'check' failed
make[1]: *** [check] Error 1
Best regards
Uwe
[1] https://packages.debian.org/sid/horst
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: sparse test failures on ppc32le (and other not so common archs)
2017-08-30 17:36 ` Uwe Kleine-König
@ 2017-08-31 0:11 ` Christopher Li
2017-08-31 20:55 ` Uwe Kleine-König
0 siblings, 1 reply; 55+ messages in thread
From: Christopher Li @ 2017-08-31 0:11 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Ramsay Jones, Linux-Sparse, 873508, Antoine Beaupre
On Wed, Aug 30, 2017 at 1:36 PM, Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
>> >
>> > diff --git a/validation/backend/sum.c b/validation/backend/sum.c
>> > index 0604299..d0be8dd 100644
>> > --- a/validation/backend/sum.c
>> > +++ b/validation/backend/sum.c
>> > @@ -1,3 +1,5 @@
>> > +#define __powerpc64__
>> > +#define _CALL_ELF 2
>> > #include <stdio.h>
>> > #include <stdlib.h>
>> >
>> >
>>
>> Yep, sparse/sparsec do not define various macros that gcc/clang define
>> by default on a given architecture. This is a known problem (that I have
>> been meaning to fix ...). The 'workaround' for the time being is to use
>> the cgcc front-end to sparse. (for example 'make CC=cgcc', or perhaps
>> 'cgcc -no-compile').
>>
>> [You didn't mention your usage - is this for a kernel build?]
>
> This problem became visible during the make check phase when creating packaged
> on the listed archs for horst[1]. You can see a build logs at
>
> https://buildd.debian.org/status/fetch.php?pkg=horst&arch=s390x&ver=5.0-1&stamp=1503905687&raw=0
> https://buildd.debian.org/status/fetch.php?pkg=horst&arch=ppc64el&ver=5.0-1&stamp=1503906226&raw=0
>
> The error message looks identical (I checked the ppc64el log) to the
> problem with backend/sum.c:
>
> sparse -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -std=gnu99 -Wall -Wextra -g -I. -DDO_DEBUG -I/usr/include/libnl3 *.[ch]
> /usr/include/powerpc64le-linux-gnu/gnu/stubs.h:8:12: error: unable to open 'gnu/stubs-32.h'
That is very much like on x86_64 missing define "#weak_define __x86_64__ 1"
Does cgcc work for you? In the future we do want to move the archetecture
related define from cgcc into sparse by itself. For now you can set
"sparse" as "cgcc -no-compile"
Chris
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: sparse test failures on ppc32le (and other not so common archs)
2017-08-31 0:11 ` Christopher Li
@ 2017-08-31 20:55 ` Uwe Kleine-König
2017-08-31 22:43 ` Ramsay Jones
2017-09-01 0:47 ` sparse test failures on ppc32le (and other not so common archs) Christopher Li
0 siblings, 2 replies; 55+ messages in thread
From: Uwe Kleine-König @ 2017-08-31 20:55 UTC (permalink / raw)
To: Christopher Li; +Cc: Ramsay Jones, Linux-Sparse, 873508, Antoine Beaupre
[-- Attachment #1: Type: text/plain, Size: 2277 bytes --]
Hello Christopher,
On Wed, Aug 30, 2017 at 08:11:49PM -0400, Christopher Li wrote:
> On Wed, Aug 30, 2017 at 1:36 PM, Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
> >> >
> >> > diff --git a/validation/backend/sum.c b/validation/backend/sum.c
> >> > index 0604299..d0be8dd 100644
> >> > --- a/validation/backend/sum.c
> >> > +++ b/validation/backend/sum.c
> >> > @@ -1,3 +1,5 @@
> >> > +#define __powerpc64__
> >> > +#define _CALL_ELF 2
> >> > #include <stdio.h>
> >> > #include <stdlib.h>
> >> >
> >> >
> >>
> >> Yep, sparse/sparsec do not define various macros that gcc/clang define
> >> by default on a given architecture. This is a known problem (that I have
> >> been meaning to fix ...). The 'workaround' for the time being is to use
> >> the cgcc front-end to sparse. (for example 'make CC=cgcc', or perhaps
> >> 'cgcc -no-compile').
> >>
> >> [You didn't mention your usage - is this for a kernel build?]
> >
> > This problem became visible during the make check phase when creating packaged
> > on the listed archs for horst[1]. You can see a build logs at
> >
> > https://buildd.debian.org/status/fetch.php?pkg=horst&arch=s390x&ver=5.0-1&stamp=1503905687&raw=0
> > https://buildd.debian.org/status/fetch.php?pkg=horst&arch=ppc64el&ver=5.0-1&stamp=1503906226&raw=0
> >
> > The error message looks identical (I checked the ppc64el log) to the
> > problem with backend/sum.c:
> >
> > sparse -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -std=gnu99 -Wall -Wextra -g -I. -DDO_DEBUG -I/usr/include/libnl3 *.[ch]
> > /usr/include/powerpc64le-linux-gnu/gnu/stubs.h:8:12: error: unable to open 'gnu/stubs-32.h'
>
> That is very much like on x86_64 missing define "#weak_define __x86_64__ 1"
>
> Does cgcc work for you? In the future we do want to move the archetecture
> related define from cgcc into sparse by itself. For now you can set
> "sparse" as "cgcc -no-compile"
Yes that works. So to address the Debian bug I can do:
- move sparse to /usr/lib
- teach cgcc about the move of sparse
- make /usr/bin/sparse call cgcc -no-compile "$@"
or is it easier to teach sparse about the architecture stuff?
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: sparse test failures on ppc32le (and other not so common archs)
2017-08-31 20:55 ` Uwe Kleine-König
@ 2017-08-31 22:43 ` Ramsay Jones
2017-09-01 0:50 ` Christopher Li
2017-09-01 7:46 ` Uwe Kleine-König
2017-09-01 0:47 ` sparse test failures on ppc32le (and other not so common archs) Christopher Li
1 sibling, 2 replies; 55+ messages in thread
From: Ramsay Jones @ 2017-08-31 22:43 UTC (permalink / raw)
To: Uwe Kleine-König, Christopher Li
Cc: Linux-Sparse, 873508, Antoine Beaupre
On 31/08/17 21:55, Uwe Kleine-König wrote:
> On Wed, Aug 30, 2017 at 08:11:49PM -0400, Christopher Li wrote:
>> That is very much like on x86_64 missing define "#weak_define __x86_64__ 1"
>>
>> Does cgcc work for you? In the future we do want to move the archetecture
>> related define from cgcc into sparse by itself. For now you can set
>> "sparse" as "cgcc -no-compile"
>
> Yes that works. So to address the Debian bug I can do:
>
> - move sparse to /usr/lib
> - teach cgcc about the move of sparse
> - make /usr/bin/sparse call cgcc -no-compile "$@"
Hmm, I don't think that would be a good idea ...
> or is it easier to teach sparse about the architecture stuff?
I now understand (I think!) that you are building a sparse
package (presumably a .deb) and you are concerned that sparse
does not pass it's own testsuite on those platforms.
As I said before, the additional failures you are seeing are
in the 'llvm backend' code (which, as far as I know, only passes
on x86_64 Linux), and in my opinion the llvm-backend programs should
not be installed. (The Makefile will build them automatically if
you have llvm installed, likewise for c2xml/libxml and test-inspect/gtk).
[I would like to see build variable(s) to allow the user to suppress
the build (or installation) of the other 'non-primary' sparse programs.]
Anyway, if you were to un-install llvm, sparse-llvm etc., would not
be built, and the tests would not be run ... ;-)
Christopher, as the project maintainer, has the joy of making these
kinds of decisions! :-D
ATB,
Ramsay Jones
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: sparse test failures on ppc32le (and other not so common archs)
2017-08-31 22:43 ` Ramsay Jones
@ 2017-09-01 0:50 ` Christopher Li
2017-09-01 7:46 ` Uwe Kleine-König
1 sibling, 0 replies; 55+ messages in thread
From: Christopher Li @ 2017-09-01 0:50 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Uwe Kleine-König, Linux-Sparse, 873508, Antoine Beaupre
On Thu, Aug 31, 2017 at 6:43 PM, Ramsay Jones
>> - move sparse to /usr/lib
>> - teach cgcc about the move of sparse
>> - make /usr/bin/sparse call cgcc -no-compile "$@"
>
> Hmm, I don't think that would be a good idea ...
>
Agree.
>
> Anyway, if you were to un-install llvm, sparse-llvm etc., would not
> be built, and the tests would not be run ... ;-)
I think Uwe already confirm using cgcc to invoke sparse will
fix the problem.
In this test, we just need to use cgcc to invoke sparse-llvm.
I have a patch to fix the usage in test-suite in the other email.
Chris
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: sparse test failures on ppc32le (and other not so common archs)
2017-08-31 22:43 ` Ramsay Jones
2017-09-01 0:50 ` Christopher Li
@ 2017-09-01 7:46 ` Uwe Kleine-König
2017-09-01 11:51 ` Christopher Li
2017-09-21 18:58 ` Bug#873508: " Uwe Kleine-König
1 sibling, 2 replies; 55+ messages in thread
From: Uwe Kleine-König @ 2017-09-01 7:46 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Christopher Li, Linux-Sparse, 873508, Antoine Beaupre
[-- Attachment #1: Type: text/plain, Size: 2794 bytes --]
Hello,
On Thu, Aug 31, 2017 at 11:43:53PM +0100, Ramsay Jones wrote:
> On 31/08/17 21:55, Uwe Kleine-König wrote:
> > On Wed, Aug 30, 2017 at 08:11:49PM -0400, Christopher Li wrote:
> >> That is very much like on x86_64 missing define "#weak_define __x86_64__ 1"
> >>
> >> Does cgcc work for you? In the future we do want to move the archetecture
> >> related define from cgcc into sparse by itself. For now you can set
> >> "sparse" as "cgcc -no-compile"
> >
> > Yes that works. So to address the Debian bug I can do:
> >
> > - move sparse to /usr/lib
> > - teach cgcc about the move of sparse
> > - make /usr/bin/sparse call cgcc -no-compile "$@"
>
> Hmm, I don't think that would be a good idea ...
>
> > or is it easier to teach sparse about the architecture stuff?
>
> I now understand (I think!) that you are building a sparse
> package (presumably a .deb) and you are concerned that sparse
> does not pass it's own testsuite on those platforms.
Nearly right. I'm responsible for the sparse Debian package and the
problem at hand is https://bugs.debian.org/873508. This bug report has
"Severity: serious" wihch might eventually result in the removal of
sparse from the Debian archive.
@anarcat: Given that cgcc seems to work, would you agree to apply the
following patch to horst:
diff --git a/Makefile b/Makefile
index 4f924fa..d563652 100644
--- a/Makefile
+++ b/Makefile
@@ -110,7 +110,7 @@ $(NAME): $(OBJS)
$(OBJS): .buildflags
check:
- sparse $(CFLAGS) *.[ch]
+ cgcc -no-compile $(CFLAGS) *.[ch]
clean:
-rm -f *.o radiotap/*.o *~
and downgrade the bug to "important"? That would be a compromise that
buys us a bit of time.
> As I said before, the additional failures you are seeing are
> in the 'llvm backend' code (which, as far as I know, only passes
> on x86_64 Linux), and in my opinion the llvm-backend programs should
> not be installed. (The Makefile will build them automatically if
> you have llvm installed, likewise for c2xml/libxml and test-inspect/gtk).
Currently the sparse package contains /usr/include/sparse/, c2xml, cgcc,
sparse, sparse-llvm, sparsec and a separate package sparse-test-inspect
includes test-inspect. (That's how I inherited the package some time
ago.)
> [I would like to see build variable(s) to allow the user to suppress
> the build (or installation) of the other 'non-primary' sparse programs.]
>
> Anyway, if you were to un-install llvm, sparse-llvm etc., would not
> be built, and the tests would not be run ... ;-)
>
> Christopher, as the project maintainer, has the joy of making these
> kinds of decisions! :-D
This only solves a part of the problem because the bug report is about
sparse itself, not it's llvm part.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: sparse test failures on ppc32le (and other not so common archs)
2017-09-01 7:46 ` Uwe Kleine-König
@ 2017-09-01 11:51 ` Christopher Li
2017-09-21 18:58 ` Bug#873508: " Uwe Kleine-König
1 sibling, 0 replies; 55+ messages in thread
From: Christopher Li @ 2017-09-01 11:51 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Ramsay Jones, Linux-Sparse, 873508, Antoine Beaupre
On Fri, Sep 1, 2017 at 3:46 AM, Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
\>
> Nearly right. I'm responsible for the sparse Debian package and the
> problem at hand is https://bugs.debian.org/873508. This bug report has
> "Severity: serious" wihch might eventually result in the removal of
> sparse from the Debian archive.
>
> @anarcat: Given that cgcc seems to work, would you agree to apply the
> following patch to horst:
>
> diff --git a/Makefile b/Makefile
> index 4f924fa..d563652 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -110,7 +110,7 @@ $(NAME): $(OBJS)
> $(OBJS): .buildflags
>
> check:
> - sparse $(CFLAGS) *.[ch]
> + cgcc -no-compile $(CFLAGS) *.[ch]
You patch definitely works.
I think it is the better way to fix it.
Sparse "selfcheck" target was doing the same thing.
It is using "cgcc -no-compile" already.
I suggest in your patch you can do some thing
similar to "selfcheck" target:
CHECKER = cgcc -no-compile
$(CHECKER) $(CFLAGS) *.[ch]
Later when we update sparse to handle architecture
properly. We can just invoke make with "CHECKER=xxxx"
to test.
> and downgrade the bug to "important"? That would be a compromise that
> buys us a bit of time.
Agree.
>
> This only solves a part of the problem because the bug report is about
> sparse itself, not it's llvm part.
I agree with that too.
Chris
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: Bug#873508: sparse test failures on ppc32le (and other not so common archs)
2017-09-01 7:46 ` Uwe Kleine-König
2017-09-01 11:51 ` Christopher Li
@ 2017-09-21 18:58 ` Uwe Kleine-König
2017-09-26 18:11 ` Uwe Kleine-König
1 sibling, 1 reply; 55+ messages in thread
From: Uwe Kleine-König @ 2017-09-21 18:58 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Christopher Li, Linux-Sparse, 873508, Antoine Beaupre
[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]
Control: clone 873508 -1
Control: retitle -1 Please use cgcc to check hosted C code instead of sparse
Control: severity -1 normal
Control: reassign -1 horst
On Fri, Sep 01, 2017 at 09:46:44AM +0200, Uwe Kleine-König wrote:
> @anarcat: Given that cgcc seems to work, would you agree to apply the
> following patch to horst:
>
> diff --git a/Makefile b/Makefile
> index 4f924fa..d563652 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -110,7 +110,7 @@ $(NAME): $(OBJS)
> $(OBJS): .buildflags
>
> check:
> - sparse $(CFLAGS) *.[ch]
> + cgcc -no-compile $(CFLAGS) *.[ch]
>
> clean:
> -rm -f *.o radiotap/*.o *~
>
In the meantime I learned from upstream that sparse is not expected to
grok arbitrary hosted code. For that it is needed to use the cgcc
wrapper to handle the required cpp symbols. That it works on some
architectures with plain sparse is mostly luck.
I still expect some platforms to fail with the wrapper, too, because
cgcc doesn't know about all platforms yet. But I intend to upload a new
sparse package soon that includes a build time check for that, and the
respective fixes are easy.
> and downgrade the bug to "important"? That would be a compromise that
> buys us a bit of time.
I'd say sparse failing on hosted code isn't "important", but cgcc should
have all necessary definitions for Debian platforms. So I'm keeping this
bug at important and intend to close it once all platforms are known to
it.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Bug#873508: sparse test failures on ppc32le (and other not so common archs)
2017-09-21 18:58 ` Bug#873508: " Uwe Kleine-König
@ 2017-09-26 18:11 ` Uwe Kleine-König
2017-09-27 8:00 ` Uwe Kleine-König
0 siblings, 1 reply; 55+ messages in thread
From: Uwe Kleine-König @ 2017-09-26 18:11 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Christopher Li, Linux-Sparse, 873508, Antoine Beaupre
[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]
Control: severity 873508 normal
Control: retitle 873508 Fix FTBFS for m68k, hurd, x32 and ppc64
On Thu, Sep 21, 2017 at 08:58:23PM +0200, Uwe Kleine-König wrote:
> I still expect some platforms to fail with the wrapper, too, because
> cgcc doesn't know about all platforms yet. But I intend to upload a new
> sparse package soon that includes a build time check for that, and the
> respective fixes are easy.
I did that now, and at least all official Debian ports pass that new
check. I downgraded the severity accordingly to normal.
Current build failures can be seen at
https://buildd.debian.org/status/package.php?p=sparse&suite=unstable
hurd fails because it doesn't define PATH_MAX and NAME_MAX. m68k fails
with
sparse: ptrlist.c:125: __add_ptr_list: Assertion `(3 & (unsigned long)ptr) == 0' failed.
(Didn't look into this one yet.) And ppc64 and x32 need the respective
cpp defines added I think. If noone beats me to it, I will look into the
latter at least during the next few days.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: Bug#873508: sparse test failures on ppc32le (and other not so common archs)
2017-09-26 18:11 ` Uwe Kleine-König
@ 2017-09-27 8:00 ` Uwe Kleine-König
2017-09-27 8:40 ` Luc Van Oostenryck
2017-09-27 21:11 ` [PATCH] fix cgcc ELF version for ppc64/pcc64le Luc Van Oostenryck
0 siblings, 2 replies; 55+ messages in thread
From: Uwe Kleine-König @ 2017-09-27 8:00 UTC (permalink / raw)
To: Luc Van Oostenryck
Cc: Christopher Li, Ramsay Jones, Linux-Sparse, 873508, Antoine Beaupre
[-- Attachment #1: Type: text/plain, Size: 865 bytes --]
Hello,
On Tue, Sep 26, 2017 at 08:11:01PM +0200, Uwe Kleine-König wrote:
> And ppc64 and x32 need the respective cpp defines added I think. If
> noone beats me to it, I will look into the latter at least during the
> next few days.
Looking at ppc64, the following fixes the build:
diff --git a/cgcc b/cgcc
index a8d7b4f217fe..a1c02899c623 100755
--- a/cgcc
+++ b/cgcc
@@ -286,7 +286,7 @@ sub add_specs {
} elsif ($spec eq 'ppc64') {
return (' -D__powerpc__=1 -D__PPC__=1 -D_STRING_ARCH_unaligned=1' .
' -D__powerpc64__=1 -D__PPC64__=1' .
- ' -D_CALL_ELF=2' .
+ ' -D_CALL_ELF=1' .
' -m64' .
&float_types (1, 1, 21, [24,8], [53,11], [113,15]));
} elsif ($spec eq 's390x') {
I wonder if that could be right. Luc, you added =2 in
e0306fe0b725af6e2e7ff59d7f0d99c96315791a, maybe you can comment?
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: Bug#873508: sparse test failures on ppc32le (and other not so common archs)
2017-09-27 8:00 ` Uwe Kleine-König
@ 2017-09-27 8:40 ` Luc Van Oostenryck
2017-09-27 21:11 ` [PATCH] fix cgcc ELF version for ppc64/pcc64le Luc Van Oostenryck
1 sibling, 0 replies; 55+ messages in thread
From: Luc Van Oostenryck @ 2017-09-27 8:40 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Christopher Li, Ramsay Jones, Linux-Sparse, 873508, Antoine Beaupre
On Wed, Sep 27, 2017 at 10:00 AM, Uwe Kleine-König
<uwe@kleine-koenig.org> wrote:
> Hello,
>
> On Tue, Sep 26, 2017 at 08:11:01PM +0200, Uwe Kleine-König wrote:
>> And ppc64 and x32 need the respective cpp defines added I think. If
>> noone beats me to it, I will look into the latter at least during the
>> next few days.
>
> Looking at ppc64, the following fixes the build:
>
> diff --git a/cgcc b/cgcc
> index a8d7b4f217fe..a1c02899c623 100755
> --- a/cgcc
> +++ b/cgcc
> @@ -286,7 +286,7 @@ sub add_specs {
> } elsif ($spec eq 'ppc64') {
> return (' -D__powerpc__=1 -D__PPC__=1 -D_STRING_ARCH_unaligned=1' .
> ' -D__powerpc64__=1 -D__PPC64__=1' .
> - ' -D_CALL_ELF=2' .
> + ' -D_CALL_ELF=1' .
> ' -m64' .
> &float_types (1, 1, 21, [24,8], [53,11], [113,15]));
> } elsif ($spec eq 's390x') {
>
> I wonder if that could be right. Luc, you added =2 in
> e0306fe0b725af6e2e7ff59d7f0d99c96315791a, maybe you can comment?
Neither =2 or =1 is correct, it depends on which version of the ELF
ABI you're using.
This in turn (as I understood) is most of the time tied to fact that
you're using ppc64le
(which normally needs ELFv2) or not.
I can't look at this now but will do this evening.
-- Luc
^ permalink raw reply [flat|nested] 55+ messages in thread* [PATCH] fix cgcc ELF version for ppc64/pcc64le
2017-09-27 8:00 ` Uwe Kleine-König
2017-09-27 8:40 ` Luc Van Oostenryck
@ 2017-09-27 21:11 ` Luc Van Oostenryck
2017-09-30 8:49 ` Uwe Kleine-König
2017-10-03 4:46 ` Christopher Li
1 sibling, 2 replies; 55+ messages in thread
From: Luc Van Oostenryck @ 2017-09-27 21:11 UTC (permalink / raw)
To: linux-sparse; +Cc: Christopher Li, Uwe Kleine-König, Luc Van Oostenryck
Commit e0306fe0 "cgcc: teach cgcc about ppc64[le]" add support
for PPC64 to cgcc by adding the needed options like '-m64' &
'-m{little,big}-endian' and defines likes '-D__PPC64__=1'.
In this commit the defined '-D_CALL_ELF=2' was also added
but the value of 2 is for ELF v2 ABI, normally used for ppc64le,
while the older ELF ABI, normally used for plain ppc64 should use
'-D_CALL_ELF=2'.
Fix this by using the value of 1 or 2 for '_CALL_ELF' depending
if the architecture is ppc64 or ppc64le.
Fixes: e0306fe0b725af6e2e7ff59d7f0d99c96315791a
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
---
cgcc | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/cgcc b/cgcc
index a8d7b4f21..909cd2477 100755
--- a/cgcc
+++ b/cgcc
@@ -286,7 +286,6 @@ sub add_specs {
} elsif ($spec eq 'ppc64') {
return (' -D__powerpc__=1 -D__PPC__=1 -D_STRING_ARCH_unaligned=1' .
' -D__powerpc64__=1 -D__PPC64__=1' .
- ' -D_CALL_ELF=2' .
' -m64' .
&float_types (1, 1, 21, [24,8], [53,11], [113,15]));
} elsif ($spec eq 's390x') {
@@ -317,9 +316,9 @@ sub add_specs {
} elsif ($arch =~ /^(ppc)$/i) {
return &add_specs ('ppc');
} elsif ($arch =~ /^(ppc64)$/i) {
- return &add_specs ('ppc64') . ' -mbig-endian';
+ return &add_specs ('ppc64') . ' -mbig-endian -D_CALL_ELF=1';
} elsif ($arch =~ /^(ppc64le)$/i) {
- return &add_specs ('ppc64') . ' -mlittle-endian';
+ return &add_specs ('ppc64') . ' -mlittle-endian -D_CALL_ELF=2';
} elsif ($arch =~ /^(s390x)$/i) {
return &add_specs ('s390x');
} elsif ($arch =~ /^(sparc64)$/i) {
--
2.14.0
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: [PATCH] fix cgcc ELF version for ppc64/pcc64le
2017-09-27 21:11 ` [PATCH] fix cgcc ELF version for ppc64/pcc64le Luc Van Oostenryck
@ 2017-09-30 8:49 ` Uwe Kleine-König
2017-10-02 19:45 ` Luc Van Oostenryck
2017-10-03 4:46 ` Christopher Li
1 sibling, 1 reply; 55+ messages in thread
From: Uwe Kleine-König @ 2017-09-30 8:49 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: linux-sparse, Christopher Li
[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]
Hello Luc,
On Wed, Sep 27, 2017 at 11:11:37PM +0200, Luc Van Oostenryck wrote:
> Commit e0306fe0 "cgcc: teach cgcc about ppc64[le]" add support
> for PPC64 to cgcc by adding the needed options like '-m64' &
> '-m{little,big}-endian' and defines likes '-D__PPC64__=1'.
>
> In this commit the defined '-D_CALL_ELF=2' was also added
> but the value of 2 is for ELF v2 ABI, normally used for ppc64le,
> while the older ELF ABI, normally used for plain ppc64 should use
> '-D_CALL_ELF=2'.
>
> Fix this by using the value of 1 or 2 for '_CALL_ELF' depending
> if the architecture is ppc64 or ppc64le.
>
> Fixes: e0306fe0b725af6e2e7ff59d7f0d99c96315791a
> Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
I tested that patch on the following machines:
hostname/chroot uname -m gcc -dumpmachine
partch/sid ppc powerpc-linux-gnu
pizzetti/sid_ppc64-dchroot ppc64 powerpc64-linux-gnu
plummer/sid_ppc64el-dchroot ppc64le powerpc64le-linux-gnu
and my test case (env CHECK=./sparse ./cgcc -no-compile memops.c) works
on all of them now.
Tested-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Thanks
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [PATCH] fix cgcc ELF version for ppc64/pcc64le
2017-09-30 8:49 ` Uwe Kleine-König
@ 2017-10-02 19:45 ` Luc Van Oostenryck
2017-10-02 21:17 ` Christopher Li
0 siblings, 1 reply; 55+ messages in thread
From: Luc Van Oostenryck @ 2017-10-02 19:45 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: linux-sparse, Christopher Li
On Sat, Sep 30, 2017 at 10:49:13AM +0200, Uwe Kleine-König wrote:
> Hello Luc,
>
> On Wed, Sep 27, 2017 at 11:11:37PM +0200, Luc Van Oostenryck wrote:
> > Commit e0306fe0 "cgcc: teach cgcc about ppc64[le]" add support
> > for PPC64 to cgcc by adding the needed options like '-m64' &
> > '-m{little,big}-endian' and defines likes '-D__PPC64__=1'.
> >
> > In this commit the defined '-D_CALL_ELF=2' was also added
> > but the value of 2 is for ELF v2 ABI, normally used for ppc64le,
> > while the older ELF ABI, normally used for plain ppc64 should use
> > '-D_CALL_ELF=2'.
> >
> > Fix this by using the value of 1 or 2 for '_CALL_ELF' depending
> > if the architecture is ppc64 or ppc64le.
> >
> > Fixes: e0306fe0b725af6e2e7ff59d7f0d99c96315791a
> > Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
>
> I tested that patch on the following machines:
>
> hostname/chroot uname -m gcc -dumpmachine
> partch/sid ppc powerpc-linux-gnu
> pizzetti/sid_ppc64-dchroot ppc64 powerpc64-linux-gnu
> plummer/sid_ppc64el-dchroot ppc64le powerpc64le-linux-gnu
>
> and my test case (env CHECK=./sparse ./cgcc -no-compile memops.c) works
> on all of them now.
>
> Tested-by: Uwe Kleine-König <uwe@kleine-koenig.org>
>
> Thanks
> Uwe
Many thanks for the testing.
@ Chris,
Can you take the patch as is or do you prefer that I send a pull request?
-- Luc
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] fix cgcc ELF version for ppc64/pcc64le
2017-09-27 21:11 ` [PATCH] fix cgcc ELF version for ppc64/pcc64le Luc Van Oostenryck
2017-09-30 8:49 ` Uwe Kleine-König
@ 2017-10-03 4:46 ` Christopher Li
1 sibling, 0 replies; 55+ messages in thread
From: Christopher Li @ 2017-10-03 4:46 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: Linux-Sparse, Uwe Kleine-König
On Wed, Sep 27, 2017 at 5:11 PM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
> Commit e0306fe0 "cgcc: teach cgcc about ppc64[le]" add support
> for PPC64 to cgcc by adding the needed options like '-m64' &
> '-m{little,big}-endian' and defines likes '-D__PPC64__=1'.
>
> In this commit the defined '-D_CALL_ELF=2' was also added
> but the value of 2 is for ELF v2 ABI, normally used for ppc64le,
> while the older ELF ABI, normally used for plain ppc64 should use
> '-D_CALL_ELF=2'.
>
> Fix this by using the value of 1 or 2 for '_CALL_ELF' depending
> if the architecture is ppc64 or ppc64le.
Applied on master.
Chris
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: sparse test failures on ppc32le (and other not so common archs)
2017-08-31 20:55 ` Uwe Kleine-König
2017-08-31 22:43 ` Ramsay Jones
@ 2017-09-01 0:47 ` Christopher Li
2017-09-01 7:02 ` Josh Triplett
2017-09-09 21:02 ` Uwe Kleine-König
1 sibling, 2 replies; 55+ messages in thread
From: Christopher Li @ 2017-09-01 0:47 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Ramsay Jones, Linux-Sparse, 873508, Antoine Beaupre
On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König <uwe@kleine-> Yes
that works. So to address the Debian bug I can do:
>
> - move sparse to /usr/lib
> - teach cgcc about the move of sparse
> - make /usr/bin/sparse call cgcc -no-compile "$@"
I don't like that. It means the user can't invoke sparse directly.
>
> or is it easier to teach sparse about the architecture stuff?
First of all. It is not very trivial to teach sparse about the architecture
stuff. To my mind, we need to move all the cgcc logic into sparse.
For this case, I think it is easier to teach the sparse validation
code to use cgcc on those back end testing. Most validation don't
need to include system header file at all so it does not have
this problem.
How about this patch?
I know my patch is white space damaged in email.
Git branch is at:
https://git.kernel.org/pub/scm/devel/sparse/chrisl/sparse.git/log/?h=llvm-cgcc
Please let me know if that fix your problem. It pass check
on my local machine running x86_64. I don't have ppc64 to
test with.
Chris
diff --git a/sparsec b/sparsec
index 9dc96c9..2990d26 100755
--- a/sparsec
+++ b/sparsec
@@ -32,7 +32,8 @@ done
TMPLLVM=`mktemp -t tmp.XXXXXX`".llvm"
TMPFILE=`mktemp -t tmp.XXXXXX`".o"
-$DIRNAME/sparse-llvm $SPARSEOPTS > $TMPLLVM
+env CHECK=$DIRNAME/sparse-llvm $DIRNAME/cgcc -no-compile \
+ $SPARSEOPTS > $TMPLLVM
LLC=`"${LLVM_CONFIG:-llvm-config}" --bindir`/llc
diff --git a/sparsei b/sparsei
index 3431a9f..3abd00f 100755
--- a/sparsei
+++ b/sparsei
@@ -10,4 +10,4 @@ if [ $# -eq 0 ]; then
exit 1
fi
-$DIRNAME/sparse-llvm $@ | $LLI
+env CHECK=$DIRNAME/sparse-llvm $DIRNAME/cgcc -no-compile $@ | $LLI
^ permalink raw reply related [flat|nested] 55+ messages in thread* Re: sparse test failures on ppc32le (and other not so common archs)
2017-09-01 0:47 ` sparse test failures on ppc32le (and other not so common archs) Christopher Li
@ 2017-09-01 7:02 ` Josh Triplett
2017-09-01 7:57 ` Uwe Kleine-König
` (2 more replies)
2017-09-09 21:02 ` Uwe Kleine-König
1 sibling, 3 replies; 55+ messages in thread
From: Josh Triplett @ 2017-09-01 7:02 UTC (permalink / raw)
To: Christopher Li
Cc: Uwe Kleine-König, Ramsay Jones, Linux-Sparse, 873508,
Antoine Beaupre
On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
> On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König <uwe@kleine-> Yes
> that works. So to address the Debian bug I can do:
> >
> > - move sparse to /usr/lib
> > - teach cgcc about the move of sparse
> > - make /usr/bin/sparse call cgcc -no-compile "$@"
>
> I don't like that. It means the user can't invoke sparse directly.
>
> >
> > or is it easier to teach sparse about the architecture stuff?
>
> First of all. It is not very trivial to teach sparse about the architecture
> stuff. To my mind, we need to move all the cgcc logic into sparse.
Related to that: while it would mean we couldn't necessarily just rely
entirely on GCC's definitions for a target platform, I think in an ideal
world we could have a sparse binary that understood *all* target
platforms at once, such that you could ask Sparse on x86_64 to "compile"
as though targeting any arbitrary architecture. That would also have the
major advantage of making it easy to run the Sparse testsuite for
*every* target architecture without needing compilers for every such
architecture.
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: sparse test failures on ppc32le (and other not so common archs)
2017-09-01 7:02 ` Josh Triplett
@ 2017-09-01 7:57 ` Uwe Kleine-König
2017-09-01 22:55 ` Josh Triplett
2017-09-01 12:00 ` Christopher Li
2017-09-03 21:14 ` Luc Van Oostenryck
2 siblings, 1 reply; 55+ messages in thread
From: Uwe Kleine-König @ 2017-09-01 7:57 UTC (permalink / raw)
To: Josh Triplett
Cc: Christopher Li, Ramsay Jones, Linux-Sparse, 873508, Antoine Beaupre
[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]
On Fri, Sep 01, 2017 at 12:02:12AM -0700, Josh Triplett wrote:
> On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
> > On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König <uwe@kleine-> Yes
> > that works. So to address the Debian bug I can do:
> > >
> > > - move sparse to /usr/lib
> > > - teach cgcc about the move of sparse
> > > - make /usr/bin/sparse call cgcc -no-compile "$@"
> >
> > I don't like that. It means the user can't invoke sparse directly.
> >
> > >
> > > or is it easier to teach sparse about the architecture stuff?
> >
> > First of all. It is not very trivial to teach sparse about the architecture
> > stuff. To my mind, we need to move all the cgcc logic into sparse.
>
> Related to that: while it would mean we couldn't necessarily just rely
> entirely on GCC's definitions for a target platform, I think in an ideal
> world we could have a sparse binary that understood *all* target
> platforms at once, such that you could ask Sparse on x86_64 to "compile"
> as though targeting any arbitrary architecture. That would also have the
> major advantage of making it easy to run the Sparse testsuite for
> *every* target architecture without needing compilers for every such
> architecture.
You'd need the target arch's system headers though. But still it would
be great. In a first attempt something like:
#ifdef __powerpc__
add_pre_buffer("#weak_define __powerpc__ " __powerpc__ "\n");
#ifdef _CALL_ELF
add_pre_buffer("#weak_define _CALL_ELF " _CALL_ELF "\n");
#endif
#endif
would be helpful already.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: sparse test failures on ppc32le (and other not so common archs)
2017-09-01 7:57 ` Uwe Kleine-König
@ 2017-09-01 22:55 ` Josh Triplett
0 siblings, 0 replies; 55+ messages in thread
From: Josh Triplett @ 2017-09-01 22:55 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Christopher Li, Ramsay Jones, Linux-Sparse, 873508, Antoine Beaupre
On Fri, Sep 01, 2017 at 09:57:09AM +0200, Uwe Kleine-König wrote:
> On Fri, Sep 01, 2017 at 12:02:12AM -0700, Josh Triplett wrote:
> > On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
> > > On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König <uwe@kleine-> Yes
> > > that works. So to address the Debian bug I can do:
> > > >
> > > > - move sparse to /usr/lib
> > > > - teach cgcc about the move of sparse
> > > > - make /usr/bin/sparse call cgcc -no-compile "$@"
> > >
> > > I don't like that. It means the user can't invoke sparse directly.
> > >
> > > >
> > > > or is it easier to teach sparse about the architecture stuff?
> > >
> > > First of all. It is not very trivial to teach sparse about the architecture
> > > stuff. To my mind, we need to move all the cgcc logic into sparse.
> >
> > Related to that: while it would mean we couldn't necessarily just rely
> > entirely on GCC's definitions for a target platform, I think in an ideal
> > world we could have a sparse binary that understood *all* target
> > platforms at once, such that you could ask Sparse on x86_64 to "compile"
> > as though targeting any arbitrary architecture. That would also have the
> > major advantage of making it easy to run the Sparse testsuite for
> > *every* target architecture without needing compilers for every such
> > architecture.
>
> You'd need the target arch's system headers though.
Only for building userspace code, not for building standalone/kernel
code, or the Sparse testsuite.
- Josh Triplett
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: sparse test failures on ppc32le (and other not so common archs)
2017-09-01 7:02 ` Josh Triplett
2017-09-01 7:57 ` Uwe Kleine-König
@ 2017-09-01 12:00 ` Christopher Li
2017-09-03 21:14 ` Luc Van Oostenryck
2 siblings, 0 replies; 55+ messages in thread
From: Christopher Li @ 2017-09-01 12:00 UTC (permalink / raw)
To: Josh Triplett
Cc: Uwe Kleine-König, Ramsay Jones, Linux-Sparse, 873508,
Antoine Beaupre
On Fri, Sep 1, 2017 at 3:02 AM, Josh Triplett <josh@joshtriplett.org> wrote:
>> First of all. It is not very trivial to teach sparse about the architecture
>> stuff. To my mind, we need to move all the cgcc logic into sparse.
>
> Related to that: while it would mean we couldn't necessarily just rely
> entirely on GCC's definitions for a target platform, I think in an ideal
> world we could have a sparse binary that understood *all* target
> platforms at once, such that you could ask Sparse on x86_64 to "compile"
Yes, that is what I want to have. It is list as one of the project in
project idea document as well. I have a related question. How do we
test the different architecture handling without actually run sparse
on different platform? I am thinking maybe using gcc cross platform
compiler and compare some macro against the sparse one.
> as though targeting any arbitrary architecture. That would also have the
> major advantage of making it easy to run the Sparse testsuite for
> *every* target architecture without needing compilers for every such
> architecture.
Another way to fix the test suite for now would be let testsuite
specify using cgcc instead of sparse directly, for the test source
that needs it. That will buy us some time. Fixing sparse properly
in the long term obvious would be better.
Chris
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: sparse test failures on ppc32le (and other not so common archs)
2017-09-01 7:02 ` Josh Triplett
2017-09-01 7:57 ` Uwe Kleine-König
2017-09-01 12:00 ` Christopher Li
@ 2017-09-03 21:14 ` Luc Van Oostenryck
2017-09-04 18:00 ` Christopher Li
[not found] ` <715b7059-4ff0-0982-ff92-56c13c4160e7@kleine-koenig.org>
2 siblings, 2 replies; 55+ messages in thread
From: Luc Van Oostenryck @ 2017-09-03 21:14 UTC (permalink / raw)
To: Josh Triplett
Cc: Christopher Li, Uwe Kleine-König, Ramsay Jones,
Linux-Sparse, 873508, Antoine Beaupre
On Fri, Sep 1, 2017 at 9:02 AM, Josh Triplett <josh@joshtriplett.org> wrote:
> On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
>> On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König <uwe@kleine-> Yes
>> that works. So to address the Debian bug I can do:
>> >
>> > - move sparse to /usr/lib
>> > - teach cgcc about the move of sparse
>> > - make /usr/bin/sparse call cgcc -no-compile "$@"
>>
>> I don't like that. It means the user can't invoke sparse directly.
>>
>> >
>> > or is it easier to teach sparse about the architecture stuff?
>>
>> First of all. It is not very trivial to teach sparse about the architecture
>> stuff. To my mind, we need to move all the cgcc logic into sparse.
>
> Related to that: while it would mean we couldn't necessarily just rely
> entirely on GCC's definitions for a target platform, I think in an ideal
> world we could have a sparse binary that understood *all* target
> platforms at once, such that you could ask Sparse on x86_64 to "compile"
> as though targeting any arbitrary architecture. That would also have the
> major advantage of making it easy to run the Sparse testsuite for
> *every* target architecture without needing compilers for every such
> architecture.
I really think that the testsuite should not depend on system or library
header.
Otherwise, I'm not at all opposed to sparse being universal but I would like
to note that things can become very quickly very very messy.
For example, for the current problem here I understood that it was
at least partially based on the lack of a definition of _CALL_ELF
but do we need to define it to 1 or to 2, in other words, do we need
to support the ELFv1 ABI or the ELFv2? GCC has some flags for this
(-mabi=elfv[12]) but what default value do we want? ELFv1 is the default
for big-endian platform and ELFv2 for little-endian platform, so yes,
we need a flag for the endianness but which endianness we want as default?
And so on.
Things become even more fun when taking in account the difference
between GCC version. Do we want to be universal there too (and thus
have some flags for to specify which gcc's version we want to mimick)?
What about other compilers?
I think that part of the needed info can be auto-extracted from GCC
when doing a native build. Using some sort of spec file or a .sparserc
can help too.
I also note that currently, sparse is already largely universal *because*
it *doesn't* need those platform details (or only the very minimal: word size).
-- Luc Van Oostenryck
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: sparse test failures on ppc32le (and other not so common archs)
2017-09-03 21:14 ` Luc Van Oostenryck
@ 2017-09-04 18:00 ` Christopher Li
[not found] ` <715b7059-4ff0-0982-ff92-56c13c4160e7@kleine-koenig.org>
1 sibling, 0 replies; 55+ messages in thread
From: Christopher Li @ 2017-09-04 18:00 UTC (permalink / raw)
To: Luc Van Oostenryck
Cc: Josh Triplett, Uwe Kleine-König, Ramsay Jones, Linux-Sparse,
873508, Antoine Beaupre
On Sun, Sep 3, 2017 at 5:14 PM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
>
> I really think that the testsuite should not depend on system or library
> header.
I think that is a good point. We can start cleaning up the system header
file dependency in the existing test suite. See how it goes.
>
> Otherwise, I'm not at all opposed to sparse being universal but I would like
> to note that things can become very quickly very very messy.
> For example, for the current problem here I understood that it was
> at least partially based on the lack of a definition of _CALL_ELF
> but do we need to define it to 1 or to 2, in other words, do we need
> to support the ELFv1 ABI or the ELFv2? GCC has some flags for this
> (-mabi=elfv[12]) but what default value do we want? ELFv1 is the default
I think we can just sparse default to as late as the latest release
version of gcc.
> for big-endian platform and ELFv2 for little-endian platform, so yes,
> we need a flag for the endianness but which endianness we want as default?
I am tempting to make the endianness the same as the host gcc by default.
Then it can be overwrite by architecture flags.
>
> Things become even more fun when taking in account the difference
> between GCC version. Do we want to be universal there too (and thus
> have some flags for to specify which gcc's version we want to mimick)?
> What about other compilers?
I purpose just sync to the latest gcc version (or a late enough version
we can agree on. e.g. the one that supported by kernel compile.) Sparse
current try to sync to the latest gcc attributes already.
> I think that part of the needed info can be auto-extracted from GCC
> when doing a native build. Using some sort of spec file or a .sparserc
Is there a way to do auto-extract? That would be a good starting point.
> I also note that currently, sparse is already largely universal *because*
> it *doesn't* need those platform details (or only the very minimal: word size).
Sparse is not universal, it just support a very small sub set of the C
source file that haven't expose to those platform detail macros. Adding
those architecture macro support will not make it any less universal.
Might slow things down, that is some thing we need to watch out for.
Chris
^ permalink raw reply [flat|nested] 55+ messages in thread[parent not found: <715b7059-4ff0-0982-ff92-56c13c4160e7@kleine-koenig.org>]
* Re: sparse test failures on ppc32le (and other not so common archs)
2017-09-01 0:47 ` sparse test failures on ppc32le (and other not so common archs) Christopher Li
2017-09-01 7:02 ` Josh Triplett
@ 2017-09-09 21:02 ` Uwe Kleine-König
2017-09-10 1:56 ` [PATCH] build: disable sparse-llvm on non-x86 Luc Van Oostenryck
1 sibling, 1 reply; 55+ messages in thread
From: Uwe Kleine-König @ 2017-09-09 21:02 UTC (permalink / raw)
To: Christopher Li; +Cc: Ramsay Jones, Linux-Sparse, 873508, Antoine Beaupre
[-- Attachment #1.1: Type: text/plain, Size: 2674 bytes --]
On Thu, Aug 31, 2017 at 08:47:55PM -0400, Christopher Li wrote:
> On Thu, Aug 31, 2017 at 4:55 PM, Uwe Kleine-König <uwe@kleine-> Yes
> that works. So to address the Debian bug I can do:
> >
> > - move sparse to /usr/lib
> > - teach cgcc about the move of sparse
> > - make /usr/bin/sparse call cgcc -no-compile "$@"
>
> I don't like that. It means the user can't invoke sparse directly.
>
> >
> > or is it easier to teach sparse about the architecture stuff?
>
> First of all. It is not very trivial to teach sparse about the architecture
> stuff. To my mind, we need to move all the cgcc logic into sparse.
>
> For this case, I think it is easier to teach the sparse validation
> code to use cgcc on those back end testing. Most validation don't
> need to include system header file at all so it does not have
> this problem.
>
> How about this patch?
> I know my patch is white space damaged in email.
> Git branch is at:
> https://git.kernel.org/pub/scm/devel/sparse/chrisl/sparse.git/log/?h=llvm-cgcc
>
> Please let me know if that fix your problem. It pass check
> on my local machine running x86_64. I don't have ppc64 to
> test with.
>
> Chris
>
> diff --git a/sparsec b/sparsec
> index 9dc96c9..2990d26 100755
> --- a/sparsec
> +++ b/sparsec
> @@ -32,7 +32,8 @@ done
> TMPLLVM=`mktemp -t tmp.XXXXXX`".llvm"
> TMPFILE=`mktemp -t tmp.XXXXXX`".o"
>
> -$DIRNAME/sparse-llvm $SPARSEOPTS > $TMPLLVM
> +env CHECK=$DIRNAME/sparse-llvm $DIRNAME/cgcc -no-compile \
> + $SPARSEOPTS > $TMPLLVM
>
> LLC=`"${LLVM_CONFIG:-llvm-config}" --bindir`/llc
>
> diff --git a/sparsei b/sparsei
> index 3431a9f..3abd00f 100755
> --- a/sparsei
> +++ b/sparsei
> @@ -10,4 +10,4 @@ if [ $# -eq 0 ]; then
> exit 1
> fi
>
> -$DIRNAME/sparse-llvm $@ | $LLI
> +env CHECK=$DIRNAME/sparse-llvm $DIRNAME/cgcc -no-compile $@ | $LLI
I tried this on ppc64le and it fixes 2 tests, so were at
Out of 287 tests, 273 passed, 14 failed (10 of them are known to fail)
The repaired tests are:
backend/hello.c
backend/sum.c
unexpected failures are:
backend/arithmetic-ops.c
backend/cmp-ops.c
backend/int-cond.c
backend/logical-ops.c
These are not about missing preprocessor tokens as there are no system
includes used, but the error there is
Error: unrecognized opcode: `...`
. I didn't look into what the problem is there, but attached the test
log.
I did a build test on a few other Debian machines, arm64 was fine, mips
and mipx64el had 15 failures, ppc64 (i.e. big endian) had 12. I didn't
look in more detail and suggest to tackle one after the other :-)
Best regards
Uwe
[-- Attachment #1.2: buildlog --]
[-- Type: text/plain, Size: 21705 bytes --]
I: Started sh -c make && make check
O: make: Nothing to be done for 'all'.
O: TEST Woverride-init-def (Woverride-init-def.c)
O: TEST Woverride-init-no (Woverride-init-no.c)
O: TEST Woverride-init-yes (Woverride-init-yes.c)
O: TEST warn-unknown-attribute (Wunknown-attribute-def.c)
O: TEST warn-unknown-attribute-no (Wunknown-attribute-no.c)
O: TEST warn-unknown-attribute-yes (Wunknown-attribute-yes.c)
O: TEST __func__ (__func__.c)
O: TEST abstract array declarator static (abstract-array-declarator-static.c)
O: TEST address_space attribute (address_space.c)
O: TEST alias distinct symbols (alias-distinct.c)
O: TEST alias symbol/pointer (alias-mixed.c)
O: TEST alias same symbols (alias-same.c)
O: TEST attribute __alloc_align__ (alloc-align.c)
O: TEST alternate keywords (alternate-keywords.c)
O: TEST test anonymous union initializer (anon-union.c)
O: TEST Asm with goto labels. (asm-empty-clobber.c)
O: TEST Asm with goto labels. (asm-goto-lables.c)
O: TEST asm-toplevel.c (asm-toplevel.c)
O: TEST inline attributes (attr-inline.c)
O: TEST attribute no_sanitize_address (attr-no_sanitize_address.c)
O: TEST attribute noclone (attr-noclone.c)
O: TEST optimize attributes (attr-optimize.c)
O: TEST attribute warning (attr-warning.c)
O: TEST attribute assume_aligned (attr_aligned.c)
O: TEST attribute after ( in direct-declarator (attr_in_parameter.c)
O: TEST attribute vector_size (attr_vector_size.c)
O: TEST Arithmetic operator code generation (backend/arithmetic-ops.c)
O: error: actual error text does not match expected error text.
O: error: see backend/arithmetic-ops.c.error.* for further investigation.
O: --- backend/arithmetic-ops.c.error.expected 2017-09-09 20:44:47.964306005 +0000
O: +++ backend/arithmetic-ops.c.error.got 2017-09-09 20:44:47.960305943 +0000
O: @@ -0,0 +1,10 @@
O: +{standard input}: Assembler messages:
O: +{standard input}:38: Error: unrecognized opcode: `xsaddsp'
O: +{standard input}:52: Error: unrecognized opcode: `xsadddp'
O: +{standard input}:94: Error: unrecognized opcode: `xssubsp'
O: +{standard input}:108: Error: unrecognized opcode: `xssubdp'
O: +{standard input}:150: Error: unrecognized opcode: `xsmulsp'
O: +{standard input}:164: Error: unrecognized opcode: `xsmuldp'
O: +{standard input}:206: Error: unrecognized opcode: `xsdivsp'
O: +{standard input}:220: Error: unrecognized opcode: `xsdivdp'
O: +mv: cannot stat '/tmp/tmp.8axUUC.o': No such file or directory
O: TEST Array code generation (backend/array.c)
O: TEST Bitwise operator code generation (backend/bitwise-ops.c)
O: TEST Boolean type code generation (backend/bool-test.c)
O: TEST Cast code generation (backend/cast.c)
O: TEST Comparison operator code generation (backend/cmp-ops.c)
O: error: actual error text does not match expected error text.
O: error: see backend/cmp-ops.c.error.* for further investigation.
O: --- backend/cmp-ops.c.error.expected 2017-09-09 20:44:48.320311523 +0000
O: +++ backend/cmp-ops.c.error.got 2017-09-09 20:44:48.316311461 +0000
O: @@ -0,0 +1,18 @@
O: +{standard input}: Assembler messages:
O: +{standard input}:13: Error: unrecognized opcode: `isel'
O: +{standard input}:29: Error: unrecognized opcode: `isel'
O: +{standard input}:46: Error: unrecognized opcode: `isel'
O: +{standard input}:63: Error: unrecognized opcode: `isel'
O: +{standard input}:79: Error: unrecognized opcode: `isel'
O: +{standard input}:95: Error: unrecognized opcode: `isel'
O: +{standard input}:112: Error: unrecognized opcode: `isel'
O: +{standard input}:129: Error: unrecognized opcode: `isel'
O: +{standard input}:145: Error: unrecognized opcode: `isel'
O: +{standard input}:161: Error: unrecognized opcode: `isel'
O: +{standard input}:178: Error: unrecognized opcode: `isel'
O: +{standard input}:194: Error: unrecognized opcode: `isel'
O: +{standard input}:211: Error: unrecognized opcode: `isel'
O: +{standard input}:228: Error: unrecognized opcode: `isel'
O: +{standard input}:245: Error: unrecognized opcode: `isel'
O: +{standard input}:262: Error: unrecognized opcode: `isel'
O: +mv: cannot stat '/tmp/tmp.DoTA0H.o': No such file or directory
O: TEST Extern symbol code generation (backend/extern.c)
O: TEST Function pointer code generation (backend/function-ptr.c)
O: TEST 'hello, world' code generation (backend/hello.c)
O: TEST Non-bool condition values in branch/select (backend/int-cond.c)
O: error: actual error text does not match expected error text.
O: error: see backend/int-cond.c.error.* for further investigation.
O: --- backend/int-cond.c.error.expected 2017-09-09 20:44:48.572315429 +0000
O: +++ backend/int-cond.c.error.got 2017-09-09 20:44:48.568315367 +0000
O: @@ -0,0 +1,4 @@
O: +{standard input}: Assembler messages:
O: +{standard input}:11: Error: unrecognized opcode: `isel'
O: +{standard input}:26: Error: unrecognized opcode: `isel'
O: +mv: cannot stat '/tmp/tmp.ytNQ13.o': No such file or directory
O: TEST Type of loaded objects (backend/load-type.c)
O: TEST Logical operator code generation (backend/logical-ops.c)
O: error: actual error text does not match expected error text.
O: error: see backend/logical-ops.c.error.* for further investigation.
O: --- backend/logical-ops.c.error.expected 2017-09-09 20:44:48.696317351 +0000
O: +++ backend/logical-ops.c.error.got 2017-09-09 20:44:48.692317289 +0000
O: @@ -0,0 +1,4 @@
O: +{standard input}: Assembler messages:
O: +{standard input}:14: Error: unrecognized opcode: `isel'
O: +{standard input}:32: Error: unrecognized opcode: `isel'
O: +mv: cannot stat '/tmp/tmp.onWlTP.o': No such file or directory
O: TEST Loops (backend/loop.c)
O: TEST Loops with unused counter (backend/loop2.c)
O: TEST Pointer cast code generation (backend/ptrcast.c)
O: TEST Type of stored objects (backend/store-type.c)
O: TEST struct access code generation (backend/struct-access.c)
O: TEST Struct code generation (backend/struct.c)
O: TEST sum from 1 to n (backend/sum.c)
O: TEST Union code generation (backend/union.c)
O: TEST void return type code generation (backend/void-return-type.c)
O: TEST Bad array designated initializer (bad-array-designated-initializer.c)
O: TEST bad assignment (bad-assignment.c)
O: TEST Bad cast syntax (bad-cast.c)
O: TEST Bad ternary syntax (bad-ternary-cond.c)
O: TEST Bad typeof syntax segfault (bad-typeof.c)
O: TEST enum not in scope (badtype1.c)
O: info: test 'badtype1.c' is known to fail
O: TEST missing type (badtype2.c)
O: TEST missing type in argument list (badtype3.c)
O: TEST switch(bad_type) {...} segfault (badtype4.c)
O: TEST badtype5.c (badtype5.c)
O: TEST binary constant (binary-constant.c)
O: TEST bitfield size (bitfield-size.c)
O: TEST bitfield to integer promotion (bitfields.c)
O: TEST conversions to bitwise types (bitwise-cast.c)
O: TEST sizeof(bool array) (bool-array.c)
O: TEST bool-cast-bad.c (bool-cast-bad.c)
O: TEST bool-cast-explicit (bool-cast-explicit.c)
O: TEST bool-cast-implicit (bool-cast-implicit.c)
O: TEST bool-cast-restricted.c (bool-cast-restricted.c)
O: TEST constant folding in bswap builtins (bswap-constant-folding.c)
O: TEST inlining switch statement (bug_inline_switch.c)
O: TEST builtin-args-checking (builtin-args-checking.c)
O: TEST builtin-bswap-constant (builtin-bswap-constant.c)
O: TEST builtin-bswap (builtin-bswap-variable.c)
O: TEST __builtin_atomic (builtin_atomic.c)
O: TEST __builtin_bswap (builtin_bswap.c)
O: TEST __builtin INFINITY / nan() (builtin_inf.c)
O: TEST __builtin_safe (builtin_safe1.c)
O: TEST __builtin_unreachable() (builtin_unreachable.c)
O: TEST __builtin_va_arg_pack() (builtin_va_arg_pack.c)
O: TEST c11-alignas (c11-alignas.c)
O: TEST c11-alignof (c11-alignof.c)
O: TEST c11-noreturn (c11-noreturn.c)
O: TEST c11-stdc-version (c11-stdc-version.c)
O: TEST c11-thread-local (c11-thread-local.c)
O: TEST C99 for-loop declarations (c99-for-loop-decl.c)
O: TEST C99 for loop variable declaration (c99-for-loop.c)
O: TEST Calling convention attributes (calling-convention-attributes.c)
O: TEST cast-constant-to-float (cast-constant-to-float.c)
O: TEST cast-constants.c (cast-constants.c)
O: TEST cast-kinds (cast-kinds.c)
O: TEST Segfault in check_byte_count after syntax error (check_byte_count-ice.c)
O: TEST choose expr builtin (choose_expr.c)
O: TEST Comma and array decay (comma.c)
O: TEST Compare null pointer constant to int (compare-null-to-int.c)
O: TEST compound-assign-type (compound-assign-type.c)
O: TEST cond-address-array.c (cond-address-array.c)
O: TEST cond-address-function (cond-address-function.c)
O: TEST cond-address.c (cond-address.c)
O: TEST cond-err-expand.c (cond-err-expand.c)
O: TEST Two-argument conditional expression types (cond_expr.c)
O: TEST type of conditional expression (cond_expr2.c)
O: TEST result type of relational and logical operators (cond_expr3.c)
O: TEST conditional-type (conditional-type.c)
O: TEST address of static object's member constness verification. (constexpr-addr-of-static-member.c)
O: TEST address of static object constness verification. (constexpr-addr-of-static.c)
O: TEST Expression constness propagation in binops and alike (constexpr-binop.c)
O: TEST Expression constness propagation in casts (constexpr-cast.c)
O: TEST compound literal address constness verification (constexpr-compound-literal.c)
O: TEST Expression constness propagation in conditional expressions (constexpr-conditional.c)
O: TEST static storage object initializer constness verification. (constexpr-init.c)
O: TEST label reference constness verification. (constexpr-labelref.c)
O: TEST __builtin_offsetof() constness verification. (constexpr-offsetof.c)
O: TEST pointer arithmetic constness verification. (constexpr-pointer-arith.c)
O: TEST integer literal cast to pointer type constness verification. (constexpr-pointer-cast.c)
O: TEST Expression constness propagation in preops (constexpr-preop.c)
O: TEST constness of pure/const builtins (constexpr-pure-builtin.c)
O: TEST string literal constness verification. (constexpr-string.c)
O: TEST __builtin_types_compatible_p() constness verification. (constexpr-types-compatible-p.c)
O: TEST Check -Wcontext (context.c)
O: TEST crash add-doms (crash-add-doms.c)
O: TEST crash bb_target (crash-bb_target.c)
O: TEST crash ep->active (crash-ep-active.c)
O: TEST crash ptrlist (crash-ptrlist.c)
O: TEST crash rewrite_branch (crash-rewrite-branch.c)
O: TEST crazy02-not-so.c (crazy02-not-so.c)
O: TEST crazy03.c (crazy03.c)
O: TEST declaration after statement (ANSI) (declaration-after-statement-ansi.c)
O: TEST declaration after statement (C89) (declaration-after-statement-c89.c)
O: TEST declaration after statement (C99) (declaration-after-statement-c99.c)
O: TEST declaration after statement (default) (declaration-after-statement-default.c)
O: TEST finding definitions (definitions.c)
O: TEST designated_init attribute (designated-init.c)
O: TEST discarded-label-statement (discarded-label-statement.c)
O: TEST division constants (div.c)
O: TEST Double semicolon in struct (double-semicolon.c)
O: TEST Dubious bitwise operation on !x (dubious-bitwise-with-not.c)
O: TEST endian-big.c (endian-big.c)
O: TEST endian-little.c (endian-little.c)
O: TEST enum-mismatch (enum-mismatch.c)
O: TEST enumeration constants' scope [6.2.1p7] (enum_scope.c)
O: TEST Character escape sequences (escapes.c)
O: TEST duplicate extern array (extern-array.c)
O: TEST extern inline function (extern-inline.c)
O: TEST field overlap (field-overlap.c)
O: TEST field-override (field-override.c)
O: TEST Forced function argument type. (fored_arg.c)
O: TEST foul bitwise (foul-bitwise.c)
O: TEST fp-vs-ptrcast (fp-vs-ptrcast.c)
O: TEST Function pointer inheritance (function-pointer-inheritance.c)
O: TEST function-redecl (function-redecl.c)
O: TEST goto labels (goto-label.c)
O: TEST identifier-list parsing (identifier_list.c)
O: TEST implicit-ret-type.c (implicit-ret-type.c)
O: TEST implicit-type.c (implicit-type.c)
O: TEST internal infinite loop (0) (infinite-loop0.c)
O: TEST infinite loop 02 (infinite-loop02.c)
O: TEST infinite loop 03 (infinite-loop03.c)
O: TEST char array initializers (init-char-array.c)
O: TEST parenthesized string initializer (init-char-array1.c)
O: TEST -Winit-cstring option (init_cstring.c)
O: TEST Initializer entry defined twice (initializer-entry-defined-twice.c)
O: TEST inline compound literals (inline_compound_literals.c)
O: TEST int128 (int128.c)
O: TEST Integer promotions (integer-promotions.c)
O: TEST integer constant & conditional expression (ioc-typecheck.c)
O: info: test 'ioc-typecheck.c' is known to fail
O: TEST kill-casts (kill-casts.c)
O: TEST kill-computedgoto (kill-computedgoto.c)
O: TEST kill-cse (kill-cse.c)
O: TEST kill insert-branch (kill-insert-branch.c)
O: TEST kill-load (kill-load.c)
O: TEST kill-phi-node (kill-phi-node.c)
O: TEST kill-phi-ttsbb (kill-phi-ttsbb.c)
O: TEST kill-phi-ttsbb2 (kill-phi-ttsbb2.c)
O: TEST kill-phisrc (kill-phisrc.c)
O: TEST kill-pure-call (kill-pure-call.c)
O: TEST kill-replaced-insn (kill-replaced-insn.c)
O: TEST kill-rewritten-load (kill-rewritten-load.c)
O: TEST kill-select (kill-select.c)
O: TEST kill-slice (kill-slice.c)
O: TEST kill-store (kill-store.c)
O: TEST kill-unreachable-phi (kill-unreachable-phi.c)
O: TEST Label followed by __asm__ (label-asm.c)
O: TEST Label attribute (label-attr.c)
O: TEST label-expr (label-expr.c)
O: TEST __label__ scope (label-scope.c)
O: TEST bitfield initializer mask (linear/bitfield-init-mask.c)
O: TEST bitfield implicit init zero (linear/bitfield-init-zero.c)
O: TEST missing instruction's size (linear/missing-insn-size.c)
O: TEST struct implicit init zero not needed (linear/struct-init-full.c)
O: info: test 'linear/struct-init-full.c' is known to fail
O: TEST struct implicit init zero needed (linear/struct-init-partial.c)
O: TEST Local label (local-label.c)
O: TEST Logical and/or (logical.c)
O: TEST loop-linearization (loop-linearization.c)
O: TEST Expansion of typeof when dealing with member of struct (member_of_typeof.c)
O: TEST memops-volatile (memops-volatile.c)
O: TEST handling of identifier-less declarations (missing-ident.c)
O: TEST typedefs with many declarators (multi_typedef.c)
O: TEST nested declarator vs. parameters (nested-declarator.c)
O: TEST more on handling of ( in direct-declarator (nested-declarator2.c)
O: TEST nocast.c (nocast.c)
O: TEST noderef attribute (noderef.c)
O: TEST Using plain integer as NULL pointer (non-pointer-null.c)
O: TEST Old initializer with -Wno-old-initializer (old-initializer-nowarn.c)
O: TEST Old initializer (old-initializer.c)
O: TEST double-unop (optim/binops-same-args.c)
O: TEST bool-context (optim/bool-context.c)
O: TEST bool-same-args (optim/bool-same-args.c)
O: TEST bool-simplify (optim/bool-simplify.c)
O: TEST cse-commutativity (optim/cse-commutativity.c)
O: TEST cse-dual-compare (optim/cse-dual-compare.c)
O: info: test 'optim/cse-dual-compare.c' is known to fail
O: TEST double-unop (optim/double-unop.c)
O: TEST fpcast-nop (optim/fpcast-nop.c)
O: TEST muldiv-by-one (optim/muldiv-by-one.c)
O: TEST muldiv-by-zero (optim/muldiv-by-zero.c)
O: TEST muldiv-minus-one (optim/muldiv-minus-one.c)
O: TEST optim/setcc-setcc (optim/setcc-setcc.c)
O: TEST optim/setcc-seteq (optim/setcc-seteq.c)
O: TEST optim/setcc-setne (optim/setcc-setne.c)
O: TEST Ignore VOID in if-convert (optim/void-if-convert.c)
O: TEST There is no scope boundary between global and file scope (outer-scope.c)
O: TEST #pragma once (pragma-once.c)
O: TEST __COUNTER__ #1 (preprocessor/counter1.c)
O: TEST __COUNTER__ #2 (preprocessor/counter2.c)
O: TEST __COUNTER__ #3 (preprocessor/counter3.c)
O: TEST dump-macros with empty file (preprocessor/dump-macros-empty.c)
O: TEST dump-macros with multiple files (preprocessor/dump-macros-multi.c)
O: TEST dump-macros (preprocessor/dump-macros.c)
O: TEST early-escape (preprocessor/early-escape.c)
O: TEST predefined __<type>_BIT__ (preprocessor/predef-char-bit.c)
O: TEST predefined __<type>_MAX__ (preprocessor/predef-max.c)
O: TEST predefined __SIZEOF_<type>__ (preprocessor/predef-sizeof.c)
O: TEST Preprocessor #1 (preprocessor/preprocessor1.c)
O: TEST Preprocessor #10 (preprocessor/preprocessor10.c)
O: TEST Preprocessor #11 (preprocessor/preprocessor11.c)
O: TEST Preprocessor #12 (preprocessor/preprocessor12.c)
O: TEST Preprocessor #13 (preprocessor/preprocessor13.c)
O: TEST Preprocessor #14 (preprocessor/preprocessor14.c)
O: TEST Preprocessor #15 (preprocessor/preprocessor15.c)
O: TEST Preprocessor #16 (preprocessor/preprocessor16.c)
O: TEST Preprocessor #17 (preprocessor/preprocessor17.c)
O: TEST Preprocessor #18 (preprocessor/preprocessor18.c)
O: TEST Preprocessor #19 (preprocessor/preprocessor19.c)
O: TEST Preprocessor #2 (preprocessor/preprocessor2.c)
O: TEST Preprocessor #20 (preprocessor/preprocessor20.c)
O: TEST Preprocessor #21 (preprocessor/preprocessor21.c)
O: TEST Preprocessor #22 (preprocessor/preprocessor22.c)
O: TEST Preprocessor #23 (preprocessor/preprocessor23.c)
O: TEST Preprocessor #3 (preprocessor/preprocessor3.c)
O: TEST Preprocessor #4 (preprocessor/preprocessor4.c)
O: TEST Preprocessor #5 (preprocessor/preprocessor5.c)
O: TEST Preprocessor #6 (preprocessor/preprocessor6.c)
O: TEST Preprocessor #7 (preprocessor/preprocessor7.c)
O: TEST Preprocessor #8 (preprocessor/preprocessor8.c)
O: TEST Preprocessor #9 (preprocessor/preprocessor9.c)
O: TEST Preprocessor #14 (preprocessor/stringify.c)
O: TEST wide char token-pasting (preprocessor/wide.c)
O: TEST Compile skip function prototype (prototype.c)
O: TEST ptr-inherit.c (ptr-inherit.c)
O: TEST Pure function attribute (pure-function.c)
O: TEST const et.al. are reserved identifiers (reserved.c)
O: TEST restrict array attribute (restrict-array.c)
O: TEST typeof with bitwise types (restricted-typeof.c)
O: TEST sizeof(_Bool) is valid (sizeof-bool.c)
O: TEST Handling of sizeof compound-literal . member (sizeof-compound-postfix.c)
O: TEST valid specifier combinations (specifiers1.c)
O: TEST invalid specifier combinations (specifiers2.c)
O: TEST static forward declaration (static-forward-decl.c)
O: TEST static assertion (static_assert.c)
O: TEST Address space of a struct member (struct-as.c)
O: TEST struct attribute placement (struct-attribute-placement.c)
O: TEST struct namespaces #1 (struct-ns1.c)
O: TEST struct not in scope (struct-ns2.c)
O: info: test 'struct-ns2.c' is known to fail
O: TEST struct size (struct-size1.c)
O: TEST tautological-compare (tautological-compare.c)
O: TEST binary operations (test-be.c)
O: TEST selfcheck1 (testsuite-selfcheck1.c)
O: TEST selfcheck2 (testsuite-selfcheck2.c)
O: info: test 'testsuite-selfcheck2.c' is known to fail
O: TEST selfcheck3 (testsuite-selfcheck3.c)
O: info: test 'testsuite-selfcheck3.c' is known to fail
O: TEST Transparent union attribute. (transparent-union.c)
O: TEST "char []" to "char *" demotion (type1.c)
O: TEST typedef shadowing (typedef_shadow.c)
O: TEST typeof-addresspace.c (typeof-addresspace.c)
O: info: test 'typeof-addresspace.c' is known to fail
O: TEST Rusty Russell's typeof attribute casting. (typeof-attribute.c)
O: TEST typeof-mods (typeof-mods.c)
O: TEST typeof-noderef (typeof-noderef.c)
O: info: test 'typeof-noderef.c' is known to fail
O: TEST typeof-safe (typeof-safe.c)
O: info: test 'typeof-safe.c' is known to fail
O: TEST -Wtypesign (typesign.c)
O: TEST Varargs bogus warning regression test #1 (varargs1.c)
O: TEST wide character constants (wide.c)
E: make: *** [check] Error 1
O: Out of 287 tests, 273 passed, 14 failed (10 of them are known to fail)
O: Makefile:232: recipe for target 'check' failed
I: Finished with exitcode 2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread* [PATCH] build: disable sparse-llvm on non-x86
2017-09-09 21:02 ` Uwe Kleine-König
@ 2017-09-10 1:56 ` Luc Van Oostenryck
2017-09-12 6:02 ` Christopher Li
2017-09-12 7:01 ` Christopher Li
0 siblings, 2 replies; 55+ messages in thread
From: Luc Van Oostenryck @ 2017-09-10 1:56 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Christopher Li, linux-sparse, Antoine Beaupre, Luc Van Oostenryck
sparse-llvm doesn't have support for targets other than
x86 or x86-64.
Disable sparse-llvm on other archs as it create problems during
build, selftest, ...
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
---
Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Makefile b/Makefile
index 84bb133da..d51b60733 100644
--- a/Makefile
+++ b/Makefile
@@ -90,6 +90,7 @@ $(warning Your system does not have gtk3/gtk2, disabling test-inspect)
endif
ifeq ($(HAVE_LLVM),yes)
+ifeq ($(shell uname -m | grep -q '\(i386\|x86\)' && echo ok),ok)
LLVM_VERSION:=$(shell $(LLVM_CONFIG) --version)
ifeq ($(shell expr "$(LLVM_VERSION)" : '[3-9]\.'),2)
LLVM_PROGS := sparse-llvm
@@ -106,6 +107,9 @@ else
$(warning LLVM 3.0 or later required. Your system has version $(LLVM_VERSION) installed.)
endif
else
+$(warning sparse-llvm disabled on $(shell uname -m))
+endif
+else
$(warning Your system does not have llvm, disabling sparse-llvm)
endif
--
2.14.0
^ permalink raw reply related [flat|nested] 55+ messages in thread
* Re: [PATCH] build: disable sparse-llvm on non-x86
2017-09-10 1:56 ` [PATCH] build: disable sparse-llvm on non-x86 Luc Van Oostenryck
@ 2017-09-12 6:02 ` Christopher Li
2017-09-12 6:12 ` Luc Van Oostenryck
2017-09-12 7:01 ` Christopher Li
1 sibling, 1 reply; 55+ messages in thread
From: Christopher Li @ 2017-09-12 6:02 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: Uwe Kleine-König, Linux-Sparse, Antoine Beaupre
On Sat, Sep 9, 2017 at 9:56 PM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
> sparse-llvm doesn't have support for targets other than
> x86 or x86-64.
>
> Disable sparse-llvm on other archs as it create problems during
> build, selftest, ...
Thanks, will apply.
This is temporary while we looking at how to fix the other
architecture properly, right?
Chris
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] build: disable sparse-llvm on non-x86
2017-09-12 6:02 ` Christopher Li
@ 2017-09-12 6:12 ` Luc Van Oostenryck
2017-09-12 6:27 ` Christopher Li
0 siblings, 1 reply; 55+ messages in thread
From: Luc Van Oostenryck @ 2017-09-12 6:12 UTC (permalink / raw)
To: Christopher Li; +Cc: Uwe Kleine-König, Linux-Sparse, Antoine Beaupre
On Tue, Sep 12, 2017 at 8:02 AM, Christopher Li <sparse@chrisli.org> wrote:
> On Sat, Sep 9, 2017 at 9:56 PM, Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
>> sparse-llvm doesn't have support for targets other than
>> x86 or x86-64.
>>
>> Disable sparse-llvm on other archs as it create problems during
>> build, selftest, ...
>
> Thanks, will apply.
>
> This is temporary while we looking at how to fix the other
> architecture properly, right?
Everything is temporary, isn't it? ;)
In the other thread I explained the nature of the problem, it's *just* a
question to match the options for the model/sub-architecture between
LLVM compiler and the assembler.
Easy to do if you choose the dumbest (generic) model, pretty annoying
otherwise and a nightmare to test.
-- Luc
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] build: disable sparse-llvm on non-x86
2017-09-12 6:12 ` Luc Van Oostenryck
@ 2017-09-12 6:27 ` Christopher Li
2017-09-12 6:34 ` Luc Van Oostenryck
0 siblings, 1 reply; 55+ messages in thread
From: Christopher Li @ 2017-09-12 6:27 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: Uwe Kleine-König, Linux-Sparse, Antoine Beaupre
On Tue, Sep 12, 2017 at 2:12 AM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
>
> Everything is temporary, isn't it? ;)
>
Of course :-)
> In the other thread I explained the nature of the problem, it's *just* a
> question to match the options for the model/sub-architecture between
> LLVM compiler and the assembler.
> Easy to do if you choose the dumbest (generic) model, pretty annoying
> otherwise and a nightmare to test.
Yes, I saw the other email you have it pretty much figure out
already. I am tempting just pick up an used apple G5 and install
Linux on it for ppc64 testing.
Chris
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] build: disable sparse-llvm on non-x86
2017-09-12 6:27 ` Christopher Li
@ 2017-09-12 6:34 ` Luc Van Oostenryck
2017-09-12 6:44 ` Christopher Li
0 siblings, 1 reply; 55+ messages in thread
From: Luc Van Oostenryck @ 2017-09-12 6:34 UTC (permalink / raw)
To: Christopher Li; +Cc: Uwe Kleine-König, Linux-Sparse, Antoine Beaupre
On Tue, Sep 12, 2017 at 8:27 AM, Christopher Li <sparse@chrisli.org> wrote:
> On Tue, Sep 12, 2017 at 2:12 AM, Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
>>
>> Everything is temporary, isn't it? ;)
>>
>
> Of course :-)
>
>> In the other thread I explained the nature of the problem, it's *just* a
>> question to match the options for the model/sub-architecture between
>> LLVM compiler and the assembler.
>> Easy to do if you choose the dumbest (generic) model, pretty annoying
>> otherwise and a nightmare to test.
>
> Yes, I saw the other email you have it pretty much figure out
> already. I am tempting just pick up an used apple G5 and install
> Linux on it for ppc64 testing.
It's not the problem.
I tested it on a ppc64le (power8) machine while I investigated the
problem. So let's say that it's solved/tested for ppc64. Then what
about all the other models & archs?
-- Luc
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] build: disable sparse-llvm on non-x86
2017-09-12 6:34 ` Luc Van Oostenryck
@ 2017-09-12 6:44 ` Christopher Li
2017-09-12 6:48 ` Luc Van Oostenryck
0 siblings, 1 reply; 55+ messages in thread
From: Christopher Li @ 2017-09-12 6:44 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: Uwe Kleine-König, Linux-Sparse, Antoine Beaupre
On Tue, Sep 12, 2017 at 2:34 AM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
> It's not the problem.
> I tested it on a ppc64le (power8) machine while I investigated the
> problem. So let's say that it's solved/tested for ppc64. Then what
> about all the other models & archs?
For problem like this one happen on the host side of the package,
I don't have a magic solution either. I guess we will just fix the
bugs that we know. Then let other people who has the access to
those model & archs do the testing and report back.
Mean while, we can make it easy to enable and disable
llvm, similar to a config file. The user don't have to patch
sparse in order to disable sparse-llvm compiling.
Chris
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] build: disable sparse-llvm on non-x86
2017-09-12 6:44 ` Christopher Li
@ 2017-09-12 6:48 ` Luc Van Oostenryck
2017-09-12 7:04 ` Christopher Li
0 siblings, 1 reply; 55+ messages in thread
From: Luc Van Oostenryck @ 2017-09-12 6:48 UTC (permalink / raw)
To: Christopher Li; +Cc: Uwe Kleine-König, Linux-Sparse, Antoine Beaupre
On Tue, Sep 12, 2017 at 8:44 AM, Christopher Li <sparse@chrisli.org> wrote:
> On Tue, Sep 12, 2017 at 2:34 AM, Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
>> It's not the problem.
>> I tested it on a ppc64le (power8) machine while I investigated the
>> problem. So let's say that it's solved/tested for ppc64. Then what
>> about all the other models & archs?
>
> For problem like this one happen on the host side of the package,
> I don't have a magic solution either. I guess we will just fix the
> bugs that we know. Then let other people who has the access to
> those model & archs do the testing and report back.
>
> Mean while, we can make it easy to enable and disable
> llvm, similar to a config file. The user don't have to patch
> sparse in order to disable sparse-llvm compiling.
Hence the patch.
I think you should take it for master.
-- Luc
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] build: disable sparse-llvm on non-x86
2017-09-12 6:48 ` Luc Van Oostenryck
@ 2017-09-12 7:04 ` Christopher Li
0 siblings, 0 replies; 55+ messages in thread
From: Christopher Li @ 2017-09-12 7:04 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: Uwe Kleine-König, Linux-Sparse, Antoine Beaupre
On Tue, Sep 12, 2017 at 2:48 AM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
>
> Hence the patch.
> I think you should take it for master.
>
Sure, I want to.
There is some minor feed back on testing of the compiling
LLVM or not. It is just which path we take to apply it.
Chris
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] build: disable sparse-llvm on non-x86
2017-09-10 1:56 ` [PATCH] build: disable sparse-llvm on non-x86 Luc Van Oostenryck
2017-09-12 6:02 ` Christopher Li
@ 2017-09-12 7:01 ` Christopher Li
2017-09-12 7:10 ` Luc Van Oostenryck
1 sibling, 1 reply; 55+ messages in thread
From: Christopher Li @ 2017-09-12 7:01 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: Uwe Kleine-König, Linux-Sparse, Antoine Beaupre
On Sat, Sep 9, 2017 at 9:56 PM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
>
> ifeq ($(HAVE_LLVM),yes)
> +ifeq ($(shell uname -m | grep -q '\(i386\|x86\)' && echo ok),ok)
> LLVM_VERSION:=$(shell $(LLVM_CONFIG) --version)
> ifeq ($(shell expr "$(LLVM_VERSION)" : '[3-9]\.'),2)
> LLVM_PROGS := sparse-llvm
> @@ -106,6 +107,9 @@ else
> $(warning LLVM 3.0 or later required. Your system has version $(LLVM_VERSION) installed.)
> endif
> else
> +$(warning sparse-llvm disabled on $(shell uname -m))
> +endif
> +else
> $(warning Your system does not have llvm, disabling sparse-llvm)
> endif
>
BTW, while I am looking at this, I think the if else testing is getting
a bit too deep for the rules define of sparse-llvm.
Right now we have three excuses not to compile llvm:
1) not x86,
2) LLVM version too old
3) Host does not have llvm.
All of those testing mixing with the actual llvm rules and flags.
I think we can test three level of excuses first, then come to
conclusion of ENABLE_LLVM(or CONFIG_LLVM) or not.
The rules that define sparse-llvm related stuff should just
put inside one level of ENABLE_LLVM.
some thing like:
ifeq ($(ENABLE_LLVM),yes)
LLVM_LDFLAGS = ...
other llvm flags and rules.
endif
Do you want to come up with V2? Or I can apply your current patch
first then do the incremental update on master to use ENABLE_LLVM
or CONFIG_LLVM
Which way do you prefer?
I will need to take a crash very soon. To be continue...
Chris
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: [PATCH] build: disable sparse-llvm on non-x86
2017-09-12 7:01 ` Christopher Li
@ 2017-09-12 7:10 ` Luc Van Oostenryck
2017-09-12 15:53 ` Christopher Li
0 siblings, 1 reply; 55+ messages in thread
From: Luc Van Oostenryck @ 2017-09-12 7:10 UTC (permalink / raw)
To: Christopher Li; +Cc: Uwe Kleine-König, Linux-Sparse, Antoine Beaupre
On Tue, Sep 12, 2017 at 9:01 AM, Christopher Li <sparse@chrisli.org> wrote:
> On Sat, Sep 9, 2017 at 9:56 PM, Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
>>
>> ifeq ($(HAVE_LLVM),yes)
>> +ifeq ($(shell uname -m | grep -q '\(i386\|x86\)' && echo ok),ok)
>> LLVM_VERSION:=$(shell $(LLVM_CONFIG) --version)
>> ifeq ($(shell expr "$(LLVM_VERSION)" : '[3-9]\.'),2)
>> LLVM_PROGS := sparse-llvm
>> @@ -106,6 +107,9 @@ else
>> $(warning LLVM 3.0 or later required. Your system has version $(LLVM_VERSION) installed.)
>> endif
>> else
>> +$(warning sparse-llvm disabled on $(shell uname -m))
>> +endif
>> +else
>> $(warning Your system does not have llvm, disabling sparse-llvm)
>> endif
>>
>
> BTW, while I am looking at this, I think the if else testing is getting
> a bit too deep for the rules define of sparse-llvm.
> Right now we have three excuses not to compile llvm:
> 1) not x86,
> 2) LLVM version too old
> 3) Host does not have llvm.
> All of those testing mixing with the actual llvm rules and flags.
>
> I think we can test three level of excuses first, then come to
> conclusion of ENABLE_LLVM(or CONFIG_LLVM) or not.
>
> The rules that define sparse-llvm related stuff should just
> put inside one level of ENABLE_LLVM.
> some thing like:
>
> ifeq ($(ENABLE_LLVM),yes)
> LLVM_LDFLAGS = ...
> other llvm flags and rules.
> endif
>
> Do you want to come up with V2? Or I can apply your current patch
> first then do the incremental update on master to use ENABLE_LLVM
> or CONFIG_LLVM
>
> Which way do you prefer?
Please do as is the easiest for you.
I don't mind as I don't have something that depend on it.
-- Luc
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: [PATCH] build: disable sparse-llvm on non-x86
2017-09-12 7:10 ` Luc Van Oostenryck
@ 2017-09-12 15:53 ` Christopher Li
0 siblings, 0 replies; 55+ messages in thread
From: Christopher Li @ 2017-09-12 15:53 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: Uwe Kleine-König, Linux-Sparse, Antoine Beaupre
On Tue, Sep 12, 2017 at 3:10 AM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
>
> Please do as is the easiest for you.
> I don't mind as I don't have something that depend on it.
I have test your change does not conflict with my other Makefile
overhaul of the debug build. I already apply your patch to master.
Next thing is merge the debug build overhaul then add the config
option on top of that.
The master branch has been updated and pushed.
Thanks
Chris
^ permalink raw reply [flat|nested] 55+ messages in thread
* Bug#873508: sparse test failures on ppc32le (and other not so common archs)
[not found] <150392922734.24087.13050909898214597041.reportbug@curie.anarc.at>
2017-08-30 16:14 ` Bug#873508: sparse test failures on ppc32le (and other not so common archs) Uwe Kleine-König
@ 2017-09-01 11:33 ` Antoine Beaupré
2017-09-10 1:22 ` Luc Van Oostenryck
` (8 subsequent siblings)
10 siblings, 0 replies; 55+ messages in thread
From: Antoine Beaupré @ 2017-09-01 11:33 UTC (permalink / raw)
To: Uwe Kleine-König, Ramsay Jones; +Cc: Christopher Li, Linux-Sparse, 873508
On 2017-09-01 09:46:44, Uwe Kleine-König wrote:
> Hello,
>
> On Thu, Aug 31, 2017 at 11:43:53PM +0100, Ramsay Jones wrote:
>> On 31/08/17 21:55, Uwe Kleine-König wrote:
>> > On Wed, Aug 30, 2017 at 08:11:49PM -0400, Christopher Li wrote:
>> >> That is very much like on x86_64 missing define "#weak_define __x86_64__ 1"
>> >>
>> >> Does cgcc work for you? In the future we do want to move the archetecture
>> >> related define from cgcc into sparse by itself. For now you can set
>> >> "sparse" as "cgcc -no-compile"
>> >
>> > Yes that works. So to address the Debian bug I can do:
>> >
>> > - move sparse to /usr/lib
>> > - teach cgcc about the move of sparse
>> > - make /usr/bin/sparse call cgcc -no-compile "$@"
>>
>> Hmm, I don't think that would be a good idea ...
>>
>> > or is it easier to teach sparse about the architecture stuff?
>>
>> I now understand (I think!) that you are building a sparse
>> package (presumably a .deb) and you are concerned that sparse
>> does not pass it's own testsuite on those platforms.
>
> Nearly right. I'm responsible for the sparse Debian package and the
> problem at hand is https://bugs.debian.org/873508. This bug report has
> "Severity: serious" wihch might eventually result in the removal of
> sparse from the Debian archive.
>
> @anarcat: Given that cgcc seems to work, would you agree to apply the
> following patch to horst:
>
> diff --git a/Makefile b/Makefile
> index 4f924fa..d563652 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -110,7 +110,7 @@ $(NAME): $(OBJS)
> $(OBJS): .buildflags
>
> check:
> - sparse $(CFLAGS) *.[ch]
> + cgcc -no-compile $(CFLAGS) *.[ch]
>
> clean:
> -rm -f *.o radiotap/*.o *~
>
> and downgrade the bug to "important"? That would be a compromise that
> buys us a bit of time.
Well right now I have simply disabled the checks for those broken
architectures, so sparse isn't as affected anymore.
Frankly, I don't quite know what to do with this - but I'd be happy to
happly that patch to sparse if it fixes the issue better.
A.
--
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin, 1755
^ permalink raw reply [flat|nested] 55+ messages in thread* Bug#873508: sparse test failures on ppc32le (and other not so common archs)
[not found] <150392922734.24087.13050909898214597041.reportbug@curie.anarc.at>
2017-08-30 16:14 ` Bug#873508: sparse test failures on ppc32le (and other not so common archs) Uwe Kleine-König
2017-09-01 11:33 ` Bug#873508: sparse test failures on ppc32le (and other not so common archs) Antoine Beaupré
@ 2017-09-10 1:22 ` Luc Van Oostenryck
2017-09-10 8:43 ` Uwe Kleine-König
2017-09-10 12:29 ` Bug#873508: " Luc Van Oostenryck
` (7 subsequent siblings)
10 siblings, 1 reply; 55+ messages in thread
From: Luc Van Oostenryck @ 2017-09-10 1:22 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Christopher Li, Ramsay Jones, Linux-Sparse, 873508, Antoine Beaupre
On Sat, Sep 9, 2017 at 11:02 PM, Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
>
> I tried this on ppc64le and it fixes 2 tests, so were at
>
> Out of 287 tests, 273 passed, 14 failed (10 of them are known to fail)
>
> The repaired tests are:
>
> backend/hello.c
> backend/sum.c
>
> unexpected failures are:
>
> backend/arithmetic-ops.c
> backend/cmp-ops.c
> backend/int-cond.c
> backend/logical-ops.c
>
> These are not about missing preprocessor tokens as there are no system
> includes used, but the error there is
>
> Error: unrecognized opcode: `...`
>
> . I didn't look into what the problem is there, but attached the test
> log.
It clearly looks as the code generated by LLVM (the machine code/assembly
not LLVM's bytecode) is not understood by the assembler (or at least some
instructions). Probably a mismatch with the architecture version or something
like that.
> I did a build test on a few other Debian machines, arm64 was fine, mips
> and mipx64el had 15 failures, ppc64 (i.e. big endian) had 12. I didn't
> look in more detail and suggest to tackle one after the other :-)
I fully test on x86, x86-64, arm & ARM64 (with LLVM 3.9 or 4.0).
I also test on ppc64 but not the LLVM part because the machines I have
access to have not LLVM installed and I never bothered to install it myself.
Would it be possible to have access to a machine with the architectures
you care about?
Meanwhile, is it possible to have the build logs but with 'make V=1 ...' ?
It would also be useful to have:
- the output of 'uname -a'
- the details about the version of LLVM you're using
On the other hand, you/us should disable the sparse-llvm part since:
- it's something that is bundled and build by default but absolutely not
needed (or even useful) to use sparse.
- it hasn't been written for anything else than x86/x86-64 (no 'layout'
for anything else than those architectures.
Best regards,
-- Luc Van Ooostenryck
^ permalink raw reply [flat|nested] 55+ messages in thread* Re: sparse test failures on ppc32le (and other not so common archs)
2017-09-10 1:22 ` Luc Van Oostenryck
@ 2017-09-10 8:43 ` Uwe Kleine-König
2017-09-10 9:39 ` Luc Van Oostenryck
0 siblings, 1 reply; 55+ messages in thread
From: Uwe Kleine-König @ 2017-09-10 8:43 UTC (permalink / raw)
To: Luc Van Oostenryck
Cc: Christopher Li, Ramsay Jones, Linux-Sparse, 873508, Antoine Beaupre
[-- Attachment #1.1.1: Type: text/plain, Size: 2554 bytes --]
On 09/10/2017 03:22 AM, Luc Van Oostenryck wrote:
> On Sat, Sep 9, 2017 at 11:02 PM, Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
>>
>> I tried this on ppc64le and it fixes 2 tests, so were at
>>
>> Out of 287 tests, 273 passed, 14 failed (10 of them are known to fail)
>>
>> The repaired tests are:
>>
>> backend/hello.c
>> backend/sum.c
>>
>> unexpected failures are:
>>
>> backend/arithmetic-ops.c
>> backend/cmp-ops.c
>> backend/int-cond.c
>> backend/logical-ops.c
>>
>> These are not about missing preprocessor tokens as there are no system
>> includes used, but the error there is
>>
>> Error: unrecognized opcode: `...`
>>
>> . I didn't look into what the problem is there, but attached the test
>> log.
>
> It clearly looks as the code generated by LLVM (the machine code/assembly
> not LLVM's bytecode) is not understood by the assembler (or at least some
> instructions). Probably a mismatch with the architecture version or something
> like that.
>
>> I did a build test on a few other Debian machines, arm64 was fine, mips
>> and mipx64el had 15 failures, ppc64 (i.e. big endian) had 12. I didn't
>> look in more detail and suggest to tackle one after the other :-)
>
> I fully test on x86, x86-64, arm & ARM64 (with LLVM 3.9 or 4.0).
> I also test on ppc64 but not the LLVM part because the machines I have
> access to have not LLVM installed and I never bothered to install it myself.
>
> Would it be possible to have access to a machine with the architectures
> you care about?
Debian provides access to porter boxes for such problems. See
https://dsa.debian.org/doc/guest-account/.
> Meanwhile, is it possible to have the build logs but with 'make V=1 ...' ?
> It would also be useful to have:
> - the output of 'uname -a'
> - the details about the version of LLVM you're using
Sure, can do. Attached is a build from the ppc64el machine with Chris'
patch applied. Tell me if it contains everything you need.
> On the other hand, you/us should disable the sparse-llvm part since:
> - it's something that is bundled and build by default but absolutely not
> needed (or even useful) to use sparse.
> - it hasn't been written for anything else than x86/x86-64 (no 'layout'
> for anything else than those architectures.
With your patch applied I get (independent of having Chris' patch
applied or not):
Out of 265 tests, 255 passed, 10 failed (10 of them are known to fail)
Best regards
Uwe
[-- Attachment #1.1.2: buildlog-23a393b1cd48ea50bff94fa4a1e2c02a5d78d9cb+ --]
[-- Type: application/octet-stream, Size: 57588 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread
* Re: sparse test failures on ppc32le (and other not so common archs)
2017-09-10 8:43 ` Uwe Kleine-König
@ 2017-09-10 9:39 ` Luc Van Oostenryck
0 siblings, 0 replies; 55+ messages in thread
From: Luc Van Oostenryck @ 2017-09-10 9:39 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Christopher Li, Ramsay Jones, Linux-Sparse, 873508, Antoine Beaupre
On Sun, Sep 10, 2017 at 10:43 AM, Uwe Kleine-König
<uwe@kleine-koenig.org> wrote:
> On 09/10/2017 03:22 AM, Luc Van Oostenryck wrote:
>>
>> I fully test on x86, x86-64, arm & ARM64 (with LLVM 3.9 or 4.0).
>> I also test on ppc64 but not the LLVM part because the machines I have
>> access to have not LLVM installed and I never bothered to install it myself.
>>
>> Would it be possible to have access to a machine with the architectures
>> you care about?
>
> Debian provides access to porter boxes for such problems. See
> https://dsa.debian.org/doc/guest-account/.
OK.
I'll first try to install LLVM on what I have already access, it
should be faster.
>> Meanwhile, is it possible to have the build logs but with 'make V=1 ...' ?
>> It would also be useful to have:
>> - the output of 'uname -a'
>> - the details about the version of LLVM you're using
>
> Sure, can do. Attached is a build from the ppc64el machine with Chris'
> patch applied. Tell me if it contains everything you need.
Yes, enough to investigate the problem. Thanks.
>> On the other hand, you/us should disable the sparse-llvm part since:
>> - it's something that is bundled and build by default but absolutely not
>> needed (or even useful) to use sparse.
>> - it hasn't been written for anything else than x86/x86-64 (no 'layout'
>> for anything else than those architectures.
>
> With your patch applied I get (independent of having Chris' patch
> applied or not):
>
> Out of 265 tests, 255 passed, 10 failed (10 of them are known to fail)
Perfect.
With this, you should be unblocked.
@Chris,
can you apply the patch, please?
Best regards,
-- Luc Van Oostenryck
^ permalink raw reply [flat|nested] 55+ messages in thread
* Bug#873508: sparse test failures on ppc32le (and other not so common archs)
[not found] <150392922734.24087.13050909898214597041.reportbug@curie.anarc.at>
` (2 preceding siblings ...)
2017-09-10 1:22 ` Luc Van Oostenryck
@ 2017-09-10 12:29 ` Luc Van Oostenryck
2018-04-27 5:56 ` Uwe Kleine-König
` (6 subsequent siblings)
10 siblings, 0 replies; 55+ messages in thread
From: Luc Van Oostenryck @ 2017-09-10 12:29 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Christopher Li, Ramsay Jones, Linux-Sparse, 873508, Antoine Beaupre
On Sun, Sep 10, 2017 at 10:43 AM, Uwe Kleine-König
<uwe@kleine-koenig.org> wrote:
>
>> Meanwhile, is it possible to have the build logs but with 'make V=1 ...' ?
>> It would also be useful to have:
>> - the output of 'uname -a'
>> - the details about the version of LLVM you're using
>
> Sure, can do. Attached is a build from the ppc64el machine with Chris'
> patch applied. Tell me if it contains everything you need.
I've taken a look at it what happens.
The problem is easy to identify and very annoying to solve:
in sparsec (a wrapper for sparse-llvm + llc + as [+ ld]) there
is a discrepancy between the defaults for llc and as.
'llc' seems to default to the sub-architecture of the build machine
(possibly including the most modern features) while 'as' defaults
to the minimal features for the build machine architecture.
The problem can be solved (on the machine I have access to) by either:
- using the option "-mgeneric" for llc
- using the option "-mpower8" for as
Something smarter would be better.
-- Luc
^ permalink raw reply [flat|nested] 55+ messages in thread* Bug#873508: sparse test failures on ppc32le (and other not so common archs)
[not found] <150392922734.24087.13050909898214597041.reportbug@curie.anarc.at>
` (3 preceding siblings ...)
2017-09-10 12:29 ` Bug#873508: " Luc Van Oostenryck
@ 2018-04-27 5:56 ` Uwe Kleine-König
2018-04-27 7:33 ` Bug#873508: sparse test failures & PATH_MAX Luc Van Oostenryck
` (5 subsequent siblings)
10 siblings, 0 replies; 55+ messages in thread
From: Uwe Kleine-König @ 2018-04-27 5:56 UTC (permalink / raw)
To: linux-sparse; +Cc: 873508, Antoine Beaupre
[-- Attachment #1.1: Type: text/plain, Size: 1269 bytes --]
Hello,
On 08/30/2017 06:14 PM, Uwe Kleine-König wrote:
> Antoine Beaupre (on Cc:) noticed that sparse doesn't work on some not so
> common architectures like ppc32le, s390x, ppc64 and sparc64[1]. This is
> nicely catched by the testsuite, e.g.:
>
> [..]
Just a heads up: I uploaded 0.5.2 to Debian and there are problems left
on hurd-i386 (where PATH_MAX isn't defined[1]) and x32 where I get:
env CHECK=./sparse ./cgcc -no-compile memops.c
/usr/include/x86_64-linux-gnux32/gnu/stubs.h:10:12: error: unable to
open 'gnu/stubs-64.h'
The stubs.h file looks as follows:
#if !defined __x86_64__
# include <gnu/stubs-32.h>
#endif
#if defined __x86_64__ && defined __LP64__
# include <gnu/stubs-64.h>
#endif
#if defined __x86_64__ && defined __ILP32__
# include <gnu/stubs-x32.h>
#endif
Given that libc6-dev only provides stubs-x32.h from these three, I guess
we must not define __LP64__ in this case. I don't have a x32 machine
handy, but the complete build log of the auto builder can be found at
https://buildd.debian.org/status/fetch.php?pkg=sparse&arch=x32&ver=0.5.2-1&stamp=1524169455&raw=0
Best regards
Uwe
[1]
https://buildd.debian.org/status/fetch.php?pkg=sparse&arch=hurd-i386&ver=0.5.2-1&stamp=1524168405&raw=0
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread* Bug#873508: sparse test failures & PATH_MAX
[not found] <150392922734.24087.13050909898214597041.reportbug@curie.anarc.at>
` (4 preceding siblings ...)
2018-04-27 5:56 ` Uwe Kleine-König
@ 2018-04-27 7:33 ` Luc Van Oostenryck
2018-04-27 7:33 ` Uwe Kleine-König
` (4 subsequent siblings)
10 siblings, 0 replies; 55+ messages in thread
From: Luc Van Oostenryck @ 2018-04-27 7:33 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: linux-sparse, 873508, Antoine Beaupre
On Fri, Apr 27, 2018 at 07:56:38AM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On 08/30/2017 06:14 PM, Uwe Kleine-König wrote:
> > Antoine Beaupre (on Cc:) noticed that sparse doesn't work on some not so
> > common architectures like ppc32le, s390x, ppc64 and sparc64[1]. This is
> > nicely catched by the testsuite, e.g.:
> >
> > [..]
>
> Just a heads up: I uploaded 0.5.2 to Debian and there are problems left
> on hurd-i386 (where PATH_MAX isn't defined[1])
> ...
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=sparse&arch=hurd-i386&ver=0.5.2-1&stamp=1524168405&raw=0
Thanks for the repport.
I'll see what can be done.
-- Luc
^ permalink raw reply [flat|nested] 55+ messages in thread* Bug#873508: sparse test failures & PATH_MAX
[not found] <150392922734.24087.13050909898214597041.reportbug@curie.anarc.at>
` (5 preceding siblings ...)
2018-04-27 7:33 ` Bug#873508: sparse test failures & PATH_MAX Luc Van Oostenryck
@ 2018-04-27 7:33 ` Uwe Kleine-König
2018-04-27 7:43 ` Bug#873508: sparse test failures on x32 Luc Van Oostenryck
` (3 subsequent siblings)
10 siblings, 0 replies; 55+ messages in thread
From: Uwe Kleine-König @ 2018-04-27 7:33 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: linux-sparse, 873508, Antoine Beaupre
[-- Attachment #1.1: Type: text/plain, Size: 826 bytes --]
On 04/27/2018 09:33 AM, Luc Van Oostenryck wrote:
> On Fri, Apr 27, 2018 at 07:56:38AM +0200, Uwe Kleine-König wrote:
>> Hello,
>>
>> On 08/30/2017 06:14 PM, Uwe Kleine-König wrote:
>>> Antoine Beaupre (on Cc:) noticed that sparse doesn't work on some not so
>>> common architectures like ppc32le, s390x, ppc64 and sparc64[1]. This is
>>> nicely catched by the testsuite, e.g.:
>>>
>>> [..]
>>
>> Just a heads up: I uploaded 0.5.2 to Debian and there are problems left
>> on hurd-i386 (where PATH_MAX isn't defined[1])
>> ...
>> [1]
>> https://buildd.debian.org/status/fetch.php?pkg=sparse&arch=hurd-i386&ver=0.5.2-1&stamp=1524168405&raw=0
>
> Thanks for the repport.
> I'll see what can be done.
I think the default idiom is:
#ifndef PATH_MAX
#define PATH_MAX 4096
#endif
Best regards
Uwe
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 55+ messages in thread* Bug#873508: sparse test failures on x32
[not found] <150392922734.24087.13050909898214597041.reportbug@curie.anarc.at>
` (6 preceding siblings ...)
2018-04-27 7:33 ` Uwe Kleine-König
@ 2018-04-27 7:43 ` Luc Van Oostenryck
2018-04-27 16:11 ` Bug#873508: sparse test failures & PATH_MAX Luc Van Oostenryck
` (2 subsequent siblings)
10 siblings, 0 replies; 55+ messages in thread
From: Luc Van Oostenryck @ 2018-04-27 7:43 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: linux-sparse, 873508, Antoine Beaupre
On Fri, Apr 27, 2018 at 07:56:38AM +0200, Uwe Kleine-König wrote:
> Hello,
>
> On 08/30/2017 06:14 PM, Uwe Kleine-König wrote:
> > Antoine Beaupre (on Cc:) noticed that sparse doesn't work on some not so
> > common architectures like ppc32le, s390x, ppc64 and sparc64[1]. This is
> > nicely catched by the testsuite, e.g.:
> >
> > [..]
>
> Just a heads up: I uploaded 0.5.2 to Debian and there are problems left
> ...
> and x32 where I get:
>
> env CHECK=./sparse ./cgcc -no-compile memops.c
> /usr/include/x86_64-linux-gnux32/gnu/stubs.h:10:12: error: unable to
> open 'gnu/stubs-64.h'
>
> The stubs.h file looks as follows:
>
> #if !defined __x86_64__
> # include <gnu/stubs-32.h>
> #endif
> #if defined __x86_64__ && defined __LP64__
> # include <gnu/stubs-64.h>
> #endif
> #if defined __x86_64__ && defined __ILP32__
> # include <gnu/stubs-x32.h>
> #endif
>
> Given that libc6-dev only provides stubs-x32.h from these three, I guess
> we must not define __LP64__ in this case.
Mmmm, yes, surely.
For the moment sparse use __LP64__ unconditionnaly for __x86_64__.
> I don't have a x32 machine
But can you launch a test build for sparse easily enough?
I guess that there is no install CD available yet?
-- Luc
^ permalink raw reply [flat|nested] 55+ messages in thread* Bug#873508: sparse test failures & PATH_MAX
[not found] <150392922734.24087.13050909898214597041.reportbug@curie.anarc.at>
` (7 preceding siblings ...)
2018-04-27 7:43 ` Bug#873508: sparse test failures on x32 Luc Van Oostenryck
@ 2018-04-27 16:11 ` Luc Van Oostenryck
2019-01-10 2:28 ` Bug#873508: sparse test failures on ppc32le (and other not so common archs) Antoine Beaupré
2019-01-10 11:39 ` Luc Van Oostenryck
10 siblings, 0 replies; 55+ messages in thread
From: Luc Van Oostenryck @ 2018-04-27 16:11 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: linux-sparse, 873508, Antoine Beaupre
On Fri, Apr 27, 2018 at 09:33:55AM +0200, Uwe Kleine-König wrote:
> On 04/27/2018 09:33 AM, Luc Van Oostenryck wrote:
> > On Fri, Apr 27, 2018 at 07:56:38AM +0200, Uwe Kleine-König wrote:
> >> Hello,
> >>
> >>> [..]
> >>
> >> Just a heads up: I uploaded 0.5.2 to Debian and there are problems left
> >> on hurd-i386 (where PATH_MAX isn't defined[1])
> >> ...
> >> [1]
> >> https://buildd.debian.org/status/fetch.php?pkg=sparse&arch=hurd-i386&ver=0.5.2-1&stamp=1524168405&raw=0
> >
> > Thanks for the repport.
> > I'll see what can be done.
>
> I think the default idiom is:
>
> #ifndef PATH_MAX
> #define PATH_MAX 4096
> #endif
Yes.
I had hoped to avoid this together with removing a memcpy() but things are
more annoying than I had first thought.
Best regards,
-- Luc
^ permalink raw reply [flat|nested] 55+ messages in thread* Bug#873508: sparse test failures on ppc32le (and other not so common archs)
[not found] <150392922734.24087.13050909898214597041.reportbug@curie.anarc.at>
` (8 preceding siblings ...)
2018-04-27 16:11 ` Bug#873508: sparse test failures & PATH_MAX Luc Van Oostenryck
@ 2019-01-10 2:28 ` Antoine Beaupré
2019-01-10 11:39 ` Luc Van Oostenryck
10 siblings, 0 replies; 55+ messages in thread
From: Antoine Beaupré @ 2019-01-10 2:28 UTC (permalink / raw)
To: Uwe Kleine-König, Ramsay Jones; +Cc: Christopher Li, Linux-Sparse, 873508
Control: forwarded -1 https://github.com/br101/horst/issues/93
On 2017-09-01 10:46:44, Uwe Kleine-König wrote:
> Hello,
>
> On Thu, Aug 31, 2017 at 11:43:53PM +0100, Ramsay Jones wrote:
>> On 31/08/17 21:55, Uwe Kleine-König wrote:
>> > On Wed, Aug 30, 2017 at 08:11:49PM -0400, Christopher Li wrote:
>> >> That is very much like on x86_64 missing define "#weak_define __x86_64__ 1"
>> >>
>> >> Does cgcc work for you? In the future we do want to move the archetecture
>> >> related define from cgcc into sparse by itself. For now you can set
>> >> "sparse" as "cgcc -no-compile"
>> >
>> > Yes that works. So to address the Debian bug I can do:
>> >
>> > - move sparse to /usr/lib
>> > - teach cgcc about the move of sparse
>> > - make /usr/bin/sparse call cgcc -no-compile "$@"
>>
>> Hmm, I don't think that would be a good idea ...
>>
>> > or is it easier to teach sparse about the architecture stuff?
>>
>> I now understand (I think!) that you are building a sparse
>> package (presumably a .deb) and you are concerned that sparse
>> does not pass it's own testsuite on those platforms.
>
> Nearly right. I'm responsible for the sparse Debian package and the
> problem at hand is https://bugs.debian.org/873508. This bug report has
> "Severity: serious" wihch might eventually result in the removal of
> sparse from the Debian archive.
>
> @anarcat: Given that cgcc seems to work, would you agree to apply the
> following patch to horst:
>
> diff --git a/Makefile b/Makefile
> index 4f924fa..d563652 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -110,7 +110,7 @@ $(NAME): $(OBJS)
> $(OBJS): .buildflags
>
> check:
> - sparse $(CFLAGS) *.[ch]
> + cgcc -no-compile $(CFLAGS) *.[ch]
>
> clean:
> -rm -f *.o radiotap/*.o *~
>
> and downgrade the bug to "important"? That would be a compromise that
> buys us a bit of time.
For what it's worth, this doesn't work with the latest horst. I've
reported the bug upstream now and disabled the checks for all
architectures now that it also fails on amd64.
A.
--
Wire telegraph is a kind of a very, very long cat. You pull his tail
in New York and his head is meowing in Los Angeles. Radio operates
exactly the same way: you send signals here, they receive them
there. The only difference is that there is no cat.
- Albert Einstein [apocryphal]
^ permalink raw reply [flat|nested] 55+ messages in thread* Bug#873508: sparse test failures on ppc32le (and other not so common archs)
[not found] <150392922734.24087.13050909898214597041.reportbug@curie.anarc.at>
` (9 preceding siblings ...)
2019-01-10 2:28 ` Bug#873508: sparse test failures on ppc32le (and other not so common archs) Antoine Beaupré
@ 2019-01-10 11:39 ` Luc Van Oostenryck
10 siblings, 0 replies; 55+ messages in thread
From: Luc Van Oostenryck @ 2019-01-10 11:39 UTC (permalink / raw)
To: Antoine Beaupré
Cc: Uwe Kleine-König, Ramsay Jones, Christopher Li,
Linux-Sparse, 873508
On Wed, Jan 09, 2019 at 09:28:54PM -0500, Antoine Beaupré wrote:
> Control: forwarded -1 https://github.com/br101/horst/issues/93
Hi,
The issue showed there, more precisely the one:
/usr/include/x86_64-linux-gnu/bits/mathcalls-helper-functions.h:21:1: error: Expected ) in function declarator
is caused by sparse's lack of support for _Float128 and occurs with
recent version of glibc.
This has been fixed and upstreamed (see
https://git.kernel.org/pub/scm/devel/sparse/sparse.git/commit/?id=4e9c8ee467dd87d41d5aaa3c5a487e3f05ffb79c
for more details).
Best regards,
-- Luc
^ permalink raw reply [flat|nested] 55+ messages in thread