On Sat, Jan 05, 2019 at 01:23:14PM +0100, Thomas Koenig wrote: > > Maybe it would be better to put the checking and argument reordering > into its own routine (something like gfc_check_minloc_maxloc in > check.c) so all three arguments would be present, with an > expression possibly containing NULL, for the later routines. > This could add some clarity and save code duplication later, > when the second part of the patch is done. > > However, I do not feel strongly about that. If you feel that your > current approach is better, that is fine by me. >
Thanks, Thomas. I tried a few things and finally landed on the keyword vs positional handling and argument checking in simplify_ieee_selected_real_kind. The actual heavy lifting comes from gfc_simplify_selected_real_kind where the constant expressions are extracted and gfortran tries to determine a valid kind. I see if I can moving the keyword/positional and checking into a separate function. Long term I think we need to put all functions into the table of intrinsic subprograms, so that handling these functions is almost identical to sin(), cos(), etc. This would then give the keyword vs positional handling automatically. ieee module procedures would be marked in gfc_intrinsic_sym with a bool or a bit in a bitfield, ie, gfc_intrinsic_sym *isym; isym->ieee = true; ! Member of ieee_arthmetic. or isym->ieee = 1; ! Member of ieee_arithmetic. 'isym->ieee = true' then indicates that gfortran needs to check if the ieee_arithmetic has been used and is in scope when a procedure is seen in the Fortran code. If yes, we have the module procedure. If no, we have a possibly user-defined procedure that shadows a routine from an intrinsic module. -- Steve
