diff mbox

PR fortran/78300 -- class procedure as actual arg

Message ID CAKwh3qhD69gvLfH_GE2XmSB-NsLON+tzeTLJq4xubpHqCXFFKQ@mail.gmail.com
State New
Headers show

Commit Message

Janus Weil Nov. 14, 2016, 11:15 a.m. UTC 
2016-11-14 9:56 GMT+01:00 Janus Weil <janus@gcc.gnu.org>:
> Hi Steve,
>
>> The attach patch allows a procedure with a class result to
>> be an actual argument to subprogram where the dummy argument
>> expected to be a class.  OK to commit?
>
> that patch actually does not look quite right to me. Does it survive a regtest?
>
> I think one should rather check why the class_ok attribute is not set
> in the first place, any maybe apply a fix in gfc_build_class_symbol.

After looking into this a little bit more, I found that the culprit
seems to be 'resolve_procedure_interface', which does not properly
copy the 'class_ok' attribute. I propose the attached patch to fix
this (regtesting right now) ...

Cheers,
Janus

Comments

Janus Weil Nov. 14, 2016, 11:29 a.m. UTC | #1 
> After looking into this a little bit more, I found that the culprit
> seems to be 'resolve_procedure_interface', which does not properly
> copy the 'class_ok' attribute. I propose the attached patch to fix
> this (regtesting right now) ...

The regtest finished successfully. Is that patch ok for trunk?

Cheers,
Janus
Steve Kargl Nov. 14, 2016, 3:10 p.m. UTC | #2 
On Mon, Nov 14, 2016 at 12:29:31PM +0100, Janus Weil wrote:
> > After looking into this a little bit more, I found that the culprit
> > seems to be 'resolve_procedure_interface', which does not properly
> > copy the 'class_ok' attribute. I propose the attached patch to fix
> > this (regtesting right now) ...
> 
> The regtest finished successfully. Is that patch ok for trunk?
> 

Yes.  My original patch also regtest without a problem, but
you have a better fix.  You can also commit the patch to 
5 and 6 branch.
Janus Weil Nov. 14, 2016, 5:21 p.m. UTC | #3 
2016-11-14 16:10 GMT+01:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
> On Mon, Nov 14, 2016 at 12:29:31PM +0100, Janus Weil wrote:
>> > After looking into this a little bit more, I found that the culprit
>> > seems to be 'resolve_procedure_interface', which does not properly
>> > copy the 'class_ok' attribute. I propose the attached patch to fix
>> > this (regtesting right now) ...
>>
>> The regtest finished successfully. Is that patch ok for trunk?
>>
>
> Yes.  My original patch also regtest without a problem, but
> you have a better fix.  You can also commit the patch to
> 5 and 6 branch.

Thanks, I have committed the patch to trunk as r242392 now:

https://gcc.gnu.org/viewcvs?rev=242392&root=gcc&view=rev

Since it's not a regression, I don't care strongly about backporting.
If you think it's necessary, feel free to do it ...

Cheers,
Janus
Steve Kargl Nov. 14, 2016, 5:34 p.m. UTC | #4 
On Mon, Nov 14, 2016 at 06:21:06PM +0100, Janus Weil wrote:
> 2016-11-14 16:10 GMT+01:00 Steve Kargl <sgk@troutmask.apl.washington.edu>:
> > On Mon, Nov 14, 2016 at 12:29:31PM +0100, Janus Weil wrote:
> >> > After looking into this a little bit more, I found that the culprit
> >> > seems to be 'resolve_procedure_interface', which does not properly
> >> > copy the 'class_ok' attribute. I propose the attached patch to fix
> >> > this (regtesting right now) ...
> >>
> >> The regtest finished successfully. Is that patch ok for trunk?
> >>
> >
> > Yes.  My original patch also regtest without a problem, but
> > you have a better fix.  You can also commit the patch to
> > 5 and 6 branch.
> 
> Thanks, I have committed the patch to trunk as r242392 now:
> 
> https://gcc.gnu.org/viewcvs?rev=242392&root=gcc&view=rev
> 
> Since it's not a regression, I don't care strongly about backporting.
> If you think it's necessary, feel free to do it ...
> 

Understood.  For small patches, I typically try to backport
to at least the 6-branch as a pre-emptive measure.  My
reasoning is that gfortran users will likely use an updated
6.x compiler before trying the newest release.  Thanks for
the fix.
diff mbox

Patch

Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c	(Revision 242380)
+++ gcc/fortran/resolve.c	(Arbeitskopie)
@@ -214,27 +214,33 @@  resolve_procedure_interface (gfc_symbol *sym)
       if (ifc->result)
 	{
 	  sym->ts = ifc->result->ts;
+	  sym->attr.allocatable = ifc->result->attr.allocatable;
+	  sym->attr.pointer = ifc->result->attr.pointer;
+	  sym->attr.dimension = ifc->result->attr.dimension;
+          sym->attr.class_ok = ifc->result->attr.class_ok;
+	  sym->as = gfc_copy_array_spec (ifc->result->as);
 	  sym->result = sym;
 	}
       else
-	sym->ts = ifc->ts;
+	{
+	  sym->ts = ifc->ts;
+	  sym->attr.allocatable = ifc->attr.allocatable;
+	  sym->attr.pointer = ifc->attr.pointer;
+	  sym->attr.dimension = ifc->attr.dimension;
+	  sym->attr.class_ok = ifc->attr.class_ok;
+	  sym->as = gfc_copy_array_spec (ifc->as);
+	}
       sym->ts.interface = ifc;
       sym->attr.function = ifc->attr.function;
       sym->attr.subroutine = ifc->attr.subroutine;
 
-      sym->attr.allocatable = ifc->attr.allocatable;
-      sym->attr.pointer = ifc->attr.pointer;
       sym->attr.pure = ifc->attr.pure;
       sym->attr.elemental = ifc->attr.elemental;
-      sym->attr.dimension = ifc->attr.dimension;
       sym->attr.contiguous = ifc->attr.contiguous;
       sym->attr.recursive = ifc->attr.recursive;
       sym->attr.always_explicit = ifc->attr.always_explicit;
       sym->attr.ext_attr |= ifc->attr.ext_attr;
       sym->attr.is_bind_c = ifc->attr.is_bind_c;
-      sym->attr.class_ok = ifc->attr.class_ok;
-      /* Copy array spec.  */
-      sym->as = gfc_copy_array_spec (ifc->as);
       /* Copy char length.  */
       if (ifc->ts.type == BT_CHARACTER && ifc->ts.u.cl)
 	{