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

[Jeff Law]

On 03/22/2018 08:07 PM, Jerry DeLisle wrote:
> Sorry for my delayed response to this thread.
> 
> On 03/21/2018 10:49 PM, Jeff Law wrote:
>> On 03/21/2018 12:38 PM, Janne Blomqvist wrote:
>>> One thing which struck me was that you (or
>>> whoever implemented it???) has reinvented setting the various default
>>> widths, code which already exists in libgfortran in order to support
>>> list directed output and zero width formats (zero width formats being,
>>> roughly, the standardized version of the DEC Format extension).
> 
> Thanks Janne for pointing this out, its the first thing I noticed.
> 
>> So I've been wandering around the runtime trying to find this code.  The
>> most obvious analogous code is the list directed output support.  But
>> sadly the constants are different.
> 
> Nothing sad about, just did not meet your expectation.
> 
>>
>> Maybe there's some aspect of the implementation which corrects them
>> later, but I don't see it.  Let's take a look at kind/length of 4.  In
>> set_fnode_default we have:
>>
>> Â Â Â  case 4:
>> Â Â Â Â Â Â  f->u.real.w = 16;
>> Â Â Â Â Â Â  f->u.real.d = 9;
>> Â Â Â Â Â Â  f->u.real.e = 2;
>> Â Â Â Â Â Â  break;
>>
>> 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?
Of the compilers that handle this extension, those are the documented
values they use.

> 
> 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.
Dynamic cases are a concern.  They're certainly using tools to bring the
code base up-to-date in other areas, but it's not believed that those
tools are going to be sufficient to address the problems with default
widths.

I hope that a modernization effort around format statement handling in
this codebase will start once they're up and running with Gfortran.
Though it's obviously out of my control.


> 
> Yes, we have done a lot of -fdec features, grudgingly so.  So here we
> are again, bloating the compiler yet again.
Understood.  Believe me, I'm no fan of catering to old non-conformant code.

> 
> It just seems to me that we have the cart before the horse.  The effort
> should be spent writing a program to take DEC Fortran code and translate
> it into standard conforming Fortran, rather than taking the gfortran
> frontend and runtime and modifying to compile non standard code.
> 
> This is just my opinion. Just think about it, a one time translation to
> conforming Fortran and it never has to be dealt with again.
Everyone involved is thinking about it :-)  The issues with format
statements are just one of many issues that are being tackled.  Reality
is not everything is going to be done immediately.


> 
> --- snip ---
> 
>>
>> Anyway, I'll open a discussion with Fritz to see if we can move this
>> forward on way or another.  If he's OK with reserving the bit in DT_PARM
>> for default width support is that enough for you at this stage?  Again,
>> I'm not pushing for the code into gcc-8 (seems way too late), but just
>> the bit allocated for this purpose since it effectively is part of the
>> ABI.
> 
> It is really not up to Fritz, we are a team of people and if there is
> consensus, then it is OK. Fritz contributed portions of the DEC code
> changes, and there are several other people who have done the vast
> majority of the IO library work way before any DEC features.
I don't generally work in the Fortran front-end, so I'm not sure who the
decision makers are.   Janne suggested I discuss implementation issues
with Fritz, which is good and I'd love his feedback.

> 
> Reserving the bit is OK with me, doing so does no harm and it does not
> break the ABI.  I just question why we do this at all as I stated
> philosophically above. I am not objecting either, I just think
> converting the legacy code directly outside gfortran is a better way.
OK.  I'll submit a patch with a comment for the use of the bit.  We can
iterate on implementation details as gcc-9 stage1 opens.

> 
> (Why I think this? because, later someone will find either a bug in
> gfortran handling and it will get modified again..., and again,... and
> again, ... and then again some other obscure feature and on and on. It
> is this path that lead to the world recognizing the need for standards,
> to stop the cycle. And here we are in 2018, perpetuating it in the face
> of all the standardization efforts for the last twenty years)
No doubt.  In many ways I think the Fortran user community has had a
harder time moving their code into the modern era than the C community.
I'm not entirely sure why that is, but it's certainly the sense I've
gotten through the years.

Thanks,
Jeff