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

[Daniel Franke <franke dot daniel at gmail dot com>]

On Monday 29 December 2008 17:32:57 Paul Richard Thomas wrote:

Paul,

> 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?

Probably not. I started with FX's patch and added/removed bits and pieces all 
over the place ... I'm sure you can tell.


> 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? :-)

The plan is simple: make it work :)

I fully focused on the multiple decl problem. But learning more and more each 
day while looking into it, I'm convinced that the whole enchilada needs more 
attention. To circumvent problems with multiple decls, there are:

    * gfc_common_ns, a global namespace to deal with COMMONs
    * gfc_dt_list to pass derived types between the resolver and trans-types,
      but only within one namespace
    * module_htab, a hash table for modules that also provides unique decls
      for module variables

After Andrew pointed the problem with the last testcase, I started to think 
about a more universal approach - and came back to a (hash-)table of all decls 
available. First tests show, this would work nicely (and makes things far 
cleaner and clearer than the previous patch). However, having a global 
namespace that provides all available information instead of a flat table that 
only provides the decls would certainly be preferable - I'm all for it.

Time will be short when real-life breaks in again, but if we could lay out a 
plan who works on what and when, I'd be happy to participate. I want to see 
this for 4.5.

Cheers

	Daniel