------- Comment #27 from pault at gcc dot gnu dot org 2010-08-17 09:42 ------- (In reply to comment #25) > (In reply to comment #21) > > In my opinion revision 162487 is only a partial fix of the problem. If I > > split > > a modified test case in two files: [...] I still get [...] Bus error > > (In reply to comment #24) > > Look at -fdump-tree-original-uid dumps and see if you find the > > same decl with two different UIDs. I bet you will. > > One does. The problem is that when the module is not available. > > The variable "c" (of example in comment 21) created for the main program > "char_array_structure_constructor" but if one searches for the symbol (in > gfc_get_symbol_decl) via > gsym = gfc_find_gsymbol (gfc_gsym_root, sym->module); > the result is NULL as the only gsym which exists in gfc_gsym_root is the one > for "char_array_structure_constructor" as there is none for the module. One > should create a "fake" gsym for modules, if the module does not exist, and put > there the variables, functions, and type declarations - such that they can be > found if needed. >
Tobias, This is a very good suggestion. I will have a think about how to implement it and will come back to you. It is consistent with what I had in mind to improve the efficiency of module reading. ie. read_module proceeds as follows: (i) On encountering a USE statement, look for the module gsym. If it does not exist, use read_module, as at present, to construct the namespace, without any exclusions or renames; (ii) In the current scope, create symtrees using the ONLY and the renames and point to the symbols in the gsym namespace; (iii) Subsequent USEs of the same module proceed by using the gsym namespace. I think that Andy was smoking something or was having a whimsical spell when he wrote module.c. Whilst it is very elegant, it is unnecessarily disjunct from the rest of the frontend and could have been done as above. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44945
