Fortran 15.0.1 treats "shiftl" as impure
Hello, After a recent upgrade from Fedora 41 to 42 the gfortran got updated from 14 to 15.0.1: [chris@fedora FITSWEBQLSE]$ gfortran --version GNU Fortran (GCC) 15.0.1 20250329 (Red Hat 15.0.1-0) The new version 15.0.1 seems to treat "shiftl" elemental intrinsic functions as IMPURE. As a consequence "shiftl" cannot be used inside DO CONCURRENT anymore: Error: Reference to impure function at (1) inside a DO CONCURRENT src/fixed_array.f90:118:27: 118 | x1 = 1 + shiftl(i - 1, BASE) | 1 Error: Reference to impure function at (1) inside a DO CONCURRENT src/fixed_array.f90:119:24: 119 | x2 = min(n, shiftl(i, BASE)) |1 Error: Reference to impure function at (1) inside a DO CONCURRENT src/fixed_array.f90:121:27: 121 | y1 = 1 + shiftl(j - 1, BASE) | 1 Error: Reference to impure function at (1) inside a DO CONCURRENT src/fixed_array.f90:122:24: 122 | y2 = min(m, shiftl(j, BASE)) |1 Error: Reference to impure function at (1) inside a DO CONCURRENT This has never happened before. The code used to compile fine under prior gfortran versions 10, 11, 12, 13 and 14. Is this a bug in the new gfortran v15 series or is this a deliberate design decision made by gfortran developers? Would this be fixed in the gfortran 15.1? Regards, Christopher Zapart National Astronomical Observatory in Japan
Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support
On 4/13/25 11:47 PM, Andre Vehreschild wrote: Hi Jerry, thank you very much for the review. I would love to fix the nits you found, but I don't see, what you see. Can you elaborate? May be some mail client has removed something, or I am missing something. Are you commenting on gfc_error ( "%s argument at %L must be a scalar %s variable of at least kind %d", that this is formatted like this, i.e. the string in the next line? That is clang-format's doing. That formatter is getting worse in each iteration. I see this in the second and third chunk of your comment, too. Is this what you like me to fix? I just want to prevent overlooking some typo or the like. Thanks again and regards, Andre Yes, there appears to be some line breaks out of place like this one below. I only saw those in the one file after applying the patch. It is not critical, so proceed as you prefer. Thanks, Jerry --- snip --- gfc_resolve_expr (e); if (e && (e->ts.type != exp_type || e->ts.kind < exp_kind || e->rank != 0 || e->expr_type != EXPR_VARIABLE)) gfc_error ( "%s argument at %L must be a scalar %s variable of at least kind %d", name, &e->where, gfc_basic_typename (exp_type), exp_kind);
[PATCH] Fortran: pure subroutine with pure procedure as dummy [PR106948]
Dear all,
the testcase in the PR shows a case where the pureness of a function
is not properly determined, even though the function is resolved, and
its attributes clearly show that it is pure, because gfc_pure_function
relies on isym or esym being set. This does not happen here, probably
because the function is used as a dummy here.
The least invasive fix seems to be to look at the symbol's attributes
when isym or esym is not set.
Regression testing lead to additional redundant error messages for two
testcases, so I opted to restrict the change to the case of functions
as dummy arguments, making this patch very safe.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 5ebb5bb438e8ccf6ea30559604a9f27a75dea0ef Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 15 Apr 2025 20:43:05 +0200
Subject: [PATCH] Fortran: pure subroutine with pure procedure as dummy
[PR106948]
PR fortran/106948
gcc/fortran/ChangeLog:
* resolve.cc (gfc_pure_function): If a function has been resolved,
but esym is not yet set, look at its attributes to see whether it
is pure or elemental.
gcc/testsuite/ChangeLog:
* gfortran.dg/pure_formal_proc_4.f90: New test.
---
gcc/fortran/resolve.cc| 7 +++
.../gfortran.dg/pure_formal_proc_4.f90| 49 +++
2 files changed, 56 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/pure_formal_proc_4.f90
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index cdf043b6411..410ff685906 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -3190,6 +3190,13 @@ gfc_pure_function (gfc_expr *e, const char **name)
|| e->value.function.isym->elemental;
*name = e->value.function.isym->name;
}
+ else if (e->symtree && e->symtree->n.sym && e->symtree->n.sym->attr.dummy)
+{
+ /* The function has been resolved, but esym is not yet set.
+ This can happen with functions as dummy argument. */
+ pure = e->symtree->n.sym->attr.pure || e->symtree->n.sym->attr.elemental;
+ *name = e->symtree->n.sym->name;
+}
else
{
/* Implicit functions are not pure. */
diff --git a/gcc/testsuite/gfortran.dg/pure_formal_proc_4.f90 b/gcc/testsuite/gfortran.dg/pure_formal_proc_4.f90
new file mode 100644
index 000..92640e2d2f4
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pure_formal_proc_4.f90
@@ -0,0 +1,49 @@
+! { dg-do compile }
+! PR fortran/106948 - check that passing of PURE procedures works
+!
+! Contributed by Jim Feng
+
+module a
+ implicit none
+
+ interface new
+pure module subroutine b(x, f)
+ integer, intent(inout) :: x
+ interface
+pure function f(x) result(r)
+ real, intent(in) :: x
+ real :: r
+end function f
+ end interface
+end subroutine b
+ end interface new
+end module a
+
+submodule(a) a_b
+ implicit none
+
+contains
+ module procedure b
+x = int(f(real(x)) * 0.15)
+ end procedure b
+end submodule a_b
+
+program test
+ use a
+ implicit none
+
+ integer :: x
+
+ x = 100
+ call new(x, g)
+ print *, x
+
+contains
+
+ pure function g(y) result(r)
+real, intent(in) :: y
+real :: r
+
+r = sqrt(y)
+ end function g
+end program test
--
2.43.0
Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support
On 4/10/25 5:59 AM, Andre Vehreschild wrote:
Hi all,
I again have a series of patches. This time to improve the teams support in
gfortran.
1/5: Improves/Unifies handling of STAT= and ERRMSG= handling, which is part of
all TEAM statements. I wanted to prevent repeating myself over and over so I
factored this out (DRY principle). Because the standard's rule name for this is
sync_stat the structure to store the information in gfc_code is named like that.
2/5: Rework (FORM|CHANGE|END|SYNC) TEAM and CRITICAL to use sync_stat and
adhere to F2018 standard as much as possible. Because CHANGE TEAM has kind of
an association list (but for coarrays only), I choose to factor out that
parsing and other preparations from ASSOCIATE. Added support to caf_single for
testing.
3/5: Update/Implement get_team()/team_number() and image_status() parsing and
also add testcases as well as support in caf_single.
4/5: Update this_image() parsing and treatment as well as adding testcases and
support in caf_single.
5/5: Update image_index() and num_images() support also in caf_single.
All patches together have been bootstrapped and regtested ok on
x86_64-pc-linux-gnu.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
I have reviewed the five patches and have the following nits shown
below. These are simply white space fixes.
I had a couple of reject hunks in intrinsics.texi when applying the
patches.
All applies cleanly and regression tests here as well.
It looks OK to commit.
Regards,
Jerry
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -11467,12 +11467,11 @@ resolve_scalar_variable_as_arg (const char
*name, bt exp_type, int exp_kind,
gfc_expr *e)
{
gfc_resolve_expr (e);
if (e
&& (e->ts.type != exp_type || e->ts.kind < exp_kind || e->rank != 0
|| e->expr_type != EXPR_VARIABLE))
gfc_error (
"%s argument at %L must be a scalar %s variable of at least kind %d",
name, &e->where, gfc_basic_typename (exp_type), exp_kind);
@@ -11685,8 +11684,7 @@ resolve_branch (gfc_st_label *label, gfc_code *code)
if (code->here == label)
{
gfc_warning (0,
"Branch at %L may result in an infinite loop", &code->loc);
return;
}
@@ -11753,8 +11751,7 @@ resolve_branch (gfc_st_label *label, gfc_code *code)
allowed in Fortran 66, so we allow it as extension. No
further checks are necessary in this case. */
gfc_notify_std (GFC_STD_LEGACY, "Label at %L is not in the same block "
"as the GOTO statement at %L", &label->where, &code->loc);
Re: [PATCH] Fortran: pure subroutine with pure procedure as dummy [PR106948]
On 4/15/25 12:01 PM, Harald Anlauf wrote: Dear all, the testcase in the PR shows a case where the pureness of a function is not properly determined, even though the function is resolved, and its attributes clearly show that it is pure, because gfc_pure_function relies on isym or esym being set. This does not happen here, probably because the function is used as a dummy here. The least invasive fix seems to be to look at the symbol's attributes when isym or esym is not set. Regression testing lead to additional redundant error messages for two testcases, so I opted to restrict the change to the case of functions as dummy arguments, making this patch very safe. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Yes, OK for mainline. Thanks Herald Jerry
