public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH 00/10] fortran: clobber fixes [PR41453]
@ 2022-09-16 20:24 Mikael Morin
  2022-09-16 20:24 ` [PATCH 01/10] fortran: Move the clobber generation code Mikael Morin
                   ` (9 more replies)
  0 siblings, 10 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-16 20:24 UTC (permalink / raw)
  To: gcc-patches, fortran

Hello,

this is a set of changes around the clobber we generate in the caller
before a procedure call, for each actual argument whose associated dummy
has the INTENT(OUT) attribute.

The first patch is a refactoring moving the clobber generation in
gfc_conv_procedure_call where it feels more appropriate.
The second patch is a fix for the ICE originally motivating my work
on this topic.
The third patch is a fix for some wrong code issue discovered with an
earlier version of this series.
The following patches are gradual condition loosenings to enable clobber 
generation in more and more cases.

Each patch has been tested through an incremental bootstrap and a
partial testsuite run on fortran *intent* tests, and the whole lot has
been run through the full fortran regression testsuite.
OK for master?


Harald Anlauf (1):
  fortran: Support clobbering with implicit interfaces [PR105012]

Mikael Morin (9):
  fortran: Move the clobber generation code
  fortran: Fix invalid function decl clobber ICE [PR105012]
  fortran: Move clobbers after evaluation of all arguments [PR106817]
  fortran: Support clobbering of reference variables [PR41453]
  fortran: Support clobbering of SAVE variables [PR87395]
  fortran: Support clobbering of ASSOCIATE variables [PR87397]
  fortran: Support clobbering of allocatables and pointers [PR41453]
  fortran: Support clobbering of variable subreferences [PR88364]
  fortran: Support clobbering of derived types [PR41453]

 gcc/fortran/trans-expr.cc                     | 78 ++++++++++++-------
 gcc/fortran/trans.h                           |  3 +-
 .../gfortran.dg/intent_optimize_4.f90         | 24 ++++++
 .../gfortran.dg/intent_optimize_5.f90         | 34 ++++++++
 .../gfortran.dg/intent_optimize_6.f90         | 42 ++++++++++
 .../gfortran.dg/intent_optimize_7.f90         | 65 ++++++++++++++++
 .../gfortran.dg/intent_optimize_8.f90         | 67 ++++++++++++++++
 .../gfortran.dg/intent_optimize_9.f90         | 43 ++++++++++
 gcc/testsuite/gfortran.dg/intent_out_15.f90   | 27 +++++++
 9 files changed, 353 insertions(+), 30 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/intent_optimize_4.f90
 create mode 100644 gcc/testsuite/gfortran.dg/intent_optimize_5.f90
 create mode 100644 gcc/testsuite/gfortran.dg/intent_optimize_6.f90
 create mode 100644 gcc/testsuite/gfortran.dg/intent_optimize_7.f90
 create mode 100644 gcc/testsuite/gfortran.dg/intent_optimize_8.f90
 create mode 100644 gcc/testsuite/gfortran.dg/intent_optimize_9.f90
 create mode 100644 gcc/testsuite/gfortran.dg/intent_out_15.f90

-- 
2.35.1


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

* [PATCH 01/10] fortran: Move the clobber generation code
  2022-09-16 20:24 [PATCH 00/10] fortran: clobber fixes [PR41453] Mikael Morin
@ 2022-09-16 20:24 ` Mikael Morin
  2022-09-16 20:24 ` [PATCH 02/10] fortran: Fix invalid function decl clobber ICE [PR105012] Mikael Morin
                   ` (8 subsequent siblings)
  9 siblings, 0 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-16 20:24 UTC (permalink / raw)
  To: gcc-patches, fortran

This change inlines the clobber generation code from
gfc_conv_expr_reference to the single caller from where the add_clobber
flag can be true, and removes the add_clobber argument.

What motivates this is the standard making the procedure call a cause
for a variable to become undefined, which translates to a clobber
generation, so clobber generation should be closely related to procedure
call generation, whereas it is rather orthogonal to variable reference
generation.  Thus the generation of the clobber feels more appropriate
in gfc_conv_procedure_call than in gfc_conv_expr_reference.

Behaviour remains unchanged.

gcc/fortran/ChangeLog:

	* trans.h (gfc_conv_expr_reference): Remove add_clobber
	argument.
	* trans-expr.cc (gfc_conv_expr_reference): Ditto. Inline code
	depending on add_clobber and conditions controlling it ...
	(gfc_conv_procedure_call): ... to here.
---
 gcc/fortran/trans-expr.cc | 58 +++++++++++++++++++++------------------
 gcc/fortran/trans.h       |  3 +-
 2 files changed, 32 insertions(+), 29 deletions(-)

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 850007fd2e1..7902b941c2d 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6395,7 +6395,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 				&& e->symtree->n.sym->attr.pointer))
 			&& fsym && fsym->attr.target)
 		/* Make sure the function only gets called once.  */
-		gfc_conv_expr_reference (&parmse, e, false);
+		gfc_conv_expr_reference (&parmse, e);
 	      else if (e->expr_type == EXPR_FUNCTION
 		       && e->symtree->n.sym->result
 		       && e->symtree->n.sym->result != e->symtree->n.sym
@@ -6502,22 +6502,36 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 		    }
 		  else
 		    {
-		      bool add_clobber;
-		      add_clobber = fsym && fsym->attr.intent == INTENT_OUT
-			&& !fsym->attr.allocatable && !fsym->attr.pointer
-			&& e->symtree && e->symtree->n.sym
-			&& !e->symtree->n.sym->attr.dimension
-			&& !e->symtree->n.sym->attr.pointer
-			&& !e->symtree->n.sym->attr.allocatable
-			/* See PR 41453.  */
-			&& !e->symtree->n.sym->attr.dummy
-			/* FIXME - PR 87395 and PR 41453  */
-			&& e->symtree->n.sym->attr.save == SAVE_NONE
-			&& !e->symtree->n.sym->attr.associate_var
-			&& e->ts.type != BT_CHARACTER && e->ts.type != BT_DERIVED
-			&& e->ts.type != BT_CLASS && !sym->attr.elemental;
+		      gfc_conv_expr_reference (&parmse, e);
 
-		      gfc_conv_expr_reference (&parmse, e, add_clobber);
+		      if (fsym
+			  && fsym->attr.intent == INTENT_OUT
+			  && !fsym->attr.allocatable
+			  && !fsym->attr.pointer
+			  && e->expr_type == EXPR_VARIABLE
+			  && e->ref == NULL
+			  && e->symtree
+			  && e->symtree->n.sym
+			  && !e->symtree->n.sym->attr.dimension
+			  && !e->symtree->n.sym->attr.pointer
+			  && !e->symtree->n.sym->attr.allocatable
+			  /* See PR 41453.  */
+			  && !e->symtree->n.sym->attr.dummy
+			  /* FIXME - PR 87395 and PR 41453  */
+			  && e->symtree->n.sym->attr.save == SAVE_NONE
+			  && !e->symtree->n.sym->attr.associate_var
+			  && e->ts.type != BT_CHARACTER
+			  && e->ts.type != BT_DERIVED
+			  && e->ts.type != BT_CLASS
+			  && !sym->attr.elemental)
+			{
+			  tree var;
+			  /* FIXME: This fails if var is passed by reference, see PR
+			     41453.  */
+			  var = e->symtree->n.sym->backend_decl;
+			  tree clobber = build_clobber (TREE_TYPE (var));
+			  gfc_add_modify (&se->pre, var, clobber);
+			}
 		    }
 		  /* Catch base objects that are not variables.  */
 		  if (e->ts.type == BT_CLASS
@@ -9485,7 +9499,7 @@ gfc_conv_expr_type (gfc_se * se, gfc_expr * expr, tree type)
    values only.  */
 
 void
-gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr, bool add_clobber)
+gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr)
 {
   gfc_ss *ss;
   tree var;
@@ -9525,16 +9539,6 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr, bool add_clobber)
 	  gfc_add_block_to_block (&se->pre, &se->post);
 	  se->expr = var;
 	}
-      else if (add_clobber && expr->ref == NULL)
-	{
-	  tree clobber;
-	  tree var;
-	  /* FIXME: This fails if var is passed by reference, see PR
-	     41453.  */
-	  var = expr->symtree->n.sym->backend_decl;
-	  clobber = build_clobber (TREE_TYPE (var));
-	  gfc_add_modify (&se->pre, var, clobber);
-	}
       return;
     }
 
diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h
index 03d5288aad2..bc9035c1717 100644
--- a/gcc/fortran/trans.h
+++ b/gcc/fortran/trans.h
@@ -499,8 +499,7 @@ tree gfc_build_compare_string (tree, tree, tree, tree, int, enum tree_code);
 void gfc_conv_expr (gfc_se * se, gfc_expr * expr);
 void gfc_conv_expr_val (gfc_se * se, gfc_expr * expr);
 void gfc_conv_expr_lhs (gfc_se * se, gfc_expr * expr);
-void gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr,
-			      bool add_clobber = false);
+void gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr);
 void gfc_conv_expr_type (gfc_se * se, gfc_expr *, tree);
 
 
-- 
2.35.1


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

* [PATCH 02/10] fortran: Fix invalid function decl clobber ICE [PR105012]
  2022-09-16 20:24 [PATCH 00/10] fortran: clobber fixes [PR41453] Mikael Morin
  2022-09-16 20:24 ` [PATCH 01/10] fortran: Move the clobber generation code Mikael Morin
@ 2022-09-16 20:24 ` Mikael Morin
  2022-09-16 20:24 ` [PATCH 03/10] fortran: Move clobbers after evaluation of all arguments [PR106817] Mikael Morin
                   ` (7 subsequent siblings)
  9 siblings, 0 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-16 20:24 UTC (permalink / raw)
  To: gcc-patches, fortran

The fortran frontend, as result symbol for a function without
declared result symbol, uses the function symbol itself.  This caused
an invalid clobber of a function decl to be emitted, leading to an
ICE, whereas the intended behaviour was to clobber the function result
variable.  This change fixes the problem by getting the decl from the
just-retrieved variable reference after the call to
gfc_conv_expr_reference, instead of copying it from the frontend symbol.

	PR fortran/105012

gcc/fortran/ChangeLog:

	* trans-expr.cc (gfc_conv_procedure_call): Retrieve variable
	from the just calculated variable reference.

gcc/testsuite/ChangeLog:

	* gfortran.dg/intent_out_15.f90: New test.
---
 gcc/fortran/trans-expr.cc                   |  3 ++-
 gcc/testsuite/gfortran.dg/intent_out_15.f90 | 27 +++++++++++++++++++++
 2 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/intent_out_15.f90

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 7902b941c2d..76c587e3d9f 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6528,7 +6528,8 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 			  tree var;
 			  /* FIXME: This fails if var is passed by reference, see PR
 			     41453.  */
-			  var = e->symtree->n.sym->backend_decl;
+			  var = build_fold_indirect_ref_loc (input_location,
+							     parmse.expr);
 			  tree clobber = build_clobber (TREE_TYPE (var));
 			  gfc_add_modify (&se->pre, var, clobber);
 			}
diff --git a/gcc/testsuite/gfortran.dg/intent_out_15.f90 b/gcc/testsuite/gfortran.dg/intent_out_15.f90
new file mode 100644
index 00000000000..64334e6f038
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/intent_out_15.f90
@@ -0,0 +1,27 @@
+! { dg-do compile }
+! { dg-additional-options "-fdump-tree-original" }
+!
+! PR fortran/105012
+! The following case was triggering an ICE because of a clobber
+! on the DERFC function decl instead of its result.
+
+module error_function
+integer, parameter :: r8 = selected_real_kind(12) ! 8 byte real
+contains
+SUBROUTINE CALERF_r8(ARG, RESULT, JINT)
+   integer, parameter :: rk = r8
+   real(rk), intent(in)  :: arg
+   real(rk), intent(out) :: result
+   IF (Y .LE. THRESH) THEN
+   END IF
+end SUBROUTINE CALERF_r8
+FUNCTION DERFC(X)
+   integer, parameter :: rk = r8 ! 8 byte real
+   real(rk), intent(in) :: X
+   real(rk) :: DERFC
+   CALL CALERF_r8(X, DERFC, JINT)
+END FUNCTION DERFC
+end module error_function
+
+! { dg-final { scan-tree-dump-times "CLOBBER" 1 "original" } }
+! { dg-final { scan-tree-dump "__result_derfc = {CLOBBER};" "original" } }
-- 
2.35.1


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

* [PATCH 03/10] fortran: Move clobbers after evaluation of all arguments [PR106817]
  2022-09-16 20:24 [PATCH 00/10] fortran: clobber fixes [PR41453] Mikael Morin
  2022-09-16 20:24 ` [PATCH 01/10] fortran: Move the clobber generation code Mikael Morin
  2022-09-16 20:24 ` [PATCH 02/10] fortran: Fix invalid function decl clobber ICE [PR105012] Mikael Morin
@ 2022-09-16 20:24 ` Mikael Morin
  2022-09-16 20:24 ` [PATCH 04/10] fortran: Support clobbering with implicit interfaces [PR105012] Mikael Morin
                   ` (6 subsequent siblings)
  9 siblings, 0 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-16 20:24 UTC (permalink / raw)
  To: gcc-patches, fortran

