diff mbox series

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

Message ID trinity-2d7545f7-09e7-44d8-ba71-166690b820a8-1669581157254@3c-app-gmx-bap47
State New
Headers show
Series Fortran: ICE with elemental and dummy argument with VALUE attribute [PR107819] | expand

Commit Message

Harald Anlauf Nov. 27, 2022, 8:32 p.m. UTC 
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

Mikael Morin Nov. 28, 2022, 11:54 a.m. UTC | #1 
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.
diff mbox series

Patch

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