From patchwork Wed Mar 14 22:18:56 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 886057 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-474743-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="JrP6AVU1"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 401mR52ghvz9sVW for ; Thu, 15 Mar 2018 09:19:20 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; q=dns; s=default; b=nOtgnn6t/n5iidze9w9r0SMxX4ZZL iQOs+dSoAL0Oodt1mP0bFRfpq2/d/p3C3pIzfdavUB5PSvlNKgesW3qndhV9MtX4 lv3x+/LyCZWxsDAq0b4Qg4t9AgmzGgL2rzHEHEC8i0Sw+dHbcyvAeavbi3jRhOEo I8zKjP3Si6KXJw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; s=default; bh=wdfId575F4MmMpvEMk566TqLCqk=; b=JrP 6AVU1wzZuMj7t42yYBczJES/7csgyFn9plgjTL42lqdNKWTnVbWLcy0/3Tm3OLjy NAs8bYvwu5bRHmxgBatFiPPaeOTsWVfqQL9Y/8hEHoFWZDGeFldkHHuOocK1OUL2 +a9u3tGb+EFcc/1Jsl6jKmDO5vqNxo7pepCMsqGM= Received: (qmail 56561 invoked by alias); 14 Mar 2018 22:19:13 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 56549 invoked by uid 89); 14 Mar 2018 22:19:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 Mar 2018 22:19:11 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6BEEC4040073; Wed, 14 Mar 2018 22:19:00 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.36.118.110]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 282F710B0F5B; Wed, 14 Mar 2018 22:19:00 +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 w2EMIwcY023900; Wed, 14 Mar 2018 23:18:58 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id w2EMIuuH023899; Wed, 14 Mar 2018 23:18:56 +0100 Date: Wed, 14 Mar 2018 23:18:56 +0100 From: Jakub Jelinek To: Richard Biener , Jeff Law Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix emit_conditional_move (PR target/84860) Message-ID: <20180314221856.GL8577@tucnak> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes Hi! prepare_cmp_insn in some cases changes both the passed in comparison and the comparison mode, e.g. by promoting the arguments from SFmode to DFmode etc. In emit_conditional_move we call this in a loop, for (pass = 0; pass < 2; pass++) and in each case construct comparison arguments as well as the comparison passed to it from the original arguments (we have to after all, because when not successful, we throw the whole insn sequence away), but use cmode which the first iteration could have changed, on this testcase on powerpcspe with -mcpu=8548 from SFmode to DFmode, so we ICE the second time, because the arguments don't really match the comparison mode. Fixed by passing it an address of a copy of the cmode parameter, so that the second pass starts with the original cmode that matches the arguments again. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2018-03-14 Jakub Jelinek PR target/84860 * optabs.c (emit_conditional_move): Pass address of cmode's copy rather than address of cmode as last argument to prepare_cmp_insn. * gcc.c-torture/compile/pr84860.c: New test. Jakub --- gcc/optabs.c.jj 2018-02-09 19:11:29.000000000 +0100 +++ gcc/optabs.c 2018-03-14 09:22:31.707873477 +0100 @@ -4345,9 +4345,10 @@ emit_conditional_move (rtx target, enum save_pending_stack_adjust (&save); last = get_last_insn (); do_pending_stack_adjust (); + machine_mode cmpmode = cmode; prepare_cmp_insn (XEXP (comparison, 0), XEXP (comparison, 1), GET_CODE (comparison), NULL_RTX, unsignedp, - OPTAB_WIDEN, &comparison, &cmode); + OPTAB_WIDEN, &comparison, &cmpmode); if (comparison) { struct expand_operand ops[4]; --- gcc/testsuite/gcc.c-torture/compile/pr84860.c.jj 2018-03-14 09:26:19.988883506 +0100 +++ gcc/testsuite/gcc.c-torture/compile/pr84860.c 2018-03-14 09:26:44.854884590 +0100 @@ -0,0 +1,11 @@ +/* PR target/84860 */ + +void +foo (int x, int y) +{ + while (x < 1) + { + x = y; + y = ((float)1 / 0) ? 2 : 0; + } +}