public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] Implementation of RANDOM_INIT from F2018
@ 2018-01-08  2:52 Steve Kargl
  2018-01-09  0:58 ` Steve Kargl
  0 siblings, 1 reply; 15+ messages in thread
From: Steve Kargl @ 2018-01-08  2:52 UTC (permalink / raw)
  To: fortran, gcc-patches

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

I have attached my current implementation for RANDOM_INIT.

For programs compiled without -fcoarry= or with -fcoarray=single,
the one gets, 

% cat random_init_2.f90
program foo
   real x(2)
   call random_init(.false., .false.)
   call random_number(x)
   print *, x
   call random_init(.false., .false.)
   call random_number(x)
   print *, x

   call random_init(.true., .false.)
   call random_number(x)
   print *, x
   call random_init(.true., .false.)
   call random_number(x)
   print *, x
end program foo
% gfcx -o z random_init_2.f90 && ./z
  0.817726076      0.318128884    
  0.598739505       2.99510360E-02
  0.336736381      0.870776474    
  0.336736381      0.870776474  

Now, with -fcoarray=lib, one gets 

%  gfcx -fcoarray=lib -c random_init_2.f90
f951: Fatal Error: RANDOM_INIT with co-arrays is broken!
compilation terminated.

I have zero knowledge about co-arrays and especially zero
knowledge about gfortran internals for co-arrays.  I'm
disinclined to waste another 12 hours trying to get gfortran
to emit essentially a call to this_image().  See iresolve.c
for details.

2018-01-07  Steven G. Kargl  <kargl@gcc.gnu.org>

	* check.c (gfc_check_random_init): New function.
	* gfortran.h: Define GFC_ISYM_RANDOM_INIT.
	* intrinsic.c (add_subroutines): Add random_init to list of subroutines.
	(gfc_check_intrinsic_standard): Update error message for Fortran 2018.
	* intrinsic.h: Add prototypes for gfc_check_random_init and
	gfc_resolve_random_init.
	* iresolve.c (gfc_resolve_random_init): Implementation.

2018-01-07  Steven G. Kargl  <kargl@gcc.gnu.org>

	* libgfortran/gfortran.map: Add _gfortran_random_init.
	* libgfortran/intrinsics/random.c: Add implemention of
	_gfortran_random_init

-- 
Steve

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

Index: gcc/fortran/check.c
===================================================================
--- gcc/fortran/check.c	(revision 256045)
+++ gcc/fortran/check.c	(working copy)
@@ -5671,6 +5671,19 @@ gfc_check_mvbits (gfc_expr *from, gfc_expr *frompos, g
 
 
 bool
+gfc_check_random_init (gfc_expr *repeatable, gfc_expr *image_distinct)
+{
+  if (!type_check (repeatable, 0, BT_LOGICAL))
+    return false;
+
+  if (!type_check (image_distinct, 1, BT_LOGICAL))
+    return false;
+
+  return true;
+}
+
+
+bool
 gfc_check_random_number (gfc_expr *harvest)
 {
   if (!type_check (harvest, 0, BT_REAL))
Index: gcc/fortran/expr.c
===================================================================
--- gcc/fortran/expr.c	(revision 256045)
+++ gcc/fortran/expr.c	(working copy)
@@ -3853,7 +3853,7 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *
 
   /* Error for assignments of contiguous pointers to targets which is not
      contiguous.  Be lenient in the definition of what counts as
-     congiguous.  */
+     contiguous.  */
 
   if (lhs_attr.contiguous && !gfc_is_simply_contiguous (rvalue, false, true))
     gfc_error ("Assignment to contiguous pointer from non-contiguous "
Index: gcc/fortran/gfortran.h
===================================================================
--- gcc/fortran/gfortran.h	(revision 256045)
+++ gcc/fortran/gfortran.h	(working copy)
@@ -551,6 +551,7 @@ enum gfc_isym_id
   GFC_ISYM_PRODUCT,
   GFC_ISYM_RADIX,
   GFC_ISYM_RAND,
+  GFC_ISYM_RANDOM_INIT,
   GFC_ISYM_RANDOM_NUMBER,
   GFC_ISYM_RANDOM_SEED,
   GFC_ISYM_RANGE,
Index: gcc/fortran/intrinsic.c
===================================================================
--- gcc/fortran/intrinsic.c	(revision 256045)
+++ gcc/fortran/intrinsic.c	(working copy)
@@ -3549,6 +3549,12 @@ add_subroutines (void)
       make_alias ("kmvbits", GFC_STD_GNU);
     }
 
+  add_sym_2s ("random_init", GFC_ISYM_RANDOM_INIT, CLASS_IMPURE,
+	      BT_UNKNOWN, 0, GFC_STD_F2018,
+	      gfc_check_random_init, NULL, gfc_resolve_random_init,
+	      "repeatable",     BT_LOGICAL, dl, REQUIRED, INTENT_IN,
+	      "image_distinct", BT_LOGICAL, dl, REQUIRED, INTENT_IN);
+
   add_sym_1s ("random_number", GFC_ISYM_RANDOM_NUMBER, CLASS_IMPURE,
 	      BT_UNKNOWN, 0, GFC_STD_F95,
 	      gfc_check_random_number, NULL, gfc_resolve_random_number,
@@ -4601,6 +4607,10 @@ gfc_check_intrinsic_standard (const gfc_intrinsic_sym*
 
     case GFC_STD_F2008_TS:
       symstd_msg = "new in TS 29113/TS 18508";
+      break;
+
+    case GFC_STD_F2018:
+      symstd_msg = "new in Fortran 2018";
       break;
 
     case GFC_STD_GNU:
Index: gcc/fortran/intrinsic.h
===================================================================
--- gcc/fortran/intrinsic.h	(revision 256045)
+++ gcc/fortran/intrinsic.h	(working copy)
@@ -203,6 +203,7 @@ bool gfc_check_getlog (gfc_expr *);
 bool gfc_check_move_alloc (gfc_expr *, gfc_expr *);
 bool gfc_check_mvbits (gfc_expr *, gfc_expr *, gfc_expr *, gfc_expr *,
 		      gfc_expr *);
+bool gfc_check_random_init (gfc_expr *, gfc_expr *);
 bool gfc_check_random_number (gfc_expr *);
 bool gfc_check_random_seed (gfc_expr *, gfc_expr *, gfc_expr *);
 bool gfc_check_dtime_etime_sub (gfc_expr *, gfc_expr *);
@@ -643,6 +644,7 @@ void gfc_resolve_lstat_sub (gfc_code *);
 void gfc_resolve_ltime (gfc_code *);
 void gfc_resolve_mvbits (gfc_code *);
 void gfc_resolve_perror (gfc_code *);
+void gfc_resolve_random_init (gfc_code *);
 void gfc_resolve_random_number (gfc_code *);
 void gfc_resolve_random_seed (gfc_code *);
 void gfc_resolve_rename_sub (gfc_code *);
Index: gcc/fortran/iresolve.c
===================================================================
--- gcc/fortran/iresolve.c	(revision 256045)
+++ gcc/fortran/iresolve.c	(working copy)
@@ -35,7 +35,9 @@ along with GCC; see the file COPYING3.  If not see
 #include "intrinsic.h"
 #include "constructor.h"
 #include "arith.h"
+#include "tm.h"		/* For flag_coarray.  */
 
+
 /* Given printf-like arguments, return a stable version of the result string. 
 
    We already have a working, optimized string hashing table in the form of
@@ -3118,6 +3120,8 @@ gfc_resolve_trim (gfc_expr *f, gfc_expr *string)
 {
   f->ts.type = BT_CHARACTER;
   f->ts.kind = string->ts.kind;
+  f->ts.u.cl = NULL;
+  f->ts.u.pad = 0;
   f->value.function.name = gfc_get_string ("__trim_%d", string->ts.kind);
 }
 
@@ -3368,6 +3372,61 @@ gfc_resolve_mvbits (gfc_code *c)
   /* Create a dummy formal arglist so the INTENTs are known later for purpose
      of creating temporaries.  */
   c->resolved_sym->formal = create_formal_for_intents (c->ext.actual, INTENTS);
+}
+
+
+/* Set up the call to RANDOM_INIT.  To deal with image_distinct, we need to
+   send a hidden argument into the library function.  For program that don't
+   use co-arrays or uses -fcoarray=single, the hidden argument is set to 0.
+   For -fcoarray=lib, the hidden argument should be set to the value 
+   returned by this_image().  Using R for REPEATABLE and I for
+   IMAGE_DISTINCT. So, RANDOM_INIT(R, I) is mapped to the library routine
+   _gfortran_random_init(R, I, 0) for a single image, and it should be
+   mapped to _gfortran_random_init(R, I, this_image()).  */ 
+
+void
+gfc_resolve_random_init (gfc_code *c)
+{
+  gfc_actual_arglist *a;
+  const char *name;
+
+  name = gfc_get_string (PREFIX ("random_init"));
+  c->resolved_sym = gfc_get_intrinsic_sub_symbol (name);
+
+  /* Pass a hidden integer to deal with seeding images for coarrays.  */
+  a = gfc_get_actual_arglist ();
+  if (flag_coarray != GFC_FCOARRAY_LIB)
+    {
+      a->expr = gfc_get_constant_expr (BT_INTEGER, gfc_default_integer_kind,
+					&c->ext.actual->next->expr->where);
+      mpz_set_si (a->expr->value.integer, 0);
+    }
+  else
+    {
+      gfc_fatal_error ("RANDOM_INIT with co-arrays is broken!");
+#if 0
+/* Well, this didn't work. :(  */
+      static const char name[] = "this_image";
+      a->expr = gfc_get_expr ();
+      a->expr->expr_type = EXPR_FUNCTION;
+      a->expr->ts.type = BT_INTEGER;
+      a->expr->ts.kind = gfc_default_integer_kind;
+      a->expr->where = gfc_current_locus;
+      a->expr->value.function.isym = gfc_find_function (name);
+      a->expr->value.function.name = a->expr->value.function.isym->name;
+
+      a->expr->value.function.actual = gfc_get_actual_arglist ();
+      a->expr->value.function.actual->next = gfc_get_actual_arglist ();
+      a->expr->value.function.actual->next->next = gfc_get_actual_arglist ();
+      a->expr->value.function.isym->formal->actual = gfc_get_actual_arglist ();
+      a->expr->value.function.isym->formal->actual->next = gfc_get_actual_arglist ();
+      a->expr->value.function.isym->formal->actual->next->next = gfc_get_actual_arglist ();
+
+      gfc_simplify_expr (a->expr, 0);
+      c->resolved_isym->formal->actual->next->next = a;
+#endif
+    }
+    c->ext.actual->next->next = a;
 }
 
 
Index: libgfortran/gfortran.map
===================================================================
--- libgfortran/gfortran.map	(revision 256045)
+++ libgfortran/gfortran.map	(working copy)
@@ -801,6 +801,7 @@ GFORTRAN_8 {
     _gfortran_product_r4;
     _gfortran_product_r8;
     _gfortran_rand;
+    _gfortran_random_init;
     _gfortran_random_r10;
     _gfortran_random_r16;
     _gfortran_random_r4;
Index: libgfortran/intrinsics/random.c
===================================================================
--- libgfortran/intrinsics/random.c	(revision 256045)
+++ libgfortran/intrinsics/random.c	(working copy)
@@ -44,6 +44,9 @@ see the files COPYING3 and COPYING.RUNTIME respectivel
 #include <_mingw.h> /* For __MINGW64_VERSION_MAJOR  */
 #endif
 
+extern void random_init (GFC_LOGICAL_4 *, GFC_LOGICAL_4 *, GFC_INTEGER_4 *);
+iexport_proto(random_init);
+
 extern void random_r4 (GFC_REAL_4 *);
 iexport_proto(random_r4);
 
@@ -205,7 +208,6 @@ static uint64_t master_state[] = {
   0x625288bc262faf33ULL
 };
 
-
 static __gthread_key_t rand_state_key;
 
 static xorshift1024star_state*
@@ -927,6 +929,46 @@ random_seed_i8 (GFC_INTEGER_8 *size, gfc_array_i8 *put
 }
 iexport(random_seed_i8);
 
+
+/* random_init is used to seed the PRNG with either a default
+   set of seeds or a random set of seeds.  */
+
+void
+random_init (GFC_LOGICAL_4 *repeatable, GFC_LOGICAL_4 *image_distinct,
+	     GFC_INTEGER_4 *hidden)
+{
+  static const uint64_t repeat_state[] = {
+    0x25b946ebc0b36173ULL, 0x31fffb768dfde2d1ULL, 0xb08dbf28a70a6b08ULL,
+    0x60b1fc7fbcc04151ULL, 0xb4018862d654635dULL, 0x5c2fc35553bb5470ULL,
+    0xd588f951b8984a2bULL, 0x060c05384e97789dULL, 0x2b992ddfa23249d6ULL,
+    0x4034650f1c98bd69ULL, 0x79267e9c00e018afULL, 0x449eb881a2869d0eULL,
+    0xe2fee08d1e670313ULL, 0x17afc3eef0f0c640ULL, 0x2002db4f8acb8a0eULL,
+    0x50cd06b1b61a6804ULL
+  };
+
+  xorshift1024star_state* rs = get_rand_state();
+
+  __gthread_mutex_lock (&random_lock);
+
+  if (*repeatable)
+    {
+      /* Copy the repeat seeds.   */
+      memcpy (&rs->s, repeat_state, sizeof (repeat_state));
+      njumps = 0;
+      if (*image_distinct) njumps = *hidden;
+      master_init = true;
+      init_rand_state (rs, true);
+	  rs->p = 0;
+    }
+  else
+    {
+      master_init = false;
+      init_rand_state (rs, true);
+    }
+
+  __gthread_mutex_unlock (&random_lock);
+}
+iexport(random_init);
 
 #if !defined __GTHREAD_MUTEX_INIT || defined __GTHREADS
 static void __attribute__((constructor))

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] Implementation of RANDOM_INIT from F2018
  2018-01-08  2:52 [PATCH] Implementation of RANDOM_INIT from F2018 Steve Kargl
@ 2018-01-09  0:58 ` Steve Kargl
  2018-01-09  1:33   ` Damian Rouson
  2018-01-09  2:51   ` Jerry DeLisle
  0 siblings, 2 replies; 15+ messages in thread
