Cancel the thought on my patchlet null_5.f90 fails on excess errors. Paul
On Tue, 23 Mar 2021 at 17:34, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Tobias, > > I took something of a detour in reviewing this patch. Although short, > understanding it is not straightforward! > > Your patch works as advertised and regtests OK (with the patch for PR93660 > on board as well). Is NULL the only case where this can happen? > Just to aid my understanding, I tried: > diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c > index a6df885c80c..f4c43a7c38b 100644 > --- a/gcc/fortran/primary.c > +++ b/gcc/fortran/primary.c > @@ -3922,6 +3922,9 @@ gfc_match_rvalue (gfc_expr **result) > if (m == MATCH_NO) > m = MATCH_YES; > > + if (!strcmp (sym->name, "NULL") || !strcmp (sym->name, "null")) > + sym->attr.intrinsic = 1; > + > break; > > generic_function: > > which also works and regtests OK. (I couldn't remember whether sym->name > is upper or lower case at this stage.) > > Thus, I THINK that your patch is OK and haven't managed to find any tests > which it breaks. I'll come back with a more definitive opinion tomorrow. > > Paul > > > > On Fri, 19 Mar 2021 at 08:51, Tobias Burnus <tob...@codesourcery.com> > wrote: > >> See PR for some analysis. The problem is that during >> gfc_intrinsic_func_interface, sym->attr.flavor == FL_PROCEDURE, >> hence, attr.intrinsic is not set – but later when parsing >> 'null()', gfortran calls: >> >> if (sym->attr.proc != PROC_INTRINSIC >> && !(sym->attr.use_assoc && sym->attr.intrinsic) >> && (!gfc_add_procedure(&sym->attr, PROC_INTRINSIC, sym->name, NULL) >> || !gfc_add_function (&sym->attr, sym->name, NULL))) >> return MATCH_ERROR; >> >> The gfc_add_procedure call fails as 'sym' is use-associated and >> may not be modified. >> >> The obvious solution to also set attr.intrinsic for FL_PROCEDURE fails >> in multiple ways, e.g. for gfortran.dg/char_length_16.f90 which has: >> CHARACTER (LEN(ITEMVAL)) :: ITEM >> INTRINSIC LEN >> the error is that INTRINSIC has been speicified twice. It also affects >> the error diagnostic in for generic resolution due to (I think): >> if (sym->attr.intrinsic) >> return gfc_intrinsic_func_interface (expr, 0); >> For gfortran.dg/allocatable_scalar_11.f90 the specific >> ‘array’ argument of ‘allocated’ intrinsic at (1) must be a variable >> gets replaced by the generic >> Generic function 'allocated' at (1) is not consistent with a specific >> intrinsic interface >> >> I have now tried it as shown. I think attr.function was not set, but >> am not sure. But setting it again for FL_PROCEDURE looks sensible. >> >> I am far from certain that now everything fits together, but I do hope >> that nothing fails which did work before ... >> >> OK for mainline? And after waiting a while for GCC 10? >> >> Tobias >> >> PS: I did see once a fail for pr93792.f90 (additional error as 't' in >> type(t) >> is not known) – but I could not reproduce it; the error is valid but >> later runs >> stopped with 'cannot open module file' and did not reach that follow-up >> error. >> >> ----------------- >> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München >> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank >> Thürauf >> > > > -- > "If you can't explain it simply, you don't understand it well enough" - > Albert Einstein > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein