[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 markeggleston at gcc dot gnu.org changed: What|Removed |Added CC||mark.eggleston at codethink dot co ||m --- Comment #20 from markeggleston at gcc dot gnu.org --- *** Bug 92196 has been marked as a duplicate of this bug. ***
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 --- Comment #19 from Janne Blomqvist --- This latest commit fixes the testsuite failure. Thanks for the quick fix.
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 markeggleston at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #18 from markeggleston at gcc dot gnu.org --- Cut and paste issue. Forgot to remove -not from one of the scan-tree-dump lines. Committed as obvious: master: https://gcc.gnu.org/g:e82ba180d6641a1e2bad1ac327234fc1cda658ef releases/gcc-9 https://gcc.gnu.org/g:42066149461d7e6951d61c341954b0ed77c08d34
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 --- Comment #17 from CVS Commits --- The releases/gcc-9 branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:42066149461d7e6951d61c341954b0ed77c08d34 commit r9-8148-g42066149461d7e6951d61c341954b0ed77c08d34 Author: Mark Eggleston Date: Mon Jan 20 13:29:33 2020 + [PATCH] PR Fortran/93263 Correct test case Should've have checked for the existance of a non static integer using scan-tree-dump instead of scan-tree-dump-not. A cut and paste error.
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 --- Comment #16 from CVS Commits --- The master branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:e82ba180d6641a1e2bad1ac327234fc1cda658ef commit r10-6091-ge82ba180d6641a1e2bad1ac327234fc1cda658ef Author: Mark Eggleston Date: Mon Jan 20 13:23:07 2020 + [PATCH] PR Fortran/93263 Correct test case Should've have checked for the existance of a non static integer using scan-tree-dump instead of scan-tree-dump-not. A cut and paste error.
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 --- Comment #15 from Christophe Lyon --- > Seen on arm too, both master and gcc-9 And aarch64 too.
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #14 from Christophe Lyon --- (In reply to Janne Blomqvist from comment #13) > Running the testsuite on today's master (2020-01-18) on x86_64-pc-linux-gnu > fails with > > FAIL: gfortran.dg/pr93263_1.f90 -O scan-tree-dump-not original > "integer\\(kind=4\\) a" Seen on arm too, both master and gcc-9
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 Janne Blomqvist changed: What|Removed |Added Status|RESOLVED|REOPENED CC||jb at gcc dot gnu.org Resolution|FIXED |--- --- Comment #13 from Janne Blomqvist --- Running the testsuite on today's master (2020-01-18) on x86_64-pc-linux-gnu fails with FAIL: gfortran.dg/pr93263_1.f90 -O scan-tree-dump-not original "integer\\(kind=4\\) a"
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 --- Comment #12 from markeggleston at gcc dot gnu.org --- Committed: master https://gcc.gnu.org/g:e4a5f73449d7352ba8128fecbc9a9570d746abdb releases/gcc-9 https://gcc.gnu.org/g:f158d9197de75187fa0db26b74bc5d16b5aae242 Updated to URLs.
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 markeggleston at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from markeggleston at gcc dot gnu.org --- Committed: master e4a5f73449d7352ba8128fecbc9a9570d746abdb releases/gcc-9 f158d9197de75187fa0db26b74bc5d16b5aae242
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.3
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 --- Comment #10 from markeggleston at gcc dot gnu.org --- This is relevant: https://gcc.gnu.org/ml/fortran/2017-12/msg00082.html since the non_recursive keyword is not yet recognised by gfortran, I think it SHOULD be postponed.
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 --- Comment #9 from markeggleston at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #7) > (In reply to Tobias Burnus from comment #5) > > Side remark: The Fortran 2018 introduction states: > > > > "the RECURSIVE keyword is advisory only. The NON_RECURSIVE keyword specifies > > that a procedure is not recursive." > > That's a Fortran 2018 change, see also PR 91413 … > > I am not quite sure what implications this have for -fno-automatic > -frecursive etc. As those are vendor extensions, it probably just means that > one just needs to update the documentation. So for Fortran 2018 the default for a procedure should be recursive and prior to Fortran 2018 it should should not. The default standard is GNU which includes everything up Fortran 2018 plus extensions. When this is used I expect that no thought has been made regarding the standard so simply implementing the above would break existing programs. Should this issue be postponed to the stage 1?
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 --- Comment #8 from markeggleston at gcc dot gnu.org --- The change to: if (ns->save_all || (!flag_automatic && !recursive)) Now allows the second example program to produce: Hello 1 Hello 2 Hello 3 Hello 4 Hello 5 instead of: Hello 1 Hello 32766 STOP 1 I'll add the second program as a test case.
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 Tobias Burnus changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=91413 --- Comment #7 from Tobias Burnus --- (In reply to Tobias Burnus from comment #5) > Side remark: The Fortran 2018 introduction states: > > "the RECURSIVE keyword is advisory only. The NON_RECURSIVE keyword specifies > that a procedure is not recursive." That's a Fortran 2018 change, see also PR 91413 … I am not quite sure what implications this have for -fno-automatic -frecursive etc. As those are vendor extensions, it probably just means that one just needs to update the documentation.
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 --- Comment #6 from markeggleston at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #5) > (In reply to markeggleston from comment #4) > > - if (ns->save_all || !flag_automatic) > > + if (!recursive && (ns->save_all || !flag_automatic)) > > > Does the trick. Now need to write the test cases and prepare a patch. > > I wonder whether it should be rather: > if (ns->save_all || (!flag_automatic && !recursive)) That's clearer. > > I think your patch would break for the following code. And I believe it is > standard conform Fortran 90/2018: I'll check and reconsider if it does. > > integer :: cnt > cnt = 0 > call sub() > if (cnt /= 5) stop 1 > contains > recursive subroutine sub() > save > logical :: first = .true. > integer :: i > cnt = cnt + 1 > if (first) then > first = .false. > i = 1 > end if > print *, "Hello", i > i = i + 1 > if (i <= 5) call sub() > end subroutine > end > > * * * > > Side remark: The Fortran 2018 introduction states: > > "the RECURSIVE keyword is advisory only. The NON_RECURSIVE keyword specifies > that a procedure is not recursive." > > Hence, I wonder whether this is correctly implemented in gfortran …
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 --- Comment #5 from Tobias Burnus --- (In reply to markeggleston from comment #4) > - if (ns->save_all || !flag_automatic) > + if (!recursive && (ns->save_all || !flag_automatic)) > Does the trick. Now need to write the test cases and prepare a patch. I wonder whether it should be rather: if (ns->save_all || (!flag_automatic && !recursive)) I think your patch would break for the following code. And I believe it is standard conform Fortran 90/2018: integer :: cnt cnt = 0 call sub() if (cnt /= 5) stop 1 contains recursive subroutine sub() save logical :: first = .true. integer :: i cnt = cnt + 1 if (first) then first = .false. i = 1 end if print *, "Hello", i i = i + 1 if (i <= 5) call sub() end subroutine end * * * Side remark: The Fortran 2018 introduction states: "the RECURSIVE keyword is advisory only. The NON_RECURSIVE keyword specifies that a procedure is not recursive." Hence, I wonder whether this is correctly implemented in gfortran …
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 markeggleston at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |markeggleston at gcc dot gnu.org --- Comment #4 from markeggleston at gcc dot gnu.org --- diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c index 6f2a4c4d65a..4c009a65287 100644 --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -17079,6 +17079,7 @@ resolve_types (gfc_namespace *ns) gfc_data *d; gfc_equiv *eq; gfc_namespace* old_ns = gfc_current_ns; + bool recursive = ns->proc_name && ns->proc_name->attr.recursive; if (ns->types_resolved) return; @@ -17132,7 +17133,7 @@ resolve_types (gfc_namespace *ns) gfc_traverse_ns (ns, resolve_values); - if (ns->save_all || !flag_automatic) + if (!recursive && (ns->save_all || !flag_automatic)) gfc_save_all (ns); iter_stack = NULL; Does the trick. Now need to write the test cases and prepare a patch.
[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-15 CC||burnus at gcc dot gnu.org, ||dominiq at gcc dot gnu.org Known to work||8.3.1 Summary|-fno-automatic and |[9/10 Regression] |RECURSIVE |-fno-automatic and ||RECURSIVE Ever confirmed|0 |1 Known to fail||10.0, 9.2.1 --- Comment #3 from Tobias Burnus --- GCC 8 (8.3.1 20200110) shows "8" in the last line. GCC 9 + 10/trunk show "9" -> Hence, it is a regression. My bet would be that it has been caused by the fix for PR 37835, r268098 – in particular the following bit: --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -16675,3 +16675,3 @@ resolve_types (gfc_namespace *ns) - if (ns->save_all) + if (ns->save_all || !flag_automatic) gfc_save_all (ns);
