From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36748 invoked by alias); 28 Sep 2017 17:41:26 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 36725 invoked by uid 89); 28 Sep 2017 17:41:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=watch X-Spam-User: qpsmtpd, 2 recipients X-HELO: troutmask.apl.washington.edu Received: from troutmask.apl.washington.edu (HELO troutmask.apl.washington.edu) (128.95.76.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Sep 2017 17:41:24 +0000 Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id v8SHfMgv006856 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 Sep 2017 10:41:23 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id v8SHfMHS006855; Thu, 28 Sep 2017 10:41:22 -0700 (PDT) (envelope-from sgk) Date: Thu, 28 Sep 2017 17:41:00 -0000 From: Steve Kargl To: Paul Richard Thomas Cc: "fortran@gcc.gnu.org" , gcc-patches Subject: Re: [PATCH] Fix fortran/81509 Message-ID: <20170928174122.GA6554@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20170927193624.GA91517@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00130.txt.bz2 On Thu, Sep 28, 2017 at 10:46:06AM +0100, Paul Richard Thomas wrote: > > I'll take your word for it on the F2008 contraints. Given that the > patch is very good - OK for trunk. > The text for IAND from F2008 is Arguments. I shall be of type integer or a boz-literal-constant. J shall be of type integer or a boz-literal-constant. If both I and J are of type integer, they shall have the same kind type parameter. I and J shall not both be boz-literal-constants. Result Characteristics. Same as I if I is of type integer; otherwise, same as J. Result Value. If either I or J is a boz-literal-constant, it is first converted as if by the intrinsic function INT to type integer with the kind type parameter of the other. Prior to my patch one could do IAND(1_4, 4_8). gfortran would convert the 1_4 to 1_8 and return effectively IAND(1_8, 4_8). This violates the 2nd sentence in the description of J. One might argue that the extension makes sense except the documentation does not state what occurs. The real problem comes with IAND(42_2,z'DEAD') where z'DEAD' is some mask user wants to apply to an INTEGER(2) entity. On x86_64 and due to the implementation of a BOZ to statisfy requirements of the DATA statement from F95, z'DEAD' is implicitly an INTEGER(16). So, IAND(42_2,z'DEAD') convert 42_2 to 42_16 and returns a INTEGER(16). This is a violation of F2008 'Result Value' statement. In hindsight, some 13 years ago I should have introduced a BT_BOZ basic type definition. I need to check, but at one time gfortran for a boz literal constant set x->is_boz=1, x->ts.type=BT_INTEGER, and x->ts.kind=16. where x is a gfc_expr *. The is_boz is unneeded with BT_BOZ and the kind can be set to the appropriate kind when needed. A bonus with BT_BOZ would automatic fix all other intrinsics which currently accept a boz, e.g., ABS(z'DEAD'). -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow