From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luc Van Oostenryck Subject: Re: Sparse 0.5.1 RC5 released. Date: Mon, 14 Aug 2017 01:03:32 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from mail-oi0-f51.google.com ([209.85.218.51]:34533 "EHLO mail-oi0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750714AbdHMXDd (ORCPT ); Sun, 13 Aug 2017 19:03:33 -0400 Received: by mail-oi0-f51.google.com with SMTP id x3so71129149oia.1 for ; Sun, 13 Aug 2017 16:03:33 -0700 (PDT) In-Reply-To: Sender: linux-sparse-owner@vger.kernel.org List-Id: linux-sparse@vger.kernel.org To: Dibyendu Majumdar Cc: Christopher Li , Linux-Sparse , Ramsay Jones , Lance Richardson , Michael Stefaniuc On Mon, Aug 14, 2017 at 12:50 AM, Dibyendu Majumdar 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