From: Steve Kargl @ 2018-01-09  0:58 UTC (permalink / raw)
  To: fortran, gcc-patches

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

On Sun, Jan 07, 2018 at 06:52:22PM -0800, Steve Kargl wrote:
> 
> I have zero knowledge about co-arrays and especially zero
> knowledge about gfortran internals for co-arrays.  I'm
> disinclined to waste another 12 hours trying to get gfortran
> to emit essentially a call to this_image().  See iresolve.c
> for details.
> 

An epiphany came to me last night, which has led to the attach
patch.  This patch should be a complete implementation of
RANDOM_INIT.

RANDOM_INIT takes two LOGICAL, INTENT(IN) arguments.  To 
avoid library bloat, these arguments are converted/casted to
LOGICAL(4) in trans-intrinsic.c (conv_intrinsic_random_init).
It is also in this function, that I set up the hidden argument
that is needed to hopefully give standard conforming behavior
when co-arrays are involved.  I, however, cannot test -fcoarray=lib
situation.  I would appreciate feedback from a co-array user.

Boostrapped and regression tested on x86_64-*-freebsd.
OK to commit?

2018-01-08  Steven G. Kargl  <kargl@gcc.gnu.org>

	* check.c (gfc_check_random_init): New function.  Check arguments of
	random_init().
	* gfortran.h (gfc_isym_id): Add GFC_ISYM_RANDOM_INIT.
	* intrinsic.c (add_subroutines): Make random_init() an intrinsic
	subroutine.
	(gfc_check_intrinsic_standard): Check for Fortran 2018.
	* intrinsic.h: Add prototypes for gfc_check_random_init and
	gfc_resolve_random_init.
	* iresolve.c (gfc_resolve_random_init): New function.  Add
	_gfortran_random_init to list of subroutines.
	* trans-decl.c: Describe gfor_fndecl_random_init.
	* trans-intrinsic.c (conv_intrinsic_random_init): New function.
	Translate random_init and added hidden argument.
	(gfc_conv_intrinsic_subroutine): Call conv_intrinsic_random_init.
	* trans.h: Declare gfor_fndecl_random_init.

