[PATCH] Fix fortran/81509

[PATCH] Fix fortran/81509

[Steve Kargl]

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

The attached patch fixes PR fortran/81509.

In short, F2008 now allows boz-literal-constants in IAND, IOR, IEOR,
DSHIFTL, DSHIFTR, and MERGE_BITS.  gfortran currently allows BOZ
argument, but she was not enforcing restrictions in F2008.  The
attach patch causes gfortran to conform to F2008.

As aside effect, the patch removes a questionable GNU Fortran
extension that allowed arguments to IAND, IOR, and IEOR to have
different kind type parameters.  The behavior of this extension
was not documented.

2017-09-27  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/81509
	* check.c: Rename function gfc_check_iand to gfc_check_iand_ieor_ior.
	* check.c (boz_args_check): New function.  Check I and J not both BOZ.
	(gfc_check_dshift,gfc_check_iand_ieor_ior, gfc_check_ishft,
	 gfc_check_and, gfc_check_merge_bits): Use it.
	* check.c (gfc_check_iand_ieor_ior): Force conversion of BOZ to kind
	type of other agrument.  Remove silly GNU extension.
	(gfc_check_ieor, gfc_check_ior): Delete now unused functions.
	* intrinsic.c (add_functions): Use gfc_check_iand_ieor_ior. Wrap long
	line.
	* intrinsic.h: Rename gfc_check_iand to gfc_check_iand_ieor_ior.
	Delete prototype for bool gfc_check_ieor and gfc_check_ior
	* intrinsic.texi: Update documentation for boz-literal-constant.

2017-09-27  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/81509
	* gfortran.dg/graphite/id-26.f03: Fix non-conforming use of IAND.
	* gfortran.dg/pr81509_1.f90: New test.
	* gfortran.dg/pr81509_2.f90: New test.

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

[-- Attachment #2: pr81509.diff --]
[-- Type: text/x-diff, Size: 16174 bytes --]

Index: gcc/fortran/check.c
===================================================================
--- gcc/fortran/check.c	(revision 253236)
+++ gcc/fortran/check.c	(working copy)
@@ -2101,6 +2101,21 @@ gfc_check_dprod (gfc_expr *x, gfc_expr *y)
 }
 
 
