Desire to allocate bit in DT_PARM bitmask for DEC FORMAT compatibility purposes
Jerry DeLisle
jvdelisle@charter.net
Sat Mar 24 18:20:00 GMT 2018
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.
Jerry
More information about the Fortran
mailing list