[Patch/fortran] PR87477 [meta-bug] [F03] issues concerning the ASSOCIATE statement
After two months on trunk, this has been backported: Fortran: Fix some problems blocking associate meta-bug [PR87477] 2023-08-27 Paul Thomas gcc/fortran PR fortran/87477 * parse.cc (parse_associate): Replace the existing evaluation of the target rank with calls to gfc_resolve_ref and gfc_expression_rank. Identify untyped target function results with structure constructors by finding the appropriate derived type. * resolve.cc (resolve_symbol): Allow associate variables to be assumed shape. gcc/testsuite/ PR fortran/87477 * gfortran.dg/associate_54.f90 : Cope with extra error. PR fortran/102109 * gfortran.dg/pr102109.f90 : New test. PR fortran/102112 * gfortran.dg/pr102112.f90 : New test. PR fortran/102190 * gfortran.dg/pr102190.f90 : New test. PR fortran/102532 * gfortran.dg/pr102532.f90 : New test. PR fortran/109948 * gfortran.dg/pr109948.f90 : New test. PR fortran/99326 * gfortran.dg/pr99326.f90 : New test. Regards Paul
Re: [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Thanks Mikael. Pushed as r14-1487-g3c2eba4b7a2355ed5099e35332388206c484744d I should have credited you with the comments that you made about the half baked patch, which pushed me to this patch. Regards Paul On Thu, 1 Jun 2023 at 18:58, Mikael Morin wrote: > Le 01/06/2023 à 17:20, Paul Richard Thomas via Fortran a écrit : > > Hi All, > > > > This started out as the search for a fix to pr109948 and evolved to roll > in > > 5 other prs. > > > > Basically parse_associate was far too clunky and, in anycase, existing > > functions in resolve.cc were well capable of doing the determination of > the > > target expression rank. While I was checking the comments, the lightbulb > > flashed with respect to prs 102109/112/190 and the chunk dealing with > > function results of unknown type was born. > > > > Thanks to the changes in parse.cc, the problem in pr99326 migrated > > upstream to the resolution and the chunklet in resolve.cc was an obvious > > fix. > > > > I am minded to s/{ dg-do run}/{ dg-do compile } for all six testcases. > Makes sense, the PRs were bogus errors and ICEs, so all compile time > issues. > > > At > > the testing stage, I wanted to check that the testcases actually did what > > they are supposed to do :-) > > > > Bootstraps and regtests OK - good for head? > > > OK. Thanks for this. > > > Paul > > > > PS I need to do some housekeeping on pr87477 now. Some of the blockers > have > > "fixed themselves" and others are awaiting backporting. I think that > there > > are only 4 or so left, of which 89645 and 99065 are the most difficult to > > deal with. > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Le 01/06/2023 à 17:20, Paul Richard Thomas via Fortran a écrit : Hi All, This started out as the search for a fix to pr109948 and evolved to roll in 5 other prs. Basically parse_associate was far too clunky and, in anycase, existing functions in resolve.cc were well capable of doing the determination of the target expression rank. While I was checking the comments, the lightbulb flashed with respect to prs 102109/112/190 and the chunk dealing with function results of unknown type was born. Thanks to the changes in parse.cc, the problem in pr99326 migrated upstream to the resolution and the chunklet in resolve.cc was an obvious fix. I am minded to s/{ dg-do run}/{ dg-do compile } for all six testcases. Makes sense, the PRs were bogus errors and ICEs, so all compile time issues. At the testing stage, I wanted to check that the testcases actually did what they are supposed to do :-) Bootstraps and regtests OK - good for head? OK. Thanks for this. Paul PS I need to do some housekeeping on pr87477 now. Some of the blockers have "fixed themselves" and others are awaiting backporting. I think that there are only 4 or so left, of which 89645 and 99065 are the most difficult to deal with.
[Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Hi All, This started out as the search for a fix to pr109948 and evolved to roll in 5 other prs. Basically parse_associate was far too clunky and, in anycase, existing functions in resolve.cc were well capable of doing the determination of the target expression rank. While I was checking the comments, the lightbulb flashed with respect to prs 102109/112/190 and the chunk dealing with function results of unknown type was born. Thanks to the changes in parse.cc, the problem in pr99326 migrated upstream to the resolution and the chunklet in resolve.cc was an obvious fix. I am minded to s/{ dg-do run}/{ dg-do compile } for all six testcases. At the testing stage, I wanted to check that the testcases actually did what they are supposed to do :-) Bootstraps and regtests OK - good for head? Paul PS I need to do some housekeeping on pr87477 now. Some of the blockers have "fixed themselves" and others are awaiting backporting. I think that there are only 4 or so left, of which 89645 and 99065 are the most difficult to deal with. diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc index 5e2a95688d2..3947444f17c 100644 --- a/gcc/fortran/parse.cc +++ b/gcc/fortran/parse.cc @@ -4919,6 +4919,7 @@ parse_associate (void) gfc_state_data s; gfc_statement st; gfc_association_list* a; + gfc_array_spec *as; gfc_notify_std (GFC_STD_F2003, "ASSOCIATE construct at %C"); @@ -4934,8 +4935,7 @@ parse_associate (void) for (a = new_st.ext.block.assoc; a; a = a->next) { gfc_symbol* sym; - gfc_ref *ref; - gfc_array_ref *array_ref; + gfc_expr *target; if (gfc_get_sym_tree (a->name, NULL, &a->st, false)) gcc_unreachable (); @@ -4952,6 +4952,7 @@ parse_associate (void) for parsing component references on the associate-name in case of association to a derived-type. */ sym->ts = a->target->ts; + target = a->target; /* Don’t share the character length information between associate variable and target if the length is not a compile-time constant, @@ -4971,31 +4972,37 @@ parse_associate (void) && sym->ts.u.cl->length->expr_type == EXPR_CONSTANT)) sym->ts.u.cl = gfc_new_charlen (gfc_current_ns, NULL); - /* Check if the target expression is array valued. This cannot always - be done by looking at target.rank, because that might not have been - set yet. Therefore traverse the chain of refs, looking for the last - array ref and evaluate that. */ - array_ref = NULL; - for (ref = a->target->ref; ref; ref = ref->next) - if (ref->type == REF_ARRAY) - array_ref = &ref->u.ar; - if (array_ref || a->target->rank) + /* Check if the target expression is array valued. This cannot be done + by calling gfc_resolve_expr because the context is unavailable. + However, the references can be resolved and the rank of the target + expression set. */ + if (target->ref && gfc_resolve_ref (target) + && target->expr_type != EXPR_ARRAY + && target->expr_type != EXPR_COMPCALL) + gfc_expression_rank (target); + + /* Determine whether or not function expressions with unknown type are + structure constructors. If so, the function result can be converted + to be a derived type. + TODO: Deal with references to sibling functions that have not yet been + parsed (PRs 89645 and 99065). */ + if (target->expr_type == EXPR_FUNCTION && target->ts.type == BT_UNKNOWN) { - gfc_array_spec *as; - int dim, rank = 0; - if (array_ref) + gfc_symbol *derived; + /* The derived type has a leading uppercase character. */ + gfc_find_symbol (gfc_dt_upper_string (target->symtree->name), + my_ns->parent, 1, &derived); + if (derived && derived->attr.flavor == FL_DERIVED) { - a->rankguessed = 1; - /* Count the dimension, that have a non-scalar extend. */ - for (dim = 0; dim < array_ref->dimen; ++dim) - if (array_ref->dimen_type[dim] != DIMEN_ELEMENT - && !(array_ref->dimen_type[dim] == DIMEN_UNKNOWN - && array_ref->end[dim] == NULL - && array_ref->start[dim] != NULL)) - ++rank; + sym->ts.type = BT_DERIVED; + sym->ts.u.derived = derived; } - else - rank = a->target->rank; + } + + if (target->rank) + { + int rank = 0; + rank = target->rank; /* When the rank is greater than zero then sym will be an array. */ if (sym->ts.type == BT_CLASS && CLASS_DATA (sym)) { @@ -5006,8 +5013,8 @@ parse_associate (void) /* Don't just (re-)set the attr and as in the sym.ts, because this modifies the target's attr and as. Copy the data and do a build_class_symbol. */ - symbol_attribute attr = CLASS_DATA (a->target)->attr; - int corank = gfc_get_corank (a->target); + symbol_attribute attr = CLASS_DATA (target)->attr; + int corank = gfc_get_corank (target); gfc_typespec type; if (rank || corank) @@ -5042,7 +5049,7 @@ parse_associate (void) as = gfc_get_array_spec (); as->type = AS_DEFERR
Re: Ping! [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Hi Paul, On 4/7/23 23:35, Paul Richard Thomas via Gcc-patches wrote: Hi Harald, Well done on noticing the memory leak :-) I have a fix for it that I was going to post separately. Actually, it is a trivial one liner, which I could include with the patch. thanks for addressing this! I can confirm that this correction does the job. Great work! Harald @@ -2554,23 +2559,25 @@ gfc_conv_string_length (gfc_charlen * cl, gfc_expr * expr, stmtblock_t * pblock) expr_flat = gfc_copy_expr (expr); flatten_array_ctors_without_strlen (expr_flat); gfc_resolve_expr (expr_flat); - - gfc_conv_expr (&se, expr_flat); - gfc_add_block_to_block (pblock, &se.pre); - cl->backend_decl = convert (gfc_charlen_type_node, se.string_length); - + if (expr_flat->rank) + gfc_conv_expr_descriptor (&se, expr_flat); + else + gfc_conv_expr (&se, expr_flat); + if (expr_flat->expr_type != EXPR_VARIABLE) + gfc_add_block_to_block (pblock, &se.pre); + se.expr = convert (gfc_charlen_type_node, se.string_length); + gfc_add_block_to_block (pblock, &se.post); // <<>> gfc_free_expr (expr_flat); - return; } - - /* Convert cl->length. */ - - gcc_assert (cl->length); - - gfc_conv_expr_type (&se, cl->length, gfc_charlen_type_node); - se.expr = fold_build2_loc (input_location, MAX_EXPR, gfc_charlen_type_node, -se.expr, build_zero_cst (TREE_TYPE (se.expr))); - gfc_add_block_to_block (pblock, &se.pre); + else +{ + /* Convert cl->length. */ + gfc_conv_expr_type (&se, cl->length, gfc_charlen_type_node); + se.expr = fold_build2_loc (input_location, MAX_EXPR, +gfc_charlen_type_node, se.expr, +build_zero_cst (TREE_TYPE (se.expr))); + gfc_add_block_to_block (pblock, &se.pre); +} if (cl->backend_decl && VAR_P (cl->backend_decl)) gfc_add_modify (pblock, cl->backend_decl, se.expr); Cheers Paul On Fri, 7 Apr 2023 at 20:28, Harald Anlauf wrote: Hi Paul, On 4/7/23 15:53, Paul Richard Thomas via Gcc-patches wrote: duuuh! Please find them attached. the patch LGTM. Thanks! However, I have comments on the new testcase associate_60.f90: subroutine pr93813 is missing an allocation of x, e.g.: allocate (t :: x) otherwise it would be invalid. Please check and fix. Interestingly, subroutine pr92779 exhibits a small memory leak with memory allocated by the spread intrinsic. I played a little and found that the leak depends on the presence of trim(): omitting trim() removes the leak. But looking at the related pr, it seems that trim() was essential, so omitting it is likely not an option. I think the best way is to proceed and to open a PR on the memory leak rather than leaving pr92779 open. What do you think? Cheers, Harald Thanks Paul On Fri, 7 Apr 2023 at 10:41, Harald Anlauf wrote: Hi Paul, I don't see the new testcases. Is this an issue on my side, or did you forget to attach them? Thanks, Harald On 4/7/23 09:07, Paul Richard Thomas via Gcc-patches wrote: Dear All, Please find attached a slightly updated version of the patch with a consolidated testcase. The three additional testcases are nothing to do with associate and test fixes of character related bugs. OK for mainline? Cheers Paul Fortran: Fix some of the bugs in associate [PR87477] 2023-04-07 Paul Thomas gcc/fortran PR fortran/87477 * resolve.cc (resolve_assoc_var): Handle parentheses around the target expression. (resolve_block_construct): Remove unnecessary static decls. * trans-array.cc (gfc_conv_expr_descriptor): Guard string len expression in condition. Improve handling of string length and span, especially for substrings of the descriptor. (duplicate_allocatable): Make element type more explicit with 'eltype'. * trans_decl.cc (gfc_get_symbol_decl): Emit a fatal error with appropriate message instead of ICE if symbol type is unknown. * trans-expr.cc (gfc_get_expr_charlen): Retain last charlen in 'previous' and use if end expression in substring reference is null. (gfc_conv_string_length): Use gfc_conv_expr_descriptor if 'expr_flat' is an array. (gfc_trans_alloc_subarray_assign): If this is a deferred string length component, store the string length in the hidden comp. Update the typespec length accordingly. Generate a new type spec for the call to gfc_duplicate-allocatable in this case. * trans-io.cc (gfc_trans_transfer): Scalarize transfer of deferred character array components. gcc/testsuite/ PR fortran/87477 * gfortran.dg/finalize_47.f90 : Enable substring test. * gfortran.dg/finalize_51.f90 : Update an error message. PR fortran/85686 PR fortran/88247 PR fortran/91941 PR fortran/92779 PR fortran/93339 PR fortran/93813 PR fortran/100948 PR fortran/102106 * gfortran.dg/associate_60.f90 : New test PR fortran/98408 * gfortran.dg/pr98408.f90 : New test PR fortran/105205 * gfortran.dg/pr105205.f90 : New test PR
Re: Ping! [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
PS Quite right about the allocation in PR93813 - consider it to be included. Cheers and thanks Paul On Fri, 7 Apr 2023 at 22:35, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Harald, > > Well done on noticing the memory leak :-) I have a fix for it that I was > going to post separately. Actually, it is a trivial one liner, which I > could include with the patch. > @@ -2554,23 +2559,25 @@ gfc_conv_string_length (gfc_charlen * cl, gfc_expr > * expr, stmtblock_t * pblock) >expr_flat = gfc_copy_expr (expr); >flatten_array_ctors_without_strlen (expr_flat); >gfc_resolve_expr (expr_flat); > - > - gfc_conv_expr (&se, expr_flat); > - gfc_add_block_to_block (pblock, &se.pre); > - cl->backend_decl = convert (gfc_charlen_type_node, > se.string_length); > - > + if (expr_flat->rank) > + gfc_conv_expr_descriptor (&se, expr_flat); > + else > + gfc_conv_expr (&se, expr_flat); > + if (expr_flat->expr_type != EXPR_VARIABLE) > + gfc_add_block_to_block (pblock, &se.pre); > + se.expr = convert (gfc_charlen_type_node, se.string_length); > + gfc_add_block_to_block (pblock, &se.post); > // <<>> >gfc_free_expr (expr_flat); > - return; > } > - > - /* Convert cl->length. */ > - > - gcc_assert (cl->length); > - > - gfc_conv_expr_type (&se, cl->length, gfc_charlen_type_node); > - se.expr = fold_build2_loc (input_location, MAX_EXPR, > gfc_charlen_type_node, > -se.expr, build_zero_cst (TREE_TYPE > (se.expr))); > - gfc_add_block_to_block (pblock, &se.pre); > + else > +{ > + /* Convert cl->length. */ > + gfc_conv_expr_type (&se, cl->length, gfc_charlen_type_node); > + se.expr = fold_build2_loc (input_location, MAX_EXPR, > +gfc_charlen_type_node, se.expr, > +build_zero_cst (TREE_TYPE (se.expr))); > + gfc_add_block_to_block (pblock, &se.pre); > +} > >if (cl->backend_decl && VAR_P (cl->backend_decl)) > gfc_add_modify (pblock, cl->backend_decl, se.expr); > > Cheers > > Paul > > > On Fri, 7 Apr 2023 at 20:28, Harald Anlauf wrote: > >> Hi Paul, >> >> On 4/7/23 15:53, Paul Richard Thomas via Gcc-patches wrote: >> > duuuh! Please find them attached. >> >> the patch LGTM. Thanks! >> >> However, I have comments on the new testcase associate_60.f90: >> subroutine pr93813 is missing an allocation of x, e.g.: >> >> allocate (t :: x) >> >> otherwise it would be invalid. Please check and fix. >> >> Interestingly, subroutine pr92779 exhibits a small memory leak >> with memory allocated by the spread intrinsic. I played a little >> and found that the leak depends on the presence of trim(): omitting >> trim() removes the leak. But looking at the related pr, it seems >> that trim() was essential, so omitting it is likely not an option. >> >> I think the best way is to proceed and to open a PR on the memory >> leak rather than leaving pr92779 open. What do you think? >> >> Cheers, >> Harald >> >> >> > Thanks >> > >> > Paul >> > >> > >> > On Fri, 7 Apr 2023 at 10:41, Harald Anlauf wrote: >> > >> >> Hi Paul, >> >> >> >> I don't see the new testcases. Is this an issue on my side, >> >> or did you forget to attach them? >> >> >> >> Thanks, >> >> Harald >> >> >> >> On 4/7/23 09:07, Paul Richard Thomas via Gcc-patches wrote: >> >>> Dear All, >> >>> >> >>> Please find attached a slightly updated version of the patch with a >> >>> consolidated testcase. The three additional testcases are nothing to >> do >> >>> with associate and test fixes of character related bugs. >> >>> >> >>> OK for mainline? >> >>> >> >>> Cheers >> >>> >> >>> Paul >> >>> Fortran: Fix some of the bugs in associate [PR87477] >> >>> >> >>> 2023-04-07 Paul Thomas >> >>> >> >>> gcc/fortran >> >>> PR fortran/87477 >> >>> * resolve.cc (resolve_assoc_var): Handle parentheses around the >> >>> target expression. >> >>> (resolve_block_construct): Remove unnecessary static decls. >> >>> * trans-array.cc (gfc_conv_expr_descriptor): Guard string len >> >>> expression in condition. Improve handling of string length and >> >>> span, especially for substrings of the descriptor. >> >>> (duplicate_allocatable): Make element type more explicit with >> >>> 'eltype'. >> >>> * trans_decl.cc (gfc_get_symbol_decl): Emit a fatal error with >> >>> appropriate message instead of ICE if symbol type is unknown. >> >>> * trans-expr.cc (gfc_get_expr_charlen): Retain last charlen in >> >>> 'previous' and use if end expression in substring reference is >> >>> null. >> >>> (gfc_conv_string_length): Use gfc_conv_expr_descriptor if >> >>> 'expr_flat' is an array. >> >>> (gfc_trans_alloc_subarray_assign): If this is a deferred string >> >>> length component, store the string length in the hidden comp. >> >>> Update the typespec length accordingly. Generate a new type >> >>> spec for the call to gfc_duplicate-allocatable in this case. >> >>> * trans-io
Re: Ping! [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Hi Harald, Well done on noticing the memory leak :-) I have a fix for it that I was going to post separately. Actually, it is a trivial one liner, which I could include with the patch. @@ -2554,23 +2559,25 @@ gfc_conv_string_length (gfc_charlen * cl, gfc_expr * expr, stmtblock_t * pblock) expr_flat = gfc_copy_expr (expr); flatten_array_ctors_without_strlen (expr_flat); gfc_resolve_expr (expr_flat); - - gfc_conv_expr (&se, expr_flat); - gfc_add_block_to_block (pblock, &se.pre); - cl->backend_decl = convert (gfc_charlen_type_node, se.string_length); - + if (expr_flat->rank) + gfc_conv_expr_descriptor (&se, expr_flat); + else + gfc_conv_expr (&se, expr_flat); + if (expr_flat->expr_type != EXPR_VARIABLE) + gfc_add_block_to_block (pblock, &se.pre); + se.expr = convert (gfc_charlen_type_node, se.string_length); + gfc_add_block_to_block (pblock, &se.post); // <<>> gfc_free_expr (expr_flat); - return; } - - /* Convert cl->length. */ - - gcc_assert (cl->length); - - gfc_conv_expr_type (&se, cl->length, gfc_charlen_type_node); - se.expr = fold_build2_loc (input_location, MAX_EXPR, gfc_charlen_type_node, -se.expr, build_zero_cst (TREE_TYPE (se.expr))); - gfc_add_block_to_block (pblock, &se.pre); + else +{ + /* Convert cl->length. */ + gfc_conv_expr_type (&se, cl->length, gfc_charlen_type_node); + se.expr = fold_build2_loc (input_location, MAX_EXPR, +gfc_charlen_type_node, se.expr, +build_zero_cst (TREE_TYPE (se.expr))); + gfc_add_block_to_block (pblock, &se.pre); +} if (cl->backend_decl && VAR_P (cl->backend_decl)) gfc_add_modify (pblock, cl->backend_decl, se.expr); Cheers Paul On Fri, 7 Apr 2023 at 20:28, Harald Anlauf wrote: > Hi Paul, > > On 4/7/23 15:53, Paul Richard Thomas via Gcc-patches wrote: > > duuuh! Please find them attached. > > the patch LGTM. Thanks! > > However, I have comments on the new testcase associate_60.f90: > subroutine pr93813 is missing an allocation of x, e.g.: > > allocate (t :: x) > > otherwise it would be invalid. Please check and fix. > > Interestingly, subroutine pr92779 exhibits a small memory leak > with memory allocated by the spread intrinsic. I played a little > and found that the leak depends on the presence of trim(): omitting > trim() removes the leak. But looking at the related pr, it seems > that trim() was essential, so omitting it is likely not an option. > > I think the best way is to proceed and to open a PR on the memory > leak rather than leaving pr92779 open. What do you think? > > Cheers, > Harald > > > > Thanks > > > > Paul > > > > > > On Fri, 7 Apr 2023 at 10:41, Harald Anlauf wrote: > > > >> Hi Paul, > >> > >> I don't see the new testcases. Is this an issue on my side, > >> or did you forget to attach them? > >> > >> Thanks, > >> Harald > >> > >> On 4/7/23 09:07, Paul Richard Thomas via Gcc-patches wrote: > >>> Dear All, > >>> > >>> Please find attached a slightly updated version of the patch with a > >>> consolidated testcase. The three additional testcases are nothing to do > >>> with associate and test fixes of character related bugs. > >>> > >>> OK for mainline? > >>> > >>> Cheers > >>> > >>> Paul > >>> Fortran: Fix some of the bugs in associate [PR87477] > >>> > >>> 2023-04-07 Paul Thomas > >>> > >>> gcc/fortran > >>> PR fortran/87477 > >>> * resolve.cc (resolve_assoc_var): Handle parentheses around the > >>> target expression. > >>> (resolve_block_construct): Remove unnecessary static decls. > >>> * trans-array.cc (gfc_conv_expr_descriptor): Guard string len > >>> expression in condition. Improve handling of string length and > >>> span, especially for substrings of the descriptor. > >>> (duplicate_allocatable): Make element type more explicit with > >>> 'eltype'. > >>> * trans_decl.cc (gfc_get_symbol_decl): Emit a fatal error with > >>> appropriate message instead of ICE if symbol type is unknown. > >>> * trans-expr.cc (gfc_get_expr_charlen): Retain last charlen in > >>> 'previous' and use if end expression in substring reference is > >>> null. > >>> (gfc_conv_string_length): Use gfc_conv_expr_descriptor if > >>> 'expr_flat' is an array. > >>> (gfc_trans_alloc_subarray_assign): If this is a deferred string > >>> length component, store the string length in the hidden comp. > >>> Update the typespec length accordingly. Generate a new type > >>> spec for the call to gfc_duplicate-allocatable in this case. > >>> * trans-io.cc (gfc_trans_transfer): Scalarize transfer of > >>> deferred character array components. > >>> > >>> > >>> gcc/testsuite/ > >>> PR fortran/87477 > >>> * gfortran.dg/finalize_47.f90 : Enable substring test. > >>> * gfortran.dg/finalize_51.f90 : Update an error message. > >>> > >>> PR fortran/85686 > >>> PR fortran/88247 > >>> PR fortran/91941 > >>> PR fortran/92779 > >>> PR fortran/9333
Re: Ping! [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Hi Paul, On 4/7/23 15:53, Paul Richard Thomas via Gcc-patches wrote: duuuh! Please find them attached. the patch LGTM. Thanks! However, I have comments on the new testcase associate_60.f90: subroutine pr93813 is missing an allocation of x, e.g.: allocate (t :: x) otherwise it would be invalid. Please check and fix. Interestingly, subroutine pr92779 exhibits a small memory leak with memory allocated by the spread intrinsic. I played a little and found that the leak depends on the presence of trim(): omitting trim() removes the leak. But looking at the related pr, it seems that trim() was essential, so omitting it is likely not an option. I think the best way is to proceed and to open a PR on the memory leak rather than leaving pr92779 open. What do you think? Cheers, Harald Thanks Paul On Fri, 7 Apr 2023 at 10:41, Harald Anlauf wrote: Hi Paul, I don't see the new testcases. Is this an issue on my side, or did you forget to attach them? Thanks, Harald On 4/7/23 09:07, Paul Richard Thomas via Gcc-patches wrote: Dear All, Please find attached a slightly updated version of the patch with a consolidated testcase. The three additional testcases are nothing to do with associate and test fixes of character related bugs. OK for mainline? Cheers Paul Fortran: Fix some of the bugs in associate [PR87477] 2023-04-07 Paul Thomas gcc/fortran PR fortran/87477 * resolve.cc (resolve_assoc_var): Handle parentheses around the target expression. (resolve_block_construct): Remove unnecessary static decls. * trans-array.cc (gfc_conv_expr_descriptor): Guard string len expression in condition. Improve handling of string length and span, especially for substrings of the descriptor. (duplicate_allocatable): Make element type more explicit with 'eltype'. * trans_decl.cc (gfc_get_symbol_decl): Emit a fatal error with appropriate message instead of ICE if symbol type is unknown. * trans-expr.cc (gfc_get_expr_charlen): Retain last charlen in 'previous' and use if end expression in substring reference is null. (gfc_conv_string_length): Use gfc_conv_expr_descriptor if 'expr_flat' is an array. (gfc_trans_alloc_subarray_assign): If this is a deferred string length component, store the string length in the hidden comp. Update the typespec length accordingly. Generate a new type spec for the call to gfc_duplicate-allocatable in this case. * trans-io.cc (gfc_trans_transfer): Scalarize transfer of deferred character array components. gcc/testsuite/ PR fortran/87477 * gfortran.dg/finalize_47.f90 : Enable substring test. * gfortran.dg/finalize_51.f90 : Update an error message. PR fortran/85686 PR fortran/88247 PR fortran/91941 PR fortran/92779 PR fortran/93339 PR fortran/93813 PR fortran/100948 PR fortran/102106 * gfortran.dg/associate_60.f90 : New test PR fortran/98408 * gfortran.dg/pr98408.f90 : New test PR fortran/105205 * gfortran.dg/pr105205.f90 : New test PR fortran/106918 * gfortran.dg/pr106918.f90 : New test
Re: Ping! [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
duuuh! Please find them attached. Thanks Paul On Fri, 7 Apr 2023 at 10:41, Harald Anlauf wrote: > Hi Paul, > > I don't see the new testcases. Is this an issue on my side, > or did you forget to attach them? > > Thanks, > Harald > > On 4/7/23 09:07, Paul Richard Thomas via Gcc-patches wrote: > > Dear All, > > > > Please find attached a slightly updated version of the patch with a > > consolidated testcase. The three additional testcases are nothing to do > > with associate and test fixes of character related bugs. > > > > OK for mainline? > > > > Cheers > > > > Paul > > Fortran: Fix some of the bugs in associate [PR87477] > > > > 2023-04-07 Paul Thomas > > > > gcc/fortran > > PR fortran/87477 > > * resolve.cc (resolve_assoc_var): Handle parentheses around the > > target expression. > > (resolve_block_construct): Remove unnecessary static decls. > > * trans-array.cc (gfc_conv_expr_descriptor): Guard string len > > expression in condition. Improve handling of string length and > > span, especially for substrings of the descriptor. > > (duplicate_allocatable): Make element type more explicit with > > 'eltype'. > > * trans_decl.cc (gfc_get_symbol_decl): Emit a fatal error with > > appropriate message instead of ICE if symbol type is unknown. > > * trans-expr.cc (gfc_get_expr_charlen): Retain last charlen in > > 'previous' and use if end expression in substring reference is > > null. > > (gfc_conv_string_length): Use gfc_conv_expr_descriptor if > > 'expr_flat' is an array. > > (gfc_trans_alloc_subarray_assign): If this is a deferred string > > length component, store the string length in the hidden comp. > > Update the typespec length accordingly. Generate a new type > > spec for the call to gfc_duplicate-allocatable in this case. > > * trans-io.cc (gfc_trans_transfer): Scalarize transfer of > > deferred character array components. > > > > > > gcc/testsuite/ > > PR fortran/87477 > > * gfortran.dg/finalize_47.f90 : Enable substring test. > > * gfortran.dg/finalize_51.f90 : Update an error message. > > > > PR fortran/85686 > > PR fortran/88247 > > PR fortran/91941 > > PR fortran/92779 > > PR fortran/93339 > > PR fortran/93813 > > PR fortran/100948 > > PR fortran/102106 > > * gfortran.dg/associate_60.f90 : New test > > > > PR fortran/98408 > > * gfortran.dg/pr98408.f90 : New test > > > > PR fortran/105205 > > * gfortran.dg/pr105205.f90 : New test > > > > PR fortran/106918 > > * gfortran.dg/pr106918.f90 : New test > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein ! { dg-do run } ! ! Tests fixes for various pr87477 dependencies ! ! Contributed by Gerhard Steinmetz except for pr102106: ! which was contributed by Brad Richardson ! program associate_60 implicit none character(20) :: buffer call pr102106 call pr100948 call pr85686 call pr88247 call pr91941 call pr92779 call pr93339 call pr93813 contains subroutine pr102106 type :: sub_class_t integer :: i end type type :: with_polymorphic_component_t class(sub_class_t), allocatable :: sub_obj_ end type associate(obj => with_polymorphic_component_t(sub_class_t(42))) if (obj%sub_obj_%i .ne. 42) stop 1 end associate end subroutine pr100948 type t character(:), allocatable :: c(:) end type type(t), allocatable :: x ! ! Valid test in comment 1 ! x = t(['ab','cd']) associate (y => x%c(:)) if (any (y .ne. x%c)) stop 2 if (any (y .ne. ['ab','cd'])) stop 3 end associate deallocate (x) ! ! Allocation with source was found to only copy over one of the array elements ! allocate (x, source = t(['ef','gh'])) associate (y => x%c(:)) if (any (y .ne. x%c)) stop 4 if (any (y .ne. ['ef','gh'])) stop 5 end associate deallocate (x) end subroutine pr85686 call s85686([" g'day "," bye!! "]) if (trim (buffer) .ne. " a g'day a bye!!") stop 6 end subroutine s85686(x) character(*) :: x(:) associate (y => 'a'//x) write (buffer, *) y ! Used to segfault at the write statement. end associate end subroutine pr88247 type t character(:), dimension(:), allocatable :: d end type t type(t), allocatable :: x character(5) :: buffer(3) allocate (x, source = t (['ab','cd'])) ! Didn't work write(buffer(1), *) x%d(2:1:-1)! Was found to be broken write(buffer(2), *) [x%d(2:1:-1)] ! Was OK associate (y => [x%d(2:1:-1)]) write(buffer(3), *) y! Bug in comment 7 end associate if (any (buffer .ne. " cdab")) stop 7 end subroutine pr91941 character(:), allocatable :: x(:), z(:) x = [' abc', ' xyz'] z = adjustl(x) associate (y => adjustl(x)) ! Wrong character length was passed if (any(y .ne. ['abc ', 'xyz '])) stop 8 end associate end subroutine pr92779 character(3) :: a = 'abc' associate (y => spread(trim(a),1,2
Re: Ping! [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Hi Paul, I don't see the new testcases. Is this an issue on my side, or did you forget to attach them? Thanks, Harald On 4/7/23 09:07, Paul Richard Thomas via Gcc-patches wrote: Dear All, Please find attached a slightly updated version of the patch with a consolidated testcase. The three additional testcases are nothing to do with associate and test fixes of character related bugs. OK for mainline? Cheers Paul Fortran: Fix some of the bugs in associate [PR87477] 2023-04-07 Paul Thomas gcc/fortran PR fortran/87477 * resolve.cc (resolve_assoc_var): Handle parentheses around the target expression. (resolve_block_construct): Remove unnecessary static decls. * trans-array.cc (gfc_conv_expr_descriptor): Guard string len expression in condition. Improve handling of string length and span, especially for substrings of the descriptor. (duplicate_allocatable): Make element type more explicit with 'eltype'. * trans_decl.cc (gfc_get_symbol_decl): Emit a fatal error with appropriate message instead of ICE if symbol type is unknown. * trans-expr.cc (gfc_get_expr_charlen): Retain last charlen in 'previous' and use if end expression in substring reference is null. (gfc_conv_string_length): Use gfc_conv_expr_descriptor if 'expr_flat' is an array. (gfc_trans_alloc_subarray_assign): If this is a deferred string length component, store the string length in the hidden comp. Update the typespec length accordingly. Generate a new type spec for the call to gfc_duplicate-allocatable in this case. * trans-io.cc (gfc_trans_transfer): Scalarize transfer of deferred character array components. gcc/testsuite/ PR fortran/87477 * gfortran.dg/finalize_47.f90 : Enable substring test. * gfortran.dg/finalize_51.f90 : Update an error message. PR fortran/85686 PR fortran/88247 PR fortran/91941 PR fortran/92779 PR fortran/93339 PR fortran/93813 PR fortran/100948 PR fortran/102106 * gfortran.dg/associate_60.f90 : New test PR fortran/98408 * gfortran.dg/pr98408.f90 : New test PR fortran/105205 * gfortran.dg/pr105205.f90 : New test PR fortran/106918 * gfortran.dg/pr106918.f90 : New test
Re: [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Hi Paul, On 4/7/23 09:02, Paul Richard Thomas via Gcc-patches wrote: Hi All, Please find attached the patch to fix the dg directives and remove a lot of trailing white space. Unless there are any objections, I will commit as obvious over the weekend. this is OK. Thanks for the patch! Harald Cheers Paul Fortran: Fix dg directives and remove trailing whitespaces in testsuite 2023-04-07 Paul Thomas * gfortran.dg/c-interop/allocatable-optional-pointer.f90 : Fix dg directive and remove trailing whitespace. * gfortran.dg/c-interop/c407a-1.f90 : ditto * gfortran.dg/c-interop/c407b-1.f90 : ditto * gfortran.dg/c-interop/c407b-2.f90 : ditto * gfortran.dg/c-interop/c407c-1.f90 : ditto * gfortran.dg/c-interop/c535a-1.f90 : ditto * gfortran.dg/c-interop/c535a-2.f90 : ditto * gfortran.dg/c-interop/c535b-1.f90 : ditto * gfortran.dg/c-interop/c535b-2.f90 : ditto * gfortran.dg/c-interop/c535b-3.f90 : ditto * gfortran.dg/c-interop/c535c-1.f90 : ditto * gfortran.dg/c-interop/c535c-2.f90 : ditto * gfortran.dg/c-interop/deferred-character-1.f90 : ditto * gfortran.dg/c-interop/removed-restrictions-1.f90 : ditto * gfortran.dg/c-interop/removed-restrictions-2.f90 : ditto * gfortran.dg/c-interop/removed-restrictions-4.f90 : ditto * gfortran.dg/c-interop/tkr.f90 : ditto * gfortran.dg/class_result_10.f90 : ditto * gfortran.dg/dtio_35.f90 : ditto * gfortran.dg/goacc/array-with-dt-2.f90 : ditto * gfortran.dg/gomp/affinity-clause-1.f90 : ditto * gfortran.dg/pr103258.f90 : ditto * gfortran.dg/pr59107.f90 : ditto * gfortran.dg/pr93835.f08 : ditto On Wed, 29 Mar 2023 at 09:53, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: Hi Manfred, Indeed I do :-) Thanks for the spot. I have decided that it will be less messy if I roll all the testcases into one or, perhaps two => associate_xx.f90 Forgetting the space before the final brace seems to be rife! Cheers Paul On Wed, 29 Mar 2023 at 09:24, Manfred Schwarb wrote: Am 28.03.23 um 23:04 schrieb Paul Richard Thomas via Fortran: Hi All, I have made a start on ASSOCIATE issues. Some of the low(-ish) hanging fruit are already fixed but I have yet to check that they a really fixed and to close them: pr102106, pr102111, pr104430, pr106048, pr85510, pr87460, pr92960 & pr93338 The attached patch picks up those PRs involving deferred length characters in one guise or another. I believe that it is all pretty straightforward. Structure constructors with allocatable, deferred length, character array components just weren't implemented and so this is the biggest part of the patch. I found two other, non-associate PRs(106918 & 105205) that are fixed and there are probably more. The chunk in trans-io.cc is something of a kludge, which I will come back to. Some descriptors come through with a data pointer that looks as if it should be OK but I thought to submit this now to get it out of the way. The ratio of PRs fixed to the size of the patch warrants this. The next stage is going to be rather messy and so "I might take a little while" (cross talk between associate and select type, in particular). Regtests OK - good for mainline? Paul, you have some "dg-do-run" and "dg-do-compile" statements in your testcases, could you change them into their single-minus-sign variants? Cheers, Manfred BTW: I just ran my script again and found the following testsuite issues (note that outer-most braces need to be space-padded): ./c-interop/removed-restrictions-1.f90:! { dg-do compile} ./c-interop/removed-restrictions-2.f90:! { dg-do compile} ./c-interop/removed-restrictions-3.f90:! { dg-do compile} ./c-interop/removed-restrictions-4.f90:! { dg-do compile} ./c-interop/tkr.f90:! { dg-do compile} ./c-interop/c407c-1.f90:! { dg-do compile} ./c-interop/deferred-character-1.f90:! { dg-do compile} ./c-interop/allocatable-optional-pointer.f90:! { dg-do compile} ./c-interop/c407a-1.f90:! { dg-do compile} ./c-interop/c407b-1.f90:! { dg-do compile} ./c-interop/c407b-2.f90:! { dg-do compile} ./c-interop/c535a-1.f90:! { dg-do compile} ./c-interop/c535a-2.f90:! { dg-do compile} ./c-interop/c535b-1.f90:! { dg-do compile} ./c-interop/c535b-2.f90:! { dg-do compile} ./c-interop/c535b-3.f90:! { dg-do compile} ./c-interop/c535c-1.f90:! { dg-do compile} ./c-interop/c535c-2.f90:! { dg-do compile} ./gomp/affinity-clause-1.f90:! { dg final { scan-tree-dump-times "#pragma omp task affinity\\(iterator\\(integer\\(kind=4\\) i=D\\.\[0-9\]+:5:1\\):b\\\[\\(.* ? \\+ -1\\\]\\) affinity\\(iterator\\(integer\\(kind=4\\) i=D\\.\[0-9\]+:5:1\\):d\\\[\\(\\(integer\\(kind=8\\)\\) i \\+ -1\\) \\* 6\\\]\\)" 1 "original" } } ./class_result_10.f90:! { dg-do run} ./pr103258.f90:! { dg-do compile} ./dtio_35.f90:! { dg-compile } ./pr93835.f08:! {dg-do run } ./pr59107.f90:! { dg-compile } Cheers Paul Fortran: Fix some of the bugs in associate [PR87477] 2023-03-28 Paul Thomas gcc/fortran PR fortran/87477 * trans-array.cc (gfc_conv_expr_descriptor): Guard string len expression in condition.
Re: Ping! [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Dear All, Please find attached a slightly updated version of the patch with a consolidated testcase. The three additional testcases are nothing to do with associate and test fixes of character related bugs. OK for mainline? Cheers Paul Fortran: Fix some of the bugs in associate [PR87477] 2023-04-07 Paul Thomas gcc/fortran PR fortran/87477 * resolve.cc (resolve_assoc_var): Handle parentheses around the target expression. (resolve_block_construct): Remove unnecessary static decls. * trans-array.cc (gfc_conv_expr_descriptor): Guard string len expression in condition. Improve handling of string length and span, especially for substrings of the descriptor. (duplicate_allocatable): Make element type more explicit with 'eltype'. * trans_decl.cc (gfc_get_symbol_decl): Emit a fatal error with appropriate message instead of ICE if symbol type is unknown. * trans-expr.cc (gfc_get_expr_charlen): Retain last charlen in 'previous' and use if end expression in substring reference is null. (gfc_conv_string_length): Use gfc_conv_expr_descriptor if 'expr_flat' is an array. (gfc_trans_alloc_subarray_assign): If this is a deferred string length component, store the string length in the hidden comp. Update the typespec length accordingly. Generate a new type spec for the call to gfc_duplicate-allocatable in this case. * trans-io.cc (gfc_trans_transfer): Scalarize transfer of deferred character array components. gcc/testsuite/ PR fortran/87477 * gfortran.dg/finalize_47.f90 : Enable substring test. * gfortran.dg/finalize_51.f90 : Update an error message. PR fortran/85686 PR fortran/88247 PR fortran/91941 PR fortran/92779 PR fortran/93339 PR fortran/93813 PR fortran/100948 PR fortran/102106 * gfortran.dg/associate_60.f90 : New test PR fortran/98408 * gfortran.dg/pr98408.f90 : New test PR fortran/105205 * gfortran.dg/pr105205.f90 : New test PR fortran/106918 * gfortran.dg/pr106918.f90 : New test diff --git a/gcc/fortran/iresolve.cc b/gcc/fortran/iresolve.cc index 33794f0a858..8acad60a02b 100644 --- a/gcc/fortran/iresolve.cc +++ b/gcc/fortran/iresolve.cc @@ -230,7 +230,9 @@ gfc_resolve_adjustl (gfc_expr *f, gfc_expr *string) { f->ts.type = BT_CHARACTER; f->ts.kind = string->ts.kind; - if (string->ts.u.cl) + if (string->ts.deferred) +f->ts = string->ts; + else if (string->ts.u.cl) f->ts.u.cl = gfc_new_charlen (gfc_current_ns, string->ts.u.cl); f->value.function.name = gfc_get_string ("__adjustl_s%d", f->ts.kind); @@ -242,7 +244,9 @@ gfc_resolve_adjustr (gfc_expr *f, gfc_expr *string) { f->ts.type = BT_CHARACTER; f->ts.kind = string->ts.kind; - if (string->ts.u.cl) + if (string->ts.deferred) +f->ts = string->ts; + else if (string->ts.u.cl) f->ts.u.cl = gfc_new_charlen (gfc_current_ns, string->ts.u.cl); f->value.function.name = gfc_get_string ("__adjustr_s%d", f->ts.kind); @@ -3361,7 +3365,7 @@ gfc_resolve_mvbits (gfc_code *c) } -/* Set up the call to RANDOM_INIT. */ +/* Set up the call to RANDOM_INIT. */ void gfc_resolve_random_init (gfc_code *c) diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc index f6ec76acb0b..6e42397c2ea 100644 --- a/gcc/fortran/resolve.cc +++ b/gcc/fortran/resolve.cc @@ -9084,6 +9084,7 @@ static void resolve_assoc_var (gfc_symbol* sym, bool resolve_target) { gfc_expr* target; + bool parentheses = false; gcc_assert (sym->assoc); gcc_assert (sym->attr.flavor == FL_VARIABLE); @@ -9096,6 +9097,16 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target) return; gcc_assert (!sym->assoc->dangling); + if (target->expr_type == EXPR_OP + && target->value.op.op == INTRINSIC_PARENTHESES + && target->value.op.op1->expr_type == EXPR_VARIABLE) +{ + sym->assoc->target = gfc_copy_expr (target->value.op.op1); + gfc_free_expr (target); + target = sym->assoc->target; + parentheses = true; +} + if (resolve_target && !gfc_resolve_expr (target)) return; @@ -9177,6 +9188,7 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target) /* See if this is a valid association-to-variable. */ sym->assoc->variable = (target->expr_type == EXPR_VARIABLE + && !parentheses && !gfc_has_vector_subscript (target)); /* Finally resolve if this is an array or not. */ @@ -9191,7 +9203,6 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target) return; } - /* We cannot deal with class selectors that need temporaries. */ if (target->ts.type == BT_CLASS && gfc_ref_needs_temporary_p (target->ref)) @@ -10885,11 +10896,6 @@ gfc_resolve_forall (gfc_code *code, gfc_namespace *ns, int forall_save) /* Resolve a BLOCK construct statement. */ -static gfc_expr* -get_temp_from_expr (gfc_expr *, gfc_namespace *); -static gfc_code * -build_assignment (gfc_exec_op, gfc_expr *, gfc_expr *, - gfc_component *, gfc_component *, locus); static void resolve_block_construct (gfc_code* code) diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc index 41661b4
Re: [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Hi All, Please find attached the patch to fix the dg directives and remove a lot of trailing white space. Unless there are any objections, I will commit as obvious over the weekend. Cheers Paul Fortran: Fix dg directives and remove trailing whitespaces in testsuite 2023-04-07 Paul Thomas * gfortran.dg/c-interop/allocatable-optional-pointer.f90 : Fix dg directive and remove trailing whitespace. * gfortran.dg/c-interop/c407a-1.f90 : ditto * gfortran.dg/c-interop/c407b-1.f90 : ditto * gfortran.dg/c-interop/c407b-2.f90 : ditto * gfortran.dg/c-interop/c407c-1.f90 : ditto * gfortran.dg/c-interop/c535a-1.f90 : ditto * gfortran.dg/c-interop/c535a-2.f90 : ditto * gfortran.dg/c-interop/c535b-1.f90 : ditto * gfortran.dg/c-interop/c535b-2.f90 : ditto * gfortran.dg/c-interop/c535b-3.f90 : ditto * gfortran.dg/c-interop/c535c-1.f90 : ditto * gfortran.dg/c-interop/c535c-2.f90 : ditto * gfortran.dg/c-interop/deferred-character-1.f90 : ditto * gfortran.dg/c-interop/removed-restrictions-1.f90 : ditto * gfortran.dg/c-interop/removed-restrictions-2.f90 : ditto * gfortran.dg/c-interop/removed-restrictions-4.f90 : ditto * gfortran.dg/c-interop/tkr.f90 : ditto * gfortran.dg/class_result_10.f90 : ditto * gfortran.dg/dtio_35.f90 : ditto * gfortran.dg/goacc/array-with-dt-2.f90 : ditto * gfortran.dg/gomp/affinity-clause-1.f90 : ditto * gfortran.dg/pr103258.f90 : ditto * gfortran.dg/pr59107.f90 : ditto * gfortran.dg/pr93835.f08 : ditto On Wed, 29 Mar 2023 at 09:53, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi Manfred, > > Indeed I do :-) Thanks for the spot. I have decided that it will be less > messy if I roll all the testcases into one or, perhaps two => > associate_xx.f90 > > Forgetting the space before the final brace seems to be rife! > > Cheers > > Paul > > > On Wed, 29 Mar 2023 at 09:24, Manfred Schwarb wrote: > >> Am 28.03.23 um 23:04 schrieb Paul Richard Thomas via Fortran: >> > Hi All, >> > >> > I have made a start on ASSOCIATE issues. Some of the low(-ish) hanging >> > fruit are already fixed but I have yet to check that they a really fixed >> > and to close them: >> > pr102106, pr102111, pr104430, pr106048, pr85510, pr87460, pr92960 & >> pr93338 >> > >> > The attached patch picks up those PRs involving deferred length >> characters >> > in one guise or another. I believe that it is all pretty >> straightforward. >> > Structure constructors with allocatable, deferred length, character >> array >> > components just weren't implemented and so this is the biggest part of >> the >> > patch. I found two other, non-associate PRs(106918 & 105205) that are >> > fixed and there are probably more. >> > >> > The chunk in trans-io.cc is something of a kludge, which I will come >> back >> > to. Some descriptors come through with a data pointer that looks as if >> it >> > should be OK but >> > >> > I thought to submit this now to get it out of the way. The ratio of PRs >> > fixed to the size of the patch warrants this. The next stage is going >> to be >> > rather messy and so "I might take a little while" (cross talk between >> > associate and select type, in particular). >> > >> > Regtests OK - good for mainline? >> > >> >> Paul, you have some "dg-do-run" and "dg-do-compile" statements in your >> testcases, >> could you change them into their single-minus-sign variants? >> >> Cheers, >> Manfred >> >> >> BTW: I just ran my script again and found the following testsuite issues >> (note that outer-most >> braces need to be space-padded): >> >> ./c-interop/removed-restrictions-1.f90:! { dg-do compile} >> ./c-interop/removed-restrictions-2.f90:! { dg-do compile} >> ./c-interop/removed-restrictions-3.f90:! { dg-do compile} >> ./c-interop/removed-restrictions-4.f90:! { dg-do compile} >> ./c-interop/tkr.f90:! { dg-do compile} >> ./c-interop/c407c-1.f90:! { dg-do compile} >> ./c-interop/deferred-character-1.f90:! { dg-do compile} >> ./c-interop/allocatable-optional-pointer.f90:! { dg-do compile} >> ./c-interop/c407a-1.f90:! { dg-do compile} >> ./c-interop/c407b-1.f90:! { dg-do compile} >> ./c-interop/c407b-2.f90:! { dg-do compile} >> ./c-interop/c535a-1.f90:! { dg-do compile} >> ./c-interop/c535a-2.f90:! { dg-do compile} >> ./c-interop/c535b-1.f90:! { dg-do compile} >> ./c-interop/c535b-2.f90:! { dg-do compile} >> ./c-interop/c535b-3.f90:! { dg-do compile} >> ./c-interop/c535c-1.f90:! { dg-do compile} >> ./c-interop/c535c-2.f90:! { dg-do compile} >> ./gomp/affinity-clause-1.f90:! { dg final { scan-tree-dump-times "#pragma >> omp task affinity\\(iterator\\(integer\\(kind=4\\) >> i=D\\.\[0-9\]+:5:1\\):b\\\[\\(.* ? \\+ -1\\\]\\) >> affinity\\(iterator\\(integer\\(kind=4\\) >> i=D\\.\[0-9\]+:5:1\\):d\\\[\\(\\(integer\\(kind=8\\)\\) i \\+ -1\\) \\* >> 6\\\]\\)" 1 "original" } } >> ./class_result_10.f90:! { dg-do run} >> ./pr103258.f90:! { dg-do compile} >> ./dtio_35.f90:! { dg-compile } >> ./pr93835.f08:! {dg-do run } >> ./pr59107.f90:! { dg-compile } >> >> >> >> > Cheers >> > >> > Paul >> > >> > Fortran: Fix some
Re: [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Hi Manfred, Indeed I do :-) Thanks for the spot. I have decided that it will be less messy if I roll all the testcases into one or, perhaps two => associate_xx.f90 Forgetting the space before the final brace seems to be rife! Cheers Paul On Wed, 29 Mar 2023 at 09:24, Manfred Schwarb wrote: > Am 28.03.23 um 23:04 schrieb Paul Richard Thomas via Fortran: > > Hi All, > > > > I have made a start on ASSOCIATE issues. Some of the low(-ish) hanging > > fruit are already fixed but I have yet to check that they a really fixed > > and to close them: > > pr102106, pr102111, pr104430, pr106048, pr85510, pr87460, pr92960 & > pr93338 > > > > The attached patch picks up those PRs involving deferred length > characters > > in one guise or another. I believe that it is all pretty straightforward. > > Structure constructors with allocatable, deferred length, character array > > components just weren't implemented and so this is the biggest part of > the > > patch. I found two other, non-associate PRs(106918 & 105205) that are > > fixed and there are probably more. > > > > The chunk in trans-io.cc is something of a kludge, which I will come back > > to. Some descriptors come through with a data pointer that looks as if it > > should be OK but > > > > I thought to submit this now to get it out of the way. The ratio of PRs > > fixed to the size of the patch warrants this. The next stage is going to > be > > rather messy and so "I might take a little while" (cross talk between > > associate and select type, in particular). > > > > Regtests OK - good for mainline? > > > > Paul, you have some "dg-do-run" and "dg-do-compile" statements in your > testcases, > could you change them into their single-minus-sign variants? > > Cheers, > Manfred > > > BTW: I just ran my script again and found the following testsuite issues > (note that outer-most > braces need to be space-padded): > > ./c-interop/removed-restrictions-1.f90:! { dg-do compile} > ./c-interop/removed-restrictions-2.f90:! { dg-do compile} > ./c-interop/removed-restrictions-3.f90:! { dg-do compile} > ./c-interop/removed-restrictions-4.f90:! { dg-do compile} > ./c-interop/tkr.f90:! { dg-do compile} > ./c-interop/c407c-1.f90:! { dg-do compile} > ./c-interop/deferred-character-1.f90:! { dg-do compile} > ./c-interop/allocatable-optional-pointer.f90:! { dg-do compile} > ./c-interop/c407a-1.f90:! { dg-do compile} > ./c-interop/c407b-1.f90:! { dg-do compile} > ./c-interop/c407b-2.f90:! { dg-do compile} > ./c-interop/c535a-1.f90:! { dg-do compile} > ./c-interop/c535a-2.f90:! { dg-do compile} > ./c-interop/c535b-1.f90:! { dg-do compile} > ./c-interop/c535b-2.f90:! { dg-do compile} > ./c-interop/c535b-3.f90:! { dg-do compile} > ./c-interop/c535c-1.f90:! { dg-do compile} > ./c-interop/c535c-2.f90:! { dg-do compile} > ./gomp/affinity-clause-1.f90:! { dg final { scan-tree-dump-times "#pragma > omp task affinity\\(iterator\\(integer\\(kind=4\\) > i=D\\.\[0-9\]+:5:1\\):b\\\[\\(.* ? \\+ -1\\\]\\) > affinity\\(iterator\\(integer\\(kind=4\\) > i=D\\.\[0-9\]+:5:1\\):d\\\[\\(\\(integer\\(kind=8\\)\\) i \\+ -1\\) \\* > 6\\\]\\)" 1 "original" } } > ./class_result_10.f90:! { dg-do run} > ./pr103258.f90:! { dg-do compile} > ./dtio_35.f90:! { dg-compile } > ./pr93835.f08:! {dg-do run } > ./pr59107.f90:! { dg-compile } > > > > > Cheers > > > > Paul > > > > Fortran: Fix some of the bugs in associate [PR87477] > > > > 2023-03-28 Paul Thomas > > > > gcc/fortran > > PR fortran/87477 > > * trans-array.cc (gfc_conv_expr_descriptor): Guard string len > > expression in condition. > > (duplicate_allocatable): Make element type more explicit with > > 'eltype'. > > * trans-expr.cc (gfc_get_expr_charlen): Retain last charlen in > > 'previous' and use if end expression in substring reference is > > null. > > (gfc_conv_string_length): Use gfc_conv_expr_descriptor if > > 'expr_flat' is an array. > > (gfc_trans_alloc_subarray_assign): If this is a deferred string > > length component, store the string length in the hidden comp. > > Update the typespec length accordingly. Generate a new type > > spec for the call to gfc_duplicate-allocatable in this case. > > * trans-io.cc (gfc_trans_transfer): Scalarize transfer of > > deferred character array components. > > > > > > gcc/testsuite/ > > PR fortran/92994 > > * gfortran.dg/finalize_51.f90 : Update an error message. > > > > PR fortran/85686 > > * gfortran.dg/pr85686.f90 : New test > > > > PR fortran/88247 > > * gfortran.dg/pr88247.f90 : New test > > > > PR fortran/91941 > > * gfortran.dg/pr91941.f90 : New test > > > > PR fortran/92779 > > * gfortran.dg/pr92779.f90 : New test > > > > PR fortran/93339 > > * gfortran.dg/pr93339.f90 : New test > > > > PR fortran/93813 > > * gfortran.dg/pr93813.f90 : New test > > > > PR fortran/100948 > > * gfortran.dg/pr100948.f90 : New test > > > > PR fortran/102106 > > * gfortran.dg/pr102106.f90 : New test > > > > PR fortran/105205 > > * gfortran.dg/pr105205.f90 : New test > > > > PR fortran/106918 > > * gfortran.dg/pr106918.f
Re: [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Am 28.03.23 um 23:04 schrieb Paul Richard Thomas via Fortran: > Hi All, > > I have made a start on ASSOCIATE issues. Some of the low(-ish) hanging > fruit are already fixed but I have yet to check that they a really fixed > and to close them: > pr102106, pr102111, pr104430, pr106048, pr85510, pr87460, pr92960 & pr93338 > > The attached patch picks up those PRs involving deferred length characters > in one guise or another. I believe that it is all pretty straightforward. > Structure constructors with allocatable, deferred length, character array > components just weren't implemented and so this is the biggest part of the > patch. I found two other, non-associate PRs(106918 & 105205) that are > fixed and there are probably more. > > The chunk in trans-io.cc is something of a kludge, which I will come back > to. Some descriptors come through with a data pointer that looks as if it > should be OK but > > I thought to submit this now to get it out of the way. The ratio of PRs > fixed to the size of the patch warrants this. The next stage is going to be > rather messy and so "I might take a little while" (cross talk between > associate and select type, in particular). > > Regtests OK - good for mainline? > Paul, you have some "dg-do-run" and "dg-do-compile" statements in your testcases, could you change them into their single-minus-sign variants? Cheers, Manfred BTW: I just ran my script again and found the following testsuite issues (note that outer-most braces need to be space-padded): ./c-interop/removed-restrictions-1.f90:! { dg-do compile} ./c-interop/removed-restrictions-2.f90:! { dg-do compile} ./c-interop/removed-restrictions-3.f90:! { dg-do compile} ./c-interop/removed-restrictions-4.f90:! { dg-do compile} ./c-interop/tkr.f90:! { dg-do compile} ./c-interop/c407c-1.f90:! { dg-do compile} ./c-interop/deferred-character-1.f90:! { dg-do compile} ./c-interop/allocatable-optional-pointer.f90:! { dg-do compile} ./c-interop/c407a-1.f90:! { dg-do compile} ./c-interop/c407b-1.f90:! { dg-do compile} ./c-interop/c407b-2.f90:! { dg-do compile} ./c-interop/c535a-1.f90:! { dg-do compile} ./c-interop/c535a-2.f90:! { dg-do compile} ./c-interop/c535b-1.f90:! { dg-do compile} ./c-interop/c535b-2.f90:! { dg-do compile} ./c-interop/c535b-3.f90:! { dg-do compile} ./c-interop/c535c-1.f90:! { dg-do compile} ./c-interop/c535c-2.f90:! { dg-do compile} ./gomp/affinity-clause-1.f90:! { dg final { scan-tree-dump-times "#pragma omp task affinity\\(iterator\\(integer\\(kind=4\\) i=D\\.\[0-9\]+:5:1\\):b\\\[\\(.* ? \\+ -1\\\]\\) affinity\\(iterator\\(integer\\(kind=4\\) i=D\\.\[0-9\]+:5:1\\):d\\\[\\(\\(integer\\(kind=8\\)\\) i \\+ -1\\) \\* 6\\\]\\)" 1 "original" } } ./class_result_10.f90:! { dg-do run} ./pr103258.f90:! { dg-do compile} ./dtio_35.f90:! { dg-compile } ./pr93835.f08:! {dg-do run } ./pr59107.f90:! { dg-compile } > Cheers > > Paul > > Fortran: Fix some of the bugs in associate [PR87477] > > 2023-03-28 Paul Thomas > > gcc/fortran > PR fortran/87477 > * trans-array.cc (gfc_conv_expr_descriptor): Guard string len > expression in condition. > (duplicate_allocatable): Make element type more explicit with > 'eltype'. > * trans-expr.cc (gfc_get_expr_charlen): Retain last charlen in > 'previous' and use if end expression in substring reference is > null. > (gfc_conv_string_length): Use gfc_conv_expr_descriptor if > 'expr_flat' is an array. > (gfc_trans_alloc_subarray_assign): If this is a deferred string > length component, store the string length in the hidden comp. > Update the typespec length accordingly. Generate a new type > spec for the call to gfc_duplicate-allocatable in this case. > * trans-io.cc (gfc_trans_transfer): Scalarize transfer of > deferred character array components. > > > gcc/testsuite/ > PR fortran/92994 > * gfortran.dg/finalize_51.f90 : Update an error message. > > PR fortran/85686 > * gfortran.dg/pr85686.f90 : New test > > PR fortran/88247 > * gfortran.dg/pr88247.f90 : New test > > PR fortran/91941 > * gfortran.dg/pr91941.f90 : New test > > PR fortran/92779 > * gfortran.dg/pr92779.f90 : New test > > PR fortran/93339 > * gfortran.dg/pr93339.f90 : New test > > PR fortran/93813 > * gfortran.dg/pr93813.f90 : New test > > PR fortran/100948 > * gfortran.dg/pr100948.f90 : New test > > PR fortran/102106 > * gfortran.dg/pr102106.f90 : New test > > PR fortran/105205 > * gfortran.dg/pr105205.f90 : New test > > PR fortran/106918 > * gfortran.dg/pr106918.f90 : New test
[Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Hi All, I have made a start on ASSOCIATE issues. Some of the low(-ish) hanging fruit are already fixed but I have yet to check that they a really fixed and to close them: pr102106, pr102111, pr104430, pr106048, pr85510, pr87460, pr92960 & pr93338 The attached patch picks up those PRs involving deferred length characters in one guise or another. I believe that it is all pretty straightforward. Structure constructors with allocatable, deferred length, character array components just weren't implemented and so this is the biggest part of the patch. I found two other, non-associate PRs(106918 & 105205) that are fixed and there are probably more. The chunk in trans-io.cc is something of a kludge, which I will come back to. Some descriptors come through with a data pointer that looks as if it should be OK but I thought to submit this now to get it out of the way. The ratio of PRs fixed to the size of the patch warrants this. The next stage is going to be rather messy and so "I might take a little while" (cross talk between associate and select type, in particular). Regtests OK - good for mainline? Cheers Paul Fortran: Fix some of the bugs in associate [PR87477] 2023-03-28 Paul Thomas gcc/fortran PR fortran/87477 * trans-array.cc (gfc_conv_expr_descriptor): Guard string len expression in condition. (duplicate_allocatable): Make element type more explicit with 'eltype'. * trans-expr.cc (gfc_get_expr_charlen): Retain last charlen in 'previous' and use if end expression in substring reference is null. (gfc_conv_string_length): Use gfc_conv_expr_descriptor if 'expr_flat' is an array. (gfc_trans_alloc_subarray_assign): If this is a deferred string length component, store the string length in the hidden comp. Update the typespec length accordingly. Generate a new type spec for the call to gfc_duplicate-allocatable in this case. * trans-io.cc (gfc_trans_transfer): Scalarize transfer of deferred character array components. gcc/testsuite/ PR fortran/92994 * gfortran.dg/finalize_51.f90 : Update an error message. PR fortran/85686 * gfortran.dg/pr85686.f90 : New test PR fortran/88247 * gfortran.dg/pr88247.f90 : New test PR fortran/91941 * gfortran.dg/pr91941.f90 : New test PR fortran/92779 * gfortran.dg/pr92779.f90 : New test PR fortran/93339 * gfortran.dg/pr93339.f90 : New test PR fortran/93813 * gfortran.dg/pr93813.f90 : New test PR fortran/100948 * gfortran.dg/pr100948.f90 : New test PR fortran/102106 * gfortran.dg/pr102106.f90 : New test PR fortran/105205 * gfortran.dg/pr105205.f90 : New test PR fortran/106918 * gfortran.dg/pr106918.f90 : New test diff --git a/gcc/fortran/iresolve.cc b/gcc/fortran/iresolve.cc index 33794f0a858..8acad60a02b 100644 --- a/gcc/fortran/iresolve.cc +++ b/gcc/fortran/iresolve.cc @@ -230,7 +230,9 @@ gfc_resolve_adjustl (gfc_expr *f, gfc_expr *string) { f->ts.type = BT_CHARACTER; f->ts.kind = string->ts.kind; - if (string->ts.u.cl) + if (string->ts.deferred) +f->ts = string->ts; + else if (string->ts.u.cl) f->ts.u.cl = gfc_new_charlen (gfc_current_ns, string->ts.u.cl); f->value.function.name = gfc_get_string ("__adjustl_s%d", f->ts.kind); @@ -242,7 +244,9 @@ gfc_resolve_adjustr (gfc_expr *f, gfc_expr *string) { f->ts.type = BT_CHARACTER; f->ts.kind = string->ts.kind; - if (string->ts.u.cl) + if (string->ts.deferred) +f->ts = string->ts; + else if (string->ts.u.cl) f->ts.u.cl = gfc_new_charlen (gfc_current_ns, string->ts.u.cl); f->value.function.name = gfc_get_string ("__adjustr_s%d", f->ts.kind); @@ -3361,7 +3365,7 @@ gfc_resolve_mvbits (gfc_code *c) } -/* Set up the call to RANDOM_INIT. */ +/* Set up the call to RANDOM_INIT. */ void gfc_resolve_random_init (gfc_code *c) diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc index 1a03e458d99..23a04d2c5bd 100644 --- a/gcc/fortran/resolve.cc +++ b/gcc/fortran/resolve.cc @@ -9084,6 +9084,7 @@ static void resolve_assoc_var (gfc_symbol* sym, bool resolve_target) { gfc_expr* target; + bool parentheses = false; gcc_assert (sym->assoc); gcc_assert (sym->attr.flavor == FL_VARIABLE); @@ -9096,6 +9097,16 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target) return; gcc_assert (!sym->assoc->dangling); + if (target->expr_type == EXPR_OP + && target->value.op.op == INTRINSIC_PARENTHESES + && target->value.op.op1->expr_type == EXPR_VARIABLE) +{ + sym->assoc->target = gfc_copy_expr (target->value.op.op1); + gfc_free_expr (target); + target = sym->assoc->target; + parentheses = true; +} + if (resolve_target && !gfc_resolve_expr (target)) return; @@ -9177,6 +9188,7 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target) /* See if this is a valid association-to-variable. */ sym->assoc->variable = (target->expr_type == EXPR_VARIABLE + && !parentheses && !gfc_has_vector_subscript (target)); /* Finally resolve if this is an array or not. */ @@ -10885,11 +10897,6 @@ gfc_r