This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gfortran] Implementation SYSTEM_CLOCK intrinsic subroutine

On Fri, May 14, 2004 at 06:12:55PM +0100, Paul Brook wrote:
> A few issues:
> +try
> +gfc_check_system_clock (gfc_expr * count, gfc_expr * count_rate,
> +                        gfc_expr * count_max)
> +{
> The standard specifies that all arguments must be of *default* integer type. 
> Also, the second parameter of *_check should be the argument number that is 
> being checked (ie. not always zero).


> We may wish to allow other integer kinds an an extension, but we must still 
> ensure that all arguments have the same type, otherwise bad things will 
> happen.

Fixed.  I used same_type_check() to ensure that the types are
compatible.  Note, in the upcoming Fortran 200X standard the
type of COUNT_RATE can be integer or real, so our implementation
will soon be out-of-date.

> Depending on the type of checking done above, the resolved name may just be 
> based on gfc_default_integer_kind().

I tried using gfc_default_integer_kind(), but the -I8 option appears broken.

> #elif HAVE_TIME_H
> Should be #elif defined(HAVE_TIME_H)


> void
> __system_clock_1(int *count, int *count_rate, int *count_max)
> Should be declared static.

Fixed by attrition.

>           t = ((double)tp.tv_sec + tp.tv_usec * 1.e-6) * TCK;
>           if (t - t0 < (double)INT_MAX)
>             *count = (int) (t - t0);
>           else
>             {
>                *count = 0;
>                t0 = t;
>             }
> This is wrong. In the case where t - t0 > INT_MAX we should wrap, not truncate 
> to 0. This behaviour is specified by the standard.


> I don't really like the use of double, though I guess I could cope. It's not 
> all that hard to perform these calculations with integer arithmetic.

I retained double for now.  I'm still considering an integer implementation,
but I could not convince myself that the algorithm I had was robust.

>        t1 = TCK * (t - init_time);
>        if (t1 < (time_t) INT_MAX)
>          *count = (int) t1;
>        else
>          {
>             *count = 0;
>             init_time = t;
>          }
> Likewise. Also t1 may be negative, and you're also assuming
> sizeof(time_t) >= sizeof(INT_MAX). You shouldn't be multiplying by TCK.
>     if (count >= 0)							\
>       *__count = (GFC_INTEGER_##KIND) count;				\
>     else								\
>       *__count = - GFC_INTEGER_##KIND##_HUGE;				\
> This breaks when sizeof(int) > KIND.

This should be solved by the new implementation in system_clock.c.
Things to note:

  (1)  I solved the "call system_clock" problem where no arguments
       are given by introducing prefix(system_clock_nop).  I suspect
       that I need to add a __inline__ directive to this, so the 
       middle/back end optimizes the call way.  But, I've never
       __inline__ and its semantics are unclear to me.

  (2)  prefix(system_clock_4) and prefix(system_clock_8) are no longer
       generated by macro substitution.  If a system clock is not 
       available then the functions need to return -HUGE(0_KIND).  This
       was causing sizeof() problems.  

Two files are attached, the diff and system_clock.c.

Changelog for gcc/libgfortran

  2004-05-15  Steven G. Kargl  <>

  * Add intrinsics/system_clock.c
  * intrinsics/system_clock.c: New file
  * regenerated
  * aclocal.m4: regenerated

Changelog for gcc/gcc/fortran

  2004-05-15  Steven G. Kargl  <>

  *check.c (gfc_check_system_clock): New function.
  *intrinsic.c (add_sym_3s): New function, use it.
  *intrinsic.h (gfc_check_system_clock,gfc_resolve_system_clock): Add prototypes
  *iresolve.c (gfc_resolve_system_clock): New function
  *check.c, intrinsic.c, iresolve.c: Update copyright date


Attachment: sgk.diff
Description: Text document

Attachment: system_clock.c
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]