* [PATCH] Fix IMPLICIT CHARACTER handling (PR fortran/46884)
@ 2010-12-10 19:49 Jakub Jelinek
2010-12-11 11:46 ` Steve Kargl
0 siblings, 1 reply; 2+ messages in thread
From: Jakub Jelinek @ 2010-12-10 19:49 UTC (permalink / raw)
To: gcc-patches, fortran
Hi!
On the attached testcase f951 ICEs under valgrind (and on a larger
testcase can ICE even without it), because a charlen is freed, eventhough
it is actually referenced.
The problem is with IMPLICIT charlen, gfc_new_charlen with non-NULL old_cl
generates a copy of a charlen, which is then attached to an implicitly
typed symbol, but if reject_statement is called afterwards, the charlen
copy is freed, eventhough a pointer to it remains in the data structures.
Fixed by making sure we never free in reject_statements gfc_new_charlen
created structures if old_cl was non-NULL.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2010-12-10 Jakub Jelinek <jakub@redhat.com>
PR fortran/46884
* symbol.c (gfc_new_charlen): If old_cl is non-NULL, put it
at the ns->old_cl_list spot in the chain rather than at
ns->cl_list.
* gfortran.dg/pr46884.f: New test.
--- gcc/fortran/symbol.c.jj 2010-11-15 09:28:07.000000000 +0100
+++ gcc/fortran/symbol.c 2010-12-10 12:23:03.000000000 +0100
@@ -3219,19 +3219,29 @@ gfc_new_charlen (gfc_namespace *ns, gfc_
gfc_charlen *cl;
cl = gfc_get_charlen ();
- /* Put into namespace. */
- cl->next = ns->cl_list;
- ns->cl_list = cl;
-
/* Copy old_cl. */
if (old_cl)
{
+ /* Put into namespace, but don't allow reject_statement
+ to free it if old_cl is given. */
+ gfc_charlen **prev = &ns->cl_list;
+ cl->next = ns->old_cl_list;
+ while (*prev != ns->old_cl_list)
+ prev = &(*prev)->next;
+ *prev = cl;
+ ns->old_cl_list = cl;
cl->length = gfc_copy_expr (old_cl->length);
cl->length_from_typespec = old_cl->length_from_typespec;
cl->backend_decl = old_cl->backend_decl;
cl->passed_length = old_cl->passed_length;
cl->resolved = old_cl->resolved;
}
+ else
+ {
+ /* Put into namespace. */
+ cl->next = ns->cl_list;
+ ns->cl_list = cl;
+ }
return cl;
}
--- gcc/testsuite/gfortran.dg/pr46884.f.jj 2010-12-10 13:59:39.000000000 +0100
+++ gcc/testsuite/gfortran.dg/pr46884.f 2010-12-10 13:59:13.000000000 +0100
@@ -0,0 +1,8 @@
+C PR fortran/46884
+C { dg-do compile }
+C { dg-options "" }
+ SUBROUTINE F
+ IMPLICIT CHARACTER*12 (C)
+ CALL G(C1)
+ CALL H(C1(1:4))
+ END
Jakub
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] Fix IMPLICIT CHARACTER handling (PR fortran/46884)
2010-12-10 19:49 [PATCH] Fix IMPLICIT CHARACTER handling (PR fortran/46884) Jakub Jelinek
@ 2010-12-11 11:46 ` Steve Kargl
0 siblings, 0 replies; 2+ messages in thread
From: Steve Kargl @ 2010-12-11 11:46 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches, fortran
On Fri, Dec 10, 2010 at 08:45:23PM +0100, Jakub Jelinek wrote:
>
> On the attached testcase f951 ICEs under valgrind (and on a larger
> testcase can ICE even without it), because a charlen is freed, eventhough
> it is actually referenced.
>
> The problem is with IMPLICIT charlen, gfc_new_charlen with non-NULL old_cl
> generates a copy of a charlen, which is then attached to an implicitly
> typed symbol, but if reject_statement is called afterwards, the charlen
> copy is freed, eventhough a pointer to it remains in the data structures.
>
> Fixed by making sure we never free in reject_statements gfc_new_charlen
> created structures if old_cl was non-NULL.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
OK.
--
Steve
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-12-10 21:14 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-10 19:49 [PATCH] Fix IMPLICIT CHARACTER handling (PR fortran/46884) Jakub Jelinek
2010-12-11 11:46 ` Steve Kargl
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).