From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8501 invoked by alias); 27 Jun 2010 13:14:16 -0000 Received: (qmail 8452 invoked by uid 48); 27 Jun 2010 13:14:06 -0000 Date: Sun, 27 Jun 2010 13:14:00 -0000 Message-ID: <20100627131406.8451.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mikael at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-06/txt/msg02626.txt.bz2 ------- 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