Relaxing argument requiremens on SYSTEM_CLOCK

[Steve Kargl]

On Sat, Jun 07, 2014 at 12:44:19AM +0200, FX wrote:
> Since Fortran 2003, SYSTEM_CLOCK accepts all kinds (and kind
> combinations) of integer arguments, as well as real COUNT_RATE
> arguments. To handle this, and avoid explosion of number of
> nearly-identical library routines, type conversions need to be
> handled in the front-end. I?ve followed the approach of keeping
> the two existing library versions, and picking the best
> depending on the kinds of arguments passed.

Note, there is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61429
which I grabbed before you posted your patch.  I like your
approach/patch much better than the patch I had hacked up.

> The patch attached tries to do so. It?s my first time writing
> intrinsic subroutine translation code (in trans-intrinsic.c), and
> it?s less clean than intrinsic function translation? so I would
> really welcome a detailed review of the patch, because I might
> have messed things slightly, or included unnecessary code. For
> example, is it really needed to have pairs of gfc_init_se/gfc_conv_expr
> calls for each of the arguments, for this non-elemental routine?
> I?m not sure at all.

I'm not at all confident in my own understanding of the trans-*.c
files, but my understanding of your patch suggest you have everything
about right.  Tobias or Janne may have other comments.  I do note 
two issues.  In this chunk, 

@@ -2791,7 +2793,9 @@ static void
 gfc_build_intrinsic_function_decls (void)
 {
   tree gfc_int4_type_node = gfc_get_int_type (4);
+  tree gfc_pint4_type_node = build_pointer_type (gfc_int4_type_node);
   tree gfc_int8_type_node = gfc_get_int_type (8);
+  tree gfc_pint8_type_node = build_pointer_type (gfc_int4_type_node);

shouldn't the 2nd gfc_int4_type_node be gfc_int8_type_node?

Also, is this line a leftoever from debugging (and can be removed)?

+extern void debug_tree (tree);

> PS: by my reading of the standard, it?s not exactly clear that
> what we currently do, and continue to do with my patch (varying
> the clock rate returned depending on argument types), is
> actually allowed

I don't understand this comment.  CLOCK_RATE is an intent(out) entity.
The standard says that "it is is assigned a processor-dependent
approximation to the number of processor clock counts per second, or
zero if there is no clock."  Given modern hardware where cpu throttling
is common, it would seem to me that the clock rate can varying.

-- 
Steve