From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57520 invoked by alias); 26 Mar 2018 03:41:03 -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 57509 invoked by uid 89); 26 Mar 2018 03:41:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Mar 2018 03:41:01 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B470223E6E7; Mon, 26 Mar 2018 03:40:59 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-22.rdu2.redhat.com [10.10.112.22]) by smtp.corp.redhat.com (Postfix) with ESMTP id 944BF18A68; Mon, 26 Mar 2018 03:40:57 +0000 (UTC) Subject: Re: Desire to allocate bit in DT_PARM bitmask for DEC FORMAT compatibility purposes To: Jerry DeLisle , sgk@troutmask.apl.washington.edu, Jakub Jelinek Cc: Fritz Reese , Janne Blomqvist , Fortran List References: <339953f7-5a37-99e0-a110-43e5f072b97d@redhat.com> <2e64bcdc-dafd-fdd4-ce01-098e00a51b9f@charter.net> <20180323081221.GA8577@tucnak> <380c2de1-5f32-cd3c-2f9f-ffd05e8339ef@redhat.com> <20180324081852.GN8577@tucnak> <20180324160404.GA3874@troutmask.apl.washington.edu> <20180324162006.GO8577@tucnak> <20180324171137.GA92284@troutmask.apl.washington.edu> <6763dfb8-426d-8be6-319e-ba947ea425d7@charter.net> <77fd734d-ad46-4f37-6af7-0b4919cf92ba@redhat.com> From: Jeff Law Message-ID: <0a2dd6d8-68b7-7e3b-489e-f2d88e17f080@redhat.com> Date: Mon, 26 Mar 2018 03:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-03/txt/msg00186.txt.bz2 On 03/25/2018 01:09 PM, Jerry DeLisle wrote: > On 03/25/2018 11:48 AM, Jeff Law wrote: >> On 03/24/2018 12:20 PM, Jerry DeLisle wrote: >>> On 03/24/2018 10:11 AM, Steve Kargl wrote: >>>> On Sat, Mar 24, 2018 at 05:20:06PM +0100, Jakub Jelinek wrote: >>>>> On Sat, Mar 24, 2018 at 09:04:04AM -0700, Steve Kargl wrote: >>>>>>> Or shall we just check (warn_std & GFC_STD_LEGACY) != 0, if true, >>>>>>> set fmt->error if width etc. is missing, otherwise use the -1 and >>>>>>> later >>>>>>> resolve it to the default? >>>>>> >>>>>> No.  DEC extensions should be activated by the use of one of the >>>>>> -fdec-* options.  For this extension, I think it can be grouped >>>>>> under the general purpose -fdec option.  In the Fortran FE, -fdec >>>>>> then becomes "if (flag_dec)".  I don't recall if Fritz set up >>>>>> passing flag_dec into libgfortran. >>>>> >>>>> I don't see it passed directly. >>>>> With -fdec compile_options.warn_std is 0, rather than the default >>>>> GFC_STD_LEGACY | GFC_STD_F95_DEL, but _gfortran_set_options >>>>> argument is exactly the same for -fdec and for -std=legacy, so there >>>>> is no >>>>> way to differentiate the two. >>>>> >>>>> So, the only way to handle this DEC extension without adding new bits >>>>> (to either compile_options (i.e. GFC_STD_*), or the io flags as shown >>>>> by the >>>>> patch Jeff posted) would be to abuse the IOPARM_dt_default_exp bit >>>>> for it, >>>>> i.e. tie together the extension omitting exponent and the default >>>>> width. >>>>> Seems the IOPARM_dt_default_exp is set whenever -fdec and not >>>>> otherwise: >>>>> >>>> >>>> Well, if we add >>>> >>>> #define GFC_STD_DEC_EXT        (1<<13) >>>> >>>> to fortran/libgfortran.h, we still have 18 bits left. >>>> >>>> Then change options.c(set_dec_flags) to include this in the >>>> list of "standards" passed to libgfortran.  The tests would >>>> then look like >>>> >>>>      fmt->value = (gfc_option.allow_std & GFC_STD_DEC_EXT) ? 2 : 1; >>>> >>>> I don't know if this is any better than using Jeff's idea of reserving >>>> bit #28 in flag (and adding a flag2).  Other than 18 bits at 5 to 8 >>>> years per revision to the standards, means we'll be long retired >>>> before someone has to deal with running out of bits. >>>> >>> >>> I like this approach because we can then use it for anything else that >>> crops up down the road for the runtime. >> In this scenario we communicate between the compiler and runtime via the >> ALLOW_STD field.  The technical difference is the change applies >> globally rather than on per-call basis (DT_PARMs IIUC is computed and >> passed to the runtime for each format call).  I think that's likely to >> be OK. >> >> The downside of this approach is it puts these extensions under the -std >> namespace rather than in -fdec.  I think Steve K. has expressed a desire >> to keep this stuff under -fdec.  I'm not sure how to reconcile the >> difference of opinions here. > > Definitely under -fdec. I assumed one could set a new option bit with > that and have it available globally. If not the DT_PARM bit is fine too. > Either way, keep under -fdec. Ah, have -fdec set the right option in ALLOW_STD? That ought to work. I'll give it a whirl. jeff