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

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

[Jeff Law]

[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]



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

[-- Attachment #2: P --]
[-- Type: text/plain, Size: 19196 bytes --]

	* 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;
+	      break;
+	    }
 	  error = nonneg_required;
 	  goto syntax;
 	}
@@ -1105,8 +1119,17 @@ data_desc:
 	goto fail;
       if (t != FMT_ZERO && t != FMT_POSINT)
 	{
-	  error = nonneg_required;
-	  goto syntax;
+	  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;
+	    }
+	  else
+	    {
+	      error = nonneg_required;
+	      goto syntax;
+	    }
 	}
       else if (is_input && t == FMT_ZERO)
 	{
@@ -4263,6 +4286,11 @@ get_io_list:
   if (flag_dec)
     dt->default_exp = 1;
 
+  /* If DEC compatibility is enabled, then enable default widths for format
+     specifiers in the runtime.  */
+  if (flag_dec || flag_dec_format_defaults)
+    dt->default_width = 1;
+
   /* A full IO statement has been matched.  Check the constraints.  spec_end is
      supplied for cases where no locus is supplied.  */
   m = check_io_constraints (k, dt, io_code, &spec_end);
diff --git a/gcc/fortran/ioparm.def b/gcc/fortran/ioparm.def
index b9dc58f..7d77d19 100644
--- a/gcc/fortran/ioparm.def
+++ b/gcc/fortran/ioparm.def
@@ -119,4 +119,5 @@ IOPARM (dt,      sign,		1 << 24, char1)
 #define IOPARM_dt_f2003		      (1 << 25)
 #define IOPARM_dt_dtio		      (1 << 26)
 #define IOPARM_dt_default_exp	      (1 << 27)
+#define IOPARM_dt_default_width       (1 << 28)
 IOPARM (dt,      u,		0,	 pad)
diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt
index 52ac20c..605fd87 100644
--- a/gcc/fortran/lang.opt
+++ b/gcc/fortran/lang.opt
@@ -444,6 +444,11 @@ fdec-pad-with-spaces
 Fortran Var(flag_dec_pad_with_spaces)
 For character to integer conversions, use spaces for the pad rather than NUL.
 
+fdec-format-defaults
+Fortran Var(flag_dec_format_defaults)
+Allow omitting the width specifier in a FORMAT statement.  A default width will
+be selected by the runtime based on the type of the argument.
+
 fdec-intrinsic-ints
 Fortran Var(flag_dec_intrinsic_ints)
 Enable kind-specific variants of integer intrinsic functions.
diff --git a/gcc/fortran/trans-io.c b/gcc/fortran/trans-io.c
index 9058712..967de0d 100644
--- a/gcc/fortran/trans-io.c
+++ b/gcc/fortran/trans-io.c
@@ -1961,6 +1961,9 @@ build_dt (tree function, gfc_code * code)
       if (dt->default_exp)
 	mask |= IOPARM_dt_default_exp;
 
+      if (dt->default_width)
+	mask |= IOPARM_dt_default_width;
+
       if (dt->namelist)
 	{
 	  if (dt->format_expr || dt->format_label)
diff --git a/gcc/testsuite/gfortran.dg/fmt_f_default_field_width.f90 b/gcc/testsuite/gfortran.dg/fmt_f_default_field_width.f90
new file mode 100644
index 0000000..d233cea
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/fmt_f_default_field_width.f90
@@ -0,0 +1,43 @@
+! { dg-do run }
+! { dg-options -fdec-format-defaults }
+!
+! Test case for the default field widths enabled by the -fdec-format-defaults flag.
+!
+! This feature is not part of any Fortran standard, but it is supported by the
+! Oracle Fortran compiler and others.
+!
+! libgfortran uses printf() internally to implement FORMAT. If you print float
+! values to a higher precision than the type can actually store, the results
+! are implementation dependent: some platforms print zeros, others print random
+! numbers. Don't depend on this behaviour in tests because they will not be
+! portable.
+
+    character(50) :: buffer
+
+    real*4 :: real_4
+    real*8 :: real_8
+    real*16 :: real_16
+    integer :: len
+
+    real_4 = 4.18
+    write(buffer, '(A, F, A)') ':',real_4,':'
+    print *,buffer
+    if (buffer.ne.":      4.1799998:") call abort
+
+    real_4 = 0.00000018
+    write(buffer, '(A, F, A)') ':',real_4,':'
+    print *,buffer
+    if (buffer.ne.":      0.0000002:") call abort
+
+    real_8 = 4.18
+    write(buffer, '(A, F, A)') ':',real_8,':'
+    print *,buffer
+    len = len_trim(buffer)
+    if (len /= 27) call abort
+
+    real_16 = 4.18
+    write(buffer, '(A, F, A)') ':',real_16,':'
+    print *,buffer
+    len = len_trim(buffer)
+    if (len /= 44) call abort
+end
diff --git a/gcc/testsuite/gfortran.dg/fmt_g_default_field_width.f90 b/gcc/testsuite/gfortran.dg/fmt_g_default_field_width.f90
new file mode 100644
index 0000000..65784f5
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/fmt_g_default_field_width.f90
@@ -0,0 +1,48 @@
+! { dg-do run }
+! { dg-options -fdec-format-defaults }
+!
+! Test case for the default field widths enabled by the -fdec-format-defaults flag.
+!
+! This feature is not part of any Fortran standard, but it is supported by the
+! Oracle Fortran compiler and others.
+!
+! libgfortran uses printf() internally to implement FORMAT. If you print float
+! values to a higher precision than the type can actually store, the results
+! are implementation dependent: some platforms print zeros, others print random
+! numbers. Don't depend on this behaviour in tests because they will not be
+! portable.
+
+    character(50) :: buffer
+
+    real*4 :: real_4
+    real*8 :: real_8
+    real*16 :: real_16
+    integer :: len
+
+    real_4 = 4.18
+    write(buffer, '(A, G, A)') ':',real_4,':'
+    print *,buffer
+    if (buffer.ne.":   4.180000    :") call abort
+
+    real_4 = 0.00000018
+    write(buffer, '(A, G, A)') ':',real_4,':'
+    print *,buffer
+    if (buffer.ne.":  0.1800000E-06:") call abort
+
+    real_4 = 18000000.4
+    write(buffer, '(A, G, A)') ':',real_4,':'
+    print *,buffer
+    if (buffer.ne.":  0.1800000E+08:") call abort
+
+    real_8 = 4.18
+    write(buffer, '(A, G, A)') ':',real_8,':'
+    print *,buffer
+    len = len_trim(buffer)
+    if (len /= 27) call abort
+
+    real_16 = 4.18
+    write(buffer, '(A, G, A)') ':',real_16,':'
+    print *,buffer
+    len = len_trim(buffer)
+    if (len /= 44) call abort
+end
diff --git a/gcc/testsuite/gfortran.dg/fmt_i_default_field_width.f90 b/gcc/testsuite/gfortran.dg/fmt_i_default_field_width.f90
new file mode 100644
index 0000000..2a5c633
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/fmt_i_default_field_width.f90
@@ -0,0 +1,38 @@
+! { dg-do run }
+! { dg-options -fdec-format-defaults }
+!
+! Test case for the default field widths enabled by the -fdec-format-defaults flag.
+!
+! This feature is not part of any Fortran standard, but it is supported by the
+! Oracle Fortran compiler and others.
+
+    character(50) :: buffer
+    character(1) :: colon
+
+    integer*2 :: integer_2
+    integer*4 :: integer_4
+    integer*8 :: integer_8
+
+    write(buffer, '(A, I, A)') ':',12340,':'
+    print *,buffer
+    if (buffer.ne.":       12340:") call abort
+
+    read(buffer, '(A1, I, A1)') colon, integer_4, colon
+    if (integer_4.ne.12340) call abort
+
+    integer_2 = -99
+    write(buffer, '(A, I, A)') ':',integer_2,':'
+    print *,buffer
+    if (buffer.ne.":    -99:") call abort
+
+    integer_8 = -11112222
+    write(buffer, '(A, I, A)') ':',integer_8,':'
+    print *,buffer
+    if (buffer.ne.":              -11112222:") call abort
+
+! If the width is 7 and there are 7 leading zeroes, the result should be zero.
+    integer_2 = 789
+    buffer = '0000000789'
+    read(buffer, '(I)') integer_2
+    if (integer_2.ne.0) call abort
+end
diff --git a/libgfortran/io/format.c b/libgfortran/io/format.c
index b4920aa..9bf690d 100644
--- a/libgfortran/io/format.c
+++ b/libgfortran/io/format.c
@@ -956,12 +956,33 @@ parse_format_list (st_parameter_dt *dtp, bool *seen_dd)
 	  *seen_dd = true;
 	  if (u != FMT_POSINT && u != FMT_ZERO)
 	    {
+	      if (dtp->common.flags & IOPARM_DT_DEFAULT_WIDTH)
+		{
+		  tail->u.real.w = DEFAULT_WIDTH;
+		  tail->u.real.d = 0;
+		  tail->u.real.e = -1;
+		  fmt->saved_token = u;
+		  break;
+		}
 	      fmt->error = nonneg_required;
 	      goto finished;
 	    }
 	}
+      else if (u == FMT_ZERO)
+	{
+	  fmt->error = posint_required;
+	  goto finished;
+	}
       else if (u != FMT_POSINT)
 	{
+	  if (dtp->common.flags & IOPARM_DT_DEFAULT_WIDTH)
+	    {
+	      tail->u.real.w = DEFAULT_WIDTH;
+	      tail->u.real.d = 0;
+	      tail->u.real.e = -1;
+	      fmt->saved_token = u;
+	      break;
+	    }
 	  fmt->error = posint_required;
 	  goto finished;
 	}
@@ -1100,6 +1121,13 @@ parse_format_list (st_parameter_dt *dtp, bool *seen_dd)
 	{
 	  if (t != FMT_POSINT)
 	    {
+	      if (dtp->common.flags & IOPARM_DT_DEFAULT_WIDTH)
+		{
+		  tail->u.integer.w = DEFAULT_WIDTH;
+		  tail->u.integer.m = -1;
+		  fmt->saved_token = t;
+		  break;
+		}
 	      fmt->error = posint_required;
 	      goto finished;
 	    }
@@ -1108,6 +1136,13 @@ parse_format_list (st_parameter_dt *dtp, bool *seen_dd)
 	{
 	  if (t != FMT_ZERO && t != FMT_POSINT)
 	    {
+	      if (dtp->common.flags & IOPARM_DT_DEFAULT_WIDTH)
+		{
+		  tail->u.integer.w = DEFAULT_WIDTH;
+		  tail->u.integer.m = -1;
+		  fmt->saved_token = t;
+		  break;
+		}
 	      fmt->error = nonneg_required;
 	      goto finished;
 	    }
diff --git a/libgfortran/io/io.h b/libgfortran/io/io.h
index 3c2a2ca..fd0d12f 100644
--- a/libgfortran/io/io.h
+++ b/libgfortran/io/io.h
@@ -443,6 +443,7 @@ st_parameter_inquire;
 #define IOPARM_DT_HAS_F2003                     (1 << 25)
 #define IOPARM_DT_HAS_UDTIO                     (1 << 26)
 #define IOPARM_DT_DEFAULT_EXP			(1 << 27)
+#define IOPARM_DT_DEFAULT_WIDTH			(1 << 28)
 /* Internal use bit.  */
 #define IOPARM_DT_IONML_SET			(1u << 31)
 
@@ -986,5 +987,55 @@ memset4 (gfc_char4_t *p, gfc_char4_t c, int k)
     *p++ = c;
 }
 
+/* Used in width fields to indicate that the default should be used */
+#define DEFAULT_WIDTH -1
+
+/* Defaults for certain format field descriptors. These are decided based on
+ * the type of the value being formatted.
+ *
+ * The behaviour here is modelled on the Oracle Fortran compiler. At the time
+ * of writing, the details were available at this URL:
+ *
+ *   https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vnc3/index.html#z4000743746d
+ */
+
+static inline int
+default_width_for_integer (int kind)
+{
+  switch (kind)
+    {
+    case 1:
+    case 2:  return  7;
+    case 4:  return 12;
+    case 8:  return 23;
+    case 16: return 44;
+    default: return  0;
+    }
+}
+
+static inline int
+default_width_for_float (int kind)
+{
+  switch (kind)
+    {
+    case 4:  return 15;
+    case 8:  return 25;
+    case 16: return 42;
+    default: return  0;
+    }
+}
+
+static inline int
+default_precision_for_float (int kind)
+{
+  switch (kind)
+    {
+    case 4:  return 7;
+    case 8:  return 16;
+    case 16: return 33;
+    default: return 0;
+    }
+}
+
 #endif
 
diff --git a/libgfortran/io/read.c b/libgfortran/io/read.c
index 87adfb8..a9d7733 100644
--- a/libgfortran/io/read.c
+++ b/libgfortran/io/read.c
@@ -633,6 +633,12 @@ read_decimal (st_parameter_dt *dtp, const fnode *f, char *dest, int length)
 
   w = f->u.w;
 
+  /* This is a legacy extension, and the frontend will only allow such cases
+   * through when -fdec-format-defaults is passed.
+   */
+  if (w == DEFAULT_WIDTH)
+    w = default_width_for_integer (length);
+
   p = read_block_form (dtp, &w);
 
   if (p == NULL)
diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 50ea133..a74dd00 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -685,9 +685,8 @@ write_l (st_parameter_dt *dtp, const fnode *f, char *source, int len)
   p[wlen - 1] = (n) ? 'T' : 'F';
 }
 
-
 static void
-write_boz (st_parameter_dt *dtp, const fnode *f, const char *q, int n)
+write_boz (st_parameter_dt *dtp, const fnode *f, const char *q, int n, int len)
 {
   int w, m, digits, nzero, nblank;
   char *p;
@@ -720,6 +719,9 @@ write_boz (st_parameter_dt *dtp, const fnode *f, const char *q, int n)
   /* Select a width if none was specified.  The idea here is to always
      print something.  */
 
+  if (w == DEFAULT_WIDTH)
+    w = default_width_for_integer (len);
+
   if (w == 0)
     w = ((digits < m) ? m : digits);
 
@@ -846,6 +848,8 @@ write_decimal (st_parameter_dt *dtp, const fnode *f, const char *source,
 
   /* Select a width if none was specified.  The idea here is to always
      print something.  */
+  if (w == DEFAULT_WIDTH)
+    w = default_width_for_integer (len);
 
   if (w == 0)
     w = ((digits < m) ? m : digits) + nsign;
@@ -1206,13 +1210,13 @@ write_b (st_parameter_dt *dtp, const fnode *f, const char *source, int len)
   if (len > (int) sizeof (GFC_UINTEGER_LARGEST))
     {
       p = btoa_big (source, itoa_buf, len, &n);
-      write_boz (dtp, f, p, n);
+      write_boz (dtp, f, p, n, len);
     }
   else
     {
       n = extract_uint (source, len);
       p = btoa (n, itoa_buf, sizeof (itoa_buf));
-      write_boz (dtp, f, p, n);
+      write_boz (dtp, f, p, n, len);
     }
 }
 
@@ -1227,13 +1231,13 @@ write_o (st_parameter_dt *dtp, const fnode *f, const char *source, int len)
   if (len > (int) sizeof (GFC_UINTEGER_LARGEST))
     {
       p = otoa_big (source, itoa_buf, len, &n);
-      write_boz (dtp, f, p, n);
+      write_boz (dtp, f, p, n, len);
     }
   else
     {
       n = extract_uint (source, len);
       p = otoa (n, itoa_buf, sizeof (itoa_buf));
-      write_boz (dtp, f, p, n);
+      write_boz (dtp, f, p, n, len);
     }
 }
 
@@ -1247,13 +1251,13 @@ write_z (st_parameter_dt *dtp, const fnode *f, const char *source, int len)
   if (len > (int) sizeof (GFC_UINTEGER_LARGEST))
     {
       p = ztoa_big (source, itoa_buf, len, &n);
-      write_boz (dtp, f, p, n);
+      write_boz (dtp, f, p, n, len);
     }
   else
     {
       n = extract_uint (source, len);
       p = gfc_xtoa (n, itoa_buf, sizeof (itoa_buf));
-      write_boz (dtp, f, p, n);
+      write_boz (dtp, f, p, n, len);
     }
 }
 
@@ -1486,7 +1490,7 @@ size_from_kind (st_parameter_dt *dtp, const fnode *f, int kind)
 {
   int size;
 
-  if (f->format == FMT_F && f->u.real.w == 0)
+  if ((f->format == FMT_F && f->u.real.w == 0) || f->u.real.w == DEFAULT_WIDTH)
     {
       switch (kind)
       {
diff --git a/libgfortran/io/write_float.def b/libgfortran/io/write_float.def
index 177a568..31dd18b 100644
--- a/libgfortran/io/write_float.def
+++ b/libgfortran/io/write_float.def
@@ -113,7 +113,8 @@ determine_precision (st_parameter_dt * dtp, const fnode * f, int len)
 static void
 build_float_string (st_parameter_dt *dtp, const fnode *f, char *buffer,
 		    size_t size, int nprinted, int precision, int sign_bit,
-		    bool zero_flag, int npad, char *result, size_t *len)
+		    bool zero_flag, int npad, int default_width, char *result,
+                    size_t *len)
 {
   char *put;
   char *digits;
@@ -132,8 +133,17 @@ build_float_string (st_parameter_dt *dtp, const fnode *f, char *buffer,
   sign_t sign;
 
   ft = f->format;
-  w = f->u.real.w;
-  d = f->u.real.d;
+  if (f->u.real.w == DEFAULT_WIDTH)
+    /* This codepath can only be reached with -fdec-format-defaults. */
+    {
+      w = default_width;
+      d = precision;
+    }
+  else
+    {
+      w = f->u.real.w;
+      d = f->u.real.d;
+    }
   p = dtp->u.p.scale_factor;
 
   rchar = '5';
@@ -958,6 +968,11 @@ determine_en_precision (st_parameter_dt *dtp, const fnode *f,
       int save_scale_factor;\
       volatile GFC_REAL_ ## x temp;\
       save_scale_factor = dtp->u.p.scale_factor;\
+      if (w == DEFAULT_WIDTH)\
+	{\
+	  w = default_width;\
+	  d = precision;\
+	}\
       switch (dtp->u.p.current_unit->round_status)\
 	{\
 	  case ROUND_ZERO:\
@@ -1033,7 +1048,8 @@ determine_en_precision (st_parameter_dt *dtp, const fnode *f,
 	  nprinted = FDTOA(y,precision,m);\
 	}\
       build_float_string (dtp, &newf, buffer, size, nprinted, precision,\
-				   sign_bit, zero_flag, npad, result, res_len);\
+				   sign_bit, zero_flag, npad, default_width,\
+				   result, res_len);\
       dtp->u.p.scale_factor = save_scale_factor;\
     }\
   else\
@@ -1043,7 +1059,8 @@ determine_en_precision (st_parameter_dt *dtp, const fnode *f,
       else\
 	nprinted = DTOA(y,precision,m);\
       build_float_string (dtp, f, buffer, size, nprinted, precision,\
-				   sign_bit, zero_flag, npad, result, res_len);\
+				   sign_bit, zero_flag, npad, default_width,\
+				   result, res_len);\
     }\
 }\
 
@@ -1057,6 +1074,16 @@ get_float_string (st_parameter_dt *dtp, const fnode *f, const char *source,
 {
   int sign_bit, nprinted;
   bool zero_flag;
+  int default_width = 0;
+
+  if (f->u.real.w == DEFAULT_WIDTH)
+    /* This codepath can only be reached with -fdec-format-defaults. The default
+     * values are based on those used in the Oracle Fortran compiler.
+     */
+    {
+      default_width = default_width_for_float (kind);
+      precision = default_precision_for_float (kind);
+    }
 
   switch (kind)
     {

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

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 <law@redhat.com> 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 12:38 PM, Janne Blomqvist wrote:
> On Wed, Mar 21, 2018 at 7:29 PM, Jeff Law <law@redhat.com> 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

[Jeff Law]

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

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.

There's differences for the other kind/lengths as well.



For integer types, we have write_integer which has

   case 4:
      width = 11;
      break;

But in the tables I referenced we'd get a width of 12.  THere's other
differences in the integer type handling as well.


So I don't offhand see that we can share that code -- unless there's
some formulaic adjustment we could make to the return values.

I didn't find the relevant code for zero width formats.  If we look at
parse_format_list:

   case FMT_I:
    case FMT_B:
    case FMT_O:
    case FMT_Z:
      *seen_dd = true;
      get_fnode (fmt, &head, &tail, t);
      tail->repeat = repeat;

      t = format_lex (fmt);

      if (dtp->u.p.mode == READING)
        {
          if (t != FMT_POSINT)
            {
              fmt->error = posint_required;
              goto finished;
            }
        }
      else
        {
          if (t != FMT_ZERO && t != FMT_POSINT)
            {
              fmt->error = nonneg_required;
              goto finished;
            }
        }


It appears to me that we require a FMT_POSINT when reading.  FMT_ZERO
would result in setting fmt->error to posint_required AFAICT.  If we
were writing, I can see how we don't get an error, but the w field still
gets set to zero via fmt->value.    I don't immediately see where we
set/use a default though.

Maybe it works for other formats.  But my my relatively brief looksie I
don't see how we can really piggyback on the FMT_ZERO support.

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.

Jeff

ps.  The bulk of the code was from Jim MacArthur @ Codethink  I just
reworked it to use a bit in DT_PARM in a manner similar to what Fritz
Reese had done for defaulted exponents.

Re: 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

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

[Jakub Jelinek]

On Fri, Mar 23, 2018 at 09:12:21AM +0100, Jakub Jelinek wrote:
> > 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.

BTW, it seems libgfortran already has a similar extension, at least my
reading of the standards (checked 97 and 2003) is that for Lw the standard
doesn't allow omitting the width, but we allow that as extension:
          else
            {
              fmt->saved_token = t;
              notify_std (&dtp->common, GFC_STD_GNU,
                          "Positive width required with L descriptor");
            }
          fmt->value = 1;       /* Default width */
(and sadly different from what Intel Fortran does, because it uses 2).
Wonder about other compilers, if they all agree on 2, perhaps we should
behave above differently based on the new bit?

	Jakub

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

[Janne Blomqvist]

On Fri, Mar 23, 2018 at 4:07 AM, Jerry DeLisle <jvdelisle@charter.net>
wrote:

>
>
> Reserving the bit is OK with me, doing so does no harm and it does not
> break the ABI.


Come to think of it, as we're now quite close to the end of that flag
variable, should we add a flags2 variable to dt_parm just in case to avoid
breaking the ABI when we need more bits?

-- 
Janne Blomqvist

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

[Jakub Jelinek]

On Fri, Mar 23, 2018 at 11:01:49AM +0200, Janne Blomqvist wrote:
> On Fri, Mar 23, 2018 at 4:07 AM, Jerry DeLisle <jvdelisle@charter.net>
> > Reserving the bit is OK with me, doing so does no harm and it does not
> > break the ABI.
> 
> 
> Come to think of it, as we're now quite close to the end of that flag
> variable, should we add a flags2 variable to dt_parm just in case to avoid
> breaking the ABI when we need more bits?

Another possibility is to use the last bit as an extension indicating there
is another flags2 field (of course, it would have to be added at the end of
the structure).  The runtime can test flags & (1U << 31) and based on that
decide if it can read flags2 or if flags2 is to be assumed all zeros.

	Jakub

Re: 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

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

[Jakub Jelinek]

On Fri, Mar 23, 2018 at 09:12:21AM +0100, Jakub Jelinek wrote:
> 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.

Oracle:
https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vnc3/index.html#z4000743746d

	Jakub

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

[Lukasz Kolodziejczyk]

On 23/03/18 08:12, Jakub Jelinek wrote:
> 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.

In addition to the Intel and Oracle compiler documentation linked by Jakub, the 
Compaq Visual Fortran documentation is in support of 15, 7, 2:
http://jp.xlsoft.com/documents/intel/cvf/cvf_lref.pdf ("Default Widths for Data 
Edit Descriptors", page 305)

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

While we agree that modernising Fortran is the appropriate long-term goal, in 
the short term it might not be feasible for users of gfortran. Therefore we 
believe that implementing the change in this way is the most accessible approach 
for those that require this feature in the immediate future.

We have tested Jeff's patch on trunk and can confirm it works as expected with 
no regressions.


Lukasz

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

[Jerry DeLisle]

On 03/23/2018 02:01 AM, Janne Blomqvist wrote:
> On Fri, Mar 23, 2018 at 4:07 AM, Jerry DeLisle <jvdelisle@charter.net>
> wrote:
> 
>>
>>
>> Reserving the bit is OK with me, doing so does no harm and it does not
>> break the ABI.
> 
> 
> Come to think of it, as we're now quite close to the end of that flag
> variable, should we add a flags2 variable to dt_parm just in case to avoid
> breaking the ABI when we need more bits?
> 

Very good point. We already had to do this for inquire:

#define IOPARM_INQUIRE_HAS_FLAGS2	(1u << 31)

So if we do the extension bit, please also add the flags 2 at the end 
similarly and add the next set of bits.

IIRC it needs to be in st_parameter_common.

Jerry

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

[Jerry DeLisle]

On 03/23/2018 01:38 AM, Jakub Jelinek wrote:
> On Fri, Mar 23, 2018 at 09:12:21AM +0100, Jakub Jelinek wrote:
>>> 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.
> 
> BTW, it seems libgfortran already has a similar extension, at least my
> reading of the standards (checked 97 and 2003) is that for Lw the standard
> doesn't allow omitting the width, but we allow that as extension:
>            else
>              {
>                fmt->saved_token = t;
>                notify_std (&dtp->common, GFC_STD_GNU,
>                            "Positive width required with L descriptor");
>              }
>            fmt->value = 1;       /* Default width */
> (and sadly different from what Intel Fortran does, because it uses 2).
> Wonder about other compilers, if they all agree on 2, perhaps we should
> behave above differently based on the new bit?
> 
> 	Jakub
> 

Putting on my "practical" hat, if an application writes large volumes of 
data to a formatted file as a means of intermediate storage and then 
reads it back in for further processing and uses tab specifiers to 
position the read to get at a certain field, they would be screwed with 
gfortran.

I agree that with so many other compilers doing this, we should do so.

The warning we issue should state that there is a loss of precision in 
formatted file I/O.

Also I wonder if we should test the bit in set_fnode_default and do the 
changes there so they are all in one place and all the other default 
formatting should just work. For example, write(6, *) would use the 
smaller widths if the flag is set.

Also, could someone point me to a a real good example of this kind of 
DEC Fortran code so I can get a better feel for this.

Regards,

Jerry

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

[Jerry DeLisle]

On 03/23/2018 06:26 AM, Lukasz Kolodziejczyk wrote:
> On 23/03/18 08:12, Jakub Jelinek wrote:
>> 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.
> 
> In addition to the Intel and Oracle compiler documentation linked by 
> Jakub, the Compaq Visual Fortran documentation is in support of 15, 7, 2:
> http://jp.xlsoft.com/documents/intel/cvf/cvf_lref.pdf ("Default Widths 
> for Data Edit Descriptors", page 305)
> 
>>> 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.
> 
> While we agree that modernising Fortran is the appropriate long-term 
> goal, in the short term it might not be feasible for users of gfortran. 
> Therefore we believe that implementing the change in this way is the 
> most accessible approach for those that require this feature in the 
> immediate future.
> 
> We have tested Jeff's patch on trunk and can confirm it works as 
> expected with no regressions.
> 
> 
> Lukasz
> 
> 
OK, this makes sense to me. From where I sit, I have a limited view of 
these use cases.

Jerry

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

[Jeff Law]

On 03/23/2018 02:38 AM, Jakub Jelinek wrote:
> On Fri, Mar 23, 2018 at 09:12:21AM +0100, Jakub Jelinek wrote:
>>> 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.
> 
> BTW, it seems libgfortran already has a similar extension, at least my
> reading of the standards (checked 97 and 2003) is that for Lw the standard
> doesn't allow omitting the width, but we allow that as extension:
>           else
>             {
>               fmt->saved_token = t;
>               notify_std (&dtp->common, GFC_STD_GNU,
>                           "Positive width required with L descriptor");
>             }
>           fmt->value = 1;       /* Default width */
> (and sadly different from what Intel Fortran does, because it uses 2).
> Wonder about other compilers, if they all agree on 2, perhaps we should
> behave above differently based on the new bit?
Yup.  I saw that too in my wanderings.  I was hoping it was actually
more general and that we could piggy-back a bit.  But that wasn't the
case AFAICT.

jeff

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

[Jeff Law]

On 03/23/2018 07:26 AM, Lukasz Kolodziejczyk wrote:
> On 23/03/18 08:12, Jakub Jelinek wrote:
>> 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.
> 
> In addition to the Intel and Oracle compiler documentation linked by
> Jakub, the Compaq Visual Fortran documentation is in support of 15, 7, 2:
> http://jp.xlsoft.com/documents/intel/cvf/cvf_lref.pdf ("Default Widths
> for Data Edit Descriptors", page 305)
> 
>>> 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.
> 
> While we agree that modernising Fortran is the appropriate long-term
> goal, in the short term it might not be feasible for users of gfortran.
> Therefore we believe that implementing the change in this way is the
> most accessible approach for those that require this feature in the
> immediate future.
Agreed 100%.   Trying to move these old codebases into the modern world
is tough and requires decisions to be made about what to modernize
immediately vs what to defer (and thus rely on compatibility modes in
the compiler/runtime).

My understanding is there are things that are going to be fixed via
automated tools.  There are other things where we may rely on compiler
diagnostics to catch and for humans to fix and others where
modernization may be deferred  and we rely on compatibility modes in the
compiler/runtime.  The decision about which bucket any particular issue
falls into involves a nontrivial calculus.

Based on my understanding of known issues today it is believed the best
path forward includes deferring handling of default widths in format
statements by relying on compatibility modes.  Other issues are
obviously going into other buckets.

FWIW, I have proposed that the compiler issue diagnostics when it is
able to discover at compile time that a default with is going to be
used.  And I ultimately hope that proposal moves forward as I believe it
will help with the overall modernization effort.

Jeff

Re: 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

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

[Jeff Law]

On 03/23/2018 02:12 AM, Jakub Jelinek wrote:
> 
> 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?). 
And I've suggested this as a way to start the process of modernizing the
format statement handling :-)

Jeff

Re: 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

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

[Steve Kargl]

On Fri, Mar 23, 2018 at 01:39:37PM -0600, Jeff Law wrote:
> On 03/23/2018 07:26 AM, Lukasz Kolodziejczyk wrote:
> > 
> > While we agree that modernising Fortran is the appropriate long-term
> > goal, in the short term it might not be feasible for users of gfortran.
> > Therefore we believe that implementing the change in this way is the
> > most accessible approach for those that require this feature in the
> > immediate future.
> Agreed 100%.   Trying to move these old codebases into the modern world
> is tough and requires decisions to be made about what to modernize
> immediately vs what to defer (and thus rely on compatibility modes in
> the compiler/runtime).

By providing compatibility modes in the compiler/runtime,
there is *no* incentive to fix the non-standard code. 
"Why fix something that's not broken."

The problem is that these non-standard features now fall
on a tiny group of volunteer gfortran contributors to 
maintain.  

Hopefully, the diagnostics messages are sufficiently annoying
that users will be motivated to fix their code.  Perhaps,
even make it impossible to disable the message via -w.

-- 
Steve

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

[Jakub Jelinek]

On Fri, Mar 23, 2018 at 05:32:45PM -0400, Fritz Reese wrote:
> 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.

The default is
warn_std = GFC_STD_LEGACY | GFC_STD_F95_DEL;
allow_std = GFC_STD_*; // all
pedantic = 0;

So if we use e.g. notify_std (..., GFC_STD_LEGACY, ...) for this,
it would not warn at all by default, and would ever warn only if using
-pedantic.  Is that what we want for this extension?

Or shall we just check (warn_std & GFC_STD_LEGACY) != 0, if true,
set fmt->error if width etc. is missing, otherwise use the -1 and later
resolve it to the default?

Any way to deal with the FMT_L missing width inconsistency (libgfortran
under notify_std (..., GFC_STD_GNU, ...) using default length of 1 while
the other compilers all using 2?

	Jakub

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

[Steve Kargl]

On Sat, Mar 24, 2018 at 09:18:52AM +0100, Jakub Jelinek wrote:
> On Fri, Mar 23, 2018 at 05:32:45PM -0400, Fritz Reese wrote:
> > 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.
> 
> The default is
> warn_std = GFC_STD_LEGACY | GFC_STD_F95_DEL;
> allow_std = GFC_STD_*; // all
> pedantic = 0;
> 
> So if we use e.g. notify_std (..., GFC_STD_LEGACY, ...) for this,
> it would not warn at all by default, and would ever warn only if using
> -pedantic.  Is that what we want for this extension?
> 
> Or shall we just check (warn_std & GFC_STD_LEGACY) != 0, if true,
> set fmt->error if width etc. is missing, otherwise use the -1 and later
> resolve it to the default?

No.  DEC extensions should be activated by the use of one of the
-fdec-* options.  For this extension, I think it can be grouped
under the general purpose -fdec option.  In the Fortran FE, -fdec
then becomes "if (flag_dec)".  I don't recall if Fritz set up
passing flag_dec into libgfortran.

> Any way to deal with the FMT_L missing width inconsistency (libgfortran
> under notify_std (..., GFC_STD_GNU, ...) using default length of 1 while
> the other compilers all using 2?

	  fmt->value = flag_dec ? 2 : 1;	/* Default width */ 

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

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

[Steve Kargl]

On Sat, Mar 24, 2018 at 05:20:06PM +0100, Jakub Jelinek wrote:
> On Sat, Mar 24, 2018 at 09:04:04AM -0700, Steve Kargl wrote:
> > > Or shall we just check (warn_std & GFC_STD_LEGACY) != 0, if true,
> > > set fmt->error if width etc. is missing, otherwise use the -1 and later
> > > resolve it to the default?
> > 
> > No.  DEC extensions should be activated by the use of one of the
> > -fdec-* options.  For this extension, I think it can be grouped
> > under the general purpose -fdec option.  In the Fortran FE, -fdec
> > then becomes "if (flag_dec)".  I don't recall if Fritz set up
> > passing flag_dec into libgfortran.
> 
> I don't see it passed directly.
> With -fdec compile_options.warn_std is 0, rather than the default
> GFC_STD_LEGACY | GFC_STD_F95_DEL, but _gfortran_set_options
> argument is exactly the same for -fdec and for -std=legacy, so there is no
> way to differentiate the two.
> 
> So, the only way to handle this DEC extension without adding new bits
> (to either compile_options (i.e. GFC_STD_*), or the io flags as shown by the
> patch Jeff posted) would be to abuse the IOPARM_dt_default_exp bit for it,
> i.e. tie together the extension omitting exponent and the default width.
> Seems the IOPARM_dt_default_exp is set whenever -fdec and not otherwise:
> 

Well, if we add 

#define GFC_STD_DEC_EXT		(1<<13)

to fortran/libgfortran.h, we still have 18 bits left. 

Then change options.c(set_dec_flags) to include this in the
list of "standards" passed to libgfortran.  The tests would
then look like

   fmt->value = (gfc_option.allow_std & GFC_STD_DEC_EXT) ? 2 : 1;

I don't know if this is any better than using Jeff's idea of reserving
bit #28 in flag (and adding a flag2).  Other than 18 bits at 5 to 8
years per revision to the standards, means we'll be long retired 
before someone has to deal with running out of bits.

-- 
Steve
20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
20161221 https://www.youtube.com/watch?v=IbCHE-hONow

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

[Jakub Jelinek]

On Sat, Mar 24, 2018 at 09:04:04AM -0700, Steve Kargl wrote:
> > Or shall we just check (warn_std & GFC_STD_LEGACY) != 0, if true,
> > set fmt->error if width etc. is missing, otherwise use the -1 and later
> > resolve it to the default?
> 
> No.  DEC extensions should be activated by the use of one of the
> -fdec-* options.  For this extension, I think it can be grouped
> under the general purpose -fdec option.  In the Fortran FE, -fdec
> then becomes "if (flag_dec)".  I don't recall if Fritz set up
> passing flag_dec into libgfortran.

I don't see it passed directly.
With -fdec compile_options.warn_std is 0, rather than the default
GFC_STD_LEGACY | GFC_STD_F95_DEL, but _gfortran_set_options
argument is exactly the same for -fdec and for -std=legacy, so there is no
way to differentiate the two.

So, the only way to handle this DEC extension without adding new bits
(to either compile_options (i.e. GFC_STD_*), or the io flags as shown by the
patch Jeff posted) would be to abuse the IOPARM_dt_default_exp bit for it,
i.e. tie together the extension omitting exponent and the default width.
Seems the IOPARM_dt_default_exp is set whenever -fdec and not otherwise:

  /* See if we want to use defaults for missing exponents in real transfers.  */
  if (flag_dec)
    dt->default_exp = 1;
...
      if (dt->default_exp)
        mask |= IOPARM_dt_default_exp;
are the only spots that refer to default_exp in the FE.

If it is acceptable that users can't choose I want default widths but not
default exponent, or I want default exponent but not default width, then
yes, we can just check
dtp->common.flags & IOPARM_DT_DEFAULT_EXP
for whether default widths are allowed or not, rather than
dtp->common.flags & IOPARM_DT_DEFAULT_WIDTH
or
compile_options.allow_std & GFC_STD_DEC

> > Any way to deal with the FMT_L missing width inconsistency (libgfortran
> > under notify_std (..., GFC_STD_GNU, ...) using default length of 1 while
> > the other compilers all using 2?
> 
> 	  fmt->value = flag_dec ? 2 : 1;	/* Default width */ 

flag_dec would need to be one of the above.

	Jakub

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

[Jerry DeLisle]

On 03/24/2018 10:11 AM, Steve Kargl wrote:
> On Sat, Mar 24, 2018 at 05:20:06PM +0100, Jakub Jelinek wrote:
>> On Sat, Mar 24, 2018 at 09:04:04AM -0700, Steve Kargl wrote:
>>>> Or shall we just check (warn_std & GFC_STD_LEGACY) != 0, if true,
>>>> set fmt->error if width etc. is missing, otherwise use the -1 and later
>>>> resolve it to the default?
>>>
>>> No.  DEC extensions should be activated by the use of one of the
>>> -fdec-* options.  For this extension, I think it can be grouped
>>> under the general purpose -fdec option.  In the Fortran FE, -fdec
>>> then becomes "if (flag_dec)".  I don't recall if Fritz set up
>>> passing flag_dec into libgfortran.
>>
>> I don't see it passed directly.
>> With -fdec compile_options.warn_std is 0, rather than the default
>> GFC_STD_LEGACY | GFC_STD_F95_DEL, but _gfortran_set_options
>> argument is exactly the same for -fdec and for -std=legacy, so there is no
>> way to differentiate the two.
>>
>> So, the only way to handle this DEC extension without adding new bits
>> (to either compile_options (i.e. GFC_STD_*), or the io flags as shown by the
>> patch Jeff posted) would be to abuse the IOPARM_dt_default_exp bit for it,
>> i.e. tie together the extension omitting exponent and the default width.
>> Seems the IOPARM_dt_default_exp is set whenever -fdec and not otherwise:
>>
> 
> Well, if we add
> 
> #define GFC_STD_DEC_EXT		(1<<13)
> 
> to fortran/libgfortran.h, we still have 18 bits left.
> 
> Then change options.c(set_dec_flags) to include this in the
> list of "standards" passed to libgfortran.  The tests would
> then look like
> 
>     fmt->value = (gfc_option.allow_std & GFC_STD_DEC_EXT) ? 2 : 1;
> 
> I don't know if this is any better than using Jeff's idea of reserving
> bit #28 in flag (and adding a flag2).  Other than 18 bits at 5 to 8
> years per revision to the standards, means we'll be long retired
> before someone has to deal with running out of bits.
> 

I like this approach because we can then use it for anything else that 
crops up down the road for the runtime.

Jerry

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

[Jeff Law]

On 03/24/2018 12:20 PM, Jerry DeLisle wrote:
> On 03/24/2018 10:11 AM, Steve Kargl wrote:
>> On Sat, Mar 24, 2018 at 05:20:06PM +0100, Jakub Jelinek wrote:
>>> On Sat, Mar 24, 2018 at 09:04:04AM -0700, Steve Kargl wrote:
>>>>> Or shall we just check (warn_std & GFC_STD_LEGACY) != 0, if true,
>>>>> set fmt->error if width etc. is missing, otherwise use the -1 and
>>>>> later
>>>>> resolve it to the default?
>>>>
>>>> No.  DEC extensions should be activated by the use of one of the
>>>> -fdec-* options.  For this extension, I think it can be grouped
>>>> under the general purpose -fdec option.  In the Fortran FE, -fdec
>>>> then becomes "if (flag_dec)".  I don't recall if Fritz set up
>>>> passing flag_dec into libgfortran.
>>>
>>> I don't see it passed directly.
>>> With -fdec compile_options.warn_std is 0, rather than the default
>>> GFC_STD_LEGACY | GFC_STD_F95_DEL, but _gfortran_set_options
>>> argument is exactly the same for -fdec and for -std=legacy, so there
>>> is no
>>> way to differentiate the two.
>>>
>>> So, the only way to handle this DEC extension without adding new bits
>>> (to either compile_options (i.e. GFC_STD_*), or the io flags as shown
>>> by the
>>> patch Jeff posted) would be to abuse the IOPARM_dt_default_exp bit
>>> for it,
>>> i.e. tie together the extension omitting exponent and the default width.
>>> Seems the IOPARM_dt_default_exp is set whenever -fdec and not otherwise:
>>>
>>
>> Well, if we add
>>
>> #define GFC_STD_DEC_EXT        (1<<13)
>>
>> to fortran/libgfortran.h, we still have 18 bits left.
>>
>> Then change options.c(set_dec_flags) to include this in the
>> list of "standards" passed to libgfortran.  The tests would
>> then look like
>>
>>     fmt->value = (gfc_option.allow_std & GFC_STD_DEC_EXT) ? 2 : 1;
>>
>> I don't know if this is any better than using Jeff's idea of reserving
>> bit #28 in flag (and adding a flag2).  Other than 18 bits at 5 to 8
>> years per revision to the standards, means we'll be long retired
>> before someone has to deal with running out of bits.
>>
> 
> I like this approach because we can then use it for anything else that
> crops up down the road for the runtime.
In this scenario we communicate between the compiler and runtime via the
ALLOW_STD field.  The technical difference is the change applies
globally rather than on per-call basis (DT_PARMs IIUC is computed and
passed to the runtime for each format call).  I think that's likely to
be OK.

The downside of this approach is it puts these extensions under the -std
namespace rather than in -fdec.  I think Steve K. has expressed a desire
to keep this stuff under -fdec.  I'm not sure how to reconcile the
difference of opinions here.

I'm happy to go with either approach (or even generalizing the default
exponent code).  What's important to me is that we reach agreement on
the mechanism we're using for communication between the compiler and
runtime.

Jeff

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

[Jerry DeLisle]

On 03/25/2018 11:48 AM, Jeff Law wrote:
> On 03/24/2018 12:20 PM, Jerry DeLisle wrote:
>> On 03/24/2018 10:11 AM, Steve Kargl wrote:
>>> On Sat, Mar 24, 2018 at 05:20:06PM +0100, Jakub Jelinek wrote:
>>>> On Sat, Mar 24, 2018 at 09:04:04AM -0700, Steve Kargl wrote:
>>>>>> Or shall we just check (warn_std & GFC_STD_LEGACY) != 0, if true,
>>>>>> set fmt->error if width etc. is missing, otherwise use the -1 and
>>>>>> later
>>>>>> resolve it to the default?
>>>>>
>>>>> No.  DEC extensions should be activated by the use of one of the
>>>>> -fdec-* options.  For this extension, I think it can be grouped
>>>>> under the general purpose -fdec option.  In the Fortran FE, -fdec
>>>>> then becomes "if (flag_dec)".  I don't recall if Fritz set up
>>>>> passing flag_dec into libgfortran.
>>>>
>>>> I don't see it passed directly.
>>>> With -fdec compile_options.warn_std is 0, rather than the default
>>>> GFC_STD_LEGACY | GFC_STD_F95_DEL, but _gfortran_set_options
>>>> argument is exactly the same for -fdec and for -std=legacy, so there
>>>> is no
>>>> way to differentiate the two.
>>>>
>>>> So, the only way to handle this DEC extension without adding new bits
>>>> (to either compile_options (i.e. GFC_STD_*), or the io flags as shown
>>>> by the
>>>> patch Jeff posted) would be to abuse the IOPARM_dt_default_exp bit
>>>> for it,
>>>> i.e. tie together the extension omitting exponent and the default width.
>>>> Seems the IOPARM_dt_default_exp is set whenever -fdec and not otherwise:
>>>>
>>>
>>> Well, if we add
>>>
>>> #define GFC_STD_DEC_EXT        (1<<13)
>>>
>>> to fortran/libgfortran.h, we still have 18 bits left.
>>>
>>> Then change options.c(set_dec_flags) to include this in the
>>> list of "standards" passed to libgfortran.  The tests would
>>> then look like
>>>
>>>      fmt->value = (gfc_option.allow_std & GFC_STD_DEC_EXT) ? 2 : 1;
>>>
>>> I don't know if this is any better than using Jeff's idea of reserving
>>> bit #28 in flag (and adding a flag2).  Other than 18 bits at 5 to 8
>>> years per revision to the standards, means we'll be long retired
>>> before someone has to deal with running out of bits.
>>>
>>
>> I like this approach because we can then use it for anything else that
>> crops up down the road for the runtime.
> In this scenario we communicate between the compiler and runtime via the
> ALLOW_STD field.  The technical difference is the change applies
> globally rather than on per-call basis (DT_PARMs IIUC is computed and
> passed to the runtime for each format call).  I think that's likely to
> be OK.
> 
> The downside of this approach is it puts these extensions under the -std
> namespace rather than in -fdec.  I think Steve K. has expressed a desire
> to keep this stuff under -fdec.  I'm not sure how to reconcile the
> difference of opinions here.

Definitely under -fdec. I assumed one could set a new option bit with 
that and have it available globally. If not the DT_PARM bit is fine too. 
Either way, keep under -fdec.

Jerry

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

[Jeff Law]

On 03/25/2018 01:09 PM, Jerry DeLisle wrote:
> On 03/25/2018 11:48 AM, Jeff Law wrote:
>> On 03/24/2018 12:20 PM, Jerry DeLisle wrote:
>>> On 03/24/2018 10:11 AM, Steve Kargl wrote:
>>>> On Sat, Mar 24, 2018 at 05:20:06PM +0100, Jakub Jelinek wrote:
>>>>> On Sat, Mar 24, 2018 at 09:04:04AM -0700, Steve Kargl wrote:
>>>>>>> Or shall we just check (warn_std & GFC_STD_LEGACY) != 0, if true,
>>>>>>> set fmt->error if width etc. is missing, otherwise use the -1 and
>>>>>>> later
>>>>>>> resolve it to the default?
>>>>>>
>>>>>> No.  DEC extensions should be activated by the use of one of the
>>>>>> -fdec-* options.  For this extension, I think it can be grouped
>>>>>> under the general purpose -fdec option.  In the Fortran FE, -fdec
>>>>>> then becomes "if (flag_dec)".  I don't recall if Fritz set up
>>>>>> passing flag_dec into libgfortran.
>>>>>
>>>>> I don't see it passed directly.
>>>>> With -fdec compile_options.warn_std is 0, rather than the default
>>>>> GFC_STD_LEGACY | GFC_STD_F95_DEL, but _gfortran_set_options
>>>>> argument is exactly the same for -fdec and for -std=legacy, so there
>>>>> is no
>>>>> way to differentiate the two.
>>>>>
>>>>> So, the only way to handle this DEC extension without adding new bits
>>>>> (to either compile_options (i.e. GFC_STD_*), or the io flags as shown
>>>>> by the
>>>>> patch Jeff posted) would be to abuse the IOPARM_dt_default_exp bit
>>>>> for it,
>>>>> i.e. tie together the extension omitting exponent and the default
>>>>> width.
>>>>> Seems the IOPARM_dt_default_exp is set whenever -fdec and not
>>>>> otherwise:
>>>>>
>>>>
>>>> Well, if we add
>>>>
>>>> #define GFC_STD_DEC_EXT        (1<<13)
>>>>
>>>> to fortran/libgfortran.h, we still have 18 bits left.
>>>>
>>>> Then change options.c(set_dec_flags) to include this in the
>>>> list of "standards" passed to libgfortran.  The tests would
>>>> then look like
>>>>
>>>>      fmt->value = (gfc_option.allow_std & GFC_STD_DEC_EXT) ? 2 : 1;
>>>>
>>>> I don't know if this is any better than using Jeff's idea of reserving
>>>> bit #28 in flag (and adding a flag2).  Other than 18 bits at 5 to 8
>>>> years per revision to the standards, means we'll be long retired
>>>> before someone has to deal with running out of bits.
>>>>
>>>
>>> I like this approach because we can then use it for anything else that
>>> crops up down the road for the runtime.
>> In this scenario we communicate between the compiler and runtime via the
>> ALLOW_STD field.  The technical difference is the change applies
>> globally rather than on per-call basis (DT_PARMs IIUC is computed and
>> passed to the runtime for each format call).  I think that's likely to
>> be OK.
>>
>> The downside of this approach is it puts these extensions under the -std
>> namespace rather than in -fdec.  I think Steve K. has expressed a desire
>> to keep this stuff under -fdec.  I'm not sure how to reconcile the
>> difference of opinions here.
> 
> Definitely under -fdec. I assumed one could set a new option bit with
> that and have it available globally. If not the DT_PARM bit is fine too.
> Either way, keep under -fdec.
Ah, have -fdec set the right option in ALLOW_STD?  That ought to work.
I'll give it a whirl.

jeff

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

[Steve Kargl]

On Sun, Mar 25, 2018 at 12:48:52PM -0600, Jeff Law wrote:
> On 03/24/2018 12:20 PM, Jerry DeLisle wrote:
> > On 03/24/2018 10:11 AM, Steve Kargl wrote:
> >>
> >> Well, if we add
> >>
> >> #define GFC_STD_DEC_EXT   (1<<13)
> >>
> >> to fortran/libgfortran.h, we still have 18 bits left.
> >>
> >> Then change options.c(set_dec_flags) to include this in the
> >> list of "standards" passed to libgfortran.  The tests would
> >> then look like
> >>
> >>  fmt->value = (gfc_option.allow_std & GFC_STD_DEC_EXT) ? 2 : 1;
> >>
> >> I don't know if this is any better than using Jeff's idea of reserving
> >> bit #28 in flag (and adding a flag2).  Other than 18 bits at 5 to 8
> >> years per revision to the standards, means we'll be long retired
> >> before someone has to deal with running out of bits.
> >>
> > 
> > I like this approach because we can then use it for anything else that
> > crops up down the road for the runtime.
> In this scenario we communicate between the compiler and runtime via the
> ALLOW_STD field.  The technical difference is the change applies
> globally rather than on per-call basis (DT_PARMs IIUC is computed and
> passed to the runtime for each format call).  I think that's likely to
> be OK.
> 
> The downside of this approach is it puts these extensions under the -std
> namespace rather than in -fdec.  I think Steve K. has expressed a desire
> to keep this stuff under -fdec.  I'm not sure how to reconcile the
> difference of opinions here.
>
> I'm happy to go with either approach (or even generalizing the default
> exponent code).  What's important to me is that we reach agreement on
> the mechanism we're using for communication between the compiler and
> runtime.
> 

Now that you mention it, -std=dec would prevent a user from
specifically requesting, say, only Fortran 95 with DEC
extensions (i.e, -std=f95 -fdec).

So, to prevent a bikeshed and micro-engineering, I think you
should go with using bit 28 to comunicate with the runtime
and put everything under -fdec in the FE.

Thanks for your patience.

-- 
Steve

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

[Jakub Jelinek]

On Sun, Mar 25, 2018 at 08:44:41PM -0700, Steve Kargl wrote:
> Now that you mention it, -std=dec would prevent a user from
> specifically requesting, say, only Fortran 95 with DEC
> extensions (i.e, -std=f95 -fdec).
> 
> So, to prevent a bikeshed and micro-engineering, I think you
> should go with using bit 28 to comunicate with the runtime
> and put everything under -fdec in the FE.

In that case, we would have two bits that are always set based on flag_dec
in the compiler.

Thus, wouldn't following patch be better?  I.e. just rename the existing bit
from a single particular DEC extension to indicate it turns on all runtime
DEC extensions we support, now or in the future?

Is this ok for trunk now (if it passes bootstrap/regtest)?  Jeff then can
follow with his patch in stage1 just using this bit.

2018-03-26  Jakub Jelinek  <jakub@redhat.com>

	* gfortran.h (gfc_dt): Rename default_exp field to dec_ext.
	* ioparm.def (IOPARM_dt_default_exp): Rename to ...
	(IOPARM_dt_dec_ext): ... this.
	* trans-io.c (build_dt): Adjust for default_exp renaming to
	dec_ext and IOPARM_dt_default_exp renaming to IOPARM_dt_dec_ext.
	* io.c (match_io): Likewise.

	* io/io.h (IOPARM_DT_DEFAULT_EXP): Rename to ...
	(IOPARM_DT_DEC_EXT): ... this.
	* io/list_read.c (parse_real): Adjust for IOPARM_DT_DEFAULT_EXP
	renaming to IOPARM_DT_DEC_EXT.
	(read_real): Likewise.
	* io/read.c (read_f): Likewise.

--- gcc/fortran/gfortran.h.jj	2018-03-07 10:11:43.270758837 +0100
+++ gcc/fortran/gfortran.h	2018-03-26 09:29:40.049578634 +0200
@@ -2437,7 +2437,7 @@ typedef struct
   gfc_expr *io_unit, *format_expr, *rec, *advance, *iostat, *size, *iomsg,
 	   *id, *pos, *asynchronous, *blank, *decimal, *delim, *pad, *round,
 	   *sign, *extra_comma, *dt_io_kind, *udtio;
-  char default_exp;
+  char dec_ext;
 
   gfc_symbol *namelist;
   /* A format_label of `format_asterisk' indicates the "*" format */
--- gcc/fortran/ioparm.def.jj	2018-01-03 10:20:23.234538447 +0100
+++ gcc/fortran/ioparm.def	2018-03-26 09:30:59.289568901 +0200
@@ -118,5 +118,5 @@ IOPARM (dt,      round,		1 << 23, char2)
 IOPARM (dt,      sign,		1 << 24, char1)
 #define IOPARM_dt_f2003		      (1 << 25)
 #define IOPARM_dt_dtio		      (1 << 26)
-#define IOPARM_dt_default_exp	      (1 << 27)
+#define IOPARM_dt_dec_ext	      (1 << 27)
 IOPARM (dt,      u,		0,	 pad)
--- gcc/fortran/trans-io.c.jj	2018-02-26 10:46:02.880316251 +0100
+++ gcc/fortran/trans-io.c	2018-03-26 09:30:35.492571824 +0200
@@ -1958,8 +1958,8 @@ build_dt (tree function, gfc_code * code
       if (dt->udtio)
 	mask |= IOPARM_dt_dtio;
 
-      if (dt->default_exp)
-	mask |= IOPARM_dt_default_exp;
+      if (dt->dec_ext)
+	mask |= IOPARM_dt_dec_ext;
 
       if (dt->namelist)
 	{
--- gcc/fortran/io.c.jj	2018-02-19 10:30:02.385160922 +0100
+++ gcc/fortran/io.c	2018-03-26 09:30:08.919575086 +0200
@@ -4249,9 +4249,10 @@ get_io_list:
 	goto syntax;
     }
 
-  /* See if we want to use defaults for missing exponents in real transfers.  */
+  /* See if we want to use defaults for missing exponents in real transfers
+     and other DEC runtime extensions.  */
   if (flag_dec)
-    dt->default_exp = 1;
+    dt->dec_ext = 1;
 
   /* A full IO statement has been matched.  Check the constraints.  spec_end is
      supplied for cases where no locus is supplied.  */
--- libgfortran/io/io.h.jj	2018-01-07 20:28:45.921749740 +0100
+++ libgfortran/io/io.h	2018-03-26 09:32:06.789560623 +0200
@@ -442,7 +442,7 @@ st_parameter_inquire;
 #define IOPARM_DT_HAS_SIGN			(1 << 24)
 #define IOPARM_DT_HAS_F2003                     (1 << 25)
 #define IOPARM_DT_HAS_UDTIO                     (1 << 26)
-#define IOPARM_DT_DEFAULT_EXP			(1 << 27)
+#define IOPARM_DT_DEC_EXT			(1 << 27)
 /* Internal use bit.  */
 #define IOPARM_DT_IONML_SET			(1u << 31)
 
--- libgfortran/io/list_read.c.jj	2018-02-12 23:24:50.961483597 +0100
+++ libgfortran/io/list_read.c	2018-03-26 09:32:48.077555544 +0200
@@ -1380,7 +1380,7 @@ parse_real (st_parameter_dt *dtp, void *
   if (!isdigit (c))
     {
       /* Extension: allow default exponent of 0 when omitted.  */
-      if (dtp->common.flags & IOPARM_DT_DEFAULT_EXP)
+      if (dtp->common.flags & IOPARM_DT_DEC_EXP)
 	{
 	  push_char (dtp, '0');
 	  goto done;
@@ -1831,7 +1831,7 @@ read_real (st_parameter_dt *dtp, void *d
   if (!isdigit (c))
     {
       /* Extension: allow default exponent of 0 when omitted.  */
-      if (dtp->common.flags & IOPARM_DT_DEFAULT_EXP)
+      if (dtp->common.flags & IOPARM_DT_DEC_EXT)
 	{
 	  push_char (dtp, '0');
 	  goto done;
--- libgfortran/io/read.c.jj	2018-01-07 20:28:45.921749740 +0100
+++ libgfortran/io/read.c	2018-03-26 09:33:02.538553768 +0200
@@ -1093,7 +1093,7 @@ exponent:
   if (w == 0)
     {
       /* Extension: allow default exponent of 0 when omitted.  */
-      if (dtp->common.flags & IOPARM_DT_DEFAULT_EXP)
+      if (dtp->common.flags & IOPARM_DT_DEC_EXT)
 	goto done;
       else
 	goto bad_float;


	Jakub

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

[Fritz Reese]

On Mon, Mar 26, 2018 at 3:42 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Sun, Mar 25, 2018 at 08:44:41PM -0700, Steve Kargl wrote:
>> Now that you mention it, -std=dec would prevent a user from
>> specifically requesting, say, only Fortran 95 with DEC
>> extensions (i.e, -std=f95 -fdec).
>>
>> So, to prevent a bikeshed and micro-engineering, I think you
>> should go with using bit 28 to comunicate with the runtime
>> and put everything under -fdec in the FE.
>
> In that case, we would have two bits that are always set based on flag_dec
> in the compiler.
>
> Thus, wouldn't following patch be better?  I.e. just rename the existing bit
> from a single particular DEC extension to indicate it turns on all runtime
> DEC extensions we support, now or in the future?
>
> Is this ok for trunk now (if it passes bootstrap/regtest)?  Jeff then can
> follow with his patch in stage1 just using this bit.

I agree with this. Looks good to me.

---
Fritz Reese

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

[Steve Kargl]

On Mon, Mar 26, 2018 at 09:42:40AM +0200, Jakub Jelinek wrote:
> On Sun, Mar 25, 2018 at 08:44:41PM -0700, Steve Kargl wrote:
> > Now that you mention it, -std=dec would prevent a user from
> > specifically requesting, say, only Fortran 95 with DEC
> > extensions (i.e, -std=f95 -fdec).
> > 
> > So, to prevent a bikeshed and micro-engineering, I think you
> > should go with using bit 28 to comunicate with the runtime
> > and put everything under -fdec in the FE.
> 
> In that case, we would have two bits that are always set based on flag_dec
> in the compiler.
> 
> Thus, wouldn't following patch be better?  I.e. just rename the existing bit
> from a single particular DEC extension to indicate it turns on all runtime
> DEC extensions we support, now or in the future?
> 
> Is this ok for trunk now (if it passes bootstrap/regtest)?  Jeff then can
> follow with his patch in stage1 just using this bit.
> 

Jakub,

I'll going to be traveling for meetings over he next
week, so will only have limited time and email access.
I will defer to Jerry as he is much more familiar with
the runtime library IO routines.

-- 
Steve

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

[Jeff Law]

On 03/26/2018 01:42 AM, Jakub Jelinek wrote:
> On Sun, Mar 25, 2018 at 08:44:41PM -0700, Steve Kargl wrote:
>> Now that you mention it, -std=dec would prevent a user from
>> specifically requesting, say, only Fortran 95 with DEC
>> extensions (i.e, -std=f95 -fdec).
>>
>> So, to prevent a bikeshed and micro-engineering, I think you
>> should go with using bit 28 to comunicate with the runtime
>> and put everything under -fdec in the FE.
> 
> In that case, we would have two bits that are always set based on flag_dec
> in the compiler.
Steve might have been using -fdec generically -- there's a -fdec as well
as various sub-options.

My interpretation was to keep the handling of default exponents as-is.
ie, turned on via -fdec and using IOPARM_dt_default_exp.

Default widths would be a distinct option communicated by
IOPARM_dt_default_width in bit #28. It would be implied by -fdec as well
which is supposed to enable all DEC extensions.



Jeff

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

[Jeff Law]

On 03/26/2018 01:15 PM, Steve Kargl wrote:
> On Mon, Mar 26, 2018 at 09:42:40AM +0200, Jakub Jelinek wrote:
>> On Sun, Mar 25, 2018 at 08:44:41PM -0700, Steve Kargl wrote:
>>> Now that you mention it, -std=dec would prevent a user from
>>> specifically requesting, say, only Fortran 95 with DEC
>>> extensions (i.e, -std=f95 -fdec).
>>>
>>> So, to prevent a bikeshed and micro-engineering, I think you
>>> should go with using bit 28 to comunicate with the runtime
>>> and put everything under -fdec in the FE.
>>
>> In that case, we would have two bits that are always set based on flag_dec
>> in the compiler.
>>
>> Thus, wouldn't following patch be better?  I.e. just rename the existing bit
>> from a single particular DEC extension to indicate it turns on all runtime
>> DEC extensions we support, now or in the future?
>>
>> Is this ok for trunk now (if it passes bootstrap/regtest)?  Jeff then can
>> follow with his patch in stage1 just using this bit.
>>
> 
> Jakub,
> 
> I'll going to be traveling for meetings over he next
> week, so will only have limited time and email access.
> I will defer to Jerry as he is much more familiar with
> the runtime library IO routines.
Happy to go with whatever Jerry decides.

Thanks,

jeff

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

[Jakub Jelinek]

On Mon, Mar 26, 2018 at 03:03:11PM -0600, Jeff Law wrote:
> On 03/26/2018 01:42 AM, Jakub Jelinek wrote:
> > On Sun, Mar 25, 2018 at 08:44:41PM -0700, Steve Kargl wrote:
> >> Now that you mention it, -std=dec would prevent a user from
> >> specifically requesting, say, only Fortran 95 with DEC
> >> extensions (i.e, -std=f95 -fdec).
> >>
> >> So, to prevent a bikeshed and micro-engineering, I think you
> >> should go with using bit 28 to comunicate with the runtime
> >> and put everything under -fdec in the FE.
> > 
> > In that case, we would have two bits that are always set based on flag_dec
> > in the compiler.
> Steve might have been using -fdec generically -- there's a -fdec as well
> as various sub-options.

There is, but e.g. the default exponent stuff is guarded solely by -fdec, not by
some sub-option.  If the default width would be also just -fdec, then having
two bits that do the same thing would be a waste of bits.

That said, I don't care that much, there are 3 roughly equivalent ways to
propagate this info (this bit 27, bit 28 and GFC_STD_DEC_EXT on
allow_std/warn_std), let the libgfortran maintainers choose.

The patch I've posted with s/IOPARM_DT_DEC_EXP/IOPARM_DT_DEC_EXT/ to fix
one typo I've made passed bootstrap/regtest on x86_64-linux and i686-linux.

	Jakub

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

[Jerry DeLisle]

On 03/27/2018 02:13 AM, Jakub Jelinek wrote:
> On Mon, Mar 26, 2018 at 03:03:11PM -0600, Jeff Law wrote:
>> On 03/26/2018 01:42 AM, Jakub Jelinek wrote:
>>> On Sun, Mar 25, 2018 at 08:44:41PM -0700, Steve Kargl wrote:
>>>> Now that you mention it, -std=dec would prevent a user from
>>>> specifically requesting, say, only Fortran 95 with DEC
>>>> extensions (i.e, -std=f95 -fdec).
>>>>
>>>> So, to prevent a bikeshed and micro-engineering, I think you
>>>> should go with using bit 28 to comunicate with the runtime
>>>> and put everything under -fdec in the FE.
>>>
>>> In that case, we would have two bits that are always set based on flag_dec
>>> in the compiler.
>> Steve might have been using -fdec generically -- there's a -fdec as well
>> as various sub-options.
> 
> There is, but e.g. the default exponent stuff is guarded solely by -fdec, not by
> some sub-option.  If the default width would be also just -fdec, then having
> two bits that do the same thing would be a waste of bits.
> 
> That said, I don't care that much, there are 3 roughly equivalent ways to
> propagate this info (this bit 27, bit 28 and GFC_STD_DEC_EXT on
> allow_std/warn_std), let the libgfortran maintainers choose.
> 
> The patch I've posted with s/IOPARM_DT_DEC_EXP/IOPARM_DT_DEC_EXT/ to fix
> one typo I've made passed bootstrap/regtest on x86_64-linux and i686-linux.
> 
> 	Jakub
> 

Yes, please go ahead and commit. No need for mutually exclusive bits.

Regards,

Jerry