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

[Jeff Law]

On 03/21/2018 12:38 PM, Janne Blomqvist wrote:
> On Wed, Mar 21, 2018 at 7:29 PM, Jeff Law  wrote:
>> On 03/21/2018 11:25 AM, Jakub Jelinek wrote:
>>> On Tue, Mar 20, 2018 at 12:41:25PM -0600, Jeff Law wrote:
 This is documented in the old manuals from DEC and I've found
 essentially the same documentation in Oracle/Sun's current documentation
 as well as old MIPS documentation.   I have a high degree of confidence
 it exists in IBM's Fortran compilers as well.  In contrast Intel & PCG's
 Fortran compilers do not seem to support this extension.
>>>
>>> My testing disagrees with the last one, at least ifort 17.0.4 handles
>>> the default widths like this patch does with -fdec.
>> I was going from what I could find in the online documentation.  I could
>> have missed it, or it could be undocumented behavior.
> 
> FWIW, IIRC the lineage of the Intel Fortran compiler frontend is that
> at some point DEC did a Fortran compiler for Windows (Digital Visual
> Fortran, DVF. Though I don't know to which extent the actual compiler
> differed from the DEC Unix/VAX Fortran compilers, was it a port or a
> completely different codebase?), which became Compaq Visual Fortran
> (CVF). Then at some point Intel bought the product and the team which
> developed it from Compaq (or maybe it was already HP at the time, I
> don't remember), and it became Intel Fortran.
Thanks.

> 
> So if any current compiler would support the various DEC extensions,
> it would be Intel. And if anything, I suppose Intel behavior defines
> the "canonical" behavior for the DEC extensions.
> 
>  As for the implementation of the patch itself, you might want to
> discuss it with Fritz Reese who has somewhat recently implemented the
> other -fdec-* stuff. 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).
Happy to ping Fritz on this stuff.  I've looked at some of his changes
while cleaning up the Codethink patches.

Also happy to look into sharing those bits rather than reinvention.

Thanks!

jeff

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

[Janne Blomqvist]

On Wed, Mar 21, 2018 at 7:29 PM, Jeff Law  wrote:
> On 03/21/2018 11:25 AM, Jakub Jelinek wrote:
>> On Tue, Mar 20, 2018 at 12:41:25PM -0600, Jeff Law wrote:
>>> This is documented in the old manuals from DEC and I've found
>>> essentially the same documentation in Oracle/Sun's current documentation
>>> as well as old MIPS documentation.   I have a high degree of confidence
>>> it exists in IBM's Fortran compilers as well.  In contrast Intel & PCG's
>>> Fortran compilers do not seem to support this extension.
>>
>> My testing disagrees with the last one, at least ifort 17.0.4 handles
>> the default widths like this patch does with -fdec.
> I was going from what I could find in the online documentation.  I could
> have missed it, or it could be undocumented behavior.

FWIW, IIRC the lineage of the Intel Fortran compiler frontend is that
at some point DEC did a Fortran compiler for Windows (Digital Visual
Fortran, DVF. Though I don't know to which extent the actual compiler
differed from the DEC Unix/VAX Fortran compilers, was it a port or a
completely different codebase?), which became Compaq Visual Fortran
(CVF). Then at some point Intel bought the product and the team which
developed it from Compaq (or maybe it was already HP at the time, I
don't remember), and it became Intel Fortran.

So if any current compiler would support the various DEC extensions,
it would be Intel. And if anything, I suppose Intel behavior defines
the "canonical" behavior for the DEC extensions.

 As for the implementation of the patch itself, you might want to
discuss it with Fritz Reese who has somewhat recently implemented the
other -fdec-* stuff. 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).



-- 
Janne Blomqvist

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

[Jeff Law]

On 03/21/2018 11:25 AM, Jakub Jelinek wrote:
> On Tue, Mar 20, 2018 at 12:41:25PM -0600, Jeff Law wrote:
>> This is documented in the old manuals from DEC and I've found
>> essentially the same documentation in Oracle/Sun's current documentation
>> as well as old MIPS documentation.   I have a high degree of confidence
>> it exists in IBM's Fortran compilers as well.  In contrast Intel & PCG's
>> Fortran compilers do not seem to support this extension.
> 
> My testing disagrees with the last one, at least ifort 17.0.4 handles
> the default widths like this patch does with -fdec.
I was going from what I could find in the online documentation.  I could
have missed it, or it could be undocumented behavior.  Similarly for
Portland Group's compiler -- I'm going on documented behavior that I
could find online.

I don't think it materially changes things though.
jeff

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

[Jakub Jelinek]

