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
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
