From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77430 invoked by alias); 18 Jan 2019 22:52:33 -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 77419 invoked by uid 89); 18 Jan 2019 22:52:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=HTo:U*rguenther X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 Jan 2019 22:52:31 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 34DCAC04959F; Fri, 18 Jan 2019 22:52:30 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-69.ams2.redhat.com [10.36.116.69]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 749EB60BE8; Fri, 18 Jan 2019 22:52:29 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x0IMqRj1013906; Fri, 18 Jan 2019 23:52:27 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x0IMqOVx013905; Fri, 18 Jan 2019 23:52:24 +0100 Date: Fri, 18 Jan 2019 22:52:00 -0000 From: Jakub Jelinek To: Richard Biener , Jan Hubicka Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix transfer_intrinsic_3.f90 miscompilation on ppc*/s390* (PR tree-optimization/88044) Message-ID: <20190118225224.GX30353@tucnak> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg01108.txt.bz2 Hi! As mentioned in the PR, on the transfer_intrinsic_3.f90 testcase at -O3 on a few targets we have in number_of_iterations_cond: code LE_EXPR iv0->base 0 iv0->step 0 iv1->base -1 iv1->step 1 every_iteration false The loop starts with: [local count: 8656061039]: # n_63 = PHI <0(6), _28(23)> _19 = n_63 + -1; and ends with _28 = n_63 + 1; if (_28 == 4) goto ; [12.36%] else goto ; [87.64%] [local count: 7582748748]: goto ; [100.00%] and besides the exit at the end has also: [local count: 3548985018]: if (_19 > 0) goto ; [0.04%] else goto ; [99.96%] [local count: 1419591]: _gfortran_stop_numeric (1, 0); [local count: 5106238449]: if (_19 < 0) goto ; [0.04%] else goto ; [99.96%] [local count: 5104195957]: goto ; [100.00%] [local count: 2042498]: _gfortran_stop_numeric (2, 0); in the middle, so two other loop exits. But, neither bb16, nor bb18 are executed every iteration, if they were, then because _19 is -1 in the first iteration would always stop 2 and not iterate further. We have: /* If the test is not executed every iteration, wrapping may make the test to pass again. TODO: the overflow case can be still used as unreliable estimate of upper bound. But we have no API to pass it down to number of iterations code and, at present, it will not use it anyway. */ if (!every_iteration && (!iv0->no_overflow || !iv1->no_overflow || code == NE_EXPR || code == EQ_EXPR)) return false; at the start, but that doesn't trigger here, because code is not equality comparison and no_overflow is set on both IVs. If there would be an overflow, then maybe it would be right to derive number of iterations from that. But the condition that returns true is that iv0->base code iv1->base is false, if that isn't done in every iteration, it means nothing for the number of iteration analysis. Fixed thusly, bootstrapped/regtested on x86_64-linux, i686-linux, powerpc64{,le}-linux, ok for trunk? 2019-01-18 Jakub Jelinek PR tree-optimization/88044 * tree-ssa-loop-niter.c (number_of_iterations_cond): If condition is false in the first iteration, but !every_iteration, return false instead of true with niter->niter zero. --- gcc/tree-ssa-loop-niter.c.jj 2019-01-10 11:43:02.254577008 +0100 +++ gcc/tree-ssa-loop-niter.c 2019-01-18 19:51:00.245504728 +0100 @@ -1824,6 +1824,8 @@ number_of_iterations_cond (struct loop * tree tem = fold_binary (code, boolean_type_node, iv0->base, iv1->base); if (tem && integer_zerop (tem)) { + if (!every_iteration) + return false; niter->niter = build_int_cst (unsigned_type_for (type), 0); niter->max = 0; return true; Jakub