+static bool
+boz_args_check(gfc_expr *i, gfc_expr *j)
+{
+  if (i->is_boz && j->is_boz)
+    {
+      gfc_error ("Arguments of %qs at %L and %L cannot both be BOZ "
+		 "literal constants", gfc_current_intrinsic, &i->where,
+		 &j->where);
+      return false;
+
+    }
+  return true;
+}
+
+
 bool
 gfc_check_dshift (gfc_expr *i, gfc_expr *j, gfc_expr *shift)
 {
@@ -2110,12 +2125,8 @@ gfc_check_dshift (gfc_expr *i, gfc_expr *j, gfc_expr *
   if (!type_check (j, 1, BT_INTEGER))
     return false;
 
-  if (i->is_boz && j->is_boz)
-    {
-      gfc_error ("%<I%> at %L and %<J%>' at %L cannot both be BOZ literal "
-		   "constants", &i->where, &j->where);
-      return false;
-    }
+  if (!boz_args_check (i, j))
+    return false;
 
   if (!i->is_boz && !j->is_boz && !same_type_check (i, 0, j, 1))
     return false;
@@ -2361,7 +2372,7 @@ gfc_check_i (gfc_expr *i)
 
 
 bool
-gfc_check_iand (gfc_expr *i, gfc_expr *j)
+gfc_check_iand_ieor_ior (gfc_expr *i, gfc_expr *j)
 {
   if (!type_check (i, 0, BT_INTEGER))
     return false;
@@ -2369,10 +2380,16 @@ gfc_check_iand (gfc_expr *i, gfc_expr *j)
   if (!type_check (j, 1, BT_INTEGER))
     return false;
 
+  if (!boz_args_check (i, j))
+    return false;
+
+  if (i->is_boz) i->ts.kind = j->ts.kind;
+  if (j->is_boz) j->ts.kind = i->ts.kind;
+
   if (i->ts.kind != j->ts.kind)
     {
-      if (!gfc_notify_std (GFC_STD_GNU, "Different type kinds at %L",
-			   &i->where))
+      gfc_error ("Arguments of %qs have different kind type parameters "
+		 "at %L", gfc_current_intrinsic, &i->where);
 	return false;
     }
 
@@ -2487,26 +2504,6 @@ gfc_check_idnint (gfc_expr *a)
 
 
 bool
-gfc_check_ieor (gfc_expr *i, gfc_expr *j)
-{
-  if (!type_check (i, 0, BT_INTEGER))
-    return false;
-
-  if (!type_check (j, 1, BT_INTEGER))
-    return false;
-
-  if (i->ts.kind != j->ts.kind)
-    {
-      if (!gfc_notify_std (GFC_STD_GNU, "Different type kinds at %L",
-			   &i->where))
-	return false;
-    }
-
-  return true;
-}
-
-
-bool
 gfc_check_index (gfc_expr *string, gfc_expr *substring, gfc_expr *back,
 		 gfc_expr *kind)
 {
@@ -2559,28 +2556,7 @@ gfc_check_intconv (gfc_expr *x)
   return true;
 }
 
-
 bool
-gfc_check_ior (gfc_expr *i, gfc_expr *j)
-{
-  if (!type_check (i, 0, BT_INTEGER))
-    return false;
-
-  if (!type_check (j, 1, BT_INTEGER))
-    return false;
-
-  if (i->ts.kind != j->ts.kind)
-    {
-      if (!gfc_notify_std (GFC_STD_GNU, "Different type kinds at %L",
-			   &i->where))
-	return false;
-    }
-
-  return true;
-}
-
-
-bool
 gfc_check_ishft (gfc_expr *i, gfc_expr *shift)
 {
   if (!type_check (i, 0, BT_INTEGER)
@@ -3364,6 +3340,12 @@ gfc_check_merge_bits (gfc_expr *i, gfc_expr *j, gfc_ex
   if (!type_check (j, 1, BT_INTEGER))
     return false;
 
+  if (!boz_args_check (i, j))
+    return false;
+
+  if (i->is_boz) i->ts.kind = j->ts.kind;
+  if (j->is_boz) j->ts.kind = i->ts.kind;
+
   if (!type_check (mask, 2, BT_INTEGER))
     return false;
 
@@ -3373,6 +3355,8 @@ gfc_check_merge_bits (gfc_expr *i, gfc_expr *j, gfc_ex
   if (!same_type_check (i, 0, mask, 2))
     return false;
 
+  if (mask->is_boz) mask->ts.kind = i->ts.kind;
+
   return true;
 }
 
@@ -6460,6 +6444,12 @@ gfc_check_and (gfc_expr *i, gfc_expr *j)
 
   if (!scalar_check (j, 1))
     return false;
+
+  if (!boz_args_check (i, j))
+    return false;
+
+  if (i->is_boz) i->ts.kind = j->ts.kind;
+  if (j->is_boz) j->ts.kind = i->ts.kind;
 
   return true;
 }
Index: gcc/fortran/intrinsic.c
===================================================================
--- gcc/fortran/intrinsic.c	(revision 253236)
+++ gcc/fortran/intrinsic.c	(working copy)
@@ -1970,8 +1970,9 @@ add_functions (void)
 
   make_generic ("iachar", GFC_ISYM_IACHAR, GFC_STD_F95);
 
-  add_sym_2 ("iand", GFC_ISYM_IAND, CLASS_ELEMENTAL, ACTUAL_NO, BT_INTEGER, di, GFC_STD_F95,
-	     gfc_check_iand, gfc_simplify_iand, gfc_resolve_iand,
+  add_sym_2 ("iand", GFC_ISYM_IAND, CLASS_ELEMENTAL, ACTUAL_NO, BT_INTEGER, di,
+	     GFC_STD_F95,
+	     gfc_check_iand_ieor_ior, gfc_simplify_iand, gfc_resolve_iand,
 	     i, BT_INTEGER, di, REQUIRED, j, BT_INTEGER, di, REQUIRED);
 
   if (flag_dec_intrinsic_ints)
@@ -2059,8 +2060,9 @@ add_functions (void)
 
   make_generic ("ichar", GFC_ISYM_ICHAR, GFC_STD_F77);
 
-  add_sym_2 ("ieor", GFC_ISYM_IEOR, CLASS_ELEMENTAL, ACTUAL_NO, BT_INTEGER, di, GFC_STD_F95,
-	     gfc_check_ieor, gfc_simplify_ieor, gfc_resolve_ieor,
+  add_sym_2 ("ieor", GFC_ISYM_IEOR, CLASS_ELEMENTAL, ACTUAL_NO, BT_INTEGER, di,
+	     GFC_STD_F95,
+	     gfc_check_iand_ieor_ior, gfc_simplify_ieor, gfc_resolve_ieor,
 	     i, BT_INTEGER, di, REQUIRED, j, BT_INTEGER, di, REQUIRED);
 
   if (flag_dec_intrinsic_ints)
@@ -2137,8 +2139,9 @@ add_functions (void)
 
   make_generic ("long", GFC_ISYM_LONG, GFC_STD_GNU);
 
-  add_sym_2 ("ior", GFC_ISYM_IOR, CLASS_ELEMENTAL, ACTUAL_NO, BT_INTEGER, di, GFC_STD_F95,
-	     gfc_check_ior, gfc_simplify_ior, gfc_resolve_ior,
+  add_sym_2 ("ior", GFC_ISYM_IOR, CLASS_ELEMENTAL, ACTUAL_NO, BT_INTEGER, di,
+	     GFC_STD_F95,
+	     gfc_check_iand_ieor_ior, gfc_simplify_ior, gfc_resolve_ior,
 	     i, BT_INTEGER, di, REQUIRED, j, BT_INTEGER, di, REQUIRED);
 
   if (flag_dec_intrinsic_ints)
Index: gcc/fortran/intrinsic.h
===================================================================
--- gcc/fortran/intrinsic.h	(revision 253236)
+++ gcc/fortran/intrinsic.h	(working copy)
@@ -87,17 +87,15 @@ bool gfc_check_hostnm (gfc_expr *);
 bool gfc_check_huge (gfc_expr *);
 bool gfc_check_hypot (gfc_expr *, gfc_expr *);
 bool gfc_check_i (gfc_expr *);
-bool gfc_check_iand (gfc_expr *, gfc_expr *);
+bool gfc_check_iand_ieor_ior (gfc_expr *, gfc_expr *);
 bool gfc_check_and (gfc_expr *, gfc_expr *);
 bool gfc_check_ibits (gfc_expr *, gfc_expr *, gfc_expr *);
 bool gfc_check_ichar_iachar (gfc_expr *, gfc_expr *);
 bool gfc_check_idnint (gfc_expr *);
-bool gfc_check_ieor (gfc_expr *, gfc_expr *);
 bool gfc_check_image_status (gfc_expr *, gfc_expr *);
 bool gfc_check_index (gfc_expr *, gfc_expr *, gfc_expr *, gfc_expr *);
 bool gfc_check_int (gfc_expr *, gfc_expr *);
 bool gfc_check_intconv (gfc_expr *);
-bool gfc_check_ior (gfc_expr *, gfc_expr *);
 bool gfc_check_irand (gfc_expr *);
 bool gfc_check_isatty (gfc_expr *);
 bool gfc_check_isnan (gfc_expr *);
Index: gcc/fortran/intrinsic.texi
===================================================================
--- gcc/fortran/intrinsic.texi	(revision 253236)
+++ gcc/fortran/intrinsic.texi	(working copy)
@@ -1142,15 +1142,20 @@ Function
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
 @item @var{I} @tab The type shall be either a scalar @code{INTEGER}
-type or a scalar @code{LOGICAL} type.
-@item @var{J} @tab The type shall be the same as the type of @var{I}.
+type or a scalar @code{LOGICAL} type or a boz-literal-constant.
+@item @var{J} @tab The type shall be the same as the type of @var{I} or
+a boz-literal-constant. @var{I} and @var{J} shall not both be
+boz-literal-constants.  If either @var{I} or @var{J} is a
+boz-literal-constant, then the other argument must be a scalar @code{INTEGER}.
 @end multitable
 
 @item @emph{Return value}:
 The return type is either a scalar @code{INTEGER} or a scalar
 @code{LOGICAL}.  If the kind type parameters differ, then the
 smaller kind type is implicitly converted to larger kind, and the 
-return has the larger kind.
+return has the larger kind.  A boz-literal-constant is 
+converted to an @code{INTEGER} with the kind type parameter of
+the other argument as-if a call to @ref{INT} occurred.
 
 @item @emph{Example}:
 @smallexample
@@ -7461,16 +7466,17 @@ Elemental function
 
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
-@item @var{I} @tab The type shall be @code{INTEGER}.
-@item @var{J} @tab The type shall be @code{INTEGER}, of the same
-kind as @var{I}.  (As a GNU extension, different kinds are also 
-permitted.)
+@item @var{I} @tab The type shall be @code{INTEGER} or a boz-literal-constant.
+@item @var{J} @tab The type shall be @code{INTEGER} with the same
+kind type parameter as @var{I} or a boz-literal-constant.
+@var{I} and @var{J} shall not both be boz-literal-constants.
 @end multitable
 
 @item @emph{Return value}:
-The return type is @code{INTEGER}, of the same kind as the
-arguments.  (If the argument kinds differ, it is of the same kind as
-the larger argument.)
+The return type is @code{INTEGER} with the kind type parameter of the
+arguments.
+A boz-literal-constant is converted to an @code{INTEGER} with the kind
+type parameter of the other argument as-if a call to @ref{INT} occurred.
 
 @item @emph{Example}:
 @smallexample
@@ -7911,16 +7917,17 @@ Elemental function
 
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
-@item @var{I} @tab The type shall be @code{INTEGER}.
-@item @var{J} @tab The type shall be @code{INTEGER}, of the same
-kind as @var{I}.  (As a GNU extension, different kinds are also 
-permitted.)
+@item @var{I} @tab The type shall be @code{INTEGER} or a boz-literal-constant.
+@item @var{J} @tab The type shall be @code{INTEGER} with the same
+kind type parameter as @var{I} or a boz-literal-constant.
+@var{I} and @var{J} shall not both be boz-literal-constants.
 @end multitable
 
 @item @emph{Return value}:
-The return type is @code{INTEGER}, of the same kind as the
-arguments.  (If the argument kinds differ, it is of the same kind as
-the larger argument.)
+The return type is @code{INTEGER} with the kind type parameter of the
+arguments.
+A boz-literal-constant is converted to an @code{INTEGER} with the kind
+type parameter of the other argument as-if a call to @ref{INT} occurred.
 
 @item @emph{Specific names}:
 @multitable @columnfractions .20 .20 .20 .25
@@ -8229,16 +8236,17 @@ Elemental function
 
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
-@item @var{I} @tab The type shall be @code{INTEGER}.
-@item @var{J} @tab The type shall be @code{INTEGER}, of the same
-kind as @var{I}.  (As a GNU extension, different kinds are also 
-permitted.)
+@item @var{I} @tab The type shall be @code{INTEGER} or a boz-literal-constant.
+@item @var{J} @tab The type shall be @code{INTEGER} with the same
+kind type parameter as @var{I} or a boz-literal-constant.
+@var{I} and @var{J} shall not both be boz-literal-constants.
 @end multitable
 
 @item @emph{Return value}:
-The return type is @code{INTEGER}, of the same kind as the
-arguments.  (If the argument kinds differ, it is of the same kind as
-the larger argument.)
+The return type is @code{INTEGER} with the kind type parameter of the
+arguments.
+A boz-literal-constant is converted to an @code{INTEGER} with the kind
+type parameter of the other argument as-if a call to @ref{INT} occurred.
 
 @item @emph{Specific names}:
 @multitable @columnfractions .20 .20 .20 .25
@@ -10225,11 +10233,12 @@ Elemental function
 
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
-@item @var{I}    @tab Shall be of type @code{INTEGER}.
-@item @var{J}    @tab Shall be of type @code{INTEGER} and of the same
-kind as @var{I}.
-@item @var{MASK} @tab Shall be of type @code{INTEGER} and of the same
-kind as @var{I}.
+@item @var{I} @tab Shall be of type @code{INTEGER} or a boz-literal-constant.
+@item @var{J} @tab Shall be of type @code{INTEGER} with the same
+kind type parameter as @var{I} or a boz-literal-constant.
+@var{I} and @var{J} shall not both be boz-literal-constants.
+@item @var{MASK} @tab Shall be of type @code{INTEGER} or a boz-literal-constant
+and of the same kind as @var{I}.
 @end multitable
 
 @item @emph{Return value}:
@@ -11046,15 +11055,20 @@ Function
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
 @item @var{I} @tab The type shall be either a scalar @code{INTEGER}
-type or a scalar @code{LOGICAL} type.
-@item @var{J} @tab The type shall be the same as the type of @var{J}.
+type or a scalar @code{LOGICAL} type or a boz-literal-constant.
+@item @var{J} @tab The type shall be the same as the type of @var{I} or
+a boz-literal-constant. @var{I} and @var{J} shall not both be
+boz-literal-constants.  If either @var{I} and @var{J} is a
+boz-literal-constant, then the other argument must be a scalar @code{INTEGER}.
 @end multitable
 
 @item @emph{Return value}:
 The return type is either a scalar @code{INTEGER} or a scalar
 @code{LOGICAL}.  If the kind type parameters differ, then the
 smaller kind type is implicitly converted to larger kind, and the 
-return has the larger kind.
+return has the larger kind.  A boz-literal-constant is 
+converted to an @code{INTEGER} with the kind type parameter of
+the other argument as-if a call to @ref{INT} occurred.
 
 @item @emph{Example}:
 @smallexample
@@ -14506,16 +14520,21 @@ Function
 
 @item @emph{Arguments}:
 @multitable @columnfractions .15 .70
-@item @var{I} @tab The type shall be either  a scalar @code{INTEGER}
-type or a scalar @code{LOGICAL} type.
-@item @var{J} @tab The type shall be the same as the type of @var{I}.
+@item @var{I} @tab The type shall be either a scalar @code{INTEGER}
+type or a scalar @code{LOGICAL} type or a boz-literal-constant.
+@item @var{J} @tab The type shall be the same as the type of @var{I} or
+a boz-literal-constant. @var{I} and @var{J} shall not both be
+boz-literal-constants.  If either @var{I} and @var{J} is a
+boz-literal-constant, then the other argument must be a scalar @code{INTEGER}.
 @end multitable
 
 @item @emph{Return value}:
 The return type is either a scalar @code{INTEGER} or a scalar
 @code{LOGICAL}.  If the kind type parameters differ, then the
 smaller kind type is implicitly converted to larger kind, and the 
-return has the larger kind.
+return has the larger kind.  A boz-literal-constant is 
+converted to an @code{INTEGER} with the kind type parameter of
+the other argument as-if a call to @ref{INT} occurred.
 
 @item @emph{Example}:
 @smallexample
Index: gcc/testsuite/gfortran.dg/graphite/id-26.f03
===================================================================
--- gcc/testsuite/gfortran.dg/graphite/id-26.f03	(revision 253236)
+++ gcc/testsuite/gfortran.dg/graphite/id-26.f03	(working copy)
@@ -51,11 +51,11 @@
   ! Attempt to create 64-byte aligned allocatable
   do i = 1, 64
     allocate (c(1023 + i))
-    if (iand (loc (c(1)), 63) == 0) exit
+    if (iand(int(loc(c(1)), 8), 63_8) == 0) exit
     deallocate (c)
     allocate (b(i)%a(1023 + i))
     allocate (c(1023 + i))
-    if (iand (loc (c(1)), 63) == 0) exit
+    if (iand(int(loc(c(1)), 8), 63_8) == 0) exit
     deallocate (c)
   end do
   if (allocated (c)) then
Index: gcc/testsuite/gfortran.dg/pr81509_1.f90
===================================================================
--- gcc/testsuite/gfortran.dg/pr81509_1.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr81509_1.f90	(working copy)
@@ -0,0 +1,12 @@
+! { dg-do run }
+! https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81509
+program foo
+logical :: a = .false.
+integer :: i = 42
+integer(8) :: k = 42
+if (kind(ieor(z'ade',i)) /= 4) call abort
+if (kind(ior(i,z'1111')) /= 4) call abort
+if (kind(ior(1_8,k)) /= 8) call abort
+if (kind(iand(k,b'1111')) /= 8) call abort
+end program foo
+
Index: gcc/testsuite/gfortran.dg/pr81509_2.f90
===================================================================
--- gcc/testsuite/gfortran.dg/pr81509_2.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr81509_2.f90	(working copy)
@@ -0,0 +1,18 @@
+! { dg-do compile }
+! https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81509
+!
+program foo
+logical :: a = .false.
+integer :: i = 42
+integer(8) :: k
+k = iand(z'aaaa', z'1234')    ! { dg-error "cannot both be BOZ literal" }
+k = and(z'aaaa', z'1234')     ! { dg-error "cannot both be BOZ literal" }
+k = and(1, z'1234')
+k = and(i, z'1234')
+k = ieor(z'ade',i)
+k = ior(i,z'1111')
+k = ior(i,k)                  ! { dg-error "different kind type parameters" }
+k = and(i,k)
+k = and(a,z'1234')            ! { dg-error "must have the same type" }
+end program foo
+

Re: [PATCH] Fix fortran/81509

[Paul Richard Thomas]

Hi Steve,

I'll take your word for it on the F2008 contraints. Given that the
patch is very good - OK for trunk.

Thanks

Paul

On 27 September 2017 at 20:36, Steve Kargl
<sgk@troutmask.apl.washington.edu> wrote:
> The attached patch fixes PR fortran/81509.
>
> In short, F2008 now allows boz-literal-constants in IAND, IOR, IEOR,
> DSHIFTL, DSHIFTR, and MERGE_BITS.  gfortran currently allows BOZ
> argument, but she was not enforcing restrictions in F2008.  The
> attach patch causes gfortran to conform to F2008.
>
> As aside effect, the patch removes a questionable GNU Fortran
> extension that allowed arguments to IAND, IOR, and IEOR to have
> different kind type parameters.  The behavior of this extension
> was not documented.
>
> 2017-09-27  Steven G. Kargl  <kargl@gcc.gnu.org>
>
>         PR fortran/81509
>         * check.c: Rename function gfc_check_iand to gfc_check_iand_ieor_ior.
>         * check.c (boz_args_check): New function.  Check I and J not both BOZ.
>         (gfc_check_dshift,gfc_check_iand_ieor_ior, gfc_check_ishft,
>          gfc_check_and, gfc_check_merge_bits): Use it.
>         * check.c (gfc_check_iand_ieor_ior): Force conversion of BOZ to kind
>         type of other agrument.  Remove silly GNU extension.
>         (gfc_check_ieor, gfc_check_ior): Delete now unused functions.
>         * intrinsic.c (add_functions): Use gfc_check_iand_ieor_ior. Wrap long
>         line.
>         * intrinsic.h: Rename gfc_check_iand to gfc_check_iand_ieor_ior.
>         Delete prototype for bool gfc_check_ieor and gfc_check_ior
>         * intrinsic.texi: Update documentation for boz-literal-constant.
>
> 2017-09-27  Steven G. Kargl  <kargl@gcc.gnu.org>
>
>         PR fortran/81509
>         * gfortran.dg/graphite/id-26.f03: Fix non-conforming use of IAND.
>         * gfortran.dg/pr81509_1.f90: New test.
>         * gfortran.dg/pr81509_2.f90: New test.
>
> --
> Steve
> 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
> 20161221 https://www.youtube.com/watch?v=IbCHE-hONow



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein

Re: [PATCH] Fix fortran/81509

[Steve Kargl]

On Thu, Sep 28, 2017 at 10:46:06AM +0100, Paul Richard Thomas wrote:
> 
> I'll take your word for it on the F2008 contraints. Given that the
> patch is very good - OK for trunk.
> 

The text for IAND from F2008 is 

Arguments.

I   shall be of type integer or a boz-literal-constant.
J   shall be of type integer or a boz-literal-constant. If both I and J
    are of type integer, they shall have the same kind type parameter.
    I and J shall not both be boz-literal-constants.

Result Characteristics.

Same as I if I is of type integer; otherwise, same as J.

Result Value.

If either I or J is a boz-literal-constant, it is first converted as if
by the intrinsic function INT to type integer with the kind type parameter
of the other.


Prior to my patch one could do IAND(1_4, 4_8).  gfortran would convert 
the 1_4 to 1_8 and return effectively IAND(1_8, 4_8).  This violates 
the 2nd sentence in the description of J.  One might argue that the 
extension makes sense except the documentation does not state what
occurs.  The real problem comes with IAND(42_2,z'DEAD') where 
z'DEAD' is some mask user wants to apply to an INTEGER(2) entity.
On x86_64 and due to the implementation of a BOZ to statisfy 
requirements of the DATA statement from F95, z'DEAD' is implicitly an
INTEGER(16).  So, IAND(42_2,z'DEAD') convert 42_2 to 42_16 and returns
a INTEGER(16).  This is a violation of F2008 'Result Value' statement.

In hindsight, some 13 years ago I should have introduced a BT_BOZ basic
type definition.  I need to check, but at one time gfortran for a boz
literal constant set x->is_boz=1, x->ts.type=BT_INTEGER, and x->ts.kind=16. 
where x is a gfc_expr *.  The is_boz is unneeded with BT_BOZ and the
kind can be set to the appropriate kind when needed.  A bonus with
BT_BOZ would automatic fix all other intrinsics which currently accept
a boz, e.g., ABS(z'DEAD').

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

Re: [PATCH] Fix fortran/81509

[Janus Weil]

Hi Steve,

> As aside effect, the patch removes a questionable GNU Fortran
> extension that allowed arguments to IAND, IOR, and IEOR to have
> different kind type parameters.  The behavior of this extension
> was not documented.

I don't really like that part. We were using the nice and convenient
mechanism of gfc_notify_std here, which allows the developer to choose
via the -std flag whether to strictly adhere to a chosen Fortran
standard or to allow GNU extensions etc. You're taking away that
flexibility and replacing it by an unconditional error. I don't
actually think that's a good idea.

In general one can argue about whether or not it's a good idea to use
non-std extensions. But I think gfortran should rather leave the
choice to its users, whether they want to use 'dirty and covenient'
code or have very strict checking. We have nice mechanisms for this,
and I do think we should keep them.

Cheers,
Janus



> 2017-09-27  Steven G. Kargl  <kargl@gcc.gnu.org>
>
>         PR fortran/81509
>         * check.c: Rename function gfc_check_iand to gfc_check_iand_ieor_ior.
>         * check.c (boz_args_check): New function.  Check I and J not both BOZ.
>         (gfc_check_dshift,gfc_check_iand_ieor_ior, gfc_check_ishft,
>          gfc_check_and, gfc_check_merge_bits): Use it.
>         * check.c (gfc_check_iand_ieor_ior): Force conversion of BOZ to kind
>         type of other agrument.  Remove silly GNU extension.
>         (gfc_check_ieor, gfc_check_ior): Delete now unused functions.
>         * intrinsic.c (add_functions): Use gfc_check_iand_ieor_ior. Wrap long
>         line.
>         * intrinsic.h: Rename gfc_check_iand to gfc_check_iand_ieor_ior.
>         Delete prototype for bool gfc_check_ieor and gfc_check_ior
>         * intrinsic.texi: Update documentation for boz-literal-constant.
>
> 2017-09-27  Steven G. Kargl  <kargl@gcc.gnu.org>
>
>         PR fortran/81509
>         * gfortran.dg/graphite/id-26.f03: Fix non-conforming use of IAND.
>         * gfortran.dg/pr81509_1.f90: New test.
>         * gfortran.dg/pr81509_2.f90: New test.
>
> --
> Steve
> 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
> 20161221 https://www.youtube.com/watch?v=IbCHE-hONow

Re: [PATCH] Fix fortran/81509

[Steve Kargl]

On Fri, Sep 29, 2017 at 11:15:47AM +0200, Janus Weil wrote:
> Hi Steve,
> 
> > As aside effect, the patch removes a questionable GNU Fortran
> > extension that allowed arguments to IAND, IOR, and IEOR to have
> > different kind type parameters.  The behavior of this extension
> > was not documented.
> 
> I don't really like that part. We were using the nice and convenient
> mechanism of gfc_notify_std here, which allows the developer to choose
> via the -std flag whether to strictly adhere to a chosen Fortran
> standard or to allow GNU extensions etc. You're taking away that
> flexibility and replacing it by an unconditional error. I don't
> actually think that's a good idea.
> 
> In general one can argue about whether or not it's a good idea to use
> non-std extensions. But I think gfortran should rather leave the
> choice to its users, whether they want to use 'dirty and covenient'
> code or have very strict checking. We have nice mechanisms for this,
> and I do think we should keep them.
> 

It is undefined behavior.  I withdraw the patch.

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

Re: [PATCH] Fix fortran/81509

[Janus Weil]

2017-09-29 16:08 GMT+02:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
> On Fri, Sep 29, 2017 at 11:15:47AM +0200, Janus Weil wrote:
>> Hi Steve,
>>
>> > As aside effect, the patch removes a questionable GNU Fortran
>> > extension that allowed arguments to IAND, IOR, and IEOR to have
>> > different kind type parameters.  The behavior of this extension
>> > was not documented.
>>
>> I don't really like that part. We were using the nice and convenient
>> mechanism of gfc_notify_std here, which allows the developer to choose
>> via the -std flag whether to strictly adhere to a chosen Fortran
>> standard or to allow GNU extensions etc. You're taking away that
>> flexibility and replacing it by an unconditional error. I don't
>> actually think that's a good idea.
>>
>> In general one can argue about whether or not it's a good idea to use
>> non-std extensions. But I think gfortran should rather leave the
>> choice to its users, whether they want to use 'dirty and covenient'
>> code or have very strict checking. We have nice mechanisms for this,
>> and I do think we should keep them.
>>
>
> It is undefined behavior.

... with regards to the F08 standard, which forbids it, yes. I guess
that is the nature of a "non-standard extension". It can still give a
meaningful result, after the smaller kind is implicitly converted to
the larger kind.

Btw, contrary to your earlier claim, the extension is actually
documented: https://gcc.gnu.org/onlinedocs/gfortran/IAND.html


> I withdraw the patch.

Why? It does fix a rejects-valid bug after all, doesn't it? I
completely agree with Paul's earlier review that this is good and
necessary.

All I'm saying is that I don't think it's a good idea to turn the
gfc_notify_std into a gfc_error. If you keep the gfc_notify_std, the
patch is ok for trunk from my side.

Cheers,
Janus

Re: [PATCH] Fix fortran/81509

[Janne Blomqvist]

On Sun, Oct 1, 2017 at 8:42 PM, Janus Weil <janus@gcc.gnu.org> wrote:
> 2017-09-29 16:08 GMT+02:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
>> On Fri, Sep 29, 2017 at 11:15:47AM +0200, Janus Weil wrote:
>>> Hi Steve,
>>>
>>> > As aside effect, the patch removes a questionable GNU Fortran
>>> > extension that allowed arguments to IAND, IOR, and IEOR to have
>>> > different kind type parameters.  The behavior of this extension
>>> > was not documented.
>>>
>>> I don't really like that part. We were using the nice and convenient
>>> mechanism of gfc_notify_std here, which allows the developer to choose
>>> via the -std flag whether to strictly adhere to a chosen Fortran
>>> standard or to allow GNU extensions etc. You're taking away that
>>> flexibility and replacing it by an unconditional error. I don't
>>> actually think that's a good idea.
>>>
>>> In general one can argue about whether or not it's a good idea to use
>>> non-std extensions. But I think gfortran should rather leave the
>>> choice to its users, whether they want to use 'dirty and covenient'
>>> code or have very strict checking. We have nice mechanisms for this,
>>> and I do think we should keep them.
>>>
>>
>> It is undefined behavior.
>
> ... with regards to the F08 standard, which forbids it, yes. I guess
> that is the nature of a "non-standard extension". It can still give a
> meaningful result, after the smaller kind is implicitly converted to
> the larger kind.
>
> Btw, contrary to your earlier claim, the extension is actually
> documented: https://gcc.gnu.org/onlinedocs/gfortran/IAND.html

Yes, it's documented, and Steve's patch would have removed those words
so I presume he was aware of that. I think the crux was that yes, the
existence of such an extension was documented, but not the semantics.
Is the smaller kind variable sign-extended to match the larger kind?
Or zero-extended? Or is the larger kind variable truncated (presumably
not, due to the wording in the return value section)? Or something
else? And are whatever semantics that are actually implemented
guaranteed in some way or are they just accidents due to how the
compiler internals happen to work without any thought into it?

Furthermore, is such an extension useful? I don't see bitwise logical
operations on different sized types making much sense, whatever
semantics we ostensibly support.

>> I withdraw the patch.
>
> Why? It does fix a rejects-valid bug after all, doesn't it? I
> completely agree with Paul's earlier review that this is good and
> necessary.
>
> All I'm saying is that I don't think it's a good idea to turn the
> gfc_notify_std into a gfc_error. If you keep the gfc_notify_std, the
> patch is ok for trunk from my side.

Maybe handling both the standard-conforming BOZ semantics and
different kind types would have made the patch significantly more
complicated, so Steve opted to just delete the non-specified
different-kinds extension?

Personally, I'm be Ok with Steve's patch as is.



-- 
Janne Blomqvist

Re: [PATCH] Fix fortran/81509

[Steve Kargl]

On Sun, Oct 01, 2017 at 07:42:09PM +0200, Janus Weil wrote:
> 2017-09-29 16:08 GMT+02:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
> > On Fri, Sep 29, 2017 at 11:15:47AM +0200, Janus Weil wrote:
> >> Hi Steve,
> >>
> >> > As aside effect, the patch removes a questionable GNU Fortran
> >> > extension that allowed arguments to IAND, IOR, and IEOR to have
> >> > different kind type parameters.  The behavior of this extension
> >> > was not documented.
> >>
> >> I don't really like that part. We were using the nice and convenient
> >> mechanism of gfc_notify_std here, which allows the developer to choose
> >> via the -std flag whether to strictly adhere to a chosen Fortran
> >> standard or to allow GNU extensions etc. You're taking away that
> >> flexibility and replacing it by an unconditional error. I don't
> >> actually think that's a good idea.
> >>
> >> In general one can argue about whether or not it's a good idea to use
> >> non-std extensions. But I think gfortran should rather leave the
> >> choice to its users, whether they want to use 'dirty and covenient'
> >> code or have very strict checking. We have nice mechanisms for this,
> >> and I do think we should keep them.
> >>
> >
> > It is undefined behavior.
> 
> ... with regards to the F08 standard, which forbids it, yes. I guess
> that is the nature of a "non-standard extension". It can still give a
> meaningful result, after the smaller kind is implicitly converted to
> the larger kind.

F95 and F03 have

IAND(I,J)

Arguments.
  
I   shall be of type integer.
J   shall be of type integer with the same kind type parameter as I.

and F08 has

I   shall be of type integer or a boz-literal-constant.
J   shall be of type integer or a boz-literal-constant. If both I and J
    are of type integer, they shall have the same kind type parameter.
    I and J shall not both be boz-literal-constants.

If a user wants to mix the kind type parameters, then the user
can use AND, OR, and XOR.

> Btw, contrary to your earlier claim, the extension is actually
> documented: https://gcc.gnu.org/onlinedocs/gfortran/IAND.html

A parenthetical remark hardly counts as documentation.

>> I withdraw the patch.
> 
> Why? It does fix a rejects-valid bug after all, doesn't it? I
> completely agree with Paul's earlier review that this is good and
> necessary.
> 
> All I'm saying is that I don't think it's a good idea to turn the
> gfc_notify_std into a gfc_error. If you keep the gfc_notify_std, the
> patch is ok for trunk from my side.

gfortran should encourage users to write standard conforming code.

% cat a.f90
program foo
   integer(4) :: i = 4
   integer(8) :: j = 5
   print *, iand(i,j)
end program foo
% gfortran6 -Wall -c a.f90
% gfortran6 -Wconversion -c a.f90
% gfortran6 -Wall -Wextra -c a.f90
% gfortran6 -Wall -Wextra -Wsurprising -c a.f90

There is no mechanism available to warn the user of nonstandard code.

Finally, I have neither the time nor energy to debate the merits of
a dubious undocumented bug/feature.  I have supplied a patch.  An
objection has been raised.  I withdraw the patch.

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

Re: [PATCH] Fix fortran/81509

[Janus Weil]

Hi Steve,

>> >> In general one can argue about whether or not it's a good idea to use
>> >> non-std extensions. But I think gfortran should rather leave the
>> >> choice to its users, whether they want to use 'dirty and covenient'
>> >> code or have very strict checking. We have nice mechanisms for this,
>> >> and I do think we should keep them.
>> >>
>> >
>> > It is undefined behavior.
>>
>> ... with regards to the F08 standard, which forbids it, yes. I guess
>> that is the nature of a "non-standard extension". It can still give a
>> meaningful result, after the smaller kind is implicitly converted to
>> the larger kind.
>
> F95 and F03 have
>
> IAND(I,J)
>
> Arguments.
>
> I   shall be of type integer.
> J   shall be of type integer with the same kind type parameter as I.
>
> and F08 has
>
> I   shall be of type integer or a boz-literal-constant.
> J   shall be of type integer or a boz-literal-constant. If both I and J
>     are of type integer, they shall have the same kind type parameter.
>     I and J shall not both be boz-literal-constants.
>
> If a user wants to mix the kind type parameters, then the user
> can use AND, OR, and XOR.

... which are non-standard, just as differing kinds in IAND. Why would
AND(i4,i8) be any 'better' than IAND(i4, i8) from your point of view?


>> Btw, contrary to your earlier claim, the extension is actually
>> documented: https://gcc.gnu.org/onlinedocs/gfortran/IAND.html
>
> A parenthetical remark hardly counts as documentation.

It is pretty much better than nothing I'd say. Lack of documentation
is not a good motivation for removing a feature (but rather for
enhancing the documentation).


>>> I withdraw the patch.
>>
>> Why? It does fix a rejects-valid bug after all, doesn't it? I
>> completely agree with Paul's earlier review that this is good and
>> necessary.
>>
>> All I'm saying is that I don't think it's a good idea to turn the
>> gfc_notify_std into a gfc_error. If you keep the gfc_notify_std, the
>> patch is ok for trunk from my side.
>
> gfortran should encourage users to write standard conforming code.

I absolutely fully agree here. But it should not do this by
unimplementing non-standard features, but rather by providing a
mechanism to let the user choose between

* "I want my code to strictly comply with my favorite Fortran standard" and
* "I need to use this or that non-standard feature, for this or that
reason. I know that Steve doesn't like it, but quite frankly it's not
his decision to make."

Note that such a mechanism is very nicely provided by the flag
"-std=...", which is certainly one of the stronger points of gfortran.

https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html



> % cat a.f90
> program foo
>    integer(4) :: i = 4
>    integer(8) :: j = 5
>    print *, iand(i,j)
> end program foo
> % gfortran6 -Wall -c a.f90
> % gfortran6 -Wconversion -c a.f90
> % gfortran6 -Wall -Wextra -c a.f90
> % gfortran6 -Wall -Wextra -Wsurprising -c a.f90
>
> There is no mechanism available to warn the user of nonstandard code.

Of course there is:

$ gfortran -std=f2008 a.f90
a.f90:4:17:

    print *, iand(i,j)
                 1
Error: GNU Extension: Different type kinds at (1)



> Finally, I have neither the time nor energy to debate the merits of
> a dubious undocumented bug/feature.  I have supplied a patch.  An
> objection has been raised.  I withdraw the patch.

If every patch submitter would withdraw his patches after getting a
review, gfortran wouldn't be going anywhere I guess.

I never claimed that your patch is all bullshit. I told told you one
detail I don't like about it, and I think that's my good right (or
even my duty) as a reviewer. It's actually very simple to fix, but you
already got two OKs, so you can just as well ignore my opinion and
commit your patch as posted.

Cheers,
Janus

Re: [PATCH] Fix fortran/81509

[Steve Kargl]

On Tue, Oct 03, 2017 at 04:27:15PM +0200, Janus Weil wrote:
> >>
> >> ... with regards to the F08 standard, which forbids it, yes. I guess
> >> that is the nature of a "non-standard extension". It can still give a
> >> meaningful result, after the smaller kind is implicitly converted to
> >> the larger kind.
> >
> > F95 and F03 have
> >
> > IAND(I,J)
> >
> > Arguments.
> >
> > I   shall be of type integer.
> > J   shall be of type integer with the same kind type parameter as I.
> >
> > and F08 has
> >
> > I   shall be of type integer or a boz-literal-constant.
> > J   shall be of type integer or a boz-literal-constant. If both I and J
> >     are of type integer, they shall have the same kind type parameter.
> >     I and J shall not both be boz-literal-constants.
> >
> > If a user wants to mix the kind type parameters, then the user
> > can use AND, OR, and XOR.
> 
> ... which are non-standard, just as differing kinds in IAND. Why would
> AND(i4,i8) be any 'better' than IAND(i4, i8) from your point of view?

You are correct that AND, OR, and XOR are not specified in any Fortran
standard.  However, the Fortran standards permit an implementation to
include additional intrinsic subprograms not specified in a standard.
Fortran 95 has

  A standard-conforming processor may allow additional forms
  and relationships provided that such additions do not conflict
  with the standard forms and relationships.  However, a standard-
  conforming processor may allow additional intrinsic procedures
  even though this could cause a conflict with the name of a procedure
  in a standard-conforming program.  If such a conflict occurs and
  involves the name of an external procedure, the processor is permitted
  to use the intrinsic procedure unless the name is given an interface
  body or the EXTERNAL attribute in the same scoping unit (14).

Similar language appears in F03 and F08.  The gfortran implementation
and documentation for AND, OR, and XOR defined their behavior.

> >>> I withdraw the patch.
> >>
> >> Why? It does fix a rejects-valid bug after all, doesn't it? I
> >> completely agree with Paul's earlier review that this is good and
> >> necessary.
> >>
> >> All I'm saying is that I don't think it's a good idea to turn the
> >> gfc_notify_std into a gfc_error. If you keep the gfc_notify_std, the
> >> patch is ok for trunk from my side.
> >
> > gfortran should encourage users to write standard conforming code.
> 
> I absolutely fully agree here. But it should not do this by
> unimplementing non-standard features, but rather by providing a
> mechanism to let the user choose between
> 
> * "I want my code to strictly comply with my favorite Fortran standard" and
> * "I need to use this or that non-standard feature, for this or that
> reason. I know that Steve doesn't like it, but quite frankly it's not
> his decision to make."

You are correct it is not my decision.  You raised an objection.
You and I have a difference of opinion on the correct action to
take.  So, I withdraw the patch to maintain the status quo.

Since you're adamant about maintaining nonstandard behavior.
Then, please do not cherry-pick from my patch to enforce F2008
semantics for

program foo
   print '(I0)', iand(z'1234',b'1010101')
end program foo

which currently gives

% gfortran6 -static -o z a.f90 && ./z
20

The above nonstandard semantics are currently permitted, and therefore
cannot be changed because someone must have code that uses this feature.

In fact, gfortran current permits

program foo
   x = abs(z'7F7FFFFF')
   print *, x
end program foo

% gfcx -o z -std=f2008 -Wall a.f90 && ./z
a.f90:3:7:

    x = abs(z'7F7FFFFF')
       1
Warning: Change of value in conversion from 'INTEGER(16)' to 'REAL(4)'
at (1) [-Wconversion]
   2.13909504E+09

Please do not change gfortran's behavior of allowing boz-literal-constants
in all intrinsic routines that accept INTEGER(16) as actual argument(s).

> Note that such a mechanism is very nicely provided by the flag
> "-std=...", which is certainly one of the stronger points of gfortran.
> 
> https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html
> 
> > % cat a.f90
> > program foo
> >    integer(4) :: i = 4
> >    integer(8) :: j = 5
> >    print *, iand(i,j)
> > end program foo
> > % gfortran6 -Wall -c a.f90
> > % gfortran6 -Wconversion -c a.f90
> > % gfortran6 -Wall -Wextra -c a.f90
> > % gfortran6 -Wall -Wextra -Wsurprising -c a.f90
> >
> > There is no mechanism available to warn the user of nonstandard code.
> 
> Of course there is:
> 
> $ gfortran -std=f2008 a.f90
> a.f90:4:17:
> 
>     print *, iand(i,j)
>                  1
> Error: GNU Extension: Different type kinds at (1)
> 

Reread what I wrote.  There is NO MECHANISM TO WARN the user.
-std=f2008 does not produce a WARNING.  It produces an ERROR.

For the record, I am aware that -std=f2008 produces an (un)desirable
result for AND, OR, and XOR.  However, if someone is inclined to
use -std=f2008, then that someone is likely to not use AND, OR, XOR.
That someone will use IAND, IOR, and IEOR with correctly typed 
arguments. 

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

Re: [PATCH] Fix fortran/81509

[Janus Weil]

2017-10-03 20:10 GMT+02:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
>> > There is no mechanism available to warn the user of nonstandard code.
>>
>> Of course there is:
>>
>> $ gfortran -std=f2008 a.f90
>> a.f90:4:17:
>>
>>     print *, iand(i,j)
>>                  1
>> Error: GNU Extension: Different type kinds at (1)
>>
>
> Reread what I wrote.  There is NO MECHANISM TO WARN the user.
> -std=f2008 does not produce a WARNING.  It produces an ERROR.

Sorry, I'm currently traveling and must have misread that.

Anyway, I don't have the feeling this discussion is going anywhere. I
said my opinion, you heard it. You have two OKs, so just go ahead and
commit the patch. I really don't care.

Cheers,
Janus

Re: [PATCH] Fix fortran/81509

[Steve Kargl]

On Tue, Oct 03, 2017 at 09:38:51PM +0200, Janus Weil wrote:
> 2017-10-03 20:10 GMT+02:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
> >> > There is no mechanism available to warn the user of nonstandard code.
> >>
> >> Of course there is:
> >>
> >> $ gfortran -std=f2008 a.f90
> >> a.f90:4:17:
> >>
> >>     print *, iand(i,j)
> >>                  1
> >> Error: GNU Extension: Different type kinds at (1)
> >>
> >
> > Reread what I wrote.  There is NO MECHANISM TO WARN the user.
> > -std=f2008 does not produce a WARNING.  It produces an ERROR.
> 
> Sorry, I'm currently traveling and must have misread that.
> 
> Anyway, I don't have the feeling this discussion is going anywhere. I
> said my opinion, you heard it. You have two OKs, so just go ahead and
> commit the patch. I really don't care.
> 

That's two us.  I really don't care.  I don't use IAND, IOR, IEOR, AND, OR,
or XOR.  I simply supplied a patch that brings gfortran into conformance
with F2008.  It sparked controversy.  I withdrew the patch.  The changes
are no longer in my local tree, so I won't be committing anything.  I've
moved onto other things.

For record, my controversal patch fixed

% cat a.f90
program foo
  print '(2(I0,1X))', iand(42,z'dead'), kind(iand(42,z'dead'))
  print '(2(I0,1X))', iand(z'dead',42), kind(iand(z'dead',42))
end program foo
% gfortran6 -static -o z a.f90 && ./z
40 4
40 8

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