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] |
tobias.schlueter@physik.uni-muenchen.de wrote: > Erik Edelmann wrote: > > There is however, one thing that I am still a bit unsure about (I > > hope this question doesn't sound too stupid); I learned (the hard > > way) that expr2->value.function.esym is NULL sometimes (which is > > why the patch checks that first). Can I trust > > expr2->value.function.esym to allways be non-NULL for elemental > > functions? I browsed the gfortran source code, but found no > > definite answer to that question. > > It can apparently, see resolve.c:767. > if (sym->attr.generic) > { > s = > gfc_search_interface (sym->generic, 0, &expr->value.function.actual); > if (s != NULL) > { > expr->value.function.name = s->name; > expr->value.function.esym = s; > expr->ts = s->ts; > if (s->as != NULL) > expr->rank = s->as->rank; > return MATCH_YES; > } > > /* TODO: Need to search for elemental references in generic interface */ > } > I assume what's missing is that array arguments are matched against elemental > function in interfaces, but I'm not sure. > > Furthermore, trans-expr.c:1550 says this: > /* expr.value.function.esym is the resolved (specific) function symbol for > most functions. However this isn't set for dummy procedures. */ > sym = expr->value.function.esym; > if (!sym) > sym = expr->symtree->n.sym; > gfc_conv_function_call (se, sym, expr->value.function.actual); > > It looks like your patch is correct, but I'd rather we understand when esym > should be set, first. I've browsed some more code, and did some testing. First, value.function.esym was non-NULL in all test I did with dummy procedures, so I don't quite understand that comment from trans-expr.c:1550 above. Instead, value.function.esym seems to be NULL for, and only for, intrinsics. My patch work with elemental intrinsics because elemental intrinsics are cought by a previous if-statement: if (expr2->value.function.isym && !gfc_is_intrinsic_libcall (expr2)) return NULL; If we still want to be really safe from elemental intrinsics, we could of course check for them explicitely; modified patch attached. (This by the way how we check for elemental functions in resolve.c/resolve_function().) Erik
Attachment:
diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |