* sparse-next assertion failures on cygwin
@ 2017-03-06 22:17 Ramsay Jones
2017-03-07 6:35 ` Luc Van Oostenryck
0 siblings, 1 reply; 6+ messages in thread
From: Ramsay Jones @ 2017-03-06 22:17 UTC (permalink / raw)
To: Sparse Mailing-list; +Cc: Christopher Li, Luc Van Oostenryck
Hi Luc, Christopher,
I have had 3 additional (backend related) failures on cygwin for a long
time now. When they first appeared, I had a quick look and, since they
seemed to be cygwin specific, I have effectively ignored them ever since.
(At the time, I had the llvm tools installed on linux, and these errors
did not appear there. I don't have the llvm tools installed on linux at
the moment).
With the sparse-next branch from today, I now have another failure and
the current failures have changed a little, to now include an assert
failure. For example, with the current master branch:
$ make check
Makefile:66: Your system does not have libxml, disabling c2xml
Makefile:78: Your system does not have libgtk2, disabling test-inspect
TEST __func__ (__func__.c)
...
TEST 'hello, world' code generation (backend/hello.c)
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-03-06 20:56:47.161540100 +0000
+++ backend/hello.c.error.got 2017-03-06 20:56:47.430860000 +0000
@@ -0,0 +1,6 @@
+{standard input}: Assembler messages:
+{standard input}:14: Error: invalid register for .seh_pushreg
+{standard input}:14: Error: junk at end of line, first unrecognized character is `5'
+{standard input}:20: Error: invalid register for .seh_setframe
+{standard input}:20: Error: missing separator
+mv: cannot stat '/tmp/tmp.RXtXMQ.o': No such file or directory
...
TEST Loops (backend/loop.c)
error: actual error text does not match expected error text.
error: see backend/loop.c.error.* for further investigation.
--- backend/loop.c.error.expected 2017-03-06 20:56:49.981803500 +0000
+++ backend/loop.c.error.got 2017-03-06 20:56:50.321243300 +0000
@@ -0,0 +1,6 @@
+{standard input}: Assembler messages:
+{standard input}:14: Error: invalid register for .seh_pushreg
+{standard input}:14: Error: junk at end of line, first unrecognized character is `6'
+{standard input}:17: Error: invalid register for .seh_pushreg
+{standard input}:17: Error: junk at end of line, first unrecognized character is `7'
+mv: cannot stat '/tmp/tmp.geNp6E.o': No such file or directory
...
TEST sum from 1 to n (backend/sum.c)
error: actual output text does not match expected output text.
error: see backend/sum.c.output.* for further investigation.
--- backend/sum.c.output.expected 2017-03-06 20:56:54.297468500 +0000
+++ backend/sum.c.output.got 2017-03-06 20:56:54.368834400 +0000
@@ -1,2 +0,0 @@
-15
-5050
...
TEST warn-unknown-attribute-yes (Wunknown-attribute-yes.c)
Out of 218 tests, 207 passed, 11 failed (8 of them are known to fail)
make: *** [Makefile:213: check] Error 1
$
Note that for the 'hello world' test, the gas assembler is complaining about
some structured exception directives (it looks like a register number is
being used rather than a register name. eg. 5 rather than %rbp).
If I run the tools by hand, and remove lines 14 and 20 from the assembler
file, then:
$ cd validation/
$ ../sparse-llvm backend/hello.c >zz.llvm
$ /usr/bin/llc -o xx.S zz.llvm
$ vim xx.S # delete lines 20 and 14
$ as xx.S -o xx.o
$ gcc -o xx xx.o
$ ./xx
hello, world
$
So, this looks like a cygwin specific toolchain problem. I also assumed that
the 'backend/loop.c' test had the same problem (but I admit to never having
checked properly!).
The 'backend/sum.c' test is yet another oddity. If I run the exact same
commands issued by the sparsei script by hand, then the 'test' passes:
$ cd validation/
$ ../sparse-llvm backend/sum.c | /usr/bin/lli
15
5050
$
I eventually found a solution, that looked like this:
diff --git a/sparsei b/sparsei
index 3431a9f..d915b1f 100755
--- a/sparsei
+++ b/sparsei
@@ -10,4 +10,4 @@ if [ $# -eq 0 ]; then
exit 1
fi
-$DIRNAME/sparse-llvm $@ | $LLI
+$DIRNAME/sparse-llvm $@ | $LLI -force-interpreter=true
So, I speculate that, when run at the terminal, lli flushes the output
stream (when JITing the code), but not otherwise. Presumably, when using
the interpreter it always flushes the output stream.
So, again, this seems like a cygwin specific llvm tool problem.
Having updated today, the 'sparse-next' branch (@ commit ab8076b "llvm: fix
output_op_[ptr]cast()", 05-03-2017), the test run looks like:
$ make check
Makefile:66: Your system does not have libxml, disabling c2xml
Makefile:78: Your system does not have libgtk2, disabling test-inspect
TEST __func__ (__func__.c)
...
TEST 'hello, world' code generation (backend/hello.c)
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-03-06 21:57:24.847706600 +0000
+++ backend/hello.c.error.got 2017-03-06 21:57:25.092496200 +0000
@@ -0,0 +1,6 @@
+{standard input}: Assembler messages:
+{standard input}:14: Error: invalid register for .seh_pushreg
+{standard input}:14: Error: junk at end of line, first unrecognized character is `5'
+{standard input}:20: Error: invalid register for .seh_setframe
+{standard input}:20: Error: missing separator
+mv: cannot stat '/tmp/tmp.sSmppX.o': No such file or directory
...
TEST Loops (backend/loop.c)
error: actual error text does not match expected error text.
error: see backend/loop.c.error.* for further investigation.
--- backend/loop.c.error.expected 2017-03-06 21:57:27.695953300 +0000
+++ backend/loop.c.error.got 2017-03-06 21:57:30.636386100 +0000
@@ -0,0 +1,2 @@
+assertion "ctype" failed: file "sparse-llvm.c", line 312, function: val_to_value
+.././sparsec: line 35: 8900 Aborted (core dumped) $DIRNAME/sparse-llvm $SPARSEOPTS > $TMPLLVM
TEST Loops with unused counter (backend/loop2.c)
error: actual error text does not match expected error text.
error: see backend/loop2.c.error.* for further investigation.
--- backend/loop2.c.error.expected 2017-03-06 21:57:31.062468300 +0000
+++ backend/loop2.c.error.got 2017-03-06 21:57:33.949417000 +0000
@@ -0,0 +1,2 @@
+assertion "ctype" failed: file "sparse-llvm.c", line 312, function: val_to_value
+.././sparsec: line 35: 4808 Aborted (core dumped) $DIRNAME/sparse-llvm $SPARSEOPTS > $TMPLLVM
...
TEST sum from 1 to n (backend/sum.c)
error: actual output text does not match expected output text.
error: see backend/sum.c.output.* for further investigation.
--- backend/sum.c.output.expected 2017-03-06 21:57:38.398598700 +0000
+++ backend/sum.c.output.got 2017-03-06 21:57:38.485067900 +0000
@@ -1,2 +0,0 @@
-15
-5050
error: actual error text does not match expected error text.
error: see backend/sum.c.error.* for further investigation.
--- backend/sum.c.error.expected 2017-03-06 21:57:38.419504300 +0000
+++ backend/sum.c.error.got 2017-03-06 21:57:41.135029400 +0000
@@ -0,0 +1,2 @@
+assertion "ctype" failed: file "sparse-llvm.c", line 312, function: val_to_value
+'main' function not found in module.
error: Actual exit value does not match the expected one.
error: expected 0, got 255.
...
TEST warn-unknown-attribute-yes (Wunknown-attribute-yes.c)
Out of 230 tests, 217 passed, 13 failed (9 of them are known to fail)
make: *** [Makefile:213: check] Error 1
$
Note that 'backend/loop2.c' now also fails and, with the exception of
the 'backend/hello.c' test, they now fail with an assert.
I don't have time to look into this further tonight (I'm guessing that
you are not seeing this on linux), so I just wanted to let you know
about it.
ATB,
Ramsay Jones
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sparse-next assertion failures on cygwin
2017-03-06 22:17 sparse-next assertion failures on cygwin Ramsay Jones
@ 2017-03-07 6:35 ` Luc Van Oostenryck
2017-03-07 7:34 ` Dibyendu Majumdar
2017-03-08 1:38 ` Ramsay Jones
0 siblings, 2 replies; 6+ messages in thread
From: Luc Van Oostenryck @ 2017-03-07 6:35 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Sparse Mailing-list, Christopher Li, Dibyendu Majumdar
On Mon, Mar 06, 2017 at 10:17:36PM +0000, Ramsay Jones wrote:
> Hi Luc, Christopher,
Hi,
> ...
>
> So, this looks like a cygwin specific toolchain problem. I also assumed that
> the 'backend/loop.c' test had the same problem (but I admit to never having
> checked properly!).
>
> ...
>
> So, again, this seems like a cygwin specific llvm tool problem.
>
> ...
>
> TEST Loops (backend/loop.c)
> error: actual error text does not match expected error text.
> error: see backend/loop.c.error.* for further investigation.
> --- backend/loop.c.error.expected 2017-03-06 21:57:27.695953300 +0000
> +++ backend/loop.c.error.got 2017-03-06 21:57:30.636386100 +0000
> @@ -0,0 +1,2 @@
> +assertion "ctype" failed: file "sparse-llvm.c", line 312, function: val_to_value
> +.././sparsec: line 35: 8900 Aborted (core dumped) $DIRNAME/sparse-llvm $SPARSEOPTS > $TMPLLVM
That's surprising as it appears that you have linearized code that is
different that what we have on Linux (one of the type/symbol is NULL).
It whould be very interesting to:
1) show the result of test-linearize on the file
2) replace the assert with a check followed with a dump of the
offending pseudo (show_pseudo()) and ideally the corresponding
instruction (show_instruction()).
> Note that 'backend/loop2.c' now also fails and, with the exception of
> the 'backend/hello.c' test, they now fail with an assert.
Odd.
> I don't have time to look into this further tonight (I'm guessing that
> you are not seeing this on linux), so I just wanted to let you know
> about it.
>
> ATB,
> Ramsay Jones
No, nothing like that on Linux.
Dibyendu, are you seeing something like this on your environment?
Thanks to reporting this, alas as such I can't really do something
about it.
-- Luc Van Ooostenryck
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sparse-next assertion failures on cygwin
2017-03-07 6:35 ` Luc Van Oostenryck
@ 2017-03-07 7:34 ` Dibyendu Majumdar
2017-03-08 1:38 ` Ramsay Jones
1 sibling, 0 replies; 6+ messages in thread
From: Dibyendu Majumdar @ 2017-03-07 7:34 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: Ramsay Jones, Sparse Mailing-list, Christopher Li
On 7 March 2017 at 06:35, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
> On Mon, Mar 06, 2017 at 10:17:36PM +0000, Ramsay Jones wrote:
> Dibyendu, are you seeing something like this on your environment?
>
On Windows I build my modified version using Visual C++, but as the
test driver is a shell script, I usually run the tests on a Linux
instance. I will run some tests individually and report back - but
note that I am synced with master not sparse-next.
Regards
Dibyendu
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sparse-next assertion failures on cygwin
2017-03-07 6:35 ` Luc Van Oostenryck
2017-03-07 7:34 ` Dibyendu Majumdar
@ 2017-03-08 1:38 ` Ramsay Jones
2017-03-08 2:23 ` Ramsay Jones
2017-03-08 7:07 ` Luc Van Oostenryck
1 sibling, 2 replies; 6+ messages in thread
From: Ramsay Jones @ 2017-03-08 1:38 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: Sparse Mailing-list, Christopher Li, Dibyendu Majumdar
On 07/03/17 06:35, Luc Van Oostenryck wrote:
> On Mon, Mar 06, 2017 at 10:17:36PM +0000, Ramsay Jones wrote:
>> So, this looks like a cygwin specific toolchain problem. I also assumed that
>> the 'backend/loop.c' test had the same problem (but I admit to never having
>> checked properly!).
>>
>> ...
>>
>> So, again, this seems like a cygwin specific llvm tool problem.
>>
>> ...
>>
>> TEST Loops (backend/loop.c)
>> error: actual error text does not match expected error text.
>> error: see backend/loop.c.error.* for further investigation.
>> --- backend/loop.c.error.expected 2017-03-06 21:57:27.695953300 +0000
>> +++ backend/loop.c.error.got 2017-03-06 21:57:30.636386100 +0000
>> @@ -0,0 +1,2 @@
>> +assertion "ctype" failed: file "sparse-llvm.c", line 312, function: val_to_value
>> +.././sparsec: line 35: 8900 Aborted (core dumped) $DIRNAME/sparse-llvm $SPARSEOPTS > $TMPLLVM
>
> That's surprising as it appears that you have linearized code that is
> different that what we have on Linux (one of the type/symbol is NULL).
No, the linearized code is exactly the same on Linux and cygwin.
(checked with both diff and sha1sum).
> It whould be very interesting to:
> 1) show the result of test-linearize on the file
$ ./test-linearize validation/backend/loop.c
foo:
.L0:
<entry-point>
phisrc.32 %phi4(y) <- $0
br .L4
.L4:
phi.32 %r1(y) <- %phi4(y), %phi5(y)
setlt.32 %r2 <- %r1(y), $1000
cbr %r2, .L1, .L5
.L1:
call.32 %r4 <- bar, %arg1
add.32 %r7 <- %r1(y), %r4
phisrc.32 %phi5(y) <- %r7
br .L4
.L5:
ret.32 %r1(y)
$
> 2) replace the assert with a check followed with a dump of the
> offending pseudo (show_pseudo()) and ideally the corresponding
> instruction (show_instruction()).
<show_pseudo>: $0
<show_instruction>: phisrc.32 %phi4(y) <- $0 (%r1(y))
> No, nothing like that on Linux.
It seems Christopher is seeing the same thing. (He didn't say that
he saw it on Linux, but ...).
Are you sure you are running/testing the sparse-next branch (which
is currently at commit ab8076b83d ("llvm: fix output_op_[ptr]cast()",
05-03-2017)?
It would come as no surprise (I guess) that 'git bisect' fingers
commit 0c12ac32af ("llvm: fix translation of PSEUDO_VALs into a
ValueRefs", 05-03-2017).
ATB,
Ramsay Jones
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sparse-next assertion failures on cygwin
2017-03-08 1:38 ` Ramsay Jones
@ 2017-03-08 2:23 ` Ramsay Jones
2017-03-08 7:07 ` Luc Van Oostenryck
1 sibling, 0 replies; 6+ messages in thread
From: Ramsay Jones @ 2017-03-08 2:23 UTC (permalink / raw)
To: Luc Van Oostenryck; +Cc: Sparse Mailing-list, Christopher Li, Dibyendu Majumdar
On 08/03/17 01:38, Ramsay Jones wrote:
>
> On 07/03/17 06:35, Luc Van Oostenryck wrote:
>> On Mon, Mar 06, 2017 at 10:17:36PM +0000, Ramsay Jones wrote:
>>> So, this looks like a cygwin specific toolchain problem. I also assumed that
>>> the 'backend/loop.c' test had the same problem (but I admit to never having
>>> checked properly!).
>>>
>>> ...
>>>
>>> So, again, this seems like a cygwin specific llvm tool problem.
>>>
>>> ...
>>>
>>> TEST Loops (backend/loop.c)
>>> error: actual error text does not match expected error text.
>>> error: see backend/loop.c.error.* for further investigation.
>>> --- backend/loop.c.error.expected 2017-03-06 21:57:27.695953300 +0000
>>> +++ backend/loop.c.error.got 2017-03-06 21:57:30.636386100 +0000
>>> @@ -0,0 +1,2 @@
>>> +assertion "ctype" failed: file "sparse-llvm.c", line 312, function: val_to_value
>>> +.././sparsec: line 35: 8900 Aborted (core dumped) $DIRNAME/sparse-llvm $SPARSEOPTS > $TMPLLVM
>>
>> That's surprising as it appears that you have linearized code that is
>> different that what we have on Linux (one of the type/symbol is NULL).
>
> No, the linearized code is exactly the same on Linux and cygwin.
> (checked with both diff and sha1sum).
>
>> It whould be very interesting to:
>> 1) show the result of test-linearize on the file
>
> $ ./test-linearize validation/backend/loop.c
> foo:
> .L0:
> <entry-point>
> phisrc.32 %phi4(y) <- $0
> br .L4
>
> .L4:
> phi.32 %r1(y) <- %phi4(y), %phi5(y)
> setlt.32 %r2 <- %r1(y), $1000
> cbr %r2, .L1, .L5
>
> .L1:
> call.32 %r4 <- bar, %arg1
> add.32 %r7 <- %r1(y), %r4
> phisrc.32 %phi5(y) <- %r7
> br .L4
>
> .L5:
> ret.32 %r1(y)
>
>
> $
>
>> 2) replace the assert with a check followed with a dump of the
>> offending pseudo (show_pseudo()) and ideally the corresponding
>> instruction (show_instruction()).
>
> <show_pseudo>: $0
> <show_instruction>: phisrc.32 %phi4(y) <- $0 (%r1(y))
>
>> No, nothing like that on Linux.
>
> It seems Christopher is seeing the same thing. (He didn't say that
> he saw it on Linux, but ...).
>
> Are you sure you are running/testing the sparse-next branch (which
> is currently at commit ab8076b83d ("llvm: fix output_op_[ptr]cast()",
> 05-03-2017)?
And, of course, I've just noticed that sparse-next has been updated
to remove the top four commits! (which, naturally, also removes the
problem :-P ).
ATB,
Ramsay Jones
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: sparse-next assertion failures on cygwin
2017-03-08 1:38 ` Ramsay Jones
2017-03-08 2:23 ` Ramsay Jones
@ 2017-03-08 7:07 ` Luc Van Oostenryck
1 sibling, 0 replies; 6+ messages in thread
From: Luc Van Oostenryck @ 2017-03-08 7:07 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Sparse Mailing-list, Christopher Li, Dibyendu Majumdar
On Wed, Mar 08, 2017 at 01:38:10AM +0000, Ramsay Jones wrote:
> > That's surprising as it appears that you have linearized code that is
> > different that what we have on Linux (one of the type/symbol is NULL).
>
> No, the linearized code is exactly the same on Linux and cygwin.
> (checked with both diff and sha1sum).
>
> > It whould be very interesting to:
> > 1) show the result of test-linearize on the file
>
> $ ./test-linearize validation/backend/loop.c
> foo:
> .L0:
> <entry-point>
> phisrc.32 %phi4(y) <- $0
> br .L4
>
> .L4:
> phi.32 %r1(y) <- %phi4(y), %phi5(y)
> setlt.32 %r2 <- %r1(y), $1000
> cbr %r2, .L1, .L5
>
> .L1:
> call.32 %r4 <- bar, %arg1
> add.32 %r7 <- %r1(y), %r4
> phisrc.32 %phi5(y) <- %r7
> br .L4
>
> .L5:
> ret.32 %r1(y)
Wish it would also display the type of all pseudos and symbols.
I'll add this to my todo-list.
> > 2) replace the assert with a check followed with a dump of the
> > offending pseudo (show_pseudo()) and ideally the corresponding
> > instruction (show_instruction()).
>
> <show_pseudo>: $0
> <show_instruction>: phisrc.32 %phi4(y) <- $0 (%r1(y))
There is some logics why it crashs here.
> > No, nothing like that on Linux.
>
> It seems Christopher is seeing the same thing. (He didn't say that
> he saw it on Linux, but ...).
Yes, I saw that.
> Are you sure you are running/testing the sparse-next branch (which
> is currently at commit ab8076b83d ("llvm: fix output_op_[ptr]cast()",
> 05-03-2017)?
No, I had a bit of advance ... :)
I was running on what correspong to sparse-next now:
97ebb3459 use VOID instead of directly using &void_pseudo
plus the _whole_ llvm serie I had posted,
plus a few more patches without functional effects.
> It would come as no surprise (I guess) that 'git bisect' fingers
> commit 0c12ac32af ("llvm: fix translation of PSEUDO_VALs into a
> ValueRefs", 05-03-2017).
Sure, it must.
And the problem didn't appears on my side because another patch in the
serie solved the problems you & Chris have seen:
33ac15536 give a type to OP_PHISOURCE
I'll reorder a few patches and this should be solved.
-- Luc
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-03-08 7:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-03-06 22:17 sparse-next assertion failures on cygwin Ramsay Jones
2017-03-07 6:35 ` Luc Van Oostenryck
2017-03-07 7:34 ` Dibyendu Majumdar
2017-03-08 1:38 ` Ramsay Jones
2017-03-08 2:23 ` Ramsay Jones
2017-03-08 7:07 ` Luc Van Oostenryck
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).