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