| Message ID | CAGkQGi+37A1-WeFGUQrUXdJVEOBngW6j2KzFJH+WJb9_SYmaBQ@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [fortran] PR99602 - [11 regression] runtime error: pointer actual argument not associated | expand |
Hi Paul, I do not understand the !UNLIMITED_POLY(fsym) part of the patch. In particular, your patch causes foo.f90 to fail by wrongly diagnosting: Fortran runtime error: Pointer actual argument 'cptr' is not associated I have only did some light tests – but it seems that just removing '&& !UNLIMITED_POLY(fsym)' seems to be enough. (But I did not run the testsuite.) Hence: - Please include the attached testcases or some variants of them. - Check that removing !UNLIMITED_POLY does not cause any regressions If that works: OK for mainline Thanks for looking into this issue and working on the patches. Tobias On 26.03.21 07:58, Paul Richard Thomas via Fortran wrote: > This patch is straightforward but the isolation of the problem was rather > less so. Many thanks to Juergen for testcase reduction. > > Regtested on FC33/x86_64 - OK for master? > > Paul > > Fortran: Fix problem with runtime pointer chack [PR99602]. > > 2021-03-26 Paul Thomas <pault@gcc.gnu.org> > > gcc/fortran/ChangeLog > > PR fortran/99602 > * trans-expr.c (gfc_conv_procedure_call): Use the _data attrs > for class expressions and detect proc pointer evaluations by > the non-null actual argument list. > > gcc/testsuite/ChangeLog > > PR fortran/99602 > * gfortran.dg/pr99602.f90: New test. > * gfortran.dg/pr99602a.f90: New test. > * gfortran.dg/pr99602b.f90: New test. ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank Thürauf
Hi Tobias, An earlier version of the patch, without the exclusion of unlimited polymorphic expressions caused several regressions. However, omitting the exclusion now causes no regressions. I forgot to go back to this wrinkle. I have included your testcases with appropriate attribution and pushed as 297363774e6a5dca2f46a85ab086f1d9e59431ac . Thanks for the review and the additional testcases. Paul On Fri, 26 Mar 2021 at 11:22, Tobias Burnus <tobias@codesourcery.com> wrote: > Hi Paul, > > I do not understand the !UNLIMITED_POLY(fsym) part of the patch. > In particular, your patch causes foo.f90 to fail by wrongly diagnosting: > > Fortran runtime error: Pointer actual argument 'cptr' is not associated > > I have only did some light tests – but it seems that just removing > '&& !UNLIMITED_POLY(fsym)' seems to be enough. (But I did not run > the testsuite.) > > Hence: > - Please include the attached testcases or some variants of them. > - Check that removing !UNLIMITED_POLY does not cause any regressions > > If that works: OK for mainline > > Thanks for looking into this issue and working on the patches. > > Tobias > > On 26.03.21 07:58, Paul Richard Thomas via Fortran wrote: > > This patch is straightforward but the isolation of the problem was rather > > less so. Many thanks to Juergen for testcase reduction. > > > > Regtested on FC33/x86_64 - OK for master? > > > > Paul > > > > Fortran: Fix problem with runtime pointer chack [PR99602]. > > > > 2021-03-26 Paul Thomas <pault@gcc.gnu.org> > > > > gcc/fortran/ChangeLog > > > > PR fortran/99602 > > * trans-expr.c (gfc_conv_procedure_call): Use the _data attrs > > for class expressions and detect proc pointer evaluations by > > the non-null actual argument list. > > > > gcc/testsuite/ChangeLog > > > > PR fortran/99602 > > * gfortran.dg/pr99602.f90: New test. > > * gfortran.dg/pr99602a.f90: New test. > > * gfortran.dg/pr99602b.f90: New test. > ----------------- > Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank > Thürauf >
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c index bffe0808dff..723ebcc27f8 100644 --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -6663,6 +6663,18 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym, char *msg; tree cond; tree tmp; + symbol_attribute fsym_attr; + + if (fsym) + { + if (fsym->ts.type == BT_CLASS && !UNLIMITED_POLY (fsym)) + { + fsym_attr = CLASS_DATA (fsym)->attr; + fsym_attr.pointer = fsym_attr.class_pointer; + } + else + fsym_attr = fsym->attr; + } if (e->expr_type == EXPR_VARIABLE || e->expr_type == EXPR_FUNCTION) attr = gfc_expr_attr (e); @@ -6685,17 +6697,17 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym, tree present, null_ptr, type; if (attr.allocatable - && (fsym == NULL || !fsym->attr.allocatable)) + && (fsym == NULL || !fsym_attr.allocatable)) msg = xasprintf ("Allocatable actual argument '%s' is not " "allocated or not present", e->symtree->n.sym->name); else if (attr.pointer - && (fsym == NULL || !fsym->attr.pointer)) + && (fsym == NULL || !fsym_attr.pointer)) msg = xasprintf ("Pointer actual argument '%s' is not " "associated or not present", e->symtree->n.sym->name); - else if (attr.proc_pointer - && (fsym == NULL || !fsym->attr.proc_pointer)) + else if (attr.proc_pointer && !e->value.function.actual + && (fsym == NULL || !fsym_attr.proc_pointer)) msg = xasprintf ("Proc-pointer actual argument '%s' is not " "associated or not present", e->symtree->n.sym->name); @@ -6719,15 +6731,15 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym, else { if (attr.allocatable - && (fsym == NULL || !fsym->attr.allocatable)) + && (fsym == NULL || !fsym_attr.allocatable)) msg = xasprintf ("Allocatable actual argument '%s' is not " "allocated", e->symtree->n.sym->name); else if (attr.pointer - && (fsym == NULL || !fsym->attr.pointer)) + && (fsym == NULL || !fsym_attr.pointer)) msg = xasprintf ("Pointer actual argument '%s' is not " "associated", e->symtree->n.sym->name); - else if (attr.proc_pointer - && (fsym == NULL || !fsym->attr.proc_pointer)) + else if (attr.proc_pointer && !e->value.function.actual + && (fsym == NULL || !fsym_attr.proc_pointer)) msg = xasprintf ("Proc-pointer actual argument '%s' is not " "associated", e->symtree->n.sym->name); else