Re: Desire to allocate bit in DT_PARM bitmask for DEC FORMAT compatibility purposes

[Jeff Law <law@redhat.com>]

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.

I'm happy to go with either approach (or even generalizing the default
exponent code).  What's important to me is that we reach agreement on
the mechanism we're using for communication between the compiler and
runtime.

Jeff