For actual arguments whose dummy is INTENT(OUT), we used to generate
clobbers on them at the same time we generated the argument reference
for the function call.  This was wrong if for an argument coming
later, the value expression was depending on the value of the just-
clobbered argument, and we passed an undefined value in that case.

With this change, clobbers are collected separatedly and appended
to the procedure call preliminary code after all the arguments have been
evaluated.

	PR fortran/106817

gcc/fortran/ChangeLog:

	* trans-expr.cc (gfc_conv_procedure_call): Collect all clobbers
	to their own separate block.  Append the block of clobbers to
	the procedure preliminary block after the argument evaluation
	codes for all the arguments.

gcc/testsuite/ChangeLog:

	* gfortran.dg/intent_optimize_9.f90: New test.
---
 gcc/fortran/trans-expr.cc                     |  6 ++-
 .../gfortran.dg/intent_optimize_9.f90         | 43 +++++++++++++++++++
 2 files changed, 47 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/intent_optimize_9.f90

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 76c587e3d9f..a62a3bb642d 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6018,7 +6018,6 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
   gfc_charlen cl;
   gfc_expr *e;
   gfc_symbol *fsym;
-  stmtblock_t post;
   enum {MISSING = 0, ELEMENTAL, SCALAR, SCALAR_POINTER, ARRAY};
   gfc_component *comp = NULL;
   int arglen;
@@ -6062,7 +6061,9 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
   else
     info = NULL;
 
+  stmtblock_t post, clobbers;
   gfc_init_block (&post);
+  gfc_init_block (&clobbers);
   gfc_init_interface_mapping (&mapping);
   if (!comp)
     {
@@ -6531,7 +6532,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 			  var = build_fold_indirect_ref_loc (input_location,
 							     parmse.expr);
 			  tree clobber = build_clobber (TREE_TYPE (var));
-			  gfc_add_modify (&se->pre, var, clobber);
+			  gfc_add_modify (&clobbers, var, clobber);
 			}
 		    }
 		  /* Catch base objects that are not variables.  */
@@ -7400,6 +7401,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 
       vec_safe_push (arglist, parmse.expr);
     }
+  gfc_add_block_to_block (&se->pre, &clobbers);
   gfc_finish_interface_mapping (&mapping, &se->pre, &se->post);
 
   if (comp)
diff --git a/gcc/testsuite/gfortran.dg/intent_optimize_9.f90 b/gcc/testsuite/gfortran.dg/intent_optimize_9.f90
new file mode 100644
index 00000000000..effbaa12a2d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/intent_optimize_9.f90
@@ -0,0 +1,43 @@
+! { dg-do run }
+! { dg-additional-options "-fdump-tree-original" }
+! { dg-final { scan-tree-dump-times "CLOBBER" 2 "original" } }
+!
+! PR fortran/106817
+! Check that for an actual argument whose dummy is INTENT(OUT),
+! the clobber that is emitted in the caller before a procedure call
+! happens after any expression depending on the argument value has been
+! evaluated.
+! 
+
+module m
+  implicit none
+contains
+  subroutine copy1(out, in)
+    integer, intent(in) :: in
+    integer, intent(out) :: out
+    out = in
+  end subroutine copy1
+  subroutine copy2(in, out)
+    integer, intent(in) :: in
+    integer, intent(out) :: out
+    out = in
+  end subroutine copy2
+end module m
+
+program p
+  use m
+  implicit none
+  integer :: a, b
+
+  ! Clobbering of a should happen after a+1 has been evaluated.
+  a = 3
+  call copy1(a, a+1)
+  if (a /= 4) stop 1
+
+  ! Clobbering order does not depend on the order of arguments.
+  ! It should also come last with reversed arguments.
+  b = 12
+  call copy2(b+1, b)
+  if (b /= 13) stop 2
+
+end program p
-- 
2.35.1


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

* [PATCH 04/10] fortran: Support clobbering with implicit interfaces [PR105012]
  2022-09-16 20:24 [PATCH 00/10] fortran: clobber fixes [PR41453] Mikael Morin
                   ` (2 preceding siblings ...)
  2022-09-16 20:24 ` [PATCH 03/10] fortran: Move clobbers after evaluation of all arguments [PR106817] Mikael Morin
@ 2022-09-16 20:24 ` Mikael Morin
  2022-09-16 20:24 ` [PATCH 05/10] fortran: Support clobbering of reference variables [PR41453] Mikael Morin
                   ` (5 subsequent siblings)
  9 siblings, 0 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-16 20:24 UTC (permalink / raw)
  To: gcc-patches, fortran

From: Harald Anlauf <anlauf@gmx.de>

Before procedure calls, we clobber actual arguments whose associated
dummy is INTENT(OUT).  This only applies to procedures with explicit
interfaces, as the knowledge of the interface is necessary to know
whether an argument has the INTENT(OUT) attribute.

This change also enables clobber generation for procedure calls without
explicit interface, when the procedure has been defined in the same
file because we can use the dummy arguments' characteristics from the
procedure definition in that case.

The knowledge of the dummy characteristics is directly available through
gfc_actual_arglist’s associated_dummy pointers which have been populated
as a side effect of calling gfc_check_externals.

	PR fortran/105012

gcc/fortran/ChangeLog:

	* trans-expr.cc (gfc_conv_procedure_call): Use dummy
	information from associated_dummy if there is no information
	from the procedure interface.

gcc/testsuite/ChangeLog:

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

Co-Authored-By: Mikael Morin <mikael@gcc.gnu.org>
---
 gcc/fortran/trans-expr.cc                     | 19 +++++++++++----
 .../gfortran.dg/intent_optimize_4.f90         | 24 +++++++++++++++++++
 2 files changed, 39 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/intent_optimize_4.f90

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index a62a3bb642d..2301724729f 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6505,10 +6505,21 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 		    {
 		      gfc_conv_expr_reference (&parmse, e);
 
-		      if (fsym
-			  && fsym->attr.intent == INTENT_OUT
-			  && !fsym->attr.allocatable
-			  && !fsym->attr.pointer
+		      gfc_symbol *dsym = fsym;
+		      gfc_dummy_arg *dummy;
+
+		      /* Use associated dummy as fallback for formal
+			 argument if there is no explicit interface.  */
+		      if (dsym == NULL
+			  && (dummy = arg->associated_dummy)
+			  && dummy->intrinsicness == GFC_NON_INTRINSIC_DUMMY_ARG
+			  && dummy->u.non_intrinsic->sym)
+			dsym = dummy->u.non_intrinsic->sym;
+
+		      if (dsym
+			  && dsym->attr.intent == INTENT_OUT
+			  && !dsym->attr.allocatable
+			  && !dsym->attr.pointer
 			  && e->expr_type == EXPR_VARIABLE
 			  && e->ref == NULL
 			  && e->symtree
diff --git a/gcc/testsuite/gfortran.dg/intent_optimize_4.f90 b/gcc/testsuite/gfortran.dg/intent_optimize_4.f90
new file mode 100644
index 00000000000..2f184bf84a8
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/intent_optimize_4.f90
@@ -0,0 +1,24 @@
+! { dg-do run }
+! { dg-additional-options "-fno-inline -fno-ipa-modref -fdump-tree-optimized -fdump-tree-original" }
+!
+! PR fortran/105012
+! Check that the INTENT(OUT) attribute causes one clobber to be emitted in
+! the caller before the call to Y in the *.original dump, and the
+! initialization constant to be optimized away in the *.optimized dump,
+! despite the non-explicit interface if the subroutine with the INTENT(OUT)
+! is declared in the same file.
+
+SUBROUTINE Y (Z)
+      integer, intent(out) :: Z
+      Z = 42
+END SUBROUTINE Y
+PROGRAM TEST
+    integer :: X
+    X = 123456789
+    CALL Y (X)
+    if (X.ne.42) STOP 1
+END PROGRAM
+
+! { dg-final { scan-tree-dump-times "CLOBBER" 1 "original" } }
+! { dg-final { scan-tree-dump "x = {CLOBBER};" "original" } }
+! { dg-final { scan-tree-dump-not "123456789" "optimized" { target __OPTIMIZE__ } } }
-- 
2.35.1


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

* [PATCH 05/10] fortran: Support clobbering of reference variables [PR41453]
  2022-09-16 20:24 [PATCH 00/10] fortran: clobber fixes [PR41453] Mikael Morin
                   ` (3 preceding siblings ...)
  2022-09-16 20:24 ` [PATCH 04/10] fortran: Support clobbering with implicit interfaces [PR105012] Mikael Morin
@ 2022-09-16 20:24 ` Mikael Morin
  2022-09-16 20:24 ` [PATCH 06/10] fortran: Support clobbering of SAVE variables [PR87395] Mikael Morin
                   ` (4 subsequent siblings)
  9 siblings, 0 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-16 20:24 UTC (permalink / raw)
  To: gcc-patches, fortran

This adds support for clobbering of variables passed by reference,
when the reference is forwarded to a subroutine as actual argument
whose associated dummy has the INTENT(OUT) attribute.
This was explicitly disabled and enabling it seems to work, as
demonstrated by the new testcase.

	PR fortran/41453

gcc/fortran/ChangeLog:

	* trans-expr.cc (gfc_conv_procedure_call): Remove condition
	disabling clobber generation for dummy variables.  Remove
	obsolete comment.

gcc/testsuite/ChangeLog:

	* gfortran.dg/intent_optimize_5.f90: New test.
---
 gcc/fortran/trans-expr.cc                     |  4 ---
 .../gfortran.dg/intent_optimize_5.f90         | 34 +++++++++++++++++++
 2 files changed, 34 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/intent_optimize_5.f90

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 2301724729f..9b2832bdb26 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6527,8 +6527,6 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 			  && !e->symtree->n.sym->attr.dimension
 			  && !e->symtree->n.sym->attr.pointer
 			  && !e->symtree->n.sym->attr.allocatable
