[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, >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 = >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, );
+ 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_DEFERRED;
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 (, expr_flat);
- gfc_add_block_to_block (pblock, );
- cl->backend_decl = convert (gfc_charlen_type_node, se.string_length);
-
+ if (expr_flat->rank)
+ gfc_conv_expr_descriptor (, expr_flat);
+ else
+ gfc_conv_expr (, expr_flat);
+ if (expr_flat->expr_type != EXPR_VARIABLE)
+ gfc_add_block_to_block (pblock, );
+ se.expr = convert (gfc_charlen_type_node, se.string_length);
+ gfc_add_block_to_block (pblock, );
// <<>>
gfc_free_expr (expr_flat);
- return;
}
-
- /* Convert cl->length. */
-
- gcc_assert (cl->length);
-
- gfc_conv_expr_type (, 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, );
+ else
+{
+ /* Convert cl->length. */
+ gfc_conv_expr_type (, 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, );
+}
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 fortran/106918
* gfortran.dg/pr106918.f90 : New
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 (, expr_flat);
> - gfc_add_block_to_block (pblock, );
> - cl->backend_decl = convert (gfc_charlen_type_node,
> se.string_length);
> -
> + if (expr_flat->rank)
> + gfc_conv_expr_descriptor (, expr_flat);
> + else
> + gfc_conv_expr (, expr_flat);
> + if (expr_flat->expr_type != EXPR_VARIABLE)
> + gfc_add_block_to_block (pblock, );
> + se.expr = convert (gfc_charlen_type_node, se.string_length);
> + gfc_add_block_to_block (pblock, );
> // <<>>
>gfc_free_expr (expr_flat);
> - return;
> }
> -
> - /* Convert cl->length. */
> -
> - gcc_assert (cl->length);
> -
> - gfc_conv_expr_type (, 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, );
> + else
> +{
> + /* Convert cl->length. */
> + gfc_conv_expr_type (, 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, );
> +}
>
>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
>>
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 (, expr_flat);
- gfc_add_block_to_block (pblock, );
- cl->backend_decl = convert (gfc_charlen_type_node, se.string_length);
-
+ if (expr_flat->rank)
+ gfc_conv_expr_descriptor (, expr_flat);
+ else
+ gfc_conv_expr (, expr_flat);
+ if (expr_flat->expr_type != EXPR_VARIABLE)
+ gfc_add_block_to_block (pblock, );
+ se.expr = convert (gfc_charlen_type_node, se.string_length);
+ gfc_add_block_to_block (pblock, );
// <<>>
gfc_free_expr (expr_flat);
- return;
}
-
- /* Convert cl->length. */
-
- gcc_assert (cl->length);
-
- gfc_conv_expr_type (, 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, );
+ else
+{
+ /* Convert cl->length. */
+ gfc_conv_expr_type (, 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, );
+}
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
>
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 =>
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
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
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
> > *
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 @@
