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

[Jakub Jelinek]

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.

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

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

We can certainly offer a warning with suggested fixit, if the compiler sees
the format string with ommitted widths, it can warn that it is a DEC
extension and hint how to rewrite the string with the default width so that
users can change it (does Fortran FE also have the -fdiagnostics-generate-patch
support?).  I think doing it outside of the compiler or runtime is
just too hard, and can't handle the cases where the format string is not
visible.  With the reserved bit the patch still properly rejects such code
by default (either with compile time diagnostics or at runtime, depending on
what can see the format string), and with -fdec it is like all the other DEC
extensions, including one done also in the runtime library, the
http://gcc.gnu.org/r241828 change.

	Jakub