PR 36322/36463

[Janus Weil]

I just tried to recompile the full example on c.l.f. with the current
patch, and noticed that there is one problem left, which is exposed by
the following test case:


module other_fun
   implicit none

   abstract interface
      function abstract_fun(x)
         integer x(:)
         integer abstract_fun(size(x))
      end function abstract_fun
   end interface

end module other_fun

program gptr
   use other_fun
   implicit none

   procedure(abstract_fun) :: fun

end program gptr


This gives:

Internal Error at (1):
gfc_get_default_type(): Bad symbol

The problem originates from symbols with the names "@0" and "@1". It
seems like these are generated during the reading of the module file
to replace "x" and "size". This happens in read_cleanup (module.c).
The @-names are generated by gfc_get_unique_symtree, and are supposed
to represent "hidden" symbols. Now I guess one should somehow mark
them as "non-hidden", e.g. by setting the rsym.referenced field, so
that they can keep their proper names. Maybe someone with more
experience in the module code can give me a hint on how to do this
properly ...

Cheers,
Janus