-			  /* See PR 41453.  */
-			  && !e->symtree->n.sym->attr.dummy
 			  /* FIXME - PR 87395 and PR 41453  */
 			  && e->symtree->n.sym->attr.save == SAVE_NONE
 			  && !e->symtree->n.sym->attr.associate_var
@@ -6538,8 +6536,6 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 			  && !sym->attr.elemental)
 			{
 			  tree var;
-			  /* FIXME: This fails if var is passed by reference, see PR
-			     41453.  */
 			  var = build_fold_indirect_ref_loc (input_location,
 							     parmse.expr);
 			  tree clobber = build_clobber (TREE_TYPE (var));
diff --git a/gcc/testsuite/gfortran.dg/intent_optimize_5.f90 b/gcc/testsuite/gfortran.dg/intent_optimize_5.f90
new file mode 100644
index 00000000000..1633b681fc3
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/intent_optimize_5.f90
@@ -0,0 +1,34 @@
+! { dg-do run }
+! { dg-additional-options "-fno-inline -fno-ipa-modref -fdump-tree-optimized -fdump-tree-original" }
+!
+! PR fortran/41453
+! Check that the INTENT(OUT) attribute causes one clobber to be emitted in
+! the caller before each call to FOO in the *.original dump, and the
+! initialization constant to be optimized away in the *.optimized dump,
+! in the case of an argument passed by reference to the caller.
+
+module x
+implicit none
+contains
+  subroutine foo(a)
+    integer, intent(out) :: a
+    a = 42
+  end subroutine foo
+  subroutine bar(b)
+    integer :: b
+    b = 123456789
+    call foo(b)
+  end subroutine bar
+end module x
+
+program main
+  use x
+  implicit none
+  integer :: c
+  call bar(c)
+  if (c /= 42) stop 1
+end program main
+
+! { dg-final { scan-tree-dump-times "CLOBBER" 1 "original" } }
+! { dg-final { scan-tree-dump "\\*\\\(integer\\\(kind=4\\\) \\*\\\) b = {CLOBBER};" "original" } }
+! { dg-final { scan-tree-dump-not "123456789" "optimized" { target __OPTIMIZE__ } } }
-- 
2.35.1


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

* [PATCH 06/10] fortran: Support clobbering of SAVE variables [PR87395]
  2022-09-16 20:24 [PATCH 00/10] fortran: clobber fixes [PR41453] Mikael Morin
                   ` (4 preceding siblings ...)
  2022-09-16 20:24 ` [PATCH 05/10] fortran: Support clobbering of reference variables [PR41453] Mikael Morin
@ 2022-09-16 20:24 ` Mikael Morin
  2022-09-16 20:24 ` [PATCH 07/10] fortran: Support clobbering of ASSOCIATE variables [PR87397] Mikael Morin
                   ` (3 subsequent siblings)
  9 siblings, 0 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-16 20:24 UTC (permalink / raw)
  To: gcc-patches, fortran

This is in spirit a revert of:
r9-3032-gee7fb0588c6361b4d77337ab0f7527be64fcdde2

That commit added a condition to avoid generating ICE with clobbers
of variables with the SAVE attribute.
The test added at that point continues to pass if we remove that
condition now.

	PR fortran/87395
	PR fortran/41453

gcc/fortran/ChangeLog:

	* trans-expr.cc (gfc_conv_procedure_call): Remove condition
	on SAVE attribute guarding clobber generation.
---
 gcc/fortran/trans-expr.cc | 2 --
 1 file changed, 2 deletions(-)

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 9b2832bdb26..d169df44a71 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6527,8 +6527,6 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 			  && !e->symtree->n.sym->attr.dimension
 			  && !e->symtree->n.sym->attr.pointer
 			  && !e->symtree->n.sym->attr.allocatable
-			  /* FIXME - PR 87395 and PR 41453  */
-			  && e->symtree->n.sym->attr.save == SAVE_NONE
 			  && !e->symtree->n.sym->attr.associate_var
 			  && e->ts.type != BT_CHARACTER
 			  && e->ts.type != BT_DERIVED
-- 
2.35.1


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

* [PATCH 07/10] fortran: Support clobbering of ASSOCIATE variables [PR87397]
  2022-09-16 20:24 [PATCH 00/10] fortran: clobber fixes [PR41453] Mikael Morin
                   ` (5 preceding siblings ...)
  2022-09-16 20:24 ` [PATCH 06/10] fortran: Support clobbering of SAVE variables [PR87395] Mikael Morin
@ 2022-09-16 20:24 ` Mikael Morin
  2022-09-16 20:24 ` [PATCH 08/10] fortran: Support clobbering of allocatables and pointers [PR41453] Mikael Morin
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-16 20:24 UTC (permalink / raw)
  To: gcc-patches, fortran

This is in spirit a revert of:
r9-3051-gc109362313623d83fe0a5194bceaf994cf0c6ce0

That commit added a condition to avoid generating ICE with clobbers
of ASSOCIATE variables.
The test added at that point continues to pass if we remove that
condition now.

	PR fortran/87397
	PR fortran/41453

gcc/fortran/ChangeLog:

	* trans-expr.cc (gfc_conv_procedure_call): Remove condition
	disabling clobber generation for ASSOCIATE variables.
---
 gcc/fortran/trans-expr.cc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index d169df44a71..4491465c4d6 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6527,7 +6527,6 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 			  && !e->symtree->n.sym->attr.dimension
 			  && !e->symtree->n.sym->attr.pointer
 			  && !e->symtree->n.sym->attr.allocatable
-			  && !e->symtree->n.sym->attr.associate_var
 			  && e->ts.type != BT_CHARACTER
 			  && e->ts.type != BT_DERIVED
 			  && e->ts.type != BT_CLASS
-- 
2.35.1


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

* [PATCH 08/10] fortran: Support clobbering of allocatables and pointers [PR41453]
  2022-09-16 20:24 [PATCH 00/10] fortran: clobber fixes [PR41453] Mikael Morin
                   ` (6 preceding siblings ...)
  2022-09-16 20:24 ` [PATCH 07/10] fortran: Support clobbering of ASSOCIATE variables [PR87397] Mikael Morin
@ 2022-09-16 20:24 ` Mikael Morin
  2022-09-16 20:24 ` [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364] Mikael Morin
  2022-09-16 20:24 ` [PATCH 10/10] fortran: Support clobbering of derived types [PR41453] Mikael Morin
  9 siblings, 0 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-16 20:24 UTC (permalink / raw)
  To: gcc-patches, fortran

This adds support for clobbering of allocatable and pointer scalar
variables passed as actual argument to a subroutine when the associated
dummy has the INTENT(OUT) attribute.
Support was explicitly disabled, but the clobber generation code seems
to support it well, as demonstrated by the newly added testcase.

	PR fortran/41453

gcc/fortran/ChangeLog:

	* trans-expr.cc (gfc_conv_procedure_call): Remove conditions
	on ALLOCATABLE and POINTER attributes guarding clobber
	generation.

gcc/testsuite/ChangeLog:

	* gfortran.dg/intent_optimize_6.f90: New test.
---
 gcc/fortran/trans-expr.cc                     |  2 -
 .../gfortran.dg/intent_optimize_6.f90         | 42 +++++++++++++++++++
 2 files changed, 42 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/intent_optimize_6.f90

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 4491465c4d6..ae685157e22 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6525,8 +6525,6 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 			  && e->symtree
 			  && e->symtree->n.sym
 			  && !e->symtree->n.sym->attr.dimension
-			  && !e->symtree->n.sym->attr.pointer
-			  && !e->symtree->n.sym->attr.allocatable
 			  && e->ts.type != BT_CHARACTER
 			  && e->ts.type != BT_DERIVED
 			  && e->ts.type != BT_CLASS
diff --git a/gcc/testsuite/gfortran.dg/intent_optimize_6.f90 b/gcc/testsuite/gfortran.dg/intent_optimize_6.f90
new file mode 100644
index 00000000000..0146dff4e20
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/intent_optimize_6.f90
@@ -0,0 +1,42 @@
+! { dg-do run }
+! { dg-additional-options "-fno-inline -fno-ipa-modref -fdump-tree-optimized -fdump-tree-original" }
+!
+! PR fortran/41453
+! Check that the INTENT(OUT) attribute causes one clobber to be emitted in
+! the caller before each call to FOO in the *.original dump, and the
+! initialization constants to be optimized away in the *.optimized dump,
+! in the case of scalar allocatables and pointers.
+
+module x
+implicit none
+contains
+  subroutine foo(a)
+    integer, intent(out) :: a
+    a = 42
+  end subroutine foo
+end module x
+
+program main
+  use x
+  implicit none
+  integer, allocatable :: ca
+  integer, target :: ct
+  integer, pointer :: cp
+
+  allocate(ca)
+  ca = 123456789
+  call foo(ca)
+  if (ca /= 42) stop 1
+  deallocate(ca)
+
+  ct = 987654321
+  cp => ct
+  call foo(cp)
+  if (ct /= 42) stop 2
+end program main
+
+! { dg-final { scan-tree-dump-times "CLOBBER" 2 "original" } }
+! { dg-final { scan-tree-dump "\\*ca = {CLOBBER};" "original" } }
+! { dg-final { scan-tree-dump "\\*cp = {CLOBBER};" "original" } }
+! { dg-final { scan-tree-dump-not "123456789" "optimized" { target __OPTIMIZE__ } } }
+! { dg-final { scan-tree-dump-not "987654321" "optimized" { target __OPTIMIZE__ } } }
-- 
2.35.1


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

* [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-16 20:24 [PATCH 00/10] fortran: clobber fixes [PR41453] Mikael Morin
                   ` (7 preceding siblings ...)
  2022-09-16 20:24 ` [PATCH 08/10] fortran: Support clobbering of allocatables and pointers [PR41453] Mikael Morin
@ 2022-09-16 20:24 ` Mikael Morin
  2022-09-17 17:03   ` Thomas Koenig
  2022-09-16 20:24 ` [PATCH 10/10] fortran: Support clobbering of derived types [PR41453] Mikael Morin
  9 siblings, 1 reply; 36+ messages in thread
From: Mikael Morin @ 2022-09-16 20:24 UTC (permalink / raw)
  To: gcc-patches, fortran

This adds support for clobbering of partial variable references, when
they are passed as actual argument and the associated dummy has the
INTENT(OUT) attribute.
Support includes array elements, derived type component references,
and complex real or imaginary parts.

This is done by removing the check for lack of subreferences, which is
basically a revert of r9-4911-gbd810d637041dba49a5aca3d085504575374ac6f.
This removal allows more expressions than just array elements,
components and complex parts, but the other expressions are excluded by
other conditions: substrings are excluded by the check on expression
type (CHARACTER is excluded), KIND and LEN references are rejected by
the compiler as not valid in a variable definition context.

The check for scalarness is also updated as it was only valid when there
was no subreference.

	PR fortran/88364
	PR fortran/41453

gcc/fortran/ChangeLog:

	* trans-expr.cc (gfc_conv_procedure_call): Don’t check for lack
	of subreference.  Check the global expression rank instead of
	the root symbol dimension attribute.

gcc/testsuite/ChangeLog:

	* gfortran.dg/intent_optimize_7.f90: New test.
---
 gcc/fortran/trans-expr.cc                     |  5 +-
 .../gfortran.dg/intent_optimize_7.f90         | 65 +++++++++++++++++++
 2 files changed, 66 insertions(+), 4 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/intent_optimize_7.f90

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index ae685157e22..f1026d7f309 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6521,10 +6521,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 			  && !dsym->attr.allocatable
 			  && !dsym->attr.pointer
 			  && e->expr_type == EXPR_VARIABLE
-			  && e->ref == NULL
-			  && e->symtree
-			  && e->symtree->n.sym
-			  && !e->symtree->n.sym->attr.dimension
+			  && e->rank == 0
 			  && e->ts.type != BT_CHARACTER
 			  && e->ts.type != BT_DERIVED
 			  && e->ts.type != BT_CLASS
diff --git a/gcc/testsuite/gfortran.dg/intent_optimize_7.f90 b/gcc/testsuite/gfortran.dg/intent_optimize_7.f90
new file mode 100644
index 00000000000..14dcfd9961b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/intent_optimize_7.f90
@@ -0,0 +1,65 @@
+! { dg-do run }
+! { dg-additional-options "-fno-inline -fno-ipa-modref -fdump-tree-optimized -fdump-tree-original" }
+!
+! PR fortran/41453
+! Check that the INTENT(OUT) attribute causes one clobber to be emitted in
+! the caller before each call to FOO or BAR in the *.original dump, and the
+! initialization constants to be optimized away in the *.optimized dump,
+! in the case of scalar array elements, derived type components,
+! and complex real and imaginary part.
+
+module x
+implicit none
+contains
+  subroutine foo(a)
+    integer, intent(out) :: a
+    a = 42
+  end subroutine foo
+  subroutine bar(a)
+    real, intent(out) :: a
+    a = 24.0
+  end subroutine bar
+end module x
+
+program main
+  use x
+  implicit none
+  type :: t
+    integer :: c
+  end type t
+  type(t) :: dc
+  integer :: ac(3)
+  complex :: xc, xd
+
+  dc = t(123456789)
+  call foo(dc%c)
+  if (dc%c /= 42) stop 1
+
+  ac = 100
+  ac(2) = 987654321
+  call foo(ac(2))
+  if (any(ac /= [100, 42, 100])) stop 2
+
+  xc = (12345.0, 11.0)
+  call bar(xc%re)
+  if (xc /= (24.0, 11.0)) stop 3
+
+  xd = (17.0, 67890.0)
+  call bar(xd%im)
+  if (xd /= (17.0, 24.0)) stop 4
+
+end program main
+
+! { dg-final { scan-tree-dump-times "CLOBBER" 4 "original" } }
+! { dg-final { scan-tree-dump "dc\\.c = {CLOBBER};" "original" } }
+! { dg-final { scan-tree-dump "ac\\\[1\\\] = {CLOBBER};" "original" } }
+! { dg-final { scan-tree-dump "REALPART_EXPR <xc> = {CLOBBER};" "original" } }
+! { dg-final { scan-tree-dump "IMAGPART_EXPR <xd> = {CLOBBER};" "original" } }
+! { dg-final { scan-tree-dump     "123456789" "original" } }
+! { dg-final { scan-tree-dump-not "123456789" "optimized" { target __OPTIMIZE__ } } }
+! { dg-final { scan-tree-dump     "987654321" "original" } }
+! { dg-final { scan-tree-dump-not "987654321" "optimized" { target __OPTIMIZE__ } } }
+! { dg-final { scan-tree-dump     "1\\.2345e\\+4" "original"  } }
+! { dg-final { scan-tree-dump-not "1\\.2345e\\+4" "optimized" { target __OPTIMIZE__ } } }
+! { dg-final { scan-tree-dump     "6\\.789e\\+4" "original"  } }
+! { dg-final { scan-tree-dump-not "6\\.789e\\+4" "optimized" { target __OPTIMIZE__ } } }
-- 
2.35.1


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

* [PATCH 10/10] fortran: Support clobbering of derived types [PR41453]
  2022-09-16 20:24 [PATCH 00/10] fortran: clobber fixes [PR41453] Mikael Morin
                   ` (8 preceding siblings ...)
  2022-09-16 20:24 ` [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364] Mikael Morin
@ 2022-09-16 20:24 ` Mikael Morin
  9 siblings, 0 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-16 20:24 UTC (permalink / raw)
  To: gcc-patches, fortran

This is probably the most risky patch in the series.

A previous version of this patch allowing all exactly matching derived
types showed two regressions.  One of them uncovered PR106817 for which
I added a fix in this series, and for the other I have excluded
types with allocatable components from clobbering.

I have additionnally excluded finalizable types for similar reasons, and
parameterized derived type because they may not be constant-sized.

I hope we are safe for all the rest.

-- >8 --

This adds support for clobbering of non-polymorphic derived type
variables, when they are passed as actual argument whose associated
dummy has the INTENT(OUT) attribute.

We avoid to play with non-constant type sizes or class descriptors by
requiring that the types are derived (not class) and strictly matching,
and by excluding parameterized derived types.

Types that are used in the callee are also excluded: they are types with
allocatable components (the components will be deallocated), and
finalizable types or types with finalizable components (they will be
passed to finalization routines).

	PR fortran/41453

gcc/fortran/ChangeLog:

	* trans-expr.cc (gfc_conv_procedure_call): Allow strictly
	matching derived types.

gcc/testsuite/ChangeLog:

	* gfortran.dg/intent_optimize_8.f90: New test.
---
 gcc/fortran/trans-expr.cc                     | 18 ++++-
 .../gfortran.dg/intent_optimize_8.f90         | 67 +++++++++++++++++++
 2 files changed, 84 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/intent_optimize_8.f90

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index f1026d7f309..f8fcd2d97d9 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6523,8 +6523,24 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 			  && e->expr_type == EXPR_VARIABLE
 			  && e->rank == 0
 			  && e->ts.type != BT_CHARACTER
-			  && e->ts.type != BT_DERIVED
 			  && e->ts.type != BT_CLASS
+			  && (e->ts.type != BT_DERIVED
+			      || (dsym->ts.type == BT_DERIVED
+				  && e->ts.u.derived == dsym->ts.u.derived
+				  /* Types with allocatable components are
+				     excluded from clobbering because we need
+				     the unclobbered pointers to free the
+				     allocatable components in the callee.
+				     Same goes for finalizable types or types
+				     with finalizable components, we need to
+				     pass the unclobbered values to the
+				     finalization routines.
+				     For parameterized types, it's less clear
+				     but they may not have a constant size
+				     so better exclude them in any case.  */
+				  && !e->ts.u.derived->attr.alloc_comp
+				  && !e->ts.u.derived->attr.pdt_type
+				  && !gfc_is_finalizable (e->ts.u.derived, NULL)))
 			  && !sym->attr.elemental)
 			{
 			  tree var;
diff --git a/gcc/testsuite/gfortran.dg/intent_optimize_8.f90 b/gcc/testsuite/gfortran.dg/intent_optimize_8.f90
new file mode 100644
index 00000000000..584592842e1
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/intent_optimize_8.f90
@@ -0,0 +1,67 @@
+! { dg-do run }
+! { dg-additional-options "-fno-inline -fno-ipa-modref -fdump-tree-optimized -fdump-tree-original" }
+!
+! PR fortran/41453
+! Check that the INTENT(OUT) attribute causes in the case of non-polymorphic derived type arguments:
+!  - one clobber to be emitted in the caller before calls to FOO in the *.original dump,
+!  - no clobber to be emitted in the caller before calls to BAR in the *.original dump,
+!  - the initialization constants to be optimized away in the *.optimized dump.
+
+module x
+  implicit none
+  type :: t
+    integer :: c
+  end type t
+  type, extends(t) :: u
+    integer :: d
+  end type u
+contains
+  subroutine foo(a)
+    type(t), intent(out) :: a
+    a = t(42)
+  end subroutine foo
+  subroutine bar(b)
+    class(t), intent(out) :: b
+    b%c = 24
+  end subroutine bar
+end module x
+
+program main
+  use x
+  implicit none
+  type(t) :: tc
+  type(u) :: uc, ud
+  class(t), allocatable :: te, tf
+
+  tc = t(123456789)
+  call foo(tc)
+  if (tc%c /= 42) stop 1
+
+  uc = u(987654321, 0)
+  call foo(uc%t)
+  if (uc%c /= 42) stop 2
+  if (uc%d /= 0) stop 3
+
+  ud = u(11223344, 0)
+  call bar(ud)
+  if (ud%c /= 24) stop 4
+
+  te = t(55667788)
+  call foo(te)
+  if (te%c /= 42) stop 5
+
+  tf = t(99887766)
+  call bar(tf)
+  if (tf%c /= 24) stop 6
+
+end program main
+
+! We don't support class descriptors, so there are clobbers for tc and uc only; no clobber for ud, te, tf.
+! { dg-final { scan-tree-dump-times "CLOBBER" 2 "original" } }
+! { dg-final { scan-tree-dump "tc = {CLOBBER};" "original" } }
+! { dg-final { scan-tree-dump "uc\\.t = {CLOBBER};" "original" } }
+
+! There are clobbers for tc and uc, so we should manage to optimize away the associated initialization constants (but not other
+! initialization constants).
+! { dg-final { scan-tree-dump-not "123456789" "optimized" { target __OPTIMIZE__ } } }
+! { dg-final { scan-tree-dump-not "987654321" "optimized" { target __OPTIMIZE__ } } }
-- 
2.35.1


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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-16 20:24 ` [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364] Mikael Morin
@ 2022-09-17 17:03   ` Thomas Koenig
  2022-09-17 19:33     ` Mikael Morin
  0 siblings, 1 reply; 36+ messages in thread
From: Thomas Koenig @ 2022-09-17 17:03 UTC (permalink / raw)
  To: Mikael Morin, gcc-patches, fortran


Hi Mikael,

> This adds support for clobbering of partial variable references, when
> they are passed as actual argument and the associated dummy has the
> INTENT(OUT) attribute.
> Support includes array elements, derived type component references,
> and complex real or imaginary parts.
> 
> This is done by removing the check for lack of subreferences, which is
> basically a revert of r9-4911-gbd810d637041dba49a5aca3d085504575374ac6f.
> This removal allows more expressions than just array elements,
> components and complex parts, but the other expressions are excluded by
> other conditions: substrings are excluded by the check on expression
> type (CHARACTER is excluded), KIND and LEN references are rejected by
> the compiler as not valid in a variable definition context.
> 
> The check for scalarness is also updated as it was only valid when there
> was no subreference.

First, thanks a lot for digging into this subject. I have looked through
the patch series, and it looks very good so far.

I have a concern about this part, though.  My understanding at the
time was that it is not possible to clobber an individual array
element, but that this clobbers anything off the pointer that this
is based on.

So,

   integer, dimension(3) :: a

   a(1) = 1
   a(3) = 3
   call foo(a(1))

would also invalidate the store to a(3).  Is my understanding correct?
If so, I think this we cannot revert that patch (which was introduced
because of a regression).

Best regards

	Thomas

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-17 17:03   ` Thomas Koenig
@ 2022-09-17 19:33     ` Mikael Morin
  2022-09-17 19:49       ` Bernhard Reutner-Fischer
                         ` (2 more replies)
  0 siblings, 3 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-17 19:33 UTC (permalink / raw)
  To: Thomas Koenig, Mikael Morin, gcc-patches, fortran

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

Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
> 
> Hi Mikael,
> 
>> This adds support for clobbering of partial variable references, when
>> they are passed as actual argument and the associated dummy has the
>> INTENT(OUT) attribute.
>> Support includes array elements, derived type component references,
>> and complex real or imaginary parts.
>>
>> This is done by removing the check for lack of subreferences, which is
>> basically a revert of r9-4911-gbd810d637041dba49a5aca3d085504575374ac6f.
>> This removal allows more expressions than just array elements,
>> components and complex parts, but the other expressions are excluded by
>> other conditions: substrings are excluded by the check on expression
>> type (CHARACTER is excluded), KIND and LEN references are rejected by
>> the compiler as not valid in a variable definition context.
>>
>> The check for scalarness is also updated as it was only valid when there
>> was no subreference.
> 
> First, thanks a lot for digging into this subject. I have looked through
> the patch series, and it looks very good so far.
> 
> I have a concern about this part, though.  My understanding at the
> time was that it is not possible to clobber an individual array
> element, but that this clobbers anything off the pointer that this
> is based on.
> 
Well, we need the middle-end guys to give a definitive answer on this 
topic, but I think it would be a very penalizing limitation if that was 
the case.  I have assumed that the clobber spanned the value it was 
applied on, neither more nor less, so just the array element in case of 
array elements.

> So,
> 
>    integer, dimension(3) :: a
> 
>    a(1) = 1
>    a(3) = 3
>    call foo(a(1))
> 
> would also invalidate the store to a(3).  Is my understanding correct?

I think it was the case before patch 2 in in the series, because the 
clobber was applied to the symbol decl, so in the case of the expression 
A(1), it was applied to A which is the full array.  After patch 2, the 
clobber is applied to the expression A(1), so the element alone.

> If so, I think this we cannot revert that patch (which was introduced
> because of a regression).
> 
The testcase from the patch was not specifically checking lack of 
side-effect clobbers, so I have double-checked with the following 
testcase, which should lift your concerns.
I propose to keep the patch with the testcase added to it.  What do you 
think?

Mikael


[-- Attachment #2: intent_optimize_11.f90 --]
[-- Type: text/x-fortran, Size: 1234 bytes --]

! { dg-do run }
! { dg-additional-options "-fno-inline -fno-ipa-modref -fdump-tree-optimized -fdump-tree-original" }
!
! PR fortran/41453
! Check that the INTENT(OUT) attribute causes one clobber to be emitted
! for the array element passed as argument in the *.original dump, and the
! associated initialization constant to be optimized away in the *.optimized
! dump, whereas the other initialization constants are not optimized away.

module x
implicit none
contains
  subroutine foo(a)
    integer, intent(out) :: a
    a = 42
  end subroutine foo
end module x

program main
  use x
  implicit none
  integer :: ac(3)

  ac(1) = 123
  ac(2) = 456
  ac(3) = 789
  call foo(ac(2))
  if (any(ac /= [123, 42, 789])) stop 1

end program main

! { dg-final { scan-tree-dump-times "CLOBBER" 1 "original" } }
! { dg-final { scan-tree-dump "ac\\\[1\\\] = {CLOBBER};" "original" } }
! { dg-final { scan-tree-dump     "123" "original" } }
! { dg-final { scan-tree-dump     "123" "optimized" } }
! { dg-final { scan-tree-dump     "456" "original" } }
! { dg-final { scan-tree-dump-not "456" "optimized" { target __OPTIMIZE__ } } }
! { dg-final { scan-tree-dump     "789" "original" } }
! { dg-final { scan-tree-dump     "789" "optimized" } }

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-17 19:33     ` Mikael Morin
@ 2022-09-17 19:49       ` Bernhard Reutner-Fischer
  2022-09-17 19:50       ` Mikael Morin
  2022-09-18  6:12       ` Richard Biener
  2 siblings, 0 replies; 36+ messages in thread
From: Bernhard Reutner-Fischer @ 2022-09-17 19:49 UTC (permalink / raw)
  To: Mikael Morin, Thomas Koenig, Mikael Morin, gcc-patches, fortran

On 17 September 2022 21:33:22 CEST, Mikael Morin <morin-mikael@orange.fr> wrote:
>Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
>> 
>> Hi Mikael,
>> 
>>> This adds support for clobbering of partial variable references, when
>>> they are passed as actual argument and the associated dummy has the
>>> INTENT(OUT) attribute.
>>> Support includes array elements, derived type component references,
>>> and complex real or imaginary parts.
>>> 
>>> This is done by removing the check for lack of subreferences, which is
>>> basically a revert of r9-4911-gbd810d637041dba49a5aca3d085504575374ac6f.
>>> This removal allows more expressions than just array elements,
>>> components and complex parts, but the other expressions are excluded by
>>> other conditions: substrings are excluded by the check on expression
>>> type (CHARACTER is excluded), KIND and LEN references are rejected by
>>> the compiler as not valid in a variable definition context.
>>> 
>>> The check for scalarness is also updated as it was only valid when there
>>> was no subreference.
>> 
>> First, thanks a lot for digging into this subject. I have looked through
>> the patch series, and it looks very good so far.

I second that!
The series looks plausible IMO.

>> 
>> I have a concern about this part, though.  My understanding at the
>> time was that it is not possible to clobber an individual array
>> element, but that this clobbers anything off the pointer that this
>> is based on.
>> 
>Well, we need the middle-end guys to give a definitive answer on this topic, but I think it would be a very penalizing limitation if that was the case.  I have assumed that the clobber spanned the value it was applied on, neither more nor less, so just the array element in case of array elements.

I would assume the same, fwiw.
Let's blame the ME iff something goes amiss then, but I doubt it will.

>> So,
>> 
>>    integer, dimension(3) :: a
>> 
>>    a(1) = 1
>>    a(3) = 3
>>    call foo(a(1))
>> 
>> would also invalidate the store to a(3).  Is my understanding correct?
>
>I think it was the case before patch 2 in in the series, because the clobber was applied to the symbol decl, so in the case of the expression A(1), it was applied to A which is the full array.  After patch 2, the clobber is applied to the expression A(1), so the element alone.

Yep.

>> If so, I think this we cannot revert that patch (which was introduced
>> because of a regression).
>> 
>The testcase from the patch was not specifically checking lack of side-effect clobbers, so I have double-checked with the following testcase, which should lift your concerns.
>I propose to keep the patch with the testcase added to it.  What do you think?

I cannot approve it but the series looks good to me.

Thanks!

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-17 19:33     ` Mikael Morin
  2022-09-17 19:49       ` Bernhard Reutner-Fischer
@ 2022-09-17 19:50       ` Mikael Morin
  2022-09-17 21:24         ` Bernhard Reutner-Fischer
  2022-09-18  6:12       ` Richard Biener
  2 siblings, 1 reply; 36+ messages in thread
From: Mikael Morin @ 2022-09-17 19:50 UTC (permalink / raw)
  To: Thomas Koenig, Mikael Morin, gcc-patches, fortran

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

Le 17/09/2022 à 21:33, Mikael Morin a écrit :
> The testcase from the patch was not specifically checking lack of 
> side-effect clobbers, so I have double-checked with the following 
> testcase, which should lift your concerns.
> 
The dump matches didn’t fail as expected with patch 2/10 reversed.
This testcase should be better.

[-- Attachment #2: intent_optimize_11.f90 --]
[-- Type: text/x-fortran, Size: 1258 bytes --]

! { dg-do run }
! { dg-additional-options "-fno-inline -fno-ipa-modref -fdump-tree-optimized -fdump-tree-original" }
!
! PR fortran/41453
! Check that the INTENT(OUT) attribute causes one clobber to be emitted
! for the array element passed as argument in the *.original dump, and the
! associated initialization constant to be optimized away in the *.optimized
! dump, whereas the other initialization constants are not optimized away.

module x
implicit none
contains
  subroutine foo(a)
    integer, intent(out) :: a
    a = 42
  end subroutine foo
end module x

program main
  use x
  implicit none
  integer :: ac(3)

  ac(1) = 123
  ac(2) = 456
  ac(3) = 789
  call foo(ac(2))
  if (any(ac /= [123, 42, 789])) stop 1

end program main

! { dg-final { scan-tree-dump-times "CLOBBER" 1 "original" } }
! { dg-final { scan-tree-dump "ac\\\[1\\\] = {CLOBBER};" "original" } }
! { dg-final { scan-tree-dump-times "123" 2 "original" } }
! { dg-final { scan-tree-dump-times "123" 2 "optimized" } }
! { dg-final { scan-tree-dump-times "456" 1 "original" } }
! { dg-final { scan-tree-dump-times "456" 0 "optimized" { target __OPTIMIZE__ } } }
! { dg-final { scan-tree-dump-times "789" 2 "original" } }
! { dg-final { scan-tree-dump-times "789" 2 "optimized" } }

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-17 19:50       ` Mikael Morin
@ 2022-09-17 21:24         ` Bernhard Reutner-Fischer
  0 siblings, 0 replies; 36+ messages in thread
From: Bernhard Reutner-Fischer @ 2022-09-17 21:24 UTC (permalink / raw)
  To: Mikael Morin, Thomas Koenig, Mikael Morin, gcc-patches, fortran

On 17 September 2022 21:50:20 CEST, Mikael Morin <morin-mikael@orange.fr> wrote:
>Le 17/09/2022 à 21:33, Mikael Morin a écrit :
>> The testcase from the patch was not specifically checking lack of side-effect clobbers, so I have double-checked with the following testcase, which should lift your concerns.
>> 
>The dump matches didn’t fail as expected with patch 2/10 reversed.
>This testcase should be better.

! { dg-final { scan-tree-dump-times "456" 0 "optimized" { target __OPTIMIZE__ } } }

I'd spell this as scan-tree-dump-not, fwiw.

That said, plain scan-tree-dump is usually only viable in arch influenced checks which in fortran we do not usually have. Here, we should for the most part use -not or a specific -times.

I think you had a check for integer(kind=4) in there, too, which might not work all that well for -fdefault-integer-8 or, for the corresponding real scan, -fdefault-real-8, eventually. Easily tweaked on top if anyone (certainly will) complain later on, though..

fore, either way, I'd say :-)
thanks,

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-17 19:33     ` Mikael Morin
  2022-09-17 19:49       ` Bernhard Reutner-Fischer
  2022-09-17 19:50       ` Mikael Morin
@ 2022-09-18  6:12       ` Richard Biener
  2022-09-18  9:10         ` Mikael Morin
  2 siblings, 1 reply; 36+ messages in thread
From: Richard Biener @ 2022-09-18  6:12 UTC (permalink / raw)
  To: Mikael Morin; +Cc: Thomas Koenig, Mikael Morin, gcc-patches, fortran

On Sat, Sep 17, 2022 at 9:33 PM Mikael Morin <morin-mikael@orange.fr> wrote:
>
> Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
> >
> > Hi Mikael,
> >
> >> This adds support for clobbering of partial variable references, when
> >> they are passed as actual argument and the associated dummy has the
> >> INTENT(OUT) attribute.
> >> Support includes array elements, derived type component references,
> >> and complex real or imaginary parts.
> >>
> >> This is done by removing the check for lack of subreferences, which is
> >> basically a revert of r9-4911-gbd810d637041dba49a5aca3d085504575374ac6f.
> >> This removal allows more expressions than just array elements,
> >> components and complex parts, but the other expressions are excluded by
> >> other conditions: substrings are excluded by the check on expression
> >> type (CHARACTER is excluded), KIND and LEN references are rejected by
> >> the compiler as not valid in a variable definition context.
> >>
> >> The check for scalarness is also updated as it was only valid when there
> >> was no subreference.
> >
> > First, thanks a lot for digging into this subject. I have looked through
> > the patch series, and it looks very good so far.
> >
> > I have a concern about this part, though.  My understanding at the
> > time was that it is not possible to clobber an individual array
> > element, but that this clobbers anything off the pointer that this
> > is based on.
> >
> Well, we need the middle-end guys to give a definitive answer on this
> topic, but I think it would be a very penalizing limitation if that was
> the case.  I have assumed that the clobber spanned the value it was
> applied on, neither more nor less, so just the array element in case of
> array elements.

There is IL verification that the LHS of a CLOBBER is either
a declaration or a pointer dereference, no array or component
selection is allowed there.  Now, nothing should go wrong here,
but we might eventually just drop those CLOBBERs or ICE if
we frontend hands us an "invalid" one.

Richard.

> > So,
> >
> >    integer, dimension(3) :: a
> >
> >    a(1) = 1
> >    a(3) = 3
> >    call foo(a(1))
> >
> > would also invalidate the store to a(3).  Is my understanding correct?
>
> I think it was the case before patch 2 in in the series, because the
> clobber was applied to the symbol decl, so in the case of the expression
> A(1), it was applied to A which is the full array.  After patch 2, the
> clobber is applied to the expression A(1), so the element alone.
>
> > If so, I think this we cannot revert that patch (which was introduced
> > because of a regression).
> >
> The testcase from the patch was not specifically checking lack of
> side-effect clobbers, so I have double-checked with the following
> testcase, which should lift your concerns.
> I propose to keep the patch with the testcase added to it.  What do you
> think?
>
> Mikael
>

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-18  6:12       ` Richard Biener
@ 2022-09-18  9:10         ` Mikael Morin
  2022-09-18 10:23           ` Thomas Koenig
  2022-09-18 10:48           ` Richard Biener
  0 siblings, 2 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-18  9:10 UTC (permalink / raw)
  To: Richard Biener; +Cc: Thomas Koenig, Mikael Morin, gcc-patches, fortran

Le 18/09/2022 à 08:12, Richard Biener a écrit :
> On Sat, Sep 17, 2022 at 9:33 PM Mikael Morin <morin-mikael@orange.fr> wrote:
>>
>> Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
>>>
>>> I have a concern about this part, though.  My understanding at the
>>> time was that it is not possible to clobber an individual array
>>> element, but that this clobbers anything off the pointer that this
>>> is based on.
>>>
>> Well, we need the middle-end guys to give a definitive answer on this
>> topic, but I think it would be a very penalizing limitation if that was
>> the case.  I have assumed that the clobber spanned the value it was
>> applied on, neither more nor less, so just the array element in case of
>> array elements.
> 
> There is IL verification that the LHS of a CLOBBER is either
> a declaration or a pointer dereference, no array or component
> selection is allowed there.  Now, nothing should go wrong here,
> but we might eventually just drop those CLOBBERs or ICE if
> we frontend hands us an "invalid" one.
> 

Obviously I have assumed too much here; it's probably best to drop this 
patch.
It is unfortunate as there is some desirable behavior within reach here. 
  The test shows that the patch permits the elimination of a useless 
store.  And IL verification doesn't seem that upset with it by the way.
Does *(&a[1]) count as a pointer dereference?  Even in the original dump 
it is already simplified to a straight a[1].

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-18  9:10         ` Mikael Morin
@ 2022-09-18 10:23           ` Thomas Koenig
  2022-09-18 18:32             ` Harald Anlauf
  2022-09-18 20:43             ` Mikael Morin
  2022-09-18 10:48           ` Richard Biener
  1 sibling, 2 replies; 36+ messages in thread
From: Thomas Koenig @ 2022-09-18 10:23 UTC (permalink / raw)
  To: Mikael Morin, Richard Biener; +Cc: Mikael Morin, gcc-patches, fortran


On 18.09.22 11:10, Mikael Morin wrote:
> Le 18/09/2022 à 08:12, Richard Biener a écrit :
>> On Sat, Sep 17, 2022 at 9:33 PM Mikael Morin <morin-mikael@orange.fr> 
>> wrote:
>>>
>>> Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
>>>>
>>>> I have a concern about this part, though.  My understanding at the
>>>> time was that it is not possible to clobber an individual array
>>>> element, but that this clobbers anything off the pointer that this
>>>> is based on.
>>>>
>>> Well, we need the middle-end guys to give a definitive answer on this
>>> topic, but I think it would be a very penalizing limitation if that was
>>> the case.  I have assumed that the clobber spanned the value it was
>>> applied on, neither more nor less, so just the array element in case of
>>> array elements.
>>
>> There is IL verification that the LHS of a CLOBBER is either
>> a declaration or a pointer dereference, no array or component
>> selection is allowed there.  Now, nothing should go wrong here,
>> but we might eventually just drop those CLOBBERs or ICE if
>> we frontend hands us an "invalid" one.
>>
> 
> Obviously I have assumed too much here; it's probably best to drop this 
> patch.

Probably, yes.

> It is unfortunate as there is some desirable behavior within reach here. 

I think some of the desired behavior can still be salvaged.  For
example, for

   subroutine foo(a,n)
     integer :: n
     integer, dimension(n), intent(in) :: n

...

   subroutine bar(a)
     integer, intent(out) :: a

...

   integer :: a(3)

   call foo(a,3)
   call foo(a(1),3)

clobbers for the whole array can still be generated, but not for

   call foo(a(2),2)

so one would have to look at the lower bound.

For this case, it would be helpful to clobber a range a(2:), but that
is a wishlist item for the future ;-)

What is unsafe, currently, is

   call bar(a(1))

Best regards

	Thomas

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-18  9:10         ` Mikael Morin
  2022-09-18 10:23           ` Thomas Koenig
@ 2022-09-18 10:48           ` Richard Biener
  2022-09-19  7:31             ` Mikael Morin
  1 sibling, 1 reply; 36+ messages in thread
From: Richard Biener @ 2022-09-18 10:48 UTC (permalink / raw)
  To: Mikael Morin; +Cc: Thomas Koenig, Mikael Morin, gcc-patches, fortran



> Am 18.09.2022 um 11:10 schrieb Mikael Morin <morin-mikael@orange.fr>:
> 
> Le 18/09/2022 à 08:12, Richard Biener a écrit :
>>> On Sat, Sep 17, 2022 at 9:33 PM Mikael Morin <morin-mikael@orange.fr> wrote:
>>> 
>>> Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
>>>> 
>>>> I have a concern about this part, though.  My understanding at the
>>>> time was that it is not possible to clobber an individual array
>>>> element, but that this clobbers anything off the pointer that this
>>>> is based on.
>>>> 
>>> Well, we need the middle-end guys to give a definitive answer on this
>>> topic, but I think it would be a very penalizing limitation if that was
>>> the case.  I have assumed that the clobber spanned the value it was
>>> applied on, neither more nor less, so just the array element in case of
>>> array elements.
>> There is IL verification that the LHS of a CLOBBER is either
>> a declaration or a pointer dereference, no array or component
>> selection is allowed there.  Now, nothing should go wrong here,
>> but we might eventually just drop those CLOBBERs or ICE if
>> we frontend hands us an "invalid" one.
> 
> Obviously I have assumed too much here; it's probably best to drop this patch.
> It is unfortunate as there is some desirable behavior within reach here.  The test shows that the patch permits the elimination of a useless store.  And IL verification doesn't seem that upset with it by the way.
> Does *(&a[1]) count as a pointer dereference?

Yes, technically.

>  Even in the original dump it is already simplified to a straight a[1].

But this not anymore.  The check can probably be relaxed, it stems from the dual purpose of CLOBBER.

Richard 

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-18 10:23           ` Thomas Koenig
@ 2022-09-18 18:32             ` Harald Anlauf
  2022-09-18 20:55               ` Mikael Morin
  2022-09-18 20:43             ` Mikael Morin
  1 sibling, 1 reply; 36+ messages in thread
From: Harald Anlauf @ 2022-09-18 18:32 UTC (permalink / raw)
  To: Thomas Koenig, Mikael Morin, Richard Biener
  Cc: Mikael Morin, gcc-patches, fortran

On 18.09.22 12:23, Thomas Koenig via Gcc-patches wrote:
>
> On 18.09.22 11:10, Mikael Morin wrote:
>> It is unfortunate as there is some desirable behavior within reach here.
>
> I think some of the desired behavior can still be salvaged.  For
> example, for
>
>    subroutine foo(a,n)
>      integer :: n
>      integer, dimension(n), intent(in) :: n

     integer, dimension(n), intent(out) :: a  ! ?

> ...
>
>    subroutine bar(a)
>      integer, intent(out) :: a
>
> ...
>
>    integer :: a(3)
>
>    call foo(a,3)
>    call foo(a(1),3)
>
> clobbers for the whole array can still be generated, but not for
>
>    call foo(a(2),2)
>
> so one would have to look at the lower bound.
>
> For this case, it would be helpful to clobber a range a(2:), but that
> is a wishlist item for the future ;-)
>
> What is unsafe, currently, is
>
>    call bar(a(1))

We'll need a good coverage by testcases for the different handling
required for assumed shape / assumed size / explicit size dummies
to avoid new regressions.  Assumed shape will be on the easy side,
while assumed size likely needs to be excluded for clobbering.

Harald


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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-18 10:23           ` Thomas Koenig
  2022-09-18 18:32             ` Harald Anlauf
@ 2022-09-18 20:43             ` Mikael Morin
  1 sibling, 0 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-18 20:43 UTC (permalink / raw)
  To: Thomas Koenig, Richard Biener; +Cc: Mikael Morin, gcc-patches, fortran

Le 18/09/2022 à 12:23, Thomas Koenig a écrit :
> 
> I think some of the desired behavior can still be salvaged.  For
> example, for
> 
(...)
> 
> clobbers for the whole array can still be generated, but not for
> 
>    call foo(a(2),2)
> 
> so one would have to look at the lower bound.
> 
Well, my patches were for scalars only,
I prefer to stay away from arrays; they are just too full of traps.


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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-18 18:32             ` Harald Anlauf
@ 2022-09-18 20:55               ` Mikael Morin
  2022-09-19  7:11                 ` Mikael Morin
  2022-09-19 19:46                 ` Harald Anlauf
  0 siblings, 2 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-18 20:55 UTC (permalink / raw)
  To: Harald Anlauf, Thomas Koenig, Richard Biener
  Cc: Mikael Morin, gcc-patches, fortran

Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
> 
> Assumed shape will be on the easy side,
> while assumed size likely needs to be excluded for clobbering.
> 
Isn’t it the converse that is true?
Assumed shape can be non-contiguous so have to be excluded, but assumed 
size are contiguous, so valid candidates for clobbering. No?

No way, really, arrays are going to be a maze of complexity.


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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-18 20:55               ` Mikael Morin
@ 2022-09-19  7:11                 ` Mikael Morin
  2022-09-19 19:46                 ` Harald Anlauf
  1 sibling, 0 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-19  7:11 UTC (permalink / raw)
  To: Harald Anlauf, Thomas Koenig, Richard Biener
  Cc: Mikael Morin, gcc-patches, fortran

Le 18/09/2022 à 22:55, Mikael Morin a écrit :
> Assumed shape can be non-contiguous so have to be excluded, 
> 
Thinking about it again, assumed shape are probably acceptable, but 
there should be a check for contiguousness on the actual argument.

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-18 10:48           ` Richard Biener
@ 2022-09-19  7:31             ` Mikael Morin
  2022-09-19  7:58               ` Richard Biener
  0 siblings, 1 reply; 36+ messages in thread
From: Mikael Morin @ 2022-09-19  7:31 UTC (permalink / raw)
  To: Richard Biener; +Cc: Thomas Koenig, Mikael Morin, gcc-patches, fortran

Le 18/09/2022 à 12:48, Richard Biener a écrit :
> 
>> Does *(&a[1]) count as a pointer dereference?
> 
> Yes, technically.
> 
>>   Even in the original dump it is already simplified to a straight a[1].
> 
> But this not anymore.  The check can probably be relaxed, it stems from the dual purpose of CLOBBER.
> 
So the following makes the frontend-emitted IL valid, by handing the 
simplification over to the middle-end, but I can't help thinking that 
behavior won't be more reliable.


diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index f8fcd2d97d9..5fb9a3a536d 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6544,8 +6544,9 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * 
sym,
                           && !sym->attr.elemental)
                         {
                           tree var;
-                         var = build_fold_indirect_ref_loc (input_location,
-                                                            parmse.expr);
+                         var = build1_loc (input_location, INDIRECT_REF,
+                                           TREE_TYPE (TREE_TYPE 
(parmse.expr)),
+                                           parmse.expr);
                           tree clobber = build_clobber (TREE_TYPE (var));
                           gfc_add_modify (&clobbers, var, clobber);
                         }


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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-19  7:31             ` Mikael Morin
@ 2022-09-19  7:58               ` Richard Biener
  0 siblings, 0 replies; 36+ messages in thread
From: Richard Biener @ 2022-09-19  7:58 UTC (permalink / raw)
  To: Mikael Morin; +Cc: Thomas Koenig, Mikael Morin, gcc-patches, fortran

On Mon, Sep 19, 2022 at 9:31 AM Mikael Morin <morin-mikael@orange.fr> wrote:
>
> Le 18/09/2022 à 12:48, Richard Biener a écrit :
> >
> >> Does *(&a[1]) count as a pointer dereference?
> >
> > Yes, technically.
> >
> >>   Even in the original dump it is already simplified to a straight a[1].
> >
> > But this not anymore.  The check can probably be relaxed, it stems from the dual purpose of CLOBBER.
> >
> So the following makes the frontend-emitted IL valid, by handing the
> simplification over to the middle-end, but I can't help thinking that
> behavior won't be more reliable.

I think that will just delay the folding.  We are basically relying on
the frontends to
restrict what they produce, the *ptr case was specifically for C++
this in CTOR/DTORs
and during inlining we throw away all clobbers that end up "wrong" but
I guess we
might have latent issues when we obfuscate the address in the caller enough and
get undesired simplification ...

>
> diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
> index f8fcd2d97d9..5fb9a3a536d 100644
> --- a/gcc/fortran/trans-expr.cc
> +++ b/gcc/fortran/trans-expr.cc
> @@ -6544,8 +6544,9 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
> sym,
>                            && !sym->attr.elemental)
>                          {
>                            tree var;
> -                         var = build_fold_indirect_ref_loc (input_location,
> -                                                            parmse.expr);
> +                         var = build1_loc (input_location, INDIRECT_REF,
> +                                           TREE_TYPE (TREE_TYPE
> (parmse.expr)),
> +                                           parmse.expr);
>                            tree clobber = build_clobber (TREE_TYPE (var));
>                            gfc_add_modify (&clobbers, var, clobber);
>                          }
>

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-18 20:55               ` Mikael Morin
  2022-09-19  7:11                 ` Mikael Morin
@ 2022-09-19 19:46                 ` Harald Anlauf
  2022-09-19 20:50                   ` Mikael Morin
  1 sibling, 1 reply; 36+ messages in thread
From: Harald Anlauf @ 2022-09-19 19:46 UTC (permalink / raw)
  To: Mikael Morin, Thomas Koenig, Richard Biener
  Cc: Mikael Morin, gcc-patches, fortran

Am 18.09.22 um 22:55 schrieb Mikael Morin:
> Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
>>
>> Assumed shape will be on the easy side,
>> while assumed size likely needs to be excluded for clobbering.
>>
> Isn’t it the converse that is true?
> Assumed shape can be non-contiguous so have to be excluded, but assumed
> size are contiguous, so valid candidates for clobbering. No?

I really was referring here to *dummies*, as in the following example:

program p
   integer :: a(4)
   a = 1
   call sub (a(1), 2)
   print *, a
contains
   subroutine sub (b, k)
     integer, intent(in)  :: k
     integer, intent(out) :: b(*)
!   integer, intent(out) :: b(k)
     if (k > 2) b(k) = k
   end subroutine sub
end program p

Assumed size (*) is just a contiguous hunk of memory of possibly
unknown size, which can be zero.  So you couldn't set a clobber
for the a(1) actual argument.

> No way, really, arrays are going to be a maze of complexity.

Agreed.



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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-19 19:46                 ` Harald Anlauf
@ 2022-09-19 20:50                   ` Mikael Morin
  2022-09-20  6:54                     ` Thomas Koenig
  2022-09-20 21:08                     ` Harald Anlauf
  0 siblings, 2 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-19 20:50 UTC (permalink / raw)
  To: Harald Anlauf, Thomas Koenig, Richard Biener
  Cc: Mikael Morin, gcc-patches, fortran

Le 19/09/2022 à 21:46, Harald Anlauf a écrit :
> Am 18.09.22 um 22:55 schrieb Mikael Morin:
>> Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
>>>
>>> Assumed shape will be on the easy side,
>>> while assumed size likely needs to be excluded for clobbering.
>>>
>> Isn’t it the converse that is true?
>> Assumed shape can be non-contiguous so have to be excluded, but assumed
>> size are contiguous, so valid candidates for clobbering. No?
> 
> I really was referring here to *dummies*, as in the following example:
> 
> program p
>    integer :: a(4)
>    a = 1
>    call sub (a(1), 2)
>    print *, a
> contains
>    subroutine sub (b, k)
>      integer, intent(in)  :: k
>      integer, intent(out) :: b(*)
> !   integer, intent(out) :: b(k)
>      if (k > 2) b(k) = k
>    end subroutine sub
> end program p
> 
> Assumed size (*) is just a contiguous hunk of memory of possibly
> unknown size, which can be zero.  So you couldn't set a clobber
> for the a(1) actual argument.
> 
Couldn't you clobber A entirely?  If no element of B is initialized in 
SUB, well, A has undefined values on return from SUB.  That's how 
INTENT(OUT) works.

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-19 20:50                   ` Mikael Morin
@ 2022-09-20  6:54                     ` Thomas Koenig
  2022-09-20  8:46                       ` Mikael Morin
  2022-09-20 21:08                     ` Harald Anlauf
  1 sibling, 1 reply; 36+ messages in thread
From: Thomas Koenig @ 2022-09-20  6:54 UTC (permalink / raw)
  To: Mikael Morin, Harald Anlauf, Richard Biener
  Cc: Mikael Morin, gcc-patches, fortran


On 19.09.22 22:50, Mikael Morin wrote:
> Le 19/09/2022 à 21:46, Harald Anlauf a écrit :
>> Am 18.09.22 um 22:55 schrieb Mikael Morin:
>>> Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
>>>>
>>>> Assumed shape will be on the easy side,
>>>> while assumed size likely needs to be excluded for clobbering.
>>>>
>>> Isn’t it the converse that is true?
>>> Assumed shape can be non-contiguous so have to be excluded, but assumed
>>> size are contiguous, so valid candidates for clobbering. No?
>>
>> I really was referring here to *dummies*, as in the following example:
>>
>> program p
>>    integer :: a(4)
>>    a = 1
>>    call sub (a(1), 2)
>>    print *, a
>> contains
>>    subroutine sub (b, k)
>>      integer, intent(in)  :: k
>>      integer, intent(out) :: b(*)
>> !   integer, intent(out) :: b(k)
>>      if (k > 2) b(k) = k
>>    end subroutine sub
>> end program p
>>
>> Assumed size (*) is just a contiguous hunk of memory of possibly
>> unknown size, which can be zero.  So you couldn't set a clobber
>> for the a(1) actual argument.
>>
> Couldn't you clobber A entirely?  If no element of B is initialized in 
> SUB, well, A has undefined values on return from SUB.  That's how 
> INTENT(OUT) works.

Yes, I think so - you are passing the starting element of an array
to an assumed-size array via storage association rules.

It has to be an explicit interface, of course, otherwise it is
unclear if an array or an array element is passed.

Best regards

	Thomas

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-20  6:54                     ` Thomas Koenig
@ 2022-09-20  8:46                       ` Mikael Morin
  0 siblings, 0 replies; 36+ messages in thread
From: Mikael Morin @ 2022-09-20  8:46 UTC (permalink / raw)
  To: Thomas Koenig, Harald Anlauf; +Cc: Mikael Morin, gcc-patches, fortran

Le 20/09/2022 à 08:54, Thomas Koenig a écrit :
> 
> On 19.09.22 22:50, Mikael Morin wrote:
>> Le 19/09/2022 à 21:46, Harald Anlauf a écrit :
>>>
>>> Assumed size (*) is just a contiguous hunk of memory of possibly
>>> unknown size, which can be zero.  So you couldn't set a clobber
>>> for the a(1) actual argument.
>>>
>> Couldn't you clobber A entirely?  If no element of B is initialized in 
>> SUB, well, A has undefined values on return from SUB.  That's how 
>> INTENT(OUT) works.
> 
> Yes, I think so - you are passing the starting element of an array
> to an assumed-size array via storage association rules.
> 
> It has to be an explicit interface, of course, otherwise it is
> unclear if an array or an array element is passed.
> 

I have looked for the relevant excerpts from the standard.
 From 15.5.2.11 (sequence association):

> If the dummy argument is not of type character
> with default or C character kind, and the actual argument is an array element designator, the element sequence
> consists of that array element and each element that follows it in array element order.

> If the dummy argument is
> assumed-size, the number of elements in the dummy argument is exactly the number of elements in the element
> sequence.

So the dummy size, even if not known to the programmer, is clearly 
defined (to the full array size in your example).

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-19 20:50                   ` Mikael Morin
  2022-09-20  6:54                     ` Thomas Koenig
@ 2022-09-20 21:08                     ` Harald Anlauf
  2022-09-20 21:08                       ` Harald Anlauf
  2022-09-21  9:57                       ` Thomas Koenig
  1 sibling, 2 replies; 36+ messages in thread
From: Harald Anlauf @ 2022-09-20 21:08 UTC (permalink / raw)
  To: fortran; +Cc: gcc-patches

Am 19.09.22 um 22:50 schrieb Mikael Morin:
> Le 19/09/2022 à 21:46, Harald Anlauf a écrit :
>> Am 18.09.22 um 22:55 schrieb Mikael Morin:
>>> Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
>>>>
>>>> Assumed shape will be on the easy side,
>>>> while assumed size likely needs to be excluded for clobbering.
>>>>
>>> Isn’t it the converse that is true?
>>> Assumed shape can be non-contiguous so have to be excluded, but assumed
>>> size are contiguous, so valid candidates for clobbering. No?
>>
>> I really was referring here to *dummies*, as in the following example:
>>
>> program p
>>    integer :: a(4)
>>    a = 1
>>    call sub (a(1), 2)
>>    print *, a
>> contains
>>    subroutine sub (b, k)
>>      integer, intent(in)  :: k
>>      integer, intent(out) :: b(*)
>> !   integer, intent(out) :: b(k)
>>      if (k > 2) b(k) = k
>>    end subroutine sub
>> end program p
>>
>> Assumed size (*) is just a contiguous hunk of memory of possibly
>> unknown size, which can be zero.  So you couldn't set a clobber
>> for the a(1) actual argument.
>>
> Couldn't you clobber A entirely?  If no element of B is initialized in 
> SUB, well, A has undefined values on return from SUB.  That's how 
> INTENT(OUT) works.
> 

I think I understand much of what is said, but I feel that I do
not really understand what *clobber* means for the different
beasts we are discussing (although I have an impression of what
it means for a scalar object).




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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-20 21:08                     ` Harald Anlauf
@ 2022-09-20 21:08                       ` Harald Anlauf
  2022-09-21  9:57                       ` Thomas Koenig
  1 sibling, 0 replies; 36+ messages in thread
From: Harald Anlauf @ 2022-09-20 21:08 UTC (permalink / raw)
  To: Mikael Morin, Thomas Koenig, Richard Biener
  Cc: Mikael Morin, gcc-patches, fortran

Am 19.09.22 um 22:50 schrieb Mikael Morin:
> Le 19/09/2022 à 21:46, Harald Anlauf a écrit :
>> Am 18.09.22 um 22:55 schrieb Mikael Morin:
>>> Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
>>>>
>>>> Assumed shape will be on the easy side,
>>>> while assumed size likely needs to be excluded for clobbering.
>>>>
>>> Isn’t it the converse that is true?
>>> Assumed shape can be non-contiguous so have to be excluded, but assumed
>>> size are contiguous, so valid candidates for clobbering. No?
>>
>> I really was referring here to *dummies*, as in the following example:
>>
>> program p
>>    integer :: a(4)
>>    a = 1
>>    call sub (a(1), 2)
>>    print *, a
>> contains
>>    subroutine sub (b, k)
>>      integer, intent(in)  :: k
>>      integer, intent(out) :: b(*)
>> !   integer, intent(out) :: b(k)
>>      if (k > 2) b(k) = k
>>    end subroutine sub
>> end program p
>>
>> Assumed size (*) is just a contiguous hunk of memory of possibly
>> unknown size, which can be zero.  So you couldn't set a clobber
>> for the a(1) actual argument.
>>
> Couldn't you clobber A entirely?  If no element of B is initialized in
> SUB, well, A has undefined values on return from SUB.  That's how
> INTENT(OUT) works.
>

I think I understand much of what is said, but I feel that I do
not really understand what *clobber* means for the different
beasts we are discussing (although I have an impression of what
it means for a scalar object).


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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-20 21:08                     ` Harald Anlauf
  2022-09-20 21:08                       ` Harald Anlauf
@ 2022-09-21  9:57                       ` Thomas Koenig
  2022-09-21 18:56                         ` Mikael Morin
  1 sibling, 1 reply; 36+ messages in thread
From: Thomas Koenig @ 2022-09-21  9:57 UTC (permalink / raw)
  To: Harald Anlauf, Mikael Morin, Richard Biener; +Cc: gcc-patches, fortran


Hi Harald,

> I think I understand much of what is said, but I feel that I do
> not really understand what *clobber* means for the different
> beasts we are discussing (although I have an impression of what
> it means for a scalar object).

Obviously, "clobber" means taking a big stick and hitting the beast
in question over the head with it :-)

More seriously: My understanding of a clobber it is a hint to
the middle end that the value in question will not be used,
and that operations leading to this value can be removed,
unless they are used otherwise.

If I'm wrong or imprecise, I'm sure somebody will correct me :-)

Regards

	Thomas

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-21  9:57                       ` Thomas Koenig
@ 2022-09-21 18:56                         ` Mikael Morin
  2022-09-21 19:12                           ` Harald Anlauf
  0 siblings, 1 reply; 36+ messages in thread
From: Mikael Morin @ 2022-09-21 18:56 UTC (permalink / raw)
  To: Thomas Koenig, Harald Anlauf, Richard Biener; +Cc: gcc-patches, fortran

Le 21/09/2022 à 11:57, Thomas Koenig a écrit :
> 
> Hi Harald,
> 
>> I think I understand much of what is said, but I feel that I do
>> not really understand what *clobber* means for the different
>> beasts we are discussing (although I have an impression of what
>> it means for a scalar object).
> 
> Obviously, "clobber" means taking a big stick and hitting the beast
> in question over the head with it :-)
> 
> More seriously: My understanding of a clobber it is a hint to
> the middle end that the value in question will not be used,
> and that operations leading to this value can be removed,
> unless they are used otherwise.
> 
My understanding is that "clobber" means "overwrite with garbage" for 
all the beasts we have been discussing, which translates to nothing in 
the final code, but can be used by the optimizers as Thomas said.

