This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR43945 - [OOP] Derived type with GENERIC: resolved to the wrong specific TBP
- From: Daniel Franke <franke dot daniel at gmail dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: Tobias Burnus <burnus at net-b dot de>, Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>, Dominique Dhumieres <dominiq at lps dot ens dot fr>, fortran at gcc dot gnu dot org
- Date: Tue, 18 May 2010 00:07:54 +0200
- Subject: Re: [Patch, fortran] PR43945 - [OOP] Derived type with GENERIC: resolved to the wrong specific TBP
- References: <20100517172329.931B83BE0F@mailhost.lps.ens.fr> <4BF1B5F0.5080201@net-b.de> <4BF1B7A0.5020103@net-b.de>
On Monday 17 May 2010 23:39:44 Tobias Burnus wrote:
> Tobias Burnus wrote:
> > It is interesting if one follows "class_ref" in
> > resolve_typebound_subroutine. Before
> >
> > resolve_typebound_call (code, &name);
> >
> > it is still "type = REF_COMPONENT" but afterwards it is type =
> > 2893287512.
>
> Which makes sense:
>
> resolve_typebound_subroutine (gfc_code *code)
> {
> declared = get_declared_from_expr (&class_ref, &new_ref, code->expr1);
> resolve_typebound_call (code, &name);
> if (class_ref)
>
> and
>
> resolve_typebound_call (gfc_code* c, const char **name)
> {
> gfc_free_expr (c->expr1);
>
> Thus, it is not surprising that it won't work if one frees c->expr1 -
> and then uses c->expr1->ref == class_ref later.
This rings a small bell, PR40994 may be related here.
It's an ICE gfc_undo_symbols after dealing with a typebound procedure. It
appears that gfc_undo_symbols tries to free something that was freed before?!
Just to mention it.
Daniel