Proxy ping [PATCH] Fortran: Fix function attributes [PR100132]
Commit Message
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
Comments
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.
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
@@ -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))
new file mode 100644
@@ -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