This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: [fortran patch] Don't use TREE_LISTs for storing arguments to intrinsic functions


Lee Millward wrote:
To illustrate this take gfc_conv_intrinsic_aint for example which
creates space for two arguments, here the code is only interested in
the first argument, but making the change to only pass a single
argument to gfc_conv_intrinsic_function_args with the new assertion
will trigger failures in tests like aint_anint_1.f90. From what I'm
able to determine the need for allowing two arguments here (and in
gfc_conv_intrinsic_int) dates back to Fortran 77 where intrinsics like
AINT and INT can optionally have a "kind" parameter.

Right, yes, although this has nothing to do with Fortran 77. The problem is that AINT, INT, and so on allow an optional KIND parameter, which is only used in the front-end to figure out which library function to call, and never has any generated code associated with it.


Am I correct in understanding that this is why you have things set up so that gfc_conv_intrinsic_aint (for example) declares args as a two-element array rather than a single value? (Otherwise, I suppose it would trigger the "curr_arg < nargs" assertion if the KIND argument is present....)

I think this ends up being unfortunate in a number of ways. The declaration of args in gfc_conv_intrinsic_aint as larger than we need is one of them, and the fact that we can't guarantee that the args array gets filled is another. Thus, I would suggest rearranging things, as follows:

(1) Change the main loop in gfc_conv_intrinsic_function_args to:

  for (int curr_arg = 0; curr_arg < nargs; curr_arg++,
       actual = actual->next,
       formal = formal ? formal->next : NULL)

(2) Remove the gcc_assert(curr_arg < nargs), and add gcc_assert(actual) in its place.

The result of those two is that we guarantee that the args array gets filled, but we don't necessarily loop over the whole arglist. That is, we now allow the arglist to be longer than the args array, and we no longer allow it to be shorter. That leads to:

(3) Change gfc_conv_intrinsic_aint and other similar functions to only call for one argument, rather than two.

Oh, and:

(4) Add a comment somewhere that says that we are explicitly ignoring arguments past nargs in the arglist, in order to account for trailing KIND arguments that are not included in the generated code. :)

Does that seem reasonable?

Thanks (and apologies for putting this through so many iterations!),
- Brooks


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