Re: [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Thanks Mikael. Pushed as r14-1487-g3c2eba4b7a2355ed5099e35332388206c484744d
I should have credited you with the comments that you made about the half
baked patch, which pushed me to this patch.
Regards
Paul
On Thu, 1 Jun 2023 at 18:58, Mikael Morin wrote:
> Le 01/06/2023 à 17:20, Paul Richard Thomas via Fortran a écrit :
> > Hi All,
> >
> > This started out as the search for a fix to pr109948 and evolved to roll
> in
> > 5 other prs.
> >
> > Basically parse_associate was far too clunky and, in anycase, existing
> > functions in resolve.cc were well capable of doing the determination of
> the
> > target expression rank. While I was checking the comments, the lightbulb
> > flashed with respect to prs 102109/112/190 and the chunk dealing with
> > function results of unknown type was born.
> >
> > Thanks to the changes in parse.cc, the problem in pr99326 migrated
> > upstream to the resolution and the chunklet in resolve.cc was an obvious
> > fix.
> >
> > I am minded to s/{ dg-do run}/{ dg-do compile } for all six testcases.
> Makes sense, the PRs were bogus errors and ICEs, so all compile time
> issues.
>
> > At
> > the testing stage, I wanted to check that the testcases actually did what
> > they are supposed to do :-)
> >
> > Bootstraps and regtests OK - good for head?
> >
> OK. Thanks for this.
>
> > Paul
> >
> > PS I need to do some housekeeping on pr87477 now. Some of the blockers
> have
> > "fixed themselves" and others are awaiting backporting. I think that
> there
> > are only 4 or so left, of which 89645 and 99065 are the most difficult to
> > deal with.
>
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
Re: [Patch, fortran] 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
A doubt about IMPORT and SELECT TYPE
Hi, I have a doubt about IMPORT and SELECT TYPE, please see the forwarded message below (that also has a sample code), as well https://www.ibm.com/docs/en/xffbg/121.141?topic=attributes-import-fortran-2003 What is the correct way? Thanks. Regards. Jorge. - Forwarded message - From: "Intel Community" To: "Jorge D'Elia" Sent: Viernes, 2 de Junio 2023 10:28:31 Subject: Re: Bug with IMPORT and SELECT TYPE (Intel Community Subscription Update) Hi jdelia, OP1 (New Contributor II) posted a new reply in Intel® Fortran Compiler on 06-02-2023 10:28 AM in the Intel Community: https://community.intel.com/t5/Intel-Fortran-Compiler/Bug-with-IMPORT-and-SELECT-TYPE/m-p/1492319/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufExJRUxQQzhSUEVaS1RTfDE0OTIzMTl8U1VCU0NSSVBUSU9OU3xoSw#M166583 Subject: Re: Bug with IMPORT and SELECT TYPE Well, it appears that gfortran also gets it wrong... the use of an IMPORT statement is not limited to interfaces. See this paragraph from the Intel documentation: An IMPORT statement can appear in a submodule, module procedure, a contained procedure, the specification part of a BLOCK construct, or in an interface body. It can not appear in the specification part of a main program, external procedure, module, or block data except in an interface body. --
Re: A doubt about IMPORT and SELECT TYPE
Hi Jorge, As I posted in the Intel Community, the error generated by gfortran (and nagfor) is consistent with the F2003 constraint: C1210 (R1209) The IMPORT statement is allowed only in an interface-body. Could you please raise a problem report in gcc Bugzilla? Thanks Paul On Fri, 2 Jun 2023 at 15:04, Jorge D'Elia via Fortran wrote: > > Hi, > > I have a doubt about IMPORT and SELECT TYPE, please see the > forwarded message below (that also has a sample code), as well > > https://www.ibm.com/docs/en/xffbg/121.141?topic=attributes-import-fortran-2003 > > What is the correct way? Thanks. > > Regards. > Jorge. > > - Forwarded message - > From: "Intel Community" > To: "Jorge D'Elia" > Sent: Viernes, 2 de Junio 2023 10:28:31 > Subject: Re: Bug with IMPORT and SELECT TYPE (Intel Community Subscription > Update) > > Hi jdelia, > > OP1 (New Contributor II) posted a new reply in Intel® Fortran Compiler on > 06-02-2023 10:28 AM in the Intel Community: > > https://community.intel.com/t5/Intel-Fortran-Compiler/Bug-with-IMPORT-and-SELECT-TYPE/m-p/1492319/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufExJRUxQQzhSUEVaS1RTfDE0OTIzMTl8U1VCU0NSSVBUSU9OU3xoSw#M166583 > > Subject: Re: Bug with IMPORT and SELECT TYPE > > Well, it appears that gfortran also gets it wrong... the use of an IMPORT > statement is not limited to interfaces. > See this paragraph from the Intel documentation: An IMPORT statement can > appear in a submodule, module procedure, > a contained procedure, the specification part of a BLOCK construct, or in an > interface body. It can not appear in > the specification part of a main program, external procedure, module, or > block data except in an interface body. > > -- -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: A doubt about IMPORT and SELECT TYPE
Hi Jorge, PRs 108650/106035 cover this problem. Thanks Paul On Fri, 2 Jun 2023 at 15:04, Jorge D'Elia via Fortran wrote: > > Hi, > > I have a doubt about IMPORT and SELECT TYPE, please see the > forwarded message below (that also has a sample code), as well > > https://www.ibm.com/docs/en/xffbg/121.141?topic=attributes-import-fortran-2003 > > What is the correct way? Thanks. > > Regards. > Jorge. > > - Forwarded message - > From: "Intel Community" > To: "Jorge D'Elia" > Sent: Viernes, 2 de Junio 2023 10:28:31 > Subject: Re: Bug with IMPORT and SELECT TYPE (Intel Community Subscription > Update) > > Hi jdelia, > > OP1 (New Contributor II) posted a new reply in Intel® Fortran Compiler on > 06-02-2023 10:28 AM in the Intel Community: > > https://community.intel.com/t5/Intel-Fortran-Compiler/Bug-with-IMPORT-and-SELECT-TYPE/m-p/1492319/emcs_t/S2h8ZW1haWx8dG9waWNfc3Vic2NyaXB0aW9ufExJRUxQQzhSUEVaS1RTfDE0OTIzMTl8U1VCU0NSSVBUSU9OU3xoSw#M166583 > > Subject: Re: Bug with IMPORT and SELECT TYPE > > Well, it appears that gfortran also gets it wrong... the use of an IMPORT > statement is not limited to interfaces. > See this paragraph from the Intel documentation: An IMPORT statement can > appear in a submodule, module procedure, > a contained procedure, the specification part of a BLOCK construct, or in an > interface body. It can not appear in > the specification part of a main program, external procedure, module, or > block data except in an interface body. > > -- -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: A doubt about IMPORT and SELECT TYPE
On Fri, Jun 02, 2023 at 03:53:44PM +0100, Paul Richard Thomas via Fortran wrote: > Hi Jorge, > > As I posted in the Intel Community, the error generated by gfortran > (and nagfor) is consistent with the F2003 constraint: C1210 (R1209) > The IMPORT statement is allowed only in an interface-body. > > Could you please raise a problem report in gcc Bugzilla? > There already is a PR about IMPORT. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 There is a patch that is 95-ish% complete. The last 5% is the hard part, which it seems no one has had time or ideas on how to finish the patch. -- Steve
[PATCH, committed] Fortran: fix diagnostics for SELECT RANK [PR100607]
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
From fae09dfc0e6bf4cfe35d817558827aea78c6426f Mon Sep 17 00:00:00 2001
From: Steve Kargl
Date: Fri, 2 Jun 2023 19:44:11 +0200
Subject: [PATCH] Fortran: fix diagnostics for SELECT RANK [PR100607]
gcc/fortran/ChangeLog:
PR fortran/100607
* resolve.cc (resolve_select_rank): Remove duplicate error.
(resolve_fl_var_and_proc): Prevent NULL pointer dereference and
suppress error message for temporary.
gcc/testsuite/ChangeLog:
PR fortran/100607
* gfortran.dg/select_rank_6.f90: New test.
---
gcc/fortran/resolve.cc | 10 ++---
gcc/testsuite/gfortran.dg/select_rank_6.f90 | 48 +
2 files changed, 52 insertions(+), 6 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/select_rank_6.f90
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 2ba3101f1fe..fd059dddf05 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -10020,11 +10020,6 @@ resolve_select_rank (gfc_code *code, gfc_namespace *old_ns)
|| gfc_expr_attr (code->expr1).pointer))
gfc_error ("RANK (*) at %L cannot be used with the pointer or "
"allocatable selector at %L", &c->where, &code->expr1->where);
-
- if (case_value == -1 && (gfc_expr_attr (code->expr1).allocatable
- || gfc_expr_attr (code->expr1).pointer))
- gfc_error ("RANK (*) at %L cannot be used with the pointer or "
- "allocatable selector at %L", &c->where, &code->expr1->where);
}
/* Add EXEC_SELECT to switch on rank. */
@@ -13262,7 +13257,10 @@ resolve_fl_var_and_proc (gfc_symbol *sym, int mp_flag)
if (allocatable)
{
- if (dimension && as->type != AS_ASSUMED_RANK)
+ if (dimension
+ && as
+ && as->type != AS_ASSUMED_RANK
+ && !sym->attr.select_rank_temporary)
{
gfc_error ("Allocatable array %qs at %L must have a deferred "
"shape or assumed rank", sym->name, &sym->declared_at);
diff --git a/gcc/testsuite/gfortran.dg/select_rank_6.f90 b/gcc/testsuite/gfortran.dg/select_rank_6.f90
new file mode 100644
index 000..d0121777bb5
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/select_rank_6.f90
@@ -0,0 +1,48 @@
+! { dg-do compile }
+! PR fortran/100607 - fix diagnostics for SELECT RANK
+! Contributed by T.Burnus
+
+program p
+ implicit none
+ integer, allocatable :: A(:,:,:)
+
+ allocate(a(5:6,-2:2, 99:100))
+ call foo(a)
+ call bar(a)
+
+contains
+
+ subroutine foo(x)
+integer, allocatable :: x(..)
+if (rank(x) /= 3) stop 1
+if (any (lbound(x) /= [5, -2, 99])) stop 2
+
+select rank (x)
+rank(3)
+ if (any (lbound(x) /= [5, -2, 99])) stop 3
+end select
+
+select rank (x) ! { dg-error "pointer or allocatable selector at .2." }
+rank(*) ! { dg-error "pointer or allocatable selector at .2." }
+ if (rank(x) /= 1) stop 4
+ if (lbound(x, 1) /= 1) stop 5
+end select
+ end
+
+ subroutine bar(x)
+integer :: x(..)
+if (rank(x) /= 3) stop 6
+if (any (lbound(x) /= 1)) stop 7
+
+select rank (x)
+rank(3)
+ if (any (lbound(x) /= 1)) stop 8
+end select
+
+select rank (x)
+rank(*)
+ if (rank(x) /= 1) stop 9
+ if (lbound(x, 1) /= 1) stop 10
+end select
+ end
+end
--
2.35.3
Re: A doubt about IMPORT and SELECT TYPE
Hi Steve, As noted in the previous email :-), although I didn't mention the partially cooked patch. One day, once F2003 is sorted, I might turn to F2008/18! Cheers Paul On Fri, 2 Jun 2023, 16:27 Steve Kargl via Fortran, wrote: > On Fri, Jun 02, 2023 at 03:53:44PM +0100, Paul Richard Thomas via Fortran > wrote: > > Hi Jorge, > > > > As I posted in the Intel Community, the error generated by gfortran > > (and nagfor) is consistent with the F2003 constraint: C1210 (R1209) > > The IMPORT statement is allowed only in an interface-body. > > > > Could you please raise a problem report in gcc Bugzilla? > > > > There already is a PR about IMPORT. See > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 > > There is a patch that is 95-ish% complete. The last > 5% is the hard part, which it seems no one has had > time or ideas on how to finish the patch. > > -- > Steve >
Re: A doubt about IMPORT and SELECT TYPE
Oh, I'm not asking you or any of the other regular contributors to gfortran to pick up my WIP patch and finish the last 5%. Now, lurkers on the mailing list, who have always wanted to give back, well I'm more than willing to help explain the patch and what I think needs to be done if they are so inclined to get their hands dirty. IMPORT is an interesting construct. Originally, all entities are blocked from host assocation into an INTERFACE, so J3 invented IMPORT to allow one to cherry pick entities from the host. gfortran's implementation is fairly straightforward. In F2018, J3 extended IMPORT to block host-association in for example a contained subprogram or BLOCK construct. This seems like a logical and good thing; except this is the complete opposite of its original use. Undoing/revising gfortran'sr original implemenation of IMPORT is a bit more challenging. -- steve On Fri, Jun 02, 2023 at 09:14:01PM +0100, Paul Richard Thomas wrote: > Hi Steve, > > As noted in the previous email :-), although I didn't mention the partially > cooked patch. > > One day, once F2003 is sorted, I might turn to F2008/18! > > Cheers > > Paul > > > On Fri, 2 Jun 2023, 16:27 Steve Kargl via Fortran, > wrote: > > > On Fri, Jun 02, 2023 at 03:53:44PM +0100, Paul Richard Thomas via Fortran > > wrote: > > > Hi Jorge, > > > > > > As I posted in the Intel Community, the error generated by gfortran > > > (and nagfor) is consistent with the F2003 constraint: C1210 (R1209) > > > The IMPORT statement is allowed only in an interface-body. > > > > > > Could you please raise a problem report in gcc Bugzilla? > > > > > > > There already is a PR about IMPORT. See > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 > > > > There is a patch that is 95-ish% complete. The last > > 5% is the hard part, which it seems no one has had > > time or ideas on how to finish the patch. > > > > -- > > Steve > > -- Steve
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 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
