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
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
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
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
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
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
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
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
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
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
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
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
[-- 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" } }
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!
[-- 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" } }
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,
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 >
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].
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
> 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
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
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.
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.
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.
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); }
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); > } >
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.
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.
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
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).
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).
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).
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
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.
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. >
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. >