This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [patch,fortran] Support type real for count_rate in system_clock (PR28484)
- From: Paul Brook <paul at codesourcery dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>, Tobias Burnus <burnus at net-b dot de>, Brooks Moses <bmoses at stanford dot edu>, fortran at gcc dot gnu dot org
- Date: Sat, 28 Oct 2006 16:34:34 +0100
- Subject: Re: [patch,fortran] Support type real for count_rate in system_clock (PR28484)
- Organization: CodeSourcery
- References: <45428A72.60101@net-b.de> <454328C5.7080107@net-b.de> <20061028165340.b7z1vjki5cks8sg8@webmail.physik.uni-muenchen.de>
> > 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!
>
> One could emit the necessary type conversions, i.e. only implement
> system_clock (int4, int4, int4)
> in the library and then convert the parameters appropriately for all
> other combinations, e.g. translating
> system_clock (int4, int8, int16)
> as
> int4 t1 = int8
> int4 t2 = int16
> system_clock (int4, t1, t2)
> int8 = t1
> int16 = t2
> (I don't know the semantics of system_clock off the top of my head,
> the sensible sequence and choice of types depends on the INTENTs and
> the possible values of the arguments)
I think this is definitely the way to go.
IMHO trying to enumerate all the possible combinations of argument types and
provide library functions for them is a bad idea. It's feasible (and
sometimes necessary) for functions with only a single argument type, but not
when multiple types are involved.
Paul