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

[Jerry DeLisle <jvdelisle@charter.net>]

On 03/23/2018 06: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.
> 
> We have tested Jeff's patch on trunk and can confirm it works as 
> expected with no regressions.
> 
> 
> Lukasz
> 
> 
OK, this makes sense to me. From where I sit, I have a limited view of 
these use cases.

Jerry