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

[Fritz Reese]

Sorry I am a bit late on the discussion, I overlooked this chain of messages...

> On Tue, Mar 20, 2018 at 12:41:25PM -0600, Jeff Law wrote:
> Because this is a case where where a compile-time flag needs to affect
> the runtime, we need to communicate to the runtime that the magic
> compile-time flag is on.
>
> We have two general approaches for this kind of communication.  One is
> to set a mask within the DT_PARM which gets passed into the runtime at
> the call site.  The other is to marshall the flags in
> gfortran_set{args,options} on a global basis.

My first thought is whether we need to reserve a new bit at all. Since
allowing a default for zero-width format specifiers doesn't seem
terribly harmful, perhaps we could lump it into -std=legacy? The
standard flags are already passed to the runtime, so no additional
information would be required. I believe this would simplify the
implementation on top of saving the last few DT_PARM bits.

In this way any modern Fortran programs would still happily error-out,
and DEC programs (which almost certainly must be using -fdec or
-std=legacy by now) would get the default format behavior as such a
DEC programmer might expect. ("Modern Fortran" and "DEC programmer"
are two of my favorite oxymorons.)

Fortunately, I think width specifiers in format statements are often
not critical, at least when the output of the formatting is to be
human-read (who cares whether there are 16 or 15 spaces in each
column). For this reason as well I am of the opinion that lumping the
equivalent of -fdec-format-defaults into -std=legacy (without a new
flag at all) should be fine. After all, is there any code which
compiles with legacy support that doesn't want legacy (DEC)
format-width behavior? Or is there any code which runs modern Fortran
that should want DEC format behavior? It is easy to say no to the
latter - modern Fortran users can be told "don't do legacy stuff". The
former seems reasonable to me as well.

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

Yes, without dynamic format statements it is simple enough to catch at
compile time. Fortunately in the code bases I support there were only
static instances of omitted width specifiers, and few enough and easy
enough to catch to fix by hand. Unfortunately I can see the difficulty
of catching these with a code base that relies heavily on
dynamically-generated format strings.

In my case, I support an application which many people have written
plugins for (often in DEC Fortran). I can introduce changes in the
application itself to allow it to be compiled with GNU Fortran, but I
cannot easily extend any patches I've had to make to the
plugin-writers or users of the plugins to allow them to be compiled
with GFC as well. Some of these plugins have many users but few (or
no) maintainers, so changing and redistributing code can be difficult.

As Jeff mentioned, another good reason is when conversion of code
cannot be automated or may be difficult (such as with the
STRUCTURE/UNION extensions... or dynamically-generated format
strings).

There is another not-so-uncommon reason that comes to mind. Fortran
was(is) often used in the scientific and engineering community. These
types of applications often support real-time systems or those under
other strict constraints/lock-downs. In these cases, bureaucratic or
technical barriers may make it difficult for updates to the code to
actually be rolled out to an operational system. Given a choice
between changing the code running a mission-critical application or
using a different compiler, you might see how the latter can be an
attractive option. However the flexibility of GCC and its array of
cross-platform support do make it much more attractive than many
proprietary compilers, so in such cases tweaking the compiler is the
best option (in the opinion of some).

Of course I agree that each extension to the compiler should be
carefully considered, because there is always an added maintenance
cost if/when the new code (or code near it!) is changed.

To summarize; I think the effect of introducing this feature is fairly
low-impact, and I think the risk of compiler/library changes can be
minimized without adding a DT_PARMS bit by lumping the behavior into
-std=legacy.


---
Fritz Reese