On Tue, Mar 20, 2018 at 12:41:25PM -0600, Jeff Law wrote:
> This is documented in the old manuals from DEC and I've found
> essentially the same documentation in Oracle/Sun's current documentation
> as well as old MIPS documentation.   I have a high degree of confidence
> it exists in IBM's Fortran compilers as well.  In contrast Intel & PCG's
> Fortran compilers do not seem to support this extension.

My testing disagrees with the last one, at least ifort 17.0.4 handles
the default widths like this patch does with -fdec.

Jakub

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

[Jeff Law]

Codethink has several more changes that improve gfortran's ability to
handle legacy codebases, particularly those which rely on DEC
extensions.  Most are strictly compiler side issues.  However, one
touches on the runtime.

Specifically, as an extension, DEC Fortran allows omitting the width in
format statement field descriptors.  The runtime then selects a default
width based on the data type.

This is documented in the old manuals from DEC and I've found
essentially the same documentation in Oracle/Sun's current documentation
as well as old MIPS documentation.   I have a high degree of confidence
it exists in IBM's Fortran compilers as well.  In contrast Intel & PCG's
Fortran compilers do not seem to support this extension.

Oracle's docs can be found here (Defaults for w, d, and e):

https://docs.oracle.com/cd/E19957-01/805-4939/z40007437a2e/index.html

Another example:

http://wwwteor.mi.infn.it/~vicini/decfortman.html#77

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.

Jakub has indicated the former approach is generally preferred and it
matches what was recently done for the default exponent handling.  So
that's what this patch does under the control of -fdec-format-defaults

I am _not_ proposing this patch for inclusion into gcc-8.  I'll propose
it for gcc-9.  However, I would like to get the bit within the DT_PARM
bitmask reserved at this time for this purpose.  I'd like to use bit
#28.  That leaves two free bits remaining.  I'm not aware of any pending
need to allocate either of those two free bits.

If we can agree to allocate bit #28 for this purpose I'll propose a
gcc-8 patch which notes the bit's reservation as a comment.


Thoughts?



Jeff
* gfortran.h (struct gfc_dt): Add DEFAULT_WIDTH field.
* io.c (check_format): For -fdec-format-defaults, allow
empty width field descriptor.
(match_io): Set dt->default_width as necessary.
* ioparm.h (IOPARM_dt_default_width): Define.
* lang.opt: Add -fdec-format-defaults.
* trans-io.c (build_dt): Set IOPARM_dt_default_width as
necessary.

* gfortran.dg/fmt_f_default_field_width.f90: New test.
* gfortran.dg/fmt_g_default_field_width.f90: New test.
* gfortran.dg/fmt_i_default_field_width.f90: New test.


* io/format.c (parse_format_list): Conditionally handle
defaulted widths.
* io/io.h (IOPARM_DT_DEFAULT_WIDTH): Define.
(default_width_for_integer): New function.
(default_width_for_float): New function.
(default_precision_for_float): New function.
* io/read.c (read_decimal): Handle case where width is
the defaulted.
* io/write.c (write_boz): Accept new LEN paramter.  Use it
to determine the default width as needed.
(write_b, write_o, write_z): Pass LEN argument to write_boz.
(write_decimal): Use LEN to determine default width as needed.
(size_from_kind): Handle defaulted widths as well.
* write_float.def (build_float_string): Accept new DEFAULT_WIDTH
parameter.  Use it as needed.
(FORMAT_FLOAT): Pass new argument to build_float_string.
Handle defaulted widths as needed.
(get_float_string): Similarly.


diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 2b9eb23..922558a 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2440,6 +2440,7 @@ typedef struct
   *id, *pos, *asynchronous, *blank, *decimal, *delim, *pad, *round,
   *sign, *extra_comma, *dt_io_kind, *udtio;
   char default_exp;
+  char default_width;
 
   gfc_symbol *namelist;
   /* A format_label of `format_asterisk' indicates the "*" format */
diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index ce4eef3..68da85d 100644
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -912,6 +912,13 @@ data_desc:
 
   if (u != FMT_POSINT)
{
+ if (flag_dec_format_defaults)
+   {
+ /* Assume a default width based on the variable size.  */
+ saved_token = u;
+ break;
+   }
+
  format_locus.nextc += format_string_pos;
  gfc_error ("Positive width required in format "
 "specifier %s at %L", token_to_string (t),
@@ -1036,6 +1043,13 @@ data_desc:
goto fail;
   if (t != FMT_ZERO && t != FMT_POSINT)
{
+ if (flag_dec_format_defaults)
+   {
+ /* Assume the default width is expected here and continue lexing. 
 */
+ value = 0; /* It doesn't matter what we set the value to here.  */
+ saved_token = t;
+