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: [gfortran,patch] Fix intrinsics used as actual arguments


:REVIEWMAIL:

FX,

Chapeau!

Hi all,

Here is the patch I promised: this fixes a few problems related to the use of intrinsics as actual arguments. It's a bit long, but it's really straightforward and should be rather easy to review ;-)

... a "bit" long?!



I'll try to comment my patch below, please ask if you have any question. First, there are the general front-end changes:


-- the intrinsics list in intrinsic.c was reviewed and the actual_ok field was corrected in each case, according to the Standard. A few GNU intrinsics are kept allowed as actual arguments, for consistency: ACOSH ATANH DACOSH DASINH DATANH DCONJG DIMAG ZABS ZCOS ZEXP ZLOG ZSIN ZSQRT; also, no intrinsic subroutine is allowed as actual argument, so having an actual_ok argument to add_sym_?s functions is useless; the value of actual_ok is propagated into each gfc_intrinsic_sym

I have checked them off against the standard. All look OK.



-- create a new function gfc_intrinsic_actual_ok in intrinsic.c for the resolution functions to perform checks; it is called in resolve_actual_arglist (resolve.c) and an error message is issued if need be; the CHAR intrinsic is special-cased because it's the only one forbidden (as actual arg) in F95 and allowed in F2003

OK


-- change gfc_get_extern_function_decl in trans-decl.c to call isym->resolve.f3 when an intrinsic has 3 args

OK




Library changes:

-- make m4 generate new files for AIMAG, ASINH, ACOSH and ATANH specifics
-- use a new simple m4 file (misc_specifics.m4) to generate code for other specifics (including character functions)

The copyright years need changing. Are these sufficiently different in your opinion that you should appear as the contributer?




Smaller changes:

-- a gfc_resolve_index_func function is added to resolve the INDEX intrinsic, so that it can be used as actual argument (PR 16580)

Add a comment as to why you call it gfc_resolve_index_func, rather than gfc_resolve_index, above the entry in intrinsic.c. I think that it is the only exception, is it not?


  -- intrinsic.texi is updated to mention that DIMAG is a GNU extension
  -- testcases for all this

OK





Bootstrapped & regtested on i686-linux, OK for 4.2?

Yes, indeed! It's more than OK.


Thanks

Paul

PS Exceptionally, I did not apply this to my tree and try it out, since it is ready and waiting for the allocatable components patch.


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