[Patch] Fortran: Fix gfc_maybe_dereference_var [PR104430]

[Patch] Fortran: Fix gfc_maybe_dereference_var [PR104430]

[Tobias Burnus]

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

The problem is that inside the main program,
   y = f(z)
where the the result of z is
   type(t) :: z(size(x%a))
and 'x' is a dummy argument.

'x' looses the attr.dummy in gfc_add_interface_mapping
and this leads to an additional indirect ref in
gfc_maybe_dereference_var - but after the first indirect
ref, TREE_TYPE is alread a RECORD_TYPE ...

The simple fix is to simply punt when the argument
is not a pointer or reference.

This patch additionally fixes a comment in
conv_parent_component_references.

Those parts are obvious. The only potentially risky
change is the comparison change from a name-wise comparison
to a pointer-based comparison. I think it is fine and the
testsuite did not find any issue, but you prefer, I can
also exclude it.

OK for mainline? How about GCC 10/11 backports?
(I think leaving out the last change, it should be very safe to do.)

Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

[-- Attachment #2: pr104430-class-result.diff --]
[-- Type: text/x-patch, Size: 2099 bytes --]

Fortran: Fix gfc_maybe_dereference_var [PR104430]

	PR fortran/104430

gcc/fortran/ChangeLog:

	* trans-expr.cc (conv_parent_component_references): Fix comment;
	simplify comparison.
	(gfc_maybe_dereference_var): Avoid derefereing a nonpointer

gcc/testsuite/ChangeLog:

	* gfortran.dg/class_result_10.f90: New test.

 gcc/fortran/trans-expr.cc                     |  6 ++++--
 gcc/testsuite/gfortran.dg/class_result_10.f90 | 25 +++++++++++++++++++++++++
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index eb6a78c3a62..e441952818b 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -2805,9 +2805,9 @@ conv_parent_component_references (gfc_se * se, gfc_ref * ref)
   dt = ref->u.c.sym;
   c = ref->u.c.component;
 
-  /* Return if the component is in the parent type.  */
+  /* Return if the component is in this type, i.e. not in the parent type.  */
   for (cmp = dt->components; cmp; cmp = cmp->next)
-    if (strcmp (c->name, cmp->name) == 0)
+    if (c == cmp)
       return;
 
   /* Build a gfc_ref to recursively call gfc_conv_component_ref.  */
@@ -2867,6 +2867,8 @@ tree
 gfc_maybe_dereference_var (gfc_symbol *sym, tree var, bool descriptor_only_p,
 			   bool is_classarray)
 {
+  if (!POINTER_TYPE_P (TREE_TYPE (var)))
+    return var;
   if (is_CFI_desc (sym, NULL))
     return build_fold_indirect_ref_loc (input_location, var);
 
diff --git a/gcc/testsuite/gfortran.dg/class_result_10.f90 b/gcc/testsuite/gfortran.dg/class_result_10.f90
new file mode 100644
index 00000000000..acd9a73ebda
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/class_result_10.f90
@@ -0,0 +1,25 @@
+! { dg-do run}
+!
+! PR fortran/104430
+!
+! Contributed by  G. Steinmetz 
+
+module m
+   type t
+      integer :: a
+   end type
+contains
+   function f(x) result(z)
+      class(t) :: x(:)
+      type(t) :: z(size(x%a))
+      z%a = 42
+   end
+end
+program p
+   use m
+   class(t), allocatable :: y(:), z(:)
+   allocate (y(32))
+   z = f(y)
+   if (size(z) /= 32) stop 1
+   if (any (z%a /= 42)) stop 2
+end

Re: [Patch] Fortran: Fix gfc_maybe_dereference_var [PR104430]

[Harald Anlauf]

Hi Tobias,

Am 07.03.22 um 15:01 schrieb Tobias Burnus:
> The problem is that inside the main program,
>    y = f(z)
> where the the result of z is
>    type(t) :: z(size(x%a))
> and 'x' is a dummy argument.
>
> 'x' looses the attr.dummy in gfc_add_interface_mapping
> and this leads to an additional indirect ref in
> gfc_maybe_dereference_var - but after the first indirect
> ref, TREE_TYPE is alread a RECORD_TYPE ...
>
> The simple fix is to simply punt when the argument
> is not a pointer or reference.
>
> This patch additionally fixes a comment in
> conv_parent_component_references.

LGTM.  Regarding the commit message, there should be a period
at the end of

 >        (gfc_maybe_dereference_var): Avoid derefereing a nonpointer


I think there are other PRs which profit from this fix.
Can you please have a look at PR99585, and in particular
the link in comment#0?  ;-)

> Those parts are obvious. The only potentially risky
> change is the comparison change from a name-wise comparison
> to a pointer-based comparison. I think it is fine and the
> testsuite did not find any issue, but you prefer, I can
> also exclude it.

I was thinking about this, too.  But your change will prevent
running into trouble in the (unlikely?) case c being a NULL pointer.

> OK for mainline? How about GCC 10/11 backports?
> (I think leaving out the last change, it should be very safe to do.)

OK, as this is both an ICE-on-valid and a regression.

Thanks for the patch!

Harald

> Tobias
> -----------------
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
> 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
> Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München;
> Registergericht München, HRB 106955

Re: [Patch] Fortran: Fix gfc_maybe_dereference_var [PR104430]

[Tobias Burnus]

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

Hi Harald,

On 07.03.22 20:58, Harald Anlauf wrote:
> I think there are other PRs which profit from this fix.
> Can you please have a look at PR99585, and in particular
> the link in comment#0?  ;-)

Good pointer – the testcase looks nearly identical and it is indeed fixed.

I included it in addition in the same testcase file. (See attached patch
for the commit,  .)

Thanks,

Tobias

PS: Can I make you review my two pending patches? (NULL and SIZEOF) ;-)

PPS: I lost a bit track working on other things – are there patches
pending review?

PPPS: I think someone still has to deal with the approved and pending
patches by José ...
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

[-- Attachment #2: committed.diff --]
[-- Type: text/x-patch, Size: 2741 bytes --]

commit c0134b7383992aab5c1a91440dbdd8fbb747169c
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Mon Mar 7 22:11:33 2022 +0100

    Fortran: Fix gfc_maybe_dereference_var [PR104430][PR99585]
    
            PR fortran/99585
            PR fortran/104430
    
    gcc/fortran/ChangeLog:
    
            * trans-expr.cc (conv_parent_component_references): Fix comment;
            simplify comparison.
            (gfc_maybe_dereference_var): Avoid d referencing a nonpointer.
    
    gcc/testsuite/ChangeLog:
    
            * gfortran.dg/class_result_10.f90: New test.

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index c9d9a916c28..71d037101d4 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -2805,9 +2805,9 @@ conv_parent_component_references (gfc_se * se, gfc_ref * ref)
   dt = ref->u.c.sym;
   c = ref->u.c.component;
 
-  /* Return if the component is in the parent type.  */
+  /* Return if the component is in this type, i.e. not in the parent type.  */
   for (cmp = dt->components; cmp; cmp = cmp->next)
-    if (strcmp (c->name, cmp->name) == 0)
+    if (c == cmp)
       return;
 
   /* Build a gfc_ref to recursively call gfc_conv_component_ref.  */
@@ -2867,6 +2867,8 @@ tree
 gfc_maybe_dereference_var (gfc_symbol *sym, tree var, bool descriptor_only_p,
 			   bool is_classarray)
 {
+  if (!POINTER_TYPE_P (TREE_TYPE (var)))
+    return var;
   if (is_CFI_desc (sym, NULL))
     return build_fold_indirect_ref_loc (input_location, var);
 
diff --git a/gcc/testsuite/gfortran.dg/class_result_10.f90 b/gcc/testsuite/gfortran.dg/class_result_10.f90
new file mode 100644
index 00000000000..a4d29ab9c1d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/class_result_10.f90
@@ -0,0 +1,52 @@
+! { dg-do run}
+
+
+! PR fortran/99585
+
+module m2
+  type t
+     class(*), pointer :: bar(:)
+  end type
+  type t2
+     class(t), allocatable :: my(:)
+  end type t2
+contains
+  function f (x, y) result(z)
+    class(t) :: x(:)
+    class(t) :: y(size(x(1)%bar))
+    type(t)  :: z(size(x(1)%bar))
+  end
+  function g (x) result(z)
+    class(t) :: x(:)
+    type(t)  :: z(size(x(1)%bar))
+  end
+  subroutine s ()
+    class(t2), allocatable :: a(:), b(:), c(:), d(:)
+    class(t2), pointer     :: p(:)
+    c(1)%my = f (a(1)%my, b(1)%my)
+    d(1)%my = g (p(1)%my)
+  end
+end
+
+! Contributed by  G. Steinmetz:
+! PR fortran/104430
+
+module m
+   type t
+      integer :: a
+   end type
+contains
+   function f(x) result(z)
+      class(t) :: x(:)
+      type(t) :: z(size(x%a))
+      z%a = 42
+   end
+end
+program p
+   use m
+   class(t), allocatable :: y(:), z(:)
+   allocate (y(32))
+   z = f(y)
+   if (size(z) /= 32) stop 1
+   if (any (z%a /= 42)) stop 2
+end

Re: [Patch] Fortran: Fix gfc_maybe_dereference_var [PR104430]

[Harald Anlauf]

Hi Tobias,

Am 08.03.22 um 21:19 schrieb Tobias Burnus:
> PS: Can I make you review my two pending patches? (NULL and SIZEOF) ;-)

I just approved the former one, but rather hope that Paul or Mikael
or somebody else would jump in on the other one.

> PPS: I lost a bit track working on other things – are there patches
> pending review?
>
> PPPS: I think someone still has to deal with the approved and pending
> patches by José ...

What did prevent them getting processed after approval?

Cheers,
Harald

Re: [Patch] Fortran: Fix gfc_maybe_dereference_var [PR104430]

[Harald Anlauf]

Hi Tobias,

Am 08.03.22 um 21:19 schrieb Tobias Burnus:
> PS: Can I make you review my two pending patches? (NULL and SIZEOF) ;-)

I just approved the former one, but rather hope that Paul or Mikael
or somebody else would jump in on the other one.

> PPS: I lost a bit track working on other things – are there patches
> pending review?
> 
> PPPS: I think someone still has to deal with the approved and pending
> patches by José ...

What did prevent them getting processed after approval?

Cheers,
Harald