Re: [Patch] Fortran: Fix intrinsic null() handling [PR99651]

[Paul Richard Thomas <paul.richard.thomas@gmail.com>]

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 <tobias@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