rfc: multiple decls for functions

FX fxcoudert@gmail.com
Fri Dec 19 22:33:00 GMT 2008


Dear Daniel,

> FX worked on this problem earlier this year. When he finally got  
> stuck, he
> noted:
> 	"The best way to fix this is to use the other approach:
> 	file-scope resolution" [2].

I stand by my analysis. But...

> Thus, I'd propose the following: create a list/table of known  
> functions where
> new decls are added to, using the mangled name as a key. Before  
> adding a decl,
> check the list if the mangled name already exists, if so, use that  
> decl
> instead of creating a new one.


... what you propose here is not file-scope resolution, it happens  
later (during creation of decls). In my opinion, it's a bit late...  
see below why.

I tried what you propose, although in a slightly different way: you  
can find the decls of globally declared functions (which are the ones  
of interest here) by looking at the top binding level (see trans- 
decl.c and f95-lang.c, IIRC). That part of the idea works fine and you  
can actually get the decls you need, but another problem then arises,  
which I never managed to solve (I asked many questions to try and get  
help in this thread: http://gcc.gnu.org/ml/fortran/2008-02/ 
msg00005.html but I never managed it; you can use my patch from that  
message to try and do better that I did). The problem is with array  
arguments: two decls for the same function will be different,  
depending on whether they're built because we're translating a  
function declaration or a function call. That is, the decl created for  
f in:

     subroutine test(x)
       integer x(1)
     end subroutine test

is different from the one created when translating:

     integer x(1)
     call test(x)


One has GFC_ARRAY_TYPE_P for its argument and the other doesn't. And  
the compiler appears to care: if you reuse the one without  
GFC_ARRAY_TYPE_P when later seeing the subroutine itself, then you  
trigger an assert. I've never understood completely the  
GFC_ARRAY_TYPE_P madness but all my tries to fix this have failed.  
Which is why I recommended another course of action. But you might  
find a way to coax the arrays to work fine, I'm sure there has to be  
one.


Good luck,
FX



More information about the Fortran mailing list