public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "mikael at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument
Date: Sun, 27 Jun 2010 13:14:00 -0000	[thread overview]
Message-ID: <20100627131406.8451.qmail@sourceware.org> (raw)
In-Reply-To: <bug-42051-15301@http.gcc.gnu.org/bugzilla/>



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


  parent reply	other threads:[~2010-06-27 13:14 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-15 16:25 [Bug fortran/42051] New: ICE on allocatable array TBP result damian at rouson dot net
2009-11-15 18:31 ` [Bug fortran/42051] " janus at gcc dot gnu dot org
2009-11-15 18:50 ` [Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument janus at gcc dot gnu dot org
2009-12-03 21:28 ` pault at gcc dot gnu dot org
2009-12-03 21:46 ` pault at gcc dot gnu dot org
2009-12-04 13:18 ` dominiq at lps dot ens dot fr
2010-03-02 23:31 ` janus at gcc dot gnu dot org
2010-06-11  2:50 ` janus at gcc dot gnu dot org
2010-06-11  2:56 ` janus at gcc dot gnu dot org
2010-06-11 16:46 ` janus at gcc dot gnu dot org
2010-06-15 19:08 ` janus at gcc dot gnu dot org
2010-06-15 19:38 ` janus at gcc dot gnu dot org
2010-06-15 19:41 ` janus at gcc dot gnu dot org
2010-06-27 13:14 ` mikael at gcc dot gnu dot org [this message]
2010-06-27 13:16 ` mikael at gcc dot gnu dot org
2010-06-27 14:39 ` paul dot richard dot thomas at gmail dot com
2010-07-15 21:37 ` dfranke at gcc dot gnu dot org
2010-07-28 20:01 ` mikael at gcc dot gnu dot org
2010-07-29 11:23 ` mikael at gcc dot gnu dot org
2010-07-29 11:53 ` mikael at gcc dot gnu dot org
2010-07-31 10:28 ` mikael at gcc dot gnu dot org
2010-08-02 15:31 ` mikael at gcc dot gnu dot org
2010-08-04 14:18 ` mikael at gcc dot gnu dot org
2010-08-05 12:12 ` janus at gcc dot gnu dot org
2010-08-05 12:59 ` mikael at gcc dot gnu dot org
2010-08-05 21:09 ` mikael at gcc dot gnu dot org
2010-08-05 21:11 ` mikael at gcc dot gnu dot org
     [not found] <bug-42051-4@http.gcc.gnu.org/bugzilla/>
2011-08-16 21:23 ` janus at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100627131406.8451.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).