From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9814 invoked by alias); 13 Nov 2017 20:04:51 -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 9791 invoked by uid 89); 13 Nov 2017 20:04:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=15pm, convinced, relationship, among X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-yw0-f194.google.com Received: from mail-yw0-f194.google.com (HELO mail-yw0-f194.google.com) (209.85.161.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 13 Nov 2017 20:04:49 +0000 Received: by mail-yw0-f194.google.com with SMTP id r186so5985925ywe.13; Mon, 13 Nov 2017 12:04:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z/i4mKIrgfCIvUrNND6rYIHf6bWVjbV8qxDHOoSnuyU=; b=DK8JHdbavkHtafmb29QXxaCWE6Rm9Oi7ls8t3et49+DXh+1oCXor/dlFs2ulgbwa07 WW81eZkGxY5+l8b/VVwQLg3zOTbQIQmfCs1FYLxy5p8lIuXyECe+A8oTx2GD91pbKb8A cTeDPPo9IdjpIuKH5ODMRsvzb8MtNcTCRGxl6fhqWC/Dd0gbZZOyQ6AkGFagRGWY/P7y hIG6WjOxmkwK47Z9DW/0U2jFCCwph0ppY/X2Tvz/mfc6glkaTN4X5okNYSp20kWOOlf/ AMZEF3zXAp/7Xhi97WmSA00D0QLK32V4t0MUf7lE2imLXCTcSW8Zq56ldUzztbqxixec GMYA== X-Gm-Message-State: AJaThX5JH8ixjtFC1RVyqb5/gSThybPMWrg7hAoPDWI2KRAlsDpL61PE TYTti/CJk8qVHL3Za5gSwy/kfqfjzMCwCf+5mnM= X-Google-Smtp-Source: AGs4zMbdcqCgRZ4TsaJM/yqL/GP/u2FslX6/am5CUq12tiOWyVbUb+Zqwi5gtpzdGUKpS2Lqs4EqK2pJ/yOzgilrTgk= X-Received: by 10.129.175.17 with SMTP id n17mr6468064ywh.199.1510603487946; Mon, 13 Nov 2017 12:04:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.163.146 with HTTP; Mon, 13 Nov 2017 12:04:47 -0800 (PST) In-Reply-To: References: <1510079175-10927-1-git-send-email-blomqvist.janne@gmail.com> <20171107200641.GA47000@troutmask.apl.washington.edu> <20171107222701.GA47818@troutmask.apl.washington.edu> From: Janne Blomqvist Date: Mon, 13 Nov 2017 20:04:00 -0000 Message-ID: Subject: Re: [PATCH, fortran, PR 82869] Introduce default_logical_type_node and logical_type_node To: Steve Kargl Cc: Fortran List , GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00075.txt.bz2 On Wed, Nov 8, 2017 at 1:57 PM, Janne Blomqvist wrote: > On Wed, Nov 8, 2017 at 12:27 AM, Steve Kargl > wrote: >> On Tue, Nov 07, 2017 at 10:38:43PM +0200, Janne Blomqvist wrote: >>> On Tue, Nov 7, 2017 at 10:06 PM, Steve Kargl >>> wrote: >>> > On Tue, Nov 07, 2017 at 08:26:15PM +0200, Janne Blomqvist wrote: >>> >> + >>> >> + logical_type_node = gfc_get_logical_type (4); >>> > >>> > Can you add a comment to note that the 4 is purposely chosen? >>> > A year or so from now, someone might change this to gfc_default_logical_kind >>> > without understand/recalling why 4 is used. >>> >>> The patch contains a comment explaining that in trans-types.h. >> >> Well, did say I scanned the patch ;-) >> >>> However, a bit of further experimenting with my patch revealed that >>> one can cause these latent bugs I feared to appear by playing with >>> -fdefault-integer-8 / -finteger-4-integer-8 with the example from >>> bugzilla (so we end up passing a pointer to a logical(kind=4) variable >>> but we tell libgfortran it's kind=8). I did fix the most obvious ones >>> in the attached patch (on top of the previous one), but I'm not >>> convinced it's exhaustive. >>> >>> So I wonder, do we actually care enough about -fdefault-integer-8 / >>> -finteger-4-integer-8 to do this kind of micro-optimization (i.e. use >>> 4 byte logical temporary variables if we can even when we use >>> -fdefault-integer-8 / -finteger-4-integer-8), or should we play it >>> safe and just use default_logical_type_node everywhere? >> >> I certainly don't care about fallout when one uses -fdefault-* >> options. I've stated more than once I think these should >> be removed, because these options break storage association >> (among other things). I a little surprise that -finteger-4-integer-8 >> have an effect, but I admit I haven't looked closely at the >> internal representation of a Fortran logical and its relationship >> to INTEGER(4). >> >> -- >> steve > > > So in the end I decided to play it safe and do the simpler approach. > Patch that I committed as r254526 attached. Unless there are > objections, I'll apply it to the GCC-7 tree in a few days as well > since it's a regression. Applied to the gcc-7 branch in r254706. -- Janne Blomqvist