From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81804 invoked by alias); 9 Aug 2016 21:53:55 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 81793 invoked by uid 89); 9 Aug 2016 21:53:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2000, Attached X-HELO: mail-pa0-f47.google.com Received: from mail-pa0-f47.google.com (HELO mail-pa0-f47.google.com) (209.85.220.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 09 Aug 2016 21:53:44 +0000 Received: by mail-pa0-f47.google.com with SMTP id iw10so8902489pac.2 for ; Tue, 09 Aug 2016 14:53:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=bLEjZz6m10/fUXUwCn3YGrAzBZ+KRe4Hs1rglXdmvSo=; b=iqsw6jztp8sDWWS9XndwJvF7nMIUAeL5PHuU4RwpbgkjWZbGA+N6InzSJUEyiOBPE0 lMrevOdt/dXp31wVSEs/MNwgcn6LTd4bk/s680xiDOnYxSKZdxv7aO0O0hjwzWW+TrEk c0sSuaZE2zJd0DR8tAFIVAJWfm9yPnR2CEkrnecuK7s5x4X2aP0mHIJrBisOGjQJs0Px UUQEe7EckOv1oXXi56e3Un2i/SOM8AOpv4lvtVdnjbi0Nr+axP22dg5WCc5T5BqkT7Bd xnBZItQEXvxoUxNW28mroSRFfYSjQCpuY8HuCSQxlyyB2gnB/MCs4Iw9/khpYCYv/B7y TWSw== X-Gm-Message-State: AEkoouvG7JYZCclPiDGc+cXTYFCTS8nNODb2uJ7kAwqKEcDECt2CBbAZ9qc/6oQU+OyU9wz9 X-Received: by 10.66.52.47 with SMTP id q15mr967684pao.67.1470779622107; Tue, 09 Aug 2016 14:53:42 -0700 (PDT) Received: from [10.1.1.4] (58-6-183-210.dyn.iinet.net.au. [58.6.183.210]) by smtp.gmail.com with ESMTPSA id ps2sm58443044pab.10.2016.08.09.14.53.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Aug 2016 14:53:41 -0700 (PDT) Subject: Re: [PR72835] Incorrect arithmetic optimization involving bitfield arguments To: Andrew Pinski References: <0a1eaaf8-3ede-cd56-ffb5-40b25f94e46e@linaro.org> <98613cff-7c48-1a56-0014-6d87c35a8f26@linaro.org> Cc: "gcc-patches@gcc.gnu.org" , Richard Biener From: kugan Message-ID: <61a9ceda-26b1-2f70-7238-f4eadabee1cb@linaro.org> Date: Tue, 09 Aug 2016 21:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00764.txt.bz2 Hi Andrew, On 10/08/16 07:50, Andrew Pinski wrote: > On Tue, Aug 9, 2016 at 2:42 PM, kugan wrote: >> >> >> On 09/08/16 23:43, kugan wrote: >>> >>> Hi, >>> >>> The test-case in PR72835 is failing with -O2 and passing with >>> -fno-tree-reassoc. It also passes with -O2 -fno-tree-vrp. >>> >>> diff of .115t.dse2 and .116t.reassoc1 for the c++ testcase is as >>> follows, which looks OK. >>> >>> + unsigned int _16; >>> + unsigned int _17; >>> + unsigned int _18; >>> >>> : >>> _1 = s1.m2; >>> _2 = (unsigned int) _1; >>> _3 = s1.m3; >>> _4 = (unsigned int) _3; >>> - _5 = -_4; >>> - _6 = _2 * _5; >>> + _5 = _4; >>> + _6 = _5 * _2; >>> var_32.0_7 = var_32; >>> _8 = (unsigned int) var_32.0_7; >>> _9 = s1.m1; >>> _10 = (unsigned int) _9; >>> - _11 = -_10; >>> - _12 = _8 * _11; >>> - c_14 = _6 + _12; >>> + _11 = _10; >>> + _12 = _11 * _8; >>> + _16 = _12 + _6; >>> + _18 = _16; >>> + _17 = -_18; >>> + c_14 = _17; >>> if (c_14 != 4098873984) >>> >>> >>> However, I noticed that when we re-associate and assign different >>> operands to the stmts, we are not resetting the flow information to the >>> LHS. This looks wrong. Attached patch resets it. With this, the >>> testcases in TH PR is now working. >>> >>> >>> Bootstrap and regression testing for x86_64-linux-gnu is in progress. Is >>> this OK for trunk if there is no regression. >> >> >> There was no new regression while testing. I also moved the testcase from >> gcc.dg/torture/pr72835.c to gcc.dg/tree-ssa/pr72835.c. Is this OK for trunk? > > > Why did you move the test-case from gcc.dg/torture to gcc.dg/tree-ssa? > I think most executable testcases (that was using standard options) > should be in tortue testcases to do a full sweep of the options. I thought It was unnecessary to run with all the options as -O2 would trigger this. I am OK with moving it to gcc.dg/torture/pr72835.c if you prefer. Thanks, Kugan