public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* Proxy ping [PATCH] Fortran: Fix function attributes [PR100132]
@ 2022-09-19 20:17 Harald Anlauf
  2022-09-20  9:28 ` Mikael Morin
  0 siblings, 1 reply; 2+ messages in thread
From: Harald Anlauf @ 2022-09-19 20:17 UTC (permalink / raw)
  To: fortran, gcc-patches

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

Dear all,

the following patch was submitted by Jose but never reviewed:

https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html

Before, we didn't set function attributes properly when
passing polymorphic pointers, which could lead to
mis-optimization.

The patch is technically fine and regtests ok, although it
can be shortened slightly, which makes it more readable,
see attached.

When testing the suggested testcase I found that it was
accepted (and working fine) with NAG, but it was rejected
by both Intel and Cray.  This troubled me, but I think
it is standard conforming (F2018:15.5.2.7), while the
error messages issued by Intel

PR100132.f90(61): error #8300: If a dummy argument is allocatable or a pointer, and the dummy or its associated actual argument is polymorphic, both dummy and actual must be polymorphic with the same declared type or both must be unlimited polymorphic.   [S]
    call set(s)
-------------^

and a similar one by Cray, suggest that they refer to
F2018:15.5.2.5, which IMHO does not apply here.
(The text in the error message seems very related to
the reasoning in Note 1 of that subsection).

I'd like to hear (read: read) a second opinion on that.

Thanks,
Harald


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

From 0b19cfc098554572279c8d19997df4823b426191 Mon Sep 17 00:00:00 2001
From: Harald Anlauf <anlauf@gmx.de>
Date: Mon, 19 Sep 2022 22:00:45 +0200
Subject: [PATCH] Fortran: Fix function attributes [PR100132]

gcc/fortran/ChangeLog:

	PR fortran/100132
	* trans-types.cc (create_fn_spec): Fix function attributes when
	passing polymorphic pointers.

gcc/testsuite/ChangeLog:

	PR fortran/100132
	* gfortran.dg/PR100132.f90: New test.
---
 gcc/fortran/trans-types.cc             | 15 +++++-
 gcc/testsuite/gfortran.dg/PR100132.f90 | 75 ++++++++++++++++++++++++++
 2 files changed, 88 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/PR100132.f90

diff --git a/gcc/fortran/trans-types.cc b/gcc/fortran/trans-types.cc
index 0ea7c74a6f1..c062a5b29d7 100644
--- a/gcc/fortran/trans-types.cc
+++ b/gcc/fortran/trans-types.cc
@@ -3054,12 +3054,23 @@ create_fn_spec (gfc_symbol *sym, tree fntype)
   for (f = gfc_sym_get_dummy_args (sym); f; f = f->next)
     if (spec_len < sizeof (spec))
       {
-	if (!f->sym || f->sym->attr.pointer || f->sym->attr.target
+	bool is_class = false;
+	bool is_pointer = false;
+
+	if (f->sym)
+	  {
+	    is_class = f->sym->ts.type == BT_CLASS && CLASS_DATA (f->sym)
+	      && f->sym->attr.class_ok;
+	    is_pointer = is_class ? CLASS_DATA (f->sym)->attr.class_pointer
+				  : f->sym->attr.pointer;
+	  }
+
+	if (f->sym == NULL || is_pointer || f->sym->attr.target
 	    || f->sym->attr.external || f->sym->attr.cray_pointer
 	    || (f->sym->ts.type == BT_DERIVED
 		&& (f->sym->ts.u.derived->attr.proc_pointer_comp
 		    || f->sym->ts.u.derived->attr.pointer_comp))
-	    || (f->sym->ts.type == BT_CLASS
+	    || (is_class
 		&& (CLASS_DATA (f->sym)->ts.u.derived->attr.proc_pointer_comp
 		    || CLASS_DATA (f->sym)->ts.u.derived->attr.pointer_comp))
 	    || (f->sym->ts.type == BT_INTEGER && f->sym->ts.is_c_interop))
diff --git a/gcc/testsuite/gfortran.dg/PR100132.f90 b/gcc/testsuite/gfortran.dg/PR100132.f90
new file mode 100644
index 00000000000..78ae6702810
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR100132.f90
@@ -0,0 +1,75 @@
+! { dg-do run }
+!
+! Test the fix for PR100132
+!
+
+module main_m
+  implicit none
+
+  private
+
+  public :: &
+    foo_t
+
+  public :: &
+    set,    &
+    get
+
+  type :: foo_t
+    integer :: i
+  end type foo_t
+
+  type(foo_t), save, pointer :: data => null()
+
+contains
+
+  subroutine set(this)
+    class(foo_t), pointer, intent(in) :: this
+
+    if(associated(data)) stop 1
+    data => this
+  end subroutine set
+
+  subroutine get(this)
+    type(foo_t), pointer, intent(out) :: this
+
+    if(.not.associated(data)) stop 4
+    this => data
+    nullify(data)
+  end subroutine get
+
+end module main_m
+
+program main_p
+
+  use :: main_m, only: &
+    foo_t, set, get
+
+  implicit none
+
+  integer, parameter :: n = 1000
+
+  type(foo_t), pointer :: ps
+  type(foo_t),  target :: s
+  integer              :: i, j, yay, nay
+
+  yay = 0
+  nay = 0
+  do i = 1, n
+    s%i = i
+    call set(s)
+    call get(ps)
+    if(.not.associated(ps)) stop 13
+    j = ps%i
+    if(i/=j) stop 14
+    if(i/=s%i) stop 15
+    if(ps%i/=s%i) stop 16
+    if(associated(ps, s))then
+      yay = yay + 1
+    else
+      nay = nay + 1
+    end if
+  end do
+  if((yay/=n).or.(nay/=0)) stop 17
+
+end program main_p
--
2.35.3


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Proxy ping [PATCH] Fortran: Fix function attributes [PR100132]
  2022-09-19 20:17 Proxy ping [PATCH] Fortran: Fix function attributes [PR100132] Harald Anlauf
@ 2022-09-20  9:28 ` Mikael Morin
  0 siblings, 0 replies; 2+ messages in thread
