[Patch, fortran] PR24409 - ICE on module name vs dummy argument name

[Tobias Schlüter]

Steve Kargl wrote:
> On Tue, Nov 08, 2005 at 12:04:24AM +0100, Paul Thomas wrote:
> 
>>>PS: Someday, we should document the gfortran and libgfortran
>>>  internals on the wiki.  AFAIK, Paul T is the only person
>>>  with a grasp on how modules work. :(
>>>
>>>
>>
>>I think that you are right. Maybe I should write something on module.c, 
>>whilst I still have a grasp on it! It is a very slippery thing.
>>
>>It is my belief that module.c is more complicated, at the front end, 
>>that it needs to be. Also, for complicated codes, it can be very slow 
>>because it reads the .mod file and reconstructs the contribution to the 
>>symtree each time a module is used. As a medium-ish term project, I 
>>intend to make a list of module namespaces, into which the .mod files 
>>are unconditionally read... once. The use should then be made from those 
>>namespaces. The interior is very clever and merits some investigation.
>>
> 
> 
> Well, I've been looking at PR 15976
> 
> module sd
>   integer :: i(n)
> end module sd
> 
> This is illegal.  In resolve_symbol, I can determine i is an automatic
> array, but I have not been able to determine that i is in a module
> as oppose to say a function

I suppose (sym->ns->proc_name->attr.procedure_type == PROC_MODULE)? should be
the right question to ask.  This would be valid if n were a PARAMETER so it's
not as easy, though.  Also, you said that all pointers are NULL, so this field
might not yet have been filled in, in which case you could look at
gfc_current_namespace->attr.procedure_type, which should also contain the
right information.

- Tobi