2018-01-08  Steven G. Kargl  <kargl@gcc.gnu.org>

	* gfortran.dg/random_init_1.f90: New test.
	* gfortran.dg/random_init_2.f90: New test.

2018-01-08  Steven G. Kargl  <kargl@gcc.gnu.org>

	* gfortran.map: Add _gfortran_random_init to library map.
	* intrinsics/random.c (random_init): Implemenation of random_init.

-- 
steve

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

Index: gcc/fortran/check.c
===================================================================
--- gcc/fortran/check.c	(revision 256351)
+++ gcc/fortran/check.c	(working copy)
@@ -5723,6 +5723,27 @@ gfc_check_mvbits (gfc_expr *from, gfc_expr *frompos, g
 }
 
 
+/* Check the arguments for RANDOM_INIT.  */
+
+bool
+gfc_check_random_init (gfc_expr *repeatable, gfc_expr *image_distinct)
+{
+  if (!type_check (repeatable, 0, BT_LOGICAL))
+    return false;
+
+  if (!scalar_check (repeatable, 0))
+    return false;
+
+  if (!type_check (image_distinct, 1, BT_LOGICAL))
+    return false;
+
+  if (!scalar_check (image_distinct, 1))
+    return false;
+
+  return true;
+}
+
+
 bool
 gfc_check_random_number (gfc_expr *harvest)
 {
Index: gcc/fortran/gfortran.h
===================================================================
--- gcc/fortran/gfortran.h	(revision 256351)
+++ gcc/fortran/gfortran.h	(working copy)
@@ -551,6 +551,7 @@ enum gfc_isym_id
   GFC_ISYM_PRODUCT,
   GFC_ISYM_RADIX,
   GFC_ISYM_RAND,
+  GFC_ISYM_RANDOM_INIT,
   GFC_ISYM_RANDOM_NUMBER,
   GFC_ISYM_RANDOM_SEED,
   GFC_ISYM_RANGE,
Index: gcc/fortran/intrinsic.c
===================================================================
--- gcc/fortran/intrinsic.c	(revision 256351)
+++ gcc/fortran/intrinsic.c	(working copy)
@@ -3549,6 +3549,12 @@ add_subroutines (void)
       make_alias ("kmvbits", GFC_STD_GNU);
     }
 
