Re: Sparse 0.5.1 RC5 released.

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

On Mon, Aug 14, 2017 at 12:50 AM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
>>> 1) Without single store shortcut it fails to compile. The error generated is:
>>>
>>> error: no result for pseudo
>>> minilua.c:5593:24: error: failed to output instruction load.64*
>>> %r13018 <- 16[VOID]
>>>
>>> minilua.c:5593:24: error: failed to output load.64*    %r13018 <- 16[VOID]
>>
>> Yes. Please forget about the single store shortcut: it's broken.
>> But I'm not sure: do you mean "without the shortcut" or
>> "without the patch that remove the shortcut"?
>
> Sorry this one is with the patch that removed the shortcut.

OK.

>>> Here are the linearized outputs:
>>>
>>> I am not sure this helps you.
>>
>> Not really, I was expecting the result of the preprocessing to avoid
>> header dependencies and use the code as you're using it.
>> For example, sparse doesn't know about the __DMR_C__ macro,
>> we're not using the same header files, not even the same platform.
>
> I can save the pre-processed output if that helps. Will send you a
> link.

Yes, it really helps for lots of reasons.
For example, I wasn't able to reproduce the Wine bug with the plain
file because triggered the problem was in a header file for platform X
version Y and I hadn't any problem here.

> The __DMR_C__ macro is just to help me avoid constructs that
> Sparse LLVM cannot handle.

Yes, I saw that.

>> But really, having small testcases with a clear description of exactly
>> what is wrong, help a lot.
>
> Well I think that we need a combination of tests - real world
> programs, as well as short, to the point, tests. The way I see it - if
> we get problems with a real world program, we then start digging and
> end up with short test that reproduces the problem. Just creating
> simple short tests does not tend to cover all scenarios as it is
> impossible to construct a comprehensive test suite (unless we can
> reuse someone else's test suite - which is something I am trying to
> do).

Sure, I also use some big files for testing too, some very big, but
before you can really begin to look at things you need at least have
an idea of what is wrong and having a small problem save a lot of time.
Yes, finding a small reproducer can be a lot of work.

Regards,
-- Luc