Fortran: ICE with elemental and dummy argument with VALUE attribute [PR107819]
Checks
Commit Message
Dear Fortranners,
in dependency checking of arguments of elemental prodecures
we should treat dummy arguments with the value attribute as
implicitly having intent(in). This is simple and obvious.
The PR by Gerhard provides a series of testcases that are
either valid (like the one in the attached patch), or
arguably non-conforming. The issue is related to the
standard prescribing a temporary (in standardese language)
for the argument with the value attribute, while the
elemental attribute prescribes an application order.
Playing with other compiler brands, there seemed to be an
obvious discrepancy between NAG and Intel on the one side
and Intel on the other. Steve Lionel attributed this to
non-conformance for the discussed case (see link in PR).
I therefore decided to only use a conforming testcase
for the testsuite, as this is sufficient to check for
the fix for the ICE.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
Comments
Le 27/11/2022 à 21:32, Harald Anlauf via Fortran a écrit :
> Dear Fortranners,
>
> in dependency checking of arguments of elemental prodecures
> we should treat dummy arguments with the value attribute as
> implicitly having intent(in). This is simple and obvious.
>
> The PR by Gerhard provides a series of testcases that are
> either valid (like the one in the attached patch), or
> arguably non-conforming. The issue is related to the
> standard prescribing a temporary (in standardese language)
> for the argument with the value attribute, while the
> elemental attribute prescribes an application order.
>
> Playing with other compiler brands, there seemed to be an
> obvious discrepancy between NAG and Intel on the one side
> and Intel on the other. Steve Lionel attributed this to
> non-conformance for the discussed case (see link in PR).
>
> I therefore decided to only use a conforming testcase
> for the testsuite, as this is sufficient to check for
> the fix for the ICE.
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
Yes.
Thanks.
From c6f9d47f2e631a7ace71466ba6ec6f323d791b1b Mon Sep 17 00:00:00 2001
From: Harald Anlauf <anlauf@gmx.de>
Date: Sun, 27 Nov 2022 21:10:18 +0100
Subject: [PATCH] Fortran: ICE with elemental and dummy argument with VALUE
attribute [PR107819]
gcc/fortran/ChangeLog:
PR fortran/107819
* trans-stmt.cc (gfc_conv_elemental_dependencies): In checking for
elemental dependencies, treat dummy argument with VALUE attribute
as implicitly having intent(in).
gcc/testsuite/ChangeLog:
PR fortran/107819
* gfortran.dg/elemental_dependency_7.f90: New test.
---
gcc/fortran/trans-stmt.cc | 1 +
.../gfortran.dg/elemental_dependency_7.f90 | 28 +++++++++++++++++++
2 files changed, 29 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/elemental_dependency_7.f90
@@ -264,6 +264,7 @@ gfc_conv_elemental_dependencies (gfc_se * se, gfc_se * loopse,
if (e->expr_type == EXPR_VARIABLE
&& e->rank && fsym
&& fsym->attr.intent != INTENT_IN
+ && !fsym->attr.value
&& gfc_check_fncall_dependency (e, fsym->attr.intent,
sym, arg0, check_variable))
{
new file mode 100644
@@ -0,0 +1,28 @@
+! { dg-do run }
+! PR fortran/107819 - ICE in gfc_check_argument_var_dependency
+! Contributed by G.Steinmetz
+!
+! Note: the testcase is considered non-conforming for m>1 due to aliasing
+
+program p
+ implicit none
+ integer, parameter :: m = 1
+ integer :: i
+ integer :: a(m) = [(-i,i=1,m)]
+ integer :: n(m) = [(i,i=m,1,-1)]
+ integer :: b(m)
+ b = a
+ call s (a(n), a) ! { dg-warning "might interfere with actual argument" }
+
+ ! Compare to separate application of subroutine in element order
+ do i = 1, size (b)
+ call s (b(n(i)), b(i))
+ end do
+ if (any (a /= b)) stop 1
+contains
+ elemental subroutine s (x, y)
+ integer, value :: x
+ integer, intent(out) :: y
+ y = x
+ end
+end
--
2.35.3