+  add_sym_2s ("random_init", GFC_ISYM_RANDOM_INIT, CLASS_IMPURE,
+	      BT_UNKNOWN, 0, GFC_STD_F2018,
+	      gfc_check_random_init, NULL, gfc_resolve_random_init,
+	      "repeatable",     BT_LOGICAL, dl, REQUIRED, INTENT_IN,
+	      "image_distinct", BT_LOGICAL, dl, REQUIRED, INTENT_IN);
+
   add_sym_1s ("random_number", GFC_ISYM_RANDOM_NUMBER, CLASS_IMPURE,
 	      BT_UNKNOWN, 0, GFC_STD_F95,
 	      gfc_check_random_number, NULL, gfc_resolve_random_number,
@@ -4601,6 +4607,10 @@ gfc_check_intrinsic_standard (const gfc_intrinsic_sym*
 
     case GFC_STD_F2008_TS:
       symstd_msg = "new in TS 29113/TS 18508";
+      break;
+
+    case GFC_STD_F2018:
+      symstd_msg = "new in Fortran 2018";
       break;
 
     case GFC_STD_GNU:
Index: gcc/fortran/intrinsic.h
===================================================================
--- gcc/fortran/intrinsic.h	(revision 256351)
+++ gcc/fortran/intrinsic.h	(working copy)
@@ -203,6 +203,7 @@ bool gfc_check_getlog (gfc_expr *);
 bool gfc_check_move_alloc (gfc_expr *, gfc_expr *);
 bool gfc_check_mvbits (gfc_expr *, gfc_expr *, gfc_expr *, gfc_expr *,
 		      gfc_expr *);
+bool gfc_check_random_init (gfc_expr *, gfc_expr *);
 bool gfc_check_random_number (gfc_expr *);
 bool gfc_check_random_seed (gfc_expr *, gfc_expr *, gfc_expr *);
 bool gfc_check_dtime_etime_sub (gfc_expr *, gfc_expr *);
@@ -646,6 +647,7 @@ void gfc_resolve_lstat_sub (gfc_code *);
 void gfc_resolve_ltime (gfc_code *);
 void gfc_resolve_mvbits (gfc_code *);
 void gfc_resolve_perror (gfc_code *);
+void gfc_resolve_random_init (gfc_code *);
 void gfc_resolve_random_number (gfc_code *);
 void gfc_resolve_random_seed (gfc_code *);
 void gfc_resolve_rename_sub (gfc_code *);
Index: gcc/fortran/iresolve.c
===================================================================
--- gcc/fortran/iresolve.c	(revision 256351)
+++ gcc/fortran/iresolve.c	(working copy)
@@ -3370,6 +3370,17 @@ gfc_resolve_mvbits (gfc_code *c)
 }
 
 
+/* Set up the call to RANDOM_INIT.  */ 
+
+void
+gfc_resolve_random_init (gfc_code *c)
+{
+  const char *name;
+  name = gfc_get_string (PREFIX ("random_init"));
+  c->resolved_sym = gfc_get_intrinsic_sub_symbol (name);
+}
+
+
 void
 gfc_resolve_random_number (gfc_code *c)
 {
Index: gcc/fortran/trans-decl.c
===================================================================
--- gcc/fortran/trans-decl.c	(revision 256351)
+++ gcc/fortran/trans-decl.c	(working copy)
@@ -221,6 +221,8 @@ tree gfor_fndecl_dgemm;
 tree gfor_fndecl_cgemm;
 tree gfor_fndecl_zgemm;
 
+/* RANDOM_INIT function.  */
+tree gfor_fndecl_random_init;
 
 static void
 gfc_add_decl_to_parent_function (tree decl)
@@ -3314,6 +3316,11 @@ gfc_build_intrinsic_function_decls (void)
 	get_identifier (PREFIX("ctime")), ".W",
 	void_type_node, 3, pchar_type_node, gfc_charlen_type_node,
 	gfc_int8_type_node);
+
+  gfor_fndecl_random_init = gfc_build_library_function_decl (
+	get_identifier (PREFIX("random_init")),
+	void_type_node, 3, gfc_logical4_type_node, gfc_logical4_type_node,
+	gfc_int4_type_node);
 
   gfor_fndecl_sc_kind = gfc_build_library_function_decl_with_spec (
 	get_identifier (PREFIX("selected_char_kind")), "..R",
Index: gcc/fortran/trans-intrinsic.c
===================================================================
--- gcc/fortran/trans-intrinsic.c	(revision 256351)
+++ gcc/fortran/trans-intrinsic.c	(working copy)
@@ -3484,6 +3484,52 @@ conv_intrinsic_free (gfc_code *code)
 }
 
 
+/* Call the RANDOM_INIT library subrotuine with a hidden argument for
+   handling seeding on coarray images.  */
+
+static tree
+conv_intrinsic_random_init (gfc_code *code)
+{
+  stmtblock_t block;
+  gfc_se se;
+  tree arg1, arg2, arg3, tmp;
+  tree logical4_type_node = gfc_get_logical_type (4);
+
+  /* Make the function call.  */
+  gfc_init_block (&block);
+  gfc_init_se (&se, NULL);
+
+  /* Convert REPEATABLE to a LOGICAL(4) entity.  */
+  gfc_conv_expr (&se, code->ext.actual->expr);
+  gfc_add_block_to_block (&block, &se.pre);
+  arg1 = fold_convert (logical4_type_node, gfc_evaluate_now (se.expr, &block));
+  gfc_add_block_to_block (&block, &se.post);
+
+  /* Convert IMAGE_DISTINCT to a LOGICAL(4) entity.  */
+  gfc_conv_expr (&se, code->ext.actual->next->expr);
+  gfc_add_block_to_block (&block, &se.pre);
+  arg2 = fold_convert (logical4_type_node, gfc_evaluate_now (se.expr, &block));
+  gfc_add_block_to_block (&block, &se.post);
+
+  /* Create the hidden argument.  For non-coarray codes and -fcoarray=single,
+     simply set this to 0.  For -fcoarray=lib, generate a call to 
+     THIS_IMAGE() without arguments.  */ 
+  arg3 = build_int_cst (gfc_get_int_type (4), 0);
+  if (flag_coarray == GFC_FCOARRAY_LIB)
+    {
+      arg3 = build_call_expr_loc (input_location, gfor_fndecl_caf_this_image,
+				  1, arg3);
+      se.expr = fold_convert (gfc_get_int_type (4), arg3);
+    }
+
+  tmp = build_call_expr_loc (input_location, gfor_fndecl_random_init, 3,
+			     arg1, arg2, arg3);
+  gfc_add_expr_to_block (&block, tmp);
+ 
+  return gfc_finish_block (&block);
+}
+
+
 /* Call the SYSTEM_CLOCK library functions, handling the type and kind
    conversions.  */
 
@@ -10711,6 +10757,10 @@ gfc_conv_intrinsic_subroutine (gfc_code *code)
 
     case GFC_ISYM_FREE:
       res = conv_intrinsic_free (code);
+      break;
+
+    case GFC_ISYM_RANDOM_INIT:
+      res = conv_intrinsic_random_init (code);
       break;
 
     case GFC_ISYM_SYSTEM_CLOCK:
Index: gcc/fortran/trans.h
===================================================================
--- gcc/fortran/trans.h	(revision 256351)
+++ gcc/fortran/trans.h	(working copy)
@@ -907,6 +907,8 @@ extern GTY(()) tree gfor_fndecl_sr_kind;
 extern GTY(()) tree gfor_fndecl_ieee_procedure_entry;
 extern GTY(()) tree gfor_fndecl_ieee_procedure_exit;
 
+/* RANDOM_INIT.  */
+extern GTY(()) tree gfor_fndecl_random_init;
 
 /* True if node is an integer constant.  */
 #define INTEGER_CST_P(node) (TREE_CODE(node) == INTEGER_CST)
Index: gcc/testsuite/gfortran.dg/random_init_1.f90
===================================================================
--- gcc/testsuite/gfortran.dg/random_init_1.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/random_init_1.f90	(working copy)
@@ -0,0 +1,12 @@
+! { dg-do compile } 
+program foo
+   logical a(2)
+   real x
+   call random_init(1., .false.) ! { dg-error "must be LOGICAL" }
+   call random_init(.true., 1)   ! { dg-error "must be LOGICAL" }
+   call random_number(x)
+   a = .true.
+   call random_init(a, .false.) ! { dg-error "must be a scalar" }
+   call random_init(.false., a) ! { dg-error "must be a scalar" }
+   print *, x
+end program foo
Index: gcc/testsuite/gfortran.dg/random_init_2.f90
===================================================================
--- gcc/testsuite/gfortran.dg/random_init_2.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/random_init_2.f90	(working copy)
@@ -0,0 +1,30 @@
+! { dg-do run } 
+program foo
+
+   real x(2), y(2)
+
+   call random_init(.false., .false.)
+   call random_number(x)
+   print *, x
+!   x = int(1e6*x)
+
+   call random_init(.false., .false.)
+   call random_number(y)
+   print *, y
+!   y = int(1e6*y)
+
+   if (any(x == y)) call abort
+
+   call random_init(.true., .false.)
+   call random_number(x)
+!   print *, x
+   x = int(1e6*x)
+
+   call random_init(.true., .false.)
+   call random_number(y)
+!   print *, y
+   y = int(1e6*y)
+
+   if (any(x /= y)) call abort   
+
+end program foo
Index: libgfortran/gfortran.map
===================================================================
--- libgfortran/gfortran.map	(revision 256346)
+++ libgfortran/gfortran.map	(working copy)
@@ -801,6 +801,7 @@ GFORTRAN_8 {
     _gfortran_product_r4;
     _gfortran_product_r8;
     _gfortran_rand;
+    _gfortran_random_init;
     _gfortran_random_r10;
     _gfortran_random_r16;
     _gfortran_random_r4;
Index: libgfortran/intrinsics/random.c
===================================================================
--- libgfortran/intrinsics/random.c	(revision 256346)
+++ libgfortran/intrinsics/random.c	(working copy)
@@ -44,6 +44,9 @@ see the files COPYING3 and COPYING.RUNTIME respectivel
 #include <_mingw.h> /* For __MINGW64_VERSION_MAJOR  */
 #endif
 
+extern void random_init (GFC_LOGICAL_4, GFC_LOGICAL_4, GFC_INTEGER_4);
+iexport_proto(random_init);
+
 extern void random_r4 (GFC_REAL_4 *);
 iexport_proto(random_r4);
 
@@ -927,6 +930,46 @@ random_seed_i8 (GFC_INTEGER_8 *size, gfc_array_i8 *put
 }
 iexport(random_seed_i8);
 
+
+/* random_init is used to seed the PRNG with either a default
+   set of seeds or a random set of seeds.  */
+
+void
+random_init (GFC_LOGICAL_4 repeatable, GFC_LOGICAL_4 image_distinct,
+	     GFC_INTEGER_4 hidden)
+{
+  static const uint64_t repeat_state[] = {
+    0x25b946ebc0b36173ULL, 0x31fffb768dfde2d1ULL, 0xb08dbf28a70a6b08ULL,
+    0x60b1fc7fbcc04151ULL, 0xb4018862d654635dULL, 0x5c2fc35553bb5470ULL,
+    0xd588f951b8984a2bULL, 0x060c05384e97789dULL, 0x2b992ddfa23249d6ULL,
+    0x4034650f1c98bd69ULL, 0x79267e9c00e018afULL, 0x449eb881a2869d0eULL,
+    0xe2fee08d1e670313ULL, 0x17afc3eef0f0c640ULL, 0x2002db4f8acb8a0eULL,
+    0x50cd06b1b61a6804ULL
+  };
+
+  xorshift1024star_state* rs = get_rand_state();
+
+  __gthread_mutex_lock (&random_lock);
+
+  if (repeatable)
+    {
+      /* Copy the repeat seeds.   */
+      memcpy (&rs->s, repeat_state, sizeof (repeat_state));
+      njumps = 0;
+      if (image_distinct) njumps = hidden;
+      master_init = true;
+      init_rand_state (rs, true);
+	  rs->p = 0;
+    }
+  else
+    {
+      master_init = false;
+      init_rand_state (rs, true);
+    }
+
+  __gthread_mutex_unlock (&random_lock);
+}
+iexport(random_init);
 
 #if !defined __GTHREAD_MUTEX_INIT || defined __GTHREADS
 static void __attribute__((constructor))

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] Implementation of RANDOM_INIT from F2018
  2018-01-09  0:58 ` Steve Kargl
@ 2018-01-09  1:33   ` Damian Rouson
  2018-01-09  2:03     ` Steve Kargl
  2018-01-09  2:51   ` Jerry DeLisle
  1 sibling, 1 reply; 15+ messages in thread
From: Damian Rouson @ 2018-01-09  1:33 UTC (permalink / raw)
  To: sgk, fortran, gcc-patches

I’ll be glad to test with -fcoarray=lib -lcaf_mpi with two caveats:

1. My turnaround time will probably usually be 48-72 hours for such tests.  
2. I don’t monitor this mailing list very closely so I might miss similar requests unless they are also submitted as issues on the OpenCoarrays GitHub repository.   

For clarification, are you asking for simple execution of the existing tests or do you suspect that the tests might need modification (or new tests) to exercise the -fcoarray=lib option?

Damian
On January 8, 2018 at 4:58:09 PM, Steve Kargl (sgk@troutmask.apl.washington.edu) wrote:

On Sun, Jan 07, 2018 at 06:52:22PM -0800, Steve Kargl wrote:  
>  
> I have zero knowledge about co-arrays and especially zero  
> knowledge about gfortran internals for co-arrays. I'm  
> disinclined to waste another 12 hours trying to get gfortran  
> to emit essentially a call to this_image(). See iresolve.c  
> for details.  
>  

An epiphany came to me last night, which has led to the attach  
patch. This patch should be a complete implementation of  
RANDOM_INIT.  

RANDOM_INIT takes two LOGICAL, INTENT(IN) arguments. To  
avoid library bloat, these arguments are converted/casted to  
LOGICAL(4) in trans-intrinsic.c (conv_intrinsic_random_init).  
It is also in this function, that I set up the hidden argument  
that is needed to hopefully give standard conforming behavior  
when co-arrays are involved. I, however, cannot test -fcoarray=lib  
situation. I would appreciate feedback from a co-array user.  

Boostrapped and regression tested on x86_64-*-freebsd.  
OK to commit?  

2018-01-08 Steven G. Kargl <kargl@gcc.gnu.org>  

* check.c (gfc_check_random_init): New function. Check arguments of  
random_init().  
* gfortran.h (gfc_isym_id): Add GFC_ISYM_RANDOM_INIT.  
* intrinsic.c (add_subroutines): Make random_init() an intrinsic  
subroutine.  
(gfc_check_intrinsic_standard): Check for Fortran 2018.  
* intrinsic.h: Add prototypes for gfc_check_random_init and  
gfc_resolve_random_init.  
* iresolve.c (gfc_resolve_random_init): New function. Add  
_gfortran_random_init to list of subroutines.  
* trans-decl.c: Describe gfor_fndecl_random_init.  
* trans-intrinsic.c (conv_intrinsic_random_init): New function.  
Translate random_init and added hidden argument.  
(gfc_conv_intrinsic_subroutine): Call conv_intrinsic_random_init.  
* trans.h: Declare gfor_fndecl_random_init.  

2018-01-08 Steven G. Kargl <kargl@gcc.gnu.org>  

* gfortran.dg/random_init_1.f90: New test.  
* gfortran.dg/random_init_2.f90: New test.  

2018-01-08 Steven G. Kargl <kargl@gcc.gnu.org>  

* gfortran.map: Add _gfortran_random_init to library map.  
* intrinsics/random.c (random_init): Implemenation of random_init.  

--  
steve  

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] Implementation of RANDOM_INIT from F2018
  2018-01-09  1:33   ` Damian Rouson
@ 2018-01-09  2:03     ` Steve Kargl
  2018-01-09 23:33       ` Damian Rouson
  0 siblings, 1 reply; 15+ messages in thread
From: Steve Kargl @ 2018-01-09  2:03 UTC (permalink / raw)
  To: Damian Rouson; +Cc: fortran, gcc-patches

On Mon, Jan 08, 2018 at 05:33:01PM -0800, Damian Rouson wrote:
> I’ll be glad to test with -fcoarray=lib -lcaf_mpi with two caveats:
> 
> 1. My turnaround time will probably usually be 48-72 hours for
> such tests.

Turn around time is unimportant to me.  I'm simply interested if
what I have done work or if I need to fix a bug.

> 2. I don’t monitor this mailing list very closely so I might miss
> similar requests unless they are also submitted as issues on the
> OpenCoarrays GitHub repository.

That's understandable.  There is only so much time in a day.

> For clarification, are you asking for simple execution of the
> existing tests or do you suspect that the tests might need
> modification (or new tests) to exercise the -fcoarray=lib option?

Hopefully, this clarifies the situation.  Suppose, you have a co-array
program that causes execution of 2 images, say, image0 and image1.
If the program contains

   call random_init(repeatable=.true., image_distinct=.true.)

then image0 and image1 will have distinct PRNG sequences.  Now, if you
re-run the program, then image0 and image1 will have the same distinct
sequences.  If you have 

   call random_init(.true., .false.)

image0 and image1 do not need to have distinct PRNG sequences, but
I set up gfortran to have distinct sequences.  If you re-run the
program image0 and image1 should have the same sequences.  Finally,
if you have

   call random_init(.false.,.true.)

image0 and image1 will have distinct sequence, and if you re-run the
program image and image1 will should have different sequence than 
what was seen in the previous and these are distinct.

There is one final detail, the standard says that calling random_init
in one image cannot affect the PRNG sequence in another image if
image_distinct=.false.

-- 
Steve

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] Implementation of RANDOM_INIT from F2018
  2018-01-09  0:58 ` Steve Kargl
  2018-01-09  1:33   ` Damian Rouson
@ 2018-01-09  2:51   ` Jerry DeLisle
  2018-01-09  3:21     ` Steve Kargl
  2018-01-09 17:11     ` Steve Kargl
  1 sibling, 2 replies; 15+ messages in thread
