[{"id":1759906,"web_url":"http://patchwork.ozlabs.org/comment/1759906/","msgid":"<2c996ed9-0a2f-0c8d-abfd-e6b90869b039@mentor.com>","list_archive_url":null,"date":"2017-08-30T06:25:58","subject":"Re: [PATCH] Fix bug in simplify_ternary_operation","submitter":{"id":9225,"url":"http://patchwork.ozlabs.org/api/people/9225/","name":"Tom de Vries","email":"Tom_deVries@mentor.com"},"content":"On 08/28/2017 08:26 PM, Tom de Vries wrote:\n> Hi,\n> \n> I think I found a bug in r17465:\n> ...\n>> * cse.c (simplify_ternary_operation): Handle more IF_THEN_ELSE\n>> simplifications.\n>>\n>> diff --git a/gcc/cse.c b/gcc/cse.c\n>> index e001597..3c27387 100644\n>> --- a/gcc/cse.c\n>> +++ b/gcc/cse.c\n>> @@ -4713,6 +4713,17 @@ simplify_ternary_operation (code, mode, \n>> op0_mode, op0, op1, op2)\n> \n> Note: the parameters of simplify_ternary_operation have the following \n> meaning:\n> ...\n> /* Simplify CODE, an operation with result mode MODE and three operands,\n> OP0, OP1, and OP2. OP0_MODE was the mode of OP0 before it became\n> a constant. Return 0 if no simplifications is possible. */\n> \n> rtx\n> simplify_ternary_operation (code, mode, op0_mode, op0, op1, op2)\n> enum rtx_code code;\n> enum machine_mode mode, op0_mode;\n> rtx op0, op1, op2;\n> ...\n> \n>> && rtx_equal_p (XEXP (op0, 1), op1)\n>> && rtx_equal_p (XEXP (op0, 0), op2))\n>> return op2;\n>> + else if (! side_effects_p (op0))\n>> + {\n>> + rtx temp;\n>> + temp = simplify_relational_operation (GET_CODE (op0), op0_mode,\n>> + XEXP (op0, 0), XEXP \n>> (op0, 1));\n> \n> We're handling code == IF_THEN_ELSE here, so op0 is the condition, op1 \n> is the 'then expr' and op2 is the 'else expr'.\n> \n> The parameters of simplify_relational_operation have the following meaning:\n> ...\n> /* Like simplify_binary_operation except used for relational operators.\n> MODE is the mode of the operands, not that of the result. If MODE\n> is VOIDmode, both operands must also be VOIDmode and we compare the\n> operands in \"infinite precision\".\n> \n> If no simplification is possible, this function returns zero.\n> Otherwise, it returns either const_true_rtx or const0_rtx. */\n> \n> rtx\n> simplify_relational_operation (code, mode, op0, op1)\n> enum rtx_code code;\n> enum machine_mode mode;\n> rtx op0, op1;\n> ...\n> \n> The problem in the patch is that we use op0_mode argument for the mode \n> parameter. The mode parameter of simplify_relational_operation needs to \n> be the mode of the operands of the condition, while op0_mode is the mode \n> of the condition.\n> \n> Patch below fixes this on current trunk.\n> \n> [ I found this by running into an ICE in \n> gcc.c-torture/compile/pr28776-2.c for gcn target. I haven't been able to \n> reproduce this with an upstream branch yet. ]\n\nFiled as PR82020 - \"ICE in decompose at rtl.h:2126\" ( \nhttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=82020 ).\n\n> \n> OK for trunk if bootstrap and reg-test for x86_64 succeeds?\n\nbootstrap and reg-test for x86_64 done, no issues found.\n\nThanks,\n- Tom\n\n[ reposting patch with ChangeLog entry ]\nFix comparison mode in simplify_ternary_operation\n\n2017-08-29 Tom de Vries \n\n\tPR rtl-optimization/82020\n\t* simplify-rtx.c (simplify_ternary_operation): Fix comparison mode of\n\tIF_THEN_ELSE condition.\n\n---\n gcc/simplify-rtx.c | 2 --\n 1 file changed, 2 deletions(-)\n\ndiff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c\nindex 0133d43..fbf979b 100644\n--- a/gcc/simplify-rtx.c\n+++ b/gcc/simplify-rtx.c\n@@ -5567,8 +5567,6 @@ simplify_ternary_operation (enum rtx_code code, machine_mode mode,\n \t\t\t\t\t XEXP (op0, 0), XEXP (op0, 1));\n \t }\n \n-\t if (cmp_mode == VOIDmode)\n-\t cmp_mode = op0_mode;\n \t temp = simplify_relational_operation (GET_CODE (op0), op0_mode,\n \t\t\t \t\t\tcmp_mode, XEXP (op0, 0),\n \t\t\t\t\t\tXEXP (op0, 1));","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-461134-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"asQBdktJ\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xhwWL54Wcz9ryQ\n\tfor ;\n\tWed, 30 Aug 2017 16:26:20 +1000 (AEST)","(qmail 44606 invoked by alias); 30 Aug 2017 06:26:11 -0000","(qmail 44513 invoked by uid 89); 30 Aug 2017 06:26:10 -0000","from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131)\n\tby sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with\n\tESMTP; Wed, 30 Aug 2017 06:26:08 +0000","from nat-ies.mentorg.com ([192.94.31.2]\n\thelo=SVR-IES-MBX-04.mgc.mentorg.com)\tby relay1.mentorg.com\n\twith esmtp id 1dmwRx-0002wh-0J from Tom_deVries@mentor.com ;\n\tTue, 29 Aug 2017 23:26:05 -0700","from [127.0.0.1] (137.202.0.87) by SVR-IES-MBX-04.mgc.mentorg.com\n\t(139.181.222.4) with Microsoft SMTP Server (TLS) id\n\t15.0.1263.5; Wed, 30 Aug 2017 07:26:01 +0100"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:subject:from:to:cc:references:message-id:date:mime-version\n\t:in-reply-to:content-type; q=dns; s=default; b=wF5hVsDl6Y5FruCdP\n\tnIFUu+rv5p5V/AsaUcua/1F3oqtli5QvPvedrWoroLi/AT3bFQZG5P510vq/lN60\n\tNCTV5ySZ65nIY72gYLft7dQt3QiMtjUAyhOWe+gic7rJWBC7x9LwGNEXC9vEV7aX\n\tGlYzbRVxBjSt9vNGrWMgpPyb8A=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:subject:from:to:cc:references:message-id:date:mime-version\n\t:in-reply-to:content-type; s=default; bh=eCme/sGXwN4+iLlDGBbfiGI\n\truLQ=; b=asQBdktJTOS1ahEOJjj7x3mOPET91D1Was2990O97klScniXwKIzekC\n\tKDWoFv94qt6ghumh1qnqxyjQgWbGWhhOJc0DRHt+DJddXoI8YLKS939Cy8Y/nysO\n\tTCte8Dj0gNTMqDat4vxpz/Gib03+Q/MHamWmTSSiMuygVfi+Cl+k=","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","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-24.6 required=5.0 tests=AWL, BAYES_00,\n\tGIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3,\n\tRCVD_IN_DNSWL_NONE, SPF_PASS,\n\tURIBL_RED autolearn=ham version=3.3.2 spammy=","X-HELO":"relay1.mentorg.com","Subject":"Re: [PATCH] Fix bug in simplify_ternary_operation","From":"Tom de Vries ","To":"Jeff Law ","CC":"GCC Patches ","References":"<82ea4bb9-15cb-b00d-c6af-e1de926a9cec@mentor.com>","Message-ID":"<2c996ed9-0a2f-0c8d-abfd-e6b90869b039@mentor.com>","Date":"Wed, 30 Aug 2017 08:25:58 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64;\n\trv:52.0) Gecko/20100101 Thunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<82ea4bb9-15cb-b00d-c6af-e1de926a9cec@mentor.com>","Content-Type":"multipart/mixed;\n\tboundary=\"------------6CDE5E9B6191010FA6347B2B\"","X-ClientProxiedBy":"svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To\n\tSVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4)"}},{"id":1761340,"web_url":"http://patchwork.ozlabs.org/comment/1761340/","msgid":"<27b0d8a8-935a-dd45-b0ff-2d86f8d854e0@redhat.com>","list_archive_url":null,"date":"2017-08-31T21:44:58","subject":"Re: [PATCH] Fix bug in simplify_ternary_operation","submitter":{"id":4400,"url":"http://patchwork.ozlabs.org/api/people/4400/","name":"Jeff Law","email":"law@redhat.com"},"content":"On 08/28/2017 12:26 PM, Tom de Vries wrote:\n> Hi,\n> \n> I think I found a bug in r17465:\n> ...\n>> * cse.c (simplify_ternary_operation): Handle more IF_THEN_ELSE\n>> simplifications.\n>>\n>> diff --git a/gcc/cse.c b/gcc/cse.c\n>> index e001597..3c27387 100644\n>> --- a/gcc/cse.c\n>> +++ b/gcc/cse.c\n>> @@ -4713,6 +4713,17 @@ simplify_ternary_operation (code, mode,\n>> op0_mode, op0, op1, op2)\n> \n> Note: the parameters of simplify_ternary_operation have the following\n> meaning:\n> ...\n> /* Simplify CODE, an operation with result mode MODE and three operands,\n> OP0, OP1, and OP2. OP0_MODE was the mode of OP0 before it became\n> a constant. Return 0 if no simplifications is possible. */\n> \n> rtx\n> simplify_ternary_operation (code, mode, op0_mode, op0, op1, op2)\n> enum rtx_code code;\n> enum machine_mode mode, op0_mode;\n> rtx op0, op1, op2;\n> ...\n> \n>> && rtx_equal_p (XEXP (op0, 1), op1)\n>> && rtx_equal_p (XEXP (op0, 0), op2))\n>> return op2;\n>> + else if (! side_effects_p (op0))\n>> + {\n>> + rtx temp;\n>> + temp = simplify_relational_operation (GET_CODE (op0), op0_mode,\n>> + XEXP (op0, 0), XEXP\n>> (op0, 1));\n> \n> We're handling code == IF_THEN_ELSE here, so op0 is the condition, op1\n> is the 'then expr' and op2 is the 'else expr'.\n> \n> The parameters of simplify_relational_operation have the following meaning:\n> ...\n> /* Like simplify_binary_operation except used for relational operators.\n> MODE is the mode of the operands, not that of the result. If MODE\n> is VOIDmode, both operands must also be VOIDmode and we compare the\n> operands in \"infinite precision\".\n> \n> If no simplification is possible, this function returns zero.\n> Otherwise, it returns either const_true_rtx or const0_rtx. */\n> \n> rtx\n> simplify_relational_operation (code, mode, op0, op1)\n> enum rtx_code code;\n> enum machine_mode mode;\n> rtx op0, op1;\n> ...\n> \n> The problem in the patch is that we use op0_mode argument for the mode\n> parameter. The mode parameter of simplify_relational_operation needs to\n> be the mode of the operands of the condition, while op0_mode is the mode\n> of the condition.\n> \n> Patch below fixes this on current trunk.\n> \n> [ I found this by running into an ICE in\n> gcc.c-torture/compile/pr28776-2.c for gcn target. I haven't been able to\n> reproduce this with an upstream branch yet. ]\n> \n> OK for trunk if bootstrap and reg-test for x86_64 succeeds?\nSo clearly setting cmp_mode to op0_mode is wrong. But we also have to\nmake sure that if cmp_mode is VOIDmode that either XEXP (op0, 0) has a\nnon-void mode or that XEXP (op0, 1) has a non-void mode, otherwise we're\nlikely to abort down in simplify_const_relational_operation.\n\nISTM a better fix is to return NULL_RTX if cmp_mode is VOIDmode and both\nthe sub-operations are VOIDmode as well.\n\nCan you try that and verify that pr28776-2.c continues to work?\njeff","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-461233-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"vYAB4/p5\"; dkim-atps=neutral","sourceware.org; auth=none","ext-mx04.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none) header.from=redhat.com","ext-mx04.extmail.prod.ext.phx2.redhat.com;\n\tspf=fail smtp.mailfrom=law@redhat.com"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xjwsR1jlyz9s81\n\tfor ;\n\tFri, 1 Sep 2017 07:45:28 +1000 (AEST)","(qmail 113120 invoked by alias); 31 Aug 2017 21:45:06 -0000","(qmail 113061 invoked by uid 89); 31 Aug 2017 21:45:04 -0000","from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by\n\tsourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP;\n\tThu, 31 Aug 2017 21:45:03 +0000","from smtp.corp.redhat.com\n\t(int-mx04.intmail.prod.int.phx2.redhat.com\n\t[10.5.11.14])\t(using TLSv1.2 with cipher AECDH-AES256-SHA\n\t(256/256 bits))\t(No client certificate requested)\tby\n\tmx1.redhat.com (Postfix) with ESMTPS id A310A85550;\n\tThu, 31 Aug 2017 21:45:01 +0000 (UTC)","from localhost.localdomain (ovpn-112-13.rdu2.redhat.com\n\t[10.10.112.13])\tby smtp.corp.redhat.com (Postfix) with ESMTP\n\tid B185C5F92D; Thu, 31 Aug 2017 21:44:59 +0000 (UTC)"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:subject:to:cc:references:from:message-id:date:mime-version\n\t:in-reply-to:content-type:content-transfer-encoding; q=dns; s=\n\tdefault; b=xiSU2iECwUc6dfKnqCI8+EYqazwJn6yrcSiwu3CnhiFvFPAJYY+lK\n\tcU1vGSHs3qt43D2f0xiMKgoQf1/ASN9GepImrAch2QBXTZmf0nYlg5IcMRQ2ebGP\n\tzC1dS8aZjaUIIJWOCUGpcpDxAKYFvrSnjXS8K7TmA2aEXNOk3fTWjg=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:subject:to:cc:references:from:message-id:date:mime-version\n\t:in-reply-to:content-type:content-transfer-encoding; s=default;\n\tbh=IAECda1hHu/pcPyws7wDR/CGjoU=; b=vYAB4/p5Y0VUpCu054UwWyG+WRPy\n\tz48YGA2S1n9/FRFAXQ8Qbt+rjsdHMbj46yLSZfCqTvFqWZhS0gtTfllpYjgWVXWE\n\taZM3fkiZD8w2jyA0DM0HcYhL3E4GR5FhrktCycxPDPZVJ3xMVmZo92zWtPxcwT+m\n\tVR3IUVtlNkxHaSk=","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","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-25.9 required=5.0 tests=BAYES_00, GIT_PATCH_0,\n\tGIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3,\n\tKAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD,\n\tSPF_HELO_PASS autolearn=ham version=3.3.2 spammy=","X-HELO":"mx1.redhat.com","DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com A310A85550","Subject":"Re: [PATCH] Fix bug in simplify_ternary_operation","To":"Tom de Vries ","Cc":"GCC Patches ","References":"<82ea4bb9-15cb-b00d-c6af-e1de926a9cec@mentor.com>","From":"Jeff Law ","Message-ID":"<27b0d8a8-935a-dd45-b0ff-2d86f8d854e0@redhat.com>","Date":"Thu, 31 Aug 2017 15:44:58 -0600","User-Agent":"Mozilla/5.0 (X11; Linux x86_64;\n\trv:52.0) Gecko/20100101 Thunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<82ea4bb9-15cb-b00d-c6af-e1de926a9cec@mentor.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"7bit","X-IsSubscribed":"yes"}},{"id":1761522,"web_url":"http://patchwork.ozlabs.org/comment/1761522/","msgid":"","list_archive_url":null,"date":"2017-09-01T08:51:14","subject":"Re: [PATCH] Fix bug in simplify_ternary_operation","submitter":{"id":9225,"url":"http://patchwork.ozlabs.org/api/people/9225/","name":"Tom de Vries","email":"Tom_deVries@mentor.com"},"content":"On 08/31/2017 11:44 PM, Jeff Law wrote:\n> On 08/28/2017 12:26 PM, Tom de Vries wrote:\n>> Hi,\n>>\n>> I think I found a bug in r17465:\n>> ...\n>>> * cse.c (simplify_ternary_operation): Handle more IF_THEN_ELSE\n>>> simplifications.\n>>>\n>>> diff --git a/gcc/cse.c b/gcc/cse.c\n>>> index e001597..3c27387 100644\n>>> --- a/gcc/cse.c\n>>> +++ b/gcc/cse.c\n>>> @@ -4713,6 +4713,17 @@ simplify_ternary_operation (code, mode,\n>>> op0_mode, op0, op1, op2)\n>>\n>> Note: the parameters of simplify_ternary_operation have the following\n>> meaning:\n>> ...\n>> /* Simplify CODE, an operation with result mode MODE and three operands,\n>> OP0, OP1, and OP2. OP0_MODE was the mode of OP0 before it became\n>> a constant. Return 0 if no simplifications is possible. */\n>>\n>> rtx\n>> simplify_ternary_operation (code, mode, op0_mode, op0, op1, op2)\n>> enum rtx_code code;\n>> enum machine_mode mode, op0_mode;\n>> rtx op0, op1, op2;\n>> ...\n>>\n>>> && rtx_equal_p (XEXP (op0, 1), op1)\n>>> && rtx_equal_p (XEXP (op0, 0), op2))\n>>> return op2;\n>>> + else if (! side_effects_p (op0))\n>>> + {\n>>> + rtx temp;\n>>> + temp = simplify_relational_operation (GET_CODE (op0), op0_mode,\n>>> + XEXP (op0, 0), XEXP\n>>> (op0, 1));\n>>\n>> We're handling code == IF_THEN_ELSE here, so op0 is the condition, op1\n>> is the 'then expr' and op2 is the 'else expr'.\n>>\n>> The parameters of simplify_relational_operation have the following meaning:\n>> ...\n>> /* Like simplify_binary_operation except used for relational operators.\n>> MODE is the mode of the operands, not that of the result. If MODE\n>> is VOIDmode, both operands must also be VOIDmode and we compare the\n>> operands in \"infinite precision\".\n>>\n>> If no simplification is possible, this function returns zero.\n>> Otherwise, it returns either const_true_rtx or const0_rtx. */\n>>\n>> rtx\n>> simplify_relational_operation (code, mode, op0, op1)\n>> enum rtx_code code;\n>> enum machine_mode mode;\n>> rtx op0, op1;\n>> ...\n>>\n>> The problem in the patch is that we use op0_mode argument for the mode\n>> parameter. The mode parameter of simplify_relational_operation needs to\n>> be the mode of the operands of the condition, while op0_mode is the mode\n>> of the condition.\n>>\n>> Patch below fixes this on current trunk.\n>>\n>> [ I found this by running into an ICE in\n>> gcc.c-torture/compile/pr28776-2.c for gcn target. I haven't been able to\n>> reproduce this with an upstream branch yet. ]\n>>\n>> OK for trunk if bootstrap and reg-test for x86_64 succeeds?\n> So clearly setting cmp_mode to op0_mode is wrong. But we also have to\n> make sure that if cmp_mode is VOIDmode that either XEXP (op0, 0) has a\n> non-void mode or that XEXP (op0, 1) has a non-void mode, otherwise we're\n> likely to abort down in simplify_const_relational_operation.\n> \n\nYou're referring to this assert:\n...\n/* Check if the given comparison (done in the given MODE) is actually \n\n a tautology or a contradiction. If the mode is VOID_mode, the \n\n comparison is done in \"infinite precision\". If no simplification \n\n is possible, this function returns zero. Otherwise, it returns \n\n either const_true_rtx or const0_rtx. */\n\nrtx\nsimplify_const_relational_operation (enum rtx_code code,\n machine_mode mode,\n rtx op0, rtx op1)\n{\n ...\n\n gcc_assert (mode != VOIDmode\n || (GET_MODE (op0) == VOIDmode\n && GET_MODE (op1) == VOIDmode));\n...\n\nadded by Honza:\n...\n\t* simplify-rtx.c (simplify_relational_operation): Verify that\n mode == VOIDmode implies both operands to be VOIDmode.\n...\n\nIn other words, rewriting the assert in more readable form:\n...\n#define BOOL_IMPLIES(a, b) (!(a) || (b))\n gcc_assert (BOOL_IMPLIES (mode == VOIDmode,\n (GET_MODE (op0) == VOIDmode\n && GET_MODE (op1) == VOIDmode)));\n...\n[ I'd be in favor of rewriting imply relations using a macro or some \nsuch, I find it easier to understand. ]\n\nNow, simplify_relational_operation starts like this:\n...\nrtx\nsimplify_relational_operation (enum rtx_code code, machine_mode mode,\n machine_mode cmp_mode, rtx op0, rtx op1)\n{\n rtx tem, trueop0, trueop1;\n\n if (cmp_mode == VOIDmode)\n cmp_mode = GET_MODE (op0);\n if (cmp_mode == VOIDmode)\n cmp_mode = GET_MODE (op1);\n\n tem = simplify_const_relational_operation (code, cmp_mode, op0, op1);\n...\n\nAFAIU, the cmp_mode ifs ensure that the assert in \nsimplify_const_relational_operation doesn't trigger.\n\n> ISTM a better fix is to return NULL_RTX if cmp_mode is VOIDmode and both\n> the sub-operations are VOIDmode as well.\n> \n\nI don't think we need that. simplify_const_relational_operation can \nhandle the situation that mode == VOIDmode && GET_MODE (op0) == VOIDmode \n&& GET_MODE (op1) == VOIDmode.\n\nThanks,\n- Tom\n\n> Can you try that and verify that pr28776-2.c continues to work?\n> jeff\n>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-461256-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"PRUJnPXj\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xkCf45Tlwz9t2c\n\tfor ;\n\tFri, 1 Sep 2017 18:51:39 +1000 (AEST)","(qmail 117374 invoked by alias); 1 Sep 2017 08:51:30 -0000","(qmail 116970 invoked by uid 89); 1 Sep 2017 08:51:30 -0000","from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131)\n\tby sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with\n\tESMTP; Fri, 01 Sep 2017 08:51:24 +0000","from nat-ies.mentorg.com ([192.94.31.2]\n\thelo=SVR-IES-MBX-04.mgc.mentorg.com)\tby relay1.mentorg.com\n\twith esmtp id 1dnhfc-0002Sd-Us from Tom_deVries@mentor.com ;\n\tFri, 01 Sep 2017 01:51:21 -0700","from [127.0.0.1] (137.202.0.87) by SVR-IES-MBX-04.mgc.mentorg.com\n\t(139.181.222.4) with Microsoft SMTP Server (TLS) id\n\t15.0.1263.5; Fri, 1 Sep 2017 09:51:17 +0100"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:subject:to:cc:references:from:message-id:date:mime-version\n\t:in-reply-to:content-type:content-transfer-encoding; q=dns; s=\n\tdefault; b=EuT29osEll9JPxCIWdgW4zBkrR9WbPhrV+druvdxXn45FJNK74ECe\n\tgDiDpR/dvukmlEtxclc69VgHCEw7v/KQ+sCiTMsILHUZbEaoatm/lrIsGKgo+0S8\n\tzLCNOCC37qrEYpJj2znQc19wv4H+j0k4eBJRNIcBtch1pXYml6hJpw=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:subject:to:cc:references:from:message-id:date:mime-version\n\t:in-reply-to:content-type:content-transfer-encoding; s=default;\n\tbh=YQL89DibLZNbjvh2fDLX8Dj2x5s=; b=PRUJnPXjAabzzDqG8H/m7QVtDa3n\n\tg/uPC7RUGfZX1SEf0xcmowYJtmS37OC21RzUFEUo3fhvntJm2UPrwLDvs43Lf8gD\n\tmnx8oeLStynsjn6VDTIH2McvdaxqexiybgFX3M3ZJgJO89i+oJYkYikEgEoycHGD\n\tB7u0RJ6FAoBXhI4=","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","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-24.6 required=5.0 tests=AWL, BAYES_00,\n\tGIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3,\n\tRCVD_IN_DNSWL_NONE,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=H*M:4e38","X-HELO":"relay1.mentorg.com","Subject":"Re: [PATCH] Fix bug in simplify_ternary_operation","To":"Jeff Law ","CC":"GCC Patches ","References":"<82ea4bb9-15cb-b00d-c6af-e1de926a9cec@mentor.com>\n\t<27b0d8a8-935a-dd45-b0ff-2d86f8d854e0@redhat.com>","From":"Tom de Vries ","Message-ID":"","Date":"Fri, 1 Sep 2017 10:51:14 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64;\n\trv:52.0) Gecko/20100101 Thunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<27b0d8a8-935a-dd45-b0ff-2d86f8d854e0@redhat.com>","Content-Type":"text/plain; charset=\"utf-8\"; format=flowed","Content-Transfer-Encoding":"7bit","X-ClientProxiedBy":"svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To\n\tSVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4)"}},{"id":1774845,"web_url":"http://patchwork.ozlabs.org/comment/1774845/","msgid":"<074f66c6-7ef9-fc90-d98f-2cfd31778e32@mentor.com>","list_archive_url":null,"date":"2017-09-25T16:33:35","subject":"[PING][PATCH] Fix bug in simplify_ternary_operation","submitter":{"id":9225,"url":"http://patchwork.ozlabs.org/api/people/9225/","name":"Tom de Vries","email":"Tom_deVries@mentor.com"},"content":"On 09/01/2017 10:51 AM, Tom de Vries wrote:\n> On 08/31/2017 11:44 PM, Jeff Law wrote:\n>> On 08/28/2017 12:26 PM, Tom de Vries wrote:\n>>> Hi,\n>>>\n>>> I think I found a bug in r17465:\n>>> ...\n>>>>         * cse.c (simplify_ternary_operation): Handle more IF_THEN_ELSE\n>>>>         simplifications.\n>>>>\n>>>> diff --git a/gcc/cse.c b/gcc/cse.c\n>>>> index e001597..3c27387 100644\n>>>> --- a/gcc/cse.c\n>>>> +++ b/gcc/cse.c\n>>>> @@ -4713,6 +4713,17 @@ simplify_ternary_operation (code, mode,\n>>>> op0_mode, op0, op1, op2)\n>>>\n>>> Note: the parameters of simplify_ternary_operation have the following\n>>> meaning:\n>>> ...\n>>> /* Simplify CODE, an operation with result mode MODE and three operands,\n>>>     OP0, OP1, and OP2.  OP0_MODE was the mode of OP0 before it became\n>>>     a constant.  Return 0 if no simplifications is possible.  */\n>>>\n>>> rtx\n>>> simplify_ternary_operation (code, mode, op0_mode, op0, op1, op2)\n>>>       enum rtx_code code;\n>>>       enum machine_mode mode, op0_mode;\n>>>       rtx op0, op1, op2;\n>>> ...\n>>>\n>>>>            && rtx_equal_p (XEXP (op0, 1), op1)\n>>>>            && rtx_equal_p (XEXP (op0, 0), op2))\n>>>>          return op2;\n>>>> +      else if (! side_effects_p (op0))\n>>>> +       {\n>>>> +         rtx temp;\n>>>> +         temp = simplify_relational_operation (GET_CODE (op0), \n>>>> op0_mode,\n>>>> +                                               XEXP (op0, 0), XEXP\n>>>> (op0, 1));\n>>>\n>>> We're handling code == IF_THEN_ELSE here, so op0 is the condition, op1\n>>> is the 'then expr' and op2 is the 'else expr'.\n>>>\n>>> The parameters of simplify_relational_operation have the following \n>>> meaning:\n>>> ...\n>>> /* Like simplify_binary_operation except used for relational operators.\n>>>     MODE is the mode of the operands, not that of the result.  If MODE\n>>>     is VOIDmode, both operands must also be VOIDmode and we compare the\n>>>     operands in \"infinite precision\".\n>>>\n>>>     If no simplification is possible, this function returns zero.\n>>>     Otherwise, it returns either const_true_rtx or const0_rtx.  */\n>>>\n>>> rtx\n>>> simplify_relational_operation (code, mode, op0, op1)\n>>>       enum rtx_code code;\n>>>       enum machine_mode mode;\n>>>       rtx op0, op1;\n>>> ...\n>>>\n>>> The problem in the patch is that we use op0_mode argument for the mode\n>>> parameter. The mode parameter of simplify_relational_operation needs to\n>>> be the mode of the operands of the condition, while op0_mode is the mode\n>>> of the condition.\n>>>\n>>> Patch below fixes this on current trunk.\n>>>\n>>> [ I found this by running into an ICE in\n>>> gcc.c-torture/compile/pr28776-2.c for gcn target. I haven't been able to\n>>> reproduce this with an upstream branch yet. ]\n>>>\n>>> OK for trunk if bootstrap and reg-test for x86_64 succeeds?\n>> So clearly setting cmp_mode to op0_mode is wrong.   But we also have to\n>> make sure that if cmp_mode is VOIDmode that either XEXP (op0, 0) has a\n>> non-void mode or that XEXP (op0, 1) has a non-void mode, otherwise we're\n>> likely to abort down in simplify_const_relational_operation.\n>>\n> \n> You're referring to this assert:\n> ...\n> /* Check if the given comparison (done in the given MODE) is actually\n>    a tautology or a contradiction.  If the mode is VOID_mode, the\n>    comparison is done in \"infinite precision\".  If no simplification\n>    is possible, this function returns zero.  Otherwise, it returns\n>    either const_true_rtx or const0_rtx.  */\n> \n> rtx\n> simplify_const_relational_operation (enum rtx_code code,\n>                                      machine_mode mode,\n>                                      rtx op0, rtx op1)\n> {\n>   ...\n> \n>   gcc_assert (mode != VOIDmode\n>               || (GET_MODE (op0) == VOIDmode\n>                   && GET_MODE (op1) == VOIDmode));\n> ...\n> \n> added by Honza:\n> ...\n>     * simplify-rtx.c (simplify_relational_operation): Verify that\n>         mode == VOIDmode implies both operands to be VOIDmode.\n> ...\n> \n> In other words, rewriting the assert in more readable form:\n> ...\n> #define BOOL_IMPLIES(a, b) (!(a) || (b))\n>   gcc_assert (BOOL_IMPLIES (mode == VOIDmode,\n>                             (GET_MODE (op0) == VOIDmode\n>                              && GET_MODE (op1) == VOIDmode)));\n> ...\n> [ I'd be in favor of rewriting imply relations using a macro or some \n> such, I find it easier to understand. ]\n> \n> Now, simplify_relational_operation starts like this:\n> ...\n> rtx\n> simplify_relational_operation (enum rtx_code code, machine_mode mode,\n>                                machine_mode cmp_mode, rtx op0, rtx op1)\n> {\n>   rtx tem, trueop0, trueop1;\n> \n>   if (cmp_mode == VOIDmode)\n>     cmp_mode = GET_MODE (op0);\n>   if (cmp_mode == VOIDmode)\n>     cmp_mode = GET_MODE (op1);\n> \n>   tem = simplify_const_relational_operation (code, cmp_mode, op0, op1);\n> ...\n> \n> AFAIU, the cmp_mode ifs ensure that the assert in \n> simplify_const_relational_operation doesn't trigger.\n> \n>> ISTM a better fix is to return NULL_RTX if cmp_mode is VOIDmode and both\n>> the sub-operations are VOIDmode as well.\n>>\n> \n> I don't think we need that. simplify_const_relational_operation can \n> handle the situation that mode == VOIDmode && GET_MODE (op0) == VOIDmode \n> && GET_MODE (op1) == VOIDmode.\n> \n\nPing.\n\nThanks,\n\n- Tom\n\n\n>> Can you try that and verify that pr28776-2.c continues to work?\n>> jeff\n>>","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-462907-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"DqGfMmCN\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3y18mQ2kylz9rvt\n\tfor ;\n\tTue, 26 Sep 2017 02:33:57 +1000 (AEST)","(qmail 116351 invoked by alias); 25 Sep 2017 16:33:48 -0000","(qmail 116342 invoked by uid 89); 25 Sep 2017 16:33:48 -0000","from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131)\n\tby sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with\n\tESMTP; Mon, 25 Sep 2017 16:33:46 +0000","from nat-ies.mentorg.com ([192.94.31.2]\n\thelo=SVR-IES-MBX-04.mgc.mentorg.com)\tby relay1.mentorg.com\n\twith esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256)\tid\n\t1dwWKE-0000s7-Ox from Tom_deVries@mentor.com ;\n\tMon, 25 Sep 2017 09:33:42 -0700","from [127.0.0.1] (137.202.0.87) by SVR-IES-MBX-04.mgc.mentorg.com\n\t(139.181.222.4) with Microsoft SMTP Server (TLS) id\n\t15.0.1263.5; Mon, 25 Sep 2017 17:33:38 +0100"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:subject:from:to:cc:references:message-id:date:mime-version\n\t:in-reply-to:content-type:content-transfer-encoding; q=dns; s=\n\tdefault; b=SpNZ1hmm8ubMr1JuqZ0m7hUuz+UZBEYnuOSi1JkGcB6b+Va0eiu1q\n\t7Tsm7rfYqpQmTGDm5ppYUPsNghVQaNqWUnyHYxVdJxH/UcmPZ9XwqXfSr8rV74Fn\n\tYBvlrBHMW3tZT7pDMvvFrohkaIEpcoUzAoEnWUyAjvkxqk6kkRtk4o=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:subject:from:to:cc:references:message-id:date:mime-version\n\t:in-reply-to:content-type:content-transfer-encoding; s=default;\n\tbh=3eHERqtMdUe4m+loWX099HQbkmY=; b=DqGfMmCNhGdc/mNbno40BwLsFggV\n\tY8b3QLP9HzHT9nmMr+BEjBJounF9wtv5fLua6dGQXhcEqpGGNf1yAHBtAdqZYAAR\n\tn8lzlNCny2Ih1uXhLjrSJCNDftzMuY2aIhKmtefyqsvB5pSo2KBuHTCzkW2R0AL2\n\tpUyCjgeaQ/Cf9r0=","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","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-24.6 required=5.0 tests=AWL, BAYES_00,\n\tGIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3,\n\tRCVD_IN_DNSWL_NONE,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=ifs","X-HELO":"relay1.mentorg.com","Subject":"[PING][PATCH] Fix bug in simplify_ternary_operation","From":"Tom de Vries ","To":"Jeff Law ","CC":"GCC Patches ","References":"<82ea4bb9-15cb-b00d-c6af-e1de926a9cec@mentor.com>\n\t<27b0d8a8-935a-dd45-b0ff-2d86f8d854e0@redhat.com>\n\t","Message-ID":"<074f66c6-7ef9-fc90-d98f-2cfd31778e32@mentor.com>","Date":"Mon, 25 Sep 2017 18:33:35 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64;\n\trv:52.0) Gecko/20100101 Thunderbird/52.3.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=\"utf-8\"; format=flowed","Content-Transfer-Encoding":"8bit","X-ClientProxiedBy":"svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To\n\tSVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4)"}},{"id":1807070,"web_url":"http://patchwork.ozlabs.org/comment/1807070/","msgid":"<65851dc9-e427-eb58-469a-6327ef55fe7d@redhat.com>","list_archive_url":null,"date":"2017-11-20T02:52:25","subject":"Re: [PATCH] Fix bug in simplify_ternary_operation","submitter":{"id":4400,"url":"http://patchwork.ozlabs.org/api/people/4400/","name":"Jeff Law","email":"law@redhat.com"},"content":"Sorry, it's taken so long to get back to this patch...\n\n\nOn 09/01/2017 02:51 AM, Tom de Vries wrote:\n> On 08/31/2017 11:44 PM, Jeff Law wrote:\n>> On 08/28/2017 12:26 PM, Tom de Vries wrote:\n>>> Hi,\n>>>\n>>> I think I found a bug in r17465:\n>>> ...\n>>>>         * cse.c (simplify_ternary_operation): Handle more IF_THEN_ELSE\n>>>>         simplifications.\n>>>>\n>>>> diff --git a/gcc/cse.c b/gcc/cse.c\n>>>> index e001597..3c27387 100644\n>>>> --- a/gcc/cse.c\n>>>> +++ b/gcc/cse.c\n>>>> @@ -4713,6 +4713,17 @@ simplify_ternary_operation (code, mode,\n>>>> op0_mode, op0, op1, op2)\n>>>\n>>> Note: the parameters of simplify_ternary_operation have the following\n>>> meaning:\n>>> ...\n>>> /* Simplify CODE, an operation with result mode MODE and three operands,\n>>>     OP0, OP1, and OP2.  OP0_MODE was the mode of OP0 before it became\n>>>     a constant.  Return 0 if no simplifications is possible.  */\n>>>\n>>> rtx\n>>> simplify_ternary_operation (code, mode, op0_mode, op0, op1, op2)\n>>>       enum rtx_code code;\n>>>       enum machine_mode mode, op0_mode;\n>>>       rtx op0, op1, op2;\n>>> ...\n>>>\n>>>>            && rtx_equal_p (XEXP (op0, 1), op1)\n>>>>            && rtx_equal_p (XEXP (op0, 0), op2))\n>>>>          return op2;\n>>>> +      else if (! side_effects_p (op0))\n>>>> +       {\n>>>> +         rtx temp;\n>>>> +         temp = simplify_relational_operation (GET_CODE (op0),\n>>>> op0_mode,\n>>>> +                                               XEXP (op0, 0), XEXP\n>>>> (op0, 1));\n>>>\n>>> We're handling code == IF_THEN_ELSE here, so op0 is the condition, op1\n>>> is the 'then expr' and op2 is the 'else expr'.\n>>>\n>>> The parameters of simplify_relational_operation have the following\n>>> meaning:\n>>> ...\n>>> /* Like simplify_binary_operation except used for relational operators.\n>>>     MODE is the mode of the operands, not that of the result.  If MODE\n>>>     is VOIDmode, both operands must also be VOIDmode and we compare the\n>>>     operands in \"infinite precision\".\n>>>\n>>>     If no simplification is possible, this function returns zero.\n>>>     Otherwise, it returns either const_true_rtx or const0_rtx.  */\n>>>\n>>> rtx\n>>> simplify_relational_operation (code, mode, op0, op1)\n>>>       enum rtx_code code;\n>>>       enum machine_mode mode;\n>>>       rtx op0, op1;\n>>> ...\n>>>\n>>> The problem in the patch is that we use op0_mode argument for the mode\n>>> parameter. The mode parameter of simplify_relational_operation needs to\n>>> be the mode of the operands of the condition, while op0_mode is the mode\n>>> of the condition.\n>>>\n>>> Patch below fixes this on current trunk.\n>>>\n>>> [ I found this by running into an ICE in\n>>> gcc.c-torture/compile/pr28776-2.c for gcn target. I haven't been able to\n>>> reproduce this with an upstream branch yet. ]\n>>>\n>>> OK for trunk if bootstrap and reg-test for x86_64 succeeds?\n>> So clearly setting cmp_mode to op0_mode is wrong.   But we also have to\n>> make sure that if cmp_mode is VOIDmode that either XEXP (op0, 0) has a\n>> non-void mode or that XEXP (op0, 1) has a non-void mode, otherwise we're\n>> likely to abort down in simplify_const_relational_operation.\n>>\n> \n> You're referring to this assert:\n> ...\n> /* Check if the given comparison (done in the given MODE) is actually\n>    a tautology or a contradiction.  If the mode is VOID_mode, the\n>    comparison is done in \"infinite precision\".  If no simplification\n>    is possible, this function returns zero.  Otherwise, it returns\n>    either const_true_rtx or const0_rtx.  */\n> \n> rtx\n> simplify_const_relational_operation (enum rtx_code code,\n>                                      machine_mode mode,\n>                                      rtx op0, rtx op1)\n> {\n>   ...\n> \n>   gcc_assert (mode != VOIDmode\n>               || (GET_MODE (op0) == VOIDmode\n>                   && GET_MODE (op1) == VOIDmode));\n> ...\n> \n> added by Honza:\n> ...\n>     * simplify-rtx.c (simplify_relational_operation): Verify that\n>         mode == VOIDmode implies both operands to be VOIDmode.\n> ...\n> \n> In other words, rewriting the assert in more readable form:\n> ...\n> #define BOOL_IMPLIES(a, b) (!(a) || (b))\n>   gcc_assert (BOOL_IMPLIES (mode == VOIDmode,\n>                             (GET_MODE (op0) == VOIDmode\n>                              && GET_MODE (op1) == VOIDmode)));\n> ...\n> [ I'd be in favor of rewriting imply relations using a macro or some\n> such, I find it easier to understand. ]\n> \n> Now, simplify_relational_operation starts like this:\n> ...\n> rtx\n> simplify_relational_operation (enum rtx_code code, machine_mode mode,\n>                                machine_mode cmp_mode, rtx op0, rtx op1)\n> {\n>   rtx tem, trueop0, trueop1;\n> \n>   if (cmp_mode == VOIDmode)\n>     cmp_mode = GET_MODE (op0);\n>   if (cmp_mode == VOIDmode)\n>     cmp_mode = GET_MODE (op1);\n> \n>   tem = simplify_const_relational_operation (code, cmp_mode, op0, op1);\n> ...\n> \n> AFAIU, the cmp_mode ifs ensure that the assert in\n> simplify_const_relational_operation doesn't trigger.\n> \n>> ISTM a better fix is to return NULL_RTX if cmp_mode is VOIDmode and both\n>> the sub-operations are VOIDmode as well.\n>>\n> \n> I don't think we need that. simplify_const_relational_operation can\n> handle the situation that mode == VOIDmode && GET_MODE (op0) == VOIDmode\n> && GET_MODE (op1) == VOIDmode.\nI think you're right -- looking back at it again I think I mis-read the\nassert.\n\nGo ahead and commit your change.\n\nThanks again for your patience.\n\njeff","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-467358-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"ZFzW9446\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ygCtz4Gzyz9s7M\n\tfor ;\n\tMon, 20 Nov 2017 13:52:39 +1100 (AEDT)","(qmail 81427 invoked by alias); 20 Nov 2017 02:52:31 -0000","(qmail 81410 invoked by uid 89); 20 Nov 2017 02:52:30 -0000","from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by\n\tsourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP;\n\tMon, 20 Nov 2017 02:52:28 +0000","from smtp.corp.redhat.com\n\t(int-mx05.intmail.prod.int.phx2.redhat.com\n\t[10.5.11.15])\t(using TLSv1.2 with cipher AECDH-AES256-SHA\n\t(256/256 bits))\t(No client certificate requested)\tby\n\tmx1.redhat.com (Postfix) with ESMTPS id 484664E90A;\n\tMon, 20 Nov 2017 02:52:27 +0000 (UTC)","from localhost.localdomain (ovpn-112-12.rdu2.redhat.com\n\t[10.10.112.12])\tby smtp.corp.redhat.com (Postfix) with ESMTP\n\tid 6CBFD5D75E; Mon, 20 Nov 2017 02:52:26 +0000 (UTC)"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:subject:to:cc:references:from:message-id:date:mime-version\n\t:in-reply-to:content-type:content-transfer-encoding; q=dns; s=\n\tdefault; b=PziN5BMxTnaT2EaSbYoheTwhlQCMxj0R7NLeUHwe0D0lF7mSeQQXt\n\t9nJr9zbPOzJvLe/p/oSrvTT7fFvpsVM3//SCdY22GNbuYPu7Vjdu/WQwG3ZF8ySX\n\tq9p3pWYzfoE61GpycIMVhzBKt6+5511KY4pI75Vg7tabcWQMr1pYS8=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:subject:to:cc:references:from:message-id:date:mime-version\n\t:in-reply-to:content-type:content-transfer-encoding; s=default;\n\tbh=LABcg2o04hqy9fzRGObRSOxmyIs=; b=ZFzW944677xXfj0JDk8mofWhCiM9\n\tqls3M5aVf+iJr04Ec7l9sL47rC5rb9yJYQ29zD/5H9msW7Gbcuo23xLq6+1vlqr+\n\tAatVUW+u7Bipb9qo1l1px3hhfdqRzWYhPPGl+liAbKCT6JHP9N2dDsN/2pO3aE/I\n\tQLBVKXjvOsOYPZs=","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","X-Virus-Found":"No","X-Spam-SWARE-Status":"=?iso-8859-1?q?No=2C_score=3D-26=2E7_required=3D5=2E?=\n\t=?iso-8859-1?q?0_tests=BAYES_00=2CGIT_PATCH_0=2CGIT_PATCH_1=2CGIT_?=\n\t=?iso-8859-1?q?PATCH_2=2CGIT_PATCH_3=2CKB_WAM_FROM_NAME_SINGLEWORD?=\n\t=?iso-8859-1?q?=2CSPF_HELO_PASS=2CT_RP_MATCHES_RCVD_autolearn=3Dha?=\n\t=?iso-8859-1?q?m_version=3D3=2E3=2E2_spammy=3Dpatience=2C_wrong=2E?=\n\t=?iso-8859-1?q?=C2?=","X-HELO":"mx1.redhat.com","Subject":"Re: [PATCH] Fix bug in simplify_ternary_operation","To":"Tom de Vries ","Cc":"GCC Patches ","References":"<82ea4bb9-15cb-b00d-c6af-e1de926a9cec@mentor.com>\n\t<27b0d8a8-935a-dd45-b0ff-2d86f8d854e0@redhat.com>\n\t","From":"Jeff Law ","Message-ID":"<65851dc9-e427-eb58-469a-6327ef55fe7d@redhat.com>","Date":"Sun, 19 Nov 2017 19:52:25 -0700","User-Agent":"Mozilla/5.0 (X11; Linux x86_64;\n\trv:52.0) Gecko/20100101 Thunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit","X-IsSubscribed":"yes"}},{"id":1807128,"web_url":"http://patchwork.ozlabs.org/comment/1807128/","msgid":"","list_archive_url":null,"date":"2017-11-20T08:40:05","subject":"Re: [PATCH] Fix bug in simplify_ternary_operation","submitter":{"id":9225,"url":"http://patchwork.ozlabs.org/api/people/9225/","name":"Tom de Vries","email":"Tom_deVries@mentor.com"},"content":"On 11/20/2017 03:52 AM, Jeff Law wrote:\n> Sorry, it's taken so long to get back to this patch...\n> \n> \n> On 09/01/2017 02:51 AM, Tom de Vries wrote:\n>> On 08/31/2017 11:44 PM, Jeff Law wrote:\n>>> On 08/28/2017 12:26 PM, Tom de Vries wrote:\n>>>> Hi,\n>>>>\n>>>> I think I found a bug in r17465:\n>>>> ...\n>>>>>         * cse.c (simplify_ternary_operation): Handle more IF_THEN_ELSE\n>>>>>         simplifications.\n>>>>>\n>>>>> diff --git a/gcc/cse.c b/gcc/cse.c\n>>>>> index e001597..3c27387 100644\n>>>>> --- a/gcc/cse.c\n>>>>> +++ b/gcc/cse.c\n>>>>> @@ -4713,6 +4713,17 @@ simplify_ternary_operation (code, mode,\n>>>>> op0_mode, op0, op1, op2)\n>>>>\n>>>> Note: the parameters of simplify_ternary_operation have the following\n>>>> meaning:\n>>>> ...\n>>>> /* Simplify CODE, an operation with result mode MODE and three operands,\n>>>>     OP0, OP1, and OP2.  OP0_MODE was the mode of OP0 before it became\n>>>>     a constant.  Return 0 if no simplifications is possible.  */\n>>>>\n>>>> rtx\n>>>> simplify_ternary_operation (code, mode, op0_mode, op0, op1, op2)\n>>>>       enum rtx_code code;\n>>>>       enum machine_mode mode, op0_mode;\n>>>>       rtx op0, op1, op2;\n>>>> ...\n>>>>\n>>>>>            && rtx_equal_p (XEXP (op0, 1), op1)\n>>>>>            && rtx_equal_p (XEXP (op0, 0), op2))\n>>>>>          return op2;\n>>>>> +      else if (! side_effects_p (op0))\n>>>>> +       {\n>>>>> +         rtx temp;\n>>>>> +         temp = simplify_relational_operation (GET_CODE (op0),\n>>>>> op0_mode,\n>>>>> +                                               XEXP (op0, 0), XEXP\n>>>>> (op0, 1));\n>>>>\n>>>> We're handling code == IF_THEN_ELSE here, so op0 is the condition, op1\n>>>> is the 'then expr' and op2 is the 'else expr'.\n>>>>\n>>>> The parameters of simplify_relational_operation have the following\n>>>> meaning:\n>>>> ...\n>>>> /* Like simplify_binary_operation except used for relational operators.\n>>>>     MODE is the mode of the operands, not that of the result.  If MODE\n>>>>     is VOIDmode, both operands must also be VOIDmode and we compare the\n>>>>     operands in \"infinite precision\".\n>>>>\n>>>>     If no simplification is possible, this function returns zero.\n>>>>     Otherwise, it returns either const_true_rtx or const0_rtx.  */\n>>>>\n>>>> rtx\n>>>> simplify_relational_operation (code, mode, op0, op1)\n>>>>       enum rtx_code code;\n>>>>       enum machine_mode mode;\n>>>>       rtx op0, op1;\n>>>> ...\n>>>>\n>>>> The problem in the patch is that we use op0_mode argument for the mode\n>>>> parameter. The mode parameter of simplify_relational_operation needs to\n>>>> be the mode of the operands of the condition, while op0_mode is the mode\n>>>> of the condition.\n>>>>\n>>>> Patch below fixes this on current trunk.\n>>>>\n>>>> [ I found this by running into an ICE in\n>>>> gcc.c-torture/compile/pr28776-2.c for gcn target. I haven't been able to\n>>>> reproduce this with an upstream branch yet. ]\n>>>>\n>>>> OK for trunk if bootstrap and reg-test for x86_64 succeeds?\n>>> So clearly setting cmp_mode to op0_mode is wrong.   But we also have to\n>>> make sure that if cmp_mode is VOIDmode that either XEXP (op0, 0) has a\n>>> non-void mode or that XEXP (op0, 1) has a non-void mode, otherwise we're\n>>> likely to abort down in simplify_const_relational_operation.\n>>>\n>>\n>> You're referring to this assert:\n>> ...\n>> /* Check if the given comparison (done in the given MODE) is actually\n>>    a tautology or a contradiction.  If the mode is VOID_mode, the\n>>    comparison is done in \"infinite precision\".  If no simplification\n>>    is possible, this function returns zero.  Otherwise, it returns\n>>    either const_true_rtx or const0_rtx.  */\n>>\n>> rtx\n>> simplify_const_relational_operation (enum rtx_code code,\n>>                                      machine_mode mode,\n>>                                      rtx op0, rtx op1)\n>> {\n>>   ...\n>>\n>>   gcc_assert (mode != VOIDmode\n>>               || (GET_MODE (op0) == VOIDmode\n>>                   && GET_MODE (op1) == VOIDmode));\n>> ...\n>>\n>> added by Honza:\n>> ...\n>>     * simplify-rtx.c (simplify_relational_operation): Verify that\n>>         mode == VOIDmode implies both operands to be VOIDmode.\n>> ...\n>>\n>> In other words, rewriting the assert in more readable form:\n>> ...\n>> #define BOOL_IMPLIES(a, b) (!(a) || (b))\n>>   gcc_assert (BOOL_IMPLIES (mode == VOIDmode,\n>>                             (GET_MODE (op0) == VOIDmode\n>>                              && GET_MODE (op1) == VOIDmode)));\n>> ...\n>> [ I'd be in favor of rewriting imply relations using a macro or some\n>> such, I find it easier to understand. ]\n>>\n>> Now, simplify_relational_operation starts like this:\n>> ...\n>> rtx\n>> simplify_relational_operation (enum rtx_code code, machine_mode mode,\n>>                                machine_mode cmp_mode, rtx op0, rtx op1)\n>> {\n>>   rtx tem, trueop0, trueop1;\n>>\n>>   if (cmp_mode == VOIDmode)\n>>     cmp_mode = GET_MODE (op0);\n>>   if (cmp_mode == VOIDmode)\n>>     cmp_mode = GET_MODE (op1);\n>>\n>>   tem = simplify_const_relational_operation (code, cmp_mode, op0, op1);\n>> ...\n>>\n>> AFAIU, the cmp_mode ifs ensure that the assert in\n>> simplify_const_relational_operation doesn't trigger.\n>>\n>>> ISTM a better fix is to return NULL_RTX if cmp_mode is VOIDmode and both\n>>> the sub-operations are VOIDmode as well.\n>>>\n>>\n>> I don't think we need that. simplify_const_relational_operation can\n>> handle the situation that mode == VOIDmode && GET_MODE (op0) == VOIDmode\n>> && GET_MODE (op1) == VOIDmode.\n> I think you're right -- looking back at it again I think I mis-read the\n> assert.\n> \n> Go ahead and commit your change.\n\nDone.\n\n> Thanks again for your patience.\n> \n\nNo problem, and thanks for the review :) .\n\n- Tom","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list gcc-patches@gcc.gnu.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=gcc-patches-return-467372-incoming=patchwork.ozlabs.org@gcc.gnu.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tunprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org\n\theader.b=\"BUdGo1Is\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ygMdp41Jzz9ryv\n\tfor ;\n\tMon, 20 Nov 2017 19:41:46 +1100 (AEDT)","(qmail 61884 invoked by alias); 20 Nov 2017 08:41:38 -0000","(qmail 61299 invoked by uid 89); 20 Nov 2017 08:40:18 -0000","from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131)\n\tby sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with\n\tESMTP; Mon, 20 Nov 2017 08:40:16 +0000","from nat-ies.mentorg.com ([192.94.31.2]\n\thelo=SVR-IES-MBX-04.mgc.mentorg.com)\tby relay1.mentorg.com\n\twith esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256)\tid\n\t1eGhcj-0004U6-2o from Tom_deVries@mentor.com ;\n\tMon, 20 Nov 2017 00:40:13 -0800","from [172.30.72.34] (137.202.0.87) by\n\tSVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) with Microsoft\n\tSMTP Server (TLS) id 15.0.1320.4; Mon, 20 Nov 2017 08:40:09 +0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:subject:to:cc:references:from:message-id:date:mime-version\n\t:in-reply-to:content-type:content-transfer-encoding; q=dns; s=\n\tdefault; b=Xp7ltxnvLjrk2I4llADyvsxe4Yp1H+fRjkFe0ddxvy47Bom2IzT8J\n\tSiLp9NSSgtmuEYlyKf9wp0U3c/mWfTLisPxyA9JtV2P3QG9d84S+gl0xdw6s8aoi\n\t7NErQHVkCvXjsXsQaYdslde0DfNWbevZZQtWZcxcgD/JGnZ/2JV8OA=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id\n\t:list-unsubscribe:list-archive:list-post:list-help:sender\n\t:subject:to:cc:references:from:message-id:date:mime-version\n\t:in-reply-to:content-type:content-transfer-encoding; s=default;\n\tbh=V/kf8xoGEshq5dIcn0O0ohSekd0=; b=BUdGo1IsVEpbALm5K3SyQzZ4+h5g\n\t5WJxFVZpUB2FVmeqI5Y43oG3AJopmhVL03raBBw+ZfYPExjSZ1+SBu7W+XT9BTvQ\n\tpCYBgSCRaiU3+xD6QnC0Edmn/qB9N/mzT6+Cz2u2RmzQQgBnK9CEvJ+TNu9aDYMN\n\tNgwD0usb3wWxcAo=","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","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-24.5 required=5.0 tests=AWL, BAYES_00,\n\tGIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3,\n\tKB_WAM_FROM_NAME_SINGLEWORD, RCVD_IN_DNSWL_NONE,\n\tSPF_PASS autolearn=ham version=3.3.2 spammy=","X-HELO":"relay1.mentorg.com","Subject":"Re: [PATCH] Fix bug in simplify_ternary_operation","To":"Jeff Law ","CC":"GCC Patches ","References":"<82ea4bb9-15cb-b00d-c6af-e1de926a9cec@mentor.com>\n\t<27b0d8a8-935a-dd45-b0ff-2d86f8d854e0@redhat.com>\n\t\n\t<65851dc9-e427-eb58-469a-6327ef55fe7d@redhat.com>","From":"Tom de Vries ","Message-ID":"","Date":"Mon, 20 Nov 2017 09:40:05 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64;\n\trv:52.0) Gecko/20100101 Thunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"<65851dc9-e427-eb58-469a-6327ef55fe7d@redhat.com>","Content-Type":"text/plain; charset=\"utf-8\"; format=flowed","Content-Transfer-Encoding":"8bit","X-ClientProxiedBy":"svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To\n\tSVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4)"}}]