This is a bit off-topic but clobbers model registers having their values 
changed unpredictably or by ways unknown to the compiler, in the backend 
code, or in inline assembly statements.
Here is an excerpt from rtl.texi:
> @item (clobber @var{x})
> Represents the storing or possible storing of an unpredictable,
> undescribed value into @var{x}

I Hope it helps.

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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-21 18:56                         ` Mikael Morin
@ 2022-09-21 19:12                           ` Harald Anlauf
  2022-09-21 19:12                             ` Harald Anlauf
  0 siblings, 1 reply; 36+ messages in thread
From: Harald Anlauf @ 2022-09-21 19:12 UTC (permalink / raw)
  To: fortran; +Cc: gcc-patches

Hi Mikael,

Am 21.09.22 um 20:56 schrieb Mikael Morin:
> Le 21/09/2022 à 11:57, Thomas Koenig a écrit :
>>
>> Hi Harald,
>>
>>> I think I understand much of what is said, but I feel that I do
>>> not really understand what *clobber* means for the different
>>> beasts we are discussing (although I have an impression of what
>>> it means for a scalar object).

>>
>> More seriously: My understanding of a clobber it is a hint to
>> the middle end that the value in question will not be used,
>> and that operations leading to this value can be removed,
>> unless they are used otherwise.
>>
> My understanding is that "clobber" means "overwrite with garbage" for 
> all the beasts we have been discussing, which translates to nothing in 
> the final code, but can be used by the optimizers as Thomas said.
> 
> This is a bit off-topic but clobbers model registers having their values 
> changed unpredictably or by ways unknown to the compiler, in the backend 
> code, or in inline assembly statements.
> Here is an excerpt from rtl.texi:
>> @item (clobber @var{x})
>> Represents the storing or possible storing of an unpredictable,
>> undescribed value into @var{x}

ah, I missed that file.  I only found references to assembly,
and references to registers etc. were not really helpful here.

It also says:

 > If @var{x} is @code{(mem:BLK (const_int 0))} or
 > @code{(mem:BLK (scratch))}, it means that all memory
 > locations must be presumed clobbered.  ...

so this goes into the direction I was thinking of.

> I Hope it helps.
> 




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

* Re: [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364]
  2022-09-21 19:12                           ` Harald Anlauf
