From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp41.i.mail.ru (smtp41.i.mail.ru [94.100.177.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 0438346970E for ; Wed, 5 Feb 2020 19:19:15 +0300 (MSK) From: Nikita Pettik Date: Wed, 5 Feb 2020 19:19:09 +0300 Message-Id: In-Reply-To: References: In-Reply-To: References: Subject: [Tarantool-patches] [PATCH 1/4] sql: remove cast to INT during FP arithmetic ops List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: tarantool-patches@dev.tarantool.org Cc: v.shpilevoy@tarantool.org Arithmetic operations are implemented by OP_Add, OP_Substract etc VDBE opcodes which consist of almost the same internal logic: depending on type of operands (integer of FP) execution flow jumps to the one of two branches. At this point branch which is responsible for floating point operations finishes with next code: 1668 if (((type1|type2)&MEM_Real)==0 && !bIntint) { 1669 mem_apply_integer_type(pOut); 1670 } At least one type of type1 and type2 is supposed to be MEM_Real. Otherwise, execution flow either hits branch processing integer arithmetic operations or VDBE execution is aborted with ER_SQL_TYPE_MISMATCH Thus, condition under 'if' clause is always evaluated to 'false' value ergo mem_apply_integer_type() is never called. Let's remove this dead code. Implemented by Mergen Imeev --- src/box/sql/vdbe.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/src/box/sql/vdbe.c b/src/box/sql/vdbe.c index eab74db4a..a5f161d90 100644 --- a/src/box/sql/vdbe.c +++ b/src/box/sql/vdbe.c @@ -1566,7 +1566,6 @@ case OP_Subtract: /* same as TK_MINUS, in1, in2, out3 */ case OP_Multiply: /* same as TK_STAR, in1, in2, out3 */ case OP_Divide: /* same as TK_SLASH, in1, in2, out3 */ case OP_Remainder: { /* same as TK_REM, in1, in2, out3 */ - char bIntint; /* Started out as two integer operands */ u32 flags; /* Combined MEM_* flags from both inputs */ u16 type1; /* Numeric type of left operand */ u16 type2; /* Numeric type of right operand */ @@ -1589,7 +1588,6 @@ case OP_Remainder: { /* same as TK_REM, in1, in2, out3 */ bool is_lhs_neg = pIn1->flags & MEM_Int; bool is_rhs_neg = pIn2->flags & MEM_Int; bool is_res_neg; - bIntint = 1; switch( pOp->opcode) { case OP_Add: { if (sql_add_int(iA, is_lhs_neg, iB, is_rhs_neg, @@ -1629,7 +1627,6 @@ case OP_Remainder: { /* same as TK_REM, in1, in2, out3 */ } mem_set_int(pOut, iB, is_res_neg); } else { - bIntint = 0; if (sqlVdbeRealValue(pIn1, &rA) != 0) { diag_set(ClientError, ER_SQL_TYPE_MISMATCH, sql_value_to_diag_str(pIn1), "numeric"); @@ -1640,6 +1637,7 @@ case OP_Remainder: { /* same as TK_REM, in1, in2, out3 */ sql_value_to_diag_str(pIn2), "numeric"); goto abort_due_to_error; } + assert(((type1 | type2) & MEM_Real) != 0); switch( pOp->opcode) { case OP_Add: rB += rA; break; case OP_Subtract: rB -= rA; break; @@ -1665,9 +1663,6 @@ case OP_Remainder: { /* same as TK_REM, in1, in2, out3 */ } pOut->u.r = rB; MemSetTypeFlag(pOut, MEM_Real); - if (((type1|type2)&MEM_Real)==0 && !bIntint) { - mem_apply_integer_type(pOut); - } } break; -- 2.15.1