From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58661 invoked by alias); 22 Nov 2017 09:17:27 -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 58646 invoked by uid 89); 22 Nov 2017 09:17:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.7 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KB_WAM_FROM_NAME_SINGLEWORD,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=uncovered 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; Wed, 22 Nov 2017 09:17:25 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 37168793EC; Wed, 22 Nov 2017 09:17:23 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-247.ams2.redhat.com [10.36.116.247]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B73ED600D5; Wed, 22 Nov 2017 09:17:22 +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 vAM9HKVU017444; Wed, 22 Nov 2017 10:17:20 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id vAM9HIiB017443; Wed, 22 Nov 2017 10:17:18 +0100 Date: Wed, 22 Nov 2017 09:26:00 -0000 From: Jakub Jelinek To: Richard Biener , Richard Sandiford Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix mult expansion ICE (PR middle-end/82875) Message-ID: <20171122091718.GH14653@tucnak> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg01982.txt.bz2 Hi! On these two testcases, we end up expanding MULT_EXPR where both arguments end up being VOIDmode. For smul_optab that isn't a problem, we have the mode next to it, but in some cases we want to use {u,s}mul_widen_optab which is a conversion optab which needs two modes expand_binop is called just with one mode, the result mode, so the other mode is guessed from the operands and if both are VOIDmode, then a fallback is chosen to use return mode. The new find_widening* changes ICE on that though, previously we'd just do something. In any case, I think we need to make sure this doesn't happen while we still know both modes for the {u,s}mul_widen_optab. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Perhaps additionally we could have somewhere a case which for both arguments constant (unlikely case, as the gimple optimizers should usually optimize that out) and selected optabs for which we know the corresponding RTL code we could use simplify_const_binary_operation and see if it optimizes into a constant and just return that. Though, these functions are large and it is still possible a constant could be uncovered later, so I think we want this patch even if we do something like that. 2017-11-22 Jakub Jelinek PR middle-end/82875 * optabs.c (expand_doubleword_mult, expand_binop): Before calling expand_binop with *mul_widen_optab, make sure at least one of the operands doesn't have VOIDmode. * gcc.dg/pr82875.c: New test. * gcc.c-torture/compile/pr82875.c: New test. --- gcc/optabs.c.jj 2017-11-09 20:23:51.000000000 +0100 +++ gcc/optabs.c 2017-11-21 17:40:13.318673366 +0100 @@ -861,6 +861,11 @@ expand_doubleword_mult (machine_mode mod if (target && !REG_P (target)) target = NULL_RTX; + /* *_widen_optab needs to determine operand mode, make sure at least + one operand has non-VOID mode. */ + if (GET_MODE (op0_low) == VOIDmode && GET_MODE (op1_low) == VOIDmode) + op0_low = force_reg (word_mode, op0_low); + if (umulp) product = expand_binop (mode, umul_widen_optab, op0_low, op1_low, target, 1, OPTAB_DIRECT); @@ -1199,6 +1204,10 @@ expand_binop (machine_mode mode, optab b : smul_widen_optab), wider_mode, mode) != CODE_FOR_nothing)) { + /* *_widen_optab needs to determine operand mode, make sure at least + one operand has non-VOID mode. */ + if (GET_MODE (op0) == VOIDmode && GET_MODE (op1) == VOIDmode) + op0 = force_reg (mode, op0); temp = expand_binop (wider_mode, unsignedp ? umul_widen_optab : smul_widen_optab, op0, op1, NULL_RTX, unsignedp, OPTAB_DIRECT); --- gcc/testsuite/gcc.dg/pr82875.c.jj 2017-11-21 17:50:16.022274628 +0100 +++ gcc/testsuite/gcc.dg/pr82875.c 2017-11-21 17:49:46.000000000 +0100 @@ -0,0 +1,11 @@ +/* PR middle-end/82875 */ +/* { dg-do compile } */ +/* { dg-options "-ftree-ter" } */ + +const int a = 100; + +void +foo (void) +{ + int c[a]; +} --- gcc/testsuite/gcc.c-torture/compile/pr82875.c.jj 2017-11-21 17:48:46.409374708 +0100 +++ gcc/testsuite/gcc.c-torture/compile/pr82875.c 2017-11-21 17:48:25.000000000 +0100 @@ -0,0 +1,24 @@ +/* PR middle-end/82875 */ + +signed char a; +unsigned b; +long c, d; +long long e; + +void +foo (void) +{ + short f = a = 6; + while (0) + while (a <= 7) + { + for (;;) + ; + lab: + while (c <= 73) + ; + e = 20; + d ? (a %= c) * (e *= a ? f : b) : 0; + } + goto lab; +} Jakub