This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument



------- Comment #13 from mikael at gcc dot gnu dot org  2010-06-27 13:14 -------
Hello, 

The problem is that the oop code can add new symbols to the symtrees at
resolution or code generation time, which is unexpected. 
gfc_get_sym_tree (and thus gfc_get_symbol) has the side effect of keeping the
new/changed symbols in the changed_syms pointer chain.
When code generation is done, the namespace is freed, but changed_syms is still
pointing to the oop-generated (and freed) symbols. 
if we are not at the end of file at that point, we will continue parsing and
the next gfc_undo_symbol call will try to free these already freed symbols. 

To fix this, we should either call gfc_commit_symbols/gfc_undo_symbols when
done, or use a custom combination of
gfc_new_symbol/gfc_new_symtree/gfc_find_symbol instead of plain gfc_get_symbol
(that's how it is done for example in gfc_build_class_symbol).

The patch at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829#c20 uses the
first solution in gfc_find_derived_vtab. I don't know, however if it will catch
all cases, or whether there would be more appropriate places for it. 

Another solution would be to take changed_syms into account for reference
counting (gfc_symbol's refs member) but that would probably mean unreleased
memory in the end. 


I'm leaving this assigned to Janus because, as OOP master, he knows best the
place(s) where the change(s) have to be applied, for better cleanness,
bullet-proof-ness, and any-other-reasons-ness. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]