[patch,fortran] Support type real for count_rate in system_clock (PR28484)

[Steve Kargl]

On Sat, Oct 28, 2006 at 11:54:13AM +0200, Tobias Burnus wrote:
> Hi,
> 
> Brooks Moses wrote:
> > Steve Kargl wrote:
> >> On Sat, Oct 28, 2006 at 12:38:42AM +0200, Tobias Burnus wrote:
> >> You'll need to implement the real(10), real(16), and integer(16)
> >> versions.  If gfortran (on some target) provides any or all of
> >> these types, then we need intrinsic procedures.
> >
> > Indeed.  To clarify that, the Fortran Standard says that the
> > intrinsics can be called with any real or integer kind, and so not
> > supplying all intrinsics for all supported kinds would mean that the
> > compiler isn't standard-conforming.
> 
> Should one also implement
>    system_clock(int4, int8, int16)
> that is: Mixing all different integer kinds for system_clock? Currently,
> the integer have to be all of the same kind.
> Doing so gives then in total 3*3*3 = 27 integer and 4*3*3 = 36
> real/integer combinations, i.e. 63 combinations!
> 

Unfortunately, yes.  The standard does not require the arguments
to be the same.  It's been a while since I looked at the system_clock
implementation, but we probably want two master internal system_clock
routines and bunch of wrappers.

void
prefix(system_clock_iX_iY_iZ)(INTEGER_X *clock, INTEGER_Y *clock_rate, 
       INTEGER_Z *clock_max)
{
   long clk, rate, cmax;

   internal_system_clock(&clk, &rate, &cmax);
   
   if (clock) clock = clk;
   if (clock_rate) = clock_rate;
   if (clock_max) = cmax;
}

Here, X, Y, Z take on the values 1, 2, 4, 8, and 16.  Of course, 
we would need something similar for REAL(kind=W) clock_rate.
Fortunately, the file can be generated once using a scripting
languange.

As noted elsewhere, this problem is not isolated to system_clock.

-- 
Steve