Patchwork [Fortran] PR58436 - Fix a CLASS(*) finalization bug

login
register
mail settings
Submitter Tobias Burnus
Date Sept. 16, 2013, 8:18 p.m.
Message ID <52376796.4030405@net-b.de>
Download mbox | patch
Permalink /patch/275285/
State New
Headers show

Comments

Tobias Burnus - Sept. 16, 2013, 8:18 p.m.
I forgot, again, to attach the patch.

However, to my surprise the email made it through. Contrary to Janus' 
second patch review of today which didn't went past GCC's mail server. 
(The same problem I had yesterday: Three emails didn't make it.)

Tobias Burnus wrote:
> There were two related issues with the _vtab of CLASS(*): First, it 
> was crashing in the generation of the finalization wrapper. Secondly, 
> one needs to ensure that the _vtab contains a NULL pointer for _final.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
>
> Tobias
>
Janus Weil - Sept. 16, 2013, 8:25 p.m.
> Contrary to Janus' second
> patch review of today which didn't went past GCC's mail server.

Huh, indeed. I hadn't noticed ...


> (The same
> problem I had yesterday: Three emails didn't make it.)

Any idea what's the reason for this?

Cheers,
Janus
Tobias Burnus - Sept. 16, 2013, 8:28 p.m.
Janus Weil wrote:
>> (The same problem I had yesterday: Three emails didn't make it.)
> Any idea what's the reason for this?

No idea. Usually, one gets a bounce message but this time one didn't. 
Thus, I have no possibility to debug this from my side. #overseers 
didn't see it as their business and postmaster@  either didn't reply or 
didn't get the email.

Tobias
Tobias Burnus - Sept. 22, 2013, 10:48 p.m.
*PING* http://gcc.gnu.org/ml/fortran/2013-09/msg00031.html

(Additional early ping for: 
http://gcc.gnu.org/ml/fortran/2013-09/msg00039.html )

On September 16, 2013 22:18, Tobias Burnus wrote:
> I forgot, again, to attach the patch.
>
> However, to my surprise the email made it through. Contrary to Janus' 
> second patch review of today which didn't went past GCC's mail server. 
> (The same problem I had yesterday: Three emails didn't make it.)
>
> Tobias Burnus wrote:
>> There were two related issues with the _vtab of CLASS(*): First, it 
>> was crashing in the generation of the finalization wrapper. Secondly, 
>> one needs to ensure that the _vtab contains a NULL pointer for _final.
>>
>> Build and regtested on x86-64-gnu-linux.
>> OK for the trunk?
>>
>> Tobias
>>

Patch

diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 7117e83..be4959a 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -1427,6 +1427,12 @@  generate_finalization_wrapper (gfc_symbol *derived, gfc_namespace *ns,
   gfc_expr *ancestor_wrapper = NULL, *rank;
   gfc_iterator *iter;
 
+  if (derived->attr.unlimited_polymorphic)
+    {
+      vtab_final->initializer = gfc_get_null_expr (NULL);
+      return;
+    }
+
   /* Search for the ancestor's finalizers. */
   if (derived->attr.extension && derived->components
       && (!derived->components->ts.u.derived->attr.abstract
diff --git a/gcc/testsuite/gfortran.dg/finalize_21.f90 b/gcc/testsuite/gfortran.dg/finalize_21.f90
new file mode 100644
index 0000000..6f6ede3
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/finalize_21.f90
@@ -0,0 +1,12 @@ 
+! { dg-do compile }
+! { dg-options "-fdump-tree-original" }
+!
+! PR fortran/58436
+!
+! The following was ICEing and lacking _final=0
+!
+class(*), allocatable :: var
+end
+
+! { dg-final { scan-tree-dump "static struct __vtype__STAR __vtab__STAR = {._hash=0, ._size=., ._extends=0B, ._def_init=0B, ._copy=0B, ._final=0B};" "original" } }
+! { dg-final { cleanup-tree-dump "original" } }