From: Jerry DeLisle @ 2018-01-09  2:51 UTC (permalink / raw)
  To: sgk, fortran, gcc-patches

On 01/08/2018 04:58 PM, Steve Kargl wrote:
> On Sun, Jan 07, 2018 at 06:52:22PM -0800, Steve Kargl wrote:
>>
>> I have zero knowledge about co-arrays and especially zero
>> knowledge about gfortran internals for co-arrays.  I'm
>> disinclined to waste another 12 hours trying to get gfortran
>> to emit essentially a call to this_image().  See iresolve.c
>> for details.
>>
> 
> An epiphany came to me last night, which has led to the attach
> patch.  This patch should be a complete implementation of
> RANDOM_INIT.
> 
> RANDOM_INIT takes two LOGICAL, INTENT(IN) arguments.  To 
> avoid library bloat, these arguments are converted/casted to
> LOGICAL(4) in trans-intrinsic.c (conv_intrinsic_random_init).
> It is also in this function, that I set up the hidden argument
> that is needed to hopefully give standard conforming behavior
> when co-arrays are involved.  I, however, cannot test -fcoarray=lib
> situation.  I would appreciate feedback from a co-array user.
> 
> Boostrapped and regression tested on x86_64-*-freebsd.
> OK to commit?
> 

Yes, Looks good Steve.  So all we need is a run test with actual =lib case.

Jerry

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] Implementation of RANDOM_INIT from F2018
  2018-01-09  2:51   ` Jerry DeLisle
@ 2018-01-09  3:21     ` Steve Kargl
  2018-01-09 17:11     ` Steve Kargl
  1 sibling, 0 replies; 15+ messages in thread
From: Steve Kargl @ 2018-01-09  3:21 UTC (permalink / raw)
  To: Jerry DeLisle; +Cc: fortran, gcc-patches

On Mon, Jan 08, 2018 at 06:51:06PM -0800, Jerry DeLisle wrote:
> On 01/08/2018 04:58 PM, Steve Kargl wrote:
> > On Sun, Jan 07, 2018 at 06:52:22PM -0800, Steve Kargl wrote:
> >>
> >> I have zero knowledge about co-arrays and especially zero
> >> knowledge about gfortran internals for co-arrays.  I'm
> >> disinclined to waste another 12 hours trying to get gfortran
> >> to emit essentially a call to this_image().  See iresolve.c
> >> for details.
> >>
> > 
> > An epiphany came to me last night, which has led to the attach
> > patch.  This patch should be a complete implementation of
> > RANDOM_INIT.
> > 
> > RANDOM_INIT takes two LOGICAL, INTENT(IN) arguments.  To 
> > avoid library bloat, these arguments are converted/casted to
> > LOGICAL(4) in trans-intrinsic.c (conv_intrinsic_random_init).
> > It is also in this function, that I set up the hidden argument
> > that is needed to hopefully give standard conforming behavior
> > when co-arrays are involved.  I, however, cannot test -fcoarray=lib
> > situation.  I would appreciate feedback from a co-array user.
> > 
> > Boostrapped and regression tested on x86_64-*-freebsd.
> > OK to commit?
> > 
> 
> Yes, Looks good Steve.  So all we need is a run test with actual =lib case.
> 

Yes.  If someone adds this to a program that creates two
images, and each image executes foo

subroutine foo
   character(len=10) name
   real x(2)
   integer fd
   write(name,'(A,I0)') 'dat', this_image()
   call random_init(repeatable=.true., image_distinct=.true.)
   call random_number(x)
   open(newunit=fd,file=name)
   write(fd,*) x
   close(fd)
end program  

then dat0 and dat1 will contain distinct numbers, and everytime
the program executes the new dat0 and new dat1 should match the
old dat0 and dat1.

If repeatable=.false., then dat0 and dat1 will still be distinct
sequences.  Repeated execution of the program will cause the new
dat0 and new dat1 to not match the old dat0 and old dat1.

-- 
Steve

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] Implementation of RANDOM_INIT from F2018
  2018-01-09  2:51   ` Jerry DeLisle
  2018-01-09  3:21     ` Steve Kargl
@ 2018-01-09 17:11     ` Steve Kargl
  1 sibling, 0 replies; 15+ messages in thread
