Re: fix for the multiple-decl problem - please test

["Paul Richard Thomas" <paul dot richard dot thomas at gmail dot com>]

Daniel,

I have had a quick look at your patch; it seems to be doing a lot of
the right things with the function declarations but I wonder if it is
overall the simplest and cleanest way of skinning this particular cat?

As you might be aware, I started on a revamp of the parsing,
resolution and translation that put all the symbols for all procedures
and the main program into a global namespace.  In this way, parsing
and translation could be done on a "whole file" basis.  The multiple
declaration problem could be solved by translating the function or
procedure as soon as any reference to it is encountered and the
backend_decl can be found subsequently attached to the symbol in the
global namespace.  Similarly, interfaces can be resolved using the
existing mechanics in interface.c and derived types are taken care of
naturally, as if in a single program unit; ie. they have the lifetime
of the global namespace.

Now you might well ask why I did not develop this further? Partially
because of the question that I raised in
http://gcc.gnu.org/ml/fortran/2007-07/msg00151.html - I now understand
this to be baseless but it stopped me at the time.  Secondly, such
time as I have had subsequently for gfortran has been taken more or
less entirely taken by firefighting:-(  I would early have liked to
have developed it further.

Anyway, I am raising this question because your approach looks as if
it is entirely focussed on the multiple decl problem and that you will
attack the other issues separately, largely because you associate
external decls in the backend tree.  Maybe you have some plan in mind
that I have not figured out? :-)

Cheers

Paul

PS will answer separately to your question about the derived type checking...

On Mon, Dec 29, 2008 at 2:35 AM, Daniel Franke <franke.daniel@gmail.com> wrote:
> On Saturday 27 December 2008 20:27:42 Daniel Franke wrote:
>> > Yes global variables also have the multiple-decl issue and not just
>> > functions :).  You need to merge them too.
>>
>> You are right, unfortunately.
>> Same with COMMON:
>>
>>   common /global/ p
>>   integer :: p
>>
>>   p = 1
>>   CALL set_p()
>>   IF (p /= 42) CALL ABORT()
>> END
>>
>> SUBROUTINE set_p()
>>   common /global/ p
>>   p = 42
>> END SUBROUTINE
>
> To correct myself: COMMON is fine. This aborts because of the different types
> for P in the program (INTEGER) and the subroutine (implicitly typed REAL) ^^
>
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy