Re: [PATCH] fortran: Remove reference count update [PR108957]
Hi Mikael, The comment is very welcome! Looks good to me. OK for mainline. Thanks for the patch. Paul On Fri, 15 Sept 2023 at 08:19, Mikael Morin via Fortran wrote: > > Hello, > > Harald reminded me recently that there was a working patch attached to the PR. > I added a documentation comment with the hope that it may help avoid > making the same mistake in the future. > Regression tested on x86_64-pc-linux-gnu. > OK for master? > > -- >8 -- > > Remove one reference count incrementation following the assignment of a > symbol pointer to a local variable. Most symbol pointers are "weak" pointer > and don't need any reference count update when they are assigned, and it is > especially the case of local variables. > > This fixes a memory leak with the testcase from the PR (not included). > > PR fortran/108957 > > gcc/fortran/ChangeLog: > > * gfortran.h (gfc_symbol): Add comment documenting reference counting. > * parse.cc (parse_interface): Remove reference count incrementation. > --- > gcc/fortran/gfortran.h | 20 > gcc/fortran/parse.cc | 3 --- > 2 files changed, 20 insertions(+), 3 deletions(-) > > diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h > index f4a1c106cea..6caf7765ac6 100644 > --- a/gcc/fortran/gfortran.h > +++ b/gcc/fortran/gfortran.h > @@ -1944,7 +1944,27 @@ typedef struct gfc_symbol > according to the Fortran standard. */ >unsigned pass_as_value:1; > > + /* Reference counter, used for memory management. > + > + Some symbols may be present in more than one namespace, for example > + function and subroutine symbols are present both in the outer namespace > and > + the procedure body namespace. Freeing symbols with the namespaces they > are > + in would result in double free for those symbols. This field counts > + references and is used to delay the memory release until the last > reference > + to the symbol is removed. > + > + Not every symbol pointer is accounted for reference counting. Fields > + gfc_symtree::n::sym are, and gfc_finalizer::proc_sym as well. But most > of > + them (dummy arguments, generic list elements, etc) are "weak" pointers; > + the reference count isn't updated when they are assigned, and they are > + ignored when the surrounding structure memory is released. This is not > a > + problem because there is always a namespace as surrounding context and > + symbols have a name they can be referred with in that context, so the > + namespace keeps the symbol from being freed, keeping the pointer valid. > + When the namespace ceases to exist, and the symbols with it, the other > + structures referencing symbols cease to exist as well. */ >int refs; > + >struct gfc_namespace *ns;/* namespace containing this symbol */ > >tree backend_decl; > diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc > index 8f09ddf753c..58386805ffe 100644 > --- a/gcc/fortran/parse.cc > +++ b/gcc/fortran/parse.cc > @@ -4064,9 +4064,6 @@ loop: >accept_statement (st); >prog_unit = gfc_new_block; >prog_unit->formal_ns = gfc_current_ns; > - if (prog_unit == prog_unit->formal_ns->proc_name > - && prog_unit->ns != prog_unit->formal_ns) > -prog_unit->refs++; > > decl: >/* Read data declaration statements. */ > -- > 2.40.1 >
Re: [PATCH] Fortran: improve bounds-checking for array sections [PR30802]
Hi Harald, The statement, in array_bound_check_elemental is redundant since the call is determined by a more restrictive condition. + if (!(gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)) +return; Apart from that, it looks good to me. OK for mainline. Thanks for the patch. Paul On Thu, 14 Sept 2023 at 21:22, Harald Anlauf via Fortran wrote: > > Dear all, > > array bounds checking was missing a few cases of array sections > that are handled via gfc_conv_expr_descriptor. Bounds checking > was done for the dimensions with ranges, but not for elemental > dimensions. > > The attached patch implements that and fixes pr30802 and also > pr97039, maybe a few more similar cases. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > Thanks, > Harald >
[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
[Patch, fortran] PR92586 - ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types
Committed as 'obvious'. 13-branch to follow. commit r14-3501-g44bcb51eb0d5cac6eb2de54541ca8e6c2d738160 Author: Paul Thomas Date: Sat Aug 26 14:37:49 2023 +0100 Fortran: Supply a missing dereference [PR92586] 2023-08-26 Paul Thomas gcc/fortran PR fortran/92586 * trans-expr.cc (gfc_trans_arrayfunc_assign): Supply a missing dereference for the call to gfc_deallocate_alloc_comp_no_caf. gcc/testsuite/ PR fortran/92586 * gfortran.dg/pr92586.f90 : New test Paul
Re: [PATCH] Fortran: implement vector sections in DATA statements [PR49588]
Hi Harald, It all looks good to me and does indeed make the code clearer. OK for trunk. Thanks for the patch. I was shocked to find that there are 217 older bugs than 49588. Does anybody test older bugs to check if any of them have been fixed? Paul On Mon, 21 Aug 2023 at 20:48, Harald Anlauf via Fortran wrote: > > Dear all, > > the attached patch implements vector sections in DATA statements. > > The implementation is simpler than the size of the patch suggests, > as part of changes try to clean up the existing code to make it > easier to understand, as ordinary sections (start:end:stride) > and vector sections may actually share some common code. > > The basisc idea of the implementation is that one needs a > temporary vector that keeps track of the offsets into the > array constructors for the indices in the array reference > that are vectors. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > Thanks, > Harald >
Re: [Patch, fortran] PR109684 - compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
I took a look at my calendar and decided to backport right away. r13-7703-ged049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7 BTW It is a regression :-) Paul On Wed, 9 Aug 2023 at 12:10, Paul Richard Thomas wrote: > > Committed to trunk as 'obvious' in > r14-3098-gb8ec3c952324f866f191883473922e250be81341 > > 13-branch to follow in a few days. > > Paul
[Patch, fortran] PR109684 - compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
Committed to trunk as 'obvious' in r14-3098-gb8ec3c952324f866f191883473922e250be81341 13-branch to follow in a few days. Paul
Re: [PATCH] fortran: Release symbols in reversed order [PR106050]
Hi Mikhail,
That's more than OK by me.
Thanks for attacking this PR.
I have a couple more of Steve's orphans waiting to be packaged up -
91960 and 104649. I'll submit them this evening.100607 is closed-fixed
and 103796 seems to be fixed.
Regards
Paul
On Tue, 11 Jul 2023 at 13:08, Mikael Morin via Fortran
wrote:
>
> Hello,
>
> I saw the light regarding this PR after Paul posted a comment yesterday.
>
> Regression test in progress on x86_64-pc-linux-gnu.
> I plan to push in the next hours.
>
> Mikael
>
> -- >8 --
>
> Release symbols in reversed order wrt the order they were allocated.
> This fixes an error recovery ICE in the case of a misplaced
> derived type declaration. Such a declaration creates nested
> symbols, one for the derived type and one for each type parameter,
> which should be immediately released as the declaration is
> rejected. This breaks if the derived type is released first.
> As the type parameter symbols are in the namespace of the derived
> type, releasing the derived type releases the type parameters, so
> one can't access them after that, even to release them. Hence,
> the type parameters should be released first.
>
> PR fortran/106050
>
> gcc/fortran/ChangeLog:
>
> * symbol.cc (gfc_restore_last_undo_checkpoint): Release symbols
> in reverse order.
>
> gcc/testsuite/ChangeLog:
>
> * gfortran.dg/pdt_33.f90: New test.
> ---
> gcc/fortran/symbol.cc| 2 +-
> gcc/testsuite/gfortran.dg/pdt_33.f90 | 15 +++
> 2 files changed, 16 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gfortran.dg/pdt_33.f90
>
> diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
> index 37a9e8fa0ae..4a71d84b3fe 100644
> --- a/gcc/fortran/symbol.cc
> +++ b/gcc/fortran/symbol.cc
> @@ -3661,7 +3661,7 @@ gfc_restore_last_undo_checkpoint (void)
>gfc_symbol *p;
>unsigned i;
>
> - FOR_EACH_VEC_ELT (latest_undo_chgset->syms, i, p)
> + FOR_EACH_VEC_ELT_REVERSE (latest_undo_chgset->syms, i, p)
> {
>/* Symbol in a common block was new. Or was old and just put in common
> */
>if (p->common_block
> diff --git a/gcc/testsuite/gfortran.dg/pdt_33.f90
> b/gcc/testsuite/gfortran.dg/pdt_33.f90
> new file mode 100644
> index 000..0521513f2f8
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/pdt_33.f90
> @@ -0,0 +1,15 @@
> +! { dg-do compile }
> +!
> +! PR fortran/106050
> +! The following used to trigger an error recovery ICE by releasing
> +! the symbol T before the symbol K which was leading to releasing
> +! K twice as it's in T's namespace.
> +!
> +! Contributed by G. Steinmetz
> +
> +program p
> + a = 1
> + type t(k) ! { dg-error "Unexpected derived type
> declaration" }
> + integer, kind :: k = 4 ! { dg-error "not allowed outside a TYPE
> definition" }
> + end type ! { dg-error "Expecting END PROGRAM" }
> +end
> --
> 2.40.1
>
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
[Patch, fortran] Fix default type bugs in gfortran [PR99139, PR99368]
The attached patch incorporates two of Steve's "Orphaned Patches" -
https://gcc.gnu.org/pipermail/fortran/2023-June/059423.html
They have in common that they both involve faults in use of default
type and that I was the ultimate cause of the bugs.
The patch regtests with the attached testcases.
I will commit in the next 24 hours unless there are any objections.
Paul
Fortran: Fix default type bugs in gfortran [PR99139, PR99368]
2023-07-08 Steve Kargl
gcc/fortran
PR fortran/99139
PR fortran/99368
* match.cc (gfc_match_namelist): Check for host associated or
defined types before applying default type.
(gfc_match_select_rank): Apply default type to selector of
unlnown type if possible.
* resolve.cc (resolve_fl_variable): Do not apply local default
initialization to assumed rank entities.
gcc/testsuite/
PR fortran/999139
* gfortran.dg/pr99139.f90 : New test
PR fortran/99368
* gfortran.dg/pr99368.f90 : New test
Fortran: Fix default type bugs in gfortran [PR99139, PR99368]
2023-07-08 Steve Kargl
gcc/fortran
PR fortran/99139
PR fortran/99368
* match.cc (gfc_match_namelist): Check for host associated or
defined types before applying default type.
(gfc_match_select_rank): Apply default type to selector of
unlnown type if possible.
* resolve.cc (resolve_fl_variable): Do not apply local default
initialization to assumed rank entities.
gcc/testsuite/
PR fortran/999139
* gfortran.dg/pr99139.f90 : New test
PR fortran/99368
* gfortran.dg/pr99368.f90 : New test
! { dg-do compile }
! { dg-options "-finit-local-zero" }
!
! Contributed by Gerhard Steinmetz
!
! Original implicitly typed 'x' gave a bad symbol ICE
subroutine s1(x)
target :: x(..)
select rank (y => x)
rank (1)
rank (2)
end select
end
! Comment #2: Failed with above option
subroutine s2(x, z)
real, target :: x(..)
real :: z(10)
select rank (y => x) ! Error was:Assumed-rank variable y at (1) may only be
! used as actual argument
rank (1)
rank (2)
end select
end
! { dg-do compile }
!
! Contributed by Gerhard Steinmetz
!
program p
type y ! { dg-error "Derived type" }
end type
contains
subroutine s1
namelist /x/ y ! { dg-error "conflicts with namelist object" }
character(3) y
end
subroutine s2
namelist /z/ y ! { dg-error "conflicts with namelist object" }
character(3) y
end
enddiff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index ca64e59029e..a778bae0b9f 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -5622,10 +5622,32 @@ gfc_match_namelist (void)
gfc_error_check ();
}
else
- /* If the type is not set already, we set it here to the
- implicit default type. It is not allowed to set it
- later to any other type. */
- gfc_set_default_type (sym, 0, gfc_current_ns);
+ {
+ /* Before the symbol is given an implicit type, check to
+ see if the symbol is already available in the namespace,
+ possibly through host association. Importantly, the
+ symbol may be a user defined type. */
+
+ gfc_symbol *tmp;
+
+ gfc_find_symbol (sym->name, NULL, 1, );
+ if (tmp
+ && tmp->attr.generic
+ && (tmp = gfc_find_dt_in_generic (tmp)))
+ {
+ if (tmp->attr.flavor == FL_DERIVED)
+ {
+ gfc_error ("Derived type %qs at %L conflicts with "
+ "namelist object %qs at %C",
+ tmp->name, >declared_at, sym->name);
+ goto error;
+ }
+ }
+
+ /* Set type of the symbol to its implicit default type. It is
+ not allowed to set it later to any other type. */
+ gfc_set_default_type (sym, 0, gfc_current_ns);
+ }
}
if (sym->attr.in_namelist == 0
&& !gfc_add_in_namelist (>attr, sym->name, NULL))
@@ -6805,8 +6827,20 @@ gfc_match_select_rank (void)
gfc_current_ns = gfc_build_block_ns (ns);
m = gfc_match (" %n => %e", name, );
+
if (m == MATCH_YES)
{
+ /* If expr2 corresponds to an implicitly typed variable, then the
+ actual type of the variable may not have been set. Set it here. */
+ if (!gfc_current_ns->seen_implicit_none
+ && expr2->expr_type == EXPR_VARIABLE
+ && expr2->ts.type == BT_UNKNOWN
+ && expr2->symtree && expr2->symtree->n.sym)
+ {
+ gfc_set_default_type (expr2->symtree->n.sym, 0, gfc_current_ns);
+ expr2->ts.type = expr2->symtree->n.sym->ts.type;
+ }
+
expr1 = gfc_get_expr ();
expr1->expr_type = EXPR_VARIABLE;
expr1->where = expr2->where;
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 8e018b6e7e8..f7cfdfc133f 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -13510,7 +13510,8 @@ resolve_fl_variable (gfc_symbol *sym, int mp_flag)
}
}
- if (sym->value == NULL && sym->attr.referenced)
+ if (sym->value == NULL && sym->attr.referenced
+ && !(sym->as && sym->as->type == AS_ASSUMED_RANK))
apply_default_init_local (sym); /* Try to apply a default initialization. */
/* Determine if the
Re: [PATCH] Fortran: simplification of FINDLOC for constant complex arguments [PR110585]
Hi Harald, This is indeed obvious :-) Thanks for the patch. Paul On Fri, 7 Jul 2023 at 19:32, Harald Anlauf via Fortran wrote: > > Dear all, > > I intend to commit the attached obvious patch within 24h unless > someone objects. gfc_compare_expr() did not handle the case of > complex constants, which may be compared for equality. This > case is needed in the simplification of the FINDLOC intrinsic. > > Regtested on x86_64-pc-linux-gnu. > > Thanks, > Harald > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: PR82943 - Suggested patch to fix
Hi All, I have gone through the PDT problem reports and made sure that they block PR82173. To my utter astonishment (i) There might be only one duplicate; and (ii) Only 82649, 84119, 90218, 95541, 99079, 102901 & 105380 (out of 50 PRs) depend on the representation. Regards Paul
Re: PR82943 - Suggested patch to fix
Hi Alexander,
I suggest that you take a look at PR82649 before going too far down
the road of fixing PDT bugs. This PR underlines just how wrong the PDT
representation is - mea culpa!
The mechanics for constructing PDTs are in
decl.cc(gfc_get_pdt_instance). They need to be turned inside out to
create a container, not unlike the class containers, with
{data-field(assumed rank array?), kind and len parameters}. This will
then trigger all manner of failures in trans-***.cc in particular.
It had been my intention to turn to PDTs after I complete my scourge
of associate construct bugs. If you want to take this on, please do so
and I will give you all the help that I can. You will see from PR82649
that I have been promising to get on to this for a long time but have
not had the time thus far :-( If you want to get on with parsing bugs
to start with, please be my guest!
I notice that searching for PDT in PR title lines generates 48 hits,
while the PDT meta-bug PR82173 only has 28 blockers. I will get on
with the housekeeping this weekend by updating PR82173 and eliminating
duplicates.
Welcome, Alexander!
Paul
On Fri, 30 Jun 2023 at 05:42, Steve Kargl via Fortran
wrote:
>
> On Thu, Jun 29, 2023 at 10:38:42PM -0500, Alexander Westbrooks via Fortran
> wrote:
> > I have finished my testing, and updated my patch and relevant Changelogs. I
> > added 4 new tests and all the existing tests in the current testsuite
> > for gfortran passed or failed as expected. Do I need to attach the test
> > results here?
>
> Yes. It helps others also do testing to have one self-contained
> patch (which I don't know to generate with git and new files :-( ).
> It may also be a good idea to attach the patch and test cases to
> the PR in bugzilla so that they don't accidentally get lost.
>
> > The platform I tested on was a Docker container running in Docker Desktop,
> > running the "mcr.microsoft.com/devcontainers/universal:2-linux" image.
> >
> > I also made sure that my code changes followed the coding standards. Please
> > let me know if there is anything else that I need to do. I don't have
> > write-access to the repository.
>
> See the legal link that Harald provided. At one time, one needed to
> assign copyright to the FSF with a wet-ink signature on some form.
> Now, I think you just need to attest that you have the right to
> provide the code to the gcc project.
>
> PS: Welcome to the gfortran development world. Don't be put off
> if there is a delay in getting feedback/review. There are too
> few contributors and too little time. If a week passes simply
> ping the mailing list. I'll try to carve out some time to look
> over your patch this weekend.
>
> --
> steve
>
>
> >
> > Thanks,
> >
> > Alexander
> >
> > On Wed, Jun 28, 2023 at 4:14 PM Harald Anlauf wrote:
> >
> > > Hi Alex,
> > >
> > > welcome to the gfortran community. It is great that you are trying
> > > to get actively involved.
> > >
> > > You already did quite a few things right: patches shall be sent to
> > > the gcc-patches ML, but Fortran reviewers usually notice them only
> > > where they are copied to the fortran ML.
> > >
> > > There are some general recommendations on the formatting of C code,
> > > like indentation, of the patches, and of the commit log entries.
> > >
> > > Regarding coding standards, see https://www.gnu.org/prep/standards/ .
> > >
> > > Regarding testcases, a recommendation is to have a look at
> > > existing testcases, e.g. in gcc/testsuite/gfortran.dg/, and then
> > > decide if the testcase shall test the compile-time or run-time
> > > behaviour, and add the necessary dejagnu directives.
> > >
> > > You should also verify if your patch passes regression testing.
> > > For changes to gfortran, it is usually sufficient to run
> > >
> > > make check-fortran -j
> > >
> > > where is the number of parallel tests.
> > > You would need to report also the platform where you tested on.
> > >
> > > There is also a legal issue to consider before non-trivial patches can
> > > be accepted for incorporation: https://gcc.gnu.org/contribute.html#legal
> > >
> > > If your patch is accepted and if you do not have write-access to the
> > > repository, one of the maintainers will likely take care of it.
> > > If you become a regular contributor, you will probably want to consider
> > > getting write access.
> > >
> > > Cheers,
> > > Harald
> > >
> > >
> > >
> > > On 6/24/23 19:17, Alexander Westbrooks via Gcc-patches wrote:
> > > > Hello,
> > > >
> > > > I am new to the GFortran community. Over the past two weeks I created a
> > > > patch that should fix PR82943 for GFortran. I have attached it to this
> > > > email. The patch allows the code below to compile successfully. I am
> > > > working on creating test cases next, but I am new to the process so it
> > > may
> > > > take me some time. After I make test cases, do I email them to you as
> > > well?
> > > > Do I need to make a pull-request on github in order to get the patch
> > > >
Re: [Patch, fortran] PR49213 - [OOP] gfortran rejects structure constructor expression
Hi Harald,
I'll change to gfc_charlen_type_node.
Thanks for your patience in reviewing this patch :-)
Cheers
Paul
On Tue, 27 Jun 2023 at 20:27, Harald Anlauf wrote:
>
> Hi Paul,
>
> this is much better now.
>
> I have only a minor comment left: in the calculation of the
> size of a character string you are using an intermediate
> gfc_array_index_type, whereas I have learned to use
> gfc_charlen_type_node now, which seems like the natural
> type here.
>
> OK for trunk, and thanks for your patience!
>
> Harald
>
>
> On 6/27/23 12:30, Paul Richard Thomas via Gcc-patches wrote:
> > Hi Harald,
> >
> > Let's try again :-)
> >
> > OK for trunk?
> >
> > Regards
> >
> > Paul
> >
> > Fortran: Enable class expressions in structure constructors [PR49213]
> >
> > 2023-06-27 Paul Thomas
> >
> > gcc/fortran
> > PR fortran/49213
> > * expr.cc (gfc_is_ptr_fcn): Remove reference to class_pointer.
> > * resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow
> > associate names with pointer function targets to be used in
> > variable definition context.
> > * trans-decl.cc (get_symbol_decl): Remove extraneous line.
> > * trans-expr.cc (alloc_scalar_allocatable_subcomponent): Obtain
> > size of intrinsic and character expressions.
> > (gfc_trans_subcomponent_assign): Expand assignment to class
> > components to include intrinsic and character expressions.
> >
> > gcc/testsuite/
> > PR fortran/49213
> > * gfortran.dg/pr49213.f90 : New test
> >
> > On Sat, 24 Jun 2023 at 20:50, Harald Anlauf wrote:
> >>
> >> Hi Paul!
> >>
> >> On 6/24/23 15:18, Paul Richard Thomas via Gcc-patches wrote:
> >>> I have included the adjustment to 'gfc_is_ptr_fcn' and eliminating the
> >>> extra blank line, introduced by my last patch. I played safe and went
> >>> exclusively for class functions with attr.class_pointer set on the
> >>> grounds that these have had all the accoutrements checked and built
> >>> (ie. class_ok). I am still not sure if this is necessary or not.
> >>
> >> maybe it is my fault, but I find the version in the patch confusing:
> >>
> >> @@ -816,7 +816,7 @@ bool
> >>gfc_is_ptr_fcn (gfc_expr *e)
> >>{
> >> return e != NULL && e->expr_type == EXPR_FUNCTION
> >> - && (gfc_expr_attr (e).pointer
> >> + && ((e->ts.type != BT_CLASS && gfc_expr_attr (e).pointer)
> >> || (e->ts.type == BT_CLASS
> >> && CLASS_DATA (e)->attr.class_pointer));
> >>}
> >>
> >> The caller 'gfc_is_ptr_fcn' has e->expr_type == EXPR_FUNCTION, so
> >> gfc_expr_attr (e) boils down to:
> >>
> >> if (e->value.function.esym && e->value.function.esym->result)
> >> {
> >>gfc_symbol *sym = e->value.function.esym->result;
> >>attr = sym->attr;
> >>if (sym->ts.type == BT_CLASS && sym->attr.class_ok)
> >> {
> >>attr.dimension = CLASS_DATA (sym)->attr.dimension;
> >>attr.pointer = CLASS_DATA (sym)->attr.class_pointer;
> >>attr.allocatable = CLASS_DATA (sym)->attr.allocatable;
> >> }
> >> }
> >> ...
> >> else if (e->symtree)
> >> attr = gfc_variable_attr (e, NULL);
> >>
> >> So I thought this should already do what you want if you do
> >>
> >> gfc_is_ptr_fcn (gfc_expr *e)
> >> {
> >> return e != NULL && e->expr_type == EXPR_FUNCTION && gfc_expr_attr
> >> (e).pointer;
> >> }
> >>
> >> or what am I missing? The additional checks in gfc_expr_attr are
> >> there to avoid ICEs in case CLASS_DATA (sym) has issues, and we all
> >> know Gerhard who showed that he is an expert in exploiting this.
> >>
> >> To sum up, I'd prefer to use the safer form if it works. If it
> >> doesn't, I would expect a latent issue.
> >>
> >> The rest of the code looked good to me, but I was suspicious about
> >> the handling of CHARACTER.
> >>
> >> Nasty as I am, I modified the testcase to use character(kind=4)
> >> instead of kind=1 (see attached). This either fails here (stop 10),
> >> or if I activate the marked line
> >>
&
Re: [Patch, fortran] PR49213 - [OOP] gfortran rejects structure constructor expression
Hi Harald,
Let's try again :-)
OK for trunk?
Regards
Paul
Fortran: Enable class expressions in structure constructors [PR49213]
2023-06-27 Paul Thomas
gcc/fortran
PR fortran/49213
* expr.cc (gfc_is_ptr_fcn): Remove reference to class_pointer.
* resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow
associate names with pointer function targets to be used in
variable definition context.
* trans-decl.cc (get_symbol_decl): Remove extraneous line.
* trans-expr.cc (alloc_scalar_allocatable_subcomponent): Obtain
size of intrinsic and character expressions.
(gfc_trans_subcomponent_assign): Expand assignment to class
components to include intrinsic and character expressions.
gcc/testsuite/
PR fortran/49213
* gfortran.dg/pr49213.f90 : New test
On Sat, 24 Jun 2023 at 20:50, Harald Anlauf wrote:
>
> Hi Paul!
>
> On 6/24/23 15:18, Paul Richard Thomas via Gcc-patches wrote:
> > I have included the adjustment to 'gfc_is_ptr_fcn' and eliminating the
> > extra blank line, introduced by my last patch. I played safe and went
> > exclusively for class functions with attr.class_pointer set on the
> > grounds that these have had all the accoutrements checked and built
> > (ie. class_ok). I am still not sure if this is necessary or not.
>
> maybe it is my fault, but I find the version in the patch confusing:
>
> @@ -816,7 +816,7 @@ bool
> gfc_is_ptr_fcn (gfc_expr *e)
> {
> return e != NULL && e->expr_type == EXPR_FUNCTION
> - && (gfc_expr_attr (e).pointer
> + && ((e->ts.type != BT_CLASS && gfc_expr_attr (e).pointer)
>|| (e->ts.type == BT_CLASS
>&& CLASS_DATA (e)->attr.class_pointer));
> }
>
> The caller 'gfc_is_ptr_fcn' has e->expr_type == EXPR_FUNCTION, so
> gfc_expr_attr (e) boils down to:
>
>if (e->value.function.esym && e->value.function.esym->result)
> {
> gfc_symbol *sym = e->value.function.esym->result;
> attr = sym->attr;
> if (sym->ts.type == BT_CLASS && sym->attr.class_ok)
> {
> attr.dimension = CLASS_DATA (sym)->attr.dimension;
> attr.pointer = CLASS_DATA (sym)->attr.class_pointer;
> attr.allocatable = CLASS_DATA (sym)->attr.allocatable;
> }
> }
> ...
>else if (e->symtree)
> attr = gfc_variable_attr (e, NULL);
>
> So I thought this should already do what you want if you do
>
> gfc_is_ptr_fcn (gfc_expr *e)
> {
>return e != NULL && e->expr_type == EXPR_FUNCTION && gfc_expr_attr
> (e).pointer;
> }
>
> or what am I missing? The additional checks in gfc_expr_attr are
> there to avoid ICEs in case CLASS_DATA (sym) has issues, and we all
> know Gerhard who showed that he is an expert in exploiting this.
>
> To sum up, I'd prefer to use the safer form if it works. If it
> doesn't, I would expect a latent issue.
>
> The rest of the code looked good to me, but I was suspicious about
> the handling of CHARACTER.
>
> Nasty as I am, I modified the testcase to use character(kind=4)
> instead of kind=1 (see attached). This either fails here (stop 10),
> or if I activate the marked line
>
> !cont = tContainer('hello!') ! ### ICE! ###
>
> I get an ICE.
>
> Can you have another look?
>
> Thanks,
> Harald
>
> >
>
> > OK for trunk?
> >
> > Paul
> >
> > Fortran: Enable class expressions in structure constructors [PR49213]
> >
> > 2023-06-24 Paul Thomas
> >
> > gcc/fortran
> > PR fortran/49213
> > * expr.cc (gfc_is_ptr_fcn): Guard pointer attribute to exclude
> > class expressions.
> > * resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow
> > associate names with pointer function targets to be used in
> > variable definition context.
> > * trans-decl.cc (get_symbol_decl): Remove extraneous line.
> > * trans-expr.cc (alloc_scalar_allocatable_subcomponent): Obtain
> > size of intrinsic and character expressions.
> > (gfc_trans_subcomponent_assign): Expand assignment to class
> > components to include intrinsic and character expressions.
> >
> > gcc/testsuite/
> > PR fortran/49213
> > * gfortran.dg/pr49213.f90 : New test
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
! { dg-do run }
!
! Contributed by Neil Carlson
!
program main
character(2) :: c
type :: S
integer :: n
end type
type(S) :: Sobj
type, extends(S) :: S2
integer :: m
end type
type(S2) :: S2obj
type :: T
class(S), allocatable :: x
en
[Patch, fortran] PR49213 - [OOP] gfortran rejects structure constructor expression
Hi All,
I was looking through Neil Carlson's collection of gfortran bugs and
was shocked to find this rather fundamental PR. At 12 years old, it is
certainly a "golden oldie"!
The patch is rather straightforward and seems to do the job of
admitting derived, intrinsic and character expressions to allocatable
class components in structure constructors.
I have included the adjustment to 'gfc_is_ptr_fcn' and eliminating the
extra blank line, introduced by my last patch. I played safe and went
exclusively for class functions with attr.class_pointer set on the
grounds that these have had all the accoutrements checked and built
(ie. class_ok). I am still not sure if this is necessary or not.
OK for trunk?
Paul
Fortran: Enable class expressions in structure constructors [PR49213]
2023-06-24 Paul Thomas
gcc/fortran
PR fortran/49213
* expr.cc (gfc_is_ptr_fcn): Guard pointer attribute to exclude
class expressions.
* resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow
associate names with pointer function targets to be used in
variable definition context.
* trans-decl.cc (get_symbol_decl): Remove extraneous line.
* trans-expr.cc (alloc_scalar_allocatable_subcomponent): Obtain
size of intrinsic and character expressions.
(gfc_trans_subcomponent_assign): Expand assignment to class
components to include intrinsic and character expressions.
gcc/testsuite/
PR fortran/49213
* gfortran.dg/pr49213.f90 : New test
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index c960dfeabd9..92061d69781 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -816,7 +816,7 @@ bool
gfc_is_ptr_fcn (gfc_expr *e)
{
return e != NULL && e->expr_type == EXPR_FUNCTION
- && (gfc_expr_attr (e).pointer
+ && ((e->ts.type != BT_CLASS && gfc_expr_attr (e).pointer)
|| (e->ts.type == BT_CLASS
&& CLASS_DATA (e)->attr.class_pointer));
}
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 82e6ac53aa1..217d69d4e0b 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -1350,6 +1350,9 @@ resolve_structure_cons (gfc_expr *expr, int init)
&& CLASS_DATA (comp)->as)
rank = CLASS_DATA (comp)->as->rank;
+ if (comp->ts.type == BT_CLASS && cons->expr->ts.type == BT_DERIVED)
+ gfc_find_derived_vtab (cons->expr->ts.u.derived);
+
if (cons->expr->expr_type != EXPR_NULL && rank != cons->expr->rank
&& (comp->attr.allocatable || cons->expr->rank))
{
@@ -1381,7 +1384,7 @@ resolve_structure_cons (gfc_expr *expr, int init)
gfc_basic_typename (comp->ts.type));
t = false;
}
- else
+ else if (!UNLIMITED_POLY (comp))
{
bool t2 = gfc_convert_type (cons->expr, >ts, 1);
if (t)
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index 18589e17843..b0fd25e92a3 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -1915,7 +1915,6 @@ gfc_get_symbol_decl (gfc_symbol * sym)
gcc_assert (!sym->value || sym->value->expr_type == EXPR_NULL);
}
-
gfc_finish_var_decl (decl, sym);
if (sym->ts.type == BT_CHARACTER)
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 3c209bcde97..5a1ff0c1d21 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -8781,6 +8781,7 @@ alloc_scalar_allocatable_subcomponent (stmtblock_t *block, tree comp,
tree size;
tree size_in_bytes;
tree lhs_cl_size = NULL_TREE;
+ gfc_se se;
if (!comp)
return;
@@ -8815,16 +8816,26 @@ alloc_scalar_allocatable_subcomponent (stmtblock_t *block, tree comp,
}
else if (cm->ts.type == BT_CLASS)
{
- gcc_assert (expr2->ts.type == BT_CLASS || expr2->ts.type == BT_DERIVED);
- if (expr2->ts.type == BT_DERIVED)
+ if (expr2->ts.type != BT_CLASS)
{
- tmp = gfc_get_symbol_decl (expr2->ts.u.derived);
- size = TYPE_SIZE_UNIT (tmp);
+ if (expr2->ts.type == BT_CHARACTER)
+ {
+ gfc_init_se (, NULL);
+ gfc_conv_expr (, expr2);
+ size = fold_convert (size_type_node, se.string_length);
+ }
+ else
+ {
+ if (expr2->ts.type == BT_DERIVED)
+ tmp = gfc_get_symbol_decl (expr2->ts.u.derived);
+ else
+ tmp = gfc_typenode_for_spec (>ts);
+ size = TYPE_SIZE_UNIT (tmp);
+ }
}
else
{
gfc_expr *e2vtab;
- gfc_se se;
e2vtab = gfc_find_and_cut_at_last_class_ref (expr2);
gfc_add_vptr_component (e2vtab);
gfc_add_size_component (e2vtab);
@@ -8975,6 +8986,7 @@ gfc_trans_subcomponent_assign (tree dest, gfc_component * cm,
{
gfc_init_se (, NULL);
gfc_conv_expr (, expr);
+ tree size;
/* Take care about non-array allocatable components here. The alloc_*
routine below is motivated by the alloc_scalar_allocatable_for_
@@ -8990,7 +9002,7 @@ gfc_trans_subcomponent_assign (tree dest, gfc_component * cm,
&& expr->symtree->n.sym->attr.dummy)
se.expr = build_fold_indirect_ref_loc (input_location, se.expr);
- if (cm->ts.type == BT_CLASS &&
Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault
Hi Both,
> while I only had a minor question regarding gfc_is_ptr_fcn(),
> can you still try to enlighten me why that second part
> was necessary? (I believed it to be redundant and may have
> overlooked the obvious.)
Blast! I forgot about checking that. Lurking in the back of my mind
and going back to the first days of OOP in gfortran is a distinction
between a class entity with the pointer attribute and one whose data
component has the class_pointer attribute. I'll check it out and do
whatever is needed.
> > + else if (context && gfc_is_ptr_fcn (assoc->target))
> > + {
> > + if (!gfc_notify_std (GFC_STD_F2018, "%qs at %L associated to "
> > +"pointer function target being used in a "
> > +"variable definition context (%s)", name,
> > +>where, context))
>
> I'm curious why you decided to put context in braces and not simply use
> quotes as per %qs?
That's the way it's done in the preceding errors. I had to keep the
context in context, so to speak.
> > +/* Build the associate name */
> > +static int
> > +build_associate_name (const char *name, gfc_expr **e1, gfc_expr **e2)
> > +{
>
> > +return 1;
>
> > + return 0;
> > +}
>
> I've gone through the frontend recently and changed several such
> boolean functions to use bool where appropriate. May i ask folks to use
> narrower types in new code, please?
> Iff later in the pipeline it is considered appropriate or benefical to
> promote types, these will eventually be promoted.
>
> > diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
> > index e6a4337c0d2..18589e17843 100644
> > --- a/gcc/fortran/trans-decl.cc
> > +++ b/gcc/fortran/trans-decl.cc
>
> > @@ -1906,6 +1915,7 @@ gfc_get_symbol_decl (gfc_symbol * sym)
> > gcc_assert (!sym->value || sym->value->expr_type == EXPR_NULL);
> > }
> >
> > +
>
'twas accidental. There had previously been another version of the fix
that I commented out and the extra line crept in when I deleted it.
Thanks for the spot.
>
> Please kindly excuse my comment and, again, thanks!
>
> >gfc_finish_var_decl (decl, sym);
> >
> >if (sym->ts.type == BT_CHARACTER)
Regards
Paul
Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault
Committed as r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27
Thanks for the help and the review Harald. Thanks to Steve too for
picking up Neil Carlson's bugs.
Cheers
Paul
On Tue, 20 Jun 2023 at 22:57, Harald Anlauf wrote:
>
> Hi Paul,
>
> On 6/20/23 12:54, Paul Richard Thomas via Gcc-patches wrote:
> > Hi Harald,
> >
> > Fixing the original testcase in this PR turned out to be slightly more
> > involved than I expected. However, it resulted in an open door to fix
> > some other PRs and the attached much larger patch.
> >
> > This time, I did remember to include the testcases in the .diff :-)
>
> indeed! :-)
>
> I've only had a superficial look so far although it looks very good.
> (I have to trust your experience with unlimited polymorphism.)
>
> However, I was wondering about the following helper function:
>
> +bool
> +gfc_is_ptr_fcn (gfc_expr *e)
> +{
> + return e != NULL && e->expr_type == EXPR_FUNCTION
> + && (gfc_expr_attr (e).pointer
> + || (e->ts.type == BT_CLASS
> + && CLASS_DATA (e)->attr.class_pointer));
> +}
> +
> +
> /* Copy a shape array. */
>
> Is there a case where gfc_expr_attr (e).pointer returns false
> and you really need the || part? Looking at gfc_expr_attr
> and the present context, it might just not be necessary.
>
> > I believe that, between the Change.Logs and the comments, it is
> > reasonably self-explanatory.
> >
> > OK for trunk?
>
> OK from my side.
>
> Thanks for the patch!
>
> Harald
>
> > Regards
> >
> > Paul
> >
> > Fortran: Fix some bugs in associate [PR87477]
> >
> > 2023-06-20 Paul Thomas
> >
> > gcc/fortran
> > PR fortran/87477
> > PR fortran/88688
> > PR fortran/94380
> > PR fortran/107900
> > PR fortran/110224
> > * decl.cc (char_len_param_value): Fix memory leak.
> > (resolve_block_construct): Remove unnecessary static decls.
> > * expr.cc (gfc_is_ptr_fcn): New function.
> > (gfc_check_vardef_context): Use it to permit pointer function
> > result selectors to be used for associate names in variable
> > definition context.
> > * gfortran.h: Prototype for gfc_is_ptr_fcn.
> > * match.cc (build_associate_name): New function.
> > (gfc_match_select_type): Use the new function to replace inline
> > version and to build a new associate name for the case where
> > the supplied associate name is already used for that purpose.
> > * resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow
> > associate names with pointer function targets to be used in
> > variable definition context.
> > * trans-decl.cc (gfc_get_symbol_decl): Unlimited polymorphic
> > variables need deferred initialisation of the vptr.
> > (gfc_trans_deferred_vars): Do the vptr initialisation.
> > * trans-stmt.cc (trans_associate_var): Ensure that a pointer
> > associate name points to the target of the selector and not
> > the selector itself.
> >
> > gcc/testsuite/
> > PR fortran/87477
> > PR fortran/107900
> > * gfortran.dg/pr107900.f90 : New test
> >
> > PR fortran/110224
> > * gfortran.dg/pr110224.f90 : New test
> >
> > PR fortran/88688
> > * gfortran.dg/pr88688.f90 : New test
> >
> > PR fortran/94380
> > * gfortran.dg/pr94380.f90 : New test
> >
> > PR fortran/95398
> > * gfortran.dg/pr95398.f90 : Set -std=f2008, bump the line
> > numbers in the error tests by two and change the text in two.
>
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Re: [Patch, fortran] PR108961 - Segfault when associating to pointer from C_F_POINTER
Committed as r14-2021-gcaf0892eea67349d9a1e44590c3440768136fe2b Thanks for the pointers, Tobias and Mikael, I used them both. Paul On Tue, 20 Jun 2023 at 21:47, Mikael Morin wrote: > > Le 20/06/2023 à 18:30, Tobias Burnus a écrit : > > On 20.06.23 18:19, Paul Richard Thomas via Fortran wrote: > > > >> Is there a better way to detect a type(c_ptr) formal argument? > > u.derived->intmod_sym_id == ISOCBINDING_PTR ? > && u.derived->from_intmod == INTMOD_ISO_C_BINDING ? > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[Patch, fortran] PR108961 - Segfault when associating to pointer from C_F_POINTER
Dear All,
This patch is verging on obvious. The PR was originally, incorrectly
blocking PR87477 and the testcase has remained in my 'associate'
directory. I thought that it is time to get shot of it!
Is there a better way to detect a type(c_ptr) formal argument?
Subject to advice on the question, OK for trunk?
Paul
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 45a984b6bdb..0823efd5abc 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -7353,6 +7353,8 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
need the length. */
if (parmse.string_length != NULL_TREE
&& !sym->attr.is_bind_c
+ && !(fsym && fsym->ts.type == BT_DERIVED
+ && !strcmp (fsym->ts.u.derived->name, "c_ptr"))
&& !(fsym && UNLIMITED_POLY (fsym)))
vec_safe_push (stringargs, parmse.string_length);
Change.Logs
Description: Binary data
! { dg-do run }
!
! Contributed by Jeffrey Hill
!
module associate_ptr
use iso_c_binding
contains
subroutine c_f_strpointer(cptr, ptr2)
type(c_ptr), target, intent(in) :: cptr
character(kind=c_char,len=4), pointer :: ptr1
character(kind=c_char,len=:), pointer, intent(out) :: ptr2
call c_f_pointer(cptr, ptr1)
if (ptr1 .ne. 'abcd') stop 1
ptr2 => ptr1 ! Failed here
end subroutine
end module
program test_associate_ptr
use associate_ptr
character(kind=c_char, len=1), target :: char_array(7)
character(kind=c_char,len=:), pointer :: ptr2
char_array = ['a', 'b', 'c', 'd', c_null_char, 'e', 'f']
! The first argument was providing a constant hidden string length => segfault
call c_f_strpointer(c_loc(char_array), ptr2)
if (ptr2 .ne. 'abcd') stop 2
end program
Re: [Patch] Fortran's gfc_match_char: %S to match symbol with host_assoc
Hi Tobias,
This looks good to me. I'm interested to see it in use :-)
OK for trunk
Paul
On Tue, 20 Jun 2023 at 11:50, Tobias Burnus wrote:
>
> When just matching a symbol, one can use 'gfc_match_symbol (, host_assoc)'
> and has the option to match with and without host association.
>
> However, when matching something more complex via 'gfc_match' like
> "something ( %s ) , " the match uses host_assoc = false.
> While it can be combined ("something (" + symbol + " ) ,"), this requires
> keeping track of the previous location and resetting it.
>
> It seems to be much simply to add a new flag supporting host_assoc = true,
> which this patch does (using '%S'). The advantage is also that when looking
> at the comment or at the "%s" implementation, it is clear that there are two
> variants, making it less likely to choose the wrong matching.
>
> OK for mainline?
>
> Tobias
>
> PS: I will use it in an upcoming OpenMP to parse 'uses_allocators'.
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
> München, HRB 106955
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Re: [Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault
Hi Harald,
Fixing the original testcase in this PR turned out to be slightly more
involved than I expected. However, it resulted in an open door to fix
some other PRs and the attached much larger patch.
This time, I did remember to include the testcases in the .diff :-)
I believe that, between the Change.Logs and the comments, it is
reasonably self-explanatory.
OK for trunk?
Regards
Paul
Fortran: Fix some bugs in associate [PR87477]
2023-06-20 Paul Thomas
gcc/fortran
PR fortran/87477
PR fortran/88688
PR fortran/94380
PR fortran/107900
PR fortran/110224
* decl.cc (char_len_param_value): Fix memory leak.
(resolve_block_construct): Remove unnecessary static decls.
* expr.cc (gfc_is_ptr_fcn): New function.
(gfc_check_vardef_context): Use it to permit pointer function
result selectors to be used for associate names in variable
definition context.
* gfortran.h: Prototype for gfc_is_ptr_fcn.
* match.cc (build_associate_name): New function.
(gfc_match_select_type): Use the new function to replace inline
version and to build a new associate name for the case where
the supplied associate name is already used for that purpose.
* resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow
associate names with pointer function targets to be used in
variable definition context.
* trans-decl.cc (gfc_get_symbol_decl): Unlimited polymorphic
variables need deferred initialisation of the vptr.
(gfc_trans_deferred_vars): Do the vptr initialisation.
* trans-stmt.cc (trans_associate_var): Ensure that a pointer
associate name points to the target of the selector and not
the selector itself.
gcc/testsuite/
PR fortran/87477
PR fortran/107900
* gfortran.dg/pr107900.f90 : New test
PR fortran/110224
* gfortran.dg/pr110224.f90 : New test
PR fortran/88688
* gfortran.dg/pr88688.f90 : New test
PR fortran/94380
* gfortran.dg/pr94380.f90 : New test
PR fortran/95398
* gfortran.dg/pr95398.f90 : Set -std=f2008, bump the line
numbers in the error tests by two and change the text in two.
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index d09c8bc97d9..844345df77e 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -1086,6 +1086,8 @@ char_len_param_value (gfc_expr **expr, bool *deferred)
p = gfc_copy_expr (*expr);
if (gfc_is_constant_expr (p) && gfc_simplify_expr (p, 1))
gfc_replace_expr (*expr, p);
+ else
+gfc_free_expr (p);
if ((*expr)->expr_type == EXPR_FUNCTION)
{
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index d5cfbe0cc55..c960dfeabd9 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -812,6 +812,16 @@ gfc_has_vector_index (gfc_expr *e)
}
+bool
+gfc_is_ptr_fcn (gfc_expr *e)
+{
+ return e != NULL && e->expr_type == EXPR_FUNCTION
+ && (gfc_expr_attr (e).pointer
+ || (e->ts.type == BT_CLASS
+ && CLASS_DATA (e)->attr.class_pointer));
+}
+
+
/* Copy a shape array. */
mpz_t *
@@ -6470,6 +6480,22 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer, bool alloc_obj,
}
return false;
}
+ else if (context && gfc_is_ptr_fcn (assoc->target))
+ {
+ if (!gfc_notify_std (GFC_STD_F2018, "%qs at %L associated to "
+ "pointer function target being used in a "
+ "variable definition context (%s)", name,
+ >where, context))
+ return false;
+ else if (gfc_has_vector_index (e))
+ {
+ gfc_error ("%qs at %L associated to vector-indexed target"
+ " cannot be used in a variable definition"
+ " context (%s)",
+ name, >where, context);
+ return false;
+ }
+ }
/* Target must be allowed to appear in a variable definition context. */
if (!gfc_check_vardef_context (assoc->target, pointer, false, false, NULL))
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index a58c60e9828..30631abd788 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3659,6 +3659,7 @@ bool gfc_is_constant_expr (gfc_expr *);
bool gfc_simplify_expr (gfc_expr *, int);
bool gfc_try_simplify_expr (gfc_expr *, int);
bool gfc_has_vector_index (gfc_expr *);
+bool gfc_is_ptr_fcn (gfc_expr *);
gfc_expr *gfc_get_expr (void);
gfc_expr *gfc_get_array_expr (bt type, int kind, locus *);
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index e7be7fddc64..0e4b5440393 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -6377,6 +6377,39 @@ build_class_sym:
}
+/* Build the associate name */
+static int
+build_associate_name (const char *name, gfc_expr **e1, gfc_expr **e2)
+{
+ gfc_expr *expr1 = *e1;
+ gfc_expr *expr2 = *e2;
+ gfc_symbol *sym;
+
+ /* For the case where the associate name is already an associate name. */
+ if (!expr2)
+expr2 = expr1;
+ expr1 = gfc_get_expr ();
+ expr1->expr_type = EXPR_VARIABLE;
+ expr1->where = expr2->where;
+ if (gfc_get_sym_tree (name, NULL, >symtree, false))
+return 1;
+
+ sym = expr1->symtree->n.sym;
+ if (expr2->ts.type == BT_UNKNOWN)
+ sym->attr.untyped = 1;
+ else
+
[Patch, fortran] PR107900 Select type with intrinsic type inside associate causes ICE / Segmenation fault
Hi All,
The attached patch is amply described by the comments and the
changelog. It also includes the fix for the memory leak in decl.cc, as
promised some days ago.
OK for trunk?
Regards
Paul
PS This leaves 89645 and 99065 as the only real blockers to PR87477.
These will take a little while to fix. They come about because the
type of the associate name is determined by that of a derived type
function that hasn't been parsed at the time that component references
are being parsed. If the order of the contained procedures is
reversed, both test cases compile correctly. The fix will comprise
matching the component name to the accessible derived types, while
keeping track of all the references in case the match is ambiguous and
has to be fixed up later.
Change107900.Logs
Description: Binary data
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index d09c8bc97d9..844345df77e 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -1086,6 +1086,8 @@ char_len_param_value (gfc_expr **expr, bool *deferred)
p = gfc_copy_expr (*expr);
if (gfc_is_constant_expr (p) && gfc_simplify_expr (p, 1))
gfc_replace_expr (*expr, p);
+ else
+gfc_free_expr (p);
if ((*expr)->expr_type == EXPR_FUNCTION)
{
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index e6a4337c0d2..ab5f94e9f03 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -1875,6 +1875,13 @@ gfc_get_symbol_decl (gfc_symbol * sym)
&& !(sym->attr.use_assoc && !intrinsic_array_parameter)))
gfc_defer_symbol_init (sym);
+ /* Nullify so that select type doesn't fall over if the variable
+ is not associated. */
+ if (sym->ts.type == BT_CLASS && UNLIMITED_POLY (sym)
+ && sym->attr.flavor == FL_VARIABLE && !sym->assoc
+ && !sym->attr.dummy && CLASS_DATA (sym)->attr.class_pointer)
+gfc_defer_symbol_init (sym);
+
if (sym->ts.type == BT_CHARACTER
&& sym->attr.allocatable
&& !sym->attr.dimension
@@ -1906,6 +1913,7 @@ gfc_get_symbol_decl (gfc_symbol * sym)
gcc_assert (!sym->value || sym->value->expr_type == EXPR_NULL);
}
+
gfc_finish_var_decl (decl, sym);
if (sym->ts.type == BT_CHARACTER)
@@ -4652,6 +4660,21 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gfc_wrapped_block * block)
if (sym->assoc)
continue;
+ /* Nullify unlimited polymorphic variables so that they do not cause
+ segfaults in select type, when the selector is an intrinsic type. */
+ if (sym->ts.type == BT_CLASS && UNLIMITED_POLY (sym)
+ && sym->attr.flavor == FL_VARIABLE && !sym->assoc
+ && !sym->attr.dummy && CLASS_DATA (sym)->attr.class_pointer)
+ {
+ gfc_expr *lhs = gfc_lval_expr_from_sym (sym);
+ gfc_expr *rhs = gfc_get_null_expr (NULL);
+ tmp = gfc_trans_pointer_assignment (lhs, rhs);
+ gfc_init_block ();
+ gfc_add_expr_to_block (, tmp);
+ gfc_add_init_cleanup (block, gfc_finish_block (), NULL);
+ continue;
+ }
+
if (sym->ts.type == BT_DERIVED
&& sym->ts.u.derived
&& sym->ts.u.derived->attr.pdt_type)
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 45a984b6bdb..eeae13998a3 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -10034,6 +10034,19 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gfc_expr * expr2)
build_zero_cst (TREE_TYPE (lse.string_length)));
}
+ /* Unlimited polymorphic arrays, nullified in gfc_trans_deferred_vars,
+ arrive here as a scalar expr. Find the descriptor data field. */
+ if (expr1->ts.type == BT_CLASS && UNLIMITED_POLY (expr1)
+ && expr2->expr_type == EXPR_NULL
+ && !expr1->ref && !expr1->rank
+ && (CLASS_DATA (expr1)->attr.dimension
+ || CLASS_DATA (expr1)->attr.codimension))
+ {
+ lse.expr = gfc_get_class_from_expr (lse.expr);
+ lse.expr = gfc_class_data_get (lse.expr);
+ lse.expr = gfc_conv_descriptor_data_get (lse.expr);
+ }
+
gfc_add_modify (, lse.expr,
fold_convert (TREE_TYPE (lse.expr), rse.expr));
Re: [Patch, fortran] PR87477 - (associate) - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Thanks Gents!
The solution is to gfc_free_expr (p) if the replacement is not made.
I am regtesting a patch for PR107900. I'll include the fix for the
memory leak in the patch for that.
Cheers
Paul
On Thu, 8 Jun 2023 at 09:30, Harald Anlauf wrote:
>
> On 6/8/23 09:46, Mikael Morin wrote:
> > Le 08/06/2023 à 07:57, Paul Richard Thomas via Fortran a écrit :
> >> Hi Harald,
> >>
> >> In answer to your question:
> >> void
> >> gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
> >> {
> >>free_expr0 (dest);
> >>*dest = *src;
> >>free (src);
> >> }
> >> So it does indeed do the job.
> >>
> > Sure, but his comment was about the case gfc_replace_expr is *not*
> > executed.
>
> Right. The following legal code exhibits the leak, pointing
> to the gfc_copy_expr:
>
> subroutine paul (n)
>integer :: n
>character(n) :: c
> end
>
> >> I should perhaps have remarked that, following the divide error,
> >> gfc_simplify_expr was returning a mutilated version of the expression
> >> and this was somehow connected with successfully simplifying the
> >> parentheses. Copying and replacing on no errors deals with the
> >> problem.
> >>
> > Is the expression mutilated enough that it can't be safely freed?
> >
> >
> >
>
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Re: [Patch, fortran] PR87477 - (associate) - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Hi Harald,
In answer to your question:
void
gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
{
free_expr0 (dest);
*dest = *src;
free (src);
}
So it does indeed do the job.
I should perhaps have remarked that, following the divide error,
gfc_simplify_expr was returning a mutilated version of the expression
and this was somehow connected with successfully simplifying the
parentheses. Copying and replacing on no errors deals with the
problem.
Thanks
Paul
On Wed, 7 Jun 2023 at 19:38, Harald Anlauf wrote:
>
> Hi Paul!
>
> On 6/7/23 18:10, Paul Richard Thomas via Gcc-patches wrote:
> > Hi All,
> >
> > Three more fixes for PR87477. Please note that PR99350 was a blocker
> > but, as pointed out in comment #5 of the PR, this has nothing to do
> > with the associate construct.
> >
> > All three fixes are straight forward and the .diff + ChangeLog suffice
> > to explain them. 'rankguessed' was made redundant by the last PR87477
> > fix.
> >
> > Regtests on x86_64 - good for mainline?
> >
> > Paul
> >
> > Fortran: Fix some more blockers in associate meta-bug [PR87477]
> >
> > 2023-06-07 Paul Thomas
> >
> > gcc/fortran
> > PR fortran/99350
> > * decl.cc (char_len_param_value): Simplify a copy of the expr
> > and replace the original if there is no error.
>
> This seems to lack a gfc_free_expr (p) in case the gfc_replace_expr
> is not executed, leading to a possible memleak. Can you check?
>
> @@ -1081,10 +1082,10 @@ char_len_param_value (gfc_expr **expr, bool
> *deferred)
> if (!gfc_expr_check_typed (*expr, gfc_current_ns, false))
> return MATCH_ERROR;
>
> - /* If gfortran gets an EXPR_OP, try to simplify it. This catches things
> - like CHARACTER(([1])). */
> - if ((*expr)->expr_type == EXPR_OP)
> -gfc_simplify_expr (*expr, 1);
> + /* Try to simplify the expression to catch things like
> CHARACTER(([1])). */
> + p = gfc_copy_expr (*expr);
> + if (gfc_is_constant_expr (p) && gfc_simplify_expr (p, 1))
> +gfc_replace_expr (*expr, p);
> else
> gfc_free_expr (p);
>
> > * gfortran.h : Remove the redundant field 'rankguessed' from
> > 'gfc_association_list'.
> > * resolve.cc (resolve_assoc_var): Remove refs to 'rankguessed'.
> >
> > PR fortran/107281
> > * resolve.cc (resolve_variable): Associate names with constant
> > or structure constructor targets cannot have array refs.
> >
> > PR fortran/109451
> > * trans-array.cc (gfc_conv_expr_descriptor): Guard expression
> > character length backend decl before using it. Suppress the
> > assignment if lhs equals rhs.
> > * trans-io.cc (gfc_trans_transfer): Scalarize transfer of
> > associate variables pointing to a variable. Add comment.
> > * trans-stmt.cc (trans_associate_var): Remove requirement that
> > the character length be deferred before assigning the value
> > returned by gfc_conv_expr_descriptor. Also, guard the backend
> > decl before testing with VAR_P.
> >
> > gcc/testsuite/
> > PR fortran/99350
> > * gfortran.dg/pr99350.f90 : New test.
> >
> > PR fortran/107281
> > * gfortran.dg/associate_5.f03 : Changed error message.
> > * gfortran.dg/pr107281.f90 : New test.
> >
> > PR fortran/109451
> > * gfortran.dg/associate_61.f90 : New test
>
> Otherwise LGTM.
>
> Thanks for the patch!
>
> Harald
>
>
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
[Patch, fortran] PR87477 - (associate) - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Hi All,
Three more fixes for PR87477. Please note that PR99350 was a blocker
but, as pointed out in comment #5 of the PR, this has nothing to do
with the associate construct.
All three fixes are straight forward and the .diff + ChangeLog suffice
to explain them. 'rankguessed' was made redundant by the last PR87477
fix.
Regtests on x86_64 - good for mainline?
Paul
Fortran: Fix some more blockers in associate meta-bug [PR87477]
2023-06-07 Paul Thomas
gcc/fortran
PR fortran/99350
* decl.cc (char_len_param_value): Simplify a copy of the expr
and replace the original if there is no error.
* gfortran.h : Remove the redundant field 'rankguessed' from
'gfc_association_list'.
* resolve.cc (resolve_assoc_var): Remove refs to 'rankguessed'.
PR fortran/107281
* resolve.cc (resolve_variable): Associate names with constant
or structure constructor targets cannot have array refs.
PR fortran/109451
* trans-array.cc (gfc_conv_expr_descriptor): Guard expression
character length backend decl before using it. Suppress the
assignment if lhs equals rhs.
* trans-io.cc (gfc_trans_transfer): Scalarize transfer of
associate variables pointing to a variable. Add comment.
* trans-stmt.cc (trans_associate_var): Remove requirement that
the character length be deferred before assigning the value
returned by gfc_conv_expr_descriptor. Also, guard the backend
decl before testing with VAR_P.
gcc/testsuite/
PR fortran/99350
* gfortran.dg/pr99350.f90 : New test.
PR fortran/107281
* gfortran.dg/associate_5.f03 : Changed error message.
* gfortran.dg/pr107281.f90 : New test.
PR fortran/109451
* gfortran.dg/associate_61.f90 : New test
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index f5d39e2a3d8..d09c8bc97d9 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -1056,6 +1056,7 @@ static match
char_len_param_value (gfc_expr **expr, bool *deferred)
{
match m;
+ gfc_expr *p;
*expr = NULL;
*deferred = false;
@@ -1081,10 +1082,10 @@ char_len_param_value (gfc_expr **expr, bool *deferred)
if (!gfc_expr_check_typed (*expr, gfc_current_ns, false))
return MATCH_ERROR;
- /* If gfortran gets an EXPR_OP, try to simplify it. This catches things
- like CHARACTER(([1])). */
- if ((*expr)->expr_type == EXPR_OP)
-gfc_simplify_expr (*expr, 1);
+ /* Try to simplify the expression to catch things like CHARACTER(([1])). */
+ p = gfc_copy_expr (*expr);
+ if (gfc_is_constant_expr (p) && gfc_simplify_expr (p, 1))
+gfc_replace_expr (*expr, p);
if ((*expr)->expr_type == EXPR_FUNCTION)
{
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 3e5f942d7fd..a65dd571591 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2914,9 +2914,6 @@ typedef struct gfc_association_list
for memory handling. */
unsigned dangling:1;
- /* True when the rank of the target expression is guessed during parsing. */
- unsigned rankguessed:1;
-
char name[GFC_MAX_SYMBOL_LEN + 1];
gfc_symtree *st; /* Symtree corresponding to name. */
locus where;
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 2ba3101f1fe..f2604314570 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -5872,7 +5872,15 @@ resolve_variable (gfc_expr *e)
if (sym->ts.type == BT_CLASS)
gfc_fix_class_refs (e);
if (!sym->attr.dimension && e->ref && e->ref->type == REF_ARRAY)
- return false;
+ {
+ /* Unambiguously scalar! */
+ if (sym->assoc->target
+ && (sym->assoc->target->expr_type == EXPR_CONSTANT
+ || sym->assoc->target->expr_type == EXPR_STRUCTURE))
+ gfc_error ("Scalar variable %qs has an array reference at %L",
+ sym->name, >where);
+ return false;
+ }
else if (sym->attr.dimension && (!e->ref || e->ref->type != REF_ARRAY))
{
/* This can happen because the parser did not detect that the
@@ -9279,7 +9287,7 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target)
gfc_array_spec *as;
/* The rank may be incorrectly guessed at parsing, therefore make sure
it is corrected now. */
- if (sym->ts.type != BT_CLASS && (!sym->as || sym->assoc->rankguessed))
+ if (sym->ts.type != BT_CLASS && !sym->as)
{
if (!sym->as)
sym->as = gfc_get_array_spec ();
@@ -9292,8 +9300,7 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target)
sym->attr.codimension = 1;
}
else if (sym->ts.type == BT_CLASS
- && CLASS_DATA (sym)
- && (!CLASS_DATA (sym)->as || sym->assoc->rankguessed))
+ && CLASS_DATA (sym) && !CLASS_DATA (sym)->as)
{
if (!CLASS_DATA (sym)->as)
CLASS_DATA (sym)->as = gfc_get_array_spec ();
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 1c7ea900ea1..e1c75e9fe02 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -7934,7 +7934,8 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
else
tmp = se->string_length;
- if (expr->ts.deferred && VAR_P
Re: [Patch, fortran] PR37336 finalization
Hi Thomas, I want to get something approaching correct finalization to the distros, which implies 12-branch at present. Hopefully I can do the same with associate in a month or two's time. I am dithering about changing the F2003/08 part of finalization since the default is 2018 compliance. That said, it does need a change since the suppression of constructor finalization is also suppressing finalization of function results within the compilers. I'll do that first, perhaps? Cheers Paul On Sat, 3 Jun 2023 at 06:50, Thomas Koenig wrote: > > Hi Paul, > > > I propose to backport > > r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very > > soon. > > Is this something that we usually do? > > While finalization was basically broken before, some people still used > working subsets (or subsets that were broken, and they adapted or > wrote their code accordingly). > > What is the general opinion on that? I'm undecided. > > > Before that, I propose to remove the F2003/2008 finalization of > > structure and array constructors in 13- and 14-branches. I can see why > > it was removed from the standard in a correction to F2008 and think > > that it is likely to cause endless confusion and maintenance > > complications. However, finalization of function results within > > constructors will be retained. > > That, I agree with. Should it be noted somewhere as an intentional > deviation from the standard? > > Best regards > > Thomas > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH, committed] Fortran: fix diagnostics for SELECT RANK [PR100607]
Hi Harald, It looks good to me. Thanks to you and Steve for the fix. I suggest that it is such and obvious one that it deserved back-porting. Cheers Paul On Fri, 2 Jun 2023 at 19:06, Harald Anlauf via Fortran wrote: > > Dear all, > > I've committed that attached simple patch on behalf of Steve > after discussion in the PR and regtesting on x86_64-pc-linux-gnu. > > It fixes a duplicate error message and an ICE. > > Pushed as r14-1505-gfae09dfc0e6bf4cfe35d817558827aea78c6426f . > > Thanks, > Harald > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch, fortran] PR37336 finalization
Hi All, I propose to backport r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee to 12-branch very soon. Before that, I propose to remove the F2003/2008 finalization of structure and array constructors in 13- and 14-branches. I can see why it was removed from the standard in a correction to F2008 and think that it is likely to cause endless confusion and maintenance complications. However, finalization of function results within constructors will be retained. If there are any objections, please let me know. 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
[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: [Patch, fortran] PR103716 - [10/11/12/13/14 Regression] ICE in gimplify_expr, at gimplify.c:15964
Duuh! There's even a choice :-)
Paul
On Tue, 9 May 2023 at 19:29, Harald Anlauf wrote:
> Hi Paul,
>
> On 5/9/23 18:00, Paul Richard Thomas via Gcc-patches wrote:
> > Hi All,
> >
> > This problem caused the gimplifier failure because the reference chain
> > ending in an inquiry_len still retained a full array reference. This had
> > already been corrected for deferred character lengths but the fix extends
> > this to all characters without a length expression and integer
> expressions,
> > which is the correct type of course, that retain a full array_spec. The
> > nullification of the se->string length in conv_inquiry is a
> > belts-and-braces measure to stop it from winding up as a hidden argument
> in
> > procedure calls.
> >
> > OK for trunk and, after a decent delay, backporting?
>
> ENOTESTCASE.
>
> Nevertheless the patch LGTM and is also OK for backporting.
>
> Thanks for fixing this!
>
> Harald
>
>
> > Cheers
> >
> > Paul
> >
> > Fortran: Fix assumed length chars and len inquiry [PR103716]
> >
> > 2023-05-09 Paul Thomas
> >
> > gcc/fortran
> > PR fortran/103716
> > * resolve.cc (gfc_resolve_ref): Conversion of array_ref into an
> > element should be done for all characters without a len expr,
> > not just deferred lens, and for integer expressions.
> > * trans-expr.cc (conv_inquiry): For len and kind inquiry refs,
> > set the se string_length to NULL_TREE.
> >
> > gcc/testsuite/
> > PR fortran/103716
> > * gfortran.dg/pr103716 : New test.
>
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
! { dg-do run }
!
! The gimplifier used to throw a fit on the write statements in f1 and f2.
!
! Contributed by Gerhard Steinmetz
!
module m
character(6) :: buffer
contains
integer function g(x)
integer :: x
g = x
end
integer function f1(x)
character(*) :: x(*)
write (buffer(1:3),'(i2)') g(x%len)
end
integer function f2(x)
character(*) :: x(3)
write (buffer(4:6),'(i2)') g(x%len)
end
end module m
use m
integer :: i(2), j
character(2), dimension(3) :: chr = ['ab','cd','ef']
i(1) = f1(chr)
i(2) = f2(chr)
if (any (i .eq.2)) stop 1
if (trim(buffer) .ne. ' 2 2') stop 2
end
! { dg-do compile }
!
! The gimplifier used to throw a fit on thes two functions.
!
! Contributed by Gerhard Steinmetz
!
function f1(x)
character(*) :: x(*)
print *, g(x%len)
end
function f2(x)
character(*) :: x(3)
print *, g(x%len)
end
[Patch, fortran] PR103716 - [10/11/12/13/14 Regression] ICE in gimplify_expr, at gimplify.c:15964
Hi All,
This problem caused the gimplifier failure because the reference chain
ending in an inquiry_len still retained a full array reference. This had
already been corrected for deferred character lengths but the fix extends
this to all characters without a length expression and integer expressions,
which is the correct type of course, that retain a full array_spec. The
nullification of the se->string length in conv_inquiry is a
belts-and-braces measure to stop it from winding up as a hidden argument in
procedure calls.
OK for trunk and, after a decent delay, backporting?
Cheers
Paul
Fortran: Fix assumed length chars and len inquiry [PR103716]
2023-05-09 Paul Thomas
gcc/fortran
PR fortran/103716
* resolve.cc (gfc_resolve_ref): Conversion of array_ref into an
element should be done for all characters without a len expr,
not just deferred lens, and for integer expressions.
* trans-expr.cc (conv_inquiry): For len and kind inquiry refs,
set the se string_length to NULL_TREE.
gcc/testsuite/
PR fortran/103716
* gfortran.dg/pr103716 : New test.
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 55d8e326a87..8f0dd8b6dee 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -5504,7 +5504,9 @@ gfc_resolve_ref (gfc_expr *expr)
case REF_INQUIRY:
/* Implement requirement in note 9.7 of F2018 that the result of the
LEN inquiry be a scalar. */
- if (ref->u.i == INQUIRY_LEN && array_ref && expr->ts.deferred)
+ if (ref->u.i == INQUIRY_LEN && array_ref
+ && ((expr->ts.type == BT_CHARACTER && !expr->ts.u.cl->length)
+ || expr->ts.type == BT_INTEGER))
{
array_ref->u.ar.type = AR_ELEMENT;
expr->rank = 0;
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 09cdd9263c4..3225b419989 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -2861,11 +2861,13 @@ conv_inquiry (gfc_se * se, gfc_ref * ref, gfc_expr *expr, gfc_typespec *ts)
case INQUIRY_KIND:
res = build_int_cst (gfc_typenode_for_spec (>ts),
ts->kind);
+ se->string_length = NULL_TREE;
break;
case INQUIRY_LEN:
res = fold_convert (gfc_typenode_for_spec (>ts),
se->string_length);
+ se->string_length = NULL_TREE;
break;
default:
[Patch, fortran] PR97122 - Spurious FINAL ... must be in the specification part of a MODULE
Hi All,
Thanks to Steve Kargl for the fix. It caused finalize_8.f03 to fail because
this testcase checked that finalizable derived types could not be specified
in a submodule. I have replaced the original test with a test of the patch.
Thanks also to Malcolm Cohen for guidance on this.
OK for trunk?
Paul
Fortran: Allow declaration of finalizable DT in a submodule [PR97122]
2023-05-09 Paul Thomas
Steven G. Kargl
gcc/fortran
PR fortran/97122
* decl.cc (variable_decl): Clean up white space issues.
(gfc_match_final_decl): Declaration of finalizable derived type
is allowed in a submodule.
gcc/testsuite/
PR fortran/97122
* gfortran.dg/finalize_8.f03 : Replace testcase that checks
declaration of finalizable derived types in submodules works.
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 233bf244d62..6d6ce0854de 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2698,7 +2698,7 @@ variable_decl (int elem)
}
gfc_seen_div0 = false;
-
+
/* F2018:C830 (R816) An explicit-shape-spec whose bounds are not
constant expressions shall appear only in a subprogram, derived
type definition, BLOCK construct, or interface body. */
@@ -2769,7 +2769,7 @@ variable_decl (int elem)
if (e->expr_type != EXPR_CONSTANT)
{
n = gfc_copy_expr (e);
- if (!gfc_simplify_expr (n, 1) && gfc_seen_div0)
+ if (!gfc_simplify_expr (n, 1) && gfc_seen_div0)
{
m = MATCH_ERROR;
goto cleanup;
@@ -2784,12 +2784,12 @@ variable_decl (int elem)
if (e->expr_type != EXPR_CONSTANT)
{
n = gfc_copy_expr (e);
- if (!gfc_simplify_expr (n, 1) && gfc_seen_div0)
+ if (!gfc_simplify_expr (n, 1) && gfc_seen_div0)
{
m = MATCH_ERROR;
goto cleanup;
}
-
+
if (n->expr_type == EXPR_CONSTANT)
gfc_replace_expr (e, n);
else
@@ -11637,8 +11637,9 @@ gfc_match_final_decl (void)
block = gfc_state_stack->previous->sym;
gcc_assert (block);
- if (!gfc_state_stack->previous || !gfc_state_stack->previous->previous
- || gfc_state_stack->previous->previous->state != COMP_MODULE)
+ if (gfc_state_stack->previous->previous
+ && gfc_state_stack->previous->previous->state != COMP_MODULE
+ && gfc_state_stack->previous->previous->state != COMP_SUBMODULE)
{
gfc_error ("Derived type declaration with FINAL at %C must be in the"
" specification part of a MODULE");
diff --git a/gcc/testsuite/gfortran.dg/finalize_8.f03 b/gcc/testsuite/gfortran.dg/finalize_8.f03
index b2027a0ba6d..b7fa10dda31 100644
--- a/gcc/testsuite/gfortran.dg/finalize_8.f03
+++ b/gcc/testsuite/gfortran.dg/finalize_8.f03
@@ -1,35 +1,49 @@
-! { dg-do compile }
-
-! Parsing of finalizer procedure definitions.
-! Check that FINAL-declarations are only allowed on types defined in the
-! specification part of a module.
-
-MODULE final_type
+! { dg-do run }
+!
+! PR97122: Declaration of a finalizable derived type in a submodule
+! IS allowed.
+!
+! Contributed by Ian Harvey
+!
+MODULE m
IMPLICIT NONE
-CONTAINS
+ INTERFACE
+MODULE SUBROUTINE other(i)
+ IMPLICIT NONE
+ integer, intent(inout) :: i
+END SUBROUTINE other
+ END INTERFACE
- SUBROUTINE bar
-IMPLICIT NONE
+ integer :: mi
-TYPE :: mytype
- INTEGER, ALLOCATABLE :: fooarr(:)
- REAL :: foobar
-CONTAINS
- FINAL :: myfinal ! { dg-error "in the specification part of a MODULE" }
-END TYPE mytype
-
- CONTAINS
+END MODULE m
-SUBROUTINE myfinal (el)
- TYPE(mytype) :: el
-END SUBROUTINE myfinal
+SUBMODULE (m) s
+ IMPLICIT NONE
- END SUBROUTINE bar
+ TYPE :: t
+integer :: i
+ CONTAINS
+FINAL :: final_t ! Used to be an error here
+ END TYPE t
-END MODULE final_type
+CONTAINS
-PROGRAM finalizer
- IMPLICIT NONE
- ! Do nothing here
-END PROGRAM finalizer
+ SUBROUTINE final_t(arg)
+TYPE(t), INTENT(INOUT) :: arg
+mi = -arg%i
+ END SUBROUTINE final_t
+
+ module subroutine other(i) ! 'ti' is finalized
+integer, intent(inout) :: i
+type(t) :: ti
+ti%i = i
+ END subroutine other
+END SUBMODULE s
+
+ use m
+ integer :: i = 42
+ call other(i)
+ if (mi .ne. -i) stop 1
+end
[Patch, fortran] PRs 105152, 100193, 87946, 103389, 104429 and 82774
Hi All,
As usual, I received a string of emails on retargeting for PRs for which I
was either responsible or was on the cc list. This time I decided to take a
look at them all, in order to reward the tireless efforts of Richi, Jakub
and Martin with some attention at least.
I have fixed the PRs in the title line: See the attached changelog, patch
and testcases.
OK for 14-branch?
Of the others:
PR100815 - fixed already for 12-branch on. Martin located the fix from
Tobias, for which thanks. It's quite large but has stood the test of time.
Should I backport to 11-branch?
PR103366 - fixed on 12-branch on. I closed it.
PR103715 - might be fixed but the report is for gcc with checking enabled.
I will give that a go.
PR103716 - a gimple problem with assumed shape characters. A TODO.
PR103931 - I couldn't reproduce the bug, which involves 'ambiguous c_ptr'.
To judge by the comments, it seems that this bug is a bit elusive.
PR65381 - Seems to be fixed for 12-branch on
PR82064 - Seems to be fixed.
PR83209 - Coarray allocation - seems to be fixed.
PR84244 - Coarray segfault. I have no acquaintance with the inner works of
coarrays and so don't think that I can fix this one.
PR87674 - Segfault in runtime with non-overridable proc-pointer. A TODO.
PR96087 - A module procedure problem. A TODO.
I have dejagnu-ified testcases for the already fixed PRs ready to go.
Should these be committed or do we assume that the fixes already provided
adequate tests?
Regards
Paul
! { dg-do compile }
!
! Contributed by Gerhard Steinmetz
!
program p
use iso_c_binding
type, bind(c) :: t
integer(c_int) :: a
end type
interface
function f(x) bind(c) result(z)
import :: c_int, t
type(t) :: x(:)
integer(c_int) :: z
end
end interface
class(*), allocatable :: y(:)
n = f(y) ! { dg-error "either an unlimited polymorphic or assumed type" }
end
! { dg-do compile }
!
! Contributed by Gerhard Steinmetz
!
module m
implicit none
type t
procedure(f), pointer, nopass :: g
end type
contains
function f()
character(:), allocatable :: f
f = 'abc'
end
subroutine s
type(t) :: z
z%g = 'x' ! { dg-error "is a procedure pointer" }
if ( z%g() /= 'abc' ) stop
end
end
program p
use m
implicit none
call s
end
! { dg-do run }
!
! Contributed by Gerhard Steinmetz
!
module m
type t
contains
generic :: h => g
procedure, private :: g
end type
contains
function g(x, y) result(z)
class(t), intent(in) :: x
real, intent(in) :: y(:, :)
real :: z(size(y, 2))
integer :: i
do i = 1, size(y, 2)
z(i) = i
end do
end
end
module m2
use m
type t2
class(t), allocatable :: u(:)
end type
end
use m2
type(t2) :: x
real :: y(1,5)
allocate (x%u(1))
if (any (int(f (x, y)) .ne. [1,2,3,4,5])) stop 1
deallocate (x%u)
contains
function f(x, y) result(z)
use m2
type(t2) :: x
real :: y(:, :)
real :: z(size(y, 2))
z = x%u(1)%h(y) ! Used to segfault here
end
end
! { dg-do run }
!
! Contributed by Gerhard Steinmetz
!
program p
type t
integer, allocatable :: a(:)
end type
type(t) :: y
y%a = [1,2]
call s((y))
if (any (y%a .ne. [3,4])) stop 1
contains
subroutine s(x)
class(*) :: x
select type (x)
type is (t)
x%a = x%a + 2
class default
stop 2
end select
end
end
! { dg-do run }
module m
type t
real :: r
contains
procedure :: op
procedure :: assign
generic :: operator(*) => op
generic :: assignment(=) => assign
end type
contains
function op (x, y)
class(t), allocatable :: op
class(t), intent(in) :: x
real, intent(in) :: y
allocate (op, source = t (x%r * y))
end
subroutine assign (z, x)
type(t), intent(in) :: x
class(t), intent(out) :: z
z%r = x%r
end
end
program p
use m
class(t), allocatable :: x
real :: y = 2
allocate (x, source = t (2.0))
x = x * y
if (int (x%r) .ne. 4) stop 1
if (allocated (x)) deallocate (x)
end
! { dg-do run }
!
! Contributed by Steve Kargl
!
program main
implicit none
type stuff
character(:), allocatable :: key
end type stuff
type(stuff) nonsense, total
nonsense = stuff('Xe')
total = stuff(nonsense%key) ! trim nonsense%key made this work
if (nonsense%key /= total%key) call abort
if (len(total%key) /= 2) call abort
end program main
Change.Logs
Description: Binary data
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index e9843e9549c..fa505ab7ed9 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -3312,6 +3312,16 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
}
}
+ if (UNLIMITED_POLY (a->expr)
+ && !(f->sym->ts.type == BT_ASSUMED || UNLIMITED_POLY (f->sym)))
+ {
+ gfc_error
Re: [Patch, fortran] PR109451 - ICE in gfc_conv_expr_descriptor with ASSOCIATE and substrings
Hi Harald,
The fix was trivial. An updated patch and testcase are attached.
Thanks
Paul
Fortran: Fix some deferred character problems in associate [PR109451]
2023-04-14 Paul Thomas
gcc/fortran
PR fortran/109451
* trans-array.cc (gfc_conv_expr_descriptor): Guard expression
character length backend decl before using it. Suppress the
assignment if lhs equals rhs.
* trans-io.cc (gfc_trans_transfer): Scalarize transfer of
associate variables pointing to a variable. Add comment.
* trans-stmt.cc (trans_associate_var): Remove requirement that
the character length be deferred before assigning the value
returned by gfc_conv_expr_descriptor. Also, guard the backend
decl before testing with VAR_P.
gcc/testsuite/
PR fortran/109451
* gfortran.dg/associate_61.f90 : New test
On Thu, 13 Apr 2023 at 07:18, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Harald,
>
> That's interesting - the string length '.q' is not set for either of the
> associate blocks. I'm onto it.
>
> Thanks
>
> Paul
>
>
> On Wed, 12 Apr 2023 at 20:26, Harald Anlauf wrote:
>
>> Hi Paul,
>>
>> On 4/12/23 17:25, Paul Richard Thomas via Gcc-patches wrote:
>> > Hi All,
>> >
>> > I think that the changelog says it all. OK for mainline?
>>
>> this looks almost fine, but still fails if one directly uses the
>> dummy argument as the ASSOCIATE target, as in:
>>
>> program p
>>implicit none
>>character(4) :: c(2) = ["abcd","efgh"]
>>call dcs0 (c)
>> ! call dcs0 (["abcd","efgh"])
>> contains
>>subroutine dcs0(a)
>> character(len=*), intent(in) :: a(:)
>> print *, size(a),len(a)
>> associate (q => a(:))
>>print *, size(q),len(q)
>> end associate
>> associate (q => a(:)(:))
>>print *, size(q),len(q)
>> end associate
>> return
>>end subroutine dcs0
>> end
>>
>> This prints e.g.
>>
>> 2 4
>> 2 0
>> 2 0
>>
>> (sometimes I also get junk values for the character length).
>>
>> Can you please have another look?
>>
>> Thanks,
>> Harald
>>
>>
>> > Paul
>> >
>> > Fortran: Fix some deferred character problems in associate [PR109451]
>> >
>> > 2023-04-07 Paul Thomas
>> >
>> > gcc/fortran
>> > PR fortran/109451
>> > * trans-array.cc (gfc_conv_expr_descriptor): Guard expression
>> > character length backend decl before using it. Suppress the
>> > assignment if lhs equals rhs.
>> > * trans-io.cc (gfc_trans_transfer): Scalarize transfer of
>> > associate variables pointing to a variable. Add comment.
>> >
>> >
>> > gcc/testsuite/
>> > PR fortran/109451
>> > * gfortran.dg/associate_61.f90 : New test
>>
>>
>
> --
> "If you can't explain it simply, you don't understand it well enough" -
> Albert Einstein
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index e1725808033..7c0bcfe5cbb 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -7934,8 +7934,12 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
else
tmp = se->string_length;
- if (expr->ts.deferred && VAR_P (expr->ts.u.cl->backend_decl))
- gfc_add_modify (>pre, expr->ts.u.cl->backend_decl, tmp);
+ if (expr->ts.deferred && expr->ts.u.cl->backend_decl
+ && VAR_P (expr->ts.u.cl->backend_decl))
+ {
+ if (expr->ts.u.cl->backend_decl != tmp)
+ gfc_add_modify (>pre, expr->ts.u.cl->backend_decl, tmp);
+ }
else
expr->ts.u.cl->backend_decl = tmp;
}
@@ -7998,7 +8002,13 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
}
}
}
-
+ if (expr->ts.type == BT_CHARACTER
+ && VAR_P (TYPE_SIZE_UNIT (gfc_get_element_type (TREE_TYPE (parm)
+ {
+ tree elem_len = TYPE_SIZE_UNIT (gfc_get_element_type (TREE_TYPE (parm)));
+ gfc_add_modify (, elem_len,
+ fold_convert (TREE_TYPE (elem_len), gfc_get_array_span (desc, expr)));
+ }
/* Set the span field. */
tmp = NULL_TREE;
if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (desc)))
diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc
index 9b54d2f0d31..67658769b9e 100644
--- a/gcc/fortran/trans-io.cc
+++ b/gcc/fortran/trans-io.cc
@@ -2620,9 +2620,13 @@ gfc_trans_transfer (gfc_code * code)
gcc_assert (ref && ref->typ
Re: [Patch, fortran] PR109451 - ICE in gfc_conv_expr_descriptor with ASSOCIATE and substrings
Hi Harald, That's interesting - the string length '.q' is not set for either of the associate blocks. I'm onto it. Thanks Paul On Wed, 12 Apr 2023 at 20:26, Harald Anlauf wrote: > Hi Paul, > > On 4/12/23 17:25, Paul Richard Thomas via Gcc-patches wrote: > > Hi All, > > > > I think that the changelog says it all. OK for mainline? > > this looks almost fine, but still fails if one directly uses the > dummy argument as the ASSOCIATE target, as in: > > program p >implicit none >character(4) :: c(2) = ["abcd","efgh"] >call dcs0 (c) > ! call dcs0 (["abcd","efgh"]) > contains >subroutine dcs0(a) > character(len=*), intent(in) :: a(:) > print *, size(a),len(a) > associate (q => a(:)) >print *, size(q),len(q) > end associate > associate (q => a(:)(:)) >print *, size(q),len(q) > end associate > return >end subroutine dcs0 > end > > This prints e.g. > > 2 4 > 2 0 > 2 0 > > (sometimes I also get junk values for the character length). > > Can you please have another look? > > Thanks, > Harald > > > > Paul > > > > Fortran: Fix some deferred character problems in associate [PR109451] > > > > 2023-04-07 Paul Thomas > > > > gcc/fortran > > PR fortran/109451 > > * trans-array.cc (gfc_conv_expr_descriptor): Guard expression > > character length backend decl before using it. Suppress the > > assignment if lhs equals rhs. > > * trans-io.cc (gfc_trans_transfer): Scalarize transfer of > > associate variables pointing to a variable. Add comment. > > > > > > gcc/testsuite/ > > PR fortran/109451 > > * gfortran.dg/associate_61.f90 : New test > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[Patch, fortran] PR109451 - ICE in gfc_conv_expr_descriptor with ASSOCIATE and substrings
Hi All,
I think that the changelog says it all. OK for mainline?
Paul
Fortran: Fix some deferred character problems in associate [PR109451]
2023-04-07 Paul Thomas
gcc/fortran
PR fortran/109451
* trans-array.cc (gfc_conv_expr_descriptor): Guard expression
character length backend decl before using it. Suppress the
assignment if lhs equals rhs.
* trans-io.cc (gfc_trans_transfer): Scalarize transfer of
associate variables pointing to a variable. Add comment.
gcc/testsuite/
PR fortran/109451
* gfortran.dg/associate_61.f90 : New test
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index e1725808033..3d90a02cdac 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -7934,8 +7934,12 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr)
else
tmp = se->string_length;
- if (expr->ts.deferred && VAR_P (expr->ts.u.cl->backend_decl))
- gfc_add_modify (>pre, expr->ts.u.cl->backend_decl, tmp);
+ if (expr->ts.deferred && expr->ts.u.cl->backend_decl
+ && VAR_P (expr->ts.u.cl->backend_decl))
+ {
+ if (expr->ts.u.cl->backend_decl != tmp)
+ gfc_add_modify (>pre, expr->ts.u.cl->backend_decl, tmp);
+ }
else
expr->ts.u.cl->backend_decl = tmp;
}
diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc
index 9b54d2f0d31..67658769b9e 100644
--- a/gcc/fortran/trans-io.cc
+++ b/gcc/fortran/trans-io.cc
@@ -2620,9 +2620,13 @@ gfc_trans_transfer (gfc_code * code)
gcc_assert (ref && ref->type == REF_ARRAY);
}
+ /* These expressions don't always have the dtype element length set
+ correctly, rendering them useless for array transfer. */
if (expr->ts.type != BT_CLASS
&& expr->expr_type == EXPR_VARIABLE
&& ((expr->symtree->n.sym->ts.type == BT_DERIVED && expr->ts.deferred)
+ || (expr->symtree->n.sym->assoc
+ && expr->symtree->n.sym->assoc->variable)
|| gfc_expr_attr (expr).pointer))
goto scalarize;
! { dg-do run }
! Test fixes for PR109451
! Contributed by Harald Anlauf
!
call dcs3(['abcd','efgh'])
contains
subroutine dcs3(a)
character(len=*), intent(in) :: a(:)
character(:), allocatable :: b(:)
b = a(:)
call test (b, a, 1)
associate (q => b(:))! no ICE but print repeated first element
call test (q, a, 2)
print *, q
end associate
associate (q => b(:)(:)) ! ICE
call test (q, a, 3)
associate (r => q(:)(1:3))
call test (r, a(:)(1:3), 4)
end associate
end associate
associate (q => b(:)(2:3))
call test (q, a(:)(2:3), 5)
end associate
end subroutine dcs3
subroutine test (x, y, i)
character(len=*), intent(in) :: x(:), y(:)
integer, intent(in) :: i
if (any (x .ne. y)) stop i
end subroutine test
end
! { dg-output " abcdefgh" }
Re: [PATCH] Fortran: fix functions with entry and pointer/allocatable result [PR104312]
Hi Harald, The patch looks good to me - OK for mainline. Thanks Paul On Tue, 11 Apr 2023 at 21:12, Harald Anlauf via Fortran wrote: > Dear all, > > the testcase in the PR by Gerhard exhibited a mis-treatment of > the function decl of the entry master if the function result > had a pointer attribute and the translation unit was compiled > with -ff2c. We actually should not use the peculiar special > treatment for default-real functions in that case, as -ff2c is > reserved for function results that can be expressed in Fortran77, > and POINTER was not allowed in that standard. Same for complex. > > Furthermore, it turned out that ALLOCATABLE function results > were not yet handled for functions with entries, even without > -ff2c. Adding support for this was straightforward. > > I also fixed a potential buffer overflow for a generated > internal symbol. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > Thanks, > Harald > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
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.
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
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
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] PR104272 - finalizer gets called during allocate
Hi Harald, Quite right - good spot. There was an 'else' that turned out to be unnecessary. Thanks Paul On Wed, 5 Apr 2023 at 19:50, Harald Anlauf wrote: > Hi Paul, > > On 4/5/23 08:53, Paul Richard Thomas via Gcc-patches wrote: > > Hi All, > > > > This is a first in my recent experience - a very old bug that produces > too > > many finalizations! It results from a bit of a fix up, where class > objects > > are allocated using the derived typespec, rather than a source or mold > > expression. This occurs upstream in resolve.cc, where the default > > initializer is assigned to expr3 but no means are provided to identify > what > > it is. The patch applies a signaling bit-field to the ext field of > > gfc_code, which then suppresses the deallocation of allocatable > components > > in the allocate expression. I have checked that this does not cause > memory > > leaks, even though the number of builtin_frees in class_result_8.f90 goes > > down by one. > > can you have a look again at the logic in the hunk touching > trans-stmt.cc (gfc_trans_allocate)? I haven't checked in detail, > but it seems possible that you get a stale tmp in the > gfc_prepend_expr_to_block if (code->ext.alloc.expr3_not_explicit == 0). > Wouldn't it make more sense to move this condition before the braces > as part of the overall condition? > > > OK for mainline? > > Otherwise this LGTM. > > Thanks for the patch! > > Harald > > > Paul > > > > Fortran: Fix and excess finalization during allocation [PR104272] > > > > 2023-04-04 Paul Thomas > > > > gcc/fortran > > PR fortran/104272 > > * gfortran.h : Add expr3_not_explicit bit field to gfc_code. > > * resolve.cc (resolve_allocate_expr): Set bit field when the > > default initializer is applied to expr3. > > * trans-stmt.cc (gfc_trans_allocate): If expr3_not_explicit is > > set, do not deallocate expr3. > > > > gcc/testsuite/ > > PR fortran/104272 > > * gfortran.dg/class_result_8.f90 : Number of builtin_frees down > > from 6 to 5 without memory leaks. > > * gfortran.dg/finalize_52.f90: New test > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[Patch, fortran] PR104272 - finalizer gets called during allocate
Hi All,
This is a first in my recent experience - a very old bug that produces too
many finalizations! It results from a bit of a fix up, where class objects
are allocated using the derived typespec, rather than a source or mold
expression. This occurs upstream in resolve.cc, where the default
initializer is assigned to expr3 but no means are provided to identify what
it is. The patch applies a signaling bit-field to the ext field of
gfc_code, which then suppresses the deallocation of allocatable components
in the allocate expression. I have checked that this does not cause memory
leaks, even though the number of builtin_frees in class_result_8.f90 goes
down by one.
OK for mainline?
Paul
Fortran: Fix and excess finalization during allocation [PR104272]
2023-04-04 Paul Thomas
gcc/fortran
PR fortran/104272
* gfortran.h : Add expr3_not_explicit bit field to gfc_code.
* resolve.cc (resolve_allocate_expr): Set bit field when the
default initializer is applied to expr3.
* trans-stmt.cc (gfc_trans_allocate): If expr3_not_explicit is
set, do not deallocate expr3.
gcc/testsuite/
PR fortran/104272
* gfortran.dg/class_result_8.f90 : Number of builtin_frees down
from 6 to 5 without memory leaks.
* gfortran.dg/finalize_52.f90: New test
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 9bab2c40ead..3efe6634908 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3005,6 +3005,8 @@ typedef struct gfc_code
/* Take the array specification from expr3 to allocate arrays
without an explicit array specification. */
unsigned arr_spec_from_expr3:1;
+ /* expr3 is not explicit */
+ unsigned expr3_not_explicit:1;
}
alloc;
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 1a03e458d99..ebe58d1d3b6 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -8072,6 +8072,7 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code, bool *array_alloc_wo_spec)
if (!t)
goto failure;
+ code->ext.alloc.expr3_not_explicit = 0;
if (e->ts.type == BT_CLASS && CLASS_DATA (e)->attr.dimension
&& !code->expr3 && code->ext.alloc.ts.type == BT_DERIVED)
{
@@ -8080,6 +8081,7 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code, bool *array_alloc_wo_spec)
when the allocated type is different from the declared type but
no SOURCE exists by setting expr3. */
code->expr3 = gfc_default_initializer (>ext.alloc.ts);
+ code->ext.alloc.expr3_not_explicit = 1;
}
else if (flag_coarray != GFC_FCOARRAY_LIB && e->ts.type == BT_DERIVED
&& e->ts.u.derived->from_intmod == INTMOD_ISO_FORTRAN_ENV
@@ -8087,6 +8089,7 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code, bool *array_alloc_wo_spec)
{
/* We have to zero initialize the integer variable. */
code->expr3 = gfc_get_int_expr (gfc_default_integer_kind, >where, 0);
+ code->ext.alloc.expr3_not_explicit = 1;
}
if (e->ts.type == BT_CLASS && !unlimited && !UNLIMITED_POLY (code->expr3))
diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index f78875455a5..0b03fd5ed2f 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -6465,8 +6465,10 @@ gfc_trans_allocate (gfc_code * code)
&& code->expr3->ts.u.derived->attr.alloc_comp
&& !code->expr3->must_finalize)
{
- tmp = gfc_deallocate_alloc_comp (code->expr3->ts.u.derived,
- expr3, code->expr3->rank);
+ /* Switch off finalization if expr3 is implicit. */
+ if (code->ext.alloc.expr3_not_explicit == 0)
+ tmp = gfc_deallocate_alloc_comp (code->expr3->ts.u.derived,
+ expr3, code->expr3->rank);
gfc_prepend_expr_to_block (, tmp);
}
diff --git a/gcc/testsuite/gfortran.dg/class_result_8.f90 b/gcc/testsuite/gfortran.dg/class_result_8.f90
index 573dd44daad..9a1fb2ba50f 100644
--- a/gcc/testsuite/gfortran.dg/class_result_8.f90
+++ b/gcc/testsuite/gfortran.dg/class_result_8.f90
@@ -37,5 +37,5 @@ program polymorphic_operators_memory_leaks
call assign_a_type (a, add_a_type(a,b))
print *, a%x
end
-! { dg-final { scan-tree-dump-times "builtin_free" 6 "original" } }
+! { dg-final { scan-tree-dump-times "builtin_free" 5 "original" } }
! { dg-final { scan-tree-dump-times "builtin_malloc" 7 "original" } }
! { dg-do run }
!
! Test the fix for PR104272 in which allocate caused an unwanted finalization
!
! Contributed by Kai Germaschewski
!
module solver_m
implicit none
type, abstract, public :: solver_base_t
end type solver_base_t
type, public, extends(solver_base_t) :: solver_gpu_t
complex, dimension(:), allocatable :: x
contains
final :: solver_gpu_final
end type solver_gpu_t
type, public, extends(solver_gpu_t) :: solver_sparse_gpu_t
contains
final :: solver_sparse_gpu_final
end type solver_sparse_gpu_t
integer :: final_counts = 0
contains
impure elemental subroutine solver_gpu_final(this)
type(solver_gpu_t), intent(INOUT) :: this
Re: [PATCH] Fortran: reject module variable as character length in PARAMETER [PR104349]
Hi Harald, OK for mainline. It is sufficiently small that, if there is any fallout in the next weeks, it can easily be reverted without great impact. Thanks for the patch. Paul On Mon, 3 Apr 2023 at 20:46, Harald Anlauf via Fortran wrote: > Dear all, > > the attached patch fixes an ICE-on-invalid for a PARAMETER expression > where the character length was a MODULE variable. The ICE seemed > strange, as we were catching related erroneous code for declarations in > programs or subroutines. Removing a seemingly bogus check of restricted > expressions is the simplest way to fix this. (We could also catch this > differently in decl.cc). > > Besides, this also fixes an accepts-invalid, see testcase. :-) > > Regtested on x86_64-pc-linux-gnu. OK for mainline (13) or rather wait? > > Thanks, > Harald > > -- "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
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
> > *
[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 @@
Re: [PATCH, commited] Fortran: remove dead code [PR104321]
Hi Harald, If you will excuse the British cultural reference, that's a Norwegian Blue alright! Good spot. OK for mainline. Thanks Paul On Sat, 25 Mar 2023 at 19:13, Harald Anlauf via Fortran wrote: > Dear all, > > I've committed the attached patch from the PR that removes > a dead code snippet, see discussion. > > Regtested originally by Tobias, and reconfirmed on > x86_64-pc-linux-gnu. > > Pushed as r13-6862-gb5fce899dbbd72 . > > Thanks, > Harald > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH] Fortran: reject MODULE PROCEDURE outside generic module interface [PR99036]
Hi Harald, This is good for trunk and for backporting. Thanks for the rapid fix. Paul On Mon, 20 Mar 2023 at 20:57, Harald Anlauf via Fortran wrote: > Dear all, > > the attached trivial patch catches a MODULE PROCEDURE outside of a > module interface before we run into an internal error. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > This PR is marked as an 11/12/13 regression, so this is a candidate > for backporting. > > Thanks, > Harald > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [patch, fortran, doc] Explicitly mention undefined overflow
Hi Thomas, Yes, that's fine for trunk. I wonder if it is worth being explicit that linear congruential pseudo-random number generators can and do fail at -O3? Thanks for the doc patches! Paul On Sun, 19 Mar 2023 at 08:32, Thomas Koenig via Fortran wrote: > Here's also an update on the docs to explicitly mention behavior > on overflow. > > Maybe this will reach another 0.05% of users... > > OK for trunk? > > Best regards > > Thomas > > gcc/fortran/ChangeLog: > > * gfortran.texi: Mention behavior on overflow. > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[Patch, fortran] PR87127 - External function not recognised from within an associate block
Hi All,
I committed this to 8-branch on 2019-04-24 but not to 9-branch. I have no
record of why I did this.
The patch now requires an additional line,
&& sym->ns->proc_name->attr.proc != PROC_MODULE
to prevent the error message in pr88376.f90 from changing to the less
helpful
Error: Specification function ‘n’ at (1) must be PURE
I propose to commit to mainline and backport to 12-branch unless there are
objections in the next 24 hours.
Cheers
Paul
Fortran: Recognise external function from within an associate block
that has not been declared as external [PR87127]
2023-03-19 Paul Thomas
gcc/fortran
PR fortran/87127
* resolve.cc (check_host_association): If an external function
is typed but not declared explicitly to be external, change the
old symbol from a variable to an external function.
gcc/testsuite/
PR fortran/87127
* gfortran.dg/external_procedures_4.f90: New test.
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index ba603b4c407..a947f908ece 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -6079,11 +6079,14 @@ resolve_procedure:
/* Checks to see that the correct symbol has been host associated.
- The only situation where this arises is that in which a twice
- contained function is parsed after the host association is made.
- Therefore, on detecting this, change the symbol in the expression
- and convert the array reference into an actual arglist if the old
- symbol is a variable. */
+ The only situations where this arises are:
+ (i) That in which a twice contained function is parsed after
+ the host association is made. On detecting this, change
+ the symbol in the expression and convert the array reference
+ into an actual arglist if the old symbol is a variable; or
+ (ii) That in which an external function is typed but not declared
+ explcitly to be external. Here, the old symbol is changed
+ from a variable to an external function. */
static bool
check_host_association (gfc_expr *e)
{
@@ -6185,6 +6188,27 @@ check_host_association (gfc_expr *e)
gfc_resolve_expr (e);
sym->refs++;
}
+ /* This case corresponds to a call, from a block or a contained
+ procedure, to an external function, which has not been declared
+ as being external in the main program but has been typed. */
+ else if (sym && old_sym != sym
+ && !e->ref
+ && sym->ts.type == BT_UNKNOWN
+ && old_sym->ts.type != BT_UNKNOWN
+ && sym->attr.flavor == FL_PROCEDURE
+ && old_sym->attr.flavor == FL_VARIABLE
+ && sym->ns->parent == old_sym->ns
+ && sym->ns->proc_name
+ && sym->ns->proc_name->attr.proc != PROC_MODULE
+ && (sym->ns->proc_name->attr.flavor == FL_LABEL
+ || sym->ns->proc_name->attr.flavor == FL_PROCEDURE))
+ {
+ old_sym->attr.flavor = FL_PROCEDURE;
+ old_sym->attr.external = 1;
+ old_sym->attr.function = 1;
+ old_sym->result = old_sym;
+ gfc_resolve_expr (e);
+ }
}
/* This might have changed! */
return e->expr_type == EXPR_FUNCTION;
! { dg-do run }
!
! Test the fix for PR87127 in which the references to exfunc cause
! the error "exfunc at (1) is not a function".
!
! Contributed by Gerhard Steinmetz
!
function exfunc(i)
implicit none
integer :: exfunc,i
exfunc = 2*i
end function
! contents of test.f90
program test
implicit none
integer :: exfunc,i
integer,parameter :: array(2)=[6,7]
associate(i=>array(2))! Original bug
if (exfunc(i) .ne. 2*i) stop 1
end associate
i = 99
call foo
contains
subroutine foo() ! Comment #3
if (exfunc(i) .ne. 2*i) stop 2
end subroutine foo
end program
Re: [patch, wwwdocs] Mention finalization
Hi Thomas, Thanks for that! I think that your one-liner says it all :-) There are three PRs left open that PR37336 depends on: PR65347: Is partially fixed. The F2003/8 feature of finalization of a structure constructor within an array constructor doesn't work. I wonder if a compile option -finalize-constructors might not be better than -std=f2003/8? PR84472: I need to investigate if it is fixed or not. It behaves like one of the other brands, which complains about a double free. The other brand does not have this problem. At one stage, I nulled pointer components before finalization of a function result but removed it because it is not required by the standard. It might well be a good idea, just on the grounds that smart-pointers and resource managers seem to be the main real-life use of finalization and pointer components loom large with them. PR91316: An impure final call is allowed within a pure procedure at the moment. Malcolm Cohen convinced me that this should be disallowed. If the finalization patch has survived a few weeks on mainline without causing problems, I am inclined to backport to 12-branch. Would that be acceptable to one and all? Cheers Paul On Sun, 19 Mar 2023 at 08:15, Thomas Koenig via Fortran wrote: > Hi, > > the sentence below seems a bit short for such a huge undertaking, > but I could not think of anything else to day. > > Tested with "tidy -e". > > OK for wwwdocs? > > Best regards > > Thomas > > > diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html > index c8d757b6..a4b71ffa 100644 > --- a/htdocs/gcc-13/changes.html > +++ b/htdocs/gcc-13/changes.html > @@ -373,7 +373,12 @@ a work-in-progress. > > > > - > +Fortran > + > + > +Finalization is now fully supported. > + > + > > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH] Fortran: fix ICE in check_charlen_present [PR108420]
Hi Harald, This is fine for mainline and for backporting if you feel so inclined. Thanks for the patch. Paul On Mon, 16 Jan 2023 at 21:12, Harald Anlauf via Fortran wrote: > Dear all, > > it appears that the fix for pr107874 uncovered a latent bug > for the case of arrays of type character and size zero when > passed to the intrinsics MERGE and SPREAD as SOURCE. In that > case, there is no constructor from which we could obtain > another character length. A reasonable solution seems to > retain the array's character length. > > Since I could not find a simple case where this fails, I've > added an assertion that we actually have a meaningful length. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > Thanks, > Harald > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [patch, fortran] Fix common subexpression elimination with IEEE rounding (PR108329)
Hi Thomas, Following your off-line explanation that the seemingly empty looking assembly line forces an effective reload from memory, all is now clear. OK for mainline and for backporting as you see fit. Thanks for the patch. Paul On Sat, 7 Jan 2023 at 15:46, Thomas Koenig via Fortran wrote: > Hello world, > > this patch fixes Fortran's handling of common subexpression elimination > across ieee_set_rouding_mode calls. It does so using a rather big > hammer, by issuing a memory barrier to force reload from memory > (and thus a recomputation). > > This is a rather big hammer, so if there are more elegant ways > to fix it, I am very much open to suggestions. > > If PR 34678 is fixed, then this solution can also be applied here. > > OK for trunk? How do you feel about a backport? > > Best regards > > Thomas > > Add memory barrier for calls to ieee_set_rounding_mode. > > gcc/fortran/ChangeLog: > > PR fortran/108329 > * trans-expr.cc (trans_memory_barrier): New functions. > (gfc_conv_procedure_call): Insert memory barrier for > ieee_set_rounding_mode. > > gcc/testsuite/ChangeLog: > > PR fortran/108329 > * gfortran.dg/rounding_4.f90: New test. -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH] Fortran: ICE on recursive derived types with allocatable components [PR107872]
Hi Harald, Thanks for doing that. My attention is elsewhere gfortran-wise. Good for mainline. Paul On Fri, 9 Dec 2022 at 21:27, Harald Anlauf via Fortran wrote: > Dear all, > > I am submitting the attached simple - and obvious - patch on > behalf of Paul. It prevents a resource exhaustion due to an > infinite loop, and has been regtested by multiple contributers, ;-) > at least on x86_64-pc-linux-gnu. > > I intend to commit it to mainline within 24 hours, unless > there are further comments. > > Thanks, > Harald > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH] Fortran: fix typo in documentation of intrinsic FLOOR [PR107870]
Hi Harald, You will, perhaps, rue having me back when you see the updated finalization patch :-) This time, I will be breaking it up into digestible chunks! I'll be posting in about one week. Regards Paul On Sun, 4 Dec 2022 at 19:40, Harald Anlauf wrote: > Hi Paul, > > thanks - and it is good to see that you are back! > > Harald > > Am 04.12.22 um 12:48 schrieb Paul Richard Thomas via Gcc-patches: > > Hi Harald, > > > > That's good to commit. > > > > Thanks for the patch. > > > > Paul > > > > > > > > On Sat, 3 Dec 2022 at 20:40, Harald Anlauf via Fortran < > fort...@gcc.gnu.org> > > wrote: > > > >> Dear all, > >> > >> here's a small documentation fix for the intrinsic FLOOR. > >> Besides that, I adjusted the description of the optional > >> KIND argument to Fortran intrinsics to conform to the F2018 > >> standard, which reads "scalar integer constant expression". > >> > >> Tested with "make dvi". > >> > >> OK for mainline? > >> > >> Thanks, > >> Harald > >> > >> > > > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH] Fortran: fix typo in documentation of intrinsic FLOOR [PR107870]
Hi Harald, That's good to commit. Thanks for the patch. Paul On Sat, 3 Dec 2022 at 20:40, Harald Anlauf via Fortran wrote: > Dear all, > > here's a small documentation fix for the intrinsic FLOOR. > Besides that, I adjusted the description of the optional > KIND argument to Fortran intrinsics to conform to the F2018 > standard, which reads "scalar integer constant expression". > > Tested with "make dvi". > > OK for mainline? > > Thanks, > Harald > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH] Fortran: error recovery handling invalid CLASS variable [PR107899]
Hi Harald, It looks good to me. OK to commit. Thanks Paul On Sat, 3 Dec 2022 at 18:27, Harald Anlauf via Fortran wrote: > Dear all, > > the attached obvious patch fixes a NULL pointer dereference > that occurs with an invalid CLASS argument to DEALLOCATE. > > Regtested on x86_64-pc-linux-gnu. > > Will commit soon unless there are comments. > > Thanks, > Harald > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH] Fortran: intrinsic MERGE shall use all its arguments [PR107874]
Hi Harald, It looks good to me. Thanks to you and Steve for the patch. Paul On Mon, 28 Nov 2022 at 20:05, Harald Anlauf via Fortran wrote: > Dear all, > > as reported, the Fortran standard requires all actual argument > expressions to be evaluated (e.g. F2018:15.5.3). > > There were two cases for intrinsic MERGE where we failed to do so: > > - non-constant mask; Steve provided the patch > > - constant scalar mask; we need to be careful to simplify only if > the argument on the "other" path is known to be constant so that > it does not have side-effects and can be immediately removed. > > The latter change needed a correction of a sub-test of testcase > merge_init_expr_2.f90, which should not have been simplified > the way the original author assumed. I decided to modify the > test in such way that simplification is valid and provides > the expect pattern. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > Thanks, > Harald > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH, v2] PR fortran/105184 - ICE in gfc_array_init_size, at fortran/trans-array.cc:5841
Hi Harald, It looks good to me - OK for mainline. Thanks Paul On Fri, 8 Apr 2022 at 21:45, Harald Anlauf via Fortran wrote: > Dear all, > > Am 06.04.22 um 22:30 schrieb Harald Anlauf via Fortran: > > Dear all, > > > > the logic for checking the allocate-coshape-spec in an ALLOCATE > > statement was sort of sideways, and allowed to pass invalid > > specifications to the code generation. > > > > The fix seems obvious (to me). > > after submitting the previous patch, I found another invalid case with > a missing lower bound which was still silently accepted. The attached > revised patch adds this check, improves the original error message to > actually point to the coarray specification, and renames the testcase > to align better with existing coarray testcases. > > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > (12 or wait for 13?). > > Regtested again with no new failures. OK for mainline? > > Thanks, > Harald > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch] Fortran: Fix CLASS handling in SIZEOF intrinsic
Hi Tobias, Thanks for the patch and the particularly comprehensive testcase. OK for mainline as far as I am concerned. Paul On Tue, 8 Mar 2022 at 20:06, Tobias Burnus wrote: > Fix SIZEOF handling. > > I have to admit that I do understand what the current code does, > but do not understand what the previous code did. However, it > still passes the testsuite - and also some code which did ICE > now compiles :-) > > While writing the testcase, I did find two issues: > * Passing a CLASS to TYPE(*),dimension(..) will have an >elem_len of the declared type and not of the dynamic type. >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104844 > * var%class_array(1,1)%array will have size(...) == 0 >instead of size(... % array). >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104845 > > OK for mainline? (Unless you want to hold off until GCC 13) > > Tobias > > - > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, > 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: > Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; > Registergericht München, HRB 106955 > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization
Hi Harald, I have run your modified version of finalize_38.f90, and now I see > that you can get a bloody head just from scratching too much... > > crayftn 12.0.2: > > 1, 3, 1 > It appears that Cray interpret a derived type constructor as being a function call and so "6 If a specification expression in a scoping unit references a function, the result is finalized before execution of the executable constructs in the scoping unit." A call to 'test' as the first statement might be useful to diagnose: call test(2, 0, [0,0], -10) > 2, 21, 0 > 21 is presumably the value left over from simple(21) but quite why it should happen in this order is not apparent to me. > 11, 3, 2 > I am mystified as to why the finalization of 'var' is not occurring because "1 When an intrinsic assignment statement is executed (10.2.1.3), if the variable is not an unallocated allocatable variable, it is finalized after evaluation of expr and before the definition of the variable." Note the double negative! 'var' has been allocated and should return 1 to 'scalar' > 12, 21, 1 > 21, 4, 3 > This is a residue of earlier differences in the final count. > 23, 21, 22 | 42, 43 > The value is inexplicable to me. 31, 6, 4 > 41, 7, 5 > 51, 9, 7 > 61, 10, 8 > 71, 13, 10 > 101, 2, 1 > One again, a function 'expr' finalization has been added after intrinsic assignment; ie. derived type constructor == function. > 102, 4, 3 > > 111, 3, 2 > 121, 4, 2 > 122, 0, 4 > 123, 5, 6 | 2*0 > >From the value of 'array', I would devine that the source in the allocation is being finalized as an array, whereas I would expect each invocation of 'simple' to generate a scalar final call. > 131, 5, 2 > 132, 0, 4 > 133, 7, 8 | 2*0 > The final count has increased by 1, as expected. The value of 'scalar' is stuck at 0, so the second line is explicable. The array value is explicable if the finalization is of 'expr' and that 'var' is not finalized or the finalization of 'var' is occuring after assignment; ie. wrong order. ***I notice from the code that even with the patch, gfortran is finalizing before evaluation of 'expr', which is incorrect. It should be after evaluation of 'expr' and before the assignment.*** 141, 6, 3 > Final count offset - OK 151, 10, 5 > The two extra calls come, I presume from the source in the allocation. Since the type is extended, we see two finalizations each for the allocation and the deallocation. 161, 16, 9 > I think that the extra two finalizations come from the evaluation of 'src' in 'constructor2'. 171, 18, 11 > Final count offset - OK 175, 0., 20. | 10., 20. > The value of 'rarray' is mystifying. Conclusions from Cray: (i) Determine if derived type constructors should be interpreted as function calls. (ii) The order of finalization in class array assignment needs to be checked and fixed if necessary. > > nagfor 7.0: > > 1 0 1 > "1 When an intrinsic assignment statement is executed (10.2.1.3), if the variable is not an unallocated allocatable variable, it is finalized after evaluation of expr and before the definition of the variable." So I think that NAG has this wrong, either because the timing is right and an unallocatable allocatable is being finalized or because the timing is wrong. 11 1 2 > 23 21 22 | 42 43 > It seems that the finalization is occurring after assignment. 71 9 10 > 72 11 99 > It seems that the finalization of the function 'expr' after assignment is not happening. 131 3 2 > 132 5 4 > I am not sure that I know where the extra final call is nor where the scalar value of 5 comes from. 141 4 3 > 151 6 5 > 161 10 9 > 171 12 11 > The above are OK since there is an offset in the final count, starting at 131. Conclusions from NAG: (i) Some minor nits but pretty close to my interpretation. Intel 2021.5.0: > > 131 3 2 > 132 0 4 > 133 5 6 | 0 0 > 141 4 3 > 151 7 5 > 152 3 0 > 153 0 0 | 1 3 > forrtl: severe (174): SIGSEGV, segmentation fault occurred > [...] > ifort (IFORT) 2021.1 Beta 20201112 manages to carry on to the end. 161 13 9 162 20 0 163 0 0 | 10 20 171 14 11 Conclusions on ifort: (i) The agreement between gfortran, with the patch applied, and ifort is strongest of all the other brands; (ii) The disagreements are all down to the treatment of the parent component of arrays of extended types: gfortran finalizes the parent component as an array, whereas ifort does a scalarization. I have a patch ready to do likewise. Overall conclusions: (i) Sort out whether or not derived type constructors are
Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization
Hi Harald,
Thanks for giving the patch a whirl.
> the parent components as an array. I strongly suspect that, from reading
> > 7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However,
> this
> > is another issue to come back to in the future.
>
> Could you specify which version of Intel you tried?
>
ifort (IFORT) 2021.1 Beta 20201112
>
> Testcase finalize_38.f90 fails for me with ifort 2021.5.0 with:
>
> 131
>
That's the point where the interpretation of the standard diverges. Ifort
uses the scalar finalization for the parent component, whereas gfortran
uses the rank 1. Thus the final count is different by one. I have a version
of the patch, where gfortran behaves in the same way as ifort.
> This test also fails with crayftn 11 & 12 and nagfor 7.0,
> but in a different place.
>
>
> (Also finalize_45.f90 fails with that version with something that
> looks like memory corruption, but that might be just a compiler bug.)
>
I take it 'that version' is of ifort? Mine does the same. I suspect that it
is one of the perils of using pointer components in such circumstances! You
will notice that I had to nullify pointer components when doing the copy.
>
> Thanks,
> Harald
>
Could you use the attached version of finalize_38.f90 with crayftn and NAG?
All the stop statements are replaced with prints. Ifort gives:
131 3 2
132 0 4
133 5 6 | 0 0
141 4 3
151 7 5
152 3 0
153 0 0 | 1 3
161 13 9
162 20 0
163 0 0 | 10 20
171 14 11
Best regards
Paul
! { dg-do run }
!
! Test finalization on intrinsic assignment (F2018 (7.5.6.3))
!
module testmode
implicit none
type :: simple
integer :: ind
contains
final :: destructor1, destructor2
end type simple
type, extends(simple) :: complicated
real :: rind
contains
final :: destructor3, destructor4
end type complicated
integer :: check_scalar
integer :: check_array(4)
real :: check_real
real :: check_rarray(4)
integer :: final_count = 0
contains
subroutine destructor1(self)
type(simple), intent(inout) :: self
check_scalar = self%ind
check_array = 0
final_count = final_count + 1
end subroutine destructor1
subroutine destructor2(self)
type(simple), intent(inout) :: self(:)
check_scalar = 0
check_array(1:size(self, 1)) = self%ind
final_count = final_count + 1
end subroutine destructor2
subroutine destructor3(self)
type(complicated), intent(inout) :: self
check_real = self%rind
check_array = 0.0
final_count = final_count + 1
end subroutine destructor3
subroutine destructor4(self)
type(complicated), intent(inout) :: self(:)
check_real = 0.0
check_rarray(1:size(self, 1)) = self%rind
final_count = final_count + 1
end subroutine destructor4
function constructor1(ind) result(res)
type(simple), allocatable :: res
integer, intent(in) :: ind
allocate (res, source = simple (ind))
end function constructor1
function constructor2(ind, rind) result(res)
class(simple), allocatable :: res(:)
integer, intent(in) :: ind(:)
real, intent(in), optional :: rind(:)
type(complicated), allocatable :: src(:)
integer :: sz
integer :: i
if (present (rind)) then
sz = min (size (ind, 1), size (rind, 1))
src = [(complicated (ind(i), rind(i)), i = 1, sz)]
allocate (res, source = src)
else
sz = size (ind, 1)
allocate (res, source = [(simple (ind(i)), i = 1, sz)])
end if
end function constructor2
subroutine test (cnt, scalar, array, off, rind, rarray)
integer :: cnt
integer :: scalar
integer :: array(:)
integer :: off
real, optional :: rind
real, optional :: rarray(:)
if (final_count .ne. cnt) print *, 1 + off, final_count, cnt
if (check_scalar .ne. scalar) print *, 2 + off, check_scalar, scalar
if (any (check_array(1:size (array, 1)) .ne. array)) print *, 3 + off, &
check_array(1:size (array, 1)), "|", array
if (present (rind)) then
if (check_real .ne. rind) print *, 4+off, check_real, rind
end if
if (present (rarray)) then
if (any (check_rarray(1:size (rarray, 1)) .ne. rarray)) print *, 5 + off, &
check_rarray(1:size (rarray, 1)), "|", rarray
end if
end subroutine test
end module testmode
program test_final
use testmode
implicit none
type(simple), allocatable :: MyType, MyType2
type(simple), allocatable :: MyTypeArray(:)
type(simple) :: ThyType = simple(21), ThyType2 = simple(22)
class(simple), allocatable :: MyClass
class(simple), allocatable ::
Re: [PATCH] PR fortran/104311 - [9/10/11/12 Regression] ICE out of memory since r9-6321-g4716603bf875ce
Hi Harald, Indeed, this is obvious, as you say. OK for the affected branches. Regards Paul On Tue, 1 Feb 2022 at 22:38, Harald Anlauf via Fortran wrote: > Dear Fortranners, > > a check in gfc_calculate_transfer_sizes had a bug in the logic: > it did not trigger for MOLD having a storage size zero when > arugment SIZE was present. The attached obvious patch fixes this. > > Regtested on x86_64-pc-linux-gnu. OK for mainline/11/10/9? > > Thanks, > Harald > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH] fortran: Unshare associate var charlen [PR104228]
Hi Harald and Mikael, This looks fine to me. OK for all the listed branches. Thanks for the patch Paul On Wed, 2 Feb 2022 at 20:20, Harald Anlauf via Fortran wrote: > Hi Mikael, > > Am 29.01.22 um 15:24 schrieb Mikael Morin: > > Hello, > > > > the attached patch is a fix for PR104228. > > Even if simple, I wouldn’t call it obvious, as it’s involving character > > length and associate, so I don’t mind some extra review eyes. > > I am probably not experienced enough to review this. Paul? > > Nevertheless, I looked at the commits that introduced the code > you touched. It appears that these did not cover, maybe even > avoid the current case where the associate target is not a dummy. > Your changes seem to make sense and fix the issue. > > > Tested on x86_64-pc-linux-gnu. Ok for master/11/10/9? > > OK, and thanks for the patch! > > Harald > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization
This patch has been an excessively long time in coming. Please accept my apologies for that. All but two of the PR37336 dependencies are fixed, The two exceptions are PRs 59694 and 65347. The former involves lack of finalization of an unreferenced entity declared in a block, which I am sure is trivial but I cannot see where the missing trigger is, and the latter involves finalization of function results within an array constructor, for which I will submit an additional patch shortly. PR104272 also remains, in which finalization is occurring during allocation. I fixed this in one place but it seems to have crept out in another :-) Beyond this patch and ones for the three lagging PRs above, a thorough tidy up and unification of finalization is needed. However, I will concentrate on functionality in the first instance. I have tried to interpret F2018 7.5.6.2 and 7.5.6.3 as well as possible. This is not always straightforward and has involved a lot of head scratching! I have used the Intel compiler as a litmus test for the outcomes. This was largely motivated by the observation that, in the user survey conducted by Steve Lionel, gfortran and ifort are often used together . Therefore, quite aside from wishing to comply with the standard as far as possible, it is more than reasonable that the two compilers comply. On application of this patch, only exception to this is the treatment of finalization of arrays of extended types, where the Intel takes "If the entity is of extended type and the parent type is finalizable, the parent component is finalized" such that the parent component is finalized one element at a time, whereas gfortran finalises the parent components as an array. I strongly suspect that, from reading 7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However, this is another issue to come back to in the future. The work centred on three areas: (i) Finalization on assignment: This was required because finalization of the lhs was occurring at the wrong time relative to evaluation of the rhs expression and was taking the finalization of entities with finalizable components in the wrong order. The changes in trans-array.cc (structure_alloc_comps) allow gfc_deallocate_alloc_comp_no_caf to occur without finalization so that it can be preceded by calls to the finalization wrapper. The other key change in this area is the addition of trans-expr.cc (gfc_assignment_finalizer_call), which manages the ordering of finalization and deallocation. (ii) Finalization of derived type function results. Previously, finalization was not occuring at all for derived type results but it did for class results. The former is now implemented in trans-expr.cc (finalize_function_result), into which the treatment of class finalization has been included. In order to handled complex expressions correctly, an extra block has been included in gfc_se and is initialized in gfc_init_se. This block accumulates the finalizations so that they can be added at the right time. It is the way in which I will fix PR65347 (I have already tested the principle). (iii) Minor fixes These include the changes in class.cc and the exclusion of artificial entities from finalization. There are some missing testcases (sorry Andrew and Sandro!), which might not be necessary because the broken/missing features are already fixed. The fact that the work correctly now is a strong indication that this is the case. Regtests OK on FC33/x86_64 - OK for mainline (and 11-branch)? Best regards Paul Fortran:Implement missing finalization features [PR37336] 2022-02-02 Paul Thomas gcc/fortran PR fortran/103854 * class.cc (has_finalizer_component): Do not return true for procedure pointer components. PR fortran/96122 * class.cc (finalize_component): Include the missing arguments in the call to the component's finalizer wrapper. PR fortran/37336 * class.cc (finalizer_insert_packed_call): Remove the redundant argument in the call to the final subroutine. * resolve.cc (resolve_where, gfc_resolve_where_code_in_forall, gfc_resolve_forall_body, gfc_resolve_code): Check that the op code is still EXEC_ASSIGN. If it is set lhs to must finalize. * trans-array.cc (structure_alloc_comps): Add boolean argument to suppress finalization and use it for calls from gfc_deallocate_alloc_comp_no_caf. Otherwise it defaults to false. Add a second, additional boolean argument to nullify pointer components and use it in gfc_copy_alloc_comp_del_ptrs. (gfc_alloc_allocatable_for_assignment): Suppress finalization by setting new arg in call to gfc_deallocate_alloc_comp_no_caf. (gfc_copy_alloc_comp_del_ptrs): New function. * trans-array.h : Add the new boolean argument to the prototype of gfc_deallocate_alloc_comp_no_caf with a default of false. Add prototype for gfc_copy_alloc_comp_del_ptrs. * trans-expr.cc (gfc_init_se): Initialize finalblock. (finalize_function_result): New function that finalizes function results in the correct order. (gfc_conv_procedure_call): Use
[Patch, fortran] PR64290 - [F03] No finalization at deallocation of LHS
Hi All,
Strictly speaking, the attached patch is branching out into a more
generalised attack on PR37336(Finalization) - [F03] Finish derived-type
finalization but most of it fixes PR64290.
I started work on this patch almost a year ago but had to drop it due
daytime work pressure and only picked it up again a couple of weeks back.
It is not, as yet, complete but I thought to post it in its present form
because stage 3 ended yesterday.
The main thrusts of the patch are:
(i) To correct the order taken by finalization and deallocation of
components for the lhs of assignments. This is done instead by a call to
Tobias' finalization wrapper, rather than performing finalization component
by component in structure_alloc_comps;
(ii) To add finalization of scalar derived type function results, again by
use of the finalization wrapper. This points to a problem that I haven't
yet managed to fix, F2018(7.5.6.3 para 5) "If an executable construct
references a nonpointer function, the result is finalized after execution
of the innermost executable construct containing the reference." I have
been struggling to avoid implementing this by introducing a finalization
block into gfc_se but have run out of ideas as to how to do it otherwise.
(eg. Try using a finalizable function as the actual argument of another
procedure.); and
(iii) Once (ii) is added, a segfault occurs if the derived type has
allocatable, finalizable components. (PR96122) This occurred because the
call to the component finalization wrapper was missing two arguments in the
call; most particularly 'byte_stride'.
There is still quite a lot to do to bring together common code chunks, fix
the ordering requirement of F2018 (7.5.6.3 para 5), add more testcases.
It's certainly not ready to be committed yet :-(
Regards
Paul
Fortran:Implement missing finalization features [PR64290]
2022-01-17 Paul Thomas
gcc/fortran
PR fortran/103854
* class.c (has_finalizer_component): Do not return true for
procedure pointer components.
PR fortran/96087
* class.c (finalize_component): Include the missing arguments
in the call to the component's finalizer wrapper.
PR fortran/64290
* resolve.c (resolve_where, gfc_resolve_where_code_in_forall,
gfc_resolve_forall_body, gfc_resolve_code): Check that the op
code is still EXEC_ASSIGN. If it is set lhs to must finalize.
* trans-array.c (structure_alloc_comps): Add boolean argument
to suppress finalization and use it for calls from
gfc_deallocate_alloc_comp_no_caf. Otherwise it defaults to
false.
(gfc_alloc_allocatable_for_assignment): Suppress finalization
by setting new arg in call to gfc_deallocate_alloc_comp_no_caf.
* trans-array.h : Add the new boolean argument to the prototype
of gfc_deallocate_alloc_comp_no_caf with a default of false.
* trans-expr.c (gfc_conv_procedure_call): Call finalizer for
finalizable scalar function results.
(gfc_trans_scalar_assign): Suppress finalization by setting new
argument in call to gfc_deallocate_alloc_comp_no_caf.
(gfc_assignment_finalizer_call): New function to provide
finalization on intrinsic assignment.
(trans_class_assignment, gfc_trans_assignment_1): Call it and
add the block between the rhs evaluation and any reallocation
on assignment that there might be.
gcc/testsuite/
PR fortran/64290
* gfortran.dg/finalize_38.f90 : New test.
* gfortran.dg/allocate_with_source_25.f90 : The number of final
calls goes down from 6 to 4.
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 2cb0c6572bd..18289eaffe8 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -896,7 +896,8 @@ has_finalizer_component (gfc_symbol *derived)
gfc_component *c;
for (c = derived->components; c; c = c->next)
-if (c->ts.type == BT_DERIVED && !c->attr.pointer && !c->attr.allocatable)
+if (c->ts.type == BT_DERIVED && !c->attr.pointer && !c->attr.allocatable
+ && c->attr.flavor != FL_PROCEDURE)
{
if (c->ts.u.derived->f2k_derived
&& c->ts.u.derived->f2k_derived->finalizers)
@@ -1059,7 +1060,8 @@ finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp,
{
/* Call FINAL_WRAPPER (comp); */
gfc_code *final_wrap;
- gfc_symbol *vtab;
+ gfc_symbol *vtab, *byte_stride;
+ gfc_expr *scalar, *size_expr, *fini_coarray_expr;
gfc_component *c;
vtab = gfc_find_derived_vtab (comp->ts.u.derived);
@@ -1068,12 +1070,54 @@ finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp,
break;
gcc_assert (c);
+
+ /* Set scalar argument for storage_size. */
+ gfc_get_symbol ("comp_byte_stride", sub_ns, _stride);
+ byte_stride->ts = e->ts;
+ byte_stride->attr.flavor = FL_VARIABLE;
+ byte_stride->attr.value = 1;
+ byte_stride->attr.artificial = 1;
+ gfc_set_sym_referenced (byte_stride);
+ gfc_commit_symbol (byte_stride);
+ scalar = gfc_lval_expr_from_sym (byte_stride);
+
final_wrap = gfc_get_code (EXEC_CALL);
final_wrap->symtree =
[Patch, fortran] PR103366 - [9/10/11/12 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:5647
I doubt that this is a regression on 9-11 branches since the testcase
compiles correctly on each of my copies of these branches. IMHO it is
rather more likely to have been caused by
64f9623765da3306b0ab6a47997dc5d62c2ea261, which introduced this new form of
gfc_conv_gfc_desc_to_cfi_desc.
The patch is self-explanatory. OK for mainline?
Paul
Fortran: Match unlimited polymorphic argument to assumed type [PR103366].
2022-01-07 Paul Thomas
gcc/fortran
PR fortran/103366
* trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Allow unlimited
polymorphic actual argument passed to assumed type formal.
gcc/testsuite/
PR fortran/103366
* gfortran.dg/pr103366.f90: New test.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 381915e2a76..2e15a7e874c 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -50,10 +50,10 @@ static tree
gfc_get_character_len (tree type)
{
tree len;
-
+
gcc_assert (type && TREE_CODE (type) == ARRAY_TYPE
&& TYPE_STRING_FLAG (type));
-
+
len = TYPE_MAX_VALUE (TYPE_DOMAIN (type));
len = (len) ? (len) : (integer_zero_node);
return fold_convert (gfc_charlen_type_node, len);
@@ -67,10 +67,10 @@ tree
gfc_get_character_len_in_bytes (tree type)
{
tree tmp, len;
-
+
gcc_assert (type && TREE_CODE (type) == ARRAY_TYPE
&& TYPE_STRING_FLAG (type));
-
+
tmp = TYPE_SIZE_UNIT (TREE_TYPE (type));
tmp = (tmp && !integer_zerop (tmp))
? (fold_convert (gfc_charlen_type_node, tmp)) : (NULL_TREE);
@@ -5630,6 +5630,16 @@ gfc_conv_gfc_desc_to_cfi_desc (gfc_se *parmse, gfc_expr *e, gfc_symbol *fsym)
itype = CFI_type_other; // FIXME: Or CFI_type_cptr ?
break;
case BT_CLASS:
+ if (UNLIMITED_POLY (e) && fsym->ts.type == BT_ASSUMED)
+ {
+ // F2017: 7.3.2.2: "An entity that is declared using the TYPE(*)
+ // type specifier is assumed-type and is an unlimited polymorphic
+ // entity." The actual argument _data component is passed.
+ itype = CFI_type_other; // FIXME: Or CFI_type_cptr ?
+ break;
+ }
+ else
+ gcc_unreachable ();
case BT_PROCEDURE:
case BT_HOLLERITH:
case BT_UNION:
! { dg-do compile }
!
! Test the fix for PR103366.
!
! Contributed by Gerhardt Steinmetz
!
program p
call u([1])
contains
subroutine s(x) bind(c)
type(*) :: x(..)
end
subroutine u(x)
class(*) :: x(..)
call s(x) ! Used to ICE here
end
end
Re: [PATCH] Fortran: Fix ICE caused by missing error for untyped symbol [PR103258]
Hi Sandra, That's a good shout to query suppress_errors. The patch is OK by me. Thanks Paul On Wed, 5 Jan 2022 at 03:21, Sandra Loosemore wrote: > This patch fixes an ICE that appeared after I checked in my patch for > PR101337 back in November, which made the resolve phase try harder to > check all operands/arguments for errors instead of giving up after the > first one, but it's actually a bug that existed before that and was only > revealed by that earlier patch. > > The problem is that the parse phase is doing early resolution to try to > constant-fold a character length expression. It's throwing away the > error(s) if it fails, but in the test case for this issue it was leaving > behind some state indicating that the error had already been diagnosed > so it wasn't getting caught again during the "real" resolution phase > either. > > Every bit of code touched by this seems kind of hacky to me -- the > different mechanisms for suppressing/ignoring errors, the magic bit in > the symbol attributes, the part that tries to constant-fold an > expression that might not actually be a constant, etc. But, this is the > least hacky fix I could come up with. :-P It fixes the test case from > the issue and does not cause any regressions elsewhere in the gfortran > testsuite. > > OK to check in? > > -Sandra > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH] PR fortran/102332 - ICE in select_type_set_tmp, at fortran/match.c:6366
Hi Harald, That is the sort of thing that I had in mind. Is it worth adding the check for CLASS_DATA? I cannot remember if that is made redundant by the test of the class_ok attribute. Cheers Paul On Tue, 28 Dec 2021 at 21:08, Harald Anlauf wrote: > Hi Paul, > > Am 28.12.21 um 12:56 schrieb Paul Richard Thomas via Fortran: > > Hi Harald, > > > > This looks good to me. OK for mainline and, dare I suggest, 11-branch? > > > > From a quick run through resolve.c, there are many places where the > extra > > checks that you introduced in the patch have been implemented. This makes > > me wonder whether a function or macro might not make the relevant code > more > > concise. > > I had thought about this in the past, too. Suitably chosen macros > could help to make checking not only more concise, but also more > robust and (hopefully) readable at the same time. > > What do you think about e.g. > > > diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h > index e5d2dd7971e..f3d22b46a75 100644 > --- a/gcc/fortran/gfortran.h > +++ b/gcc/fortran/gfortran.h > @@ -3885,6 +3885,8 @@ bool gfc_is_finalizable (gfc_symbol *, gfc_expr **); > && CLASS_DATA (sym) \ > && CLASS_DATA (sym)->attr.dimension \ > && !CLASS_DATA (sym)->attr.class_pointer) > +#define IS_CLASS_OBJ(sym) \ > + (sym->ts.type == BT_CLASS && sym->attr.class_ok) > > /* frontend-passes.c */ > > > to be used to ensure that we are dealing with a CLASS object where > attributes should already have been set up? Or use a better name? > (IS_CLASS_OBJECT?) > > Thanks, > Harald > > > Thanks for the patch > > > > Paul > > > > > > On Mon, 27 Dec 2021 at 22:17, Harald Anlauf via Fortran < > fort...@gcc.gnu.org> > > wrote: > > > >> Dear all, > >> > >> there are a couple of NULL pointer dereferences leading to improper > >> error recovery when trying to handle Gerhard's testcases involving > >> SELECT TYPE and invalid uses of CLASS variables. > >> > >> The fixes look pretty obvious to me, but I'm submitting here to > >> check if there is more that should be done here. > >> > >> (I was surprised to see that there are several different places > >> involved by rather simple variations in the basic test case.) > >> > >> Regtested on x86_64-pc-linux-gnu. OK for mainline? > >> > >> Thanks, > >> Harald > >> > >> > > > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH] PR fortran/102332 - ICE in select_type_set_tmp, at fortran/match.c:6366
Hi Harald, This looks good to me. OK for mainline and, dare I suggest, 11-branch? >From a quick run through resolve.c, there are many places where the extra checks that you introduced in the patch have been implemented. This makes me wonder whether a function or macro might not make the relevant code more concise. Thanks for the patch Paul On Mon, 27 Dec 2021 at 22:17, Harald Anlauf via Fortran wrote: > Dear all, > > there are a couple of NULL pointer dereferences leading to improper > error recovery when trying to handle Gerhard's testcases involving > SELECT TYPE and invalid uses of CLASS variables. > > The fixes look pretty obvious to me, but I'm submitting here to > check if there is more that should be done here. > > (I was surprised to see that there are several different places > involved by rather simple variations in the basic test case.) > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > Thanks, > Harald > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [committed] Fortran: Add more documentation for mixed-language programming
Hi Sandra, Looks good to me. Thanks Paul On Fri, 5 Nov 2021 at 21:13, Sandra Loosemore wrote: > I was recently pinged about PR35276. It's an old issue, but a couple of > the concerns raised there haven't been fixed yet, so I've checked in > this patch to fill in the gaps. > > -Sandra > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: José's pending bind(C) patches / status (was: Re: [Patch, fortran V3] PR fortran/100683 - Array initialization refuses valid)
Hi Tobias, My disappearance is partly responsible for the backlog. I told José that I would start working on it some months since but just have not had the time. I can do some of the reviews but still do not have much time to spare. Perhaps you could divide them up between us. Andrew Benson has been working on some standards issues associated with a patch of mine that sorts out finalization for intrinsic assignment - PR64290. The main issue was that of finalization of finalizable types/classes that themselves have finalizable array components. I believe that the patch has it right, following a comparison between the (differing!) behaviour of other brands. We have also found a case where gfortran, with the patch applied, that still does not finalize when it should. I will work up a fix for this and will coordinate with Andrew to produce testcases as necessary, well before 15th November. Best regards Paul On Fri, 22 Oct 2021 at 08:42, Tobias Burnus wrote: > Hi José, hi all, > > especially since my patch which moved the descriptor conversion from > libgfortran to gfortran is in, I wonder whether there are still patches > to be applied and useful testcases; I assume there are more issues in > Bugzilla, especially as I filled myself some (often related to > polymorphism or assumed rank). While I (and also Sandra) try to resolve > some bugs and look at testcases: > > it would be helpful if others – in particular José – could check > whether: (a) PRs can be now closed, (b) testcases exist which still > should be added, (c) patches exist which still are applicable (even if > they need to be revised). (Partial/full list below.) > > I hope that we can really cleanup this backlog – and possibly fix also > some of the remaining bugs before GCC 12 is released! > > And kudos to José for the bug reports, testcases and patches – and sorry > for slow reviews. I hope we resolve the pending issues and be quicker in > future. > > Tobias > > PS: Old and probably current but incomplete pending patch list: > > On 21.06.21 17:21, José Rui Faustino de Sousa wrote: > > On 21/06/21 12:37, Tobias Burnus wrote: > >> Thus: Do you have a list of patches pending review? > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056168.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056167.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056163.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056162.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056155.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056154.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056152.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056159.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055982.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-June/056169.html > > > > https://gcc.gnu.org/pipermail/fortran/2021-April/055921.html > > > > I am not 100% sure this is all of them but it should be most. > - > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, > 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: > Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; > Registergericht München, HRB 106955 > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch] Fortran: Fix CLASS conversion check [PR102745]
Hi Tobias, This is OK for mainline and as far back in the branches as you feel inclined to go. Thanks for the patch. Paul On Fri, 15 Oct 2021 at 22:19, Tobias Burnus wrote: > This patch fixes two issues: > > First, to print 'CLASS(t2)' instead of: > Error: Type mismatch in argument ‘x’ at (1); passed > CLASS(__class_MAIN___T2_a) to TYPE(t) > > Additionally, > >class(t2) = class(t) ! 't2' extends 't' >class(t2) = class(any) > > was wrongly accepted. > > OK? > > Tobias > - > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, > 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: > Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; > Registergericht München, HRB 106955 > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch] [v3] Fortran: Fix Bind(C) Array-Descriptor Conversion (Move to Front-End Code)
Hi Tobias,
I can only echo Harald's comment that this is an impressive bit of work.
I spent some time messing with fc-descriptor-7.f90/gc-descriptor-7-c.cc
because it kept failing on me. This came about because I missed one of the
chunks not applying in the C component of the test; namely:
for (int j = 0; j < 5; ++j)
for (int i = 0; i < 10; ++i)
{
subscripts[0] = j; subscripts[1] = i;
if (*(int *) CFI_address (a, subscripts) != (i+1) + 100*(j+1))
abort ();
}
This set me to wondering whether or not the user should be aware that the
result of the transpose intrinsic being passed in this way should not
generate a warning that the CFI API must be used in this case and not to
depend on the data being transposed?
Apart from this I have no other comments, still less corrections :-)
Many thanks for the patch - OK for mainline.
Paul
On Wed, 13 Oct 2021 at 21:11, Harald Anlauf wrote:
> Hi Tobias,
>
> Am 13.10.21 um 18:01 schrieb Tobias Burnus:
> > Dear all,
> >
> > a minor update [→ v3].
>
> this has become an impressive work.
>
> > I searched for XFAIL in Sandra's c-interop/ and found
> > two remaining true** xfails, now fixed:
> >
> > - gfortran.dg/c-interop/typecodes-scalar-basic.f90
> >The conversion of scalars of type(c_ptr) was mishandled;
> >fixed now; the fix did run into issues converting a string_cst,
> >which has also been fixed.
> >
> > - gfortran.dg/c-interop/fc-descriptor-7.f90
> >this one uses TRANSPOSE which did not work [now mostly* does]
> >→ PR fortran/101309 now also fixed.
> >
> > I forgot what the exact issue for the latter was. However, when
> > looking at the testcase and extending it, I did run into the
> > following issue - and at the end the testcase does now pass.
> > The issue I had was that when a contiguous check was requested
> > (i.e. only copy in when needed) it failed to work, when
> > parmse->expr was (a pointer to) a descriptor. I fixed that and
> > now most* things work.
> >
> > OK for mainline? Comments? Suggestions? More PRs which fixes
> > this patch? Regressions? Test results?
>
> Doesn't break my own codes so far.
>
> If nobody else responds within the next days, assume an OK
> from my side.
>
> This will also provide Gerhard with a new playground. ;-)
>
> Thanks for the patch!
>
> Harald
>
> > Tobias
> >
> > PS: I intent to commit this patch to the OG11 (devel/omp/gcc-11)
> > branch, in case someone wants to test it there.
> >
> > PPS: Nice to have an extensive testcase suite - kudos to Sandra
> > in this case. I am sure Gerald will find more issues and once
> > it is in, I think I/we have to check some PRs + José's patches
> > whether for additional testcases + follow-up fixes.
> >
> > (*) I write most as passing a (potentially) noncontiguous
> > assumed-rank array to a CONTIGUOUS assumed-rank array causes
> > an ICE as the scalarizer does not handle dynamic ranks alias
> > expr->rank == -1 / ss->dimen = -1.
> > I decided that that's a separate issue and filled:
> > https://gcc.gnu.org/PR102729
> > BTW, my impression is that fixing that PR might fix will solve
> > the trans*.c part of https://gcc.gnu.org/PR102641 - but I have
> > not investigated.
> >
> > (**) There are still some 'xfail' in comments (outside dg-*)
> > whose tests now pass. And those where for two bugs in the same
> > statement, only one is reported - and the other only after fixing
> > the first one, which is fine.
> >
> > On 09.10.21 23:48, Tobias Burnus wrote:
> >> Hi all,
> >>
> >> attached is the updated version. Changes:
> >> * Handle noncontiguous arrays – with BIND(C), (g)Fortran needs to make
> it
> >> contiguous in the caller but also handle noncontiguous in the callee.
> >> * Fixes/handle 'character(len=*)' with BIND(C); those always use an
> >> array descriptor - also with explicit-size and assumed-size arrays
> >> * Fixed a bunch of bugs, found when writing extensive testcases.
> >> * Fixed type(*) handling - those now pass properly type and elem_len
> >> on when calling a new function (bind(C) or not).
> >>
> >> Besides adding the type itself (which is rather straight forward),
> >> this patch only had minor modifications – and then the two big
> >> conversion functions.
> >>
> >> While it looks intimidating, it should be comparably simple to
> >> review as everything is on one place and hopefully sufficiently
> >> well documented.
> >>
> >> OK – for mainline? Other comments? More PRs which are fixed?
> >> Issues not yet fixed (which are inside the scope of this patch)?
> >>
> >> (If this patch is too long, I also have a nine-day old pending patch
> >> at https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580624.html )
> >>
> >> Tobias
> >>
> >> PS: The following still applies.
> >>
> >> On 06.09.21 12:52, Tobias Burnus wrote:
> >>> gfortran's internal array descriptor (xgfc descriptor) and
> >>> the descriptor used with BIND(C) (CFI descriptor, ISO_Fortran_binding.h
> >>> of TS29113 / Fortran 2018) are
Re: *PING**2 – Re: [Patch] Fortran: Fix Bind(C) char-len check, add ptr-contiguous check
Hi Tobias, s/However, as argument they are also iteroperable/However, as an argument they are also interoperable/ s/ /* else: valid only sind F2018 - and an assumed-shape/rank array; however, gfc_notify_std is already called when those array type are used. Thus, silently accept F200x. */ / /* else: valid only since F2018 - and an assumed-shape/rank array; however, gfc_notify_std is already called when those array types are used. Thus, silently accept F200x. */ Apart from those nits, it looks good to me. It even regtests OK :-) Thanks for sorting out the standard-ese. OK for mainline and, I would suggest 11-branch. Cheers Paul On Sun, 29 Aug 2021 at 08:35, Tobias Burnus wrote: > PING**2 > > On 25.08.21 20:58, Tobias Burnus wrote: > > Early *PING*. > > (I also should still review several Fortan patches... There are lots of > > patches waiting for review :-/) > > > > On 20.08.21 19:24, Tobias Burnus wrote: > >> The following is about interoperability (BIND(C)) only. > >> > >> > >> * The patch adds a missing check for pointer + contiguous. > >> (Rejected to avoid copy-in issues? Or checking issues?) > >> > >> > >> * And it corrects an issue regarding len > 1 characters. While > >> > >> subroutine foo(x) > >> character(len=2) :: x(*) > >> > >> is valid Fortran code (the argument can be "abce" or ['a','b','c','d'] > >> or ...) > >> – and would work also with bind(C) as the len=2 does not need to be > >> passed > >> as hidden argument as len is a constant. > >> However, it is not valid nonetheless. > >> > >> > >> OK? Comments? > >> > >> Tobias > >> > >> > >> PS: Referenced locations in the standard (F2018): > >> > >> C1554 If proc-language-binding-spec is specified for a procedure, > >> each of its dummy arguments shall be an interoperable procedure (18.3.6) > >> or a variable that is interoperable (18.3.4, 18.3.5), assumed-shape, > >> assumed-rank, assumed-type, of type CHARACTER with assumed length, > >> or that has the ALLOCATABLE or POINTER attribute. > >> > >> 18.3.1: "... If the type is character, the length type parameter is > >> interoperable if and only if its value is one. ..." > >> > >> "18.3.4 Interoperability of scalar variables": > >> "... A named scalar Fortran variable is interoperable ... if it > >> is of type character12its length is not assumed or declared by > >> an expression that is not a constant expression." > >> > >> 18.3.5: Likewise but for arrays. > >> > >> 18.3.6 "... Fortran procedure interface is interoperable with a C > >> function prototype ..." > >> "(5) any dummy argument without the VALUE attribute corresponds > >> to a formal parameter of the prototype that is of a pointer type, > >> and either > >> • the dummy argument is interoperable with an entity of the > >> referenced type ..." > >> (Remark: those are passed as byte stream) > >> "• the dummy argument is a nonallocatable nonpointer variable of > >> type > >> CHARACTER with assumed character length and the formal > >> parameter is > >> a pointer to CFI_cdesc_t, > >> • the dummy argument is allocatable, assumed-shape, > >> assumed-rank, or > >> a pointer without the CONTIGUOUS attribute, and the formal > >> parameter > >> is a pointer to CFI_cdesc_t, or > >> (Remark: those two use an array descriptor, also for > >> explicit-size/assumed-size > >> arrays or for scalars.) > >> • the dummy argument is assumed-type ..." > >> > > - > > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße > > 201, 80634 München; Gesellschaft mit beschränkter Haftung; > > Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: > > München; Registergericht München, HRB 106955 > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH] PR fortran/87737 - ICE tree check: expected ssa_name, have addr_expr in remap_gimple_op_r, at tree-inline.c:923
Hi Harald, It looks good to me. OK for mainline. You might even consider backporting to 11-branch. Best regards Paul On Fri, 27 Aug 2021 at 21:15, Harald Anlauf via Fortran wrote: > Dear all, > > the ICE in the original testcase does no longer occur but leads to an > error in a later stage of compilation, and we accepted invalid code. > (Cross-checked with other compilers, such as Intel and NAG). > > F2018 states: > > 15.6.2.6 ENTRY statement > > (3) ... If the characteristics of the result of the function named in the > ENTRY statement are the same as the characteristics of the result of the > function named in the FUNCTION statement, their result names identify the > same > entity, although their names need not be the same. Otherwise, they are > storage > associated and shall all be nonpointer, nonallocatable scalar variables > that > are default integer, default real, double precision real, default complex, > or > default logical. > > We thus better reject the testcase example during resolution with an > appropriate error message. (I hope the chosen one is fine enough.) > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > Thanks, > Harald > > > Fortran - reject function entries with mismatched characteristics > > gcc/fortran/ChangeLog: > > PR fortran/87737 > * resolve.c (resolve_entries): For functions of type CHARACTER > tighten the checks for matching characteristics. > > gcc/testsuite/ChangeLog: > > PR fortran/87737 > * gfortran.dg/entry_24.f90: New test. > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: PING [PATCH] PR fortran/99839 - [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
Hi Harald, Looks good to me - OK for as many branches as you have sufficient fortitude for. Regards Paul On Thu, 3 Jun 2021 at 21:22, Harald Anlauf via Fortran wrote: > *PING* > > > Gesendet: Donnerstag, 27. Mai 2021 um 22:20 Uhr > > Von: "Harald Anlauf" > > An: "fortran" , "gcc-patches" < > gcc-patches@gcc.gnu.org> > > Betreff: [PATCH] PR fortran/99839 - [9/10/11/12 Regression] ICE in > inline_matmul_assign, at fortran/frontend-passes.c:4234 > > > > Dear Fortranners, > > > > frontend optimization tries to inline matmul, but then it also needs > > to take care of the assignment to the result array. If that one is > > not of canonical type, we currently get an ICE. The straightforward > > solution is to simply punt in those cases and avoid inlining. > > > > Regtested on x86_64-pc-linux-gnu. > > > > OK for mainline? Backport to affected branches? > > > > Thanks, > > Harald > > > > > > Fortran - ICE in inline_matmul_assign > > > > Restrict inlining of matmul to those cases where assignment to the > > result array does not need special treatment. > > > > gcc/fortran/ChangeLog: > > > > PR fortran/99839 > > * frontend-passes.c (inline_matmul_assign): Do not inline matmul > > if the assignment to the resulting array if it is not of canonical > > type (real/integer/complex/logical). > > > > gcc/testsuite/ChangeLog: > > > > PR fortran/99839 > > * gfortran.dg/inline_matmul_25.f90: New test. > > > > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch, fortran] PR fortran/100120/100816/100818/100819/100821 problems raised by aggregate data types
Hi José, I can second Dominique's thanks. I applied it to my tree when you first posted, set the regtest in motion and have not been able to return to gfortran matters since. OK for master. I am especially happy that you have tackled this area and have rationalised it to a substantial degree. The wheel keeps being re-invented by different people, largely for a lack of documentation or coherent self-documentation. I know, as one of the guilty ones. Regards Paul On Thu, 3 Jun 2021 at 16:05, dhumieres.dominique--- via Fortran < fort...@gcc.gnu.org> wrote: > Hi José, > > > Patch tested only on x86_64-pc-linux-gnu. > > Also tested on darwin20. The patch is OK for me. > > Thanks for the work, > > Dominique > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH] PR fortran/100551 - [11/12 Regression] Passing return value to class(*) dummy argument
Hi Harald, I meant to deal with this myself since I am the guilty party. However, the last two weeks have been taken up by a house move and so gfortran has been on the backburner. The patch looks good and seems to do the job - OK for master and 11-branch. Thanks a million for dealing with it! Paul PS If I walk 200m I can now see the "dreaming spires" of Oxford! Better still, there are no fewer than three very good pub/restaurants within walking distance :-) On Thu, 20 May 2021 at 23:22, Harald Anlauf via Fortran wrote: > The fix for PR93924/5 has caused a regression for code such as given > in the present PR. This can be remedied by adjusting the check when > to invoke the implicit conversion of actual argument to an unlimited > polymorphic procedure argument. > > Regtested on x86_64-pc-linux-gnu. > > OK for mainline and backport to 11-branch? > > Thanks, > Harald > > > Fortran: fix passing return value to class(*) dummy argument > > gcc/fortran/ChangeLog: > > PR fortran/100551 > * trans-expr.c (gfc_conv_procedure_call): Adjust check for > implicit conversion of actual argument to an unlimited polymorphic > procedure argument. > > gcc/testsuite/ChangeLog: > > PR fortran/100551 > * gfortran.dg/pr100551.f90: New test. > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch, fortran] PRs 46691 and 99819: Assumed and explicit size class arrays
It's 46991 of course. Many thanks Paul On Thu, 6 May 2021 at 17:15, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Blast! Thanks for pointing it out. The testcase is in a directory > ~/prs/pr46691, which I then took from the editor. Original sin and all > that. > > Paul > > > On Thu, 6 May 2021 at 17:06, Jonathan Wakely wrote: > >> PR 46691 is the wrong PR number: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46691 >> >> The comment in the testcase is wrong, and the ChangeLog file will get >> auto-updated with the wrong number overnight (you can manually edit it >> and push the fix tomorrow after it's been generated). >> >> >> > > -- > "If you can't explain it simply, you don't understand it well enough" - > Albert Einstein > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch, fortran] PRs 46691 and 99819: Assumed and explicit size class arrays
Blast! Thanks for pointing it out. The testcase is in a directory ~/prs/pr46691, which I then took from the editor. Original sin and all that. Paul On Thu, 6 May 2021 at 17:06, Jonathan Wakely wrote: > PR 46691 is the wrong PR number: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46691 > > The comment in the testcase is wrong, and the ChangeLog file will get > auto-updated with the wrong number overnight (you can manually edit it > and push the fix tomorrow after it's been generated). > > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch, fortran] PRs 46691 and 99819: Assumed and explicit size class arrays
Hi All, Please find below a corrected ChangeLog. Sorry that I didn't get it right first go. Paul Fortran: Assumed and explicit size class arrays [PR46691/99819]. 2021-05-06 Paul Thomas gcc/fortran/ChangeLog PR fortran/46691 PR fortran/99819 * class.c (gfc_build_class_symbol): Remove the error that disables assumed size class arrays. Class array types that are not deferred shape or assumed rank are given a unique name and placed in the procedure namespace. * trans-array.c (gfc_trans_g77_array): Obtain the data pointer for class arrays. (gfc_trans_dummy_array_bias): Suppress the runtime error for extent violations in explicit shape class arrays because it always fails. * trans-expr.c (gfc_conv_procedure_call): Handle assumed size class actual arguments passed to non-descriptor formal args by using the data pointer, stored as the symbol's backend decl. gcc/testsuite/ChangeLog PR fortran/46691 PR fortran/99819 * gfortran.dg/class_dummy_6.f90: New test. * gfortran.dg/class_dummy_7.f90: New test. On Thu, 6 May 2021 at 07:57, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi All, > > Although I had undertaken to concentrate on PDTs, PR99819 so intrigued me > that I became locked into it :-( After extensive, fruitless rummaging > through decl.c and trans-decl.c, I realised that the problem was far > simpler than it seemed and that it lay in class.c. After that PR was fixed, > PR46691 was a trivial follow up. > > The comments in the patch explain the fixes. I left a TODO for the extent > checking of assumed size class arrays. I will try to fix it before pushing. > > Regtested on FC33/x86_64 and checked against the 'other brand'. OK for > 12-branch and, perhaps, 11-branch? > > Regards > > Paul > > Fortran: Assumed and explicit size class arrays [PR46691/99819]. > > 2021-05-06 Paul Thomas > > gcc/fortran/ChangeLog > > PR fortran/46691 > PR fortran/99819 > * class.c (gfc_build_class_symbol): Class array types that are > not deferred shape or assumed rank are given a unique name and > placed in the procedure namespace. > * trans-array.c (gfc_trans_g77_array): Obtain the data pointer > for class arrays. > (gfc_trans_dummy_array_bias): Suppress the runtime error for > extent violations in explicit shape class arrays because it > always fails. > * trans-expr.c (gfc_conv_procedure_call): Handle assumed size > class actual arguments passed to non-descriptor formal args by > using the data pointer, stored as the symbol's backend decl. > > gcc/testsuite/ChangeLog > > PR fortran/46691 > PR fortran/99819 > * gfortran.dg/class_dummy_6.f90: New test. > * gfortran.dg/class_dummy_6.f90: New test. > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[Patch, fortran] PRs 46691 and 99819: Assumed and explicit size class arrays
Hi All,
Although I had undertaken to concentrate on PDTs, PR99819 so intrigued me
that I became locked into it :-( After extensive, fruitless rummaging
through decl.c and trans-decl.c, I realised that the problem was far
simpler than it seemed and that it lay in class.c. After that PR was fixed,
PR46691 was a trivial follow up.
The comments in the patch explain the fixes. I left a TODO for the extent
checking of assumed size class arrays. I will try to fix it before pushing.
Regtested on FC33/x86_64 and checked against the 'other brand'. OK for
12-branch and, perhaps, 11-branch?
Regards
Paul
Fortran: Assumed and explicit size class arrays [PR46691/99819].
2021-05-06 Paul Thomas
gcc/fortran/ChangeLog
PR fortran/46691
PR fortran/99819
* class.c (gfc_build_class_symbol): Class array types that are
not deferred shape or assumed rank are given a unique name and
placed in the procedure namespace.
* trans-array.c (gfc_trans_g77_array): Obtain the data pointer
for class arrays.
(gfc_trans_dummy_array_bias): Suppress the runtime error for
extent violations in explicit shape class arrays because it
always fails.
* trans-expr.c (gfc_conv_procedure_call): Handle assumed size
class actual arguments passed to non-descriptor formal args by
using the data pointer, stored as the symbol's backend decl.
gcc/testsuite/ChangeLog
PR fortran/46691
PR fortran/99819
* gfortran.dg/class_dummy_6.f90: New test.
* gfortran.dg/class_dummy_6.f90: New test.
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 89353218417..93118ad3455 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -630,6 +630,7 @@ gfc_get_len_component (gfc_expr *e, int k)
component '_vptr' which determines the dynamic type. When this CLASS
entity is unlimited polymorphic, then also add a component '_len' to
store the length of string when that is stored in it. */
+static int ctr = 0;
bool
gfc_build_class_symbol (gfc_typespec *ts, symbol_attribute *attr,
@@ -645,13 +646,6 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_attribute *attr,
gcc_assert (as);
- if (*as && (*as)->type == AS_ASSUMED_SIZE)
-{
- gfc_error ("Assumed size polymorphic objects or components, such "
- "as that at %C, have not yet been implemented");
- return false;
-}
-
if (attr->class_ok)
/* Class container has already been built. */
return true;
@@ -693,7 +687,30 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_attribute *attr,
else
ns = ts->u.derived->ns;
- gfc_find_symbol (name, ns, 0, );
+ /* Although this might seem to be counterintuitive, we can build separate
+ class types with different array specs because the TKR interface checks
+ work on the declared type. All array type other than deferred shape or
+ assumed rank are added to the function namespace to ensure that they
+ are properly distinguished. */
+ if (attr->dummy && !attr->codimension && (*as)
+ && !((*as)->type == AS_DEFERRED || (*as)->type == AS_ASSUMED_RANK))
+{
+ char *sname;
+ ns = gfc_current_ns;
+ gfc_find_symbol (name, ns, 0, );
+ /* If a local class type with this name already exists, update the
+ name with an index. */
+ if (fclass)
+ {
+ fclass = NULL;
+ sname = xasprintf ("%s_%d", name, ++ctr);
+ free (name);
+ name = sname;
+ }
+}
+ else
+gfc_find_symbol (name, ns, 0, );
+
if (fclass == NULL)
{
gfc_symtree *st;
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index e99980fd223..6d38ea78273 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -6524,7 +6524,14 @@ gfc_trans_g77_array (gfc_symbol * sym, gfc_wrapped_block * block)
/* Set the pointer itself if we aren't using the parameter directly. */
if (TREE_CODE (parm) != PARM_DECL)
{
- tmp = convert (TREE_TYPE (parm), GFC_DECL_SAVED_DESCRIPTOR (parm));
+ tmp = GFC_DECL_SAVED_DESCRIPTOR (parm);
+ if (sym->ts.type == BT_CLASS)
+ {
+ tmp = build_fold_indirect_ref_loc (input_location, tmp);
+ tmp = gfc_class_data_get (tmp);
+ tmp = gfc_conv_descriptor_data_get (tmp);
+ }
+ tmp = convert (TREE_TYPE (parm), tmp);
gfc_add_modify (, parm, tmp);
}
stmt = gfc_finish_block ();
@@ -6626,7 +6633,8 @@ gfc_trans_dummy_array_bias (gfc_symbol * sym, tree tmpdesc,
&& VAR_P (sym->ts.u.cl->backend_decl))
gfc_conv_string_length (sym->ts.u.cl, NULL, );
- checkparm = (as->type == AS_EXPLICIT
+ /* TODO: Fix the exclusion of class arrays from extent checking. */
+ checkparm = (as->type == AS_EXPLICIT && !is_classarray
&& (gfc_option.rtcheck & GFC_RTCHECK_BOUNDS));
no_repack = !(GFC_DECL_PACKED_ARRAY (tmpdesc)
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 213f32b0a67..5f5479561c2 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6420,6 +6420,15 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
fsym ? fsym->attr.intent
[Patch, fortran] PR84119 - Type parameter inquiry for PDT returns array instead of scalar
Ping! On Tue, 20 Apr 2021 at 12:51, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi All, > > This is another PDT warm-up patch before tackling the real beast: PR82649. > > As the contributor wrote in the PR, "The F08 standard clearly > distinguishes between type parameter definition statements and component > definition statements. See R425, R431, R435, and in particular see Note 6.7 > which says 'It [array%a, for example] is scalar even if designator is an > array.' " gfortran was not making this distinction. The patch realises the > fix by lifting the code used for inquiry part references into a new > function and calling for PDT parameters and inquiry references. The > arrayspec lbound is used for 'start' now, rather than unity. In principle > this should remove the need to suppress bound checking. However, since this > would be confusing for the user to say the least of it, the suppression has > been retained. > > Bootstraps and regtests on FC33/x86_64. OK for 12- and 11-branches? > > Cheers > > Paul > > Fortran: Make PDT LEN and KIND expressions always scalar [PR84119]. > > 2021-04-20 Paul Thomas > > gcc/fortran > PR fortran/84119 > * resolve.c (reset_array_ref_to_scalar): New function. > (gfc_resolve_ref): Call it for PDT kind and len expressions. > Code for inquiry refs. moved to new function and replaced by a > call to it. > > gcc/testsuite/ > PR fortran/84119 > * gfortran.dg/pdt_32.f03: New test. > * gfortran.dg/pdt_20.f03: Correct the third test to be against > a scalar instead of an array. > > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch, fortran] PR fortran/82376 - Duplicate function call using -fcheck=pointer
Hi José!
The fix is fine.
Note however that the testcase will pass even without the fix because you
haven't included the
! { dg-options "-fcheck=pointer" }.
In fact, I suggest that you use the version of the tescase that I have
attached that does not run but counts the number of occurrences of 'new' in
the tree dump.
OK for master, certainly for 11-branch, when it is open again, and for
10-branch after a wait.
Are you reliant on others to commit and push your patches or have you done
the FSF paperwork?
Thanks
Paul
On Thu, 22 Apr 2021 at 21:50, José Rui Faustino de Sousa via Fortran <
fort...@gcc.gnu.org> wrote:
> Hi All!
>
> Proposed patch to:
>
> PR82376 - Duplicate function call using -fcheck=pointer
>
> Patch tested only on x86_64-pc-linux-gnu.
>
> Evaluate function result and then pass a pointer, instead of a reference
> to the function itself, thus avoiding multiple evaluations of the function.
>
> Thank you very much.
>
> Best regards,
> José Rui
>
> Fortran: Fix double function call with -fcheck=pointer [PR]
>
> gcc/fortran/ChangeLog:
>
> PR fortran/82376
> * trans-expr.c (gfc_conv_procedure_call): Evaluate function result
> and then pass a pointer.
>
> gcc/testsuite/ChangeLog:
>
> PR fortran/82376
> * gfortran.dg/PR82376.f90: New test.
>
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
! { dg-do compile }
! { dg-options "-fdump-tree-original -fcheck=pointer" }
!
! Test the fix for PR82376. The pointer check was doubling up the call
! to new. The fix reduces the count of 'new' from 5 to 4.
!
! Contributed by José Rui Faustino de Sousa
!
program main_p
integer, parameter :: n = 10
type :: foo_t
integer, pointer :: v =>null()
end type foo_t
integer, save :: pcnt = 0
type(foo_t) :: int
integer :: i
do i = 1, n
call init(int, i)
if(.not.associated(int%v)) stop 1
if(int%v/=i) stop 2
if(pcnt/=i) stop 3
end do
contains
function new(data) result(this)
integer, target, intent(in) :: data
integer, pointer :: this
nullify(this)
this => data
pcnt = pcnt + 1
return
end function new
subroutine init(this, data)
type(foo_t), intent(out) :: this
integer, intent(in) :: data
call set(this, new(data))
return
end subroutine init
subroutine set(this, that)
type(foo_t), intent(inout) :: this
integer, target, intent(in):: that
this%v => that
return
end subroutine set
end program main_p
! { dg-final { scan-tree-dump-times "new" 4 "original" } }
Re: [Patch] PR fortran/100218 - target of pointer from evaluation of function-reference
Hi Harald, Another good one - OK for master but wait a while for 11-branch. I am a bit hesitant about 10-branch because this is not a regression. That said, this is harmless because it is permissive, so I will leave it to you to decide. Is there a test for an error with -std=f2003? If not, you should, perhaps, include one. Thanks Paul On Thu, 22 Apr 2021 at 23:37, Harald Anlauf via Fortran wrote: > Dear Fortranners, > > while analyzing a different PR (PR100154), Tobias pointed out that the > target of a pointer from the evaluation of function-reference is allowed > to be used in a variable definition context and thus as an actual > argument to a function or subroutine. > > This seems to be a more general issue that seems to have been overlooked. > The attached simple patch allows to compile and run the attached example, > which is by the way already yet rejected with -std=f2003. > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > Shall we backport this to (at least) 11? > > Thanks, > Harald > > > Fortran - allow target of pointer from evaluation of function-reference > > Fortran allows the target of a pointer from the evaluation of a > function-reference in a variable definition context (e.g. F2018:R902). > > gcc/fortran/ChangeLog: > > PR fortran/100218 > * expr.c (gfc_check_vardef_context): Extend check to allow pointer > from a function reference. > > gcc/testsuite/ChangeLog: > > PR fortran/100218 > * gfortran.dg/pr100218.f90: New test. > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch] PR fortran/100154 - [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
Hi Harald,
It looks good to me! Keep clear of 11-branch until release but OK for the
others.
Thanks
Paul
On Fri, 23 Apr 2021 at 00:18, Harald Anlauf via Fortran
wrote:
> Now with the correct patch attached ...
>
> Sorry for the confusion!
>
> ---
>
> Dear Fortranners,
>
> we need to check the arguments to the affected GNU intrinsic extensions
> properly, and - as pointed out in the PR by Tobias - we need to allow
> function references that have a data pointer result. Also the argument
> names of the character arguments of the subroutine versions needed a
> fix ("c" instead of "count").
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline (12)?
> OK for backports after 11.1 release?
>
> Thanks,
> Harald
>
>
> PR fortran/100154 - ICE in gfc_conv_procedure_call, at
> fortran/trans-expr.c:6131
>
> Add appropriate static checks for the character and status arguments to
> the GNU Fortran intrinsic extensions fget[c], fput[c]. Extend variable
> check to allow a function reference having a data pointer result.
>
> gcc/fortran/ChangeLog:
>
> PR fortran/100154
> * check.c (variable_check): Allow function reference having a data
> pointer result.
> (arg_strlen_is_zero): New function.
> (gfc_check_fgetputc_sub): Add static check of character and status
> arguments.
> (gfc_check_fgetput_sub): Likewise.
> * intrinsic.c (add_subroutines): Fix argument name for the
> character argument to intrinsic subroutines fget[c], fput[c].
>
> gcc/testsuite/ChangeLog:
>
> PR fortran/100154
> * gfortran.dg/pr100154.f90: New test.
>
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
[Patch, fortran] PR84119 - Type parameter inquiry for PDT returns array instead of scalar
Hi All,
This is another PDT warm-up patch before tackling the real beast: PR82649.
As the contributor wrote in the PR, "The F08 standard clearly distinguishes
between type parameter definition statements and component definition
statements. See R425, R431, R435, and in particular see Note 6.7 which says
'It [array%a, for example] is scalar even if designator is an array.' "
gfortran was not making this distinction. The patch realises the fix by
lifting the code used for inquiry part references into a new function and
calling for PDT parameters and inquiry references. The arrayspec lbound is
used for 'start' now, rather than unity. In principle this should remove
the need to suppress bound checking. However, since this would be confusing
for the user to say the least of it, the suppression has been retained.
Bootstraps and regtests on FC33/x86_64. OK for 12- and 11-branches?
Cheers
Paul
Fortran: Make PDT LEN and KIND expressions always scalar [PR84119].
2021-04-20 Paul Thomas
gcc/fortran
PR fortran/84119
* resolve.c (reset_array_ref_to_scalar): New function.
(gfc_resolve_ref): Call it for PDT kind and len expressions.
Code for inquiry refs. moved to new function and replaced by a
call to it.
gcc/testsuite/
PR fortran/84119
* gfortran.dg/pdt_32.f03: New test.
* gfortran.dg/pdt_20.f03: Correct the third test to be against
a scalar instead of an array.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index dd4b26680e0..1571fa9d70c 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -5254,12 +5254,46 @@ gfc_resolve_substring_charlen (gfc_expr *e)
}
+/* Convert an array reference to an array element so that PDT KIND and LEN
+ or inquiry references are always scalar. */
+
+static void
+reset_array_ref_to_scalar (gfc_expr *expr, gfc_ref *array_ref)
+{
+ gfc_expr *unity = gfc_get_int_expr (gfc_default_integer_kind, NULL, 1);
+ int dim;
+
+ array_ref->u.ar.type = AR_ELEMENT;
+ expr->rank = 0;
+ /* Suppress the runtime bounds check. */
+ expr->no_bounds_check = 1;
+ for (dim = 0; dim < array_ref->u.ar.dimen; dim++)
+{
+ array_ref->u.ar.dimen_type[dim] = DIMEN_ELEMENT;
+ if (array_ref->u.ar.start[dim])
+ gfc_free_expr (array_ref->u.ar.start[dim]);
+
+ if (array_ref->u.ar.as && array_ref->u.ar.as->lower[dim])
+ array_ref->u.ar.start[dim]
+ = gfc_copy_expr (array_ref->u.ar.as->lower[dim]);
+ else
+ array_ref->u.ar.start[dim] = gfc_copy_expr (unity);
+
+ if (array_ref->u.ar.end[dim])
+ gfc_free_expr (array_ref->u.ar.end[dim]);
+ if (array_ref->u.ar.stride[dim])
+ gfc_free_expr (array_ref->u.ar.stride[dim]);
+}
+ gfc_free_expr (unity);
+}
+
+
/* Resolve subtype references. */
bool
gfc_resolve_ref (gfc_expr *expr)
{
- int current_part_dimension, n_components, seen_part_dimension, dim;
+ int current_part_dimension, n_components, seen_part_dimension;
gfc_ref *ref, **prev, *array_ref;
bool equal_length;
@@ -5365,6 +5399,14 @@ gfc_resolve_ref (gfc_expr *expr)
}
}
+ /* The F08 standard distinguishes between type parameter definition
+ statements and component definition statements. See R425, R431,
+ R435, and in particular see Note 6.7 which says "It [array%a, for
+ example] is scalar even if designator is an array." */
+ if (array_ref && (ref->u.c.component->attr.pdt_kind
+ || ref->u.c.component->attr.pdt_len))
+ reset_array_ref_to_scalar (expr, array_ref);
+
n_components++;
break;
@@ -5375,27 +5417,7 @@ gfc_resolve_ref (gfc_expr *expr)
/* Implement requirement in note 9.7 of F2018 that the result of the
LEN inquiry be a scalar. */
if (ref->u.i == INQUIRY_LEN && array_ref && expr->ts.deferred)
- {
- array_ref->u.ar.type = AR_ELEMENT;
- expr->rank = 0;
- /* INQUIRY_LEN is not evaluated from the rest of the expr
- but directly from the string length. This means that setting
- the array indices to one does not matter but might trigger
- a runtime bounds error. Suppress the check. */
- expr->no_bounds_check = 1;
- for (dim = 0; dim < array_ref->u.ar.dimen; dim++)
- {
- array_ref->u.ar.dimen_type[dim] = DIMEN_ELEMENT;
- if (array_ref->u.ar.start[dim])
- gfc_free_expr (array_ref->u.ar.start[dim]);
- array_ref->u.ar.start[dim]
- = gfc_get_int_expr (gfc_default_integer_kind, NULL, 1);
- if (array_ref->u.ar.end[dim])
- gfc_free_expr (array_ref->u.ar.end[dim]);
- if (array_ref->u.ar.stride[dim])
- gfc_free_expr (array_ref->u.ar.stride[dim]);
- }
- }
+ reset_array_ref_to_scalar (expr, array_ref);
break;
}
diff --git a/gcc/testsuite/gfortran.dg/pdt_20.f03 b/gcc/testsuite/gfortran.dg/pdt_20.f03
index b712ed59dbb..3aa9b2e086b 100644
--- a/gcc/testsuite/gfortran.dg/pdt_20.f03
+++ b/gcc/testsuite/gfortran.dg/pdt_20.f03
@@ -16,5 +16,5 @@ program p
allocate (t2(3) :: x)! Used to segfault in trans-array.c.
if (x%b .ne. 3) STOP 1
if (x%b .ne. size (x%r, 1))
Re: [Patch, fortran] PR100110 - Parameterized Derived Types, problems with global variable
Hi Tobias,
That was entirely accidental. I should have been more careful about
checking the timing of the merge. When I last checked the number of P1s
seemed to indicate that there was a while before it would happen.
Apologies to all.
Paul
On Tue, 20 Apr 2021 at 11:07, Tobias Burnus wrote:
> Answer: Because my 'git pull' somehow got stuck – and showed an old trunk.
>
> Your patch just went in before the merge – thus it was on mainline GCC
> 11 and is now
> on mainline GCC 12 + GCC 11 branch ...
>
> Sorry for the confusion.
>
> Tobias
>
> On 20.04.21 11:58, Tobias Burnus wrote:
> > Hi Paul,
> >
> > is there a reason why you did not apply the patch to mainline ('master')
> > but only to GCC 11 ('releases/gcc-11')?
> >
> > While GCC 11 is okay, I had expected it to be (only) on mainline!
> >
> > Tobias
> >
> > On 20.04.21 10:55, Paul Richard Thomas wrote:
> >> Hi Tobias,
> >>
> >> Thanks. Commit r11-8255-g67378cd63d62bf0c69e966d1d202a1e586550a68.
> >>
> >> By the way, I did check that there were no problems with pdt_26.f03
> >> reported by valgrind, given the decrease in the malloc count.
> >>
> >> Cheers
> >>
> >> Paul
> >>
> >>
> >> On Mon, 19 Apr 2021 at 14:08, Tobias Burnus >> <mailto:tob...@codesourcery.com>> wrote:
> >>
> >> Hi Paul,
> >>
> >> On 19.04.21 14:40, Paul Richard Thomas via Gcc-patches wrote:
> >> > I was just about to announce that I will only do backports and
> >> regressions,
> >> > while I finally attack the fundamental problem with the
> >> representation of
> >> > Parameterized Derived Types. Then this PR came up that was such
> >> clear low
> >> > hanging fruit that I decided to fix it right away.
> >> >
> >> > Regtests on FC33/x86_64 - OK for mainline?
> >>
> >> LGTM.
> >>
> >> Thanks,
> >>
> >> Tobias
> >>
> >> -
> >> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634
> >> München Registergericht München HRB 106955, Geschäftsführer:
> >> Thomas Heurung, Frank Thürauf
> >>
> >>
> >>
> >> --
> >> "If you can't explain it simply, you don't understand it well enough"
> >> - Albert Einstein
> > -
> > Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
> > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
> > Frank Thürauf
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
> Thürauf
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
Re: [Patch, fortran] PR100110 - Parameterized Derived Types, problems with global variable
Hi Tobias, Thanks. Commit r11-8255-g67378cd63d62bf0c69e966d1d202a1e586550a68. By the way, I did check that there were no problems with pdt_26.f03 reported by valgrind, given the decrease in the malloc count. Cheers Paul On Mon, 19 Apr 2021 at 14:08, Tobias Burnus wrote: > Hi Paul, > > On 19.04.21 14:40, Paul Richard Thomas via Gcc-patches wrote: > > I was just about to announce that I will only do backports and > regressions, > > while I finally attack the fundamental problem with the representation of > > Parameterized Derived Types. Then this PR came up that was such clear low > > hanging fruit that I decided to fix it right away. > > > > Regtests on FC33/x86_64 - OK for mainline? > > LGTM. > > Thanks, > > Tobias > > - > Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank > Thürauf > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[Patch, fortran] PR100110 - Parameterized Derived Types, problems with global variable
Hi All,
I was just about to announce that I will only do backports and regressions,
while I finally attack the fundamental problem with the representation of
Parameterized Derived Types. Then this PR came up that was such clear low
hanging fruit that I decided to fix it right away.
Regtests on FC33/x86_64 - OK for mainline?
Note that this is sufficiently safe that it could be applied to 11-branch
right now. However, I am prepared to hold off until 11-branch is released.
Regards
Paul
Fortran: Fix host associated PDT entity initialization [PR99307].
2021-04-19 Paul Thomas
gcc/fortran
PR fortran/100110
* trans-decl.c (gfc_get_symbol_decl): Replace test for host
association with a check that the current and symbol namespaces
are the same.
gcc/testsuite/
PR fortran/100110
* gfortran.dg/pdt_31.f03: New test.
* gfortran.dg/pdt_26.f03: Reduce 'builtin_malloc' count from 9
to 8.
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 34a0d49bae7..cc9d85543ca 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1548,7 +1548,8 @@ gfc_get_symbol_decl (gfc_symbol * sym)
declaration of the entity and memory allocated/deallocated. */
if ((sym->ts.type == BT_DERIVED || sym->ts.type == BT_CLASS)
&& sym->param_list != NULL
- && !(sym->attr.host_assoc || sym->attr.use_assoc || sym->attr.dummy))
+ && gfc_current_ns == sym->ns
+ && !(sym->attr.use_assoc || sym->attr.dummy))
gfc_defer_symbol_init (sym);
/* Dummy PDT 'len' parameters should be checked when they are explicit. */
diff --git a/gcc/testsuite/gfortran.dg/pdt_26.f03 b/gcc/testsuite/gfortran.dg/pdt_26.f03
index bf1273743d3..59ddcfb6cc4 100644
--- a/gcc/testsuite/gfortran.dg/pdt_26.f03
+++ b/gcc/testsuite/gfortran.dg/pdt_26.f03
@@ -2,7 +2,7 @@
! { dg-options "-fdump-tree-original" }
!
! Test the fix for PR83567 in which the parameterized component 'foo' was
-! being deallocated before return from 'addw', with consequent segfault in
+! being deallocated before return from 'addw', with consequent segfault in
! the main program.
!
! Contributed by Berke Durak
@@ -43,4 +43,4 @@ program test_pdt
if (any (c(1)%foo .ne. [13,15,17])) STOP 2
end program test_pdt
! { dg-final { scan-tree-dump-times "__builtin_free" 8 "original" } }
-! { dg-final { scan-tree-dump-times "__builtin_malloc" 9 "original" } }
+! { dg-final { scan-tree-dump-times "__builtin_malloc" 8 "original" } }
pdt_31.f03
Description: Binary data
Re: [PATCH] docs: Remove empty table column.
Hi Martin,
It looks good to me - please push before release.
Thanks
Paul
On Mon, 12 Apr 2021 at 16:59, Martin Liška wrote:
> A column with empty values seems suspicious.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/fortran/ChangeLog:
>
> * intrinsic.texi: The table has first column empty and it makes
> trouble when processing makeinfo --xml output.
> ---
> gcc/fortran/intrinsic.texi | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
> index 73baa34104e..c74a7f56c60 100644
> --- a/gcc/fortran/intrinsic.texi
> +++ b/gcc/fortran/intrinsic.texi
> @@ -4764,15 +4764,15 @@ Unavailable time and date parameters return blanks.
>
> @var{VALUES} is @code{INTENT(OUT)} and provides the following:
>
> -@multitable @columnfractions .15 .30 .40
> -@item @tab @code{VALUE(1)}: @tab The year
> -@item @tab @code{VALUE(2)}: @tab The month
> -@item @tab @code{VALUE(3)}: @tab The day of the month
> -@item @tab @code{VALUE(4)}: @tab Time difference with UTC in minutes
> -@item @tab @code{VALUE(5)}: @tab The hour of the day
> -@item @tab @code{VALUE(6)}: @tab The minutes of the hour
> -@item @tab @code{VALUE(7)}: @tab The seconds of the minute
> -@item @tab @code{VALUE(8)}: @tab The milliseconds of the second
> +@multitable @columnfractions .15 .70
> +@item @code{VALUE(1)}: @tab The year
> +@item @code{VALUE(2)}: @tab The month
> +@item @code{VALUE(3)}: @tab The day of the month
> +@item @code{VALUE(4)}: @tab Time difference with UTC in minutes
> +@item @code{VALUE(5)}: @tab The hour of the day
> +@item @code{VALUE(6)}: @tab The minutes of the hour
> +@item @code{VALUE(7)}: @tab The seconds of the minute
> +@item @code{VALUE(8)}: @tab The milliseconds of the second
> @end multitable
>
> @item @emph{Standard}:
> --
> 2.31.1
>
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
Re: [Patch, fortran v2] PR fortran/84006, PR fortran/100027 - ICE on storage_size with polymorphic argument
Hi Jose, Please take a look at my reply on the PR, which points to PR98534. Regards Paul On Fri, 16 Apr 2021 at 20:47, José Rui Faustino de Sousa via Fortran < fort...@gcc.gnu.org> wrote: > Hi All! > > Proposed patch to: > PR84006 - [8/9/10/11 Regression] ICE in storage_size() with CLASS entity > PR100027 - ICE on storage_size with polymorphic argument > > Patch tested only on x86_64-pc-linux-gnu. > > Add branch to if clause to handle polymorphic objects, not sure if I got > all possible variations... > > Now with a new and extended test. > > Thank you very much. > > Best regards, > José Rui > > Fortran: Fix ICE using storage_size intrinsic [PR84006, PR100027] > > gcc/fortran/ChangeLog: > > PR fortran/84006 > PR fortran/100027 > * trans-intrinsic.c (gfc_conv_intrinsic_storage_size): add if > clause branch to handle polymorphic objects. > > gcc/testsuite/ChangeLog: > > PR fortran/84006 > * gfortran.dg/PR84006.f90: New test. > > PR fortran/100027 > * gfortran.dg/PR100027.f90: New test. > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch, fortran] 99307 - FAIL: gfortran.dg/class_assign_4.f90 execution test
Pushed to master in commit 9a0e09f3dd5339bb18cc47317f2298d9157ced29
Thanks
Paul
On Wed, 14 Apr 2021 at 14:51, Tobias Burnus wrote:
> On 11.04.21 09:05, Paul Richard Thomas wrote:
> > Tobias noticed a major technical fault with the resubmission below: I
> > forgot to attach the patch :-(
>
> LGTM. Plus as remarked in the first review: 'trans-expr_c' typo needs to
> be fixed (ChangeLog).
>
> Tobias
>
> >
> > Please find it attached this time.
> >
> > Paul
> >
> > On Tue, 6 Apr 2021 at 18:08, Paul Richard Thomas
> > mailto:paul.richard.tho...@gmail.com>>
> > wrote:
> >
> > Hi Tobias,
> >
> > I believe that the attached fixes the problems that you found with
> > gfc_find_and_cut_at_last_class_ref.
> >
> > I will test:
> >type1%type%array_class2 → NULL is returned (why?)
> >class1%type%array_class2 → ts = class1 but array2_class is used
> > later on (ups!)
> >class1%...%scalar_class2 → ts = class1 but scalar_class2 is used
> >
> > The ChangeLogs remain the same, apart from the date.
> >
> > Regtests OK on FC33/x86_64.
> >
> > Paul
> >
> >
> > On Mon, 29 Mar 2021 at 14:58, Tobias Burnus
> > mailto:tob...@codesourcery.com>> wrote:
> >
> > Hi all,
> >
> > as preremark I want to note that the testcase class_assign_4.f90
> > was added for PR83118/PR96012 (fixes problems in handling
> > class objects, Dec 18, 2020)
> > and got revised for PR99124 (class defined operators, Feb 23,
> > 2021).
> > Both patches were then also applied to GCC 9 and 10.
> >
> > On 26.03.21 17:30, Paul Richard Thomas via Gcc-patches wrote:
> > > This patch comes in two versions: submit.diff with
> > Change.Logs or
> > > submit2.diff with Change2.Logs.
> > > The first fixes the problem by changing array temporaries
> > from class
> > > expressions into class temporaries. This permits the use of
> > > gfc_get_class_from_expr to obtain the vptr for these
> > temporaries and all
> > > the good things that come with that when handling dynamic
> > types. The second
> > > part of the fix is to use the array element length from the
> > class
> > > descriptor, when reallocating on assignment. This is needed
> > because the
> > > vptr is being set too early. I will set about trying to
> > track down why this
> > > is happening and fix it after release.
> > >
> > > The second version does the same as the first but puts in
> > place a load of
> > > tidying up that is permitted by the fix to class array
> > temporaries.
> >
> > > I couldn't readily see how to prepare a testcase - ideas?
> > > Both regtest on FC33/x86_64. The first was tested by
> > Dominique (see the
> > > PR). OK for master?
> >
> > Typo – underscore-'c' should be a dot-'c' – both changelog files
> >
> > > * trans-expr_c (gfc_trans_scalar_assign): Make use of
> > pre and
> >
> > I think the second longer version is nicer in general, but at
> > least for
> > GCC 9/GCC10 the first version is simpler and, hence, less
> > error prone.
> >
> > As you only ask about mainline, I would prefer the second one.
> >
> > However, I am not happy about gfc_find_and_cut_at_last_class_ref:
> >
> > > + of refs following. If ts is non-null the cut is at the
> > class entity
> > > + or component that is followed by an array reference, which
> > is not +
> > > an element. */ ... + + if (ts) + { + if (e->symtree + &&
> > > e->symtree->n.sym->ts.type == BT_CLASS) + *ts =
> > > >symtree->n.sym->ts; + else + *ts = NULL; + } + for (ref
> > = e->ref;
> > > ref; ref = ref->next) { + if (ts && ref->type ==
> > REF_COMPONENT + &&
> > > ref->u.c.component->ts.type == BT_CLASS + && ref->next &&
> > > ref->next->type == REF_COMPONENT + && strcmp
> > > (ref->next->u.c.component->name, "_data") == 0 + &&
Re: [Patch, fortran] 99307 - FAIL: gfortran.dg/class_assign_4.f90 execution test
Tobias noticed a major technical fault with the resubmission below: I
forgot to attach the patch :-(
Please find it attached this time.
Paul
On Tue, 6 Apr 2021 at 18:08, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Tobias,
>
> I believe that the attached fixes the problems that you found with
> gfc_find_and_cut_at_last_class_ref.
>
> I will test:
>type1%type%array_class2 → NULL is returned (why?)
>class1%type%array_class2 → ts = class1 but array2_class is used later
> on (ups!)
>class1%...%scalar_class2 → ts = class1 but scalar_class2 is used
>
> The ChangeLogs remain the same, apart from the date.
>
> Regtests OK on FC33/x86_64.
>
> Paul
>
>
> On Mon, 29 Mar 2021 at 14:58, Tobias Burnus
> wrote:
>
>> Hi all,
>>
>> as preremark I want to note that the testcase class_assign_4.f90
>> was added for PR83118/PR96012 (fixes problems in handling class objects,
>> Dec 18, 2020)
>> and got revised for PR99124 (class defined operators, Feb 23, 2021).
>> Both patches were then also applied to GCC 9 and 10.
>>
>> On 26.03.21 17:30, Paul Richard Thomas via Gcc-patches wrote:
>> > This patch comes in two versions: submit.diff with Change.Logs or
>> > submit2.diff with Change2.Logs.
>> > The first fixes the problem by changing array temporaries from class
>> > expressions into class temporaries. This permits the use of
>> > gfc_get_class_from_expr to obtain the vptr for these temporaries and all
>> > the good things that come with that when handling dynamic types. The
>> second
>> > part of the fix is to use the array element length from the class
>> > descriptor, when reallocating on assignment. This is needed because the
>> > vptr is being set too early. I will set about trying to track down why
>> this
>> > is happening and fix it after release.
>> >
>> > The second version does the same as the first but puts in place a load
>> of
>> > tidying up that is permitted by the fix to class array temporaries.
>>
>> > I couldn't readily see how to prepare a testcase - ideas?
>> > Both regtest on FC33/x86_64. The first was tested by Dominique (see the
>> > PR). OK for master?
>>
>> Typo – underscore-'c' should be a dot-'c' – both changelog files
>>
>> > * trans-expr_c (gfc_trans_scalar_assign): Make use of pre and
>>
>> I think the second longer version is nicer in general, but at least for
>> GCC 9/GCC10 the first version is simpler and, hence, less error prone.
>>
>> As you only ask about mainline, I would prefer the second one.
>>
>> However, I am not happy about gfc_find_and_cut_at_last_class_ref:
>>
>> > + of refs following. If ts is non-null the cut is at the class entity
>> > + or component that is followed by an array reference, which is not +
>> > an element. */ ... + + if (ts) + { + if (e->symtree + &&
>> > e->symtree->n.sym->ts.type == BT_CLASS) + *ts =
>> > >symtree->n.sym->ts; + else + *ts = NULL; + } + for (ref = e->ref;
>> > ref; ref = ref->next) { + if (ts && ref->type == REF_COMPONENT + &&
>> > ref->u.c.component->ts.type == BT_CLASS + && ref->next &&
>> > ref->next->type == REF_COMPONENT + && strcmp
>> > (ref->next->u.c.component->name, "_data") == 0 + && ref->next->next +
>> > && ref->next->next->type == REF_ARRAY + && ref->next->next->u.ar.type
>> > != AR_ELEMENT) + { + *ts = >u.c.component->ts; + class_ref = ref;
>> > + break; + } + + if (ts && *ts == NULL) + return NULL; +
>> Namely, if there is:
>>type1%array_class2 → array_class2 is used for 'ts' and later (ok)
>>type1%type%array_class2 → NULL is returned (why?)
>>class1%type%array_class2 → ts = class1 but array2_class is used later
>> on (ups!)
>>class1%...%scalar_class2 → ts = class1 but scalar_class2 is used
>> etc.
>>
>> Thus this either needs to be cleaned up (separate 'ref' loop for
>> ts != NULL) – including the wording in the description which tells what
>> happens if 'ts' is passed as arg but the expr has rank == 0 – and
>> what value is assigned to 'ts'. (You can then also fix 'class.c::' to
>> 'class.c: ' in the description above the function.)
>>
>> Alternatively, you can leave the current code ref handling code in place
>> at build_class_array_ref, which might be the simpler alternative.
>>
>> Otherwise, it looks sensible to me.
&
Re: [Patch, fortran] 99307 - FAIL: gfortran.dg/class_assign_4.f90 execution test
Hi Tobias,
I believe that the attached fixes the problems that you found with
gfc_find_and_cut_at_last_class_ref.
I will test:
type1%type%array_class2 → NULL is returned (why?)
class1%type%array_class2 → ts = class1 but array2_class is used later on
(ups!)
class1%...%scalar_class2 → ts = class1 but scalar_class2 is used
The ChangeLogs remain the same, apart from the date.
Regtests OK on FC33/x86_64.
Paul
On Mon, 29 Mar 2021 at 14:58, Tobias Burnus wrote:
> Hi all,
>
> as preremark I want to note that the testcase class_assign_4.f90
> was added for PR83118/PR96012 (fixes problems in handling class objects,
> Dec 18, 2020)
> and got revised for PR99124 (class defined operators, Feb 23, 2021).
> Both patches were then also applied to GCC 9 and 10.
>
> On 26.03.21 17:30, Paul Richard Thomas via Gcc-patches wrote:
> > This patch comes in two versions: submit.diff with Change.Logs or
> > submit2.diff with Change2.Logs.
> > The first fixes the problem by changing array temporaries from class
> > expressions into class temporaries. This permits the use of
> > gfc_get_class_from_expr to obtain the vptr for these temporaries and all
> > the good things that come with that when handling dynamic types. The
> second
> > part of the fix is to use the array element length from the class
> > descriptor, when reallocating on assignment. This is needed because the
> > vptr is being set too early. I will set about trying to track down why
> this
> > is happening and fix it after release.
> >
> > The second version does the same as the first but puts in place a load of
> > tidying up that is permitted by the fix to class array temporaries.
>
> > I couldn't readily see how to prepare a testcase - ideas?
> > Both regtest on FC33/x86_64. The first was tested by Dominique (see the
> > PR). OK for master?
>
> Typo – underscore-'c' should be a dot-'c' – both changelog files
>
> > * trans-expr_c (gfc_trans_scalar_assign): Make use of pre and
>
> I think the second longer version is nicer in general, but at least for
> GCC 9/GCC10 the first version is simpler and, hence, less error prone.
>
> As you only ask about mainline, I would prefer the second one.
>
> However, I am not happy about gfc_find_and_cut_at_last_class_ref:
>
> > + of refs following. If ts is non-null the cut is at the class entity
> > + or component that is followed by an array reference, which is not +
> > an element. */ ... + + if (ts) + { + if (e->symtree + &&
> > e->symtree->n.sym->ts.type == BT_CLASS) + *ts =
> > >symtree->n.sym->ts; + else + *ts = NULL; + } + for (ref = e->ref;
> > ref; ref = ref->next) { + if (ts && ref->type == REF_COMPONENT + &&
> > ref->u.c.component->ts.type == BT_CLASS + && ref->next &&
> > ref->next->type == REF_COMPONENT + && strcmp
> > (ref->next->u.c.component->name, "_data") == 0 + && ref->next->next +
> > && ref->next->next->type == REF_ARRAY + && ref->next->next->u.ar.type
> > != AR_ELEMENT) + { + *ts = >u.c.component->ts; + class_ref = ref;
> > + break; + } + + if (ts && *ts == NULL) + return NULL; +
> Namely, if there is:
>type1%array_class2 → array_class2 is used for 'ts' and later (ok)
>type1%type%array_class2 → NULL is returned (why?)
>class1%type%array_class2 → ts = class1 but array2_class is used later
> on (ups!)
>class1%...%scalar_class2 → ts = class1 but scalar_class2 is used
> etc.
>
> Thus this either needs to be cleaned up (separate 'ref' loop for
> ts != NULL) – including the wording in the description which tells what
> happens if 'ts' is passed as arg but the expr has rank == 0 – and
> what value is assigned to 'ts'. (You can then also fix 'class.c::' to
> 'class.c: ' in the description above the function.)
>
> Alternatively, you can leave the current code ref handling code in place
> at build_class_array_ref, which might be the simpler alternative.
>
> Otherwise, it looks sensible to me.
>
> Tobias
>
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
> Thürauf
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
Re: [Patch, fortran] PR99818 - [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186
Hi Jerry, A belated thanks is in order. Pushed as fc27115d6107f219e6f3dc610c99210005fe9dc5. I'll wait a little while for 10-branch since it is an ICE on wrong code. Regards Paul On Fri, 2 Apr 2021 at 04:11, Jerry DeLisle wrote: > Paul, > > This looks OK to me for Trunk. I believe 10 is in freeze so it may have > to wait or get release manager approval. > > Jerry > > On 4/1/21 6:44 AM, Paul Richard Thomas via Fortran wrote: > > This one is trivial. The wrong error message was transformed by my patch > > for PR98897 into an ICE. This patch now produces the correct error. > > > > Regtests OK on FC33/x86_64 - OK for the affected branches? > > > > Paul > > > > Fortran: Fix ICE on wrong code [PR99818]. > > > > 2021-04-01 Paul Thomas > > > > gcc/fortran/ChangeLog > > > > PR fortran/99818 > > * interface.c (compare_parameter): The codimension attribute is > > applied to the _data field of class formal arguments. > > > > gcc/testsuite/ChangeLog > > > > PR fortran/99818 > > * gfortran.dg/coarray_48.f90: New test. > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[Patch, fortran] PR99818 - [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186
This one is trivial. The wrong error message was transformed by my patch
for PR98897 into an ICE. This patch now produces the correct error.
Regtests OK on FC33/x86_64 - OK for the affected branches?
Paul
Fortran: Fix ICE on wrong code [PR99818].
2021-04-01 Paul Thomas
gcc/fortran/ChangeLog
PR fortran/99818
* interface.c (compare_parameter): The codimension attribute is
applied to the _data field of class formal arguments.
gcc/testsuite/ChangeLog
PR fortran/99818
* gfortran.dg/coarray_48.f90: New test.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index f7ca52e6550..60736123550 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -2327,6 +2327,7 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
bool rank_check, is_pointer;
char err[200];
gfc_component *ppc;
+ bool codimension = false;
/* If the formal arg has type BT_VOID, it's to one of the iso_c_binding
procs c_f_pointer or c_f_procpointer, and we need to accept most
@@ -2490,7 +2491,12 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
return false;
}
- if (formal->attr.codimension && !gfc_is_coarray (actual))
+ if (formal->ts.type == BT_CLASS && formal->attr.class_ok)
+codimension = CLASS_DATA (formal)->attr.codimension;
+ else
+codimension = formal->attr.codimension;
+
+ if (codimension && !gfc_is_coarray (actual))
{
if (where)
gfc_error ("Actual argument to %qs at %L must be a coarray",
@@ -2498,7 +2504,7 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
return false;
}
- if (formal->attr.codimension && formal->attr.allocatable)
+ if (codimension && formal->attr.allocatable)
{
gfc_ref *last = NULL;
@@ -2520,7 +2526,7 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
}
}
- if (formal->attr.codimension)
+ if (codimension)
{
/* F2008, 12.5.2.8 + Corrig 2 (IR F08/0048). */
/* F2018, 12.5.2.8. */
@@ -2586,7 +2592,7 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
return false;
}
- if (formal->attr.allocatable && !formal->attr.codimension
+ if (formal->attr.allocatable && !codimension
&& actual_attr.codimension)
{
if (formal->attr.intent == INTENT_OUT)
! { dg-do compile }
! { dg-options "-fcoarray=lib" }
!
! Fix for P99818 in which wrong code caused an ICE.
!
! Contributed by Gerhard Steinmetz
!
module m
type t
integer :: a
contains
procedure :: s
end type
contains
subroutine s(x)
class(t) :: x[*]
end
end
program p
use m
associate (y => t(1))
call y%s ! { dg-error "must be a coarray" }
end associate
end
