| Message ID | CAKwh3qh6G_OL4MTJhUx4o+1fDFwaYchto2dw+m142wqxGWsjuw@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Ping! I was hoping this would still make it into GCC 7, which apparently is very close to being released now (branched already) ... Cheers, Janus 2017-04-17 11:07 GMT+02:00 Janus Weil <janus@gcc.gnu.org>: > Hi all, > > the attached patch fixes an ICE-on-valid regression, where the > compiler runs into an infinite loop if a derived type contains a > procedure-pointer component which has a polymorphic result of the > original type. > > We already have a piece of code which prevents the infinite loop for > TYPE-valued PPCs, but it doesn't work for CLASS results, which is > fixed by the patch here. > > Ok for trunk and the 5/6 branches? > > Cheers, > Janus > > > > 2017-04-17 Janus Weil <janus@gcc.gnu.org> > > PR fortran/80392 > * trans-types.c (gfc_get_derived_type): Prevent an infinite loop when > building a derived type that includes a procedure pointer component > with a polymorphic result. > > 2017-04-17 Janus Weil <janus@gcc.gnu.org> > > PR fortran/80392 > * gfortran.dg/proc_ptr_comp_49.f90: New test case.
The patch looks ok to me. You'll need Release Manager approval (jakub, richi, or maybe law) to apply the patch to the 7-branch. Hmmm, gcc.gnu.org seems to be unreachable at the moment.
2017-04-21 19:49 GMT+02:00 Steve Kargl <sgk@troutmask.apl.washington.edu>: > The patch looks ok to me. Thanks, Steve. I will at least commit to trunk now. > You'll need Release Manager > approval (jakub, richi, or maybe law) to apply the > patch to the 7-branch. I know. Would anyone of those gentlemen see the possibility of accepting the patch for the 7-branch at this point? I'm aware that it's in no way release-critical, but it's a regression after all and was posted before the branching. > Hmmm, gcc.gnu.org seems to be unreachable at the moment. Appears to be back by now ... Cheers, Janus > On Fri, Apr 21, 2017 at 06:57:14PM +0200, Janus Weil wrote: >> Ping! I was hoping this would still make it into GCC 7, which >> apparently is very close to being released now (branched already) ... >> >> Cheers, >> Janus >> >> >> >> 2017-04-17 11:07 GMT+02:00 Janus Weil <janus@gcc.gnu.org>: >> > Hi all, >> > >> > the attached patch fixes an ICE-on-valid regression, where the >> > compiler runs into an infinite loop if a derived type contains a >> > procedure-pointer component which has a polymorphic result of the >> > original type. >> > >> > We already have a piece of code which prevents the infinite loop for >> > TYPE-valued PPCs, but it doesn't work for CLASS results, which is >> > fixed by the patch here. >> > >> > Ok for trunk and the 5/6 branches? >> > >> > Cheers, >> > Janus >> > >> > >> > >> > 2017-04-17 Janus Weil <janus@gcc.gnu.org> >> > >> > PR fortran/80392 >> > * trans-types.c (gfc_get_derived_type): Prevent an infinite loop when >> > building a derived type that includes a procedure pointer component >> > with a polymorphic result. >> > >> > 2017-04-17 Janus Weil <janus@gcc.gnu.org> >> > >> > PR fortran/80392 >> > * gfortran.dg/proc_ptr_comp_49.f90: New test case. > > -- > Steve > 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
On Fri, Apr 21, 2017 at 08:47:47PM +0200, Janus Weil wrote: > 2017-04-21 19:49 GMT+02:00 Steve Kargl <sgk@troutmask.apl.washington.edu>: > > > You'll need Release Manager > > approval (jakub, richi, or maybe law) to apply the > > patch to the 7-branch. > > I know. Would anyone of those gentlemen see the possibility of > accepting the patch for the 7-branch at this point? > > I'm aware that it's in no way release-critical, but it's a regression > after all and was posted before the branching. Patches to regressions that were submitted before branching are typically allowed as long as one has done the due diligence to run the testsuite. The GCC homepage states "Serious Regression. All regressions." for 7.1. My take: it does not hurt to ask RM. The worse outcome is they say 'no'.
2017-04-21 20:47 GMT+02:00 Janus Weil <janus@gcc.gnu.org>: > 2017-04-21 19:49 GMT+02:00 Steve Kargl <sgk@troutmask.apl.washington.edu>: >> The patch looks ok to me. > > Thanks, Steve. I will at least commit to trunk now. Committed to trunk as r247069. Cheers, Janus >> On Fri, Apr 21, 2017 at 06:57:14PM +0200, Janus Weil wrote: >>> Ping! I was hoping this would still make it into GCC 7, which >>> apparently is very close to being released now (branched already) ... >>> >>> Cheers, >>> Janus >>> >>> >>> >>> 2017-04-17 11:07 GMT+02:00 Janus Weil <janus@gcc.gnu.org>: >>> > Hi all, >>> > >>> > the attached patch fixes an ICE-on-valid regression, where the >>> > compiler runs into an infinite loop if a derived type contains a >>> > procedure-pointer component which has a polymorphic result of the >>> > original type. >>> > >>> > We already have a piece of code which prevents the infinite loop for >>> > TYPE-valued PPCs, but it doesn't work for CLASS results, which is >>> > fixed by the patch here. >>> > >>> > Ok for trunk and the 5/6 branches? >>> > >>> > Cheers, >>> > Janus >>> > >>> > >>> > >>> > 2017-04-17 Janus Weil <janus@gcc.gnu.org> >>> > >>> > PR fortran/80392 >>> > * trans-types.c (gfc_get_derived_type): Prevent an infinite loop when >>> > building a derived type that includes a procedure pointer component >>> > with a polymorphic result. >>> > >>> > 2017-04-17 Janus Weil <janus@gcc.gnu.org> >>> > >>> > PR fortran/80392 >>> > * gfortran.dg/proc_ptr_comp_49.f90: New test case. >> >> -- >> Steve >> 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
Index: gcc/fortran/trans-types.c =================================================================== --- gcc/fortran/trans-types.c (revision 246939) +++ gcc/fortran/trans-types.c (working copy) @@ -2617,9 +2617,10 @@ gfc_get_derived_type (gfc_symbol * derived, int co the same as derived, by forcing the procedure pointer component to be built as if the explicit interface does not exist. */ if (c->attr.proc_pointer - && ((c->ts.type != BT_DERIVED && c->ts.type != BT_CLASS) - || (c->ts.u.derived - && !gfc_compare_derived_types (derived, c->ts.u.derived)))) + && (c->ts.type != BT_DERIVED || (c->ts.u.derived + && !gfc_compare_derived_types (derived, c->ts.u.derived))) + && (c->ts.type != BT_CLASS || (CLASS_DATA (c)->ts.u.derived + && !gfc_compare_derived_types (derived, CLASS_DATA (c)->ts.u.derived)))) field_type = gfc_get_ppc_type (c); else if (c->attr.proc_pointer && derived->backend_decl) {
Hi all, the attached patch fixes an ICE-on-valid regression, where the compiler runs into an infinite loop if a derived type contains a procedure-pointer component which has a polymorphic result of the original type. We already have a piece of code which prevents the infinite loop for TYPE-valued PPCs, but it doesn't work for CLASS results, which is fixed by the patch here. Ok for trunk and the 5/6 branches? Cheers, Janus 2017-04-17 Janus Weil <janus@gcc.gnu.org> PR fortran/80392 * trans-types.c (gfc_get_derived_type): Prevent an infinite loop when building a derived type that includes a procedure pointer component with a polymorphic result. 2017-04-17 Janus Weil <janus@gcc.gnu.org> PR fortran/80392 * gfortran.dg/proc_ptr_comp_49.f90: New test case.