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

[Jeff Law]

On 03/23/2018 07:26 AM, Lukasz Kolodziejczyk wrote:
> On 23/03/18 08:12, Jakub Jelinek wrote:
>> On Thu, Mar 22, 2018 at 07:07:11PM -0700, Jerry DeLisle wrote:
>>>> But in the tables I referenced and in the new code we want 15, 7, 2
>>>> respectively.
>>> The widths we use now were picked specifically to assure that values
>>> written
>>> and then read back in result in the same values.
>>>
>>> I have some philosophical questions.
>>>
>>> 1) Why do you want 15, 7, 2? Why is this so critical?
>> Because that is what all those compilers document and agree on.
>> See e.g.
>> https://software.intel.com/en-us/node/678750#32937290-265D-4805-B2B7-4E78F6AAD0D8
>>
>> for Intel documentation, I'm sure Jeff has links to other documentations.
> 
> In addition to the Intel and Oracle compiler documentation linked by
> Jakub, the Compaq Visual Fortran documentation is in support of 15, 7, 2:
> http://jp.xlsoft.com/documents/intel/cvf/cvf_lref.pdf ("Default Widths
> for Data Edit Descriptors", page 305)
> 
>>> 2) If it is critical, why are you trying to make gfortran do non
>>> standard
>>> stuff?  Why is it so difficult to write a python script to translate
>>> any and
>>> all legacy DEC code to standard conforming format specifiers?  The only
>>> thing that would not be straight forward is if the format strings are
>>> being
>>> computed on the fly. Not the best practice, but nothing surprises me
>>> with
>>> these legacy codes.
>> Changing this stuff isn't that easy with python scripts, because for that
>> you need to understand the kinds of the arguments.  If the format
>> string is
>> visible to compiler and so are the kinds of the arguments, sure, the
>> compiler could change it at compile time, passing a different format
>> string
>> to the runtime and the runtime wouldn't have to worry.  If the format
>> string
>> is built at runtime, or even compile time, but the compiler can't see it
>> (say the format string in one TU and used in another TU), then that is
>> something that can only be handled in the runtime.
> 
> While we agree that modernising Fortran is the appropriate long-term
> goal, in the short term it might not be feasible for users of gfortran.
> Therefore we believe that implementing the change in this way is the
> most accessible approach for those that require this feature in the
> immediate future.
Agreed 100%.   Trying to move these old codebases into the modern world
is tough and requires decisions to be made about what to modernize
immediately vs what to defer (and thus rely on compatibility modes in
the compiler/runtime).

My understanding is there are things that are going to be fixed via
automated tools.  There are other things where we may rely on compiler
diagnostics to catch and for humans to fix and others where
modernization may be deferred  and we rely on compatibility modes in the
compiler/runtime.  The decision about which bucket any particular issue
falls into involves a nontrivial calculus.

Based on my understanding of known issues today it is believed the best
path forward includes deferring handling of default widths in format
statements by relying on compatibility modes.  Other issues are
obviously going into other buckets.

FWIW, I have proposed that the compiler issue diagnostics when it is
able to discover at compile time that a default with is going to be
used.  And I ultimately hope that proposal moves forward as I believe it
will help with the overall modernization effort.

Jeff