public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [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).