[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 --- Comment #18 from Paul Thomas --- (In reply to anlauf from comment #17) > *** Bug 103757 has been marked as a duplicate of this bug. *** Thanks, Harald! Paul
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||b.j.braams at cwi dot nl --- Comment #17 from anlauf at gcc dot gnu.org --- *** Bug 103757 has been marked as a duplicate of this bug. ***
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #16 from Paul Thomas --- Now I have corrected the ChangeLog entries, this can be closed. Thanks for your help on this, Steve. Paul
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 --- Comment #15 from Paul Thomas --- Wrongly pushed as pr106135 - sorry. Will correct wrong pr number tomorrow. The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:743c04db2f93612845e6baa7dabf9e511c3cfd85 commit r16-2189-g743c04db2f93612845e6baa7dabf9e511c3cfd85 Author: Paul Thomas Date: Fri Jul 11 08:28:27 2025 +0100 Fortran: Implement F2018 IMPORT statements [PR106135] 2025-09-09 Paul Thomas gcc/fortran PR fortran/106135 * decl.cc (build_sym): Emit an error if a symbol associated by an IMPORT, ONLY or IMPORT, all statement is being redeclared. (gfc_match_import): Parse and check the F2018 versions of the IMPORT statement. For scopes other than and interface body, if the symbol cannot be found in the host scope, generate it and set it up such that gfc_fixup_sibling_symbols can transfer its 'imported attribute' if it turnes out to be a not yet parsed procedure. Test for violations of C897-8100. * gfortran.h : Add 'import_only' to the gfc_symtree structure. Add the enum, 'importstate', which is used for values the new field 'import_state' in gfc_namespace. * parse.cc (gfc_fixup_sibling_symbols): Transfer the attribute 'imported' to the new symbol. * resolve.cc (check_sym_import_status, check_import_status): New functions to test symbols and expressions for violations of F2018:C8102. (resolve_call): Test the 'resolved_sym' against C8102 by a call to 'check_sym_import_status'. (gfc_resolve_expr): If the expression is OK and an IMPORT statement has been registered in the current scope, test C102 by calling 'check_import_status'. (resolve_select_type): Test the declared derived type in TYPE IS and CLASS IS statements. gcc/testsuite/ PR fortran/106135 * gfortran.dg/import3.f90: Use -std=f2008 and comment on change in error message texts with f2018. * gfortran.dg/import12.f90: New test.
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 Paul Thomas changed: What|Removed |Added Attachment #61467|0 |1 is obsolete|| Attachment #61595|0 |1 is obsolete|| --- Comment #14 from Paul Thomas --- Created attachment 61601 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61601&action=edit Pre-submission version of the patch The attached needs cleaning up but I think that it is now in a satisfactory state from the functional point of view. Such things as s/%s/%qs/ will be done, whitespace checked etc., etc. Paul
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2025-06-06 Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #13 from Paul Thomas --- Created attachment 61595 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61595&action=edit Patch in development for this PR The attached regtests OK. There are two wrinkles noted in the testcase. The error detected by ifx was supposed to be identified by the first chunk in decl.cc so I will have to delve further. I have yet to find the corresponding constraint in the standard. Comments/suggestions are welcome. Paul
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 --- Comment #12 from Paul Thomas --- (In reply to kargls from comment #11) > (In reply to Paul Thomas from comment #9) > > Created attachment 61467 [details] > > Test vehicle for my f2018 import patch > > > > Hi Steve, > > > > Note the sections marked WRINKLE. ifx considers an associate block to be > > executable code such that the import statement cannot appear there. With my > > patch, symbols in the associate target expression are not accepted, unless > > imported into the host scope. > > > > I just check F2023, and ifx is correct. An import statement > is not allowed in an associate construct. As an associate construct > does not have a declaration section. > > R1102 associate‑construct is > associate‑stmt > > end‑associate‑stmt > > as opposed to > > R1107 block‑construct is > block‑stmt > [block‑specification‑part] > > end‑block‑stmt > > R1109 block‑specification‑part is > [ use‑stmt ] ... > [ import‑stmt ] ... > [ declaration‑construct ] Thanks for doing the legwork on that. I'll roll it in. Paul
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 --- Comment #11 from kargls at comcast dot net --- (In reply to Paul Thomas from comment #9) > Created attachment 61467 [details] > Test vehicle for my f2018 import patch > > Hi Steve, > > Note the sections marked WRINKLE. ifx considers an associate block to be > executable code such that the import statement cannot appear there. With my > patch, symbols in the associate target expression are not accepted, unless > imported into the host scope. > I just check F2023, and ifx is correct. An import statement is not allowed in an associate construct. As an associate construct does not have a declaration section. R1102 associate‑construct is associate‑stmt end‑associate‑stmt as opposed to R1107 block‑construct is block‑stmt [block‑specification‑part] end‑block‑stmt R1109 block‑specification‑part is [ use‑stmt ] ... [ import‑stmt ] ... [ declaration‑construct ]
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 --- Comment #10 from kargls at comcast dot net --- (In reply to Paul Thomas from comment #8) > Created attachment 61466 [details] > > As I wrote elsewhere, I should have checked if anybody else is working on > import. Apologies for treading on your toes. No need to apologies. As the audit trail indicates I got stuck and then ran into have too little time to actually work out how to handle import-list. > > The testcase that I have been using follows. > > Some important differences between our patches: > > 1) I have assumed and import, only :: import_list>. Does this need an interpretation request? My reading agrees with your interpretation above. From F2003, made all host symbols available within an interface body. seems to be just a more verbose way of spelling . Until you mentioned it, I unconsciously assumed was the same as . It seems that J3 is simply extending the . Note, the use of only a single colon. The older former from F2003 must still be accepted for backwards compatibility. > > 2) I retained the original functioning of 'has_import_set' until such time > as f2018 import functions to my satisfaction. Your approach is better. > > 3) resolve.cc(check_import_status) is (possibly?) the wrong approach > compared with your checking of host association in symbol.cc. This is where I got stuck. is easy as host association is simply blocked in symbol.cc. I was unable to come up with a way to implement . My idea as to construct a linked list of symbol names within the current namespace, but that's as far as I got. > > 4) I think that my error messages are more helpful, if considerably less > concise. > > A merging of the best features from both might be in order. > Feel free to take or ignore anything from my WIP patch. One that you may want to carry over is the big comment above gfc_match_import with the EBNF of the various standards. Once you have something that you're happy with, feel free to ping me for a review.
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 --- Comment #9 from Paul Thomas --- Created attachment 61467 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61467&action=edit Test vehicle for my f2018 import patch Hi Steve, Note the sections marked WRINKLE. ifx considers an associate block to be executable code such that the import statement cannot appear there. With my patch, symbols in the associate target expression are not accepted, unless imported into the host scope. Cheers Paul
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #8 from Paul Thomas --- Created attachment 61466 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61466&action=edit The patch that I had been working on Hi Steve, As I wrote elsewhere, I should have checked if anybody else is working on import. Apologies for treading on your toes. The testcase that I have been using follows. Some important differences between our patches: 1) I have assumed and . Does this need an interpretation request? 2) I retained the original functioning of 'has_import_set' until such time as f2018 import functions to my satisfaction. Your approach is better. 3) resolve.cc(check_import_status) is (possibly?) the wrong approach compared with your checking of host association in symbol.cc. 4) I think that my error messages are more helpful, if considerably less concise. A merging of the best features from both might be in order. Paul
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 --- Comment #7 from kargls at comcast dot net --- Bummer. Seems I lost my WIP on this bug. 'import, none' would be handy for block host association in contained subprograms in my current development.
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 --- Comment #6 from Steve Kargl --- On Fri, Jun 02, 2023 at 05:51:17PM +, [email protected] wrote: > > --- Comment #5 from Jorge D'Elia --- > > The access restriction is a reason of the use IMPORT statements in the > projects, since it is a very convenient and nifty way to detect any name > collision between local entities and host-associated entities, and well as, in > BLOCK statements, for the same purpose. Jorge, I agree with you 100% on the usefulness of IMPORT. The 2nd patch I attached to this PR is almost complete. That is, 'import', 'import, none', and 'import, all' work as defined in F2018. Unfortunately, 'import, only :: a, b, etc' does not work and I haven't had time to work out the details. My first thought is to create a list of allowed use-associated symbols. The list would be added to the current namespace after verifying the symbols are in a parent namespace, but that's as far as I've gotten.
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 Jorge D'Elia changed: What|Removed |Added CC||[email protected]. ||ar --- Comment #5 from Jorge D'Elia --- Hi, The access restriction is a reason of the use IMPORT statements in the projects, since it is a very convenient and nifty way to detect any name collision between local entities and host-associated entities, and well as, in BLOCK statements, for the same purpose. However, with the test: $ cat import1.f90 module m_modulo implicit none (type, external) contains subroutine ss (ii) import, all implicit none (type, external) integer, intent (in) :: ii associate (i_loc => ii) end associate end subroutine ss end module m_modulo compiled with, (i) $ gfortran --version GNU Fortran (GCC) 12.3.1 20230508 (Red Hat 12.3.1-1) Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gfortran -march=native -mtune=native -m64 -fall-intrinsics -fcheck=all -fimplicit-none -fmax-errors=4 -fno-finite-math-only -fPIC -pthread -std=f2018 -Wall -Waliasing -Warray-temporaries -Wcharacter-truncation -Werror -Wextra -Wimplicit-interface -Wimplicit-procedure -Wintrinsic-shadow -Wline-truncation -Wrealloc-lhs-all -Wsurprising -Wtabs -Wunused-parameter -flto -O2 -o import1.exe import1.f90 import1.f90:5:11: 5 | import, all | 1 Error: IMPORT statement at (1) only permitted in an INTERFACE body f951: all warnings being treated as errors and next compiled with (ii): $ nagfor ../import1.f90 -O3 rm: cannot remove '*.original': No such file or directory NAG Fortran Compiler Release 7.1(Hanzomon) Build 7115 Error: ../import1.f90, line 2: Syntax error detected at NONE@( Error: ../import1.f90, line 5: The IMPORT statement is only allowed in an INTERFACE body detected at IMPORT@, Error: ../import1.f90, line 5: Syntax error detected at IMPORT@, Error: ../import1.f90, line 6: Syntax error detected at NONE@( [NAG Fortran Compiler pass 1 error termination, 4 errors] Thus, the errors generated by gfortran and nagfor are consistent with the F2003 constraint: C1210 (R1209) "The IMPORT statement is allowed only in an interface-body". However, the use of IMPORT in the previus test is new in F2018, which neither gfortran nor NAG Fortran support, that is: "The IMPORT statement can appear in a contained subprogram or BLOCK construct, and can restrict access via host association; diagnosis of violation of the IMPORT restrictions is required". Thus, this example should be valid F2018 but not F2008 or earlier. For instance, one can have a unit testing framework that relies extensively on BLOCK constructs, and having the guarantee that any potential conflict (between a local block entity and an entity of the host procedure) will be flagged by the compiler (when using an IMPORT statement in each block construct) sould be a godsend.
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 kargl at gcc dot gnu.org changed: What|Removed |Added CC||Boyce at engineer dot com --- Comment #4 from kargl at gcc dot gnu.org --- *** Bug 108650 has been marked as a duplicate of this bug. ***
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 kargl at gcc dot gnu.org changed: What|Removed |Added Attachment #53187|0 |1 is obsolete|| --- Comment #3 from kargl at gcc dot gnu.org --- Created attachment 55242 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55242&action=edit New diff New diff with changes to gfortran.h
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #0) > % cat a.f90 > program bug >implicit none >integer i >i = 42 >block > import none ! <-- This is valid Fortran 2018 Note, there is a comma missing after import. So this isn't valid. One finds these things while implementing a patch. The patch includes a description of all constraints in F2018, but I did not implement them all. For example, this is invalid (assuming i and j are available via host association) interface subroutine foo import, only : i import end subroutine foo end interface as is interface subroutine foo import, only : i import :: j end subroutine foo end interface To do this correctly, gfortran likely needs IMPORT_NONE, IMPORT_ONLY, and IMPORT_ALL enumerators and then gfc_current_ns->has_import_set would be set according to one of these instead of using just 0 and 1 for a namespace.
[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 --- Comment #1 from kargl at gcc dot gnu.org --- Created attachment 53187 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53187&action=edit implementation of feature; no testcases The attach patch has had some minimal testing while it was under development. For those test, the patch and gfortran appeared to do the right things.