From: Steve Kargl @ 2018-01-09 17:11 UTC (permalink / raw)
  To: Jerry DeLisle; +Cc: fortran, gcc-patches

On Mon, Jan 08, 2018 at 06:51:06PM -0800, Jerry DeLisle wrote:
> On 01/08/2018 04:58 PM, Steve Kargl wrote:
> > 
> > Boostrapped and regression tested on x86_64-*-freebsd.
> > OK to commit?
> > 
> 
> Yes, Looks good Steve.  So all we need is a run test with actual =lib case.
> 

Just realized that I forgot to update the documentation.
I'll add a RANDOM_INIT section before committing.

-- 
Steve

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] Implementation of RANDOM_INIT from F2018
  2018-01-09  2:03     ` Steve Kargl
@ 2018-01-09 23:33       ` Damian Rouson
  2018-01-10  1:10         ` Steve Kargl
  0 siblings, 1 reply; 15+ messages in thread
From: Damian Rouson @ 2018-01-09 23:33 UTC (permalink / raw)
  To: sgk; +Cc: fortran, gcc-patches

Hi Steve,

Here are the results of compiling with the OpenCoarrays “caf” compiler wrapper, which uses -fcoarray=lib -lcaf_mpi:

1. random_init(repeatable=.true., image_distinct=.true.) gives repeatable sequences that are distinct on each image.
2. random_init(.true., .false.) gives repeatable sequences that are identical on all images.
3. random_init(.false.,.true.) gives non-repeatable sequences that are distinct on each image.
4. random_init(.false.,.false.) gives non-repeatable sequences that are distinct on each image.

The behavior with test 2 differs from the description in the email below. I hope this is helpful.  I can provide the raw output if so desired. 

In case it’s of interest, there’s a script in OpenCoarrays that checks out the trunk, applies a provided patch to it, and then does a non-bootstrap build of the patched trunk, MPICH, and OpenCoarrays.  These were my steps:

git clone https://github.com/sourceryinstitute/opencoarrays
cd opencoarrays
./developer-scripts/patched-trunk-instal.sh random_init.diff
source prerequisites/installations/setup.sh
caf repeatable-distinct.f90
cafrun -n 4 ./a.out

If you decide to try this, please let me know.  I can edit the above script to give an option for multithreaded builds to speed things up quite a bit.

Damian


On January 8, 2018 at 6:03:26 PM, Steve Kargl (sgk@troutmask.apl.washington.edu) wrote:

On Mon, Jan 08, 2018 at 05:33:01PM -0800, Damian Rouson wrote:  
> I’ll be glad to test with -fcoarray=lib -lcaf_mpi with two caveats:  
>  
> 1. My turnaround time will probably usually be 48-72 hours for  
> such tests.  

Turn around time is unimportant to me. I'm simply interested if  
what I have done work or if I need to fix a bug.  

> 2. I don’t monitor this mailing list very closely so I might miss  
> similar requests unless they are also submitted as issues on the  
> OpenCoarrays GitHub repository.  

That's understandable. There is only so much time in a day.  

> For clarification, are you asking for simple execution of the  
> existing tests or do you suspect that the tests might need  
> modification (or new tests) to exercise the -fcoarray=lib option?  

Hopefully, this clarifies the situation. Suppose, you have a co-array  
program that causes execution of 2 images, say, image0 and image1.  
If the program contains  

call random_init(repeatable=.true., image_distinct=.true.)  

then image0 and image1 will have distinct PRNG sequences. Now, if you  
re-run the program, then image0 and image1 will have the same distinct  
sequences. If you have  

call  random_init(.true., .false.) 

image0 and image1 do not need to have distinct PRNG sequences, but  
I set up gfortran to have distinct sequences. If you re-run the  
program image0 and image1 should have the same sequences. Finally,  
if you have  

call random_init(.false.,.true.)  

image0 and image1 will have distinct sequence, and if you re-run the  
program image and image1 will should have different sequence than  
what was seen in the previous and these are distinct.  

There is one final detail, the standard says that calling random_init  
in one image cannot affect the PRNG sequence in another image if  
image_distinct=.false.  

--  
Steve  

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] Implementation of RANDOM_INIT from F2018
  2018-01-09 23:33       ` Damian Rouson
@ 2018-01-10  1:10         ` Steve Kargl
  2018-01-12  0:54           ` Steve Kargl
  0 siblings, 1 reply; 15+ messages in thread
From: Steve Kargl @ 2018-01-10  1:10 UTC (permalink / raw)
  To: Damian Rouson; +Cc: fortran

On Tue, Jan 09, 2018 at 03:33:24PM -0800, Damian Rouson wrote:
> Hi Steve,
> 
> Here are the results of compiling with the OpenCoarrays “caf”
> compiler wrapper, which uses -fcoarray=lib -lcaf_mpi:
> 
> 1. random_init(repeatable=.true., image_distinct=.true.) gives
> repeatable sequences that are distinct on each image.

Good.  I think that this is the intent of the Standard.  This
also shows the call that I generated to _gfortran_caf_this_image()
is working.

> 2. random_init(.true., .false.) gives repeatable sequences that
> are identical on all images.

I have to think about this one.  This may be permissible.

> 3. random_init(.false.,.true.) gives non-repeatable sequences
> that are distinct on each image.
> 4. random_init(.false.,.false.) gives non-repeatable sequences
> that are distinct on each image.

Good.  I believe 3 and 4 match the intent of the standard.

> The behavior with test 2 differs from the description in the
> email below.  I hope this is helpful.  I can provide the raw
> output if so desired.

Raw output won't be necessary.  With regards to 2. I may have
misread the standard (a not so uncommon problem I have).  The
wording is about *the seeds* not the generated sequences.

   IMAGE_DISTINCT shall be a logical scalar. It is an INTENT(IN)
   argument.

The above is the easy part.

   If it has the value true, the seed accessed by the PNG is set
   to a processor-dependent value that is distinct from the value
   that would be set by a call to RANDOM_INIT by another image.

I interpret the above requirement to mean that the distinct seeds
will give distinct sequences of RN in the images.

Internally, each image uses an independent instance of the same
PRNG algorithm with a 2**1024-1 period.  The PRNG is seeded with
a single seed, but the sequence of RN is determined by a jump
function.  According to the code (and paper that Janne followed)
the jump function "can be used to generate 2**512 non-overlapping
subsequences for parallel computations."  What I don't know is
what happed if one inspects the seeds in each image.  Can you 
change your test 1 to spit out the seeds immediately after the
call to random_init()?  Something along the lines

   call random_init(repeatable=.true., image_distinct=.true.)
   call random_seed(get=seeds)
   write(*,*) seeds
 
I'm hoping that the jump function makes things appear as-if 
distinct seeds are used.

   If it has the value false, the value to which the seed is set
   does not depend on which image calls RANDOM_INIT.

This automatically satisfies by gfortran because each image has
an independent instance of the PRNG.  It appears to address the
possibility of a single global RNG (such as a hardware RNG) where
each image draws RN from a single sequence.


