Re: [gfortran] PATCH implement g77 intrinsics

[François-Xavier Coudert<Francois-Xavier dot Coudert at lcp dot u-psud dot fr>]

Thanks for your comments...

> > 	* gcc/fortran/check.c, gcc/fortran/gfortran.h,
> > 	  gcc/fortran/intrinsic.c, gcc/fortran/intrinsic.h,
> > 	  gcc/fortran/iresolve.c, gcc/fortran/trans-intrinsic.c:
> > 	  add support for resolving and checking arguments for the
> > 	  new intrinsics.
> >    
>
> Different files go on different lines in the ChangeLog, and yes, you have to
> list all functions.
>  
I'll do that.

> - I'm wondering if it wouldn't be better to use the same check functions for
> functions which take the same set of arguments.
>  
Well, it wouldn't be worse, that's sure. But since the list of 
intrinsics is not infinite (and we're approaching the end), I don't 
think this is really critical.

> - Instead of implementing different intrinsics for different integer kinds,
> you could insert a type conversion during resolution, see e.g.
> gfc_resolve_besn.  I don't think anybody will complain about not being able to
> call sleep with an argument > 2**32 :-)
>  
Different integer kinds are just a matter of copy-pasting ;-)

> I doubt these tests are portable, so maybe we shouldn't run these tests on
> some platforms (Windows, e.g.)
>  
We don't actually run them, but only compile them. I hesitated before 
choosing this, but I think the most important thing for intrinsics is 
their interaction with the compiler (that is, resolving and checking) 
and not the actual library code (which, in fact, is just glue for Unix 
system calls).

> I recall Steve saying that he was writing documentation for some of the
> intrinsics he has implemented.  Can you add documentation for the intrinsics
> you implemented (possibly taking it from g77), once there's a place to put it?
>  
Yes, if I'm told where, I guess it doesn't exceed my competences.

FX