From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44278 invoked by alias); 12 Sep 2018 08:16:11 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 39052 invoked by uid 89); 12 Sep 2018 08:16:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Though, HX-Envelope-From:sk:Richard X-HELO: EUR02-AM5-obe.outbound.protection.outlook.com Received: from mail-eopbgr00058.outbound.protection.outlook.com (HELO EUR02-AM5-obe.outbound.protection.outlook.com) (40.107.0.58) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Sep 2018 08:16:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zZOvrakqzvuVtZ3heuMJOrQdJFNGjIPNhA6NKFp9iVU=; b=CSGoOSwCqgyE2AbrjFInIz17DtCnmLRu4Sj7Nq3X80bW0SYweQEXLWYhxm1+KU7YUhobdy2yNBWEGg8duDVbP49Km2jeCu0JQw7DdL5ei9cFQPAJjWK93ghJfxdoZNRVCu1c1sIwjSCQoL+KCS6S94ke3pYfkzjh2zjg5HakZbA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Richard.Bunt@arm.com; Received: from [10.37.9.180] (217.140.96.140) by AM0PR08MB3185.eurprd08.prod.outlook.com (2603:10a6:208:5d::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.17; Wed, 12 Sep 2018 08:16:01 +0000 Subject: Re: [PATCH v2] Logical short circuiting with argument lists To: Tom Tromey Cc: gdb-patches@sourceware.org, nd@arm.com References: <79494820-f795-ad3c-8546-0ad288cd05b0@arm.com> <87mustueua.fsf@tromey.com> From: Richard Bunt Message-ID: <2fd31db3-e0f7-262b-6b30-bd7a78cbabbf@arm.com> Date: Wed, 12 Sep 2018 08:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87mustueua.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-Path: richard.bunt@arm.com Received-SPF: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00350.txt.bz2 On 09/07/2018 11:23 PM, Tom Tromey wrote: >>>>>> "Richard" == Richard Bunt writes: > > I wonder if we really want this to error in the case where the symbol > isn't found. But I suppose it is necessary for your patch to work. > > I tend to think it is fine; I couldn't think of a plausible, > non-pathological way that I would want to use the non-erroring behavior. If I understand correctly the concern here is that the evaluation will report an error if the symbol is not found, even if it is supposed to be evaluated in a lazy manner. I considered a similar issue when testing with the following expression: print k .OR. array(1,2,3,4) where k == .TRUE. and array only has 3 dimensions. The debugger still reports that this is invalid even though the array access is not needed for the truth value. I considered this to be acceptable as this code wouldn't compile anyway and I would rather it failed fast than at some point later (when k becomes false). I believe a similar justification holds for the case where array is an invalid symbol. > > Though, another option is to do this in a fortran-specific way. Are you able to provide some more details on this approach please? > > Richard> + gdb_test "p .TRUE. .OR. binary_string($range1) .OR. truth_table($range2, 1)" \ > > For some of the tests -- I'm afraid I didn't enumerate them -- you will > need to supply a different (and unique) test name to gdb_test, because > there is a rule against tests having parenthesized text at the end of > their name: > > https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Do_not_use_.22tail_parentheses.22_on_test_messages > > Tom > Based on the discussion with Simon I understand that there is no issue here. However, if I had used a space between the array symbol name and the parenthesizes this would have been a problem. This is useful to know. Missing comments, style errors and non-idiomatic code have been fixed in v3. Many thanks for the comments, Rich.