-- 
Steve

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] Implementation of RANDOM_INIT from F2018
  2018-01-10  1:10         ` Steve Kargl
@ 2018-01-12  0:54           ` Steve Kargl
  2018-01-12  3:11             ` Damian Rouson
  0 siblings, 1 reply; 15+ messages in thread
From: Steve Kargl @ 2018-01-12  0:54 UTC (permalink / raw)
  To: Damian Rouson; +Cc: fortran

On Tue, Jan 09, 2018 at 05:10:42PM -0800, Steve Kargl wrote:
> On Tue, Jan 09, 2018 at 03:33:24PM -0800, Damian Rouson wrote:
> > Hi Steve,
> > 
> > Here are the results of compiling with the OpenCoarrays “caf”
> > compiler wrapper, which uses -fcoarray=lib -lcaf_mpi:
>

Well, I was going to try to save you time and me more
headaches than I've already caused on the J3 mailing
list.  Installation of OpenCoarray is broken beyond my
patience.

-- 
Steve

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] Implementation of RANDOM_INIT from F2018
  2018-01-12  0:54           ` Steve Kargl
@ 2018-01-12  3:11             ` Damian Rouson
  2018-01-12  4:17               ` Steve Kargl
  0 siblings, 1 reply; 15+ messages in thread
From: Damian Rouson @ 2018-01-12  3:11 UTC (permalink / raw)
  To: sgk; +Cc: fortran

I have no idea to what you're referring and I would have at least hoped for
a nicer response after investing the time of trying to be helpful.
Hopefully I'll remember to not make that mistake again.  There many ways to
install OpenCoarrays. I only mentioned one. Probably the simplest is
package management, but I didn't want to suggest something that would
require installing a package manager before installing OpenCoarrays so I
suggested our installer, which I know many people use successfully and
which I run refukarkrh, including on bare metal hundreds of times. We've
attempted to respond to all the many ways people prefer to install and
attempted to support a multitude of options.  A simple issue report would
be a lot more helpful and nicer than "broken beyond my patience."

On January 11, 2018 at 4:53:55 PM, Steve Kargl (
sgk@troutmask.apl.washington.edu) wrote:

> On Tue, Jan 09, 2018 at 05:10:42PM -0800, Steve Kargl wrote:
>
> On Tue, Jan 09, 2018 at 03:33:24PM -0800, Damian Rouson wrote:
>
> Hi Steve,
>
> Here are the results of compiling with the OpenCoarrays “caf”
> compiler wrapper, which uses -fcoarray=lib -lcaf_mpi:
>
>
>
> Well, I was going to try to save you time and me more
> headaches than I've already caused on the J3 mailing
> list. Installation of OpenCoarray is broken beyond my
> patience.
>
> --
> Steve
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] Implementation of RANDOM_INIT from F2018
  2018-01-12  3:11             ` Damian Rouson
@ 2018-01-12  4:17               ` Steve Kargl
  2018-01-12  5:52                 ` Damian Rouson
  2018-01-16 20:30                 ` Damian Rouson
  0 siblings, 2 replies; 15+ messages in thread
From: Steve Kargl @ 2018-01-12  4:17 UTC (permalink / raw)
  To: Damian Rouson; +Cc: fortran

I apologies for letting my frustration boil over in email.

It shouldn't take 4+ hours to wade through documentation
to install a piece of software.  The documentation in the
release tar file is in some strange not-quite HTML language.

One example of the issues.  I have cmake 3.10.1 installed.
cmake is available through my default path.  install.sh wanted
to download and use (install?) cmake 3.4.0.  install.sh --help
tells me that one can use "-m [arg]" or "--with-cmake [arg]",
but there is no description of what arg ought to be.  Should
it be /usr/local or /usr/local/bin or /usr/local/bin/cmake?

What is even more frustrating is the "-f [arg]" or 
"--with-fortran-compiler [arg]" option.  At least one can infer
that arg is the Fortran compiler or is it?  My Fortran compiler
is invoked from a Bournce shell script, gfcx, that insures
gfortran picks up the right libraries.  I used gfcx to build
OpenMPI 3.0.0 and mpfi90 and mpifort correctly wrap gfcx.  It
didn't matter if I set arg to $HOME/bin/gfcx or $HOME/work/bin/mpif90
(or mpifort), cmake died with an *emergency error* because gfortran
was not "properly wrapped with MPI".  Oddly, the command line
reported by cmake was exactly what one expects from mpif90.

-- 
steve


On Thu, Jan 11, 2018 at 07:11:25PM -0800, Damian Rouson wrote:
> I have no idea to what you're referring and I would have at least hoped for
> a nicer response after investing the time of trying to be helpful.
> Hopefully I'll remember to not make that mistake again.  There many ways to
> install OpenCoarrays. I only mentioned one. Probably the simplest is
> package management, but I didn't want to suggest something that would
> require installing a package manager before installing OpenCoarrays so I
> suggested our installer, which I know many people use successfully and
> which I run refukarkrh, including on bare metal hundreds of times. We've
> attempted to respond to all the many ways people prefer to install and
> attempted to support a multitude of options.  A simple issue report would
> be a lot more helpful and nicer than "broken beyond my patience."
> 
> On January 11, 2018 at 4:53:55 PM, Steve Kargl (
> sgk@troutmask.apl.washington.edu) wrote:
> 
> > On Tue, Jan 09, 2018 at 05:10:42PM -0800, Steve Kargl wrote:
> >
> > On Tue, Jan 09, 2018 at 03:33:24PM -0800, Damian Rouson wrote:
> >
> > Hi Steve,
> >
> > Here are the results of compiling with the OpenCoarrays “caf”
> > compiler wrapper, which uses -fcoarray=lib -lcaf_mpi:
> >
> >
> >
> > Well, I was going to try to save you time and me more
> > headaches than I've already caused on the J3 mailing
> > list. Installation of OpenCoarray is broken beyond my
> > patience.
> >
> > --
> > Steve
> >

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] Implementation of RANDOM_INIT from F2018
  2018-01-12  4:17               ` Steve Kargl
@ 2018-01-12  5:52                 ` Damian Rouson
  2018-01-12  6:57                   ` Steve Kargl
  2018-01-16 20:30                 ` Damian Rouson
  1 sibling, 1 reply; 15+ messages in thread
From: Damian Rouson @ 2018-01-12  5:52 UTC (permalink / raw)
  To: sgk; +Cc: fortran

Thanks for the details. I will copy this feedback into an issue on the
OpenCoarrays repository and we will address each concern. My guess is that
the documentation to which you're referring is in GitHub-flavored Markdown
(.md file name extensions). If so, then hopefully there's a comment in the
first line of each file stating that the file is best viewed in a browser
at a provided URL.  Markdown is a server-side technology so it renders
correctly when served by the web site that hosts it.  Markdown is intended
to be more lightweight and readable without a browser than HTML, but I
think your feedback is telling me that we might have gone too far in using
lots of features that make the document look nicer online but look
confusing when viewed as raw text.

One of the most difficult challenges has been trying to support everyone's
preferred installation method yet keep the documentation terse, which is
why the documentation is not at all terse.  For every installation method
we offer, I know specific users who swear by that one approach to the
exclusion of all others.  We have users who won't touch CMake or our bash
script and will only use a static Makefile.  We have users who will only
use package management or even will only use one specific package manager
even if their platform supports several. And we have users who will only
use our bash installer.   Maybe we should stop trying to be all things to
all people.

The good news is that I hope this will all be moot in a few months. A
graduate student is coming to work with me for 12 weeks this Spring and is
keen on finishing the great work Jerry did to integrate the downloading and
building of OpenCoarrays into the GCC build system. After that, it should
be the case that anyone who installs gfortran by whatever method they
choose will automatically get OpenCoarrays installed too.  Then the only
reason anyone would ever need to install OpenCoarrays separately would be
if they want to do something unusual such as use OpenSHMEM instead of MPI.


Damian

On January 11, 2018 at 8:16:58 PM, Steve Kargl (
sgk@troutmask.apl.washington.edu) wrote:

