On Sat, Jan 05, 2019 at 09:22:34AM -0800, Steve Kargl wrote:
> 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.
>
Well, that was quick. Moving code around is problematic. The
hijacking of the interface checking causes gfortran to see from
1 to 3 actual arguments. A simple example is ISRK(r=3.14) (yes,
an invalid call). This has exact 1 actual argument, namely,
arg=expr->value.function.actual. So, gfortran see arg->next=NULL
and arg->next->next obvious cannot exist. The re-ordering would
require allocation of next and next->next to get the number of
actual arguments to match P,R,RADIX, so that we can extract
pointers to the expressions. Not worth the effort at the moment.
Of I might change my mind when I try to tackle the hijacking of
function rknd(n) result r
use ieee_arithmetic
integer n
r = ieee_selected_real_kind(p=n)
end function rknd
--
Steve