@ 2022-09-21 19:12                             ` Harald Anlauf
  0 siblings, 0 replies; 36+ messages in thread
From: Harald Anlauf @ 2022-09-21 19:12 UTC (permalink / raw)
  To: Mikael Morin, Thomas Koenig, Richard Biener; +Cc: gcc-patches, fortran

Hi Mikael,

Am 21.09.22 um 20:56 schrieb Mikael Morin:
> Le 21/09/2022 à 11:57, Thomas Koenig a écrit :
>>
>> Hi Harald,
>>
>>> I think I understand much of what is said, but I feel that I do
>>> not really understand what *clobber* means for the different
>>> beasts we are discussing (although I have an impression of what
>>> it means for a scalar object).

>>
>> More seriously: My understanding of a clobber it is a hint to
>> the middle end that the value in question will not be used,
>> and that operations leading to this value can be removed,
>> unless they are used otherwise.
>>
> My understanding is that "clobber" means "overwrite with garbage" for
> all the beasts we have been discussing, which translates to nothing in
> the final code, but can be used by the optimizers as Thomas said.
>
> This is a bit off-topic but clobbers model registers having their values
> changed unpredictably or by ways unknown to the compiler, in the backend
> code, or in inline assembly statements.
> Here is an excerpt from rtl.texi:
>> @item (clobber @var{x})
>> Represents the storing or possible storing of an unpredictable,
>> undescribed value into @var{x}

ah, I missed that file.  I only found references to assembly,
and references to registers etc. were not really helpful here.

It also says:

 > If @var{x} is @code{(mem:BLK (const_int 0))} or
 > @code{(mem:BLK (scratch))}, it means that all memory
 > locations must be presumed clobbered.  ...

so this goes into the direction I was thinking of.

> I Hope it helps.
>


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

end of thread, other threads:[~2022-09-21 19:12 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-16 20:24 [PATCH 00/10] fortran: clobber fixes [PR41453] Mikael Morin
2022-09-16 20:24 ` [PATCH 01/10] fortran: Move the clobber generation code Mikael Morin
2022-09-16 20:24 ` [PATCH 02/10] fortran: Fix invalid function decl clobber ICE [PR105012] Mikael Morin
2022-09-16 20:24 ` [PATCH 03/10] fortran: Move clobbers after evaluation of all arguments [PR106817] Mikael Morin
2022-09-16 20:24 ` [PATCH 04/10] fortran: Support clobbering with implicit interfaces [PR105012] Mikael Morin
2022-09-16 20:24 ` [PATCH 05/10] fortran: Support clobbering of reference variables [PR41453] Mikael Morin
2022-09-16 20:24 ` [PATCH 06/10] fortran: Support clobbering of SAVE variables [PR87395] Mikael Morin
2022-09-16 20:24 ` [PATCH 07/10] fortran: Support clobbering of ASSOCIATE variables [PR87397] Mikael Morin
2022-09-16 20:24 ` [PATCH 08/10] fortran: Support clobbering of allocatables and pointers [PR41453] Mikael Morin
2022-09-16 20:24 ` [PATCH 09/10] fortran: Support clobbering of variable subreferences [PR88364] Mikael Morin
2022-09-17 17:03   ` Thomas Koenig
2022-09-17 19:33     ` Mikael Morin
2022-09-17 19:49       ` Bernhard Reutner-Fischer
2022-09-17 19:50       ` Mikael Morin
2022-09-17 21:24         ` Bernhard Reutner-Fischer
2022-09-18  6:12       ` Richard Biener
2022-09-18  9:10         ` Mikael Morin
2022-09-18 10:23           ` Thomas Koenig
2022-09-18 18:32             ` Harald Anlauf
2022-09-18 20:55               ` Mikael Morin
2022-09-19  7:11                 ` Mikael Morin
2022-09-19 19:46                 ` Harald Anlauf
2022-09-19 20:50                   ` Mikael Morin
2022-09-20  6:54                     ` Thomas Koenig
2022-09-20  8:46                       ` Mikael Morin
2022-09-20 21:08                     ` Harald Anlauf
2022-09-20 21:08                       ` Harald Anlauf
2022-09-21  9:57                       ` Thomas Koenig
2022-09-21 18:56                         ` Mikael Morin
2022-09-21 19:12                           ` Harald Anlauf
2022-09-21 19:12                             ` Harald Anlauf
2022-09-18 20:43             ` Mikael Morin
2022-09-18 10:48           ` Richard Biener
2022-09-19  7:31             ` Mikael Morin
2022-09-19  7:58               ` Richard Biener
2022-09-16 20:24 ` [PATCH 10/10] fortran: Support clobbering of derived types [PR41453] 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).