[PATCH] Fortran: ICE with elemental and dummy argument with VALUE attribute [PR107819]

[PATCH] Fortran: ICE with elemental and dummy argument with VALUE attribute [PR107819]

[Harald Anlauf]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pr107819.diff --]
[-- Type: text/x-patch, Size: 2353 bytes --]

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

diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index fd6d294147e..b288f1f9050 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -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))
 	{
diff --git a/gcc/testsuite/gfortran.dg/elemental_dependency_7.f90 b/gcc/testsuite/gfortran.dg/elemental_dependency_7.f90
new file mode 100644
index 00000000000..ad45ea5271b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/elemental_dependency_7.f90
@@ -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

Re: [PATCH] Fortran: ICE with elemental and dummy argument with VALUE attribute [PR107819]

[Mikael Morin]

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.