hooking a new intrinsic subroutine?

[Lars Segerlund]

 I'm looking into the failure of the random_seed(put=seed) call now, however this used to work so I am a bit amazed since some of my old test programs now fail, ( they used to work ) , I probably have to make a real testsuite.

 I don't have much time this week to look at it but it's in my pipeline, it can't be very hard since it have worked before.

 / Lars Segerlund.

On Mon, 19 Apr 2004 09:34:29 +0200
Lars Segerlund <lars.segerlund@comsys.se> wrote:

> 
>  Which 'valid' tests fails for the random_XXX functions ? I thought I had taken care of the error processing, ( I do generate an error but for invalid input ).
> 
>  / Lars Segerlund.
> 
> 
> On Sun, 18 Apr 2004 11:50:34 -0700
> Steve Kargl <sgk@troutmask.apl.washington.edu> wrote:
> 
> > On Sun, Apr 18, 2004 at 07:20:36PM +0100, Paul Brook wrote:
> > > On Sunday 18 April 2004 05:58, Steve Kargl wrote:
> > > > Gang,
> > > >
> > > > Are there any simply to follow rules on hooking up a new
> > > > intrinsic subroutine to gfortran?  I have the guts of
> > > > date_and_time() implemented and system_time() will be
> > > > done shortly.  I was going to emulate how random_seed()
> > > > and random_number() are implemented, but unfortunately
> > > > these procedures are broken on FreeBSD.
> > > 
> > > Last time I looked we didn't handle optional arguments in intrinsic 
> > > subroutines properly. Specifically we don't pass the character length 
> > > parameters for absent optional arguments.
> > 
> > This explains why my random_XXX() test fails.  My test tries
> > these intrinsics with all possible combinations of using the
> > optional arguments.
> > 
> > > My preferred solution would be to fix this (no particular ideas how, sorry), 
> > > and resolve each of the two intrinsics you mention to a single library call.
> > 
> > I haven't looked at how the FE parses the calls.  If we take
> > system_clock([count],[count_rate],[count_max]) as an example,
> > I had hope that "call system_clock(count_rate=rate)" would
> > yield _gfortran_system_clock_4(NULL,*rate,NULL).  My system_clock
> > ingores the NULL arguments.
> > 
> > > The alternative would be to resolve to different library calls based on the 
> > > presence/absence of arguments. This has the potential to get really ugly if 
> > > we start adding extra character based intrinsic subroutines, so I'd prefer 
> > > not to go this route.
> > 
> > Yes, this can get real ugly. date_and_time() has 4 argument (3 of
> > type CHARACTER and one an 8 element integer array).  That would
> > explain to 24 subroutines.
> > 
> > -- 
> > Steve