From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id aPC3MHAYHWAjGwAAWB0awg (envelope-from ) for ; Fri, 05 Feb 2021 05:05:36 -0500 Received: by simark.ca (Postfix, from userid 112) id C3FA21EFCB; Fri, 5 Feb 2021 05:05:36 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, URIBL_BLOCKED autolearn=ham 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 2E0671E939 for ; Fri, 5 Feb 2021 05:05:36 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D6AAA3857032; Fri, 5 Feb 2021 10:05:35 +0000 (GMT) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id B090C3857032 for ; Fri, 5 Feb 2021 10:05:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B090C3857032 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C9961ACBA; Fri, 5 Feb 2021 10:05:31 +0000 (UTC) Subject: Re: [PATCH][gdb/exp] Fix assert when adding ptr to imaginary unit From: Tom de Vries To: Tom Tromey References: <20210128130655.GA8529@delia> <87im7hduh9.fsf@tromey.com> <396c65a8-3054-44ab-db5c-bbef7d698b66@suse.de> Message-ID: Date: Fri, 5 Feb 2021 11:05:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 1/29/21 8:10 AM, Tom de Vries wrote: > On 1/29/21 8:04 AM, Tom de Vries wrote: >> On 1/28/21 3:08 PM, Tom Tromey wrote: >>>>>>>> "Tom" == Tom de Vries writes: >>> >>> Tom> 2021-01-28 Tom de Vries >>> >>> Tom> PR exp/27265 >>> Tom> * valarith.c (scalar_binop): Don't call complex_binop unless >>> Tom> arguments are either complex or can be casted to complex. >>> >>> Thanks for doing this. >>> >>> Tom> + if ((type1->code () == TYPE_CODE_COMPLEX >>> Tom> + && (type2->code () == TYPE_CODE_COMPLEX >>> Tom> + || type2->code () == TYPE_CODE_INT >>> Tom> + || type2->code () == TYPE_CODE_FLT)) >>> Tom> + || ((type2->code () == TYPE_CODE_COMPLEX >>> Tom> + && (type1->code () == TYPE_CODE_COMPLEX >>> Tom> + || type1->code () == TYPE_CODE_INT >>> Tom> + || type1->code () == TYPE_CODE_FLT)))) >>> Tom> return complex_binop (arg1, arg2, op); >>> >>> Maybe it should use is_floating_type || is_integral_type instead? >>> is_scalar_type sounds like it should be right but does something really >>> different instead. That function looks suspect to me. >>> >>> This approach would still rule out fixed point. I'm not sure if that's >>> ok to do though. >>> >>> Also weirdly, is_fixed_point_type looks through TYPE_CODE_RANGE (seems >>> reasonable) but is_integral_type does not (seems wrong). >>> >> >> I managed to create an example using TYPE_CODE_BOOL that used to work >> but was broken by this patch, added it to the tests in the patch. >> >> I've now gone a different route: instead of trying to narrow down when >> complex_binop can be called, detect the error situation in complex_bin >> and throw an error. >> >> That avoids speculation about what type is left after promotion. >> Instead, we just check the type after promotion. >> >> WDYT? > > And FWIW, this WIP follow-up patch enables decimal float complex well > enough to do "print (_Decimal32)0 + 5i". > Filed as PR27350 - Support complex decimal float ( https://sourceware.org/bugzilla/show_bug.cgi?id=27350 ). Thanks, - Tom