From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98649 invoked by alias); 1 Mar 2019 21:02:14 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 98113 invoked by uid 89); 1 Mar 2019 21:02:14 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,SPF_HELO_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 spammy=disappear, H*i:sk:E18B0E1, H*f:sk:E18B0E1, H*c:alternative X-HELO: userp2120.oracle.com Received: from userp2120.oracle.com (HELO userp2120.oracle.com) (156.151.31.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Mar 2019 21:02:12 +0000 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x21KsTUm015630; Fri, 1 Mar 2019 21:02:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2018-07-02; bh=n1lOtJSMJPZbDCNSjRZ3522P7t13aH4mWgz3wMDT0QU=; b=U5wtPVdE39JkMrLfNJNgiZwV0Sk4m7goKKWgsgbNznowzwHQXEfvDODZgd+Suf/8D/RL Y42uZmMPKkMqGsqcQVYqY7t2AuMwmwVPjhcMxaZSrAxK9OFYxRSBU84ivXMC5tMrL2Dq qhWvRN4m8ceezEc0YlaFqJy6UpThisORMEdOhlBEFigtkqsU3+he/IvVrWEfMQvEuZQI bpUfzKWtUwmVrnP8MW8yE2g+xVdC+WhGBSB1A8ZjoRt2jPnq5NnhqPrLp/rn7UKWtt7l pKBONrmroHYb9Iae4vK6f/HlW9VsO6fcmC2CmWV7jVPpGpDngURnZT/iFQetscv1UbXi rQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2qtxts9fuh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 Mar 2019 21:02:10 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x21L24xl001515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 1 Mar 2019 21:02:04 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x21L23q6024751; Fri, 1 Mar 2019 21:02:04 GMT Received: from dhcp-10-159-129-106.vpn.oracle.com (/10.159.129.106) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Mar 2019 13:02:03 -0800 From: Qing Zhao Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: A bug in vrp_meet? Date: Fri, 01 Mar 2019 21:02:00 -0000 In-Reply-To: Cc: gcc@gcc.gnu.org, Jeff Law , gcc Patches To: Richard Biener References: <933b52ac-d372-f9d9-792e-4166f35b41f5@redhat.com> <327DC916-C1B4-47F9-92AE-468236D32C1F@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00007.txt.bz2 > On Mar 1, 2019, at 1:25 PM, Richard Biener w= rote: >=20 > On March 1, 2019 6:49:20 PM GMT+01:00, Qing Zhao > wrote: >> Jeff, >>=20 >> thanks a lot for the reply. >>=20 >> this is really helpful. >>=20 >> I double checked the dumped intermediate file for pass =E2=80=9Cdom3", a= nd >> located the following for _152: >>=20 >> ****BEFORE the pass =E2=80=9Cdom3=E2=80=9D, there is no _152, the corres= ponding Block >> looks like: >>=20 >> [local count: 12992277]: >> _98 =3D (int) ufcMSR_52(D); >> k_105 =3D (sword) ufcMSR_52(D); >> i_49 =3D _98 > 0 ? k_105 : 0; >>=20 >> ***During the pass =E2=80=9Cdoms=E2=80=9D, _152 is generated as followi= ng: >>=20 >> Optimizing block #4 >> =E2=80=A6. >> Visiting statement: >> i_49 =3D _98 > 0 ? k_105 : 0; >> Meeting >> [0, 65535] >> and >> [0, 0] >> to >> [0, 65535] >> Intersecting >> [0, 65535] >> and >> [0, 65535] >> to >> [0, 65535] >> Optimizing statement i_49 =3D _98 > 0 ? k_105 : 0; >> Replaced 'k_105' with variable '_98' >> gimple_simplified to _152 =3D MAX_EXPR <_98, 0>; >> i_49 =3D _152; >> Folded to: i_49 =3D _152; >> LKUP STMT i_49 =3D _152 >> =3D=3D=3D=3D ASGN i_49 =3D _152 >>=20 >> then bb 4 becomes: >>=20 >> [local count: 12992277]: >> _98 =3D (int) ufcMSR_52(D); >> k_105 =3D _98; >> _152 =3D MAX_EXPR <_98, 0>; >> i_49 =3D _152; >>=20 >> and all the i_49 are replaced with _152.=20 >>=20 >> However, the value range info for _152 doesnot reflect the one for >> i_49, it keeps as UNDEFINED.=20 >>=20 >> is this the root problem?=20=20 >=20 > It looks like DOM fails to visit stmts generated by simplification. Can y= ou open a bug report with a testcase? The problem is, It took me quite some time in order to come up with a small= and independent testcase for this problem, a little bit change made the error disappear.=20=20 do you have any suggestion on this? or can you give me some hint on how to= fix this in DOM? then I can try the fix on my side? Thanks a lot. Qing >=20 > Richard.=20 >=20