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

[Lukasz Kolodziejczyk]

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.

We have tested Jeff's patch on trunk and can confirm it works as expected with 
no regressions.


Lukasz