| Message ID | 20161113221255.GA16971@troutmask.apl.washington.edu |
|---|---|
| State | New |
| Headers | show |
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. Cheers, Janus
> 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
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. -- Steve
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
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. -- Steve
Index: gcc/fortran/resolve.c =================================================================== --- gcc/fortran/resolve.c (revision 242362) +++ gcc/fortran/resolve.c (working copy) @@ -11705,7 +11705,8 @@ resolve_fl_var_and_proc (gfc_symbol *sym /* Assume that use associated symbols were checked in the module ns. Class-variables that are associate-names are also something special and excepted from the test. */ - if (!sym->attr.class_ok && !sym->attr.use_assoc && !sym->assoc) + if (!sym->attr.class_ok && !sym->attr.use_assoc && !sym->attr.dummy + && !sym->assoc) { gfc_error ("CLASS variable %qs at %L must be dummy, allocatable " "or pointer", sym->name, &sym->declared_at); Index: gcc/testsuite/gfortran.dg/pr78300.f90 =================================================================== --- gcc/testsuite/gfortran.dg/pr78300.f90 (nonexistent) +++ gcc/testsuite/gfortran.dg/pr78300.f90 (working copy) @@ -0,0 +1,38 @@ +! { dg-do compile } +module gfc_base + + implicit none + + integer, parameter:: INTD=4 + integer, parameter:: INTL=8 + integer(INTD), parameter :: GFC_FALSE=0 + + type gfc_cont_elem_t + class(*), pointer, private:: value_p=>NULL() + integer(INTD), private:: alloc=GFC_FALSE + contains + procedure, public:: construct=>ContElemConstruct + end type gfc_cont_elem_t + + abstract interface + function gfc_copy_i(obj,ierr) result(clone) + import:: INTD + class(*), pointer:: clone + class(*), intent(in):: obj + integer(INTD), intent(out), optional:: ierr + end function gfc_copy_i + end interface + + private ContElemConstruct + + contains + + subroutine ContElemConstruct(this,obj,ierr,assoc_only,copy_constr_func) + class(gfc_cont_elem_t), intent(inout):: this + class(*), target, intent(in):: obj + integer(INTD), intent(out), optional:: ierr + logical, intent(in), optional:: assoc_only + procedure(gfc_copy_i), optional:: copy_constr_func + end subroutine ContElemConstruct + + end module gfc_base