public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Harald Anlauf <anlauf@gmx.de>
To: fortran <fortran@gcc.gnu.org>, gcc-patches <gcc-patches@gcc.gnu.org>
Subject: [PATCH] Fortran: ICE with elemental and dummy argument with VALUE attribute [PR107819]
Date: Sun, 27 Nov 2022 21:32:37 +0100	[thread overview]
Message-ID: <trinity-2d7545f7-09e7-44d8-ba71-166690b820a8-1669581157254@3c-app-gmx-bap47> (raw)

[-- 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


             reply	other threads:[~2022-11-27 20:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-27 20:32 Harald Anlauf [this message]
2022-11-28 11:54 ` Mikael Morin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=trinity-2d7545f7-09e7-44d8-ba71-166690b820a8-1669581157254@3c-app-gmx-bap47 \
    --to=anlauf@gmx.de \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).