> I apologies for letting my frustration boil over in email.
>
> It shouldn't take 4+ hours to wade through documentation
> to install a piece of software. The documentation in the
> release tar file is in some strange not-quite HTML language.
>
> One example of the issues. I have cmake 3.10.1 installed.
> cmake is available through my default path. install.sh wanted
> to download and use (install?) cmake 3.4.0. install.sh --help
> tells me that one can use "-m [arg]" or "--with-cmake [arg]",
> but there is no description of what arg ought to be. Should
> it be /usr/local or /usr/local/bin or /usr/local/bin/cmake?
>
> What is even more frustrating is the "-f [arg]" or
> "--with-fortran-compiler [arg]" option. At least one can infer
> that arg is the Fortran compiler or is it? My Fortran compiler
> is invoked from a Bournce shell script, gfcx, that insures
> gfortran picks up the right libraries. I used gfcx to build
> OpenMPI 3.0.0 and mpfi90 and mpifort correctly wrap gfcx. It
> didn't matter if I set arg to $HOME/bin/gfcx or $HOME/work/bin/mpif90
> (or mpifort), cmake died with an *emergency error* because gfortran
> was not "properly wrapped with MPI". Oddly, the command line
> reported by cmake was exactly what one expects from mpif90.
>
> --
> steve
>
>
> On Thu, Jan 11, 2018 at 07:11:25PM -0800, Damian Rouson wrote:
>
> I have no idea to what you're referring and I would have at least hoped
> for
> a nicer response after investing the time of trying to be helpful.
> Hopefully I'll remember to not make that mistake again. There many ways to
> install OpenCoarrays. I only mentioned one. Probably the simplest is
> package management, but I didn't want to suggest something that would
> require installing a package manager before installing OpenCoarrays so I
> suggested our installer, which I know many people use successfully and
> which I run refukarkrh, including on bare metal hundreds of times. We've
> attempted to respond to all the many ways people prefer to install and
> attempted to support a multitude of options. A simple issue report would
> be a lot more helpful and nicer than "broken beyond my patience."
>
> On January 11, 2018 at 4:53:55 PM, Steve Kargl (
> sgk@troutmask.apl.washington.edu) wrote:
>
> On Tue, Jan 09, 2018 at 05:10:42PM -0800, Steve Kargl wrote:
>
> On Tue, Jan 09, 2018 at 03:33:24PM -0800, Damian Rouson wrote:
>
> Hi Steve,
>
> Here are the results of compiling with the OpenCoarrays “caf”
> compiler wrapper, which uses -fcoarray=lib -lcaf_mpi:
>
>
>
> Well, I was going to try to save you time and me more
> headaches than I've already caused on the J3 mailing
> list. Installation of OpenCoarray is broken beyond my
> patience.
>
> --
> Steve
>
>
> --
> Steve
> 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4
> 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
>

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] Implementation of RANDOM_INIT from F2018
  2018-01-12  5:52                 ` Damian Rouson
@ 2018-01-12  6:57                   ` Steve Kargl
  0 siblings, 0 replies; 15+ messages in thread
From: Steve Kargl @ 2018-01-12  6:57 UTC (permalink / raw)
  To: Damian Rouson; +Cc: fortran

On Thu, Jan 11, 2018 at 09:51:08PM -0800, Damian Rouson wrote:
>
> The good news is that I hope this will all be moot in a few months. A
> graduate student is coming to work with me for 12 weeks this Spring and is
> keen on finishing the great work Jerry did to integrate the downloading and
> building of OpenCoarrays into the GCC build system. After that, it should
> be the case that anyone who installs gfortran by whatever method they
> choose will automatically get OpenCoarrays installed too.  Then the only
> reason anyone would ever need to install OpenCoarrays separately would be
> if they want to do something unusual such as use OpenSHMEM instead of MPI.
> 

This would be most welcomed by me.

And, again apologies.  Part of imy frustration also stems
from interaction with J3 members where I've expressed a
concern thatthe F2018 is codifying implementation detail.

-- 
Steve

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [PATCH] Implementation of RANDOM_INIT from F2018
  2018-01-12  4:17               ` Steve Kargl
  2018-01-12  5:52                 ` Damian Rouson
@ 2018-01-16 20:30                 ` Damian Rouson
  1 sibling, 0 replies; 15+ messages in thread
From: Damian Rouson @ 2018-01-16 20:30 UTC (permalink / raw)
  To: sgk; +Cc: fortran

Based on the email below, a list of suggested updates to our installation documentation and installer script has been incorporated in issue #478 on the OpenCoarrays repository:

https://github.com/sourceryinstitute/OpenCoarrays/issues/478

Please feel free to post any related feedback in a comment at the above link or reply to this email and I’ll incorporate any feedback received into a comment on the issue page. 

Damian


On January 11, 2018 at 8:17:02 PM, Steve Kargl (sgk@troutmask.apl.washington.edu) wrote:

I apologies for letting my frustration boil over in email.  

It shouldn't take 4+ hours to wade through documentation  
to install a piece of software. The documentation in the  
release tar file is in some strange not-quite HTML language.  

One example of the issues. I have cmake 3.10.1 installed.  
cmake is available through my default path. install.sh wanted  
to download and use (install?) cmake 3.4.0. install.sh --help  
tells me that one can use "-m [arg]" or "--with-cmake [arg]",  
but there is no description of what arg ought to be. Should  
it be /usr/local or /usr/local/bin or /usr/local/bin/cmake?  

What is even more frustrating is the "-f [arg]" or  
"--with-fortran-compiler [arg]" option. At least one can infer  
that arg is the Fortran compiler or is it? My Fortran compiler  
is invoked from a Bournce shell script, gfcx, that insures  
gfortran picks up the right libraries. I used gfcx to build  
OpenMPI 3.0.0 and mpfi90 and mpifort correctly wrap gfcx. It  
didn't matter if I set arg to $HOME/bin/gfcx or $HOME/work/bin/mpif90  
(or mpifort), cmake died with an *emergency error* because gfortran  
was not "properly wrapped with MPI". Oddly, the command line  
reported by cmake was exactly what one expects from mpif90.  

--  
steve  


On Thu, Jan 11, 2018 at 07:11:25PM -0800, Damian Rouson wrote:  
> I have no idea to what you're referring and I would have at least hoped for  
> a nicer response after investing the time of trying to be helpful.  
> Hopefully I'll remember to not make that mistake again. There many ways to  
> install OpenCoarrays. I only mentioned one. Probably the simplest is  
> package management, but I didn't want to suggest something that would  
> require installing a package manager before installing OpenCoarrays so I  
> suggested our installer, which I know many people use successfully and  
> which I run refukarkrh, including on bare metal hundreds of times. We've  
> attempted to respond to all the many ways people prefer to install and  
> attempted to support a multitude of options. A simple issue report would  
> be a lot more helpful and nicer than "broken beyond my patience."  
>  
> On January 11, 2018 at 4:53:55 PM, Steve Kargl (  
> sgk@troutmask.apl.washington.edu) wrote:  
>  
> > On Tue, Jan 09, 2018 at 05:10:42PM -0800, Steve Kargl wrote:  
> >  
> > On Tue, Jan 09, 2018 at 03:33:24PM -0800, Damian Rouson wrote:  
> >  
> > Hi Steve,  
> >  
> > Here are the results of compiling with the OpenCoarrays “caf”  
> > compiler wrapper, which uses -fcoarray=lib -lcaf_mpi:  
> >  
> >  
> >  
> > Well, I was going to try to save you time and me more  
> > headaches than I've already caused on the J3 mailing  
> > list. Installation of OpenCoarray is broken beyond my  
> > patience.  
> >  
> > --  
> > Steve  
> >  

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

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2018-01-16 20:30 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-08  2:52 [PATCH] Implementation of RANDOM_INIT from F2018 Steve Kargl
2018-01-09  0:58 ` Steve Kargl
2018-01-09  1:33   ` Damian Rouson
2018-01-09  2:03     ` Steve Kargl
2018-01-09 23:33       ` Damian Rouson
2018-01-10  1:10         ` Steve Kargl
2018-01-12  0:54           ` Steve Kargl
2018-01-12  3:11             ` Damian Rouson
2018-01-12  4:17               ` Steve Kargl
2018-01-12  5:52                 ` Damian Rouson
2018-01-12  6:57                   ` Steve Kargl
2018-01-16 20:30                 ` Damian Rouson
2018-01-09  2:51   ` Jerry DeLisle
2018-01-09  3:21     ` Steve Kargl
2018-01-09 17:11     ` Steve Kargl

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).