This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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: Relaxing argument requiremens on SYSTEM_CLOCK


Forgot the patch, here it is…

--------------

> 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.
> 
> 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.
> 
> Anyway, the patch bootstraps and regtests on x86_64-apple-darwin13, and passes a few tests I’ve written. Once I have the approach and code reviewed, I’ll make a formal submission with full testcases and documentation.
> 
> Thanks in advance.
> FX
> 
> 
> 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

Attachment: patch
Description: Binary data


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