From: Mikael Morin @ 2022-09-20  9:28 UTC (permalink / raw)
  To: Harald Anlauf, fortran, gcc-patches

Hello,

Le 19/09/2022 à 22:17, Harald Anlauf via Fortran a écrit :
> Dear all,
> 
> the following patch was submitted by Jose but never reviewed:
> 
> https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html
> 
> Before, we didn't set function attributes properly when
> passing polymorphic pointers, which could lead to
> mis-optimization.
> 
> The patch is technically fine and regtests ok, although it
> can be shortened slightly, which makes it more readable,
> see attached.
> 
> When testing the suggested testcase I found that it was
> accepted (and working fine) with NAG, but it was rejected
> by both Intel and Cray.  This troubled me, but I think
> it is standard conforming (F2018:15.5.2.7), while the
> error messages issued by Intel
> 
> PR100132.f90(61): error #8300: If a dummy argument is allocatable or a pointer, and the dummy or its associated actual argument is polymorphic, both dummy and actual must be polymorphic with the same declared type or both must be unlimited polymorphic.   [S]
>      call set(s)
> -------------^
> 
> and a similar one by Cray, suggest that they refer to
> F2018:15.5.2.5, which IMHO does not apply here.
> (The text in the error message seems very related to
> the reasoning in Note 1 of that subsection).
> 
> I'd like to hear (read: read) a second opinion on that.
> 
I think you are correct.
If the dummy wasn't INTENT(IN) the actual argument would have to be a 
pointer, and then 15.5.2.5 would apply, but it's not the case here.
With INTENT(IN) the reasons for the constraints from Note 1 don't apply.

I think you can go ahead.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-09-20  9:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-19 20:17 Proxy ping [PATCH] Fortran: Fix function attributes [PR100132] Harald Anlauf
2022-09-20  9:28 ` Mikael Morin

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).