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

[Jerry DeLisle]

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?

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.

Yes, we have done a lot of -fdec features, grudgingly so.  So here we 
are again, bloating the compiler yet again.

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.

--- 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.

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.

(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)

Regards,

Jerry