* extra 'make check' failures on 32bit Linux
@ 2017-03-26 22:21 Ramsay Jones
2017-03-26 23:56 ` Luc Van Oostenryck
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Ramsay Jones @ 2017-03-26 22:21 UTC (permalink / raw)
To: Christopher Li, Luc Van Oostenryck; +Cc: Sparse Mailing-list
Hi Christopher, Luc,
On occasion I build sparse on 32-bit Linux and I have noticed, for some
weeks now, unexpected test failures. I have been meaning to take a look
at fixing these failures, but I just haven't had the time ... :(
So, as the next best thing, I thought I should at least let you know
about the failures, viz:
$ make check
Makefile:66: Your system does not have libxml, disabling c2xml
Makefile:78: Your system does not have libgtk2, disabling test-inspect
Makefile:98: Your system does not have llvm, disabling sparse-llvm
TEST abstract array declarator static (abstract-array-declarator-static.c)
TEST address_space attribute (address_space.c)
...
TEST bool-cast-explicit (bool-cast-explicit.c)
error: Actual output contains some patterns which are not expected.
TEST bool-cast-implicit (bool-cast-implicit.c)
error: Actual output contains some patterns which are not expected.
...
TEST call-inlined (call-inlined.c)
error: actual output text does not match expected output text.
error: see call-inlined.c.output.* for further investigation.
--- call-inlined.c.output.expected 2017-03-26 18:26:03.358108923 +0100
+++ call-inlined.c.output.got 2017-03-26 18:26:03.370120836 +0100
@@ -15,14 +15,14 @@
bas:
.L6:
<entry-point>
- add.64 %r16 <- "abc", $1
- ret.64 %r16
+ add.32 %r16 <- "abc", $1
+ ret.32 %r16
qus:
.L9:
<entry-point>
- add.64 %r21 <- messg, $1
- ret.64 %r21
+ add.32 %r21 <- messg, $1
+ ret.32 %r21
TEST call-variadic (call-variadic.c)
error: actual output text does not match expected output text.
error: see call-variadic.c.output.* for further investigation.
--- call-variadic.c.output.expected 2017-03-26 18:26:03.398148634 +0100
+++ call-variadic.c.output.got 2017-03-26 18:26:03.402152605 +0100
@@ -1,14 +1,14 @@
foo:
.L0:
<entry-point>
- push.64 "msg %c: %d %d/%ld %ld/%p %p\n"
+ push.32 "msg %c: %d %d/%ld %ld/%p %p\n"
push.32 $120
push.32 %arg2
push.32 $7
- push.64 %arg3
- push.64 $0
- push.64 %arg4
- push.64 $0
+ push.32 %arg3
+ push.32 $0
+ push.32 %arg4
+ push.32 $0
call.32 %r5 <- print
ret.32 %r5
...
TEST division constants (div.c)
error: actual error text does not match expected error text.
error: see div.c.error.* for further investigation.
--- div.c.error.expected 2017-03-26 18:26:04.142887258 +0100
+++ div.c.error.got 2017-03-26 18:26:04.142887258 +0100
@@ -2,8 +2,6 @@
div.c:4:20: warning: division by zero
div.c:5:22: warning: division by zero
div.c:7:25: warning: constant integer operation overflow
-div.c:8:27: warning: constant integer operation overflow
div.c:9:34: warning: constant integer operation overflow
div.c:11:25: warning: constant integer operation overflow
-div.c:12:27: warning: constant integer operation overflow
div.c:13:34: warning: constant integer operation overflow
...
TEST warn-unknown-attribute-yes (Wunknown-attribute-yes.c)
Out of 210 tests, 196 passed, 14 failed (9 of them are known to fail)
39 tests were disabled
Makefile:213: recipe for target 'check' failed
make: *** [check] Error 1
$ cat validation/bool-cast-explicit.c.output.got
fs32:
.L0:
<entry-point>
setne.1 %r2 <- %arg1, $0
ret.1 %r2
fu32:
.L2:
<entry-point>
setne.1 %r5 <- %arg1, $0
ret.1 %r5
fvdp:
.L4:
<entry-point>
cast.32 %r8 <- (32) %arg1
setne.1 %r9 <- %r8, $0
ret.1 %r9
fsip:
.L6:
<entry-point>
cast.32 %r12 <- (32) %arg1
setne.1 %r13 <- %r12, $0
ret.1 %r13
fdbl:
.L8:
<entry-point>
set.64 %r16 <- 0.000000
setne.1 %r17 <- %arg1, %r16
ret.1 %r17
ffun:
.L10:
<entry-point>
cast.32 %r20 <- (32) ffun
setne.1 %r21 <- %r20, $0
ret.1 %r21
fres:
.L12:
<entry-point>
setne.1 %r24 <- %arg1, $0
ret.1 %r24
$
Note that the output file for bool-cast-implicit.c is identical to the
above file for bool-cast-explicit.c, so I haven't included it here.
Again, I haven't had time to look properly, but it seems that some
expected output files assume a 64-bit platform and that long and pointers
are 64-bit rather than 32-bit. (or something like that :-) )
ATB,
Ramsay Jones
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: extra 'make check' failures on 32bit Linux
2017-03-26 22:21 extra 'make check' failures on 32bit Linux Ramsay Jones
@ 2017-03-26 23:56 ` Luc Van Oostenryck
2017-03-27 1:03 ` Luc Van Oostenryck
2017-03-27 7:51 ` Christopher Li
2 siblings, 0 replies; 8+ messages in thread
From: Luc Van Oostenryck @ 2017-03-26 23:56 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Christopher Li, Sparse Mailing-list
On Sun, Mar 26, 2017 at 11:21:44PM +0100, Ramsay Jones wrote:
> Hi Christopher, Luc,
>
> On occasion I build sparse on 32-bit Linux and I have noticed, for some
> weeks now, unexpected test failures. I have been meaning to take a look
> at fixing these failures, but I just haven't had the time ... :(
>
> So, as the next best thing, I thought I should at least let you know
> about the failures, viz:
>
> ...
>
> Note that the output file for bool-cast-implicit.c is identical to the
> above file for bool-cast-explicit.c, so I haven't included it here.
>
> Again, I haven't had time to look properly, but it seems that some
> expected output files assume a 64-bit platform and that long and pointers
> are 64-bit rather than 32-bit. (or something like that :-) )
You're absolutely right. My bad.
I'll update all that.
Thanks for letting know.
-- Luc
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: extra 'make check' failures on 32bit Linux
2017-03-26 22:21 extra 'make check' failures on 32bit Linux Ramsay Jones
2017-03-26 23:56 ` Luc Van Oostenryck
@ 2017-03-27 1:03 ` Luc Van Oostenryck
2017-03-27 15:27 ` Ramsay Jones
2017-03-27 7:51 ` Christopher Li
2 siblings, 1 reply; 8+ messages in thread
From: Luc Van Oostenryck @ 2017-03-27 1:03 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Christopher Li, Sparse Mailing-list
On Sun, Mar 26, 2017 at 11:21:44PM +0100, Ramsay Jones wrote:
> Hi Christopher, Luc,
>
> On occasion I build sparse on 32-bit Linux and I have noticed, for some
> weeks now, unexpected test failures. I have been meaning to take a look
> at fixing these failures, but I just haven't had the time ... :(
> ...
>
> TEST division constants (div.c)
> error: actual error text does not match expected error text.
> error: see div.c.error.* for further investigation.
> --- div.c.error.expected 2017-03-26 18:26:04.142887258 +0100
> +++ div.c.error.got 2017-03-26 18:26:04.142887258 +0100
> @@ -2,8 +2,6 @@
> div.c:4:20: warning: division by zero
> div.c:5:22: warning: division by zero
> div.c:7:25: warning: constant integer operation overflow
> -div.c:8:27: warning: constant integer operation overflow
> div.c:9:34: warning: constant integer operation overflow
> div.c:11:25: warning: constant integer operation overflow
> -div.c:12:27: warning: constant integer operation overflow
> div.c:13:34: warning: constant integer operation overflow
> ...
It's not very clear to me what is the cause of this error.
Have you only since some weeks (then I think it's since the
we define __SIZEOF_POINTER__) or is it older (then I think
it exists since quite a long time)?
-- Luc
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: extra 'make check' failures on 32bit Linux
2017-03-27 1:03 ` Luc Van Oostenryck
@ 2017-03-27 15:27 ` Ramsay Jones
2017-03-27 16:10 ` Luc Van Oostenryck
0 siblings, 1 reply; 8+ messages in thread
From: Ramsay Jones @ 2017-03-27 15:27 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: Christopher Li, Sparse Mailing-list
On 27/03/17 02:03, Luc Van Oostenryck wrote:
> On Sun, Mar 26, 2017 at 11:21:44PM +0100, Ramsay Jones wrote:
>> Hi Christopher, Luc,
>>
>> On occasion I build sparse on 32-bit Linux and I have noticed, for some
>> weeks now, unexpected test failures. I have been meaning to take a look
>> at fixing these failures, but I just haven't had the time ... :(
>
>> ...
>>
>> TEST division constants (div.c)
>> error: actual error text does not match expected error text.
>> error: see div.c.error.* for further investigation.
>> --- div.c.error.expected 2017-03-26 18:26:04.142887258 +0100
>> +++ div.c.error.got 2017-03-26 18:26:04.142887258 +0100
>> @@ -2,8 +2,6 @@
>> div.c:4:20: warning: division by zero
>> div.c:5:22: warning: division by zero
>> div.c:7:25: warning: constant integer operation overflow
>> -div.c:8:27: warning: constant integer operation overflow
>> div.c:9:34: warning: constant integer operation overflow
>> div.c:11:25: warning: constant integer operation overflow
>> -div.c:12:27: warning: constant integer operation overflow
>> div.c:13:34: warning: constant integer operation overflow
>> ...
>
> It's not very clear to me what is the cause of this error.
> Have you only since some weeks (then I think it's since the
> we define __SIZEOF_POINTER__) or is it older (then I think
> it exists since quite a long time)?
I just did a git bisect, which shows:
...
$ git bisect good
8d688c9a6ee220ce00b30afd8bdffa34434c9950 is the first bad commit
commit 8d688c9a6ee220ce00b30afd8bdffa34434c9950
Author: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Date: Tue Feb 7 21:04:24 2017 +0100
define __LONG_MAX__ & __SIZEOF_POINTER__
They're part of GCC's common predefined macros and some
code & header files depends on them.
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Christopher Li <sparse@chrisli.org>
:100644 100644 38ff165b360525c2b83cd76d674593ee79cb9ffb 65887c40d3b5b020991be2372b0af5c1b7088776 M lib.c
$
So, I looked in the debugger and 'bits_in_long' and 'bits_in_pointer'
are set correctly, but __LONG_MAX__ is being printed with an LL suffix,
so, this fixes it for me:
$ git diff
diff --git a/lib.c b/lib.c
index 272d2c8..502c264 100644
--- a/lib.c
+++ b/lib.c
@@ -834,7 +834,7 @@ static void predefined_macros(void)
add_pre_buffer("#define __CHECKER__ 1\n");
val = (1ULL << (bits_in_long-1)) - 1;
- add_pre_buffer("#weak_define __LONG_MAX__ %#llxLL\n", val);
+ add_pre_buffer("#weak_define __LONG_MAX__ %#llxL\n", val);
add_pre_buffer("#weak_define __SIZEOF_POINTER__ %d\n", bits_in_pointer/8);
}
$
Not a proper fix, but ...
Ah, I've just noticed you have sent some patches. ;-)
I will take a look and let you know.
ATB,
Ramsay Jones
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: extra 'make check' failures on 32bit Linux
2017-03-27 15:27 ` Ramsay Jones
@ 2017-03-27 16:10 ` Luc Van Oostenryck
2017-03-27 16:53 ` Ramsay Jones
0 siblings, 1 reply; 8+ messages in thread
From: Luc Van Oostenryck @ 2017-03-27 16:10 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Christopher Li, Sparse Mailing-list
On Mon, Mar 27, 2017 at 5:27 PM, Ramsay Jones
<ramsay@ramsayjones.plus.com> wrote:
> So, I looked in the debugger and 'bits_in_long' and 'bits_in_pointer'
> are set correctly, but __LONG_MAX__ is being printed with an LL suffix,
> so, this fixes it for me:
>
> $ git diff
> diff --git a/lib.c b/lib.c
> index 272d2c8..502c264 100644
> --- a/lib.c
> +++ b/lib.c
> @@ -834,7 +834,7 @@ static void predefined_macros(void)
> add_pre_buffer("#define __CHECKER__ 1\n");
>
> val = (1ULL << (bits_in_long-1)) - 1;
> - add_pre_buffer("#weak_define __LONG_MAX__ %#llxLL\n", val);
> + add_pre_buffer("#weak_define __LONG_MAX__ %#llxL\n", val);
> add_pre_buffer("#weak_define __SIZEOF_POINTER__ %d\n", bits_in_pointer/8);
> }
>
> $
>
> Not a proper fix, but ...
Well, actually it is the proper fix as __LONG_MAX__ is supposed to be
a 'long' and not a 'long long'.
> Ah, I've just noticed you have sent some patches. ;-)
>
> I will take a look and let you know.
OK, thanks.
It should be OK as I new tested it on a 32bit machine but
another environment is always good for testing.
-- Luc
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: extra 'make check' failures on 32bit Linux
2017-03-27 16:10 ` Luc Van Oostenryck
@ 2017-03-27 16:53 ` Ramsay Jones
2017-03-27 17:15 ` Luc Van Oostenryck
0 siblings, 1 reply; 8+ messages in thread
From: Ramsay Jones @ 2017-03-27 16:53 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: Christopher Li, Sparse Mailing-list
On 27/03/17 17:10, Luc Van Oostenryck wrote:
> On Mon, Mar 27, 2017 at 5:27 PM, Ramsay Jones
> <ramsay@ramsayjones.plus.com> wrote:
>
>> So, I looked in the debugger and 'bits_in_long' and 'bits_in_pointer'
>> are set correctly, but __LONG_MAX__ is being printed with an LL suffix,
>> so, this fixes it for me:
>>
>> $ git diff
>> diff --git a/lib.c b/lib.c
>> index 272d2c8..502c264 100644
>> --- a/lib.c
>> +++ b/lib.c
>> @@ -834,7 +834,7 @@ static void predefined_macros(void)
>> add_pre_buffer("#define __CHECKER__ 1\n");
>>
>> val = (1ULL << (bits_in_long-1)) - 1;
>> - add_pre_buffer("#weak_define __LONG_MAX__ %#llxLL\n", val);
>> + add_pre_buffer("#weak_define __LONG_MAX__ %#llxL\n", val);
>> add_pre_buffer("#weak_define __SIZEOF_POINTER__ %d\n", bits_in_pointer/8);
>> }
>>
>> $
>>
>> Not a proper fix, but ...
>
> Well, actually it is the proper fix as __LONG_MAX__ is supposed to be
> a 'long' and not a 'long long'.
>
>> Ah, I've just noticed you have sent some patches. ;-)
>>
>> I will take a look and let you know.
>
> OK, thanks.
> It should be OK as I new tested it on a 32bit machine but
> another environment is always good for testing.
OK, so I tested the 5 patch series + the v2 patch that you sent
out on Linux 64bit, Linux 32bit and cygwin 64bit.
I applied the patches on top of the current 'sparse-next' branch:
$ git branch -v
chrisl-master ce18a90 sparse: update __builtin_object_size() prototype
master fbbfc73 simplify float-to-float casts that doesn't change size
mingw 9e96dd5 test-suite: Add -b option to ignore CR at eol on MinGW
sparse-next f7817f0 llvm: cleanup of output_[ptr]cast()
* sparse-next-tmp df7cd04 fix expansion of integers to floats
$ git log --oneline sparse-next..
df7cd04 fix expansion of integers to floats
83de8c4 do not depends on limits.h to test __CHAR_BIT__
ac9f7b4 fix test validation/div.c
153d5cf predefine __SIZEOF_INT__ & friends
a3a916c predefine __INT_MAX__ and friends
26a0a0a fix test for cast to bool on 32bit machines
$
On Linux 64bit, I get:
$ make check
...
Out of 214 tests, 205 passed, 9 failed (9 of them are known to fail)
39 tests were disabled
$
On Linux 32bit, I get:
$ make check
...
TEST call-inlined (call-inlined.c)
error: actual output text does not match expected output text.
error: see call-inlined.c.output.* for further investigation.
--- call-inlined.c.output.expected 2017-03-27 16:57:23.438683323 +0100
+++ call-inlined.c.output.got 2017-03-27 16:57:23.442685323 +0100
@@ -15,14 +15,14 @@
bas:
.L6:
<entry-point>
- add.64 %r16 <- "abc", $1
- ret.64 %r16
+ add.32 %r16 <- "abc", $1
+ ret.32 %r16
qus:
.L9:
<entry-point>
- add.64 %r21 <- messg, $1
- ret.64 %r21
+ add.32 %r21 <- messg, $1
+ ret.32 %r21
TEST call-variadic (call-variadic.c)
error: actual output text does not match expected output text.
error: see call-variadic.c.output.* for further investigation.
--- call-variadic.c.output.expected 2017-03-27 16:57:23.482705323 +0100
+++ call-variadic.c.output.got 2017-03-27 16:57:23.486707323 +0100
@@ -1,14 +1,14 @@
foo:
.L0:
<entry-point>
- push.64 "msg %c: %d %d/%ld %ld/%p %p\n"
+ push.32 "msg %c: %d %d/%ld %ld/%p %p\n"
push.32 $120
push.32 %arg2
push.32 $7
- push.64 %arg3
- push.64 $0
- push.64 %arg4
- push.64 $0
+ push.32 %arg3
+ push.32 $0
+ push.32 %arg4
+ push.32 $0
call.32 %r5 <- print
ret.32 %r5
...
Out of 214 tests, 203 passed, 11 failed (9 of them are known to fail)
39 tests were disabled
Makefile:213: recipe for target 'check' failed
make: *** [check] Error 1
$
And on cygwin 64bit, I get:
$ tail test-out-tmp
TEST Varargs bogus warning regression test #1 (varargs1.c)
TEST wide character constants (wide.c)
TEST Woverride-init-def (Woverride-init-def.c)
TEST Woverride-init-no (Woverride-init-no.c)
TEST Woverride-init-yes (Woverride-init-yes.c)
TEST warn-unknown-attribute (Wunknown-attribute-def.c)
TEST warn-unknown-attribute-no (Wunknown-attribute-no.c)
TEST warn-unknown-attribute-yes (Wunknown-attribute-yes.c)
Out of 253 tests, 235 passed, 18 failed (9 of them are known to fail)
make: *** [Makefile:213: check] Error 1
$
Note that the 9 unexpected failures on cygwin are due to the same
'llvm tool problems' that we discussed before. ie the new tests added
in these patches all pass.
Hope that helps.
ATB,
Ramsay Jones
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: extra 'make check' failures on 32bit Linux
2017-03-27 16:53 ` Ramsay Jones
@ 2017-03-27 17:15 ` Luc Van Oostenryck
0 siblings, 0 replies; 8+ messages in thread
From: Luc Van Oostenryck @ 2017-03-27 17:15 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Christopher Li, Sparse Mailing-list
On Mon, Mar 27, 2017 at 05:53:17PM +0100, Ramsay Jones wrote:
>
> > OK, thanks.
> > It should be OK as I new tested it on a 32bit machine but
> > another environment is always good for testing.
>
> OK, so I tested the 5 patch series + the v2 patch that you sent
> out on Linux 64bit, Linux 32bit and cygwin 64bit.
>
> I applied the patches on top of the current 'sparse-next' branch:
>
> $ git branch -v
> chrisl-master ce18a90 sparse: update __builtin_object_size() prototype
> master fbbfc73 simplify float-to-float casts that doesn't change size
> mingw 9e96dd5 test-suite: Add -b option to ignore CR at eol on MinGW
> sparse-next f7817f0 llvm: cleanup of output_[ptr]cast()
> * sparse-next-tmp df7cd04 fix expansion of integers to floats
>
> $ git log --oneline sparse-next..
> df7cd04 fix expansion of integers to floats
> 83de8c4 do not depends on limits.h to test __CHAR_BIT__
> ac9f7b4 fix test validation/div.c
> 153d5cf predefine __SIZEOF_INT__ & friends
> a3a916c predefine __INT_MAX__ and friends
> 26a0a0a fix test for cast to bool on 32bit machines
> $
>
> On Linux 64bit, I get:
>
> $ make check
> ...
> Out of 214 tests, 205 passed, 9 failed (9 of them are known to fail)
> 39 tests were disabled
> $
>
> On Linux 32bit, I get:
>
> $ make check
> ...
> TEST call-inlined (call-inlined.c)
> error: actual output text does not match expected output text.
> error: see call-inlined.c.output.* for further investigation.
> --- call-inlined.c.output.expected 2017-03-27 16:57:23.438683323 +0100
> +++ call-inlined.c.output.got 2017-03-27 16:57:23.442685323 +0100
Yes, this is expected. Sorry, I should have told earlier.
Those were part of another serie that I didn't yes sent an updated
version. The 5 patches series only covered what's already in master,
not sparse-next.
I'll sent an updated version for what's in sparse-next a bit later.
-- Luc
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: extra 'make check' failures on 32bit Linux
2017-03-26 22:21 extra 'make check' failures on 32bit Linux Ramsay Jones
2017-03-26 23:56 ` Luc Van Oostenryck
2017-03-27 1:03 ` Luc Van Oostenryck
@ 2017-03-27 7:51 ` Christopher Li
2 siblings, 0 replies; 8+ messages in thread
From: Christopher Li @ 2017-03-27 7:51 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Luc Van Oostenryck, Sparse Mailing-list
On Sun, Mar 26, 2017 at 3:21 PM, Ramsay Jones
<ramsay@ramsayjones.plus.com> wrote:
> Hi Christopher, Luc,
>
> On occasion I build sparse on 32-bit Linux and I have noticed, for some
> weeks now, unexpected test failures. I have been meaning to take a look
> at fixing these failures, but I just haven't had the time ... :(
Thanks for the report. I haven't test sparse on 32 bit platform.
It seems some byte code test case assuming the result from 64 bit platform.
Chris
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-03-27 17:25 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-26 22:21 extra 'make check' failures on 32bit Linux Ramsay Jones
2017-03-26 23:56 ` Luc Van Oostenryck
2017-03-27 1:03 ` Luc Van Oostenryck
2017-03-27 15:27 ` Ramsay Jones
2017-03-27 16:10 ` Luc Van Oostenryck
2017-03-27 16:53 ` Ramsay Jones
2017-03-27 17:15 ` Luc Van Oostenryck
2017-03-27 7:51 ` Christopher Li
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.