Re: deep copy gfc_symbol?

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

On Friday 26 December 2008 18:30:16 Paul Richard Thomas wrote:
> > is there an easy way (function?) to deep copy a gfc_symbol?
>
> It should not be too difficult but why do you want to do it?  The
> facility does not exits for fairly good reasons.

Dear Paul,

I'm working at the muliple-decl problem and made good progress. The latest 
obstacle were derived type decls not being shared across namespaces. This lead 
to an ICE somehwere in fold-const.c as it does not know how to compare 
RECORD_TYPEs (see my last mail). To overcome this, I changed gfc_dt_list to 
hold derived type decls for an unlimited time and did the necessary 
adjustments. Problem: derived types that are defined in different places that 
are nonetheless considered identical as of sec 4.4.2 in F95. As I'm not fluent 
enough in TREE-speak to compare backend_decls directly, I'm stuck with an 
identifier that fully describes a derived type, either a long mangled name or 
a symbol/typespec. At first, I chose the symbol as a key.

While the initial regressions are now dealt with, some new crept up: character 
components loose their charlen-descriptor, they are deleted by 
gfc_free_charlen() when the namespace is dealt with. To make the initial 
change work, I excluded derived types from being deleted in the cleanup, but 
this can't be done for the charlen.

Options as I see them: 
 * deep-copy a symbol/typespec to keep it around for the type description and
   let symbol.c deal with the original symbol as before
 * implement a type-mangling function that translates the derived type into a
   string that can be used as a key for the corresponding backend_decl
   (similar to gfc_compare_derived_types() which works on symbols)
 * learn enough about TREEs to compare the types on the TREE-level

Suggestions?

	Daniel