From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uHV7Ln2Y71/2TAAAWB0awg (envelope-from ) for ; Fri, 01 Jan 2021 16:47:41 -0500 Received: by simark.ca (Postfix, from userid 112) id AE2DF1F0BC; Fri, 1 Jan 2021 16:47:41 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,MAILING_LIST_MULTI, RCVD_IN_BL_SPAMCOP_NET,T_DKIM_INVALID,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 34F911E590 for ; Fri, 1 Jan 2021 16:47:40 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 02CCB386F011; Fri, 1 Jan 2021 21:47:38 +0000 (GMT) Received: from gateway22.websitewelcome.com (gateway22.websitewelcome.com [192.185.46.187]) by sourceware.org (Postfix) with ESMTPS id 0CEDE384402B for ; Fri, 1 Jan 2021 21:47:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0CEDE384402B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=tom@tromey.com Received: from cm16.websitewelcome.com (cm16.websitewelcome.com [100.42.49.19]) by gateway22.websitewelcome.com (Postfix) with ESMTP id A7B333B68 for ; Fri, 1 Jan 2021 15:47:32 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id vSGikXAVhHPnUvSGikgzF8; Fri, 01 Jan 2021 15:47:32 -0600 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Transfer-Encoding:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:To:From:Sender:Reply-To:Cc:Content-Type:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=VlDNEjv1jYiH8hsw1dNZ8wDvAQ9anfidMzyv30BQSOk=; b=YiY/bo24VUxhjq0RSSPb2wdYiR mTn1rdcOxwIh5oCXfRr/KCJySsuLpxRntkPenXCWq6/EnFtu+j58fIigpEA1gvugId7YFD718u9am umF5V9Zcn1D3qIX+GSil1jD5e; Received: from 97-122-81-39.hlrn.qwest.net ([97.122.81.39]:60374 helo=localhost.localdomain) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kvSGi-00292J-FF for gdb-patches@sourceware.org; Fri, 01 Jan 2021 14:47:32 -0700 From: Tom Tromey To: gdb-patches@sourceware.org Subject: [PATCH 016/203] Split out eval_op_binary Date: Fri, 1 Jan 2021 14:44:16 -0700 Message-Id: <20210101214723.1784144-17-tom@tromey.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20210101214723.1784144-1-tom@tromey.com> References: <20210101214723.1784144-1-tom@tromey.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 97.122.81.39 X-Source-L: No X-Exim-ID: 1kvSGi-00292J-FF X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 97-122-81-39.hlrn.qwest.net (localhost.localdomain) [97.122.81.39]:60374 X-Source-Auth: tom+tromey.com X-Email-Count: 17 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" This splits out a new eval_op_binary helper function. This function can handle several different binary operations: case BINOP_EXP: case BINOP_MUL: case BINOP_DIV: case BINOP_INTDIV: case BINOP_REM: case BINOP_MOD: case BINOP_LSH: case BINOP_RSH: case BINOP_BITWISE_AND: case BINOP_BITWISE_IOR: case BINOP_BITWISE_XOR: gdb/ChangeLog 2021-01-01 Tom Tromey * eval.c (eval_op_binary): New function. (evaluate_subexp_standard): Use it. --- gdb/ChangeLog | 5 +++ gdb/eval.c | 86 ++++++++++++++++++++++++++++----------------------- 2 files changed, 53 insertions(+), 38 deletions(-) diff --git a/gdb/eval.c b/gdb/eval.c index a94f61b0cec..5f9d5413498 100644 --- a/gdb/eval.c +++ b/gdb/eval.c @@ -1493,6 +1493,53 @@ eval_op_sub (struct type *expect_type, struct expression *exp, } } +/* Helper function for several different binary operations. */ + +static struct value * +eval_op_binary (struct type *expect_type, struct expression *exp, + enum noside noside, enum exp_opcode op, + struct value *arg1, struct value *arg2) +{ + if (noside == EVAL_SKIP) + return eval_skip_value (exp); + if (binop_user_defined_p (op, arg1, arg2)) + return value_x_binop (arg1, arg2, op, OP_NULL, noside); + else + { + /* If EVAL_AVOID_SIDE_EFFECTS and we're dividing by zero, + fudge arg2 to avoid division-by-zero, the caller is + (theoretically) only looking for the type of the result. */ + if (noside == EVAL_AVOID_SIDE_EFFECTS + /* ??? Do we really want to test for BINOP_MOD here? + The implementation of value_binop gives it a well-defined + value. */ + && (op == BINOP_DIV + || op == BINOP_INTDIV + || op == BINOP_REM + || op == BINOP_MOD) + && value_logical_not (arg2)) + { + struct value *v_one; + + v_one = value_one (value_type (arg2)); + binop_promote (exp->language_defn, exp->gdbarch, &arg1, &v_one); + return value_binop (arg1, v_one, op); + } + else + { + /* For shift and integer exponentiation operations, + only promote the first argument. */ + if ((op == BINOP_LSH || op == BINOP_RSH || op == BINOP_EXP) + && is_integral_type (value_type (arg2))) + unop_promote (exp->language_defn, exp->gdbarch, &arg1); + else + binop_promote (exp->language_defn, exp->gdbarch, &arg1, &arg2); + + return value_binop (arg1, arg2, op); + } + } +} + struct value * evaluate_subexp_standard (struct type *expect_type, struct expression *exp, int *pos, @@ -2199,44 +2246,7 @@ evaluate_subexp_standard (struct type *expect_type, case BINOP_BITWISE_XOR: arg1 = evaluate_subexp (nullptr, exp, pos, noside); arg2 = evaluate_subexp (nullptr, exp, pos, noside); - if (noside == EVAL_SKIP) - return eval_skip_value (exp); - if (binop_user_defined_p (op, arg1, arg2)) - return value_x_binop (arg1, arg2, op, OP_NULL, noside); - else - { - /* If EVAL_AVOID_SIDE_EFFECTS and we're dividing by zero, - fudge arg2 to avoid division-by-zero, the caller is - (theoretically) only looking for the type of the result. */ - if (noside == EVAL_AVOID_SIDE_EFFECTS - /* ??? Do we really want to test for BINOP_MOD here? - The implementation of value_binop gives it a well-defined - value. */ - && (op == BINOP_DIV - || op == BINOP_INTDIV - || op == BINOP_REM - || op == BINOP_MOD) - && value_logical_not (arg2)) - { - struct value *v_one; - - v_one = value_one (value_type (arg2)); - binop_promote (exp->language_defn, exp->gdbarch, &arg1, &v_one); - return value_binop (arg1, v_one, op); - } - else - { - /* For shift and integer exponentiation operations, - only promote the first argument. */ - if ((op == BINOP_LSH || op == BINOP_RSH || op == BINOP_EXP) - && is_integral_type (value_type (arg2))) - unop_promote (exp->language_defn, exp->gdbarch, &arg1); - else - binop_promote (exp->language_defn, exp->gdbarch, &arg1, &arg2); - - return value_binop (arg1, arg2, op); - } - } + return eval_op_binary (expect_type, exp, noside, op, arg1, arg2); case BINOP_SUBSCRIPT: arg1 = evaluate_subexp (nullptr, exp, pos, noside); -- 2.26.2