From patchwork Fri Mar 2 11:03:10 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christopher Li X-Patchwork-Id: 10254297 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 29E4360211 for ; Fri, 2 Mar 2018 11:03:18 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1D5F328958 for ; Fri, 2 Mar 2018 11:03:18 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 11FAE28962; Fri, 2 Mar 2018 11:03:18 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B714F28960 for ; Fri, 2 Mar 2018 11:03:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423769AbeCBLDO (ORCPT ); Fri, 2 Mar 2018 06:03:14 -0500 Received: from mail-qk0-f181.google.com ([209.85.220.181]:38305 "EHLO mail-qk0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423716AbeCBLDM (ORCPT ); Fri, 2 Mar 2018 06:03:12 -0500 Received: by mail-qk0-f181.google.com with SMTP id s198so11402927qke.5 for ; Fri, 02 Mar 2018 03:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=v6xfDrM746yMCQ7XJ0sMhWHIjUJOKPxlQIZAe8LxorE=; b=Gkv+XjGqrHXS5+SzzKGM2eGPmtkvVOBgj24b3D32gNy2HPoAjG+3Mno3kpSoYRtLXp kr2dfReDJvrSN+zV/VQ0u4cVLNZBXVA1R5v3LDTYw/GcdQ7OI0QgcFNhBjb8pE/wYLnI ez/T4ylrEEAPQAmsVcCie8n/XFCTIoQI3PMSb2aSHp1PFBOtRTGP/++rEY5fPTtcdAZD Gs/TfXHpreSo0N3sgvzwVeoXkdPcFmfC/wxC620c31mzMz1e9cqou2bGoBYvCyP0U0Eo THux0LCKMMyt70bWKtPQxsF15lrr+5xoimTwagmzZK4QVB83KOrPfJ+apKmbhfHpS9qx ALRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=v6xfDrM746yMCQ7XJ0sMhWHIjUJOKPxlQIZAe8LxorE=; b=o8jMRFEzkiYuAZqxJh17bE9eKesq7bQXMlziSr9938A/dRua7AhjnyLAcf1/a89KNp ybXdZNSKvz72xcR3ctaDr1ISK7m5OpiBbuTkhn3nYNO85PfNySQOkBvgYVbPZ7Cyjcds unQHC5Qa0sjntqzHAl1uqPi470Idoet78ErsrzW7YfXrS4GyqJsJUS8vLUh5IsVvRSb0 +U1zKb+6OwqdiUQvUJ/gCykreBKnFQ+8EEdco8Lr2ADg9o3dWgqbpKe02DjSSMHh3rUi FyCAxGZKqKFHMl2fVSJRJ0hPpK55M26cFPIZsu5gZbfRHQUDdX91Ll6na/YyWmrlf91n GkMQ== X-Gm-Message-State: AElRT7HGj200amC+qDICFr10ZZ9QGVjzr8Ih3hRRzutyG5x523AWHrB9 xcjnKfPX2sCMdwcWT3BsJEWV9WiYSViymEyrjA84 X-Google-Smtp-Source: AG47ELvtGZKaLFzggVW0v8MqiC+hKIk1Wgukr6O8cF0RY46INbD1oYZvsPiE5zuAiEpGofMS6BjQXFIhFjfwHordvZE= X-Received: by 10.233.221.69 with SMTP id r66mr7216297qkf.106.1519988591085; Fri, 02 Mar 2018 03:03:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.91.52 with HTTP; Fri, 2 Mar 2018 03:03:10 -0800 (PST) In-Reply-To: References: <20180224220029.l5soju2azz3vsy4g@ltop.local> <20180226002406.g4apmzong3qmp22z@ltop.local> <20180227011207.v57umnf4k2wpjneh@ltop.local> From: Christopher Li Date: Fri, 2 Mar 2018 03:03:10 -0800 X-Google-Sender-Auth: gOCWakCCen3nEpqKRtqOm6_Y6-c Message-ID: Subject: Re: regressions on HEAD To: Dibyendu Majumdar Cc: Luc Van Oostenryck , Linux-Sparse , Josh Triplett Sender: linux-sparse-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sparse@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, Mar 1, 2018 at 1:52 PM, Dibyendu Majumdar wrote: > On 1 March 2018 at 20:57, Dibyendu Majumdar wrote: >> On 27 February 2018 at 01:12, Luc Van Oostenryck >> wrote: >>> On Mon, Feb 26, 2018 at 03:36:38PM -0800, Christopher Li wrote: >>>> >>>> You said you did not found crash in your first round testing. >>>> However there is some regression of the IR. Can you share >>>> the regression test case you found? >>> >>> I didn't spend much time at it but a typical small example >>> of what I've seen is: >>> void a(void) { >>> long b; >>> unsigned c = 0; >>> for (;;) >>> if (c) >>> c = b; >>> } >>> >> >> Now where is the value pseudo of size 64 coming from as it is not in >> the code above? >> > > Okay it seems to come from flow.c in find_dominating_stores() - in the > call to convert_load_instruction(). Any explanation of what this is > doing? That is just the memory operation convert to pseudo. Sparse find out "b" has no dominating store (uninitialized), so it just replace it with 0 value. The 64 bit one is b, the long type. The 32 bit one is c, the int type. I already find out the place cause it: The fix is here: Chris simplify cast of constant using wrong size This fix the test case after the merge. The constant pseudo need to use the target size. Signed-off-by: Christopher Li --- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/simplify.c b/simplify.c index 09931fe..3d32cdd 100644 --- a/simplify.c +++ b/simplify.c @@ -950,7 +950,7 @@ static int simplify_cast(struct instruction *insn) if (constant(src)) { int sign = orig_type->ctype.modifiers & MOD_SIGNED; long long val = get_cast_value(src->value, orig_size, size, sign); - src = value_pseudo(orig_type, val); + src = value_pseudo(insn->type, val); goto simplify; }